xtaci
被Qos解决办法，
看到过很多分析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：设置每个隧道的时效，超过时效释放，重新发起新隧道
还有一种情况，我测udp打洞的时候，复现的， 比如阿里云来说
本地 192.168.2.22:8889-->>---阿里云 47.221.22.22:80
udp发送数据，连续发送几个udp数据包，如果阿里云那边没有返回数据，那么本地怎么发数据，阿里云那边也收不到， 这就是我看到一些人有讲必须重启进程才能连上的原因， 如果网络抖动的时候，过多单边发送udp数据，会被视为攻击行为，会被屏蔽 这时候，就要释放掉本地的端口，重新建立新的连接，即可，这就是重启进程就恢复的根本原因。
以上3点如果做到，基本就有本质的改变了。
--conn value set num of UDP connections to server (default: 1)
这个参数只是实现了多并发连接， 可以实现多连接实现更多带宽争取，
但是解决断流问题需要实现 会话平滑转移，单位时间内，先建立新的隧道，然后把会话转移到新的隧道，然后释放之前的隧道， 然后为了尽量避免因为突发带宽过高触发Qos策略，还需实现限流，是单个连接的限流，而不是根据ip限流。
运营商，不止国内，基本全球运营商的Qos都是针对单连接的限速，而不是根据某个ip限速。
--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包， nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，
Qos的条件非常简单，
在互联网中qos除了特别的策略，
只有四个条件，
源ip，源port，目标ip，目标port
而且还有时效性，
只要这四个条件一直变，就可以完全避开Qos策略。
在互联网中qos除了特别的策略，
只有四个条件，
源ip，源port，目标ip，目标port
而且还有时效性，
只要这四个条件其中一个条件一直变，就可以完全避开Qos策略。
假设一个连接只用45s-120s左右， 并发5个连接，每个连接限速50Mbps峰值， 那么一直可以持续200Mbps带宽是没问题的。
不过这样还是悄悄的玩，不然出口会更堵了。
--autoexpire value set auto expiration time(in seconds) for a single UDP connection, 0 to disable (default: 0)
@laikitleung
这个确实有这个作用，但是不支持会话平滑转移到新连接，
如果老隧道里面有长连接，老隧道会一直保持，
如果完善一下这个功能，增加一下会话平滑转遇到新建隧道，就不错了，
感觉假tcp模式还是很有必要的。 最近遇到一次udp几乎连不上，kcptun客户端和服务端重启都无效的情况。参数只加个--tcp又复活，不知道这算不算qos。
详情：宽带是电信，kcptun平常一直用来玩网游，流量非常小，最高速从来不超过1Mbit/s，不用于任何其他用途。今天突然就像被墙了一般udp疯狂丢包，日志里只有stream open、stream close。
--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的效果。
好啊，垃圾车变超跑
移动宽带，下行250M，上行100M，服务器MC机房
客户端参数
--sndwnd 2666 --rcvwnd 6666 --ds 40 --ps 10 --mode normal --autoexpire 60 --conn 60 --quiet
按照@f4nff老哥意思，设置autoexpire=60，如果在看视频，过了60秒后，假设没有预加载功能，是不是会出现卡顿(重新发起session加载视频)？
首先肯定一下楼主所说的方法是有效果的，尤其是在应对楼主所描述QOS场景时。
但是有些观点太不准确，误导性比较强：
>在一般的运营商Qos里面，只有两种策略。
>解决Qos就两种方式
>当然；最好的办法是：
1：限速，针对每个隧道限制最大带宽
2：多并发，
3：设置每个隧道的时效，超过时效释放，重新发起新隧道
>只要这四个条件一直变，就可以完全避开Qos策略。
>--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，
首先是Qos策略，除了楼主说的两种Qos策略，我能想到的其他的比较容易实现的Qos策略：
- 在路由策略里tcp流量的优先级比udp高。 如果网络上tcp流量比较大，就优先丢udp来保证tcp的质量。
- udp流量的带宽总量受限。
- udp丢包极高，或者完全被屏蔽。
- 运营商的设备对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- 本来kcptun就是udp传输，你扯tcp有何意义， udp的优势可以实现会话平滑转移，比如quic已经实现了。
扯了那么多，打了那么多字，你就说了一句话，tcp高传输比udp强，还有别的吗？ 这个你不说大家都知道， 但是kcptun使用udp的意义在于在一定丢包的场景中，使用高流量带宽进行弥补，
比如使用2倍的流量换取一倍的有效平稳流量， tcp如果丢包，一个包丢了，就需要重传，整个队伍就需要一直等待，
别鸡蛋里面挑骨头，实现了会话平滑转移之后，看看是不是有本质的改变。
不要激动。
我没否定你说的方法在一些Qos场景会有效果，也不是不鼓励你说的方法被实现出来。
只是说：
- Qos形式多种多样。
在一般的运营商Qos里面，只有两种策略这种说法是武断的。 - 你的方法可以解决你说的qos，但是存在(潜在很多)qos策略是你的方法解决不了的。所谓你的方法是”最好的办法“，”完全避开qos“，别的某某方法毫无意义。这种说法非常幼稚。
楼主分享自己的方法，是可贵的。 希望自己的方法被实现出来，这也没有问题。一些观点不准确，也没啥，毕竟人无完人。 但是没必要对自己的方法夸大其词，把别的方法贬得一文不值。
HOW TO DO?
OG-C @.***> 于2021年5月31日周一 上午9:58写道：
原理如此，用什么工具能做到那些调整呢？
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/xtaci/kcptun/issues/776#issuecomment-851115385, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWO52AWDCXDVVOQUNXP3TQLULDANCNFSM4LWSB5SQ .
楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。 请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。
实测--conn 60对多线程的提升异常猛烈！有没有办法让单线程tcp连接产生的UDP包支持走多个udp连接就香了。
我自己写了个单UDP连接走多UDP连接通道的代理程序，让kcp的单个udp连接走多个UDP通道，实测对kcptun单线程没有提速，依然3M左右每秒的单线程下载。但是kcptun在--conn 60同时多线程时，可以很轻松跑满整个带宽，有人知道这是为什么吗？有没有办法让单线程下走更激进的UDP加速？
楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。 请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。
你怎么确定你遇到的结果是由于你所谓的“MAC地址锁速度”导致的？
楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。 请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。
你怎么确定你遇到的结果是由于你所谓的“MAC地址锁速度”导致的？
首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。
首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。
你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。
首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。
你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。
也许是吧
如果是OPENVPN 或者WireGuard,如何提高速度？
miny1233 @.***> 于2021年12月27日周一 15:29写道：
首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。
你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。
也许是吧
— Reply to this email directly, view it on GitHub https://github.com/xtaci/kcptun/issues/776#issuecomment-1001394427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
如果是OPENVPN 或者WireGuard,如何提高速度？ miny1233 @.> 于2021年12月27日周一 15:29写道： … 首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。 你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。 也许是吧 — Reply to this email directly, view it on GitHub <#776 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.>
找udp的代理
THANKS TO ALL
miny1233 @.***> 于2021年12月28日周二 11:58写道：
如果是OPENVPN 或者WireGuard,如何提高速度？ miny1233 @.
> 于2021年12月27日周一 15:29写道： … <#m_3717358632975685132_> 首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。 你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。 也许是吧 — Reply to this email directly, view it on GitHub <#776 (comment) https://github.com/xtaci/kcptun/issues/776#issuecomment-1001394427>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.>
找udp的代理
— Reply to this email directly, view it on GitHub https://github.com/xtaci/kcptun/issues/776#issuecomment-1001855762, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWOYUBQ7VWF4KA7LR54TUTEYURANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
如果 OPENVPN 和WireGuard能够迅速连接，但要等三五分钟才能真正访问油管等境外网站，速度还可以。那么一般是什么地方出现问题？谢谢
michael jackson @.***> 于2021年12月28日周二 15:07写道：
THANKS TO ALL
miny1233 @.***> 于2021年12月28日周二 11:58写道：
如果是OPENVPN 或者WireGuard,如何提高速度？ miny1233 @.
> 于2021年12月27日周一 15:29写道： … <#m_-5914054423760718800_m_3717358632975685132_> 首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。 你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。 也许是吧 — Reply to this email directly, view it on GitHub <#776 (comment) https://github.com/xtaci/kcptun/issues/776#issuecomment-1001394427>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ https://github.com/notifications/unsubscribe-auth/ATPTWO344M5S4INTEFLHFKDUTAIT3ANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.>
找udp的代理
— Reply to this email directly, view it on GitHub https://github.com/xtaci/kcptun/issues/776#issuecomment-1001855762, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATPTWOYUBQ7VWF4KA7LR54TUTEYURANCNFSM4LWSB5SQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>