計(jì)算機(jī)網(wǎng)絡(luò)之十二：HTTP協(xié)議

一：HTTP簡(jiǎn)介

HTTP是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫。

它的發(fā)展是萬維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和Internet工作小組

IETF（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。

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

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，

以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。

HTTP是一個(gè)應(yīng)用層協(xié)議，由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型。HTTP是一個(gè)無狀態(tài)的協(xié)議。

http://cimc-express.com/ 是哥URL，叫統(tǒng)一資源定位符。 HTTP稱為協(xié)議，cimc-express.com是一個(gè)域名，表示互聯(lián)網(wǎng)上

的一個(gè)位置。瀏覽器會(huì)將cimc-express.com解析為IP地址，HTTP 是基于TCP協(xié)議的，要先建立TCP連接。

目前使用的HTTP協(xié)議大部分是1.1. 在1.1協(xié)議里面，默認(rèn)開啟了Keep-Alive，這樣建立的TCP連接，可以在多次請(qǐng)求中復(fù)用。

二：HTTP發(fā)送報(bào)文

HTTP報(bào)文大概分為三大部分。第一部分是請(qǐng)求行，第二部分是請(qǐng)求的首部，第三部分是請(qǐng)求的正文實(shí)體。

1.請(qǐng)求行

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

GET： 去服務(wù)器端獲取資源，對(duì)于訪問網(wǎng)頁(yè)來講，獲取的是一個(gè)頁(yè)面；對(duì)于一個(gè)基于HTTP協(xié)議的API，返回的可能是一個(gè)

JSON字符串

POST： 向服務(wù)器端提交資源

PUT： 向服務(wù)器端提交資源，POST往往是用來創(chuàng)建一個(gè)資源，PUT往往是用來修改一個(gè)資源

DELETE： 刪除資源

2.首部

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

格式，Cache-Control是用來控制緩存的。

3.正文實(shí)體

三：HTTP數(shù)據(jù)發(fā)送

1.HTTP協(xié)議是基于TCP協(xié)議的，它使用面向連接的方式發(fā)送請(qǐng)求，通過stream二進(jìn)制流的方式傳給對(duì)方。到了TCP層，會(huì)把

二進(jìn)制流變成一個(gè)報(bào)文段發(fā)送給服務(wù)器。

2.在發(fā)送每個(gè)報(bào)文段的時(shí)候，都需要對(duì)方有一個(gè)回應(yīng)ACK，來保證報(bào)文可靠到達(dá)了對(duì)方。如果沒有回應(yīng)，那么TCP這一層會(huì)

進(jìn)行重新傳輸，直到可以到達(dá)。同一個(gè)包 有可能被傳了多次，但是HTTP這一層不知道這一點(diǎn)。

3.TCP層發(fā)送每一個(gè)報(bào)文的時(shí)候，都需要加上自己的地址（源地址）和它想要去的地址（目標(biāo)地址），將這兩個(gè)信息放到IP頭

里面，交給IP層進(jìn)行傳輸。

4.IP層需要查看目標(biāo)地址和自己是否在同一個(gè)局域網(wǎng)。如果是，就發(fā)送ARP協(xié)議來請(qǐng)求這個(gè)目標(biāo)地址對(duì)應(yīng)的MAC地址，然后將

源MAC地址和目標(biāo)MAC地址放入MAC頭， 發(fā)送出去即可；如果否，就需要發(fā)送到網(wǎng)關(guān)，還需要發(fā)送ARP協(xié)議，來獲取網(wǎng)關(guān)的

MAC地址，然后將源MAC地址和網(wǎng)關(guān)MAC放入MAC頭，發(fā)送出去。

5.網(wǎng)關(guān)收到包發(fā)現(xiàn)MAC符合，取出目標(biāo)IP地址，根據(jù)路由協(xié)議找到下一跳的路由器，獲取下一條路由器的MAC地址，將包發(fā)

給嚇一跳路由。

6.目標(biāo)的機(jī)器發(fā)現(xiàn)MAC地址符合，就將包收起來；發(fā)現(xiàn)IP地址符合，根據(jù)IP頭重協(xié)議項(xiàng)，知道自己上一層是TCP協(xié)議，于是解

析TCP的頭，里面有序列號(hào)，需要看看這個(gè)序列 號(hào)是不是我要的，如果是就放入緩存中然后返回一個(gè)ACK，如果不是就丟棄

7.TCP頭里面還有端口號(hào)，HTTP的服務(wù)器正在監(jiān)聽這個(gè)端口號(hào)。于是，目標(biāo)機(jī)器自然知道是HTTP服務(wù)器這個(gè)進(jìn)程想要這個(gè)包，

于是將包發(fā)給HTTP服務(wù)器。HTTP服務(wù)器的進(jìn)程 看到，原來這個(gè)請(qǐng)求是要訪問一個(gè)網(wǎng)頁(yè)，于是就把這個(gè)網(wǎng)頁(yè)發(fā)送給客戶端。

四：HTTP返回報(bào)文

1.狀態(tài)碼

200：交易成功，400：錯(cuò)誤請(qǐng)求  404：沒有發(fā)現(xiàn)文件、查詢或URl  500：內(nèi)部服務(wù)器錯(cuò)誤 502：網(wǎng)關(guān)錯(cuò)誤

2.返回首部key:value.  Retry-After表示客戶端應(yīng)該在多長(zhǎng)時(shí)間以后再次嘗試一下，Content-Type表示返回的是HTML，還是

JSON。

3.構(gòu)造好了返回的HTTP報(bào)文，接下來就是把這個(gè)報(bào)文發(fā)送出去。是交給Socket去發(fā)送，還是交給TCP層，讓TCP層將返回的

HTML，也分成一個(gè)個(gè)小的段，并且保證每個(gè)段都可靠 到達(dá)。

五：HTTP2.0

1.HTTP1.1在應(yīng)用層以純文本的形式進(jìn)行通信，每次通信都要帶完整的HTTP的頭，而且不考慮pipeline模式的話，每次的過程

總是一去一回。這樣在實(shí)時(shí)性和并發(fā)性上都存在問題。

2.HTTP2.0會(huì)對(duì)HTTP頭進(jìn)行一定的壓縮，將原來每次都要攜帶的大量key:value在兩端建立一個(gè)索引表，對(duì)相同的頭只發(fā)送

索引表中的索引。

3.HTTP2.0協(xié)議將一個(gè)TCP的連接中，切分成多個(gè)流，每個(gè)流都有自己的ID，而且流可以是客戶端發(fā)往服務(wù)端，也可以是服務(wù)

端發(fā)往客戶端，它其實(shí)只是一個(gè)虛擬的通道，流是有 優(yōu)先級(jí)的

4.HTTP2.0還將所有的傳輸信息分割為更小的消息和幀，并對(duì)它們采用二級(jí)制格式編碼。常見的幀有Header幀，用于傳輸

Header內(nèi)容，并且會(huì)開啟一個(gè)新的流。再就是Data幀，用來 傳輸正文實(shí)體，多個(gè)Data屬于同一個(gè)流。

5.通過這兩種機(jī)制，HTTP2.0的客戶端可以將多個(gè)請(qǐng)求分到不同的流中，然后將請(qǐng)求內(nèi)容拆成幀，進(jìn)行二進(jìn)制傳輸。這些幀可

以打散亂序發(fā)送，然后根據(jù)每個(gè)幀首部的流標(biāo)識(shí)符重新組裝 ，并且可以根據(jù)優(yōu)先級(jí)，決定優(yōu)先處理哪個(gè)流的數(shù)據(jù)。

舉例： 一個(gè)頁(yè)面要發(fā)送三個(gè)獨(dú)立的請(qǐng)求，一個(gè)獲取css,一個(gè)獲取js,一個(gè)獲取圖片jpg. 如果使用HTTP 1.1 就是串行的；但是如果

使用HTTP 2.0,就可以在一個(gè)連接里，客戶端和服務(wù)端都可以 同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一對(duì)一對(duì)應(yīng)。

HTTP2.0成功解決了HTTP1.1的隊(duì)首阻塞問題，同時(shí)，也不需要通過HTTP 1.X的pipeline機(jī)制用多條TCP連接來實(shí)現(xiàn)并行請(qǐng)求

與響應(yīng)；減少了TCP連接數(shù)對(duì)服務(wù)器性能的影響，同時(shí)將頁(yè)面的 多個(gè)數(shù)據(jù)css,js,jpg等通過一個(gè)數(shù)據(jù)連接進(jìn)行傳輸，能夠加快頁(yè)

面組件的傳輸速度。

六：QUIC

HTTP 2.0雖然大大增加了并發(fā)性，但還是有問題的。因?yàn)镠TTP 2.0也是基于TCP協(xié)議的，TCP協(xié)議在處理包時(shí)是有嚴(yán)格順序的

。Google的QUIC協(xié)議基于UDP實(shí)現(xiàn)，包含自定義連接機(jī)制，

自定義重傳機(jī)制，無阻塞多路復(fù)用和自定義流量控制。