HTTP請求流程你瞭解了麼？

預備知識

前文沒有描述到傳輸和協議直接的層級對應關係，大概補充下網絡通訊中數據傳輸對應的協議，首先了解下OSI(開放式系統互聯:Open System InterConnection)七層 模式，及其對應不一樣層次的協議。

OSI體系結構	TCP/IP相關協議結構
應用層	HTTP,Telnet，FTP等
表示層
會話層
傳輸層	TCP,UDP
網絡層	IP
數據鏈路層
物理層

瞭解到HTTP協議是創建在TCP鏈接基礎之上的。HTTP 是一種容許瀏覽器向服務器獲取資源的協議，是 Web 的基礎，一般由瀏覽器發起請求，用來獲取不一樣類型的文件， 例如 HTML 文件、CSS 文件、JavaScript 文件、圖片、視頻等。此外，HTTP 也是瀏覽器使用最廣的協議。

咱們對HTTP不太瞭解的話都會存在這樣的疑惑，爲何再次訪問同一站點會比第一次快，登陸過一次後的網站再次訪問就處於登陸狀態等，咱們 經過對HTTP請求過程的剖析來解開這些謎團。

瀏覽器端發起 HTTP 請求流程

瀏覽器輸入網址：http://time.geekbang.org/index.html，以後會完成什麼步驟呢？

一、構建請求

首先，瀏覽器構建請求行信息，構建好後，瀏覽器準備發起網絡請求。

GET /index.html HTTP1.1

二、查找緩存

在真正發起網絡請求以前，瀏覽器會先在瀏覽器緩存中查詢是否有要請求的文件。其中，瀏覽器緩存是一種在本地保存資源副本，以供下次請求時直接使用的技術。

當瀏覽器發現請求資源已經存在瀏覽器緩存中存有副本，則會攔截請求並返回該資源副本結束請求。若是查找緩存失敗，則會進入網絡請求。因此會有利於：

• 緩解服務器端壓力，提高性能

• 對於網站來講，緩存是實現快速資源加載的重要組成部分，減小了獲取資源的時間。

三、準備IP地址和端口

咱們經過開頭預備知識和前文也大概瞭解到了HTTP和TCP的關係。瀏覽器使用 HTTP 協議做爲應用層協議，用來封裝請求的文本信息；並使用 TCP/IP 做傳輸層協議將它發到網絡上，因此在 HTTP 工做開始以前，瀏覽器須要經過 TCP 與服務器創建鏈接。也就是說 HTTP 的內容是經過 TCP 的傳輸數據階段來實現的。

TCP和HTTP的關係示意圖：

據此，咱們能夠知道創建HTTP網絡請求就是，經過URL地址來解析獲取IP和端口信息，創建服務器和TCP鏈接。咱們經過前文《TCP協議》 說到了數據包都是經過IP地址傳輸給接收方的。而咱們網站通常的地址都是域名，因此須要把域名和IP地址作映射關係，即解析IP地址的系統「域名系統(DNS)」解析出 IP地址，並獲取對應端口號得到創建鏈接的前置條件。換句話說，即瀏覽器請求DNS返回域名對應的IP，而請求DNS時也會查詢DNS數據緩存服務，判斷是否域名已解析過， 若是解析過則查詢直接使用，拿到IP後則判斷URL是否指明端口號，沒有則HTTP協議默認時80端口。

四、等待TCP隊列

Chrome 有個機制，同一個域名同時最多隻能創建 6 個 TCP 鏈接，若是在同一個域名下同時有 10 個請求發生，那麼其中 4 個請求會進入排隊等待狀態，直至進行中的請求完成。固然，若是當前請求數量少於 6，會直接進入下一步，創建 TCP 鏈接。

五、創建TCP鏈接

隊列等待結束後，TCP和服務器實現「三次握手」（前文TCP協議有描述），即客戶端和服務器發送三個數據包以確認鏈接，實現瀏覽器和服務的鏈接。

六、發送HTTP請求

一旦創建了 TCP 鏈接，瀏覽器就能夠和服務器進行通訊了。而 HTTP 中的數據正是在這個通訊過程當中傳輸的。

HTTP請求數據格式：

首先瀏覽器會向服務器發送請求行，它包括了請求方法、請求 URI（Uniform Resource Identifier）和 HTTP 版本協議。

其中請求方式有GET，POST,PUT,Delete等，其中經常使用的POST會用於發送一些數據給服務器，好比登陸網站把用戶信息發送給服務器，通常 這些數據會經過請求體發送。

在瀏覽器發送請求行命令以後，還要以請求頭形式發送其餘一些信息，把瀏覽器的一些基礎信息告訴服務器。好比包含了瀏覽器所使用的操做系統、瀏覽器內核等信息，以及當前請求的域名信息、Cookie等。

服務器端處理 HTTP 請求流程

一、返回請求

curl -i https://time.geekbang.org/

經過curl工具(或network面板)咱們能夠了解到服務器返回的數據格式：

首先服務器會返回響應行，包括協議版本和狀態碼。

若是出現錯誤，服務器會經過請求行的狀態碼來返回對應的處理結果，例如：

• 最經常使用的狀態碼是 200，表示處理成功；

• 404，表示沒有找到頁面

• 500，表示服務器錯誤

正如瀏覽器會隨同請求發送請求頭同樣，服務器也會隨同響應向瀏覽器發送響應頭。響應頭包含了服務器自身的一些信息， 好比服務器生成返回數據的時間、返回的數據類型（JSON、HTML、流媒體等類型），以及服務器要在客戶端保存的 Cookie 等信息。

響應頭以後，服務器會發送響應體數據，一般包含了HTML的實際內容。以上爲服務器響應瀏覽器的過程。

二、斷開鏈接

一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 鏈接。不過若是瀏覽器或者服務器在其頭信息中加入了：

Connection:Keep-Alive

則TCP 鏈接在發送後將仍然保持打開狀態，這樣瀏覽器就能夠繼續經過同一個 TCP 鏈接發送請求。保持 TCP 鏈接能夠省去下次請求時須要創建鏈接的時間，提高資源加載速度。 若是一個頁面內嵌的圖片都來自同一web站點，則初始化一個持久鏈接則可複用減小TCP的鏈接。

三、重定向

重定向返回響應行和響應頭:

狀態 301 就是告訴瀏覽器，我須要重定向到另一個網址，而須要重定向的網址正是包含在響應頭的 Location 字段中，接下來，瀏覽器獲取 Location 字段中的地址，並使用該地址從新導航，這就是一個完整重定向的執行流程。

總結

經過http請求的完整過程，咱們就知道，請求過程當中DNS緩緩和頁面資源緩存會被瀏覽器緩存起來，以減小向服務器請求的資源，因此會再次請求站點時速度會快。

瀏覽器資源緩存處理過程：

從上圖的第一次請求能夠看出，當服務器返回 HTTP 響應頭給瀏覽器時，瀏覽器是經過響應頭中的 Cache-Control 字段來設置是否緩存該資源。一般，咱們還須要爲這個資源設置一個緩存過時時長，而這個時長是經過 Cache-Control 中的 Max-age 參數來設置的。

所以在該緩存資源還未過時的狀況下, 若是再次請求該資源，會直接返回緩存中的資源給瀏覽器。

若是緩存過時了，瀏覽器則會繼續發起網絡請求，而且在 HTTP 請求頭中帶上If-None-Match，服務器收到請求頭後，會根據 If-None-Match 的值來判斷請求的資源是否有更新。

• 若是沒有更新，就返回 304 狀態碼，至關於服務器告訴瀏覽器，這個緩存能夠繼續使用。

• 若是資源有更新，服務器就直接返回最新資源給瀏覽器。

登陸網站，經過POST方式提交信息給服務器，服務器接收到瀏覽器提交的信息以後，查詢驗證信息正確則會生成表面用戶身份的字符串寫入響應頭的Set-Cookie字段裏返回瀏覽器。

瀏覽器解析響應頭，若有Set-Cookie字段則保存在本地，當用戶再次訪問時，發起HTTP請求前瀏覽器會讀取Cookie數據並寫入請求頭髮送到服務器，服務器再次判斷信息，若是 正確則展現用戶登陸狀態及用戶信息。

最後總結出瀏覽器中的HTTP請求從發起到結束一共經歷了八個階段：構建請求、查找緩存、準備 IP 和端口、等待 TCP 隊列、創建 TCP 鏈接、發起 HTTP 請求、服務器處理請求、服務器返回請求和斷開鏈接。

詳細HTTP請求流程：