关于 HTTP3，你可能还要知道这些~
公众号关注“杰哥的IT之旅”，
选择“星标”，重磅干货，第一时间送达！
一、开拓者：SPDY
1. 简介：
2. 特性：
上一篇文章中有介绍，基本和HTTP2差不多，这里就不赘述了：
多路复用
头部压缩
服务器推送
请求优先级
spdy的架构图：
3. 现状：
二、颠覆者：QUIC
1. 前置知识：
TCP 与 UDP
2) UDP支持的应用协议：NFS(网络文件系统)、SNMP(简单网络管理系统)、DNS(主域名称系统)、TFTP(通用文件传输协议)等。
TCP：面向连接、传输可靠(保证数据正确性,保证数据顺序)、用于传输大量数据(流模式)、速度慢，建立连接需要开销较多(时间，系统资源)。
UDP：面向非连接、传输不可靠、用于传输少量数据(数据包模式)、速度快。
Diffie-Hellman 算法
（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？
3. 特性
a. 基于UDP建立的连接：
我们知道，基于TCP的协议，如http2，在首次建立连接的时候需要进行三次握手，即至少需要3个ntt，而考虑安全HTTPS的TLS层，又需要至少次的通信才能协商出密钥。这在短连接的场景中极大的增加了网络延迟，而这种延迟是无法避免的。
HTTPS 使用的是 TLS + SSL 的加密手段，在交换证书、协商密钥的过程中，至少需要2次ntt进行协商通信。而quic使用了Diffie-Hellman算法,算法的原理使得客户端和浏览器之间只需要1次的协商就能获得通信密钥，quic建立安全链接的详细过程:
客户端发起Inchoate client hello
服务器返回Rejection，包括密钥交换算法的公钥信息，算法信息，证书信息等被放到server config中传给客户端
客户端发起client hello，包括客户端公钥信息
我们知道，无论是HTTP2还是SPDY,基于TCP的协议尽管实现了多路复用，但仍然没有避免队头阻塞的问题，这个问题是由于TCP底层的实现造成的，即TCP的包有严格的顺序控制，前序包如果丢失，则后续包即使返回了也不会通知到应用层协议，从而导致了前序包阻塞。而quic基于UDP则天然的避免了这个问题，由于UDP没有严格的包顺序，一个包的阻塞只会影响它自身，并不会影响到其他资源，且quic也实现了类似HTTP2的多路复用，这种没有队头阻塞的多路复用对延迟的降低是显而易见的。
在以往的基于TCP的协议中，往往使用四元组（源IP，源端口，目的IP，目的端口）来标识一条连接，当四元组中的IP或端口任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。
在chorme浏览器中，发起一个TCP请求，这个请求会同时与服务器开始建立tcp 和 quic 的连接（前提是服务器支持），如果quic连接先建立成功，则使用quic建立的连接通信，反之，则使用tcp建立的连接进行通信。具体步骤如下：
1、客户端发出tcp请求
2、服务端如果支持quic可以通过响应头alt-svc告知客户端
3、客户端同时发起tcp连接和quic连接竞赛
4、一旦quic建立连接获胜则采用quic协议发送请求
5、如遇网络或服务器不支持quic/udp，客户端标记quic为broken
6、传输中的请求通过tcp重发
7、5min后尝试重试quic，下一次尝试增大到10min
8、一旦再次成功采用quic并把broken标记取消
其中，支持quic的alt-svc头部信息如下图示：
改进的拥塞控制 丢包恢复 底层的连接持久化 head stream 保证包顺序 双级别流量控制
三、总结与思考
往期资源回顾 需要可自取
推荐阅读
点个[在看]，是对杰哥最大的支持！
评论