这是一个创建于 159 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人是做 WebRTC 音视频聊天开发，音视频走的都是 UDP 协议。在模拟环境对比腾讯会议和微信，我们做的程序在抗丢包，带宽拥塞控制方面都不比腾讯差多少。
但是在线上环境总有不少用户反馈，使用我们的产品视频通话就卡，使用腾讯会议就没问题。通过统计数据看，用户卡的时候，UDP 通信带宽非常低，基本在 100kbps 以下了。
最近看了 V 站上有讨论国内运营商对 UDP 有限制，所以想弄明白，运营商事对国外到国内的 UDP 有限制，还是境内内部的 UDP 也有限制。为什么相同条件下腾讯会议表现不卡，我们的卡？难道运营商对腾讯会议这些用户量大的软件有白名单？
49 条回复 • 2024-06-21 20:51:37 +08:00
 |
1
JensenQian 159 天前
都有，本人回家之前用 wireguard ，给限速的只剩下一半
用基于 tcp 的 openvpn 就没问题 估计是了，微信什么的肯定有白名单吧 |
 |
2
drymonfidelia 159 天前
境内肯定有限制，国内视频网站都在用 webrtc 嫖用户上传带宽
|
 |
3
yueji 159 天前
udp 的话，记得上 fec 算法
|
 |
4
yankebupt 159 天前
抗丢包做的很好的话求报一下丢包率数据……100kbps 不知道得丢多少包……
另外不知道还剩 100kbps 是不是只够打 udp 游戏的。 |
 |
5
dpx 159 天前
只要服务器在国内，UDP 数据不加密。问题不大。
|
 |
6
DonaldErvinKnuth 159 天前
个人理解
运营商针对 udp 有限制，因为无连接，容易攻击，所以会限制 服务器拉的不同线路对 udp 的限制不一致，不清楚你们的线路是否合理 ip 层本身有 tos ，不同的包优先级不一样，不知道是不是在这里要做优化 运营商会对腾讯等大公司有一些特殊照顾，你们是不是也要找运营商谈 |
 |
7
WeaponXu 159 天前
网络处理有优先级啊，楼上老哥说的 tos ，腾讯肯定是付费用户。
|
 |
8
Kroos 159 天前
音频的话还好吧，我用 coturn 、eturnal 搭建的 ICE 服务器，15 人同一个房间（启用强制 TURN ），服务器峰值上行快到 30M 了一点问题都没有。视频的话我就不清楚了。
|
 |
10
NewYear 159 天前
我在出租屋流量连接公司专线的 wireguard ，限速 50KB ，卡得死死的，所以没有任何幻想。
|
 |
11
asuraa 159 天前 via iPhone
fec 然后疯狂发包就是了
|
 |
12
wangyucn 159 天前
>fec 然后疯狂发包就是了
别教别人乱搞 超过一定限度发越多丢越多 |
 |
13
busier 159 天前 via iPhone
你都自己能判断出通信带宽非常低，还有什么可抱有幻想的，明显就是运营商会特殊照顾鹅厂
再说了 鹅厂的又不是不能用 干嘛还要去开发一个 幻想要自主可控？ |
 |
14
zhs227 159 天前
首先你要确定假设成不成立。音频在网络上传送的时候，你可以装个测速计看看腾讯会议之类的占用的带宽是多少，给腾讯会议上个限速看看他怎么表现，以及用了 TCP 还是用了 UDP 。在拥塞控制指示显示拥塞的时候，是否有对音频进行降码率，是否使用了 Lyra 之类的低比特率编码方案替代。除了所有这些软实力以外，就是运营商开 buf 了，这种硬实力一般的人没有，也基本上不能通过技术改进来解决。
|
 |
15
coderxy 159 天前
腾讯在各大运营商那边充值了，带宽不够时优先保障腾讯的报文， 你技术上怎么比？
|
 |
16
zombiecong 159 天前
不同运营商对不同厂家的服务器网络路由都不一样，要在调度和架构上优化
|
 |
17
lasuar 159 天前
很多大厂的音视频童话服务都是有协议级别的优化的，小公司基本上很难搞，用户多起来全是投诉。纯 UDP 搞不定的，不过为什么要自研呢，直接使用云提供的 IM 服务啊，这块自研成本巨高的，不是几个人 clone 个开源项目就能搞出来的。
|
 |
18
wanwaneryide 159 天前
@DonaldErvinKnuth 我觉得大公司其实不需要找运营商谈，毕竟通常来说，大公司的基础产品基本是不得不用的地步，即使不好用了，卡顿，普通人都会认为是运营商的问题，不会是大公司产品的问题，只要这类的投诉多了，运营商自然而然的会做相关的优化
|
 |
19
wy315700 159 天前
你们是不是用了 BGP 的线路。。线路质量不一样，QOS 等级不一样
|
 |
20
shadowyue 159 天前
这种像基建一样的服务，感觉不用大厂成熟方案，自己搞会不会是无底洞
|
 |
21
toneytonight 159 天前
真实经历过从自研放弃到大厂方案的，底层协议和算法的优化不是一个小团队可以搞定的
|
 |
22
mengzhuo 159 天前
|
 |
23
deavorwei 159 天前
udp over tcp ?
|
 |
24
victorc 159 天前
大厂和运营商都会 1 对 1 对接商务
小团体玩不起这个 |
 |
25
kenvix 159 天前
不会给你故意加延迟或者加塞，但是会有速率限制。这样可以保证游戏和通话通畅。因此一般没问题
|
|
26
kenvix 159 天前
不过带宽更大的话就得和运营商那边谈了。小规模带宽（游戏）一般没问题，因此你把码率压得很低也是可以的
|
 |
27
guanzhangzhang 159 天前
@NewYear 我 1M 云主机 wireguard+转 tcp ，速度能有 600-700kb
 |
 |
28
basncy 159 天前
@DonaldErvinKnuth #6 没有自己的专属 IP 段, 估计不好谈, 无法优化.
所以思科 webex, zoom, gcp 有自己的 VoIP IP 段. @Kroos #8 谁家的? 可以指定自建的 turn 服务器? |
 |
29
LLaMA2 159 天前
视频 H265 720P 15fps
音频 G711 alaw 单路通话双向流量大概不超过 3.5Mbps ,差不多单边 220KB/s 特么你要上 1080P H264 30fps AAC 单边差不多要 900KB/S |
 |
30
cnbatch 158 天前
有个办法绕开 UDP 限速，但不保证 100%有效
首先建议给 UDP 测速，看看 UDP 流量是一开始就被限速，还是过一段时间再被限速的。 遇到限速后，再在同一条宽带建立新的连接，重新再试。 整个最好用另一条闲置线路去测，不要直接用现有的繁忙的业务线路，这样准确点。 如果是过一段时间才遇到限速，并且建立新连接后发现限速解除，新连接再过一段时间又限速，那就说明运营商做的限速是基于端口的限速。这种情况就可以试下这个办法。 办法很简单： 服务器侧监听一大段端口，客户端连接这里面的端口都能通。 客户端建立连接后，每隔一段时间就再建立新的 connection ，连上服务器侧的另一个端口，把现有通讯转过去。 为什么客户端要建立新连接？因为这样可以保证客户端的源地址也会改变。 这个办法就是我写的工具 UDPHop 的基本原理，做起来相对简单 |
|
31
wangyucn 158 天前  1
@cnbatch 我也遇到过类似的情况：
(有时候)1. 本来 udp 连接很快，但是过了几天会非常慢。如果重连换个连接就会快起来。 (其他有的时候)2. udp 刚连就很慢。如果手动反复重连，多试几次可以挑出来一个快(或者说丢包低)的 session 。然后可以保持快的速度很久。 (就好像底层有什么负载均衡机制，会把 udp session 分到不同的设备，反复手动重连可以“挑”出来一个快的设备） |
 |
32
lightionight 158 天前
|
 |
33
milzero 158 天前
我之前做 K12 产品的，每天差不多 100W 分钟左右，按城市和运营商还有用户场景这些，差别很大。只能说这个地域性很强。
再说 100K 这个 case ，多半是 GCC 的锅，可以检查下，是不是同时伴随丢包。 |
 |
35
me1onsoda 158 天前
音视频不是都用 tcp 封装的 rmtp 嘛
|
 |
36
GreyWang 158 天前
腾讯会议编码用的是 H265 ，本身码率会比较低，同时加了很多魔法操作，比如网络带宽差的时候降分辨率、降帧率，这些操作都能降低对带宽的要求，保证通话的流畅性，不会出现卡顿的情况。
另外实际线上环境还有乱序到达的问题，webrtc 如果没特殊处理的话兼容性很差，基本只要一乱序就发 nack 重传，很多带宽就被浪费了。 |
 |
37
devzhaoyou OP @milzero #33 是有丢包，如果这时候 GCC 不降带宽，暴利发包，丢包会更严重，重传带宽很高，接收端还是比较卡。从统计上看就是带宽降的非常低。每天有 1W 左右的用户，出现带宽突然降低的非常低的情况占比接近 1%
|
 |
38
luxor 158 天前
运营商对于 UDP 不只是限速，而且还会出现断流。是所有 UDP 都断流。不存在按照端口限速的问题。
|
|
39
milzero 158 天前
@devzhaoyou
超过丢包阈值后就要分析丢包类型了： 1. 如果是运营商 QoS 导致的丢包，也有两种模式，第一个限制带宽，这种情况只有让运营商识别不到这种方式解决了，第二个是随机丢包，特征就是不管你发多少，运营商都按一定的比例来丢，这种情况就是 Fec 多发。或者尝试多径，但是成本有点高。 2. 信道受损产生的丢包，比如离路由器或者基站远了，或者 wifi 干扰比较严重，这个时候实际带宽可能充足，也有可能受限。如果充足的话，可以考虑调整 BWE 下降的策略. 3. 带宽受限导致的丢包，这种情况就只能考虑降级了。 上面这些都是基于我之前的一些经验。不知道你们的架构和业务这些，可能说的不对。 都得 case by case 的分析原因，针对性的看。 不知道这 1% 在城市，运营商(移动联调电信)，场景(wifi,固网，蜂窝网络)上的分布，1%说不多，说少也不少了。 |
|
40
milzero 158 天前
运营商肯定会有 QoS ，但是和具体的公司还有地域相关性很高
|
 |
41
EsWann 158 天前
|
 |
42
opentrade 158 天前
很多云服务器对 udp 也不友好
|
 |
43
daokedao 158 天前
那 http/3 也受影响？不知道国内 http/3 用的怎样？
|
 |
44
lihaohenqiang 158 天前 via iPhone
@daokedao QUIC 流量基本就是寄，有时候跨省的 QoS
就非常感人 |
 |
45
Donaldo 158 天前
都说有限制，不过我还没遇到过。不管是打游戏，打电话，还是 Hysteria2.。。
|
 |
46
Meonardo 156 天前
很神奇! 我遇到个问题, 手机 5G 网络和一台 PC 进行 WebRTC 视频通话必失败(P2P), 但是通过阿里云部署的 SFU 服务就能正常通话, 协议都是一样, 阿里云机房 IP 运营商是上了白名单吗?
|
|
47
Meonardo 156 天前
有自己部署的 STUN/TURN, 如果不通过 SFU 中转, 只通过 TURN 做转发也是不行... 这个 TURN 也是部署在阿里云.
|
Select Language