我對TCP協議的一點形而上的看法
近期和朋友交流聊到一個話題，即TCP的未來。我的觀點很簡單，即：
- 從純技術的角度，TCP已經不再合時宜，早該被淘汰了；
- 從生態的角度，TCP會持續進化下去，且會越來越龐大臃腫。
我們知道，TCP/IP構成的互聯網本身就是一個巨大的持續進化的生態系統，其中任何一個組件都不能被統一替換，你想讓它變成另外一個樣子，只能等著它進化成那個樣子，而不能把它直接修改成那個樣子，這一點與我們的生物進化論非常一致。
??TCP是一個30年前的協議，在那個時間，TCP/IP僅僅是剛剛開始，基於TCP來進行的數據傳輸首要的需求就是按序性和正確性，而不是性能。此外，當時的帶寬非常昂貴，具體表現在設備昂貴，且耗電，電纜鋪設成本高昂…這意味著技術上很難通過粗獷激進的策略去保證數據的正確按序傳輸，因此問題就轉化為：
如何用最少的字節保證數據的正確按序傳輸？
??好吧，基於單向批量停-等協議的TCP就這樣被設計了出來，請註意，這個時候並沒有什麽所謂的擁塞控制，這就好比新中國剛成立時北京大街上不需要擁塞控制一樣，紅綠燈存在的目的不是擁塞控制，而是沖突域分時復用。
??在這種先汙染後治理的理念下，隨著技術的進步，一旦出現了擁塞(不管是TCP/IP還是城市街道)，其首先想到的措施永遠是錯誤的。因為這個思路的根基就是錯誤的。
??不要覺得北京單雙號限牌，上海限外，然後深圳，廣州跟著學這件事是多麽糟糕，其實這是上述思想下應對擁堵的一個典型措施，即限制而不是疏導。先汙染後治理的思想決定了後續的應對措施必然是阻而不是疏，同樣的事情還發生在安全領域。
??還記得上世紀90年代初的防盜門嗎？現在也還有。一般的家挺都有兩層門，裏面一層朝裏開，是個木門，外面一個大鐵門朝外開用於防盜，非常不方便…在信息安全領域也是一樣。
??回到TCP。作為一個端到端協議，對網絡無感知的TCP必須要進行擁塞控制，否則整個網絡將會在TCP流量的沖擊下崩潰，但是當TCP意識到擁塞問題的時候，協議已經被設計出來了，所以我們從第一版TCP協議可以看到，TCP協議頭裏沒有任何可以用於擁塞控制的字段！於是擁塞控制只能在發送端的狀態機裏做(而不是在協議本身，因為已經晚了！)。
??怎麽做呢？很簡單，增加一個限制，即擁塞窗口cwnd！這和北京單雙號限牌，上海限外沒有任何本質上的區別。cwnd的作用在於，限制數據包發送的數量！北京上海應對交通的措施同樣是限制上路車輛的數量！問題是，擁塞的原因真的是因為數據包太多或者車輛太多嗎？
??完全不是這樣！
??深圳深南大道科技園段從大沖到南山大道這一段算是半快速路，和全快速路不同的是，即便深圳早晚高峰的時候，這段路的中間都顯得非常空，很常見一段時間幾乎沒有任何車輛通過，這場景和北京東三環，上海延安高架內環高架和深圳濱海大道的情形完全不一樣：
深南大道不是的車輛全部都bloat到前面的紅綠燈那裏了，而濱海大道的車輛卻在緩慢pacing前行，我假設兩種情況車輛通過相同長度道路所用的時間一致，請問哪種情況更能加重交通擁堵？
??非常顯然，是深南大道！因為假象會讓更多的人選擇這條道路，然後快速通過無人區後直接堵在紅綠燈處！TCP的擁塞與此類似。因此，造成擁塞的原因並不是你發送的包太多，而是你發送的包太快！這裏值得澄清一下的是，從30年前到現在，數據包通過電纜的速度幾乎沒有改變，但是數據包通過路由器交換機的速度卻時刻發生質的飛躍。在30年前，你可以認為一個數據包的80%的RTT都是排隊延時。
??以上，我們已經知道，如果cwnd過大，就會發生深南大道的情形，造成擁塞，但是一旦TCP發現了擁塞(我們這是在討論本質，所以如何發現擁塞並不重要，管你是基於丟包還是基於延時)，TCP會迅速降低cwnd，其實這是一種錯誤的自省式做法，這等於說你承認了擁塞是你造成的，至少你是幫兇，你是作案人員的一份子。TCP的收斂模型幾乎就是這種罪與罰的輪回。
??其實，TCP的MD機制還有一點自私的味道。迄今為止，最終倡導的類似CUBIC這種基於丟包的算法，但是TCP端到端流量控制的滑動窗口要求TCP必須及時恢復丟包，不然協議將不可用，所以采用保守的策略去恢復丟包幾乎是唯一的選擇。所以從本質上來講，TCP協議就是一個優化版的停等協議。
真正的擁塞控制就應該像城市快速路那樣，在擁塞時排隊緩行而不是造成bufferbloat！
??所以說，正確的做法是基於速率來控制，而不是基於數量來控制。讓我不明白的是，IP骨幹網早就采用了類似令牌桶pacing這種速率控制機制，為什麽端到端的TCP卻絲毫不跟進，依然我行我素地基於cwnd來控制數量。
??不管怎樣吧，2016年9月是一個裏程碑，Google放出了一個叫做BBR的TCP擁塞控制算法，該算法徹底重構了整個TCP擁塞控制的框架，算是一個創舉，雖然它很簡單，但從零到一難道不都是從簡單開始嗎？看到了你會覺得簡單，看不到時思維定勢很難讓你想到，不是跪舔Google，但這就是Google！
??BBR是什麽我不再多說，中文版普及資源幾乎都有我的影子，再說這個就顯得羅嗦。其它文章沒有提到的是，BBR作為擁塞控制的2.0版本(1.0當然是原始Reno，其優化版進化到了CUBIC)，這只是一個開始，我們每個人都期待能看到BBR時代的CUBIC，令人興奮的是，BBR本身的2.0就要來了，熟悉QUIC的可以先睹為快了。我這裏就給出幾個鏈接：
- 關於BBR 2.0的鏈接
https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
https://www.ietf.org/proceedings/99/slides/slides-99-iccrg-iccrg-presentation-2-00.pdf - 關於BBR 2.0之QUIC patch的鏈接
https://chromium.googlesource.com/chromium/src/net/+/0fe3a4ca32029b23947e29f072cc857293a98dd7%5E%21/#F0 - 我自己寫的一個簡易版
https://blog.csdn.net/dog250/article/details/80203520
那麽，回到主題，TCP未來會被QUIC取代嗎？
??按照生態系統的進化，TCP不會被取代，不是沒法取代它，而是取代不起，必須考慮兼容性以及投資！只要有一人還在用TCP，互聯網就要支持，更要命的是，TCP從來都不是自己！
??那麽，QUIC如何？我認為QUIC這種協議將來一定會大行其道。因為它代表了一種新的東西。如果說TCP是一個單向停等協議的話，QUIC就是狀態機同步協議的1.0版本！
??我們想象一個把一系列數據傳輸給對端這件事意味著什麽？這意味著數據在兩端發生了同步！我們把傳輸過程中的每一個狀態作為一個步驟，那麽整個傳輸過程就是一個同步的過程。發送端和接收端要做的就是不斷交換自己本端的狀態，然後查漏補缺，這正是OSPF協議的思想！這可以單向瞎猜的TCP協議猛烈多了吧。
??TCP之所以在單邊擁塞控制領域很難出成績，其硬傷就是TCP協議本身攜帶的信息太少，即便加上後來為了優化協議而添加的timestamt，sack這種，也無法和傳遞大量同步信息的QUIC協議相提並論。這一切發生的現實是，如今的帶寬非常廉價。
在互聯網的世界裏，爹很難死掉，但是孩子必須成長。Together with IPv4 vs. IPv6!讓我們拭目以待！
再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow
我對TCP協議的一點形而上的看法