基于UDP的新一代多路传输协议—QUIC（二）

本文承接  基于UDP的新一代多路传输协议—QUIC（一）

QUIC核心技术

QUIC能够处理传输可靠性、丢包或无序数据包等一系列UDP默认未处理的问题。

1.   多路复用

QUIC的多路传输指协议使用多个通道传输数据，所以当其中一个数据流丢包时，其他的通道并不会因此阻塞等待丢失的数据包，而这会发生在SPDY上，因为SPDY虽然是多路传输但是只有一个通道。Shade说，QUIC的方法解决了TCP传输的线端阻塞问题。

图  1 SPDY 的多路传输

 

 图 2 SPDY数据丢包时阻塞

图 3 QUIC的多路传输

 

 图 4 QUIC数据丢包时不阻塞

 类似于SCTP的多流设计，可以通过一个连接同时进行多个请求，不必等待上一个请求返回浪费时间，也不必同时建立若干个连接浪费资源。

   另外单流情况下若发生丢包则会有等待重传阻塞，影响整个连接的传输速度。  

2.   等待时延（Latency）

以往典型的安全TCP连接(TCP+TLS)往往需要在发送与接收端先进行2、3轮的握手通信才能正式开始数据传输。而使用QUIC的一个主要优势是如果双方此前通信过的话在客户端和服务器首次连接时不需要握手步骤，某种程度上与TCP快速开启（TCP Fast Open）类似。TCP快速开启在2011年面世，但是目前尚没有大范围使用。根据Shade的说法，采用TLS时，在一次跨大西洋的连接中TCP握手要耗时300ms，而QUIC可以将延迟降为100ms。即便双方此前未通信过时延也只有100毫秒，是TCP+TLS用时的1/3。

当被问到为什么不使用TCP+TLS，Shade解释说，虽然TCP和TLS持续升级，但协议的迭代及部署非常慢，而QUIC是部署在客户端级别，而不是在内核级别，这样就能以更快的速度进行迭代，迭代周期由以年计算加速为以周计算。

根据Shade的介绍，将来SPDY能够运行在QUIC之上，使其比现在更好。将来Google实际使用QUIC的经验和教训可以合并到TCP中。

3.   加密技术

可媲美TLS的隐私数据保证（不需要按顺序的传输或按顺序的解密），QUIC对每个散装的UDP包都进行了加密和认证的保护，并且避免使用前向依赖的处理方法(如CBC模式)，这样每个UDP包可以独立地根据IV进行加密或认证处理。

QUIC采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效。

详情可参见(中文)http://blog.csdn.net/this_capslock/article/details/42006801和(英文文档) https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pli=1

4.  前向纠错

QUIC和TCP一个主要的核心区别就是：TCP采用重传机制，而QUIC采用纠错机制。

如果发生丢包的话，TCP首先需要一个等待延时来判断发生了丢包，然后再启动重传机制，在此期间会对连接造成一定的阻塞（并且TCP窗口是缓慢增大的，Web这种突发性快速连接情况下窗口会相对较小），从而影响传输时间。

而QUIC采用了一种脑洞极大的前向纠错（FEC）方案，类似于RAID5，将N个包的校验和（异或）建立一个单独的数据包发送，这样如果在这N个包中丢了一个包可以直接恢复出来，完全不需要重传，有利于保证高速性，N可以根据网络状况动态调整。

5.   连接保持

QUIC通信通道的定义基于ID而不是IP+端口，这使得切换网络后继续转发连接成为可能，在IP地址和端口变化的情况下（比如从Wi-Fi切换到流量），可以无需重新建立连接，继续通信。对移动设备的用户体验较为友好。

6. 启用实验性QUIC协议

在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。

 

刚开始这样做的时候可以绕过墙，但现在我对Chrome进行设置时，发现已经不能绕过墙了。查了一些资料，有人说有可以是当时墙方的人员还没有抓利用此协议越狱的解决方案的数据包。

7.  QUIC优点

?  拥有SPDY的所有优点（多路传输，支持优先级，等等）

?  零往返时间连接

?  数据包同步，有效降低数据丢包率

?  向前纠错

?  自适应拥塞控制（对TCP友好），有效减少移动客户端重新连接的次数与TLS等效的加密措施

?  Chrome支持与Google的QUIC通信

7 QUIC不足

?  QUIC需要在包头打入flowid，这个特性会使很多场景无法使用QUIC

?  为了对抗DDos，一般防火墙都严格过滤UDP。

谷歌表示，TCP的支持往往是直接内置到操作系统内核，谷歌没有任何控制权，QUIC可以让谷歌来测试和试验新的想法，谷歌希望如果QUIC被证明有效，那么其功能将很快会迁移到TCP和TLS。谷歌还表示，它计划向IETF提交基于QUIC的HTTP2作为未来一个新的互联网标准。