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

百聯達發表於2019-07-12

一: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是一個無狀態的協議。

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

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

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

二:HTTP傳送報文

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

1.請求行

URL就是,版本是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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章