导读 | 在弱网络环境下,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、连接池、合并连接等无所不用其极的方法。
未来的网络是具有更好接入体验、更大带宽、更低延时、更灵活组网方式、更高效通讯的网络,所以如果一个技术要解决的问题域是一个很“猥(狭)琐(隘)”的领域,那么它真的不应该成为“趋势”乃至标准。一个具备生命力的技术应该提供机制而不是策略。解决“当下问题”是一种策略,为了混口饭吃逼出来的一些办法而已。
原文来自:
本文地址://gulass.cn/tcp-be-replaced.html编辑:xiangping wu,审核员:清蒸github
Linux大全:
Linux系统大全: