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

[devzhaoyou]

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

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

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

[toneytonight]

真实经历过从自研放弃到大厂方案的，底层协议和算法的优化不是一个小团队可以搞定的

[mengzhuo]

@wangyucn 大佬！

@devzhaoyou 其实我想上来说你们集成一下 wangyu 大佬的 udp2raw ，伪装成 tcp 就行

[deavorwei]

udp over tcp ?

[victorc]

大厂和运营商都会 1 对 1 对接商务

小团体玩不起这个

[kenvix]

不会给你故意加延迟或者加塞，但是会有速率限制。这样可以保证游戏和通话通畅。因此一般没问题

[kenvix]

不过带宽更大的话就得和运营商那边谈了。小规模带宽（游戏）一般没问题，因此你把码率压得很低也是可以的

[guanzhangzhang]

@NewYear 我 1M 云主机 wireguard+转 tcp ，速度能有 600-700kb

[basncy]

@DonaldErvinKnuth #6 没有自己的专属 IP 段, 估计不好谈, 无法优化.
所以思科 webex, zoom, gcp 有自己的 VoIP IP 段.

@Kroos #8 谁家的? 可以指定自建的 turn 服务器?

[LLaMA2]

视频 H265 720P 15fps
音频 G711 alaw
单路通话双向流量大概不超过 3.5Mbps ,差不多单边 220KB/s

特么你要上 1080P H264 30fps AAC 单边差不多要 900KB/S

[cnbatch]

有个办法绕开 UDP 限速，但不保证 100%有效

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

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

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

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

这个办法就是我写的工具 UDPHop 的基本原理，做起来相对简单

[wangyucn]

@cnbatch 我也遇到过类似的情况：

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

(其他有的时候)2. udp 刚连就很慢。如果手动反复重连，多试几次可以挑出来一个快(或者说丢包低)的 session 。然后可以保持快的速度很久。 (就好像底层有什么负载均衡机制，会把 udp session 分到不同的设备，反复手动重连可以“挑”出来一个快的设备）

[lightionight]

@guanzhangzhang 😂

[milzero]

我之前做 K12 产品的，每天差不多 100W 分钟左右，按城市和运营商还有用户场景这些，差别很大。只能说这个地域性很强。

再说 100K 这个 case ，多半是 GCC 的锅，可以检查下，是不是同时伴随丢包。

[milzero]

@coderxy 好奇运营商是怎么识别出腾讯的 RTP 包的

[me1onsoda]

音视频不是都用 tcp 封装的 rmtp 嘛

[GreyWang]

腾讯会议编码用的是 H265 ，本身码率会比较低，同时加了很多魔法操作，比如网络带宽差的时候降分辨率、降帧率，这些操作都能降低对带宽的要求，保证通话的流畅性，不会出现卡顿的情况。
另外实际线上环境还有乱序到达的问题，webrtc 如果没特殊处理的话兼容性很差，基本只要一乱序就发 nack 重传，很多带宽就被浪费了。

[devzhaoyou]

@milzero #33 是有丢包，如果这时候 GCC 不降带宽，暴利发包，丢包会更严重，重传带宽很高，接收端还是比较卡。从统计上看就是带宽降的非常低。每天有 1W 左右的用户，出现带宽突然降低的非常低的情况占比接近 1%

[luxor]

运营商对于 UDP 不只是限速，而且还会出现断流。是所有 UDP 都断流。不存在按照端口限速的问题。

[milzero]

@devzhaoyou

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

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

不知道这 1% 在城市，运营商(移动联调电信)，场景(wifi,固网，蜂窝网络)上的分布，1%说不多，说少也不少了。

[milzero]

运营商肯定会有 QoS ，但是和具体的公司还有地域相关性很高