一、引言
既然UDP天然适合流媒体场景，为什么还存在TCP的流媒体协议？UDP的实时性，低延迟，又支持组播，确实适合音视频场景，但由于UDP是不稳定不可靠传输技术，直接用它来传输音视频，在实际网络中拥塞，丢包等情况会导致大量的音视频丢包，甚至视频和音频关键帧丢失导致客户端无法解码。如果将UDP用在流媒体传输中，需要自己完成很多可靠性工作。即TCP中做的可靠性工作，都需要在UDP上层根据业务情况适当实现（注意不是照搬，是适当实现，允许少了丢包，增强可靠性）。
流媒体基本框架
二、UDP可靠性开发工作
根据笔者实际工作经验，UDP应用在流媒体传输场景可能要做以下工作：
1）乱序重排
UDP由于面向是无连接的，各个包的路由路径不一样，收到包，不一定保序，发送端在应用层要加入序列号，接收端要根据接收数据的应用层序列号就行重排。典型的RTP协议的序列号就可以用来排序
2）丢包重传（ARQ）
由于网络拥塞，或者带宽不足，或者网络设备故障，或者无线信号衰减，或者系统socketbuffer 溢出等都可能导致丢包。大量的丢包必然导致视频卡顿，甚至参考关键帧丢失而无法解码，故在应用层再次请求发送端重传。重传技术中RTO（重传超时时间）非常关键，RTO太大，导致重传太慢，RTO太小，导致正常报还没有到，就触发无效重传，通常是根据RTT（一个连接的往返时间)探测，预估RTO的值，
3）前向纠错（FEC）
由于重传可能也会带来网络拥塞，加剧网络丢包，所以重传次数是有限的。甚至如果能够FEC纠错的话，优先采用纠错。但前向纠错能力是有限的，多个连续丢包是无法纠错的。通常FEC和丢包重传结合使用。
4）拥塞控制
如果网络拥塞，如不加以拥塞控制，网络拥塞会更加剧烈，甚至传输瘫痪。tcp有拥塞窗口技术来实现拥塞控制，UDP媒体传输通常根据根据网络状态（基于丢包率，或延时），或者接收buffer，进行降帧率，降低码率，甚至自动降低分辨率，减少数据传输，进而减少网络拥塞。
5）流量控制
在TCP传输中有TCP的滑动窗口保证网络流量。UDP传输完全是尽力传输。在适当时候，发送端同样要根据实际情况做码率控制。常见做法根据音视频时间戳控发送速度，根据流媒体的码率控制发送速度等。
以上开发工作根据业务场景实现，乱序重排和丢包重传是常规做法的。更进一步做法是引入FEC，拥塞控制，流量控制，多手段结合，增强系统的弱网适应性。
三、总结
由于网络环境的复杂和多变，以上工作需要大量的人力和技术投入。所以传统流媒体技术对延迟要求不高或者可以接收一定的延迟直接采用TCP承载（如http族流媒体，RTMP等），一方面可以节省人力和技术投入 二方面可以直接服用传统的tcp技术（如web服务技术）。实际应用tcp 在带宽足够，网络状态良好的环境体验良好，但在弱网环境体验就非常糟糕。由于tcp传输的严谨性，协议栈参数有限可调的局限性，延迟和拥塞几乎导致视频通话中断或音视频卡顿频繁，后面将进一步针对UDP可靠性传输做进一步总结。
