從HTTP/1.0開始,一直到HTTP/2,不管應用層協議如何改進,TCP一直以來都是HTTP協議的基礎,主要是因為他能提供可靠連接。
但是,從HTTP 3.0開始,這個情況就有所變化了。
因為,在最新推出的HTTP 3.0中,已經徹底棄用TCP協議了。
TCP隊頭阻塞
我們知道,TCP傳輸過程中會把數據拆分為一個個按照順序排列的數據包,這些數據包通過網絡傳輸到了接收端,接收端再按照順序將這些數據包組合成原始數據,這樣就完成了數據傳輸。
但是如果其中的某一個數據包沒有按照順序到達,接收端會一直保持連接等待數據包返回,這時候就會阻塞后續請求。這就發生了TCP隊頭阻塞。
HTTP/1.1的管道化持久連接也是使得同一個TCP鏈接可以被多個HTTP使用,但是HTTP/1.1中規定一個域名可以有6個TCP連接。而HTTP/2中,同一個域名只是用一個TCP連接。
所以,在HTTP/2中,TCP隊頭阻塞造成的影響會更大,因為HTTP/2的多路復用技術使得多個請求其實是基于同一個TCP連接的,那如果某一個請求造成了TCP隊頭阻塞,那么多個請求都會受到影響。
TCP握手時長
我們都知道TCP的可靠連接是基于三次握手與四次揮手實現的。但是問題是三次握手是需要消耗時間的。
TCP三次握手的過程客戶端和服務器之間需要交互三次,那么也就是說需要額外消耗1.5 RTT。
> RTT:網絡延遲(Round Trip Time)。他是指一個請求從客戶端瀏覽器發送一個請求數據包到服務器,再從服務器得到響應數據包的這段時間。RTT 是反映網絡性能的一個重要指標。
在客戶端和服務端距離比較遠的情況下,如果一個RTT達到300-400ms,那么我握手過程就會顯得很”慢”了。
升級TCP
基于上面我們提到的兩個問題,有人提出來說:既然TCP存在這些問題,并且我們也知道這些問題的存在,甚至解決方案也不難想到,為什么不能對協議本身做一次升級,解決這些問題呢?
其實,這就涉及到一個”協議僵化“的問題。
這樣講,我們在互聯網上瀏覽數據的時候,數據的傳輸過程其實是極其復雜的。
我們知道的,想要在家里使用網絡有幾個前提,首先我們要通過運行商開通網絡,并且需要使用路由器,而路由器就是網絡傳輸過程中的一個中間設備。
中間設備是指插入在數據終端和信號轉換設備之間,完成調制前或解調后某些附加功能的輔助設備。例如集線器、交換機和無線接入點、路由器、安全解調器、通信服務器等都是中間設備。
在我們看不到的地方,這種中間設備還有很多很多,一個網絡需要經過無數個中間設備的轉發才能到達終端用戶。
如果TCP協議需要升級,那么意味著需要這些中間設備都能支持新的特性,我們知道路由器我們可以重新換一個,但是其他的那些中間設備呢?尤其是那些比較大型的設備呢?更換起來的成本是巨大的。
而且,除了中間設備之外,操作系統也是一個重要的因素,因為TCP協議需要通過操作系統內核來實現,而操作系統的更新也是非常滯后的。
所以,這種問題就被稱之為”中間設備僵化”,也是導致”協議僵化”的重要原因。這也是限制著TCP協議更新的一個重要原因。
所以,近些年來,由IETF標準化的許多TCP新特性都因缺乏廣泛支持而沒有得到廣泛的部署或使用!
QUIC
所以,擺在HTTP/3.0面前的就只有一條路,那就是放棄TCP。
于是,HTTP/3.0在基于UDP+迪菲赫爾曼算法(Diffie–Hellman)之上實現了QUIC協議(Quick UDP Internet Connections)。
QUIC協議有以下特點:
基于UDP的傳輸層協議:它使用UDP端口號來識別指定機器上的特定服務器。
可靠性:雖然UDP是不可靠傳輸協議,但是QUIC在UDP的基礎上做了些改造,使得他提供了和TCP類似的可靠性。它提供了數據包重傳、擁塞控制、調整傳輸節奏以及其他一些TCP中存在的特性。
實現了無序、并發字節流:QUIC的單個數據流可以保證有序交付,但多個數據流之間可能亂序,這意味著單個數據流的傳輸是按序的,但是多個數據流中接收方收到的順序可能與發送方的發送順序不同!
快速握手:QUIC提供0-RTT和1-RTT的連接建立
使用TLS 1.3傳輸層安全協議:與更早的TLS版本相比,TLS 1.3有著很多優點,但使用它的最主要原因是其握手所花費的往返次數更低,從而能降低協議的延遲。
阻礙
以上,我們介紹了很多QUIC的相比較于TCP的優點,可以說這種協議相比較于TCP確實要優秀一些。
因為他是基于UDP的,并沒有改變UDP協議本身,只是做了一些增強,雖然可以避開中間設備僵化的問題,但是,在推廣上面也不是完全沒有問題的。
首先,很多企業、運營商和組織對53端口(DNS)以外的UDP流量會進行攔截或者限流,因為這些流量近來常被濫用于攻擊。
特別是一些現有的UDP協議和實現易受放大攻擊(amplification attack)威脅,攻擊者可以控制無辜的主機向受害者投放發送大量的流量。
所以,基于UDP的QUIC協議的傳輸可能會受到屏蔽。
另外,因為UDP一直以來定位都是不可靠連接,所以有很多中間設備對于他的支持和優化程度并不高,所以,出現丟包的可能性還是有的。。。
但是不管怎么樣,HTTP/3.0的時代一定會到來的,QUIC協議全面代替TCP的時代也會到來的,讓我們拭目以待吧。
審核編輯:劉清
-
TCP
+關注
關注
8文章
1353瀏覽量
79068 -
UDP
+關注
關注
0文章
325瀏覽量
33934 -
RTT
+關注
關注
0文章
65瀏覽量
17122 -
Quic
+關注
關注
0文章
25瀏覽量
7298 -
HTTP協議
+關注
關注
0文章
61瀏覽量
9721
原文標題:HTTP 3.0徹底放棄TCP,TCP到底做錯了什么?
文章出處:【微信號:良許Linux,微信公眾號:良許Linux】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論