計算機網路之十二：HTTP協議

一：HTTP簡介

HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。

它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組

IETF（Internet Engineering Task Force）合作的結果，（他們）最終釋出了一系列的RFC，RFC 1945定義了HTTP/1.0版本。

其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。

HTTP協議（HyperText Transfer Protocol，超文字傳輸協議）是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議。

它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，

以及哪部分內容首先顯示(如文字先於圖形)等。

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型。HTTP是一個無狀態的協議。

http://cimc-express.com/ 是哥URL，叫統一資源定位符。 HTTP稱為協議，cimc-express.com是一個域名，表示網際網路上

的一個位置。瀏覽器會將cimc-express.com解析為IP地址，HTTP 是基於TCP協議的，要先建立TCP連線。

目前使用的HTTP協議大部分是1.1. 在1.1協議裡面，預設開啟了Keep-Alive，這樣建立的TCP連線，可以在多次請求中複用。

二：HTTP傳送報文

HTTP報文大概分為三大部分。第一部分是請求行，第二部分是請求的首部，第三部分是請求的正文實體。

1.請求行

URL就是http://cimc-express.com，版本是HTTP1.1，HTTP中的方法型別有：

GET： 去伺服器端獲取資源，對於訪問網頁來講，獲取的是一個頁面；對於一個基於HTTP協議的API，返回的可能是一個

JSON字串

POST： 向伺服器端提交資源

PUT： 向伺服器端提交資源，POST往往是用來建立一個資源，PUT往往是用來修改一個資源

DELETE： 刪除資源

2.首部

首部是key:value形式，儲存一些非常重要的欄位。Accept-Charset表示客戶端可以接受的字符集，Content-Type指正文的

格式，Cache-Control是用來控制快取的。

3.正文實體

三：HTTP資料傳送

1.HTTP協議是基於TCP協議的，它使用面向連線的方式傳送請求，通過stream二進位制流的方式傳給對方。到了TCP層，會把

二進位制流變成一個報文段傳送給伺服器。

2.在傳送每個報文段的時候，都需要對方有一個迴應ACK，來保證報文可靠到達了對方。如果沒有迴應，那麼TCP這一層會

進行重新傳輸，直到可以到達。同一個包 有可能被傳了多次，但是HTTP這一層不知道這一點。

3.TCP層傳送每一個報文的時候，都需要加上自己的地址（源地址）和它想要去的地址（目標地址），將這兩個資訊放到IP頭

裡面，交給IP層進行傳輸。

4.IP層需要檢視目標地址和自己是否在同一個區域網。如果是，就傳送ARP協議來請求這個目標地址對應的MAC地址，然後將

源MAC地址和目標MAC地址放入MAC頭， 傳送出去即可；如果否，就需要傳送到閘道器，還需要傳送ARP協議，來獲取閘道器的

MAC地址，然後將源MAC地址和閘道器MAC放入MAC頭，傳送出去。

5.閘道器收到包發現MAC符合，取出目標IP地址，根據路由協議找到下一跳的路由器，獲取下一條路由器的MAC地址，將包發

給嚇一跳路由。

6.目標的機器發現MAC地址符合，就將包收起來；發現IP地址符合，根據IP頭重協議項，知道自己上一層是TCP協議，於是解

析TCP的頭，裡面有序列號，需要看看這個序列 號是不是我要的，如果是就放入快取中然後返回一個ACK，如果不是就丟棄

7.TCP頭裡面還有埠號，HTTP的伺服器正在監聽這個埠號。於是，目標機器自然知道是HTTP伺服器這個程式想要這個包，

於是將包發給HTTP伺服器。HTTP伺服器的程式 看到，原來這個請求是要訪問一個網頁，於是就把這個網頁傳送給客戶端。

四：HTTP返回報文

1.狀態碼

200：交易成功，400：錯誤請求  404：沒有發現檔案、查詢或URl  500：內部伺服器錯誤 502：閘道器錯誤

2.返回首部key:value.  Retry-After表示客戶端應該在多長時間以後再次嘗試一下，Content-Type表示返回的是HTML，還是

JSON。

3.構造好了返回的HTTP報文，接下來就是把這個報文傳送出去。是交給Socket去傳送，還是交給TCP層，讓TCP層將返回的

HTML，也分成一個個小的段，並且保證每個段都可靠 到達。

五：HTTP2.0

1.HTTP1.1在應用層以純文字的形式進行通訊，每次通訊都要帶完整的HTTP的頭，而且不考慮pipeline模式的話，每次的過程

總是一去一回。這樣在實時性和併發性上都存在問題。

2.HTTP2.0會對HTTP頭進行一定的壓縮，將原來每次都要攜帶的大量key:value在兩端建立一個索引表，對相同的頭只傳送

索引表中的索引。

3.HTTP2.0協議將一個TCP的連線中，切分成多個流，每個流都有自己的ID，而且流可以是客戶端發往服務端，也可以是服務

端發往客戶端，它其實只是一個虛擬的通道，流是有 優先順序的

4.HTTP2.0還將所有的傳輸資訊分割為更小的訊息和幀，並對它們採用二級制格式編碼。常見的幀有Header幀，用於傳輸

Header內容，並且會開啟一個新的流。再就是Data幀，用來 傳輸正文實體，多個Data屬於同一個流。

5.通過這兩種機制，HTTP2.0的客戶端可以將多個請求分到不同的流中，然後將請求內容拆成幀，進行二進位制傳輸。這些幀可

以打散亂序傳送，然後根據每個幀首部的流識別符號重新組裝 ，並且可以根據優先順序，決定優先處理哪個流的資料。

舉例： 一個頁面要傳送三個獨立的請求，一個獲取css,一個獲取js,一個獲取圖片jpg. 如果使用HTTP 1.1 就是序列的；但是如果

使用HTTP 2.0,就可以在一個連線裡，客戶端和服務端都可以 同時傳送多個請求或迴應，而且不用按照順序一對一對應。

HTTP2.0成功解決了HTTP1.1的隊首阻塞問題，同時，也不需要通過HTTP 1.X的pipeline機制用多條TCP連線來實現並行請求

與響應；減少了TCP連線數對伺服器效能的影響，同時將頁面的 多個資料css,js,jpg等通過一個資料連線進行傳輸，能夠加快頁

面元件的傳輸速度。

六：QUIC

HTTP 2.0雖然大大增加了併發性，但還是有問題的。因為HTTP 2.0也是基於TCP協議的，TCP協議在處理包時是有嚴格順序的

。Google的QUIC協議基於UDP實現，包含自定義連線機制，

自定義重傳機制，無阻塞多路複用和自定義流量控制。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28624388/viewspace-2650328/，如需轉載，請註明出處，否則將追究法律責任。