主流的流媒体协议，如HTTP，HLS，RTMP是TCP协议，而RTSP既可以基于TCP也可基于UDP协议进行数据传输。
从趋势来看，新的流媒体协议大都选择UDP作为底层传输协议，其主要原因和流媒体业务本身的特性及TCP特性有关。 流媒体最常见的业务直播来看，用户需要直播出流快，延时低，不卡顿，在遇到弱网的情况下，能接受损失一部分画面，但是希望能快速恢复。
1.TCP协议的局限性
首先，TCP协议握手耗时长。TCP协议建立链接需要3次握手，如要通过TLS加密则还需要4次的握手。在建立链接方面，TCP协议交互流程太多，不适合快速出流。
其次，窗口阻塞导致耗时严重。TCP协议是一个高可靠且有序的协议，因此如果出现序号较低的数据包丢了，即使序号高的已经收到了，也要等序号低的重传接收后才能使用，导致当前窗口阻塞在原地（TCP队头阻塞），要是重传的数据包也丢失，触发再次重传需要等待的时间会加倍（重传策略温和），而这个机制会影响数据的传输效率，对于实时性要求较高的流媒体业务，是不可接受的。
最后，弱网情况表现差。TCP协议的慢启动和拥塞避免算法都会大幅度的降低自身的带宽占用，从而保护整个通信链路的稳定。所以在这种策略下一旦遭遇弱网，表现出来就是直播画面卡顿，基本没有弱网对抗能力。
2.SRT协议的优缺点
SRT协议通过简单的握手、固定的延时量、ARQ（自动重传请求）、FEC（前向纠错）以及ACK、NACK等策略解决TCP协议在流媒体业务上存在的问题。
2.1. SRT如何解决握手耗时长？
SRT通过2次握手和参数交换即可快速建立起一个SRT链接（总耗时：2RTT），相比基于TCP的流媒体协议RTMP 3RTT的握手时间，总耗时减少1个RTT。
2.2. SRT如何实现可靠传输？
SRT握手结束之后，就可以发媒体数据和控制指令，媒体数据结构如下：
- 数据包序列号：数据包序号的初始值在握手时确定，之后每发一个数据包，数据包序号就会加1；
- 报文序号：报文序号从0开始，之后每发一个数据包，报文序号就会加1，报文序号前4个标志位功能如图3所示；
- 时间戳：以建立时间为基准，单位为微秒；
- 目的地端口套接字ID：在多路复用的时候可以用来区分不同的SRT流。
ACK控制指令
NAK控制指令
SRT发送端通过数据包序列号和报文序号，能明确那些数据包已经被发送出去；
SRT发送端通过接收端发送过来的ACK控制指令，就知道发送出去的哪些数据已经被成功接收了；
如果出现丢包情况，SRT发送端通过接收端发送过来的NAK控制指令，就能确定哪些数据需要重传。
通过以上方式，SRT实现了可靠传输。
2.3. SRT如何实现解决窗口阻塞问题？
从2.2的实现来看，SRT发送端必须有一个发送缓存区，SRT接收端也需要一个接收缓冲区才能实现在丢包后数据重传的机制。SRT协议通过设置固定延时量来统一规定发送缓冲区和接收缓冲区的大小。
发送缓冲区用来保存有可能需要重发的数据包，一旦数据包收到了肯定应答(ACK)，则该数据包会被清理出发送缓冲区（这点和TCP也类似），一旦发送缓冲区某个数据包一直收不到肯定应答，则该数据包在超过固定延时时间后也会被清理出发送缓冲区，SRT通过这种方式解决了TCP队头阻塞的问题。
基于以上的原理，可以看出SRT并不是完全可靠的传输协议，它的可靠性介于UDP协议和TCP协议之间。
2.4. SRT如何实现解决弱网情况表现差？
从ACK控制指令内容可以发现，ACK中带有许多网络参数，例如RTT时间等。通过RTT时间和链路带宽等参数，SRT就可以估计整个网络状态，从而实现自适应的调整。
SRT在网络较差的情况下，依然会保持较大的发送速率。因此，在弱网环境时，SRT会占用更大的网络带宽来保证流畅度。
值得注意：如果网络中都是类似于SRT这种发送策略的协议，最终可能导致谁的数据也发不出去。因此，在业务的选择上可以综合考虑SRT和TCP协议的特点，优先保证重要业务。
2.5. SRT的缺陷
虽然SRT协议有很多优势，但是有一些缺点也不容忽视。首先就是SRT协议在弱网环境，带宽占用高；其次SRT协议传输策略激进，会影响同网络下的其他用户；最后由于SRT底层是走的UDP，而防火墙对于UDP并不友好。
因此，SRT协议更适合点对点的高质量低延迟可靠传输，而不大适合对海量用户的内容分发。
