TCP Tunnel

几年以前，我是对TCP in TCP毫无信心的，因为理论上一旦发生重传叠加，这个连接就会崩溃，但在实践中，这几乎不可能发生，我转而成了TCP in TCP的信徒。

TCP隧道形成了长距离传输加速的一个技术基底。来看个究竟：

事事有代价，按照以上玩法，高丢包率路径段的TCP隧道相当于一个大buffer，处理丢包重传需要时间，TCP隧道端点也存在固有buffer用来排队突发数据，这部分时间会叠加在Host的端到端RTT上，因此，代价就是RTT会变长。

分段感知MTU明显提高了带宽利用率。

少即是多，小即是好，多个小控制区执行拥塞控制，好过一个大控制区执行拥塞控制。

于是，整个路径可以拆成下面的样子：

在SDWAN概念被提出之前，TCP隧道其实就是这个意思，只不过SDWAN丰富了隧道的形式，各种隧道技术被提出来构建overlay网络，SR，SRv6是最时髦的，TCP和UDP显得朴素了些。问题是，如果在类似普通Internet非专线线路甚至Lastmile这种边缘延伸线路，运营商认SR，SRv6吗？

运营商不待见QUIC。把戏是，TCP头20字节，比UDP头长很多，UDP头的信息完全可以封装在一个假TCP头中以欺骗运营商以为这是普通TCP连接。说到底还是TCP的把戏。

说回技术，说点儿反对者的担心，总有人担心这么多的隧道处理会增加处理时延，非但不能加速，反而会劣化传输质量。

SDWAN核心是加速！

加速的要点不是优化处理时延，减少不必要的传输！很多人不理解的是，一个数据包发出去后，就要消耗带宽，最终落实的就是消耗时间，然后没完没了的优化如何处理更及时，于是陷入内卷，没完没了的加班。如果能想办法不让这个报文发送不就行了吗？

这是一个很有意思的事情，站在主机看，既然收到了一个数据包，就要用最快的速度将它处理完，但是站在协议的角度看，尽量不让一个不必要发送的数据包发送出去才是要考虑的重点。

举一个例子，一个RTT为50ms的TCP连接，把协议栈处理性能提高100倍都不如少重传一个数据包！提高协议栈处理性能是针对单机的，精确判定丢包精准重传是针对全链路的。

---

浙江温州皮鞋湿，下雨进水不会胖。