“吐槽”TCP的理由幾乎都是這幾句話：

• TCP 的擁塞控制算法會在丟包時主動降低吞吐量;
• TCP 的三次握手增加了數據傳輸的延遲和額外開銷;
• TCP 的累計應答機制導致了數據段的傳輸;

最后歸結為——在弱網絡環境下，TCP效率會大幅度下降，所以Google的QUIC才是解放生產力的工具——畢竟人家已經HTTP 3了。

[[312955]]

什么是弱網絡

弱網絡一般是指Wireless Network，LTE(4G)、Wifi都屬于這種類型的網絡。網絡是往移動性、無界的方向演進的，受限于接入技術的發展，無線接入面臨著覆蓋范圍、更高帶寬的雙重考驗。可以把這種情況理解為“不穩定的物理鏈路”，它不像以太網有線接入——通或者不通，而是會出現“帶寬”小到無法傳輸一個包頭(通常說的“信號差”)或者直接“物理斷開”。這并不是由于網絡傳輸過程中擁塞、QoS或者服務器端來不及處理引起的，而是由于Wireless Network接入技術本身的技術瓶頸。

賭未來

技術只會往好的方向發展，Wireless Network目前的技術“終點”是5G。是的，不要以為5G僅僅會代替手機接入，Wifi信號強度的問題也只能通過“蜂窩技術”解決，而目前最先進的蜂窩技術就是5G。簡單來說，5G會帶來：

• 通過更高頻段、更好的調制解調、更牛逼的天線提供更好的無線接入物理鏈路;
• 通過就邊緣節點降低延時;
• 通過NFV、云網融合提供更加有效、靈活的組網方式;

如果賭未來，那么未來可能并不存在“弱網絡”。所以當看到具有“先見之明的IETF”通過了QUIC成為HTTP3草案的時候我是一臉懵逼的。HTTP2還沒有普及，大佬們已經忙著制定HTTP3——而且以他們的學識應該能看到5G肯定會比HTTP2更早成熟，怎么就這么迫不及待的制定HTTP3了呢?后來我想明白了——沒有規定說“KPI項目”只能我朝使用，允許咱們“KPI開源”就得允許人家“KPI規范”。Google一直想在網絡上有所作為，所以必須“有所作為”。

解決當下

回答一個問題：作為應用程序，“你”需要一個什么樣的協議?

• 如果你不希望發生丟包那么一定需要確認(ACK)機制;
• 如果你希望數據有序，那么你一定需要分配一塊“緩沖”，在某個時間段內重組數據包;

按照這個思路想下去，結果一定是——滑動窗口、擁塞算法、ACK機制，所以當你需要一個可靠協議的時候結論一定是TCP協議，當你試圖創造一個“新”可靠協議的時候幾乎就是在重新發明TCP。最終大家的爭論焦點就只能是——ACK的時機、如何設置滑動窗口大小、如何優化RTO之類的問題。

至于三次握手，其實根本不是問題重點。從設計上講是需要“會話”的概念的，況且建立會話的握手過程并不會帶來非常明顯的網絡開銷。

現在說的“弱網絡”真正要解決的問題是，如果網絡幾乎無法通訊，應用程序要及時知道并且做出反饋動作(停止網絡請求、提示網絡無法連接)

以微信為例，在弱網絡中，TCP的RTO(重傳超時)是動態計算出來的，如果出現網絡問題應用并不能很快感知。社交類應用是對“反饋”非常敏感的應用，所以需要做“弱網絡優化”。解決這個問題最徹底的辦法是修改協議棧，然而——一個應用程序就別瞎琢磨內核的事情了。所以用了一套“工程化”的方式解決這個問題，比如Fast Recovery、HARQ、連接池、合并連接等無所不用其極的方法。

如果一個協議要取代TCP那么一定是在重新實現TCP

未來的網絡是具有更好接入體驗、更大帶寬、更低延時、更靈活組網方式、更高效通訊的網絡，所以如果一個技術要解決的問題域是一個很“猥(狹)瑣(隘)”的領域，那么它真的不應該成為“趨勢”乃至標準。一個具備生命力的技術應該提供機制而不是策略。解決“當下問題”是一種策略，為了混口飯吃逼出來的一些辦法而已。