随着互联网基础设施和硬件设备的不断发展。广大直播观众对于直播观看的清晰度，延时等方面的体验要求越来越高，直播也随之进入了低延迟高码率的时代，直播传输技术也面临着越来越高的要求和挑战。
腾讯视频云为此在全链路上针对流媒体传输不断深入优化，使得在各大重要赛事上具备了高可靠、低延迟、高画质和音质的需求，同时跟客户，比如斗鱼，深沉次合作，不光在服务端，在APP端也进行了SRT的合作，和赛事一样从源头上保证稳定。
在直播过程中因网络丢包，会造成各种丢帧，会造成各端卡顿甚至花屏，给观众造成很不好的观看体验，针对链路丢包，SRT是如何解决的呢？
SRT采用的是ACK+ NACK的解决方案。每隔10ms，SRT接收方会发送一个"正常"ACK包，将当前接收buffer中连续的最大包序号告诉发送方，发送方收到"正常’ACK包后，会确认数据，将发送窗口前移，同时发送ACKACK，接收方依据T(ackack) - T(ack)来计算链路rtt。对于高码率的链路，每10ms确认一次可能会不及时，为此，SRT每收到64个包，便会额外回复一个LITEACK，用来快速确认数据，尽可能快的让发送窗口移动。
每次收包时，SRT会计算当前的"乱序度"。举个例子，如下图所示：
上图当前时刻的"乱序度"为2，当发现丢包需要重传时，SRT会延迟2个包发送NACK，用来减少一部分因为UDP乱序导致的无效重传。
众所周知，TCP一个窗口内的数据包通常会一次性无间隔的发送，容易造成流量突发。Pacing机制通过平滑发送间隔，来防止该问题。
SRT是根据带宽评估来调整发送间隔的。可以从输入的速率采样，或者由用户设置最大带宽(maxBW)，并留出一部分重传带宽(overheadBW)，两者之和作为最大的传输速率。
如上图所示，若maxBW为800Kbps，overheadBW为200Kbps，链路最大带宽限制为1Mbps，按每个包大小1Kb计算，SRT会按照1ms的间隔平滑发送。
基于以上特性，腾讯视频云将SRT作为传输层之上的协议，可以将任何基于tcp的应用层协议改造为基于SRT的应用层协议，腾讯和斗鱼一起选择rtmp over SRT尝试在APP端应用SRT，针对弱网主播进行源头的优化。
在斗鱼户外版块首次尝试使用SRT后，RTMP推流和SRT推流对比如下：
某长期丢包的户外主播，打开SRT开关后，推流，播放的卡顿如下：
