采用UDP传输音视频时的效果

已经很久没有写博客了，心中颇有荒废的不安。想起最近一年一直在写音视频的东西，就趁热打铁将音视频传输的东西写出来吧。一来作为自己工作的积累，二来希望能为有这方面需求的朋友提供一点借鉴。

很多年以来我一直觉得在音视频传输方面如果采用 TCP 协议会有较大延迟，尤其是在公网上延迟会比较大。所以我一直想写 RUDP 的东西来达到音视频传输的实时性，但是因为没有相应的项目让我去接触，所以这件事情就一直搁置了下来。

直到做我的音频棋牌的时候，才实际接触了音视频传输。由于没有现成的

RUDP

传输基础类，就在网上找到了

UDT

来作为传输的基础进行开发。当时觉得

UDT

挺不错的，也能满足我的要求，就没有再深入地去研究了（后来才知道这东西是个坑），反正作为

Demo

是已经可以了的。

当我有机会着手开发音视频直播软件的时候，我便顺其自然的建议采用 UDT 来进行开发。由于有以前的基础，所以在很短的时间内将音视频传输部分完成，并在内部测试通过。

产品上线了，我信心满满的看着自己在短时间内做完的产品，心里不由得有些得意了。可是产品上线以后，就陆续有人反应无法看到视频，同时也无法听到音频。因为刚开始反映无法接收到音视频数据的用户是联通的，而我们的服务器放在电信机房，便以为仅是电信、联通线路互联互通的问题，所以也没引起多少的在意。后来逐渐发现有些电信用户也是无法接收到音视频数据的，这就让我很疑惑，难道 UDT 真的有问题么？逐渐地，越来越多的电信用户无法得到音视频数据的事实让我确定，应该是 UDT 出现了问题。本想着去看看 UDT 的代码从而解决问题，却发现 UDT 的代码太多，涉及很多参数，阅读起来简直太困难了。后来又想，要不找 UDT 的作者提问一下，看看是什么问题，却发现 UDT 早就不再进行维护，作者的人影都找不到了。这下麻烦了，看着整天用户抱怨无法正常看到视频、听到音频，我下了一个艰难的决定——写一个满足音视频使用的 UDP 通信类。

现在想想都不知道自己为啥在时间那么紧的情况下做出这种不知天高地厚的决定。

说写就马上写起来，首先要整理一下自己的优势和劣势，哪些知识了解，哪些知识不了解。优势是我对 IOCP 非常了解，劣势是我不了解 RUDP 的原理。幸好我有朋友这么多年一直在开发这方面的东西，完全可以请教他。看来所需的知识都是具备的，或者说可以通过请教来具备的。那还等什么？说干就干！

首先写出 IOCP 对于 UDP 传输的架构来。 OK ，这个很简单，花不了多久就完成了。然后将对象池、内存池等等添加进去，这个也很容易。剩下的再把帧数据管理、小包管理等等的类添加进去，这些都很容易完成，所以我先将自己能完成的东西都先完成。剩下三个问题的就是比较麻烦的东西了，一个是数据包的重发时间确定、一个是回包的方式、以及确定哪些小包是否已经接收到。这些没办法只能请教好友，好在对于他来说都是轻车熟路，虽然他只是给我了一些点拨，但是对我的帮助的确非常大。而且在请教的过程中我发现，好友最大的用处就在于当你对一些事情不清楚的时候你可以连续不断、不知羞耻的继续询问，而他也不会发脾气。这次我才知道原来我的脸皮挺厚的，哈哈。在他的帮助下， RUDP 的通信部分很快写完了，并进行了压力测试。现在已经运行在了线上，运行状态稳定，现在很少出现用户无法连接上的情况了。并且从运行来看，实时性上比 RTMP 方式的实时性要高很多，下面的图就是实际产品中主播的实时视频截图。

本文转自狗窝博客51CTO博客，原文链接

如需转载请自行联系原作者

fxh7622