New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

关于动态TCP header的必要性 #2

Open
Chion82 opened this Issue Feb 11, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@Chion82

Chion82 commented Feb 11, 2017

经过初步的测试,发现不同的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

This comment has been minimized.

Owner

linhua55 commented Feb 12, 2017

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

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

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

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

@ccsexyz

This comment has been minimized.

ccsexyz commented Feb 12, 2017

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

@Chion82

This comment has been minimized.

Chion82 commented Feb 12, 2017

@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

This comment has been minimized.

Owner

linhua55 commented Feb 13, 2017

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

@theratlesnake

This comment has been minimized.

theratlesnake commented Feb 17, 2017

不支持windows的吗?

@ccsexyz

This comment has been minimized.

ccsexyz commented Feb 17, 2017

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

@theratlesnake

This comment has been minimized.

theratlesnake commented Feb 17, 2017

@ccsexyz 噢噢,麻烦了点

@theratlesnake

This comment has been minimized.

theratlesnake commented Feb 17, 2017

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

@Chion82 Chion82 referenced this issue Jun 15, 2018

Open

SYN flag #19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment