Web通讯协议，你还须要知道： SPDY 和 QUIC

上一篇文章 前端阶段性总结（一）： HTTP 协议，从1.0到2.0梳理了一下HTTP协议。本文将重点介绍，在前端通讯协议中HTTP2的前身，具备开拓性意义的SPDY，以及具备颠覆性的QUIC协议。

1、开拓者：SPDY

1. 简介：

spdy 是由google推行的，改进版本的HTTP1.1 （那时候尚未HTTP2）。它基于TCP协议，在HTTP的基础上，结合HTTP1.X的多个痛点进行改进和升级的产物。它的出现使web的加载速度有极大的提升。HTTP2也借鉴了不少spdy的特性。

2. 特性：

上一篇文章中有介绍，基本和HTTP2差很少，这里就不赘述了：

• 多路复用
• 头部压缩
• 服务器推送
• 请求优先级

spdy的架构图：

3. 现状：

在HTTP2未推出以前，spdy在业界内已经有必定的市场占用量，而且它的成绩也是不容忽视的，所以在很长一段时间，市场上可能会见到spdy和h2同时使用的场景。

2、颠覆者：QUIC

1. 前置知识：

TCP 与 UDP

TCP（Transmission Control Protocol 传输控制协议）是一种面向链接的、可靠的、基于字节流的传输层通讯协议。

1)提供IP环境下的数据可靠传输(一台计算机发出的字节流会无差错的发往网络上的其余计算机，并且计算机A接收数据包的时候，也会向计算机B回发数据包，这也会产生部分通讯量)，有效流控，全双工操做(数据在两个方向上能同时传递)，多路复用服务，是面向链接，端到端的传输;

2)面向链接：正式通讯前必需要与对方创建链接。事先为所发送的数据开辟出链接好的通道，而后再进行数据发送，像打电话。

3)TCP支持的应用协议：Telnet(远程登陆)、FTP(文件传输协议)、SMTP(简单邮件传输协议)。TCP用于传输数据量大，可靠性要求高的应用。

UDP(User Datagram Protocol用户数据报协议）是OSI（Open System Interconnection，开放式系统互联） 参考模型中一种无链接的传输层协议，提供面向事务的简单不可靠信息传送服务。

1) 面向非链接的(正式通讯前没必要与对方创建链接，无论对方状态就直接发送，像短信，QQ)，不能提供可靠性、流控、差错恢复功能。UDP用于一次只传送少许数据，可靠性要求低、传输经济等应用。
2) UDP支持的应用协议：NFS(网络文件系统)、SNMP(简单网络管理系统)、DNS(主域名称系统)、TFTP(通用文件传输协议)等。

总的来讲：
TCP：面向链接、传输可靠(保证数据正确性,保证数据顺序)、用于传输大量数据(流模式)、速度慢，创建链接须要开销较多(时间，系统资源)。
UDP：面向非链接、传输不可靠、用于传输少许数据(数据包模式)、速度快。

Diffie-Hellman 算法

D-H算法的数学基础是离散对数的数学难题，其加密过程以下：

• （1）客户端与服务端肯定两个大素数 n和 g，这两个数不用保密
• （2）客户端选择另外一个大随机数x，并计算A以下：A = g^x mod n
• （3）客户端将 A 发给服务端
• （4）服务端选择另外一个大随机数y，并计算B以下：B = g^y mod n
• （5）服务端将B发给客户端
• （7）计算秘密密钥K1以下：K1=B^2 mod n ， 计算秘密密钥K2以下：K2=A^y mod n , K1=K2，所以服务端和客户端能够用其进行加解密

攻击者知道n和g，而且截获了A和B，可是当它们都是很是大的数的时候，依靠这四个数来计算k1和k2很是困难，这就是离散对数数学难题。

2. 什么是QUIC？

quic 是google推出的，基于UDP的高效可靠协议。quic在UDP的基础上实现了TCP的一些特性，而因为底层使用的是UDP，因此传输效率比TCP高效。

3. 特性

a. 基于UDP创建的链接：

咱们知道，基于TCP的协议，如http2，在首次创建链接的时候须要进行三次握手，即至少须要3个ntt，而考虑安全HTTPS的
TLS层，又须要至少次的通讯才能协商出密钥。这在短链接的场景中极大的增长了网络延迟，而这种延迟是没法避免的。
而基于UDP的quic协议，则不须要3次握手的过程，甚至在安全协商阶段只须要进行1~2次的协商通讯，便可创建安全稳定的链接，极大的减小了网络延迟。

b. 基于Diffie-Hellman的加密算法：

HTTPS 使用的是 TLS + SSL 的加密手段，在交换证书、协商密钥的过程当中，至少须要2次ntt进行协商通讯。而quic使用了Diffie-Hellman算法,算法的原理使得客户端和浏览器之间只须要1次的协商就能得到通讯密钥，quic创建安全连接的详细过程:

• 客户端发起Inchoate client hello
• 服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端
• 客户端发起client hello，包括客户端公钥信息

后续发起链接的过程当中，一旦客户端缓存或持久化了server config，就能够复用并结合本地生成的私钥进行加密数据传输了，不须要再次握手，从而实现0RTT创建链接。

c. 改进的多路复用

咱们知道，不管是HTTP2仍是SPDY,基于TCP的协议尽管实现了多路复用，但仍然没有避免队头阻塞的问题，这个问题是因为TCP底层的实现形成的，即TCP的包有严格的顺序控制，前序包若是丢失，则后续包即便返回了也不会通知到应用层协议，从而致使了前序包阻塞。而quic基于UDP则自然的避免了这个问题，因为UDP没有严格的包顺序，一个包的阻塞只会影响它自身，并不会影响到其余资源，且quic也实现了相似HTTP2的多路复用，这种没有队头阻塞的多路复用对延迟的下降是显而易见的。

d. 链接的迁移

在以往的基于TCP的协议中，每每使用四元组（源IP，源端口，目的IP，目的端口）来标识一条链接，当四元组中的IP或端口任一个发生变化了链接就须要从新创建，从而不具有链接迁移的能力。
而QUIC使用了connection id对链接进行惟一标识。即便网络从4G变成了wifi，只要两次链接中的connection id不变，而且客户端或者服务器能经过校验，就不须要从新创建链接，链接迁移就能成功。
这在移动端场景的优点极为明显，由于手机常常会在wifi和4g中切换，使用quic协议下降了重建链接的成本。

e. 协商的升级

在chorme浏览器中，发起一个TCP请求，这个请求会同时与服务器开始创建tcp 和 quic 的链接（前提是服务器支持），若是quic链接先创建成功，则使用quic创建的链接通讯，反之，则使用tcp创建的链接进行通讯。具体步骤以下：

• 一、客户端发出tcp请求
• 二、服务端若是支持quic能够经过响应头alt-svc告知客户端
• 三、客户端同时发起tcp链接和quic链接竞赛
• 四、一旦quic创建链接获胜则采用quic协议发送请求
• 五、如遇网络或服务器不支持quic/udp，客户端标记quic为broken
• 六、传输中的请求经过tcp重发
• 七、5min后尝试重试quic，下一次尝试增大到10min
• 八、一旦再次成功采用quic并把broken标记取消

其中，支持quic的alt-svc头部信息以下图示：

d. 其余特性：

• 改进的拥塞控制
• 丢包恢复
• 底层的链接持久化
• head stream 保证包顺序
• 双级别流量控制

3、总结与思考

在web通讯协议的演进中，SPDY是不可或缺的角色，在没有HTTP2的时代，它的出现极大的提高了网页加载速度，甚至HTTP2也是吸收了它不少的特性而制定的，是当之无愧的开拓者。而在有HTTP2的今天，quic协议的出现无异于对TCP的颠覆，它在底层抛弃了传统的TCP，而使用高效的UDP，并实现了TCP的特性，而且没有修改到应用层协议，咱们能够无缝的基于原有的规范去开发。最后，这两东西竟然都是google提出并推行的。只能说google真的牛叉~

参考文章
https://www.jianshu.com/p/2d8...
https://wetest.qq.com/lab/vie...
https://cloud.tencent.com/dev...
https://www.zhihu.com/questio...