HTTP2.0和QUIC

最近看到腾讯云支持QUIC的文章，突然意识到还没有好好认识HTTP2、QUIC，而要认识HTTP2，就需要从HTTP1.0开始讲起，才能清楚HTTP的发展历程。

HTTP1.x

HTTP（HyperText Transfer Protocol）超文本传输协议伴随着计算机网络和浏览器的诞生，HTTP1.0也随之而来，处于计算机中的应用层。HTTP是建立在TCP协议之上，所以HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性，如TCP三次握手四次挥手建立连接带来的RTT延迟时间等。 HTTP建立之初，就是为了将HTML文档从Web服务器传送到客户端浏览器。 影响一个HTTP网络请求的主要因素：带宽和延迟

• 带宽
• 延迟
  • 浏览器阻塞（HOL blocking）：浏览器对同一个域名，会限制最大连接数。
  • DNS查询（DNS Lookup）：缓存DNS
  • 建立链接（Initial connection）：TCP三次握手

HTTP 1.1与HTTP 1.0的区别：

1. 缓存处理，引入更多缓存头控制缓存策略
2. 带宽优化及网络连接的使用，增加断点续传功能
3. 错误通知的管理：新增24个错误状态码，如409（conflict）表示请求资源与资源当前状态冲突、410（Gone）表示服务器上某个资源被永久性删除。
4. Host头处理。随着虚拟主机技术的发展，一台物理服务器上可以存在多个虚拟主机且共享同一个IP。HTTP 1.1请求和响应都支持host头，请求消息中如果缺少host，会抱400（Bad Request）
5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少建立、关闭连接的消耗和延迟。HTTP 1.1中默认开启Connection:keep-alive。

HTTP 1.0与1.1存在的问题：

1. HTTP传输数据，每次都要3次握手建立连接，增加了大量延迟
2. 明文传输
3. header携带内容过大，增加传输成本，并且每次请求header变化不大，移动端增加用户流量
4. 虽然HTTP1.1支持了keep-alive，但是keep-alive使用多了同样给服务端带来大量的性能压力，因为文件被请求后，服务端需要保持不必要的连接很长时间。

HTTPS

HTTPS（网景1994创建）就是安全版的HTTP，与HTTP的区别如下：

1. HTTPS协议需要到CA申请证书，免费证书很少，一般需要交费。
2. HTTP协议运行在TCP之上，所有传输内容都是明文；HTTPS运行在SSL/TLS（Transport Layer Secure）上，SSL/TLS运行在TCP上，所有传输内容都是加密的。
3. HTTP和HTTPS使用端口不同：HTTP默认80，HTTPS默认443。
4. HTTPS可以有效防止运营商劫持。

一个HTTP网站全站改造为HTTPS，需要关注的点：

1. 安装CA证书
2. 购买证书后，在证书提供网站上配置自己的域名，将证书下载下来后，配置自己的web服务器，同时进行代码改造。
3. HTTPS降低用户访问速度。SSL握手会一定程度降低速度。如果使用SPDY，HTTPS速度甚至还要比HTTP快。
4. HTTPS中大量的密钥算法计算，会消耗服务端大量CPU资源。

SPDY

SPDY位于HTTP之下，TCP和SSL之上，可以轻松兼容老版本的HTTP协议，也可以使用已有的SSL功能。 SPDY是Google2012年提出，主要解决如下问题：

1. 降低延迟。针对HTTP高延迟的问题，SPDY采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接，解决了HOL blocking问题，降低延迟同时提高了带宽的利用率。
2. 请求优先级（request prioritization）。多路复用的连接共享机制有可能导致关键请求被阻塞。SPDY允许给每个request设置优先级，重要请求优先得到响应。
3. header压缩。
4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
5. 服务端推送（Server push）

HTTP2.0

YouTube、淘宝已经支持http2.0. HTTP2.0可以说是SPDY的升级版本，与SPDY的区别如下：

1. HTTP2.0支持明文HTTP传输，而SPDY强制使用HTTPS。
2. HTTP2.0消息头压缩算法使用HPACK，而SPDY使用DEFLATE。

HTTP2.0的主要目标是改进传输性能，实现低延迟和高吞吐量。

HTTP2.0新特性：

1. 新的二进制（Binary Format）分帧层。HTTP1.x的解析基于文本，文本的展现形式多样，要做到健壮性考虑的场景必然很多，二进制则只有0和1，更高效健壮。
2. 多路复用（MultiPlexing），即连接共享，每一个request都是用作连接共享机制的。每一个request对应一个id，一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方根据request的id将request再归属到不同服务端请求里面。客户端只需要一个连接就可以加载一个页面。
3. header压缩。避免了重复header的传输，又减少了需要传输的大小。
   1. HTTP2.0会压缩首部元数据，在client和server使用首部表跟踪和存储之前发送的健值对，对于相同数据，不需要每次请求响应都发送。首部表在HTTP2.0的连接有效期内始终存在，由client、server共同渐进地更新，每个新的首部健值对要么更新已有值要么append到表尾。
   2. 所有header必须全部小写，而且请求行要独立为健值对（即header+值）。
4. 服务端推送（server push）。服务端可以对一个客户端请求发送多个响应。server push通过推送那些它认为客户端将会需要使用到的内容到客户端缓存中，以此避免往返的延迟。
   1. 客户端可以限定推送流的数量，也可以设置为0而完全禁用server push
   2. 所有推送都遵守同源策略，即服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认的。
   3. PUSH_PROMISE帧：所有服务器推送流都通过PUSH_PROMISE发送，服务端发出有意push所述资源的信号，客户端接收到PUSH_PROMISE帧后，也可以拒绝这个流。
   4. 服务端必须遵循请求-响应的循环，只能借着对请求的响应推送资源。
   5. PUSH_PROMISE帧必须在返回响应之前发送，否则客户端会出现竞态条件。

HTTP2.0的升级改造需要考虑的点：

1. HTTP2.0其实可以支持非HTTPS的，但是主流浏览器如chrome、Firefox还是只支持基于TLS部署的HTTP2.0协议，所以要升级HTTP2.0还是先升级HTTPS好。
2. 升级HTTPS后，如果使用NGINX，只需要在配置文件中启动相应的协议就可以。
3. HTTP2.0完全兼容HTTP1.x，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容。

QUIC协议

QUIC（Quick UDP Internet Connections）是由Google提出的一种基于UDP改进的低时延的互联网传输层（其实有疑义，QUIC基于UDP，其实更像应用层协议）协议。
优点：具有SPDY的所有优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥赛控制，减少重新连接；相当于TLS加密。

1. QUIC主要目标是减少连接延迟，客户端第一次连接服务器时，QUIC只需要1RTT的延迟就可以建立可靠安全的连接，相对于TCP+TLS的1～3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，再次与服务端建立连接时可以实现0RTT的连接建立延迟。
2. QUIC同时复用了HTTP2.0的多路复用（Multiplexing）功能，但由于QUIC基于UDP，避免了HTTP/2的Head-of-Line Bolcking问题。
3. QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速部署和更新。
4. 重传与恢复
   与TCP类似，QUIC每发送一个包后，都会等待回复一个确认包。当丢包率超过协议的纠错阀值，会显示与隐式进行重传。
   对于某些重要的数据包，在确认丢失前就会进行重传。这样在网络中会有若干个相同包同时传输，任何一个成功抵达就完成了连接，通过这样降低丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传，都采用相同的重复包处理机制。
   QUIC在拥塞避免算法上还加入了心跳机包，用于减少丢包率。
   QUIC使用FEC（前向纠错）来恢复数据，FEC采用简单的异或方式。每次发送一组数据，包含若干个数据包后，并对这些数据包依次做异或运算，最后结果作为一个FEC包再发送出去。接收方收到一组数据后，根据数据包和FEC包即可以进行考验和纠错。
5. 安全性 QUIC对每个散装的UDP包都进行了加密和认证的保护，并且避免使用前向依赖（如CBC模式）的方法，这样每个UDP包可以独立地根据IV进行加密或者认证处理。 QUIC使用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后再马上协商会话密钥，这样可以保证密钥的前向安全性，之后通信过程还可以实现密钥的更新。接收方收到密钥更新时，需要用新旧两种密钥对数据进行解密，直到成功才会正式使用新密钥。
6. 0RTT握手过程
   QUIC握手过程需要一次数据交互，0RTT即可以完成握手过程的密钥协商，比TLS相比效率提供了5倍。
   QUIC在握手过程使用Diffie-Hellman算法协商初始密钥，初始化密钥依赖于服务器存储的一组配置参数，该参数会周期性更新。初始密钥协商成果后，服务端会提供一个临时随机数，双方根据这个随机数再生成会话密钥。
   client具体握手过程如下：