QUIC协议

既生瑜，何生亮？

QUIC的特性

• 提供可靠传输
• 减少连接建立的时间
• 改善拥塞控制
• 多路复用
• 转发错误连接
• 连接移植

TCP的特性

TCP的主要特性是提供面向连接的服务,数据传输前需要进行三次握手，利用重传与确认机制来保证数据的正确到达对端

UDP的特性

UDP的主要特性是面向无连接的服务,不需要确认对端是否存活,直接进行数据的发送,不能保证数据正确到达,因为不需要进行握手和确认,传输速度特别快

HTTP2的特性

• HTTP2采用二进制格式传输数据，而HTTP1使用文本格式
• HTTP2对头部采用HPACK进行数据压缩
• Server Push：服务器主动把css和js推送给客户端
• 多路复用：HTTP1.1里面也采用了连接复用，但是一个链路在一段时间内只能被一个请求占用(下一个请求要使用该链路必须等到上一个应答到来)，但是HTTP2中解决了这个问题，可以使用多个请求同时使用该连接(一个请求发出后下一个请求可以接着发)
  支持优先级传输

QUIC的架构

我们可以看到QUIC是集大成者,它底层使用了UDP协议提高了数据传输的速度,同时它吸收了TCP的特性来提供可靠传输,容纳了HTTP2的一些特性

QUIC中的握手

QUIC既然要提供可靠服务,则需要向TCP协议一样进行握手来验证对端的存在性。下面是client与server握手的过程(从Client角度来看整个握手过程)

如果client没有访问过server则会发送CHLO[client hello]给server，此后进行一些安全方面的操作,然后重新访问server；如果client以前访问过server,则server会发送SHLO给client,则表示握手成功
握手过程的详细说明 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#

QUIC中的拥塞控制

QUIC中的拥塞控制采用TCP Cubic拥塞控制算法

多路复用问题

在HTTP2中多个请求可以使用同一条TCP连接,但是会出现前向包拥塞问题，即第一请求在被发送的过程中出了包丢失，后续的HTTP请求将会被阻塞，直到包丢失问题被解决后(第一个HTTP请求被发送完毕)，后续的HTTP请求才能被写到TCP流中。QUIC底层使用UDP协议天然的解决了这个问题,因为UDP协议不会拥塞。即假如第一HTTP请求中发生了包丢失，QUIC还是会继续发送后面的HTTP请求,直到某一时刻发现第一个HTTP请求中出现了包丢失问题，这时回头解决包丢失问题

连接移植

在TCP连接中，一个链接是由源IP+源端口+目的IP+目的端口来标识的，当其中的一个发生变化，则意味着是一条新的连接,这时需要进行三次握手重新建立连接
但是在QUIC中一个连接的由64bit标识码来标识的,这个标识码是由客户端随机产生。这就意味着你在上网时可以在wifi和4G中无缝切换，而不用重新去建立连接

参考博客

http://www.cnblogs.com/awiki/articles/5174306.html
http://www.oschina.net/news/77135/quic-google-protocol-web-platform-from-tcp-to-udp
https://github.com/devsisters/libquic