默认
开启辅助访问
即时通讯网 资讯 音视频云声网Agora：从demo到实用，中间还差1万个WebRTC
即时通讯网 › 首页 ›资讯 › 查看内容
想开发IM：买成品怕坑？租第3方怕贵？找开源自已撸？尽量别走弯路了... 找站长给点建议
推荐 即时通讯资料太杂？看技术专辑吧! / 需要帮助？去社区发贴吧! / 技术交流群：185926912

音视频云声网Agora：从demo到实用，中间还差1万个WebRTC

52im.net · 8 年前 | 阅读（111038）· 评论（0）| 来源 CTI 转发 收藏4

摘要 因为音视频通话 = 音视频处理 + 网络传输，而公共互联网不是为了实时通信设计的。所以说开发真正可用的实时音视频服务，从demo到生产上线，中间还差1万个WebRTC。

前言

　　WebRTC开源之前，实时音视频通信听起来好高级：回声消除、噪声抑制……对于看到傅里叶变换都头疼的工程师很难搞定这些专业领域的问题。

　　Google收购了GIPS，开源了WebRTC项目之后，开发者可以自己折腾出互联网音视频通信了。下载、编译、集成之后，第一次听到通过互联网传过来的喂喂喂，工程师会非常兴奋，demo到万人直播现场只差一步了。
　　但是，电信行业要求可用性4个9，而刚刚让人兴奋的“喂喂喂”，1个9都到不了。某公司在展会上演示跨国音视频，多次呼叫无法接通，自嘲说我们还没有做网络优化嘛。这就等于互联网全民创业时期的”就差个程序员了“，本质上是和demo与真正产品之间的差距，是外行与内行之间的差距。
　　小红说家里WIFI聊QQ、打斗地主毫无压力，用你的音视频通话就卡的不行。想开发分享到微信这个功能，百度个文档照着一步步干就好了；但是找不到这样一个文档，照着做就能解决用户报的这些问题，进而把音视频通话做到电信水平。
　　音视频通话对教育、社交、约会类APP是刚需功能，上述问题会迫使用户使用更稳定的skype或微信来沟通。技术原因造成用户流失，是每个工程师都不愿意看到的事情。

实时音视频难在哪？

　　因为音视频通话 = 音视频处理 + 网络传输，而公共互联网不是为了实时通信设计的。 难点如下：
  1. 协议方面：tcp有无法忍受的延时，udp有丢包延时抖动乱序。
  2. 政治方面：各个国家出口光缆屈指可数，带宽也有严格限制。 
  3. 商业方面：由于成本原因，跨运营商的网络传输惨不忍睹。 
  4. 用户设备：无线路由器从802.11G开始才支持实时通信模式；多个路由器使用相同的频段会造成信号污染；2G网络上行带宽只有20kbps。 
  5. 架构方面：公共网络每个节点都不可靠，后台工程师熟悉的mtr命令可以分析哪个路由节点丢包高，如果此时正在传输音视频，质量必然受到影响。 
　　要在这样一个公共互联网上传输音视频数据，却没有做任何网络传输的工作，不遇到问题的话可以买彩票了。网络传输要怎么搞？老师没讲过、网上搜不到，是不是有一种深深的无力感。

具体怎么解决？

可以从以下几个方面入手：
  1. 质量评估：声音卡成翔，首先需要通过网络参数来评估语音质量。
  2. 数据统计：用户的使用情况到底怎么样，需要完善的数据统计模型和支撑系统，不然开发者就是睁眼瞎。
  3. 智能接入：影响质量的原因——不同的ISP会有不同的丢包水平，需要多线服务器。
  4. 智能路由：随着用户扩张到海外，比如电信用户和美国用户通话时丢包大，没有一边电信一边美国这种多线服务器，可能通过日本转发过去就不丢包了，这就是智能路由。
  5. 虚拟专线：智能接入加上智能路由，可以媲美网络专线的质量了，这就是所谓的虚拟专线。
  6. 丢包对抗：用户抱怨明显少了很多，还剩下一些自己网络不给力的用户。用户x一直用2G，用户y在公司里很多WIFI有信号污染，那么就需要丢包对抗机制。
  7. 网络可用性：用户报虹桥机场打不通，小发现公共场所WIFI有很多限制，所以需要考虑网络可用性。
  8. 后台高可用：用户没问题了，但各种互联网公司事件让运营者担心自己服务器电源也被挖掘机铲断，所以需要后台高可用。

即时通讯网 - 即时通讯开发者社区！ 来源： - 即时通讯开发者社区！

旧一篇：
基于XMPP协议的开源IM服务端Openfire发布4.0.2正式版

相关阅读

最新评论

微信扫一扫关注！

相关分类

即时通讯方案hot[淘宝下单]

本月热门资讯

技术好文分类[更多]

TCP/IP详解经典 网络编程基础 NIO编程精选 通信协议选型 IM架构篇 IM安全篇 IM群聊篇 IM热门讨论 心跳保活篇 IM综合资料 实时音视频开发 Web端实时通信 推送技术好文 IM大厂技术分享 社交产品总结 精品资源下载 通信技术高阶 程序人生

最新社区主题[更多]

返回顶部