【HTTP】Http協議知識點

HTTP協議簡介

　　HTTP 協議是互聯網中最普遍使用的協議，也是作web開發的基礎。咱們先了解下HTTP協議發展的歷史。

　　　　1. HTTP/0.9（1991年）：

　　　　　　是HTTP協議第一個協議，不過比較簡單，只有一個GET命令用於獲取文件，沒有請求頭（HEADER）。

第一個定稿的HTTP版本

做者：nickcau
連接：http://www.imooc.com/article/266160
來源：慕課網
本文首次發佈於慕課網 ，轉載請註明出處，謝謝合做

第一個定稿的HTTP版本

做者：nickcau
連接：http://www.imooc.com/article/266160
來源：慕課網
本文首次發佈於慕課網 ，轉載請註明出處，謝謝合做

　　　　2. HTTP/1.0（1996年）：

　　　　　　相較於0.9版本很是健全了。規定了http請求由請求頭，請求體，對應的還有響應頭，響應體。除了GET命令，還增長了POST，HEAD等命令。

　　　　3. HTTP/1.1（1997年）：

　　　　　　增長了connection：keep-alive，以前版本http請求在請求一次完成後就斷開，不可以持久鏈接。有了keep-alive就能夠複用以前的鏈接，減小由於TCP鏈接致使的性能損耗。這裏提一點，爲何http能夠同時發送多個請求，可是這個多個請求也是由上限的，若是同時請求過多，鏈接數增大會致使瀏覽器負載壓力很大，同時也不必定提升性能。因此通常要有個權衡。如今瀏覽器都有本身的設置，好比谷歌瀏覽器同一個域名下同時http請求數限制在6個。火狐瀏覽器也是6個，以下圖

　　

 　　

　　HTTP1.0存在的問題

　　　　1）.明文傳輸，意味着沒有壓縮，致使傳輸效率低，在早期因爲傳輸內容少，當時徹底能夠用的。對於如今web2.0時代隨便打開一個網頁可能都會加載十幾個js，css文件還有不少圖片。

　　　　2）.傳輸方式是竄行的，就是說同時發送多個http請求，必須加載完第一個請求後才能加載第二個請求，而後以此類推，這種方式效率很低。

　　　　3）.header頭部很長，須要加載不少內容。

　　　　4）.server端不能主動push（固然能夠選擇Websocket技術）。

 

　　　　4.HTTP/2.0（2015年）：

　　　　　　如今幾乎全部的主流瀏覽器都支持http2.0協議。http2.0針對以前http版本一些缺陷作出了改進，尤爲是性能上的優化，主要又下面的改進：

　　　　　　1）再也不使用明文，而採用二進制的傳輸方式，頭信息和數據體都是二進制，對明文進行了極大的壓縮。

　　　　　　2）基於上面二進制方式，http2.0有一個新的概念，叫作幀（frame）。幀是http2.0中消息傳遞方式最小單位。這個是借鑑了bt下載的思想，將傳輸內容分紅塊進行傳輸，http2.0就是經過幀的形式打包進行傳輸請求頭，請求體等信息。

　　　　　　3）HEAD 壓縮。

　　　　　　4）服務器推送。

　　　　　　5）優先級請求。

　　　　　　6）多路複用。

 　　　　　  7）HTTP2.0握手分2種方式，一種叫h2，一種叫h2c。h2要求必須使用TLS加密，在TLS握手期間會順帶完成HTTPS/2協議的協商，若是協商失敗（好比客戶端不支持或者服務端不支持），則會使用HTTPS/1繼續後續通信。h2c不使用TLS，而是多了一次基於HTTP協議的握手往返來完成向HTTP/2協議的升級通常不建議使用。

 

　　　　　　看下HTTP2.0 與HTTP1.0性能對比

　　　　　　

 

 　　　　　　上面這個網站顯示兩張圖片，每張圖片都是由幾百張小圖片組成，左邊圖片是利用HTTP1.0的技術去加載，右邊是由HTTP2.0的技術加載。根據上面顯示的時間能夠看出HTTP2.0所須要的時間遠遠小於HTTP1.0的時間。這是由於HTTP1.0對於同一個域名同時最多隻能創建6個鏈接，而且在請求完一個只會才能請求下一個。HTTP2.0經過幀的方式將傳輸數據打散而後在客戶端重組。

　　　　　　

 

　　　　5.HTTP/3.0（2019年）

 　　　　　　http3.0將會從基於TCP的鏈接變成基於UDP的鏈接。

 

 　　　　相關文檔：

　　　　 HTTP RFC文檔： https://www.w3.org/Protocols/rfc2616/rfc2616.html

 　　　　HTTP2文檔：　　http://http2.github.io/http2-spec/    

　　　　　　　　　　　　  https://hpbn.co/http2/#header-compression 

　　　　 SSL/TSL協議RFC文檔：     https://tools.ietf.org/html/rfc5246　　

 

HTTP協議特色

　　1. HTTP是無鏈接的，HTTP客戶端發起HTTP請求，發出請求後，客戶端將斷開與服務器的鏈接並等待響應。服務器處理請求並從新創建與客戶端的鏈接以發回響應。

　　  2. HTTP是無狀態的，HTTP是無鏈接的，這是HTTP是無狀態協議的直接結果。服務器和客戶端僅在當前請求期間相互瞭解。以後他們就斷開鏈接。因此客戶端和瀏覽器都不能在跨網頁的不一樣請求之間保留信息。 

 

 

HTTP協議棧所在位置

 

HTTP三次握手

　　http在進行客戶端和服務端創建通訊鏈路的過程當中須要建立tcp connection，由於http協議是工做在應用層，不承載鏈接任務都是基於tcp。http在在tcp基礎上去進行請求和響應。而http在建立鏈接時候會有三次握手。

　　　　　　　　　　TCP三次握手時序圖

 

 

HTTP狀態碼

    HTTP狀態碼是用以表示網頁服務器HTTP響應狀態的3位數字代碼。全部狀態碼的第一個數字表明瞭響應的五種狀態之一。當用戶試圖經過HTTP或FTP協議訪問一臺運行主機上的內容時，Web服務器返回一個表示該請求的狀態的數字代碼。該狀態代碼記錄在服務器日誌中，同時也可能在 Web 瀏覽器或 FTP客戶端顯示。也就是咱們打開頁面發生錯誤時，瀏覽器顯示的錯誤信息代碼。狀態代碼能夠指明具體請求是否已成功，還能夠揭示請求失敗的確切緣由。

HTTP協議狀態碼錶示的意思主要分爲五類，大致是:

• 1××：保留
• 2××：表示請求成功地接收
• 3××：爲完成請求客戶需進一步細化請求
• 4××：客戶錯誤
• 5××：服務器錯誤

      下面是一些常見的HTTP狀態碼

狀態碼	解釋
500 (內部服務器錯誤)	對HTTP 500錯誤的定義已經充分證實了這是一個最多見的HTTP錯誤。 通常來講，HTTP 500 錯誤會在服務器的程序碼出錯時出現，或者web服務器發生內部錯誤時返回的信息。 例如，web服務器過載時將沒法正確處理訪問請求。
502 (無效網關)	做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503 (服務不可用)	503錯誤也是服務器問題，表示服務當前不可用(Service unavaiable)，多是由於當前服務器繁忙沒法處理請求，好比鏈接數過高，cpu繁忙等。
404 (文件未找到)	大多數人都知道這個錯誤。 當用戶試圖訪問Web服務器（一般是一個網頁）上某個實際不存在的資源時，就會發生404錯誤。404錯誤多是由無效的連接引發，也多是URL拼 寫錯誤，還多是由於虛擬主機將所請求頁面移到其餘地方（或刪除所請求頁面）。一些網站設置了自定義頁面以防止壞連接所產生的不良影響。
403 (禁止訪問)	403錯誤相似於401錯誤，不一樣之處在於401錯誤是未經受權，而403錯誤是禁止訪問。 任何登陸對403錯誤都不起做用。嘗試訪問（被禁止的）網站目錄時，就會發生403錯誤。
400 (錯誤請求)	Web服務器經過返回HTTP 400錯誤告訴訪問者，訪問者用來訪問網站的程序出錯，或訪問請求途中遭到破壞。
401 (未經受權)	訪問者試圖訪問受限頁面但未經受權時，網站返回HTTP 401錯誤。錯誤登陸嘗試是致使這一錯誤的主因。
301 (永久重定向)	被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。
302 (臨時重定向)	請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。
304 (Not Modified)	請求資源沒有改變，可使用緩存的內容。在請求中附帶了頭部信息： If-None-Match 或If-Modified-Since。 若是是 200 OK ，響應會帶有頭部 Cache-Control, Content-Location, Date, ETag, Expires。
200 (請求成功)	請求已成功，請求所但願的響應頭或數據體將隨此響應返回。
206 (部份內容)	服務器已經成功處理了部分GET請求。相似於FlashGet或者迅雷這類的HTTP 下載工具，都是使用此類響應實現斷點續傳，或者將一個大文檔分解爲多個下載段同時下載。

 

 

 

 HTTP安全響應頭

　　　　目的：保護用戶的安全，也就是一般意義上的防止用戶受到各類攻擊，如XSS、CSRF。

　　　　1.Set-Cookie：由服務器端向客戶端發送 cookie。

　　　　2. Access-Control-Allow-Origin：容許訪問控制同源，實現跨域訪問，它有多個CORS相關字段。

　　　　3. Authorization ：HTTP協議中的 Authorization 請求消息頭含有服務器用於驗證用戶代理身份的憑證，一般會在服務器返回401 Unauthorized 狀態碼以及WWW-Authenticate 消息頭以後在後續請求中發送此消息頭。

　　　　4. X-XSS-Protection：用於開啓瀏覽器的XSS過濾功能，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將中止加載頁面，以防止XSS跨站腳本攻擊。

　　　　5. Content-Security-Policy：中文名內容安全策略，主要思想是經過內容來源白名單機制，使瀏覽器僅渲染或執行來自這些來源的資源。容許站點管理者控制用戶代理可以爲某個頁面獲取哪些資源。

更多http安全信息能夠訪問 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials

　　　　

 

HTTP管道技術（Pipelining ）

　　通常瀏覽器會在收到上一個請求的響應以後，再發送下一個請求。而http管道技術就是能夠將多個http請求同一批發送，這些http請求使用同一個 TCP 鏈接，而發送過程當中客戶端不須要等待服務器對前一個請求的響應。

　　　　http無管道和有管道示意圖

 　　

 

 

 HTTP 緩存　　

 　　HTTP換成分爲兩類：強制緩存，協商緩存。

　　 HTTP緩存相關頭信息：

　　　　1.強緩存：Pragma、Cache-Control、Expries。

　　　　2.協商緩存：Last-Modified/If-Modified-Since、Etag/If-None-Match。

 

HTTP 代理

　　HTTP 代理（Web 代理）實際上是一種存在於網絡中間的實體，能夠提供各類功能，位於客戶端和服務端之間，扮演「中間人」的角色，在兩端之間來回傳遞報文。。

Keep-Alive模式

 

多路複用

 

HTTP長鏈接

 

　　

SPDY協議

 

 

HTTP協議應用-防盜鏈

 

 

HTTP協議與Cookie

 　　Cookie的產生就是爲了解決 HTTP 協議無狀態的問題。Cookie是可以讓網站 Web 服務器把少許數據儲存到客戶端的硬盤或內存裏，或是從客戶端的硬盤裏讀取數據的一種技術。

　　原理：

　　　　服務端經過 Set-Cookie 這個響應頭來向客戶端中寫入 Cookie 信息，而客戶端讀取 Set-Cookie 這個響應頭中的信息存儲起來，在下次請求的時候取出來，再經過 Cookie這個請求頭，將 Cookie 的數據傳輸給服務端。

 　　

 

 

HTTP與HTTPS

　　因爲HTTP協議自己是不夠安全的，好比在咱們登錄網站的時候，帳號和密碼經由Http協議傳輸到服務器上，這中間可能或有人能夠截取信息，這樣信息就會不安全，好比著名的中間人攻擊。因此爲了解決http在傳輸過程當中不加密的問題，以後就增長了一個SSL協議，這個協議提供了數據安全和完整性，也就是負責網絡鏈接安全。

 

 

參考來源：

　　https://mp.weixin.qq.com/s/xc8A2dKlZmPHUhFcAevPxw