Kcptun: 被Qos解决办法，

[f4nff]

看到过很多分析Qos的文章，有伪造为tcp数据包什么的，
看似很高深，好像并没有什么用。
下面根据个人多年运维经验测试，

在一般的运营商Qos里面，只有两种策略。
1：惩罚式（比如联通，可以使用iperf3 发起上行测试，如果超过一个值，然后这个tcp连接就变得非常慢，只有几k/s，解决办法，只能断开重连。
2：限速式，电信非也，电信限制了单连接的最大上行带宽，大多家宽上行单连接都在15-20Mbps，所以导致电信宽带比较稳定，联通惩罚，体验很差，所以稳定性联通大不如电信，但是联通突发速度快。

不管是电信，还是联通，其实上行，下行qos的判断条件是一样的，基本都是突发快，然后就慢了，

比如：

kcptunclient：192.168.1.2:3321 ->>-kcptunserver：8.8.8.8:80

这是连接方式，本地会有一个端口，对应远程服务端端口，本地端口一般是随机的，

解决Qos就两种方式，
1：每个并发限速，限制最大速度，这样可以使用iperf3去测试当时qos最大值，略小，尽量不要超过惩罚值，
2：设置每个连接的时效。
比如vpngate里面有一种模式，就可以设置多并发，并且多连接。
但是释放本地端口，重新建立连接怎么会话平滑转移，我就不得而知了，
我记得quic是支持会话平滑转移的。

这种现象很明显，比如你刚开始测试kcptun开启的一段时间，速度是挺快，但是挂久了，就变得非常慢，这时候，只需要释放掉隧道，重新发起新隧道即可，这样本地的

kcptunclient：192.168.1.2:3322  ->>-kcptunserver：8.8.8.8:80
kcptunclient：192.168.1.2:3323  ->>-kcptunserver：8.8.8.8:80
kcptunclient：192.168.1.2:3324  ->>-kcptunserver：8.8.8.8:80

一直在变化，运营商Qos那边是有时效期的。

当然；最好的办法是：
1：限速，针对每个隧道限制最大带宽
2：多并发，
3：设置每个隧道的时效，超过时效释放，重新发起新隧道

[f4nff]

还有一种情况，我测udp打洞的时候，复现的，
比如阿里云来说

本地 192.168.2.22:8889-->>---阿里云 47.221.22.22:80

udp发送数据，连续发送几个udp数据包，如果阿里云那边没有返回数据，那么本地怎么发数据，阿里云那边也收不到，
这就是我看到一些人有讲必须重启进程才能连上的原因，
如果网络抖动的时候，过多单边发送udp数据，会被视为攻击行为，会被屏蔽
这时候，就要释放掉本地的端口，重新建立新的连接，即可，这就是重启进程就恢复的根本原因。

以上3点如果做到，基本就有本质的改变了。

[f4nff]

--conn value set num of UDP connections to server (default: 1)

这个参数只是实现了多并发连接，
可以实现多连接实现更多带宽争取，

但是解决断流问题需要实现 会话平滑转移，单位时间内，先建立新的隧道，然后把会话转移到新的隧道，然后释放之前的隧道，
然后为了尽量避免因为突发带宽过高触发Qos策略，还需实现限流，是单个连接的限流，而不是根据ip限流。

运营商，不止国内，基本全球运营商的Qos都是针对单连接的限速，而不是根据某个ip限速。

[f4nff]

--tcp to emulate a TCP connection(linux)

这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，

Qos的条件非常简单，
在互联网中qos除了特别的策略，
只有四个条件，
源ip，源port，目标ip，目标port
而且还有时效性，
只要这四个条件一直变，就可以完全避开Qos策略。

[f4nff]

在互联网中qos除了特别的策略，
只有四个条件，
源ip，源port，目标ip，目标port
而且还有时效性，
只要这四个条件其中一个条件一直变，就可以完全避开Qos策略。

假设一个连接只用45s-120s左右，
并发5个连接，每个连接限速50Mbps峰值，
那么一直可以持续200Mbps带宽是没问题的。

不过这样还是悄悄的玩，不然出口会更堵了。

[laikitleung]

"autoexpire"不是干这个的？

[f4nff]

--autoexpire value set auto expiration time(in seconds) for a single UDP connection, 0 to disable (default: 0)
@laikitleung
这个确实有这个作用，但是不支持会话平滑转移到新连接，
如果老隧道里面有长连接，老隧道会一直保持，
如果完善一下这个功能，增加一下会话平滑转遇到新建隧道，就不错了，

[krrr]

感觉假tcp模式还是很有必要的。
最近遇到一次udp几乎连不上，kcptun客户端和服务端重启都无效的情况。参数只加个--tcp又复活，不知道这算不算qos。

详情：宽带是电信，kcptun平常一直用来玩网游，流量非常小，最高速从来不超过1Mbit/s，不用于任何其他用途。今天突然就像被墙了一般udp疯狂丢包，日志里只有stream open、stream close。

[bash99]

--autoexpire value set auto expiration time(in seconds) for a single UDP connection, 0 to disable (default: 0)
@laikitleung
这个确实有这个作用，但是不支持会话平滑转移到新连接，
如果老隧道里面有长连接，老隧道会一直保持，
如果完善一下这个功能，增加一下会话平滑转遇到新建隧道，就不错了，

autoexpire 如果能平滑转移就太棒了，上游isp超级奇怪的封掉了kcpraw（可能fake tcp的实现不够完善被QOS了），我转到udp2raw + kcptun，还是碰到了clone超级大的git项目时断流的现象。kcpraw的自动保活重连似乎要灵敏的多。
正在测试各种参数看看能否重现kcpraw的效果。

[SOE-121]

好啊，垃圾车变超跑

移动宽带，下行250M，上行100M，服务器MC机房
客户端参数
--sndwnd 2666 --rcvwnd 6666 --ds 40 --ps 10 --mode normal --autoexpire 60 --conn 60 --quiet

[rilyuuj]

按照@f4nff老哥意思，设置autoexpire=60，如果在看视频，过了60秒后，假设没有预加载功能，是不是会出现卡顿(重新发起session加载视频)？

[wangyu-]

首先肯定一下楼主所说的方法是有效果的，尤其是在应对楼主所描述QOS场景时。

但是有些观点太不准确，误导性比较强：

>在一般的运营商Qos里面，只有两种策略。

>解决Qos就两种方式



md5-b4b6b07891238ab54363f8fd7a42662d



>当然；最好的办法是：
1：限速，针对每个隧道限制最大带宽
2：多并发，
3：设置每个隧道的时效，超过时效释放，重新发起新隧道



md5-b4b6b07891238ab54363f8fd7a42662d



>只要这四个条件一直变，就可以完全避开Qos策略。



md5-b4b6b07891238ab54363f8fd7a42662d



>--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，

首先是Qos策略，除了楼主说的两种Qos策略，我能想到的其他的比较容易实现的Qos策略：

1. 在路由策略里tcp流量的优先级比udp高。 如果网络上tcp流量比较大，就优先丢udp来保证tcp的质量。
2. udp流量的带宽总量受限。
3. udp丢包极高，或者完全被屏蔽。
4. 运营商的设备对udp nat的支持不好，不管流量大小，过一段时间nat pipe就无法保留。 (这条可能不应该算Qos策略)

(至于运营商有没有用上面的策略，我没有证据。 不过我至少比较确定我遇到过3)

楼主说的方法对1~3就没什么作用。

关于“最好的办法”，“完全避开Qos策略”，“--tcp 其实没有任何意义”：
我想说很多实际问题不存在“最好的办法”。 有些朋友的“kcptun断流，或者跑不满带宽”，这个问题可能有很多原因，有可能是楼主说的QOS策略，也可能是其他原因。 对症下药的方法才是好的方法。 楼主说的方法确实可以比较好的解决楼主描述的QOS场景。
但是如果说这种方法可以一劳永逸，”完全避开Qos策略“，别的某某方法”没有任何意义“，实在是太不准确。

--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，

检测一个链接是tcp还是udp，只要看ip包头里一个字节就可以，不需要特别”深度“的检测。nat本来就要根据流量是tcp还是udp走不同的逻辑。区分流量是tcp还是udp，本来就应该是nat设备功能的一部分，并不需要什么额外工作。

--tcp模拟三次握手，主要原因不是为了应对高深的检测，主要是为了兼容中间nat设备，让nat pipe可以正确建立。

最后，总结下。如果楼主所说的功能可以完美实现，确实可以增加一种应对Qos的选项。能不能实现就看有没有开发者有时间精力了。

[wangyu-]

@wangyu-
本来kcptun就是udp传输，你扯tcp有何意义，
udp的优势可以实现会话平滑转移，比如quic已经实现了。

扯了那么多，打了那么多字，你就说了一句话，tcp高传输比udp强，还有别的吗？
这个你不说大家都知道，
但是kcptun使用udp的意义在于在一定丢包的场景中，使用高流量带宽进行弥补，

比如使用2倍的流量换取一倍的有效平稳流量，
tcp如果丢包，一个包丢了，就需要重传，整个队伍就需要一直等待，

别鸡蛋里面挑骨头，实现了会话平滑转移之后，看看是不是有本质的改变。

不要激动。

我没否定你说的方法在一些Qos场景会有效果，也不是不鼓励你说的方法被实现出来。

只是说：

1. Qos形式多种多样。在一般的运营商Qos里面，只有两种策略这种说法是武断的。
2. 你的方法可以解决你说的qos，但是存在(潜在很多)qos策略是你的方法解决不了的。所谓你的方法是”最好的办法“，”完全避开qos“，别的某某方法毫无意义。这种说法非常幼稚。

楼主分享自己的方法，是可贵的。 希望自己的方法被实现出来，这也没有问题。一些观点不准确，也没啥，毕竟人无完人。 但是没必要对自己的方法夸大其词，把别的方法贬得一文不值。

[lbp0200]

客户端启动1000个端口，服务器端启动1000个端口，随机选择一个，不就好了？

[q741451]

实测--conn 60对多线程的提升异常猛烈！有没有办法让单线程tcp连接产生的UDP包支持走多个udp连接就香了。

[oha002]

我的VPN看1080P基本都是三万多Kbps，这是否意味着被限速了？如果是如何调整？