关于动态TCP header的必要性 about some_kcptun_tools

[ccsexyz]

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

[linhua55]

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

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

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

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

[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吗？我现在是死活都连不上服务器