Skip to content
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.

Sign up for GitHub

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

Jump to bottom

被Qos解决办法， #776

Closed
f4nff opened this issue Mar 30, 2020 · 35 comments
Closed

被Qos解决办法， #776

f4nff opened this issue Mar 30, 2020 · 35 comments

Comments

@f4nff
Copy link

f4nff commented Mar 30, 2020 •
edited
Loading

看到过很多分析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
Copy link
Author

f4nff commented Mar 30, 2020

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

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

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

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

@f4nff
Copy link
Author

f4nff commented Apr 1, 2020

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

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

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

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

@f4nff
Copy link
Author

f4nff commented Apr 1, 2020

--tcp to emulate a TCP connection(linux)

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

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

@xtaci xtaci pinned this issue Apr 1, 2020
@f4nff
Copy link
Author

f4nff commented Apr 1, 2020 •
edited
Loading

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

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

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

@laikitleung
Copy link

"autoexpire"不是干这个的？

@f4nff
Copy link
Author

f4nff commented Apr 1, 2020 •
edited
Loading

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

@krrr
Copy link

krrr commented Apr 8, 2020 •
edited
Loading

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

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

@bash99
Copy link

bash99 commented Apr 17, 2020

--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
Copy link

SOE-121 commented Jun 1, 2020

好啊，垃圾车变超跑
QQ拼音截图20200601191118
移动宽带，下行250M，上行100M，服务器MC机房
客户端参数
--sndwnd 2666 --rcvwnd 6666 --ds 40 --ps 10 --mode normal --autoexpire 60 --conn 60 --quiet

@rilyuuj
Copy link

rilyuuj commented Jun 16, 2020

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

@wangyu-
Copy link

wangyu- commented Jul 20, 2020

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

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

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

>解决Qos就两种方式

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

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

>--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-
Copy link

wangyu- commented Jul 20, 2020

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

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

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

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

不要激动。

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

只是说：

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

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

@lbp0200
Copy link

lbp0200 commented Sep 18, 2020

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

@nJhEqnvK nJhEqnvK mentioned this issue Jan 22, 2021
Closed
@q741451
Copy link

q741451 commented Mar 20, 2021

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

@oha002
Copy link

oha002 commented Apr 1, 2021

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

@OG-C
Copy link

OG-C commented May 31, 2021

原理如此，用什么工具能做到那些调整呢？

@oha002
Copy link

oha002 commented May 31, 2021 via email

@miny1233
Copy link

楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。

@mailsex
Copy link

mailsex commented Aug 23, 2021

楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。
请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。

@OG-C
Copy link

OG-C commented Aug 26, 2021

手机卡用数据流量会被QOS吗？

@q741451
Copy link

q741451 commented Dec 8, 2021

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

我自己写了个单UDP连接走多UDP连接通道的代理程序，让kcp的单个udp连接走多个UDP通道，实测对kcptun单线程没有提速，依然3M左右每秒的单线程下载。但是kcptun在--conn 60同时多线程时，可以很轻松跑满整个带宽，有人知道这是为什么吗？有没有办法让单线程下走更激进的UDP加速？

@ddzx
Copy link

ddzx commented Dec 8, 2021 via email

@adcen0107
Copy link

楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。
请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。

你怎么确定你遇到的结果是由于你所谓的“MAC地址锁速度”导致的？

@miny1233
Copy link

楼主认为Qos限速只与ip和端口有关，但是我在测试中发现可能会存在以MAC地址锁速度的情况。
请问是哪家运营商，我也发现偶尔存在这样的问题，因为我的源和目的端口都是动态的。

你怎么确定你遇到的结果是由于你所谓的“MAC地址锁速度”导致的？

首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。

@adcen0107
Copy link

首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。

你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。

@miny1233
Copy link

首先排除ip和端口的问题，一台电脑通过创建多个线程进行下载，直到总速度不变，这个速度应该就是最高速度了。此时无论再增加多少隧道速度都上不去。此时的速度没有达到家中宽带的最高速度和服务器的最高速度。不销毁这些隧道，继续进行下载。用另一台电脑连接路由器，进行相同的测速，最终速度和前一台电脑速度几乎相同，而此时两台电脑都在下载，两台电脑的下载速度并没有互相影响。两台电脑都在NAT协议下，两台电脑的公网IP相同，因此猜想分辨两台电脑的方法就是MAC地址。就是这么推来的。

你源端都在同一个NAT设备下，所以两台电脑出去的流的srcIP + srcMAC是相同的，只有src port是不同的，也即是说，同一个NAT设备下的所有流的源MAC都是相同的，不存在MAC限速的可能。我猜测你遇到的现象是通过5元组来限速的。

也许是吧

@oha002
Copy link

oha002 commented Dec 27, 2021 via email

@miny1233
Copy link

如果是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的代理

@oha002
Copy link

oha002 commented Dec 28, 2021 via email

@oha002
Copy link

oha002 commented Dec 30, 2021 via email

@briteming
Copy link

udp的代理
hi,可以介绍一款udp的代理程序吗？昨天我的wireguard这款基于udp的vpn彻底的无法用来翻／墙了

@briteming
Copy link

@miny1233

@xtaci xtaci unpinned this issue Mar 20, 2023
@zzlinwq
Copy link

zzlinwq commented Oct 20, 2023

--sndwnd 2666 --rcvwnd 6666 --ds 40 --ps 10 --mode normal --autoexpire 60 --conn 60 --quiet

@oha002
Copy link

oha002 commented Oct 21, 2023 via email

@basncy
Copy link

basncy commented Jan 8, 2025

如果是OPENVPN 或者WireGuard,如何提高速度？

Internally invite you to try udpdeminer .
Just a reminder, the total ISP bandwidth is somehow limited, don't make it being abused.

vpn client -> udpdeminer -->> Internet -->> vpn server

@xtaci xtaci closed this as completed Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests