为什么TCP不会被取代

“吐槽”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

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

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章