TCP協議自2000年後有什麼變化？

12-28

協議或實現，重要的有這麼幾個吧？

Google 主導的 TCP Fast Open 優化。原理是首次連接握手時確認雙方都支持 TFO 後，被動方通過 ACK 提供一個 cookie，由主動方保存，二次連接發起方 SYN 中攜帶的 cookie，並且直接攜帶 data，被動放校驗 cookie 後，在 SYN+ACK 中確認，同時可以不等發起方 ACK 直接向發起方發送數據，從而實現二次連接時的 0-RTT 的連接開銷。配合 TLS False Start， HTTPS 已經可以實現 1-RTT 的連接開銷（TLS 1.3 已經實現 0-RTT）.

Google 主導的 Early Retransmit 和 Tail Loss Probe 優化，可以顯著降低 TCP 在公網(尤其是移動網路)服務 HTTP 的延遲。原理是 TCP 嚴重依賴重複的 ACK 來檢測丟包進行重傳，一般是 3 次。不足 3 次需要等待 RTO 超時。HTTP 請求又通常不足 3 個分組。因此有 ER 機制，檢測重複 ACK 不足 3 個，但此時已經沒有待發送的分組，也直接進行重傳。而 TLP 是指最後一個分組無 ACK 使用更短的 PTO 超時，提前發一個 keepalive 觸發重複 ACK，以激活 ER。 ER + TLP 自 13 年後是 Linux 內核標配。

Hybird Slow Start 利用 ACK 的時間間隔和序號增量探測帶寬延遲積，在擁塞形成丟包前主動進入擁塞避免狀態。避免了基於丟包的帶寬探測導致的吞吐量下降。HSS 現在也是Linux 和 Darwin 內核的標配。

Apple 主推的 Multipath TCP 利用移動設備多個鏈路的特徵，避免連接僅走單鏈路重連造成的延時，目前還在 draft 狀態。原理大致是在現有連接的基礎上，支持在不同的鏈路再握手一個連接 (subflow)，除了全局共享 seq 號和滑動窗口外，每個 subflow 也有自己獨立的 seq 號和滑動窗口。此外subflow 也支持接收窗口通告，以支持在兩個路徑上自由調整比例發送。當其中一個連接斷開或者接受窗口為 0 時，可以立即切換到另一個連接上發送或者重發。目前已知支持的是 Darwin 內核，最的大規模應用是 Siri，尚無高級 SDK。Linux 需要獨立編譯一套單獨分發的內核(不是 Patch)

ECN 其他答案有講了。主要思路是路由器主動通知擁塞狀態。

TCP協議的規範來自IETF RFC793， RFC 793 - Transmission Control Protocol
這個協議有4個update，在2000年之後的有：
這個沒什麼人用的防掉包擴展（2001年9月）：RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 (2001). ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that may be used between two ECN-enabled endpoints when the underlying network infrastructure also supports it.
Conventionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion. The receiver of the packet echoes the congestion indication to the sender, which reduces its transmission rate as if it detected a dropped packet.

來自wikipedia

還有這個提醒一樣的東西（2011年）：RFC 6093 - On the implementation of the TCP urgent mechanism

This document analyzes how current TCP implementations process TCP
urgent indications and how the behavior of some widely deployed
middleboxes affects how end systems process urgent indications. This
document updates the relevant specifications such that they
accommodate current practice in processing TCP urgent indications,
raises awareness about the reliability of TCP urgent indications in
the Internet, and recommends against the use of urgent indications
(but provides advice to applications that do).

和這個安全性演算法更新（2012年2月）：RFC 6528 - Defending against Sequence Number Attacks

This document specifies an algorithm for the generation of TCP
Initial Sequence Numbers (ISNs), such that the chances of an off-path
attacker guessing the sequence numbers in use by a target connection
are reduced. This document revises (and formally obsoletes) RFC
1948, and takes the ISN generation algorithm originally proposed in
that document to Standards Track, formally updating RFC 793.

以上應該是全部了。

這個嘛，看看這個roadmap裡面有多少貨就知道了，小心別迷路。

A Roadmap for Transmission Control Protocol (TCP): https://tools.ietf.org/html/rfc7414

TCP最大的變化有好幾個，最大的是MP－TCP，就是支持同一個session啟動多個IP地址或多個埠。

還有一個變化是谷歌推動的HTTP／2要求TCP上一定有TLS保護。

谷歌為此搞一套SPDY來玩，HTTP2基本上就在SPDY上搞起來。

而最厲害的變化，就是谷歌提出用UDP替代TCP成為HTTP的下層協議。這個協議還在制定中，谷歌甚至中協議未完成前，做成事實標準。有興趣的去查一下QUIC。很多瀏覽器和操作系統已經支持了。

個人感覺，TCP退出歷史應該已經被提上日程了。SCTP已經比TCP高了，UDP上再折騰折騰也玩得不錯。谷歌的方向是提出一個新的協議替代TCP。

目前發展基本方向是把傳輸層的部分的功能上移，上層去接管移動性，TCP層與IP層剝離。

DDos....