一次HTTP請求到瀏覽器呈現頁面都發生了什麼

拋去瀏覽器的內部基礎機制和返回頁面的渲染之類的不說，當從網絡的角度來看其中的基本步驟：

１.瀏覽器查看緩存，若是請求的內容在緩存之中而且是在存活時限以內就會執行第10步

２.瀏覽器會向操做系統詢問該請求對應的IP地址

操做系統開始尋找域名對應的IP地址並最終返回給瀏覽器。系統查找IP地址，通常先查看瀏覽器的緩存，若是緩存中沒有請求域名對應的IP地址，就會去查找在本地的host文件中是否存在對應的IP，若是還找不到就會詢問DNS服務器。

 

DNS解析過程

３.瀏覽器開始創建與服務器的TCP鏈接

HTTP的底層是依靠TCP來通訊的，因此簡單介紹一些TCP／IP協議：

TCP/IP 協議族裏重要的一點就是分層。TCP/IP 協議族按層次分別分爲如下 4 層：應用層、傳輸層、網絡層和數據鏈路層。

應用層：應用層決定了向用戶提供應用服務時通訊的活動（如FTP，DNS，HTTP）。

傳輸層：傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。

在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議和 UDP（User Data Protocol，用戶數據報協議）。

網絡層：網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方。

鏈路層：用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動NIC（Network Interface Card，網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內。

下圖是TCP/IP的信息流：

 

TCP/IP信息流

HTTP通訊是基於TCP/IP協議的，所以在通訊以前會與目標服務器創建TCP鏈接，TCP爲了保證可靠性，會進行三次握手，確認雙方正式創建鏈接。

第一次握手：創建鏈接。客戶端發送鏈接請求報文段，將SYN位置爲1，Sequence Number爲x；而後，客戶端進入SYN_SEND狀態，等待服務器的確認；

第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，須要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，本身本身還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述全部信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN+ACK報文段。而後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢之後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

 

三次握手

 

三次握手

4.瀏覽器經過TCP鏈接發送HTTP請求

TCP鏈接創建後就能夠開始發送HTTP報文了，因爲底層通訊使用了TCP/IP協議，所以HTTP報文在客戶端會被層層包裝添加TCP/IP協議中每一層的首部信息，直到被包裝後的請求內容到達服務器端。服務器端接收到信息後又會逆向層層解包直到獲得本來的HTTP報文。

 

HTTP經過TCP/IP信息流

5.服務器接收到請求後對請求作出處理，而後返回HTTP response。

通常來講，服務器接收到請求會根據請求的路徑尋找一個能夠處理該請求的程序。用MVC框架來解釋就是：根據請求的路徑找到對應處理請求的controller，以後控制器會調用業務邏輯處理請求，而後返回一個Model，以後經過視圖解析器的包裝最終變成一個response而後經過已經創建好的TCP鏈接以一樣的傳輸方式返回給瀏覽器。

6.瀏覽器接收到HTTP響應，選擇關閉TCP鏈接，或者繼續維持等待下一次請求的發生若是選擇關閉鏈接，會進行TCP的四次揮手

第一次揮手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

第二次揮手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；

第三次揮手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次揮手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

 

四次揮手

7.瀏覽器檢查收到的響應的狀態碼

瀏覽器檢查響應是不是一個重定向響應或者是一個須要特殊處理的響應(3xx的狀態碼)，或者是須要從新認證(401狀態碼)，或者錯誤(4xx和5xx狀態碼)等；瀏覽器會和正常的響應(2xx)相區別並做出不一樣的應對。

 

HTTP狀態碼

8.若是緩存是可用的，響應會被放入緩存

9.瀏覽器對響應進行解碼(一般使用gzip)

10.瀏覽器真正決定如何處理這個響應

判斷響應是什麼文件，好比是HTML頁面或者是圖片，又或者是聲音文件。若是是頁面，瀏覽器會渲染並呈現給用戶，又或者是提供認證或者是下載的窗口等，取決於瀏覽器收到了什麼類型的響應。

下面的兩個圖能夠輔助理解這個過程：

 

HTTP工做流程

 

各個協議之間的關係

若是請求使用了HTTPS那麼流程會有什麼不一樣？

HTTPS其實是爲了保證HTTP的安全性而在HTTP的基礎上加入加密處理和認證等機制。一般，HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼HTTP。

 

HTTP和HTTPS

實際上無論怎麼稱呼，實現安全性的一種通用的措施就是對通訊內容進行加密。那麼最經常使用的兩種加密方式無非是對稱加密和非對稱加密。對稱加密即雙方持有相同的密鑰進行加密和解密，可是在網絡環境下如何傳輸密鑰就成了問題。因而出現了非對稱加密通訊雙方持有對方的公鑰和本身的私鑰，使用公鑰加密，私鑰解密。很明顯對稱加密的效率要比非對稱加密高，所以HTTPS使用了混合加密的方式。用非對稱加密傳輸共享密鑰，而後用共享密鑰進行對稱加密傳輸。

所以HTTPS的通訊過程大概以下圖所示

 

HTTPS通訊過程

步驟 1：客戶端經過發送Client Hello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。

步驟 2： 服務器可進行SSL通訊時，會以Server Hello報文做爲應答。和客戶端同樣，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3： 以後服務器發送Certificate報文。報文中包含公開密鑰證書。

步驟 4： 最後服務器發送Server Hello Done報文通知客戶端，最初階段的 SSL 握手協商部分結束。

步驟 5： SSL 第一次握手結束以後，客戶端以Client Key Exchange報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲Pre-mastersecret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。

步驟 6： 接着客戶端繼續發送Change Cipher Spec報文。該報文會提示服務器，在此報文以後的通訊會採用Pre-master secret密鑰加密。

步驟 7： 客戶端發送Finished報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

步驟 8： 服務器一樣發送Change Cipher Spec報文。

步驟 9： 服務器一樣發送Finished報文。

步驟 10： 服務器和客戶端的Finished報文交換完畢以後，SSL鏈接就算創建完成。固然，通訊會受到SSL的保護。今後處開始進行應用層協議的通訊，即發送HTTP請求。

步驟 11： 應用層協議通訊，即發送HTTP響應。

步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送close_notify報文。上圖作了一些省略，這步以後再發送TCP FIN報文來關閉與TCP的通訊。

下面的圖對上面的流程作了一個補充：

 

HTTPS通訊協商

也就是流程中從第1步到第9步都是經過協商肯定對稱加密的過程，第九步結束以後，通訊雙方都肯定了使用對稱加密，確認雙方使用了同一個共享的密鑰，以後的通訊就是在對稱加密基礎上的通訊了。

參考：

圖解HTTP

what happens when you type in a URL in browser

alex/what-happens-when