網絡協議-HTTP 協議

HTTP 協議

HTTP 協議是TCP/IP 網絡協議中的應用層協議。

URL - 統一資源定位符

DNS 的做用 將域名 轉爲 IP 地址

在發送HTTP 協議以前要創建TCP 鏈接，HTTP 是創建在TCP 鏈接之上的

HTTP 1.1 版本默認開啓Keep-alive，創建一次TCP 鏈接，能夠重複使用

 

HTTP 請求的構建

創建TCP 鏈接後須要構建HTTP 報文，其報文大概分爲三個部分

• 第一部分：請求行

• 第二部分：首部

• 第三部分：正文實體

 

  

第一部分：請求行

方法有幾種類型：

• Get，獲取資源，一般是一個網頁，也多是一個JSON 字符串。

• Post，主動告訴服務器一些信息，這些信息放到實體中，正文的格式一般是JSON。

• Put，向指定的資源位置上傳新內容， 但HTTP 的服務器一般不容許上傳文件，因此在實際應用中，Post一般用來建立一個資源，Put 用來修改一個資源。

• Delete，用來刪除資源的。

 

第二部分：首部字段

首部是key value，經過冒號分隔。一般保存重要字段。

例如，Accept-Charest，表示客戶端能夠接受的字符集。

例如，Content-Type 指出正文的格式，若是咱們進行Post的請求，若是正文是JSON，，那麼這個值就是JSON。

緩存的使用，緩存網頁中靜態的部分，例如圖片等。這樣能夠在更新數據時沒必要每次都刷新整個頁面。

這個架構圖以下所示：

 

  

HTTP頭裏的 Cache-control 是用來控制緩存的。客戶端發送的請求中有max-age 指令時，要判斷資源的緩存時間是否比指定的時間小，若是大於指定時間客戶端就要從新下載了。

If-Modified-Since 也是關於緩存的。若是服務器的資源更新了，客戶端就應該下載最新的資源。

 

HTTP 的報文構建好以後，瀏覽器如何把它交給下一層，傳輸層。本質上也是用Socket，只不過這些在瀏覽器中作好了。

 

HTTP 請求的發送

一、TCP 層會將 源地址和目標地址 信息放到IP 頭裏，並把它和報文一塊兒交給IP 層傳輸。

二、IP 層要查看目標IP地址和源IP地址在不在同一個網段

• 若是在發送ARP 協議獲取，目標IP地址的MAC 地址，讓後將源MAC 地址和目標MAC 地址放到MAC頭中，發送便可。

• 若是不在同一網段，仍是要發送ARP 協議獲取網關的MAC 地址，將網關的MAC 和 源MAC 地址放到MAC 頭中，發送出去。

三、網關收到包後查看目標IP地址，根據路由協議找下一個路由器，獲取下一個路由器的MAC，而後將包發給它。

四、路由器這樣一跳一跳的最終到達目標局域網。最後一跳的路由器發現目標IP 就在本身的某一個出口的局域網上。因而在這個局域網上發送ARP 協議，獲取目標IP 的MAC 地址，將包發走。

五、目標機器發現MAC 地址符合，將這個包接收，查看IP地址也符合，再查看TCP 的頭中的序列號，若是這個包是本身未接收的，就放入接收緩存中，而後回覆ACK。

六、TCP 頭裏還有端口號，指明是哪一個應用須要接收的包，這個應用就是HTTP 服務器。服務器查看HTTP 層的消息，是get就返回一個網頁，是Post 就建立一個新資源。

 

HTTP 返回的構建

下面這張圖是HTTP1.1 版本的返回報文。

 

 

返回報文也是分爲三個部分：狀態行、首部、實體。

一、狀態行中有，HTTP 版本；狀態碼就是202，404這些。短語會說一下出錯緣由。

二、首部仍是 key value。這裏面，Retry-After表示客戶端在多長時間再嘗試一下。Content-Type表示，返回的是HTML 仍是JSON。

三、構造好HTTP 報文後，仍是有socket發送出，先交給TCP層，TCP層會將HTTP報文分爲一個個小段（由於這是一個網頁，一個包發不了），而後是IP層，把剛纔的過程反向走一遍。

 

HTTP 2.0

HTTP 1.1 的弊端：

• 在應用層以純文本的形式通訊。

• 每次通訊都要帶完整的HTTP頭。

• 不考慮pipeline 模式的話，每次的過程都是一去一回。實時性、併發性存在問題。

HTTP 2.0 解決了 HTTP1.1 的不足：

• 對HTTP 的頭進行壓縮，在客戶端和服務端創建key value 表，對相同的頭只傳輸表的索引。

• 將一個TCP 的鏈接分爲多個流，每一個流有本身的ID，和雙向通道，有優先級。

• 將傳輸消息分爲更小的消息和幀，並對它們採用二進制傳輸。讓這些消息和幀在多個流中同時傳輸。這些幀發送時不按順序，在接收端從新組裝。

  Header 幀用於傳輸Header 內容，並開啓一個新的流；Data 幀用於傳輸正文實體，多個data 幀屬於同一個流。

 

假設咱們的頁面要發送三個獨立的請求，一個獲取css，一個獲取js，一個獲取圖片jpg。若是使用HTTP1.1 就是串行。但若是是HTTP2.0，就能夠在一個鏈接裏並行。以下圖所示：

 

  

HTTP2.0 將三個請求變成三個流，將數據分幀，亂序發送到一個TCP 鏈接中。

 

HTTP 2.0 解決了HTTP1.1 隊首阻塞問題。HTTP1.1 要想作到多通道並行，須要經過pipeline 機制創建多條TCP 鏈接來實現。

 

QUIC 協議

HTTP2.0 也是基於TCP 協議實現的，TCP 協議是有順序的。雖然HTTP2.0 是多個stream 傳輸，每一個流之間的數據並沒有關聯，流與流之間不須要順序。

這就像一條大河中航行多個船隊，每一個船隊能夠有本身的順序，可是在入港口的時候卻要求和本船隊不相干的船隻排好順序再進港同樣。

因而Google 將TCP 切換到UDP，構建了一個QUIC 協議。

 

機制一：自定義鏈接機制

TCP 重連機制太麻煩，還要三次握手啥的。要求的條件也高，既要有IP，還要有端口，差一點就斷開重連。由於它保證可靠嘛。在移動互聯網狀況下，手機的信號或WIFI 不穩定時，都會致使重連。

基於UDP後，能夠在QUIC 本身的邏輯裏維護鏈接機制，再也不以IP/Port 做爲標識，而是以一個64 位的隨機數做爲ID 標識，並且UDP 是無鏈接的，當 IP或Port 變化時，只要ID 不變，就不須要從新鏈接。

 

機制二：自定義重傳機制

TCP 有序號和應答機制來保證不丟包，一個序號的包發出去沒在必定的時間獲得應答就會重發。UDP 並無這個機制，QUIC 本身構建了一個機制保證不丟包。

QUIC 也有序列號，是遞增的。它也有ACK ，也有重傳算法。QUIC 定義了一個offset 概念。QUIC 是面向鏈接的，是一個數據流，發送的數據在這個流裏有個偏移量 offset，能夠經過offset 查看數據發送到哪了，這樣只要這個offset 的包沒有來，就要重發。

機制三：無阻塞的多路複用

同HTTP2.0 同樣，同一條QUIC 鏈接上能夠建立多個 stream，來發送多個HTTP 請求。但QUIC 是基於UDP，一個鏈接上的多個stream之間沒有依賴。

 

機制四：自定義流量控制

TCP 的流量控制是經過滑動窗口協議實現。QUIC 也是經過window_update 控制流量的。可是QUIC 的窗口是適應多路複用機制的。不但在一個鏈接上有控制窗口，並且在每一個stream 上也有控制窗口。

QUIC 的ACK 是基於 offset 的，每一個offset 的包來了，並進入緩存，就能夠應答，應答後就不會重發，中間的空擋會等待到來或者重發便可，而窗口的起始位置爲當前收到的最大offset，從這個 offset 到當前的stream 所能容納的最大緩存，就是真正的窗口大小。這個方法更準確。

小結

• HTTP 協議三個部分，狀態行、首部、實體，狀態行中的get、post、put、delete方法。首部中幾個重要字段。

• HTTP2.0 經過HTTP 頭壓縮，多個stream、分幀、二級制編碼，多路複用提高性能。

• QUIC 協議基於UDP 協議，本身實現四個機制，不須要重連，保證不掉包，控制流量，多路複用。