QUIC协议学习记录

   QUIC(Quick UDP Internet Connections，快速UDP互联网链接)是Google提出的一种基于UDP改进的通讯协议，其目的是下降网络通讯的延迟，提供更好的用户互动体验。

    QUIC的主要特色包括：具备SPDY(SPDY是谷歌研制的提高HTTP速度的协议，是HTTP/2.0的基础)全部的优势；0-RTT链接；减小丢包；前向纠错，减小重传时延；自适应拥塞控制， 减小从新链接；至关于TLS加密。

    有关QUIC的详细资料能够参考http://www.chromium.org/quic里的相关文档和代码。

    1.重传与恢复

     与TCP相似，QUIC每发送一个包后，都会等待回复一个确认包。当丢包率超过协议的纠错门限时，会显式或隐式地进行重传

    对于某些重要的数据包，如初始密钥协商时的数据包，在创建链接时很是重要，若是这类包丢失会阻塞总体数据流。QUIC对于这一类数据包在确认发生丢失前就会尝试重传，一般是等待较短的时间(如20ms)没收到确认后就立刻再次发送。这样在网络中会有若干个相同的包同时传输，只要有一个能成功抵达就完成了链接，这样下降了丢包率。接收方对于关键数据包的屡次发送和普通数据包的超时重传，都采用相同的重复包处理机制

     QUIC在拥塞避免算法的基础上还加入了心跳包，用于减小丢包率

     QUIC使用了FEC(前向纠错码)来恢复数据，FEC采用简单异或的方式。每次发送一组数据，包括若干个数据包后，并对这些数据包依次做异或运算，最后的结果做为一个FEC包再发送出去。接收方收到一组数据后，根据数据包和FEC包便可以进行校验和纠错。

    2.安全性

    QUIC对每一个散装的UDP包都进行了加密和认证的保护，而且避免使用前向依赖的处理方法(如CBC模式)，这样每一个UDP包能够独立地根据IV进行加密或认证处理。

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

    3. 0-RTT握手过程

    QUIC握手的过程是须要一次数据交互，0-RTT时延便可完成握手过程当中的密钥协商，比TLS相比效率提升了5倍，且具备更高的安全性。

    QUIC在握手过程当中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。

    具体握手过程以下：

    (1) 客户端判断本地是否已有服务器的所有配置参数，若是有则直接跳转到(5)，不然继续

    (2) 客户端向服务器发送inchoate client hello(CHLO)消息，请求服务器传输配置参数

    (3) 服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数

    (4) 客户端收到REJ，提取并存储服务器配置参数，跳回到(1) 

    (5) 客户端向服务器发送full client hello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和本身选择的公开数，能够计算出初始密钥。

    (6) 服务器收到full client hello，若是不一样意链接就回复REJ，同(3)；若是赞成链接，根据客户端的公开数计算出初始密钥，回复server hello(SHLO)消息，SHLO用初始密钥加密，而且其中包含服务器选择的一个临时公开数。

    (7) 客户端收到服务器的回复，若是是REJ则状况同(4)；若是是SHLO，则尝试用初始密钥解密，提取出临时公开数

    (8) 客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥

    (9) 双方更换为使用会话密钥通讯，初始密钥此时已无用，QUIC握手过程完毕。以后会话密钥更新的流程与以上过程相似，只是数据包中的某些字段略有不一样。