背景
在一些业务场景中传输层需要通过UDP协议传输数据，如点播和下载P2P业务，通过P2P打洞成功后，需要在应用层实现一套传输库，最终通过UDP协议传输数据。一些对实时性要求很高的直播业务，为了保证实时性也是通过UDP协议传输数据，并且在应用层实现一套传输库。这些传输库针对不同的业务有不同的特点，有的要保证传输完全可靠，有的要保证传输尽量可靠但是实时性要高。
主流开源传输库
目前网上开源的一些传输库主要有WebRTC、Quic、UDT、KCP、Enet等，其中WebRTC不能算严格意义的传输库，只能说WebRTC包含传输部分的模块，并且传输模块还耦合了其他功能，不能或者很难抠出传输那部分代码，然后用于非WebRTC项目。Quic可以说是目前很多国内外大厂研究比较多的传输库，包括微软有msquic，阿里有xquic，快手有kQuic，另外腾讯、B站、小米等公司也都有基于Quic进行自研，而且在一些秒开场景收益较高。
怎样判别好坏
在自己"造轮子"之前，我们首先需要知道目前开源的这些传输库都有哪些优点和缺点，哪些是比较好的传输库，我们需要多学习这些好的开源传输库一些优秀的设计思想。那么我们怎样判别一个传输库是否是一个优秀的传输库呢？或者说我们怎么知道一个传输库是否满足自己的业务需求呢？
简单来说就是需要对这些传输库分内网环境和公网环境进行测量，统计一些指标(如带宽利用率、数据延迟、吞吐率等)，并且横向和其他传输库进行对比。也许网上已经有这些传输库的一些优缺点总结，但是由于版本或者一些测试场景原因，还是需要自己单独对这些传输库进行测量和对比，因为测量过程中会遇到各种各样的问题，在这个过程中你会对这些传输库的一些技术细节和功能特点更加印象深刻。下面是我总结的一些传输库的特点：
其中：
（1）最关键的是核心收益场景和优缺点
（2）WebRTC的RTP传输会跟jitterbuffer模块进行紧密配合(这块后面再单独写篇文章讲解下)
要不要自研？怎样自研？
在自研前首先需要明白自研的目的是干什么？目前开源的那些传输库是否无法满足目前业务技术指标？如果满足不了，是不是可以基于这些开源库做些定制的修改，保证最终满足一些业务指标。如果最后发现还是要自研，则个人建议可以从下面一些方向出发：
其中：
（1）有效吞吐术语为goodput，举个具体的场景：比如某传输库统计的丢包率为0.1%，但是重传率为5%，重传率比丢包率大太多，相当于一些没有丢包的数据由于误判为丢包，最终导致重传的数据较多，重传误判的数据浪费了部分带宽，这部分带宽不属于有效吞吐。另外还有数据包头大小、Mss 也影响goodput，Mss越小，每次传输包的大小越小，可能本来只需一个传输包传输的数据，要分成多个传输包传输。传输的协议头越大，浪费的带宽也越大，有效吞吐也就越低了(有效吞吐具体是在接收端应用层统计，统计每秒接收了多少数据)
（2）收敛速度：表示增加或者减少到最优带宽的速度。具体场景为当带宽增加时，如果是一个优秀的传输库，可能会及时检测到当前网络带宽有增加，最终会及时占用更多的网络带宽，从而保证一个高的带宽利用率。当带宽减少时，可以及时降低发送速率和发送数据量，最终快速收敛到一个较公平的发送速度
总结
总的来说，自研一套传输库难度是相当大的，需要研发人员有相当扎实的网络功底，而且最后还不一定能够达到预期收益，所以自研前需要做足功课，尽量将一些风险点在前期排除。
附录
www.livevideostack.cn/news/quic-2
