概述
在开发流媒体服务器时，rtp数据如何在服务器之间转发，对于降低音视频延时和丢包有很重要的影响，如基于rtc的低延时直播系统。
在开发下一代基于rtc的直播系统时，会用到本文部分的设计思想，设计灵感来源于IP协议的路由表选路算法，以及IP地址的定义。
TCP UDP协议的区别
我们经常说tcp和udp的区别是，tcp是有连接的，udp是无连接的。
TCP的有连接
什么是连接？
连接就是一个固定的路径，这个路径是由网络上一些路由器、交换机组成。
这个连接途经的设备是固定的，这些是在tcp创建连接时选定的。
如何选择这些路径呢？
在TCP创建连接时，经过IP协议中的路由表算法，查找当前最优路径，来确定了这么一条路径。
并且将一些地址映射关系存储在了途径的路由器设备中，占用了设备的少量内存。
但是问题在于，这个路径在一开始是最优的，在传输过程中，可能就不是最优的了。
这就导致了tcp连接网速的不稳定。
UDP的无连接
UDP协议就不同了，它不需要创建连接的过程，也就不需要提前选定途径的设备。
针对每一个单独的UDP数据包，单独选择当前最优路径，从而达到低于TCP的延时。
总体来看，当网络不稳定时，UDP转发数据，由于会选择对单个发送最优的路径，所以速度会优于TCP协议。
两者的区别
本文关注的TCP UDP之间的区别，主要是路径选择，也就是IP协议中的路由表算法，是在什么时机起作用的。
TCP协议为何高延时？每一个中间节点，都要进行IP包的排序组包，必须等待最晚的IP包到达，从而导致整条链路延时高。
UDP协议，可以做到只在最后一个接收端进行组包，中间节点只进行IP包的立即转发。从而整体延时低。
媒体服务器的设计
对比了TCP UDP的选路算法的区别，是为了利用在媒体服务器上。
媒体服务器就是转发UDP数据的RTP服务器，它的作用就相当于网络中路由器和交换机。
我们把媒体服务器设计成一个模拟IP协议的应用服务器。
地址
UDP协议由于每个包都需要单独选路，并且无连接。
中间的路由设备只根据payload是不知道应该某个包发到哪里去的。
所以每个UDP包必须携带头部信息，头部信息中最重要的是目的地址、源地址信息。
同样的我们的服务器集群中，应该定义一个地址空间。
假如地址是这样设计的：
| 目的服务器index| sessionid | userid |
| 源服务器index |sessionid | userid |
| RTP 头部 |
| UDP 头部 |
| payload |
第一行表示，目的地址，定位接收用户。
第二行表示，发送地址，定位发送用户。
- 服务器index:整个集群中某个服务器的id，从1开始
- sessionid:某服务器上某一个session的id，从1开始
- userid:某session中一个user的id，从1开始
这样的一个地址，唯一确定了某个接入的用户，在集群的哪个服务器接入，属于哪一个会议，是谁。
转发过程
用户A的地址为：1|1000|1
用户B的地址为：10|2000|2
A将UDP包发给服务器1，由于目的地址是中服务器index是10，
所以查找路由表：
路由表查询结果为 1->10: 1-->3--10
即，从服务器1到服务器10，最短路径需要经过服务器3转发。
- 服务器1将数据包转发给服务器3
- 服务器3同样的查找路由表，将数据发送给服务器10
- 服务器10，发现目的地址是自己，查找session id，再查找userid，将数据发送给用户B
路由表的维护
媒体服务器之间需要互相发送探测包，探测各个服务器之间的延时，丢包率。
将数据上报给媒体控制服务器MCS。
MCS定期计算路由表，将新路由表推送给zookeeper。
由zookeeper下发路由表到各个媒体服务器。
媒体服务器的故障
当某台媒体服务器故障时，会被探测到不可达，或主动感知到已经故障，立即在最新的路由表中删除该节点，从而不会影响后续媒体数据的转发。
增加新的媒体服务器，只需要注册选路中心MCS即可。
后续的路由表，会自动加入该节点。
优化的方向
媒体服务器的实现逻辑越靠近IP协议，转发就越有效率，服务器集群就越稳定，容灾能力就更强。
所以后续多研究IP协议的实现，对实现媒体服务器有很大的帮助。
丢包重传
媒体服务器可以对数据包进行缓存，并处理nack请求。
由于一段时间内路由表是稳定的，nack请求会已最短路径的方式，到达曾经rtp包途径的服务器，每个服务器都可以通过本地缓存处理nack。
同时，服务器之间发包应该由下一级服务器检测丢包，及时向上级请求重传。
客户端接入的服务器，也应该运行丢包检测，及时检测到丢包，并请求重传。
服务器通过及早发现丢包，及早重传包，降低重传包到达客户端的延时。
本文关键词：
webrtc 流媒体服务器 抗丢包 低延时 方案 路由表
