共计 987 个字符，预计需要花费 3 分钟才能阅读完成。
随着互联网基础设施和硬件设施的一直倒退。宽广直播观众对于直播观看的清晰度，延时等方面的体验要求越来越高，直播也随之进入了低提早高码率的时代，直播传输技术也面临着越来越高的要求和挑战。
腾讯视频云为此在全链路上针对流媒体传输不断深入优化，使得在各大重要赛事上具备了高牢靠、低提早、高画质和音质的需要，同时跟客户，比方斗鱼，深厚次单干，不光在服务端，在 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 开关后，推流，播放的卡顿如下：
