都是之前对QUIC调研的一些记录！
TCP协议的缺陷：
*TCP有内嵌的重传策略ARQ，但不允许开发者对ARQ策略进行控制，也没有FEC，不能实现FEC；
*TCP需要进行三次握手才能建立连接，具有一定的连接等待时延，如果用了TLS加密，还会有其他的步骤，进一步增加时延；
*TCP采用重传机制，而QUIC采用纠错机制。单流情况下如果发生丢包的话，TCP首先需要一个等待延时来判断发生了丢包，然后再启动重传机制，在此期间会对连接造成一定的阻塞；
*普通基于TCP连接，是基于两端的IP和端口和协议来建立的。在网络切换场景，例如手机端切换了无线网，使用4G网络，会改变本身的IP，这就导致TCP连接必须重新创建；
*TCP重传segment的SequenceNumber和原始的segment的SequenceNumber保持不变，也正是由于这个特性，引入了TCP重传的歧义问题；
*TCP协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、修改滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击；
*TCP协议栈通常由操作系统层面内核来实现，例如Linux、Windows、iOS、Android操作系统。除非所有的服务器和客户端的操作系统都能支持，并且都更新到能支持的版本才行。所以可能这辈子都不行，就像HTTP1也支持单连接承载多请求但还没有哪个浏览器支持的；
*TCP不是从实时语音视频的角度进行设计的，更多是考虑网络传输的公平性，内嵌的传输控制策略比较温和（中庸）；
*RTMP基于TCP协议，而TCP是通用的IP网络协议，不是为实时媒体传输而设计的，在弱网环境下延迟会增大；
UDP协议的特点：
*UDP协议是无连接方式的协议，所以它的效率高，速度快，占资源少；
*UDP与TCP协议相比更为轻量，但是错误校验也要少得多，这意味着UDP往往效率更高；
*UDP适合实时语音视频通讯，允许端到端全链条进行信道策略控制（FEC、ARQ、ABCetc.），在弱网环境下可控性更强；
*UDP的延迟时间的大小取决于丢包时候的ARQ和FEC策略，在实际开发中，允许开发者深度控制ARQ和FEC策略；
*UDP是适合用来设计实时语音视频的通讯机制，根据网络状况自适应地选取ARQ和FEC策略，以及调整传输码率和报文的数量；
Http2缺点：
*Http2存在segment队头阻塞和TLS层面的队头阻塞；
*Http2在传输层仍然遇到了一些问题，没办法有效地利用网络传输，我们需要一个协议用更少的延迟和更少的重传时间消耗去传递请求，减少因丢包造成的队首阻塞，然而又要保证安全性，QUIC在这种背景下诞生了；
*Http2的限制，在我看来就像排队过关，纵使开了再多的队列，最终过关速度，也还是受审核员的制约，而TCP就像那审核员；
总结RTMP（TCP）和UDP对网络好坏的依赖：
*在网络环境好的情况下，只要语音视频编解码器相同，RTMP协议和基于UDP的私有协议的传输效率是相当的，都可以实现低延迟、低卡顿和高品质的实时通讯效果；
*在网络环境较差的情况下，特别是在跨网，甚至跨国的情况下，基于UDP的私有协议对端到端全链条可控，包括流控、码控、ARQ、FEC和抖动缓冲等，对抗恶劣网络环境会更有保障；
QUIC简介：
*QUIC是QuickUDPInternetConnection的简称
*谷歌制定的一种基于UDP的低时延的互联网传输层协议，位于应用层（Http）和网络层（UDP）之间
*开源于Chromium项目中
QUIC总体特点：
*为了实现传输的可靠性，它基本上实现并且改进了整个TCP协议的功能，包括序列号，重传机制，拥塞控制，流量控制等；
*为了实现传输的并发性，它又实现了Http2的大部分特性，包括多路复用，流量控制，优先级等等；
*QUIC是部署在客户端级别，而不是在操作系统内核级别，这样就能以更快的速度进行迭代，其迭代周期由（TCP）以年计算加速为以周计算。适合快速迭代的移动端开发；
*QUIC能够处理传输可靠性、丢包、无序数据包等一系列UDP默认未处理的问题，使之适合移动音视频的应用；
QUIC协议优点：
1）多路复用传输-无队头阻塞：
*QUIC拥有Connection和Stream两种流量控制，在一条Connetion上会同时存在多条Stream流。可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性；
*QUIC使用基于UDP的多路传输协议（单连接下）来传输数据，所以当其中一个数据流丢包时，其他的通道并不会因此阻塞等待丢失的数据包。QUIC的方法解决了TCP传输的线端阻塞问题；
*QUIC最基本的传输单元是Packet，不会超过MTU的大小，整个加密和认证过程都是基于Packet的，不会跨越多个Packet。这样就能缓解TLS协议存在的队头阻塞问题；特别是在传输大量数据是，比如视频、直播流，受队头阻塞的影响很小；
*QUIC拥有没有队头阻塞的多路复用：QUIC的多路复用和Http2类似。在一条QUIC连接上可以并发发送多个Http请求(stream)。但是QUIC的优势在于，一个连接上的多个stream之间没有依赖。这样假如stream2丢了一个udppacket，也只会影响stream2的处理。不会影响stream2之前及之后的stream的处理；
2）零往返时间连接-无握手、秒开：
*零往返时间连接（0RTT）技术是等待时延优化，使得QUIC拥有极低的等待时延（相比于TCP的三次握手）；
*0RTT是指，如果双方此前通信过的话，那么在客户端和服务器下次连接时不需要握手步骤；
3）连接转移-无感网络切换：
*QUIC的连接不再以IP及端口四元组标识，而是以一个64位的随机数作为ID来标识每一次连接，这样就算IP或者端口发生变化时，只要ID不变，这条连接依然维持着，上层业务逻辑感知不到变化，不需要重新握手，不会中断，也就不需要重连，继续传输数据。对移动端WiFi、4G各种复杂的网络环境，比较友好，特别适合移动端音视频传输！（比如大家使用公共NAT出口时，有些连接竞争时需要重新绑定端口，导致客户端的端口发生变化，此时如果是TCP，则需要重新建立连接！）；
*QUIC通信通道的定义基于ID而不是IP+端口，这使得切换网络后继续转发连接成为可能，在IP地址和端口变化的情况下，可以无需重新建立连接，继续通信。对移动设备的用户体验较为友好；
4）加密技术-盗链、盗播、劫持：
*QUIC在安全性上，拥有与TLS等效的加密措施，且推动了TLS1.3的发展；
*QUIC对SSL证书进行压缩，减少了证书传输量，且针对包头进行验证。有利于音视频秒开；
*QUIC对每个散装的UDP包都进行了加密和认证的保护，并且避免使用前向依赖的处理方法（如CBC模式），这样每个UDP包可以独立地根据IV进行加密或认证处理；
*QUIC的packet可以说是武装到了牙齿。除了个别报文比如PUBLIC_RESET和CHLO，所有报文头部都是经过认证的，报文Body都是经过加密的。这对音视频安全性更有保障；
*QUIC采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效；
5）向前纠错-减少ARQ、无卡顿：
*QUIC采用前向纠错（FEC）方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。具体实现类似于RAID5，将N个包的校验和（异或）建立一个单独的数据包发送，这样如果在这N个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性。完全不需要重传，有利于保证高速性，N可以根据网络状况动态调整；
*在重要的包，比如握手消息发生丢失时，能够根据冗余信息还原出握手消息，提升握手成功率，这对提升直播秒开成功率有帮助；
6）自适应拥塞控制-降低丢包、流畅：
*QUIC拥有完善的数据包同步机制，在应用层做了很多网络拥塞控制层面的优化，能有效降低数据丢包率，这有助降低复杂网络下的直播卡顿率，提高流畅度；
*QUIC拥有“自适应”拥塞控制（对TCP友好），有效减少移动客户端重新连接的次数，对移动直播有利；
*QUIC应用程序不需要停机和升级，就能实现拥塞控制的变更，我们在服务端只需要修改一下配置，reload一下，完全不需要停止服务就能实现拥塞控制的切换；
*QUIC的数据段落编号，使用PacketNumber代替了TCP的sequencenumber，并且每个PacketNumber都严格递增，也就是说就算PacketN丢失了，重传的PacketN的PacketNumber已经不是N，而是一个比N大的值。这使得它的重传没有歧义性（对比TCP）；
*QUIC的流量控制，是通过window_update帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。通过BlockFrame告诉对端由于流量控制被阻塞了，无法发送数据；
*QUIC具有热插拔特性，可以针对不同业务，不同网络制式，甚至不同的RTT，使用不同的拥塞控制算法；
*不允许Reneging：一个Packet只要被Ack，就认为它一定被正确接收，减少重传干扰；
*更多的Ack块：QuicAckFrame可以同时提供个AckBlock，在丢包率比较高的网络下，更多的SackBlock可以提升网络的恢复速度，减少重传量；
*QUIC算上了服务端的AckDelay时间，从而拥有更准确的RTT；
信道保护各种技术：
*根据网络环境采用合适的QoS信道保护技术，采用“向前保护”FEC、“丢包重传”ARQ、“码率自适应”ABC-多管齐下；
*使用FEC编码算法的时候要根据丢包率（PLR,PacketLostRate）来设置冗余度；
*使用前向纠错FEC算法，优点是数据包只需要传输一次，传输延迟不会受到RTT(RoundTripTime)的影响，不会增加额外的延迟时间；缺点是需要增加冗余数据包，降低了传输信道的利用率。总的来说是一种“空间换时间”的策略；
*具体地来说，发送端给每一个数据包都植入顺序号码和时间戳，顺序号码代表被发送数据包的顺序，允许接收端可以通过监测顺序号码来发现丢包事件；发送端维护一个缓冲队列，当收到重传请求的时候将会重传数据包。接收端也会维护一个缓冲队列，等待尚未收到的数据包以及对已经收到的数据包进行排序；
*ABC全称AdaptiveBit-rateControl，中文意译为码率自适应，是服务端和推流端协作控制码率来自动适应网络环境变化的技术。码率自适应的目的是为了对抗弱网环境。在网络好的情况下，适当提高码率，提高语音视频的质量和降低延迟；在网络差的情况下，适当降低码率，保障语音视频通话的可用性和流畅性，适当牺牲音画质量；
QUIConWeb的一些数据：
*QUIC的优势非常明显，即使在元素比较少（12个元素）的情况下，相比HTTP也能提升9%，相比HTTP2提升42%，相比HTTPS提升52%；
*在页面元素增多的情况下，QUIC的优势就更加明显，相比HTTP提升36%，相比HTTP2提升47%，相比HTTPS提升64%；
*QUIC请求的首字节时间（rspStart）比Http2平均减少ms，性能提升约25%，这主要得益于QUIC的0RTT和1RTT握手时间，能够更早的发出请求；
*另外QUIC请求页面加载完成的时间（loadEnd）平均减少2s，由于整体页面比较复杂，很多其它的资源加载阻塞，导致整体加载完成的时间比较长约9s，性能提升比例约22%；
QUIC缺点：
*QUIC协议非常复杂，甚至比Http2更复杂，因为它做了太多事情。客户端实现起来比较复杂；
*为了对抗DDoS，一般防火墙都严格过滤UDP，一定程度上限制了UDP在广域网的发展；
*QUIC需要在包头打入流ID（flowid），这个特性可能会使不少场景无法使用QUIC；
QUIC实现时还需优化的地方：
*“如何提升0RTT成功率”：需要实现ServerConfigID进程间共享和分布式集群的Cache，即使用全局公共缓存；
*“减少服务端本地的CPU消耗量”：对ServerConfig的内容签名和校验（RSA、ECDSA签名）等，使用SSL硬件加速卡集群，对加密签名的计算，进行异步代理；
*“实现连接迁移”：QUICConnectionID-同一台服务器保存了相同的Stream及Connection处理上下文，能够将该请求继续调度到相同业务的机器，这个需要开发功底；
*“动态的拥塞控制算法”：在实际应用中，需要对线上使用情况进行很多的变量统计和分析，包括0RTT握手成功率、握手时间、密码套件使用分布，QUIC协议的版本，stream并发数量等等等等。根据这些数据进行流量的动态控制；
QUIC与直播推流：
1）直播痛点-卡顿
*卡顿是最影响直播体验的因素之一，也是最难解决的问题之一。在流媒体的传输链路中，任何一个环节丢包都可能导致用户观看卡顿；
*主播端的推流卡顿最影响观看体验，会直接影响到所有观看直播的最终用户。主播推流卡顿在部分场景会特别显著，比如户外直播就非常考验在网络状况复杂的情况下推流的稳定性；
*QUIC的众多特性，都仿佛是专门为了解决卡顿而存在！
2）QUIC是什么？为什么可以减少卡顿？
*QUIC传输层基于UDP协议，但却是一种可靠的传输协议，因为它将很多可靠性的验证策略从系统层转移到应用层来做，这样可以使用更适合现代流媒体传输的拥塞控制策略；
*使用QUIC改善直播体验，就是用它来代替直播中TCP协议所扮演的角色
References：
QUIC协议初探-iOS实践-