关于动态TCP header的必要性

[Chion82]

经过初步的测试，发现不同的ISP对TCP header有不同的要求：

• 广东移动：
  • 服务端ack flag必须置为1，否则客户端将一直收不到服务端的packet。
  • seq/ack序列需要一直保持定值，如果一直自增会被QoS随后pipe被掐断；我在 kcptun-raw 中曾尝试过模拟真实的seq/ack，但因为确认/丢包/拥塞策略全部由kcp控制再加上还有下层自定义协议，seq和ack的模拟实在难以实现。当然貌似只有少数ISP会做这个QoS，其他ISP环境下seq/ack一直保持自增貌似是没有问题的。
• 广电宽带（广东）和电信4G：
  • 必须模拟TCP三次握手过程，即 客户端SYN->服务端SYN+ACK->客户端ACK ，随后pipe才能打通。
  • seq/ack序列无要求，保持定值和一直自增都可以。
• 服务器提供商（阿里云等）：
  • vps之间通信基本无限制，在防火墙关闭的情况下，packet想怎么发都可以（因为没有经过NAT和ISP的QoS的缘故？）；但是对于不能直接分配到公网IP的服务器（比如腾讯云和AWS，唯一的eth0只有私有地址，上下行流量都经过网关NAT），是否也需要模拟三次握手／或者至少是服务端ack flag需要置1呢？

欢迎补充其他的情况。

[linhua55]

用的北京鹏博士，简单的SYN，就可以

1. 看来最好是模拟 标准的 TCP流量，虽然有困难，但ISP的QoS策略也会变化，这是一劳永逸， 然后还可能需要加入 HTTP/HTTPS混淆
2. 统一用 RST，可以吗？ 你可以试一下

est 63 天前
@la0wei 差不多。表示自己撸了一个 socks5 over RST 。

https://www.v2ex.com/t/313464

[ccsexyz]

@linhua55 模拟 http 流量的话可以看一下我 fork 的 kcptun，已经实现了

[Chion82]

@linhua55
理想情况下最好是模拟标准的TCP流量。然而完全模拟标准的TCP流量也是会被QoS的，某些环境下就算是标准的HTTP/HTTPS文件下载也可能会被断流，在重新建立连接之前无论如何尝试recover都不work的情况也是存在的。

一劳永逸的方案是需要不断的keepalive主动探测和下层连接的快速恢复（更换端口重新连接）。目前原版kcptun的主动探测（smux中有keepalive逻辑，但是在mux层是不方便实现断流重连的）非常鸡肋，作者在多个报断流的issue中回复的autoexpire选项也只是强行定时重连下层udp连接而已（udp本身无连接，此处指换端口更新本机及网络设备的conntrack），而这个过程会造成上层连接的完全断开。

至于HTTP/HTTPS的报文模拟，目前这个需求有待进一步实验和讨论。凭经验而言HTTP/HTTPS流量可能只是一定概率上能够降低被QoS的概率，但更多的ISP是直接对TCP连接本身下手的。而带有某种特殊HTTP payload的流量可实现别的目的，这有违kcptun的初衷，暂不讨论。

统一用RST这个方案会不会过于一刀切？RST之后中间路由器的NAT映射关系不会被直接撤销吗？有待进一步试验。这里提供一段试验代码，通过修改TCP flags就可以测试双向连通性（暂无三次握手过程）：
https://gist.github.com/Chion82/699ae432a27507242ea788df324f4e47

[linhua55]

@Chion82
简单的把SYN改为RST后，确实不通

[theratlesnake]

不支持windows的吗？

[ccsexyz]

@theratlesnake 一定要在 windows 下使用的话可以开虚拟机

[theratlesnake]

@ccsexyz 噢噢，麻烦了点

[theratlesnake]

@ccsexyz 看到博主有提到finalspeed，想请问下，博主有试过在docker上运行finalspeed吗？我现在是死活都连不上服务器