QUIC协议

QUIC协议1.什么是QUICQUIC是quickudpinternetconnection的简称，是由Google提出的使用udp进行多路并发传输的协议。该缩写后被国际互联网工程任务组(IETF)定义为专用的名词来命名该协议。QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。2.为什么使用QUIC搜狐SDK组内部测试结果比较七牛云直播测试结果比较从测试效果来看，使用QUIC协议的网络请求要明显好于基于TCP协议的网络请求。腾讯相关测试数据：1.在元素比较少（12个元素）的情况下：相比HTTP也能提升9%，相比HTTP2提升42%，相比HTTPS提升52%；2.在页面元素增多的情况下：QUIC的优势就更加明显，相比HTTP提升36%，相比HTTP2提升47%，相比HTTPS提升64%。YouTube的视频服务上应用数据：用户报告通过QUIC协议在观看视频的时候可以减少30%的重新缓冲时间。3.现有网络环境的问题从互联网开始兴起一直到现在，大部分的互联网流量传输只使用了几个网络协议。使用IPv4进行路由，使用TCP进行连接层面的流量控制，使用SSL/TLS协议实现传输安全，使用DNS进行域名解析，使用HTTP进行应用数据的传输。虽有一些改进，但进展缓慢。如下几个由来已久的问题和矛盾就变得越来越突出：1.协议历史悠久导致中间设备僵化；2.依赖于操作系统的实现导致协议本身僵化；3.建立连接的握手延迟大；4.队头阻塞。4.QUIC核心特性4.1连接建立延时低0RTT建连可以说是QUIC最大的性能优势.HTTPS及QUIC建连过程由于QUIC建立在UDP的基础上，同时又实现了0RTT的安全握手，所以在大部分情况下，只需要0个RTT就能实现数据发送0-RTT握手过程QUIC握手的过程是需要一次数据交互，0-RTT时延即可完成握手过程中的密钥协商，与TLS相比效率提高了5倍，且具有更高的安全性。QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。具体握手过程如下：(1)客户端判断本地是否已有服务器的全部配置参数，如果有则直接跳转到(5)，否则继续(2)客户端向服务器发送inchoateclienthello(CHLO)消息，请求服务器传输配置参数(3)服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数(4)客户端收到REJ，提取并存储服务器配置参数，跳回到(1)(5)客户端向服务器发送fullclienthello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数，可以计算出初始密钥。(6)服务器收到fullclienthello，如果不同意连接就回复REJ，同(3)；如果同意连接，根据客户端的公开数计算出初始密钥，回复serverhello(SHLO)消息，SHLO用初始密钥加密，并且其中包含服务器选择的一个临时公开数。(7)客户端收到服务器的回复，如果是REJ则情况同(4)；如果是SHLO，则尝试用初始密钥解密，提取出临时公开数(8)客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥(9)双方更换为使用会话密钥通信，初始密钥此时已无用，QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似，只是数据包中的某些字段略有不同。4.2改进的拥塞控制QUIC协议当前默认使用了TCP协议的Cubic拥塞控制算法[6]，同时也支持CubicBytes,Reno,RenoBytes,BBR,PCC等拥塞控制算法。但也对多方面进行了改进，改进的方面有：1.可插拔，能够非常灵活地生效，变更和停止；2.单调递增的PacketNumber，避免了重传时产生的歧义性；3.不允许Reneging，减少数据重传产生的干扰；4.更多的Ack块，减少重传量。5.AckDelay时间。计算RTT更加精准。4.3基于stream和connecton级别的流量控制QUIC的流量控制类似HTTP2，即在Connection和Stream级别提供了两种流量控制。为什么需要两类流量控制呢？主要是因为QUIC支持多路复用。Stream可以认为就是一条HTTP请求。Connection可以类比一条TCP连接。多路复用意味着在一条Connetion上会同时存在多条Stream。既需要对单个Stream进行控制，又需要针对所有Stream进行总体控制。QUIC的流量控制和TCP有点区别，TCP为了保证可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的Segment，窗口也无法超过这个序列号。但QUIC不同，就算此前有些packet没有接收到，它的滑动只取决于接收到的最大偏移字节数。4.4没有队头阻塞的多路复用QUIC的多路复用和HTTP2类似。在一条QUIC连接上可以并发发送多个HTTP请求(stream)。但是QUIC的多路复用相比HTTP2有一个很大的优势。QUIC一个连接上的多个stream之间没有依赖。这样假如stream2丢了一个udppacket，也只会影响stream2的处理。不会影响stream2之前及之后的stream的处理。这也就在很大程度上缓解甚至消除了队头阻塞的影响。HTTP2在一个TCP连接上同时发送4个Stream。其中Stream1已经正确到达，并被应用层读取。但是Stream2的第三个tcpsegment丢失了，TCP为了保证数据的可靠性，需要发送端重传第3个segment才能通知应用层读取接下去的数据，虽然这个时候Stream3和Stream4的全部数据已经到达了接收端，但都被阻塞住了。不仅如此，由于HTTP2强制使用TLS，还存在一个TLS协议层面的队头阻塞。4.5加密认证的报文TCP协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。但是QUIC的packet可以说是武装到了牙齿。除了极个别报文，所有报文头部都是经过认证的，报文Body都是经过加密的。这样只要对QUIC报文任何修改，接收端都能够及时发现，有效地降低了安全风险。4.6连接迁移一条TCP连接是由四元组标识的（源IP，源端口，目的IP，目的端口）,手机在WIFI和4G移动网络切换时，客户端的IP肯定会发生变化，需要重新建立和服务端的TCP连接。而QUIC连接不再以IP及端口四元组标识，而是以一个64位的随机数作为ID来标识，这样就算IP或者端口发生变化时，只要ID不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连。4.6前向冗余纠错此外，QUIC还能实现前向冗余纠错，在重要的包比如握手消息发生丢失时，能够根据冗余信息还原出握手消息。减少重传的次数。