HTTP網(wǎng)絡(luò)協(xié)議

結(jié)論:
HTTP/1.x 有連接無(wú)法復(fù)用、隊(duì)頭阻塞、協(xié)議開(kāi)銷(xiāo)大和安全因素等多個(gè)缺陷;
HTTP/2 通過(guò)多路復(fù)用、二進(jìn)制流、Header 壓縮等等技術(shù),極大地提高了性能,但是還是存在著問(wèn)題的;
QUIC 基于 UDP 實(shí)現(xiàn),是 HTTP/3 中的底層支撐協(xié)議,該協(xié)議基于 UDP,又取了 TCP 中的精華,實(shí)現(xiàn)了即快又可靠的協(xié)議。

一、HTTP1的缺點(diǎn):
1、連接無(wú)法復(fù)用:每次連接都需要三次握手,在高延遲的場(chǎng)景下影響比較大; 慢啟動(dòng)對(duì)大量的小文件影響比較大(未到達(dá)最大窗口請(qǐng)求就被終止)
2、HOLB隊(duì)頭阻塞:同一連接只能同時(shí)處理一個(gè)請(qǐng)求,后續(xù)請(qǐng)求必須等上一個(gè)請(qǐng)求完成才可以繼續(xù)。帶寬無(wú)法充分利用。
3、協(xié)議開(kāi)銷(xiāo)大:header每次傳輸,浪費(fèi)流量
4、安全因素:明文傳輸

二、HTTP2的優(yōu)點(diǎn):
基于SPDY協(xié)議,專(zhuān)注性能,目標(biāo):用戶(hù)和網(wǎng)站之間只用一個(gè)鏈接。
1、二進(jìn)制傳輸更高效,未不是像以前一樣文本傳輸。
2、多路復(fù)用:
2.1、同域名下所有通信都在單個(gè)連接上完成;
2.2、單個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流;
2.3、數(shù)據(jù)流以消息的形式發(fā)送,而消息又由一個(gè)或多個(gè)幀組成,多個(gè)幀之間可以亂序發(fā)送,因?yàn)楦鶕?jù)幀首部的流標(biāo)識(shí)可以重新組裝。這一特性,使性能有了極大提升:
2.4、同個(gè)域名只需要占用一個(gè) TCP 連接,使用一個(gè)連接并行發(fā)送多個(gè)請(qǐng)求和響應(yīng),消除了因多個(gè) TCP 連接而帶來(lái)的延時(shí)和內(nèi)存消耗;
2.5、并行交錯(cuò)地發(fā)送多個(gè)請(qǐng)求,請(qǐng)求之間互不影響;
并行交錯(cuò)地發(fā)送多個(gè)響應(yīng),響應(yīng)之間互不干擾;
在HTTP/2中,每個(gè)請(qǐng)求都可以帶一個(gè)31bit的優(yōu)先值,0表示最高優(yōu)先級(jí), 數(shù)值越大優(yōu)先級(jí)越低。有了這個(gè)優(yōu)先值,客戶(hù)端和服務(wù)器就可以在處理不同的流時(shí)采取不同的策略,以最優(yōu)的方式發(fā)送流、消息和幀。

3、header壓縮
3.1、使用“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵-值對(duì),對(duì)于相同的數(shù)據(jù),不再通過(guò)每次請(qǐng)求和響應(yīng)發(fā)送;
3.2、首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在,由客戶(hù)端和服務(wù)器共同漸進(jìn)地更新;

4、Server Push
服務(wù)端能通過(guò)push的方式將客戶(hù)端需要的內(nèi)容預(yù)先推送過(guò)去。

三、HTTP2的缺點(diǎn):
HTTP/2 使用了多路復(fù)用,一般來(lái)說(shuō)同一域名下只需要使用一個(gè) TCP 連接。但當(dāng)這個(gè)連接中出現(xiàn)了丟包的情況,那就會(huì)導(dǎo)致 HTTP/2 的表現(xiàn)情況反倒不如 HTTP/1 了。
因?yàn)樵诔霈F(xiàn)丟包的情況下,整個(gè) TCP 都要開(kāi)始等待重傳,也就導(dǎo)致了后面的所有數(shù)據(jù)都被阻塞了。但是對(duì)于 HTTP/1.1 來(lái)說(shuō),可以開(kāi)啟多個(gè) TCP 連接,出現(xiàn)這種情況反到只會(huì)影響其中一個(gè)連接,剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。

四、HTTP3的優(yōu)點(diǎn):

1、0-RTT
通過(guò)使用類(lèi)似 TCP 快速打開(kāi)的技術(shù),緩存當(dāng)前會(huì)話(huà)的上下文,在下次恢復(fù)會(huì)話(huà)的時(shí)候,只需要將之前的緩存?zhèn)鬟f給服務(wù)端驗(yàn)證通過(guò)就可以進(jìn)行傳輸了。0RTT 建連可以說(shuō)是 QUIC 相比 HTTP2 最大的性能優(yōu)勢(shì)。

2、多路復(fù)用
雖然 HTTP/2 支持了多路復(fù)用,但是 TCP 協(xié)議終究是沒(méi)有這個(gè)功能的。QUIC 原生就實(shí)現(xiàn)了這個(gè)功能,并且傳輸?shù)膯蝹€(gè)數(shù)據(jù)流可以保證有序交付且不會(huì)影響其他的數(shù)據(jù)流,這樣的技術(shù)就解決了之前 TCP 存在的問(wèn)題。
同HTTP2.0一樣,同一條 QUIC連接上可以創(chuàng)建多個(gè)stream,來(lái)發(fā)送多個(gè)HTTP請(qǐng)求,但是,QUIC是基于UDP的,一個(gè)連接上的多個(gè)stream之間沒(méi)有依賴(lài)。比如下圖中stream2丟了一個(gè)UDP包,不會(huì)影響后面跟著 Stream3 和 Stream4,不存在 TCP 隊(duì)頭阻塞。雖然stream2的那個(gè)包需要重新傳,但是stream3、stream4的包無(wú)需等待,就可以發(fā)給用戶(hù)。


image.png

另外QUIC 在移動(dòng)端的表現(xiàn)也會(huì)比 TCP 好。因?yàn)?TCP 是基于 IP 和端口去識(shí)別連接的,這種方式在多變的移動(dòng)端網(wǎng)絡(luò)環(huán)境下是很脆弱的。但是 QUIC 是通過(guò) ID 的方式去識(shí)別一個(gè)連接,不管你網(wǎng)絡(luò)環(huán)境如何變化,只要 ID 不變,就能迅速重連上。

3、加密認(rèn)證報(bào)文
TCP 協(xié)議頭部沒(méi)有經(jīng)過(guò)任何加密和認(rèn)證,所以在傳輸過(guò)程中很容易被中間網(wǎng)絡(luò)設(shè)備篡改,注入和竊聽(tīng)。比如修改序列號(hào)、滑動(dòng)窗口。這些行為有可能是出于性能優(yōu)化,也有可能是主動(dòng)攻擊。
但是 QUIC 的 packet 可以說(shuō)是武裝到了牙齒。除了個(gè)別報(bào)文比如 PUBLIC_RESET 和 CHLO,所有報(bào)文頭部都是經(jīng)過(guò)認(rèn)證的,報(bào)文 Body 都是經(jīng)過(guò)加密的。
這樣只要對(duì) QUIC 報(bào)文任何修改,接收端都能夠及時(shí)發(fā)現(xiàn),有效地降低了安全風(fēng)險(xiǎn)。

4、向前糾錯(cuò)機(jī)制
QUIC協(xié)議有一個(gè)非常獨(dú)特的特性,稱(chēng)為向前糾錯(cuò) (Forward Error Correction,F(xiàn)EC),每個(gè)數(shù)據(jù)包除了它本身的內(nèi)容之外,還包括了部分其他數(shù)據(jù)包的數(shù)據(jù),因此少量的丟包可以通過(guò)其他包的冗余數(shù)據(jù)直接組裝而無(wú)需重傳。向前糾錯(cuò)犧牲了每個(gè)數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限,但是減少了因?yàn)閬G包導(dǎo)致的數(shù)據(jù)重傳,因?yàn)閿?shù)據(jù)重傳將會(huì)消耗更多的時(shí)間(包括確認(rèn)數(shù)據(jù)包丟失、請(qǐng)求重傳、等待新數(shù)據(jù)包等步驟的時(shí)間消耗)。

五、解釋

慢啟動(dòng)和擁塞窗口:

由于兩臺(tái)主機(jī)間的網(wǎng)絡(luò)可能很復(fù)雜,通過(guò)廣域網(wǎng)時(shí),中間的路由器轉(zhuǎn)發(fā)能力可能是瓶頸。也就是說(shuō),如果一方簡(jiǎn)單的按照另一方主機(jī)三次握手時(shí)通告的滑動(dòng)窗口大小來(lái)發(fā)送數(shù)據(jù)的話(huà),可能會(huì)使得網(wǎng)絡(luò)上的轉(zhuǎn)發(fā)路由器性能雪上加霜,最終丟失更多的分組。這時(shí),各個(gè)操作系統(tǒng)內(nèi)核都會(huì)對(duì)TCP的發(fā)送階段加入慢啟動(dòng)和擁塞避免算法。慢啟動(dòng)算法說(shuō)白了,就是對(duì)方通告的窗口大小只表示對(duì)方接收TCP分組的能力,不表示中間網(wǎng)絡(luò)能夠處理分組的能力。所以,發(fā)送方請(qǐng)悠著點(diǎn)發(fā),確保網(wǎng)絡(luò)非常通暢了后,再按照對(duì)方通告窗口來(lái)敞開(kāi)了發(fā)。
擁塞窗口(cwnd)用來(lái)幫助慢啟動(dòng)的實(shí)現(xiàn),連接剛建立時(shí),擁塞窗口的大小遠(yuǎn)小于發(fā)送窗口,它實(shí)際上是一個(gè)MSS。每收到一個(gè)ACK,擁塞窗口擴(kuò)大一個(gè)MSS大小,當(dāng)然,擁塞窗口最大只能到對(duì)方通告的接收窗口大小。當(dāng)然,為了避免指數(shù)式增長(zhǎng),擁塞窗口大小的增長(zhǎng)會(huì)更慢一些,是線性的平滑的增長(zhǎng)過(guò)程。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容