(4)HTTP/1.1、HTTP/2、HTTP/3 演變

一、HTTP/1.1 相比 1.0 性能改進

1)TCP 長連接改善 HTTP/1.0 短連接性能開銷

2)支持 管道(pipeline)網(wǎng)絡傳輸,請求發(fā)出,不必等其回來發(fā)第二個,減少響應時間

HTTP/1.1 性能瓶頸:

1)頭部未壓縮,信息越多延遲越大。只能壓部分Body,首部冗長,發(fā)送相同首部浪費

2)隊頭阻塞:按請求順序響應,如服務器響應慢

3)沒請求優(yōu)先級控制:只能從客戶端開始,服務器被動

二、1.1 的性能瓶頸,HTTP/2 做了什么優(yōu)化?

1. 頭部壓縮

同時發(fā)出多個請求,頭一樣或相似,協(xié)議消除重復

? ??就是HPACK?算法:維護頭信息表,生成一個索引號,不發(fā)送同樣字段,只發(fā)送索引號提高速度

2. 二進制格式

1.1 純文本形式的文,2?二進制格式:頭信息幀和數(shù)據(jù)幀,統(tǒng)稱為幀(frame)

報文區(qū)別:直接解析二進制報文,無需明文報文轉(zhuǎn)成二進制,增加傳輸效率

3. 數(shù)據(jù)流

數(shù)據(jù)流(Stream):請求/回應所有數(shù)據(jù)包,獨一無二的編號,客戶端發(fā)出奇數(shù), 服務器偶數(shù),可指定優(yōu)先級

不按順序發(fā)送的,同連接連續(xù)數(shù)據(jù)包,可能屬于不同回應。標記數(shù)據(jù)包屬于哪個回應

4. 多路復用

一個連接中可并發(fā)多個請求或回應,不用按照順序一一對應。移除串行請求,解決隊頭阻塞

例:TCP 連接里,服務器收客戶端 A 和 B 請求,A 耗時,回應 A 請求已處理部分,接著回應 B再回應 A 剩下部分。

5. 服務器推送

改善“請求 - 應答”,服務也可主動發(fā)

例:瀏覽器剛請求 HTML提前把可能用JS、CSS 文件等靜態(tài)資源主動發(fā)給客戶端減少延時,就是推送

三、2 有哪些缺陷?HTTP/3 做哪些優(yōu)化

2 主要問題:

? ??1)多個 HTTP 請求復用一個 TCP,TCP 不知道多少個HTTP?

? ??2)丟包觸發(fā) TCP 重傳,所有HTTP 請求都等待。1.1 pipeline阻塞,2 丟包阻塞

3 改變

1)把 HTTP 下層TCP 協(xié)議改成UDP(不管順序,不管丟包)

????UDP 不可靠,基于 UDP 的QUIC 協(xié)議(丟包時,阻塞這個流,其他流不受影響)?可實現(xiàn)類似 TCP 可靠性傳輸。

2)頭部壓縮算法升級成QPack

HTTPS 建立連接,6 次交互,先建三次握手,然后TLS/1.3?的三次握手。QUIC 合并成了 3 次

ps:TCP HTTPS(TLS/1.3) 和 QUIC HTTPS

QUIC:在UDP之上TCP + TLS + HTTP/2 多路復用協(xié)議。

新協(xié)議,很多網(wǎng)絡設備,不知道,只當UDP,出現(xiàn)新問題

HTTP/3 普及慢,不知道UDP 是否能逆襲 TCP

https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容