TCP无可取代

导读	在弱网络环境下，TCP效率会大幅度下降，所以Google的QUIC才是解放生产力的工具——毕竟人家已经HTTP 3了。

吐槽”TCP的理由几乎都是这几句话：

TCP 的拥塞控制算法会在丢包时主动降低吞吐量;

TCP 的三次握手增加了数据传输的延迟和额外开销;

TCP 的累计应答机制导致了数据段的传输;

最后归结为——在弱网络环境下，TCP效率会大幅度下降，所以Google的QUIC才是解放生产力的工具——毕竟人家已经HTTP 3了。

什么是弱网络

弱网络一般是指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

未来的网络是具有更好接入体验、更大带宽、更低延时、更灵活组网方式、更高效通讯的网络，所以如果一个技术要解决的问题域是一个很“猥(狭)琐(隘)”的领域，那么它真的不应该成为“趋势”乃至标准。一个具备生命力的技术应该提供机制而不是策略。解决“当下问题”是一种策略，为了混口饭吃逼出来的一些办法而已。

本文来自《Linux就该这么学》官方资讯站。