當前互聯網幾乎所有的 HTTP 通信都由 TCP/IP 來承載，但 TCP 為了可靠性而犧牲性能被很多人所詬病。再到 QUIC 及 HTTP over QUIC 的發(fā)布，經過改進的 UDP 仿佛正在為未來替代 TCP 做準備。雖然 HTTP/3 還沒有大面積普及，但越來越多的公司及個人也在不斷嘗試在傳輸層提升網絡連接的效率。這篇文章主要討論 TCP 及其問題和 QUIC 協議相關的內容。
傳輸層 TCP 協議為 HTTP 提供了一條可靠的比特傳輸管道。當 HTTP 傳輸一條報文時，會以流的形式將報文數據的內容通過一條打開的 TCP 連接按序輸送。TCP 收到數據流后，會將數據流砍成數據塊（段），并將其封裝在 IP 分組中，數據格式如下圖：
傳輸協議在設計時需要對各種條件和場景進行策略的權衡取舍，TCP 為了可靠性設計了一系列的規(guī)則比如三次握手，四次揮手等等。下面我們來展開討論下 TCP 連接細節(jié)以及性能問題。
為了防止 TCP 連接一開始向對方發(fā)送大量數據而導致網絡擁塞崩潰，TCP 連接一般會隨著時間進行自我調諧，起初限制連接的最大速度，如果數據傳輸成功，則會提高傳輸速度，這種自我調諧被稱為 TCP 慢啟動，用于防止因特網的突然過載和擁塞。
TCP 連接控制速度大小則通過擁塞控制窗口，在建立之初雙方會協商傳輸的數據大小，然后發(fā)送方的擁塞控制窗口大小會跟隨接收方的響應而變化，如果發(fā)送成功則線性增長，如果丟包則減半。
建立 TCP 連接時，需要通信雙方首先要對 Socket，序列號以及窗口大小信息達成共識，Socket 是由互聯網地址標識符和端口組成，窗口大小用來做流控制，序列號則是用來追蹤通信發(fā)起方發(fā)送的數據包序號，接收方可以通過序號來向發(fā)送方確認某個數據包的成功接收。
歷史連接判斷
我們知道一個客戶端是可以重復的與同一臺服務器建立連接進行通信的，RFC 793 中就指出三次握手的首要原因就是阻止歷史重復連接導致的混亂問題。
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
假如 TCP 連接為兩次握手，那服務器方將只能選擇接受或拒絕發(fā)送方多次的請求，它并不清楚哪一個是過期的連接。
為解決這個問題，TCP 選擇了三次握手并在連接引入了 RST 這一控制消息，發(fā)送方在收到接收方的 ACK 確認號后，會判斷是否為歷史連接，如果是會發(fā)送 RST 控制消息中止這次連接。如果不是則會繼續(xù)完成握手流程。
序列號控制
由于網絡具有很大的不確定性，可能會導致下面的問題：
所以 TCP 在數據包中加入了 SEQ 字段，有了數據包的序列號則可以:
避免數據丟失造成的循環(huán)
我們再假設另外一個場景，發(fā)送方發(fā)送了一個連接請求分組，對方收到后并發(fā)送確認應答分組，如果這時候認定連接建立，接收方會開始給發(fā)送方傳輸數據分組，但在應答分組丟失的情況下發(fā)送方不知道是否建立好連接，將會忽略任何數據分組直到應答分組收到為止。而接收方在發(fā)出的分組超時后會重復發(fā)送，這也形成了某種意義的死循環(huán)。
三次握手需要雙方一共發(fā)送 3 個 TCP 分組（通常是 40 ~ 60）個字節(jié)，那么三次則是 120 字節(jié)到 180 字節(jié)，但大多數 HTTP 請求都不會攜帶大量的數據，小的 HTTP 事務很可能會在 TCP 建立上花費 50% 或者更多時間，同時也會增加很多字節(jié)的額外開銷。
由于我們無法確保發(fā)送的數據分組一定能被對方收到，所以 TCP 實現了自己的確認機制來確保數據的成功傳輸。
每個 TCP 段都有一個序列號和數據完整性校驗和 (checksum)，接收者收到完好的段時都會向發(fā)送者回送小的確認分組。如果發(fā)送者沒有在指定窗口時間（通常有 100 ~ 200 ms）內收到確認信息時，發(fā)送者就認為分組已被破壞或損毀，并重發(fā)數據。
ACK 的方式很容易保證消息的順序性，但在某些情況下會導致發(fā)送方重傳已經接收的數據：比如發(fā)送方發(fā)送四個數據段，后三個傳輸成功但第一個失敗了，由于 ACK 語義是當前數據段前的全部數據段都已經被接收和處理，所以接收方無法發(fā)送 ACK 消息，發(fā)送方看沒有 ACK，所有數據段對應的計時器就會超時并重新傳輸數據。在丟包嚴重的網絡下，這種重傳機制會造成大量的帶寬浪費。
如圖所示，TCP 連接的拆除需要經過 four-way handshake，客戶端或服務器均可主動發(fā)起揮手動作。
為什么建立連接是三次握手而斷開時是四次呢？
建立連接時，服務器開始處于 LISTEN 狀態(tài)，收到 SYN 報文后可以把 ACK 和 SYN 放在一個報文回送給客戶端。 但關閉連接時，服務器收到對方的 FIN 報文時，僅僅表示對方不再發(fā)數據了但還能接收數據，自己未必全部數據都已經發(fā)送給對方，所以此時可以即刻關閉，也可以發(fā)送一些數據后再發(fā)送 FIN 報文給對方關閉連接，所以一般 ACK 和 FIN 會分開發(fā)送。
當 TCP 端點關閉 TCP 連接時，會在內存中維護一個小的控制塊，用來記錄最近所關閉連接的 IP 地址和端口號。這類信息只會維持一小段時間，通常是所估計的最大分段使用期的兩倍 2MSL, 以確保這段時間內不會創(chuàng)建相同地址和端口號的新連接。另外 TIME_WAIT 的存在也是為了保證 TCP 雙工可靠的終止，雖然四次揮手發(fā)送和協調完畢，但我們必須假設網絡是不可靠的，無法保證最后發(fā)送的 ACK 報文一定會被對方收到，因此對方處于 LAST_ACK 狀態(tài)下的 socket 可能會因為超時沒收到 ACK 報文而重發(fā) FIN 報文，所以這個 TIME_WAIT 可以用來重發(fā)可能丟失的 ACK 報文。
TIME_WAIT 時間是動態(tài)可配的，所以需要我們自己設定策略來選擇 MSL 時間。
HTTP/2 基于 Google 推行的 SPDY，專注于性能，最大的目標是用戶和網站間只需要單個連接。所以增加了二進制分幀，多路復用等強大的功能。同時 HTTP/2 協議也是最大限度的兼容 HTTP/1.x 的，request 模型，scheme 并沒有發(fā)生變化，不識別 HTTP/2 的代理服務器也可以將請求降級為 HTTP/1.x.
HTTP/2 并沒有改變 HTTP/1.x 的語義，只是在應用層使用二進制分幀的方式傳輸。因此引入了新的通信單位：幀，消息，流。HTTP/2 是一個徹底的二進制協議，頭信息和數據包都是二進制的，統稱為“幀“。
幀的類型包括了 DATA 幀 (用來承載請求或相應的內容，包括 Pad Length, Data, Padding 等字段)，HEADERS 幀 (用來承載 start line + header 的 HTTP Header 幀), PRIORITY 幀 (stream 流發(fā)送方指定了建議優(yōu)先級)，PING 幀(用作心跳檢測及計算 RTT 往返時間), GOAWAY 幀 (用于啟動連接關閉或發(fā)出嚴重錯誤信號) 等等。
分幀使得服務器單位時間接收到的請求數變多，可以提高并發(fā)數，也為多路復用提供了底層支持。
多路復用就是在一個 TCP 連接中可以存在多個 stream 流。
多個 stream 同時存在時是無序的，所以需要 streamID 來標識，stream ID 使用無符號的 31 位整數標識，客戶端發(fā)起的流必須使用奇數編號，服務器發(fā)起的則必須使用偶數編號，流標識符零 (0x0) 用于發(fā)送控制消息，并不能建立新的 stream .
數據流在發(fā)送中的任意時刻，客戶端和服務器都可以發(fā)送信號 (RST_STREAM 幀) 來取消這個數據流。
多路復用有效的解決多個鏈接時慢啟動，重復 TCP 握手耗時的問題使得 TCP 效率更高。
HTTP/2 使用 HPACK 來開啟頭部壓縮，另外客戶端和服務器同時維護一張頭信息表，所有字段會存入該表，生成索引號，同樣字段再發(fā)送時只發(fā)送索引號即可。HTTP/1.1 平均響應頭有 500 個字節(jié)左右，而 HTTP/2 平均只有 20 多個字節(jié)，只有以前的 4% 左右。
HTTP/2 還增加了服務端推送可以讓服務端主動把資源文件推送給客戶端。
但 HTTP/2 依舊存在一些問題比如:
TCP 連接依舊需要三次握手，消耗 1.5 個 RTT，再加上 TLS 握手，時間耗費將會更長。
RTT（Round-Trip Time）:往返時延。表示從發(fā)送端發(fā)送數據開始，到發(fā)送端收到來自接收端的確認（接收端收到數據后便立即發(fā)送確認），總共經歷的時延。
HTTP/2 在丟包時，整個 TCP 都要等待重傳，會阻塞該 TCP 連接中的所有請求。
多路復用沒有限制同時請求數，可能會導致許多請求的短暫爆發(fā)，導致 QPS 暴增。
網絡帶寬和服務器資源有限，多個并行的流會導致資源被稀釋，然后出現超時情況。
QUIC（Quick UDP Internet Connections）協議基于 UDP 協議，它比較出色的解決了隊頭阻塞的問題，HTTP/3 也名 HTTP over QUIC，集成了 QUIC，TLS1.3 等等。
主要特點為:
一個應用程序的不同連接能支持配置不同的擁塞控制，應用程序不需要停機和升級就能實現擁塞控制的變更，可以針對不同業(yè)務，網絡和不同的 RTT 來使用不同的擁塞控制算法
每個 Packet Number 都嚴格遞增且唯一，而 TCP 重傳存在二義性，重新發(fā)送時數據包中標識符都不變。
QUIC 中的 ACK 包含了與 TCP 中等價的信息，但 QUIC 不允許 ACK 確認過的 Packet 被丟棄。這樣不僅可以簡化發(fā)送端與接收端的實現難度，還可以減少發(fā)送端的內存壓力。
FEC 中，QUIC 數據幀的數據混合原始數據和冗余數據，來確保無論到達接收端的 n 次傳輸內容是什么，接收端都能夠恢復所有 n 個原始數據包。
QUIC 可以同時提供 256 個 ACK Block，在重排序時相對于 TCP 更有彈性，在丟包率比較高的網絡下可以提升網絡的恢復速度，減少重傳量。
同時在計算 RTT 時會把接收到包到發(fā)送 ACK 的這段時間（ACK Delay）計算進去。
QUIC 的流量控制類似 HTTP/2，在 Connection 和 Stream 級別提供了兩種流量控制。
由于 QUIC 基于 UDP，所以只需花費 0~1 個 RTT 就可以建立連接。
QUIC 是為多路復用設計的，攜帶個別流的數據包丟失時，通常只會影響該流，QUIC 連接上的多個 stream 之間并沒有依賴，也不會有底層協議限制。
這也很大程度上緩解了隊頭阻塞的影響。
TCP 通過 ip, 端口號來確定連接, 而 QUIC 則通過 ConnectionID (64 bit) 來區(qū)別不同連接。主要 Connection ID 不變連接就不需要重新建立。
QUIC 對于弱網環(huán)境的優(yōu)化是明顯的，但是也由于各種原因面臨著一些問題：
對于基于 TCP 的 HTTP(S) 傳輸，NAT 設備可以根據 TCP 報文頭的 SYN/FIN 狀態(tài)來了解通信開始結束狀態(tài)，對應記憶 NAT 映射的開始和結束，但是 UDP 中不存在 SYN/FIN 狀態(tài)位，如果 NAT 設備的記憶短于用戶會話時間則用戶會話會被中斷。
在一些網絡環(huán)境下(比如校園網)，UDP 協議會被路由器等中間網絡設備禁止（包括我國的運營商= =）, 這時客戶端會直接降級, 選擇備選通道。
QUIC 客戶端存在網絡制式切換，就算是同一個移動機房，可能第一次業(yè)務請求會落到 A 服務器，后續(xù)再連接則落到 B 服務器，重復走握手流程。
更多 QUIC 的內容可以參照 chromium/quic 官方文檔
聯系客服
