http 不同版本之間的概念

V1.0 —— 一個(gè)請(qǐng)求建立一個(gè)連接，結(jié)束則關(guān)閉

瀏覽器與服務(wù)器只保持短暫的連接，每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接， 服務(wù)器完成請(qǐng)求處理后立即斷開TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過去的請(qǐng)求。

缺點(diǎn)：每個(gè)請(qǐng)求都要連接、斷開的操作， 性能上缺陷

解決方案：如果需要建立長(zhǎng)連接，需要設(shè)置一個(gè)非標(biāo)準(zhǔn)的Connection字段 Connection：keep-alive .

V1.1 一個(gè)連接用于多個(gè)請(qǐng)求, 基于http pipelining技術(shù)

默認(rèn)支持長(zhǎng)連接(Connection: keep-alive)，即在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。

參考http1.1中的http pilining 參考：
https://www.zhihu.com/question/444343281/answer/2161660020

增加了更多的請(qǐng)求頭和響應(yīng)頭來完善功能

1）引入了更多的緩存控制策略，eg:If-Unmodified-Since , If-Match , If-None-Match等緩存頭來控制緩存策略

2）引入Range，允許值請(qǐng)求資源某個(gè)部分

3）引入host，實(shí)現(xiàn)了在一臺(tái)Web服務(wù)器上可以在同一個(gè)地址和端口號(hào)上使用不提供的主機(jī)名來創(chuàng)建多個(gè)虛擬Web站點(diǎn)并且還添加了其他的請(qǐng)求方法： put、delete、options...

1)長(zhǎng)連接：引入了持久連接，即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用

2)管道化： 在同一個(gè)TCP連接里面， 客戶端可以頭痛是發(fā)送多個(gè)請(qǐng)求，雖然允許復(fù)用TCP連接，但是統(tǒng)一個(gè)TCP連接里面，所有的數(shù)據(jù)通信時(shí)按次序進(jìn)行的，服務(wù)器只有處理完一個(gè)請(qǐng)求，才會(huì)接著處理下一個(gè)請(qǐng)求。 如果前面的處理特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。

3)新增請(qǐng)求方法， 請(qǐng)求頭、 響應(yīng)頭、狀態(tài)碼

4)緩存處理：新增字段cache-control；當(dāng)瀏覽器請(qǐng)求資源時(shí)，先看是否有緩存的資源，如果有緩存，直接取，不會(huì)再發(fā)請(qǐng)求，如果沒有緩存，則發(fā)送請(qǐng)求
通過設(shè)置字段cache-control來控制

5)斷點(diǎn)傳輸/節(jié)約寬帶：在上傳/下載資源時(shí)，如果資源過大，將其分割為多個(gè)部分，分別上傳/下載，如果遇到網(wǎng)絡(luò)故障，可以從已經(jīng)上傳/下載好的地方繼續(xù)請(qǐng)求，不用從頭開始，提高效率；在 Header 里兩個(gè)參數(shù)實(shí)現(xiàn)的，客戶端發(fā)請(qǐng)求時(shí)對(duì)應(yīng)的是 Range 服務(wù)器端響應(yīng)時(shí)對(duì)應(yīng)的是 Content-Range

6. Host 請(qǐng)求頭：早期 HTTP/1.0 中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的 IP 地址并提供單一的服務(wù)，請(qǐng)求消息中的 URL 并沒有傳遞主機(jī)名。而隨著虛擬主機(jī)的出現(xiàn)，一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)，并且它們共享同一個(gè) IP 地址。為了支持虛擬主機(jī)，HTTP/1.1 中添加了 host 請(qǐng)求頭，請(qǐng)求消息和響應(yīng)消息中應(yīng)聲明這個(gè)字段，若請(qǐng)求消息中缺少該字段時(shí)服務(wù)端會(huì)響應(yīng)一個(gè) 404 錯(cuò)誤狀態(tài)碼。
   

V2.0 性能上的提升

1. 多路復(fù)用
2. 二進(jìn)制分幀
3. 首部壓縮
4. 服務(wù)器推送

1) 多路復(fù)用

復(fù)用了TCP連接， 在一個(gè)連接里， 客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)， 而且不用按照順序一一對(duì)應(yīng)， 這樣避免了“對(duì)頭堵塞”。

因?yàn)榱?ID 的存在， 通過同一個(gè) HTTP 請(qǐng)求可以實(shí)現(xiàn)多個(gè) HTTP 請(qǐng)求傳輸，客戶端和服務(wù)器可以通過流 ID 來標(biāo)識(shí)究竟是哪個(gè)流從而定位到是哪個(gè) HTTP 請(qǐng)求。

2）二進(jìn)制分幀

1> 最小單位： 幀

2> 二進(jìn)制傳輸格式， 而非1.1的文本格式，解析起來更高效；將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼

3> 同域名下所有通信都在單個(gè)連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。

4> 每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。 多個(gè)幀之間可以亂序發(fā)送，根據(jù)幀首部的流表示可以重新組裝， 這也是多路復(fù)用同時(shí)發(fā)送數(shù)據(jù)的實(shí)現(xiàn)條件。

3）首部壓縮

在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲(chǔ)之前發(fā)送的鍵值對(duì)， 對(duì)于相同的數(shù)據(jù)，不再通過每次請(qǐng)求和響應(yīng)發(fā)送。

首部表 在v2.0的連續(xù)存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新。

請(qǐng)求1發(fā)送了所有的頭部字段， 請(qǐng)求2只需要發(fā)送差異數(shù)據(jù)，減少了冗余數(shù)據(jù)，降低開銷

4）服務(wù)器推送

允許服務(wù)器推送資源給客戶端

即為：服務(wù)器會(huì)順便把一些客戶端需要的資源一起推送到客戶端，如在響應(yīng)一個(gè)頁面請(qǐng)求中，就可以隨同頁面的其他資源， 免得客戶端再次創(chuàng)建連接發(fā)送請(qǐng)求到服務(wù)器端獲取。 —— 非常適合加載靜態(tài)資源。

v3.0 —— QUIC協(xié)議

QUIC （quick UDP internet connections）一種基于UDP的低延遲傳輸協(xié)議。

主要目的：解決采用傳輸層TCP協(xié)議存在的問題，同時(shí)滿足傳輸層和應(yīng)用層對(duì)多連接、低延遲等的需求。 融合了TCP、TLS、HTTP/2等協(xié)議的特性，并基于UDP傳輸。

主要的提升：

1）低延遲連接：當(dāng)客戶端第一次連接服務(wù)器時(shí)，QUIC 只需要 1 RTT（Round-Trid Time）延遲就可以建立安全可靠的連接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷。之后，客戶端可以在本地緩存加密的認(rèn)證信息，當(dāng)再次與服務(wù)器建立連接時(shí)可以實(shí)現(xiàn) 0 RTT 的連接建立延遲。

2）復(fù)用了HTTP/2協(xié)議的多路復(fù)用功能：由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的隊(duì)頭阻塞問題。

3）基于用戶域運(yùn)行：基于 UDP 協(xié)議的 QUIC 運(yùn)行在用戶域而不是系統(tǒng)內(nèi)核，這使得 QUIC 協(xié)議可以快速的更新和部署，從而很好地解決了 TPC 協(xié)議部署及更新的困難。

3）報(bào)文經(jīng)過加密和認(rèn)證：除了少量的報(bào)文，其它所有的 QUIC 報(bào)文頭部都經(jīng)過了認(rèn)證，報(bào)文主體經(jīng)過了加密。只要有攻擊者篡改 QUIC 報(bào)文，接收端都能及時(shí)發(fā)現(xiàn)。

4）具有向前糾錯(cuò)機(jī)制：每個(gè)數(shù)據(jù)包攜帶了除了本身內(nèi)容外的部分其他數(shù)據(jù)包的內(nèi)容，使得在出現(xiàn)少量丟包的情況下，盡量地減少其它包的重傳次數(shù)，其通過犧牲單個(gè)包所攜帶的有效數(shù)據(jù)大小換來更少的重傳次數(shù)，這在丟包數(shù)量較小的場(chǎng)景下能夠帶來一定程度的性能提升。

需要自定義的內(nèi)容

總結(jié)：

V0.9

僅僅支持Get， 近能夠訪問HTMl格式資源

V1.0:

瀏覽器與服務(wù)器只保持短暫的連接， 瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接

V1.1

1)默認(rèn)長(zhǎng)連接

2)管道化, 同時(shí)可以多個(gè)請(qǐng)求

4)緩存處理：cache-control

5)斷點(diǎn)傳輸：資源一部分一部分上傳

V2.0

1. 采用二進(jìn)制格式而非文本格式
2. 完全多路復(fù)用，而非有序并阻塞的、只需一個(gè)連接即可實(shí)現(xiàn)并行
3. 使用報(bào)頭壓縮，降低開銷
4. 服務(wù)器推送

主要解決問題：

HTTP2.0解決了HTTP1.1隊(duì)首阻塞問題，同時(shí)不需要通過HTTP1.x的pipeline機(jī)制用多條TCP連接實(shí)現(xiàn)并行請(qǐng)求與響應(yīng)；減少了TCP連接數(shù)對(duì)服務(wù)器性能的影響，同時(shí)將頁面的多個(gè)數(shù)據(jù)通過已給數(shù)據(jù)連接進(jìn)行傳輸，加快頁面的傳輸速度。

還存在的問題:

1. http2.0 是基于TCP協(xié)議的，TCP協(xié)議在處理包時(shí)是有嚴(yán)格順序的。TCP對(duì)頭阻塞壹基金 TCP協(xié)議存在的額固有問題(慢啟動(dòng)、擁塞串口尺寸的設(shè)置等)
   
   => 雖然http沒有了對(duì)頭阻塞的問題，但是TCP還是有的。所以對(duì)頭阻塞問題沒有完全解決，倘若TCP丟包率過大，則HTTP/2的表現(xiàn)還不如HTTP/1.1。 —— TCP換成UDP

v3.0 —— QUIC協(xié)議

主要解決TCP中的對(duì)頭阻塞的問題。。

1> 自定義連接機(jī)制

2> 自定義重傳機(jī)制

3> 無阻塞的多路復(fù)用

4> 自定義流量控制

本文由mdnice多平臺(tái)發(fā)布