HTTP 3-0 徹底放棄 TCP，TCP 到底做錯了什麼？

作者 l Hollis

來源 l Hollis（ID：hollischuang）

從 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 的時代也會到來的，讓我們拭目以待吧。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/MMR5uzbFDN501dbIKCyGMg