到底要不要走TCP隧道，要不要TCP over TCP？

还是这篇文章：
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

有100个理由说TCP在某种场景下不好，就有100个理由说TCP在同样的场景了好的不得了，这就好像面对中医或者传统武术一样， 古老陈旧的东西总是被拿来被吹捧或者被打压。 TCP是个30年前陈旧的协议，在计算机网络的编年史中，TCP是一个古代的协议。

• TCP在长距离传输时窗口打开太慢；
• TCP对丢包无法预测；
• TCP对RTT测不准；
• TCP对网络拥塞事件反应迟钝；
• …

这是一个保守的协议。

数据要传输到另一个地方，中间要经过一个隧道，如何构建这个隧道是一个技术问题。

考虑TCP over TCP会怎样？

TCP作为一个按序接收的有状态可靠的端到端传输协议，是因为它对下层的链路做了一个假设：

• 下层是不可靠的！！

TCP的很多特性都源自于这个 不可靠假设 。所以TCP屏蔽掉这个假设之后， TCP是可靠的！

TCP over TCP？TCP同时作为链路协议和负载协议？是的！

那么 在TCP over TCP中，不可靠假设就失效了！ ，因为 TCP是可靠的！

只要内层TCP的RTO超时时间小于外层TCP的RTO超时时间，悲剧就发生了，指数退避会让连接崩溃。

但是，这很少发生，在支持FACK/SACK/RACK的 现代TCP 中，RTO很少被触发，依靠各种xACK探测到需要重传的场景，那便尽是TCP over TCP的优势了。

为了演示TCP是如何不适合长距离传输的，先看一个标准的丢包恢复：

为什么会丢包？

下层的链路不可靠呗，那么如果在丢包的位置替换一条链路，使得它成为可靠的链路，会不会更好呢？我们把这条链路换成一条TCP隧道，看看会发生什么：

TCP有助于弥补链路不可靠，虽然以TCP来保证可靠也不是很完美，但至少这是一个POC：

• 通过软件协议来弥补底层链路的不可靠性！

其实，代理也可以达到类似的效果，只要缩短TCP端到端的距离即可：

这侧面证明了TCP确实是一个长距离不友好的勒瑟协议。

在不可靠的链路上构建一个可靠的软件协议来保证可靠性，确实是一个不错的想法。TCP协议构建隧道确实也是一个办法，但我们必须要用TCP构建隧道吗？

NoNoNoNoNo！

可以用Quic？

NoNoNoNoNo！这些都太重了，都是是烦人的东西。

只需要构建隧道的协议有丢包重传机制即可，TCP附加的按序接收，连接状态机维护都是不必要的，甚至只需要并非100%的丢包探测重传即可即可，即不需要保证一个丢失的数据包被100%重传，只要能 减少 端到端的丢包重传开销，那这条隧道就是成功的。

所以说，隧道不一定非要用TCP构建，只要 能重传丢包 即可咯。隧道还是有好处的。

于是，构建一个 像TCP但又不是TCP的传输协议 就是必要的，当然，这纯粹是trick，为了玩而已，任凭哪个公司都不敢怎么玩。

• 发送端的Netfilter挂HOOK，收到TCP write下来的数据时，直接ACK！
• 接收端的Netfilter挂HOOK，收到数据后直接copy to user，不再处理OFO！
• …

这个module实现起来非常简单吧，只要借用TCP的一个壳即可，大家都待见TCP，那就按照你说的来呗…对了，还有Quic，依着你就是了。

都是钱，又TM是鸡屎！

---

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