前天晚上在家，设置熟悉的ss梯子时，发现无法使用T.T.登录控制台查看，发现国内IP被封了。问身边的朋友，也是一样的现象，听说是因为网络安全周？！看来只能希望一周后恢复了....昨天在闲逛，看到一个开源项目：udp2raw-tunnel。他的实现是将IP报文伪装成TCP报文，目的是通过网络UDP防火墙。嗯？！这是TCP-In-TCP吗？这东西不是不能用吗？很久以前有人说过：WhyTCPOverTCPIsABadIdea为了更清楚地描述问题，我画下隧道应用的网络：图中的主机A和主机D通过隧道进行EndtoEnd通信，设备B对原始消息进行加密和封装，设备C进行解封装和解密。当然B和C不一定是独立的设备，它们可以集成在主机A和主机D中。TCP-In-TCP的问题是：当一个隧道报文在网络中丢失时，B上的TCP连接显然会重传报文，但是要知道A上也有一个TCP连接，所以如果A超时了，它也会重传，但是从整个网络的角度来看，这个重传是没有必要的。但是A不会理会，因为是TCP。TCP的设计原则是底层协议和介质是不可靠的，需要我自己来保证。所以TCP-In-TCP这样的双重保险是完全没有必要的。不仅没有必要，还可能因为网络中重传的包太多而造成拥塞。不过也有研究说TCP-In-TCP在一定条件下可以提高网络的有效吞吐率：这里的论文UnderstandingTCPoverTCP:EffectsofTCPTunnelingonEnd-to-EndThroughputandLatency仍然是类似拓扑：论文将Propagationdelay（传播延迟）考虑在内，得出的结论是当Ta和Tb比较大的时候，使用TCP-In-TCP隧道的有效吞吐量比不使用的要高.为什么？原因也很容易解释：当Ta和Tb比较大时，很明显TCP连接在A视角下的RTT会比B视角下的RTT大很多，所以如果隧道数据包在网络中丢失，B重传隧道数据包，但是A不会重传原来的数据包，因为超时时间还没有到。而如果不使用隧道，那么重传的任务还是A的。显然，B重传消息的传播时延要大于A重传的。看似合理，但是当网络条件真的很差，达到A的超时后，还是会回到之前最差的情况。。。所以我还是觉得TCP-In-TCP不是一个好主意。。所以，what关于本文开头提到的开源项目？仔细阅读了它的介绍后，我下载了它的代码。哦，原来真的只是伪装成TCP报文而已。实际上，隧道报文的外层TCP封装就是用户态自己填充的TCP头，然后通过rawsocket发送；而在接收端，也是使用rawsocket（关于这个，详见inetsocket和packetsocket），所以消息会提前发送到raw_local_deliver，不会被TCP接收到，所以不会有复杂的东西，比如TCP状态机。
