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