- 通信方式
- STUN 与 TURN 服务
- 信令系统
- 处理架构
做音视频聊天是一件有趣的事，因为你可以有机会去学到很多其它领域的东西。Cable Messenger 的音视频聊天主要采用Google的Webrtc库，以及搭配我们自己开发的一套“信令系统”实现。
对于Webrtc源码的学习和研究，一直会是一件十分振奋人心的事情。很多在接Webrtc库时，对他内部到底做了什么操作的这些疑问，以及很多技术细节，包括穿透的整个细节过程是怎么处理的等等问题将会得到答案。当然由于项目太多，时间关系，一直没有时间进行很深入的学习，以后有机会会认真学习一下，并专门写一下对于学习源码方面的心得。
通信方式好吧，我们最熟悉不过的通信方式恐怕是TCP协议，HTTP协议，以及UDP协议了吧。音视频聊天一般比较常用的协议是TCP及UDP。但TCP基于其内部的特点及复杂的机制，其在带宽的利用率以及性能上，恐怕是不能和UDP相比的。连接前后的多次握手，对发送的数据进行分包后按顺序发送，接收者的回复印机制，丢包重传，数据校验，流量控制等等机制是UDP协议所没有的。就是因为这些逻辑的存在，TCP才被大家所认为是相对可靠的传输方式。但可靠性的实现往往需要牺牲性能作为代价。
UDP协议，恐怕大家很少用。小弟很久以前，在做会议投屏项目中曾经采用过，当时也只是基于内网环境进行使用，所以没有涉及到穿
