求教国内网络 UDP 对音视频通话的友好程度

2024-06-17 20:31:07 +08:00
 devzhaoyou

本人是做 WebRTC 音视频聊天开发,音视频走的都是 UDP 协议。在模拟环境对比腾讯会议和微信,我们做的程序在抗丢包,带宽拥塞控制方面都不比腾讯差多少。

但是在线上环境总有不少用户反馈,使用我们的产品视频通话就卡,使用腾讯会议就没问题。通过统计数据看,用户卡的时候,UDP 通信带宽非常低,基本在 100kbps 以下了。

最近看了 V 站上有讨论国内运营商对 UDP 有限制,所以想弄明白,运营商事对国外到国内的 UDP 有限制,还是境内内部的 UDP 也有限制。为什么相同条件下腾讯会议表现不卡,我们的卡?难道运营商对腾讯会议这些用户量大的软件有白名单?

5823 次点击
所在节点    程序员
49 条回复
toneytonight
2024-06-18 11:11:17 +08:00
真实经历过从自研放弃到大厂方案的,底层协议和算法的优化不是一个小团队可以搞定的
mengzhuo
2024-06-18 11:30:03 +08:00
@wangyucn 大佬!

@devzhaoyou 其实我想上来说你们集成一下 wangyu 大佬的 udp2raw ,伪装成 tcp 就行
deavorwei
2024-06-18 11:36:02 +08:00
udp over tcp ?
victorc
2024-06-18 12:09:21 +08:00
大厂和运营商都会 1 对 1 对接商务

小团体玩不起这个
kenvix
2024-06-18 12:16:40 +08:00
不会给你故意加延迟或者加塞,但是会有速率限制。这样可以保证游戏和通话通畅。因此一般没问题
kenvix
2024-06-18 12:17:27 +08:00
不过带宽更大的话就得和运营商那边谈了。小规模带宽(游戏)一般没问题,因此你把码率压得很低也是可以的
guanzhangzhang
2024-06-18 12:38:32 +08:00
@NewYear 我 1M 云主机 wireguard+转 tcp ,速度能有 600-700kb
basncy
2024-06-18 14:53:50 +08:00
@DonaldErvinKnuth #6 没有自己的专属 IP 段, 估计不好谈, 无法优化.
所以思科 webex, zoom, gcp 有自己的 VoIP IP 段.

@Kroos #8 谁家的? 可以指定自建的 turn 服务器?
LLaMA2
2024-06-18 15:03:10 +08:00
视频 H265 720P 15fps
音频 G711 alaw
单路通话双向流量大概不超过 3.5Mbps ,差不多单边 220KB/s

特么你要上 1080P H264 30fps AAC 单边差不多要 900KB/S
cnbatch
2024-06-18 18:43:30 +08:00
有个办法绕开 UDP 限速,但不保证 100%有效

首先建议给 UDP 测速,看看 UDP 流量是一开始就被限速,还是过一段时间再被限速的。
遇到限速后,再在同一条宽带建立新的连接,重新再试。
整个最好用另一条闲置线路去测,不要直接用现有的繁忙的业务线路,这样准确点。

如果是过一段时间才遇到限速,并且建立新连接后发现限速解除,新连接再过一段时间又限速,那就说明运营商做的限速是基于端口的限速。这种情况就可以试下这个办法。

办法很简单:
服务器侧监听一大段端口,客户端连接这里面的端口都能通。
客户端建立连接后,每隔一段时间就再建立新的 connection ,连上服务器侧的另一个端口,把现有通讯转过去。

为什么客户端要建立新连接?因为这样可以保证客户端的源地址也会改变。

这个办法就是我写的工具 UDPHop 的基本原理,做起来相对简单
wangyucn
2024-06-18 21:31:05 +08:00
@cnbatch 我也遇到过类似的情况:

(有时候)1. 本来 udp 连接很快,但是过了几天会非常慢。如果重连换个连接就会快起来。

(其他有的时候)2. udp 刚连就很慢。如果手动反复重连,多试几次可以挑出来一个快(或者说丢包低)的 session 。然后可以保持快的速度很久。 (就好像底层有什么负载均衡机制,会把 udp session 分到不同的设备,反复手动重连可以“挑”出来一个快的设备)
lightionight
2024-06-18 22:14:02 +08:00
milzero
2024-06-18 22:19:26 +08:00
我之前做 K12 产品的,每天差不多 100W 分钟左右,按城市和运营商还有用户场景这些,差别很大。只能说这个地域性很强。

再说 100K 这个 case ,多半是 GCC 的锅,可以检查下,是不是同时伴随丢包。
milzero
2024-06-18 22:41:15 +08:00
@coderxy 好奇运营商是怎么识别出腾讯的 RTP 包的
me1onsoda
2024-06-19 09:00:04 +08:00
音视频不是都用 tcp 封装的 rmtp 嘛
GreyWang
2024-06-19 09:06:37 +08:00
腾讯会议编码用的是 H265 ,本身码率会比较低,同时加了很多魔法操作,比如网络带宽差的时候降分辨率、降帧率,这些操作都能降低对带宽的要求,保证通话的流畅性,不会出现卡顿的情况。
另外实际线上环境还有乱序到达的问题,webrtc 如果没特殊处理的话兼容性很差,基本只要一乱序就发 nack 重传,很多带宽就被浪费了。
devzhaoyou
2024-06-19 09:37:57 +08:00
@milzero #33 是有丢包,如果这时候 GCC 不降带宽,暴利发包,丢包会更严重,重传带宽很高,接收端还是比较卡。从统计上看就是带宽降的非常低。每天有 1W 左右的用户,出现带宽突然降低的非常低的情况占比接近 1%
luxor
2024-06-19 10:55:56 +08:00
运营商对于 UDP 不只是限速,而且还会出现断流。是所有 UDP 都断流。不存在按照端口限速的问题。
milzero
2024-06-19 11:56:10 +08:00
@devzhaoyou

超过丢包阈值后就要分析丢包类型了:
1. 如果是运营商 QoS 导致的丢包,也有两种模式,第一个限制带宽,这种情况只有让运营商识别不到这种方式解决了,第二个是随机丢包,特征就是不管你发多少,运营商都按一定的比例来丢,这种情况就是 Fec 多发。或者尝试多径,但是成本有点高。
2. 信道受损产生的丢包,比如离路由器或者基站远了,或者 wifi 干扰比较严重,这个时候实际带宽可能充足,也有可能受限。如果充足的话,可以考虑调整 BWE 下降的策略.
3. 带宽受限导致的丢包,这种情况就只能考虑降级了。

上面这些都是基于我之前的一些经验。不知道你们的架构和业务这些,可能说的不对。 都得 case by case 的分析原因,针对性的看。

不知道这 1% 在城市,运营商(移动联调电信),场景(wifi,固网,蜂窝网络)上的分布,1%说不多,说少也不少了。
milzero
2024-06-19 11:59:45 +08:00
运营商肯定会有 QoS ,但是和具体的公司还有地域相关性很高

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1050328

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX