HTTP協議原理

上篇文章我們以一個訪問我的部落格shiyujun.cn為例子描述了如何把一個域名轉化為ip這個過程，那麼拿到ip之後的交互過程是什麼樣的呢

第一步就是客戶端和服務端之間建立連接，也就是基於3次握手。這個之前的文章中也提到過了

接著就是發生http請求，一個http請求的格式是這樣的（紅色字體是我給出的示例）：

HTTP 請求報文封裝完成後，數據來到了TCP層

TCP 層發送每一個報文的時候，都需要加上自己的地址（即源地址）和它想要去的地方（即目標地址），將這兩個資訊放到 IP 頭裡面，交給 IP 層進行傳輸

IP 層需要查看目標地址和自己是否是在同一個區域網。如果是，就發送 ARP 協議來請求這個目標地址對應的 MAC 地址，然後將源 MAC 和目標 MAC 放入 MAC 頭，發送出去即可。

如果不在同一個區域網，就需要發送到網關，發送 ARP 協議，獲取網關的 MAC 地址，然後將源 MAC 和網關 MAC 放入 MAC 頭，發送出去

網關收到包發現 MAC 符合，取出目標 IP 地址，根據路由協議找到下一跳的路由器，獲取下一跳路由器的 MAC 地址，將包發給下一跳路由器。

這樣路由器一跳一跳終於到達目標的區域網。這個時候，最後一跳的路由器能夠發現，目標地址就在自己的某一個出口的區域網上。於是，在這個區域網上發送 ARP，獲得這個目標地址的 MAC 地址，將包發出去。

目標的機器發現 MAC 地址符合，就將包收起來。發現 IP 地址符合，根據 IP 頭中協議項，知道自己上一層是 TCP 協議，於是解析 TCP 的頭，裡面有序列號，需要看一看這個序列包是不是我要的，如果是就放入快取中然後返回一個 ACK，如果不是就丟棄。

TCP 頭裡面還有埠號，而我們的Tomcat正在監聽這個埠號。於是，目標機器自然知道是Tomcat想要這個包，於是將包發給Tomcat

忽略上方網關和路由的過程，整個請求流程如下圖所示

上方我們說的比較適應HTTP1.0/HTTP1.1，而HTTP2.0則與它們有一些區別：

採用二進位格式而非文本格式
消息頭壓縮
支援服務端推送
使用多路傳輸：HTTP1.0時一個連接一次只提交一個請求。HTTP1.1試過用流水線來解決這個問題, 但是效果並不理想(數據量較大或者速度較慢的響應, 會阻礙排在他後面的請求). 此外, 由於網路媒介和伺服器不能很好的支援流水線, 導致部署起來困難重重。而多路傳輸能夠同時處理多個消息的請求和響應; 甚至可以在傳輸過程中將一個消息跟另外一個摻雜在一起。所以客戶端只需要一個連接就能載入一個頁面