GitHub 19k Star的Java工程师成为神的路，你知道吗！
最近一段时间，有很多关于HTTP/3的新闻，越来越多的国际大公司开始使用HTTP/3。
所以，HTTP/3已经箭在弦上了。 全面使用只是时间问题。 那么，作为一线开发人员，我们也是时候了解什么是HTTP/3，为什么需要HTTP/3了。
那么，在这篇文章中，什么是HTTP/3？ 他用了什么技术？ 解决了什么问题？
HTTP/2的问题在写这篇文章之前，我写了一篇文章《HTTP/2做错了什么？刚刚辉煌2年就要被弃用了！？》，分析HTTP/2的问题及其背后的原因。
这里就不详细介绍了，我强烈建议你先读读这篇文章，对正文的学习有帮助。
如前一篇文章所述，由于底层使用的传输层协议还是TCP，所以HTTP/2存在TCP团队的信息头阻塞、TCP握手的延迟时间长、协议僵化等问题。
其结果，HTTP/2使用复用、二进制帧化等技术，但存在优化空间。
在QUIC协议中，我们知道HTTP/2被“废除”是因为他使用的传输层协议还是TCP，所以HTTP/3最需要解决的问题是绕过TCP。
开发新协议，还是会受到中间设备僵化的影响，无法大规模应用。 因此，研发人员们考虑了基于UDP实现的方法。
于是，谷歌最先采用了这种方式并付诸实践。 他们在2013年发表了被称为QUIC的协定。 全名是快速更新互联网连接。
从名称中可以看出，这是完全基于UDP的协议。
在设计之初，谷歌希望用该协议代替HTTPS/HTTP协议来提高网页的传输速度。 2015年6月，QUIC的网络草案正式提交给了互联网工程任务组。 2018年10月，互联网工程任务组HTTP和QUIC工作组正式将基于QUIC协议的http (http over quic )重命名为HTTP/3。
所以，我们现在所提到的HTTP/3，其实就是HTTP over QUIC，即基于QUIC协议实现的HTTP。
那么，要了解HTTP/3的原理，只需要了解QUIC就可以了。
QUIC协议具有以下特征：
基于UDP的传输层协议：使用UDP端口号标识指定计算机上的特定服务器。 可靠性：虽然UDP是不可靠的传输协议，但QUIC基于UDP提供了数据包重发、拥塞控制、传输速度调整和其他TCP中存在的特性。 实现了无序的同时字节流。他提供了和TCP类似的可靠性这意味着一个数据流的传输是一个顺序，但多个数据流的接收顺序可能与发送方的发送顺序不同。快速握手： http://www.Sina.com 使用TLS 1.3传送层安全协议：与以前的TLS版本相比，TLS 1.3具有许多优点，但主要原因是握手所需的往返次数少，并且可以减少协议延迟。 那么，QUIC到底属于TCP/IP协议族中的一层呢？ 我们知道QUIC是基于UDP实现的，是HTTP/3的依赖协议。 那么，根据TCP/IP的层次，他属于传输层。 这意味着它与TCP和UDP属于同一层。
更详细的说，因为QUIC不仅具有传输层协议的作用，还具有TLS的安全相关能力，所以在下图中，可以理解QUIC在HTTP/3的实现中所处的位置。
接下来，我们分别展开QUIC协议进行分析。 首先，让我们看看他是如何建立连接的。
我们知道，建立QUIC连接时，像TCP这样的可信传输协议需要三次握手。 也就是说，如果为了3次握手而追加1.5 RTT、TLS，则需要3~4个RTT连接。
那么，QUIC如何建立连接呢？ 如何减少RTT？
QUIC基于该连接机制提出了实现快速交换功能的新连接建立机制，能够在一次QUIC连接建立中使用0-RTT或1-RTT来建立连接。
QUIC在握手过程中使用diffie hellman算法来确保数据交换的安全，并结合加密和握手过程来减少连接建立过程中的往返次数。
diffiehellman (以下简称DH )密钥交换是一种特殊的密钥交换方法。 是密码学领域最早实践的密钥交换方法之一。 DH可以通过不安全的信道来达成共享密钥，前提是完全缺乏对方的“私有”信息。 该密钥用于对称加密后续的信息交换。
建立QUIC连接的总流程通常是QUIC在握手期间使用diffie hellman算法协商初始密钥，初始密钥取决于存储在服务器中的配置参数集而周期性地更新。 如果初始密钥协商成功，服务器将提供临时随机数，双方将根据该随机数重新生成会话密钥。 客户端和服务器使用冷酷的便当钥匙进行数据
加解密。以上过程主要分为两个步骤：初始握手（Initial handshake）、最终（与重复）握手（Final (and repeat) handshake），分别介绍下这两个过程。
初始握手（Initial handshake）在连接开始建立时，客户端会向服务端发送一个打招呼信息，（inchoate client hello (CHLO)），因为是初次建立，所以，服务端会返回一个拒绝消息（REJ），表明握手未建立或者密钥已过期。
但是，这个拒绝消息中还会包含更多的信息（配置参数），主要有：
Server Config：一个服务器配置，包括服务器端的Diffie-Hellman算法的长期公钥（long term Diffie-Hellman public value）Certificate Chain：用来对服务器进行认证的信任链Signature of the Server Config：将Server Config使用信任链的叶子证书的public key加密后的签名Source-Address Token：一个经过身份验证的加密块，包含客户端公开可见的IP地址和服务器的时间戳。在客户端接收到拒绝消息（REJ）之后，客户端会进行数据解析，签名验证等操作，之后会将必要的配置缓存下来。
同时，在接收到REJ之后，客户端会为这次连接随机产生一对自己的短期密钥（ephemeral Diffie-Hellman private value） 和 短期公钥（ephemeral Diffie-Hellman public value）。
之后，客户端会将自己刚刚产生的短期公钥打包一个Complete CHLO的消息包中，发送给服务端。这个请求的目的是将自己的短期密钥传输给服务端，方便做前向保密，后面篇幅会详细介绍。
在发送了Complete CHLO消息给到服务器之后，为了减少RTT，客户端并不会等到服务器的响应，而是立刻会进行数据传输。
为了保证数据的安全性，客户端会自己的短期密钥和服务器返回的长期公钥进行运算，得到一个初始密钥（initial keys）。
有了这个初识密钥之后，客户端就可以用这个密钥，将想要传输的信息进行加密，然后把他们安全的传输给服务端了。
另外一面，接收到Complete CHLO请求的服务器，解析请求之后，就同时拥有了客户端的短期公钥和自己保存的长期密钥。这样通过运算，服务端就能得到一份和客户端一模一样的初始密钥（initial keys）。
接下来他接收到客户端使用初始密钥加密的数据之后，就可以使用这个初识密钥进行解密了，并且可以将自己的响应再通过这个初始密钥进行加密后返回给客户端。
所以，从开始建立连接一直到数据传送，只消耗了初始连接连接建立的 1 RTT
最终（与重复）握手那么，之后的数据传输就可以使用初始密钥（initial keys）加密了吗？
其实并不完全是，因为初始密钥毕竟是基于服务器的长期公钥产生的，而在公钥失效前，几乎多有的连接使用的都是同一把公钥，所以，这其实存在着一定的危险性。
所以，为了达到前向保密 (Forward Secrecy) 的安全性，客户端和服务端需要使用彼此的短期公钥和自己的短期密钥来进行运算。
在密码学中，前向保密（英语：Forward Secrecy，FS）是密码学中通讯协议的安全属性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。
那么现在问题是，客户端的短期密钥已经发送给服务端，而服务端只把自己的长期密钥给了客户端，并没有给到自己的短期密钥。
所以，服务端在收到Complete CHLO之后，会给到服务器一个server hello(SHLO)消息，这个消息会使用初始密钥（initial keys）进行加密。
这个CHLO消息包中，会包含一个服务端重冷酷的便当成的短期公钥。
这样客户端和服务端就都有了对方的短期公钥（ephemeral Diffie-Hellman public value）。
这样，客户端和服务端都可以基于自己的短期密钥和对方的短期公钥做运算，产生一个仅限于本次连接使用的前向保密密钥 (Forward-Secure Key)，后续的请求发送，都基于这个密钥进行加解密就可以了。
这样，双方就完成了最终的密钥交换、连接的握手并且建立了QUIC连接。
当下一次要重新创建连接的时候，客户端会从缓存中取出自己之前缓存下来的服务器的长期公钥，并重新创建一个短期密钥，重冷酷的便当成一个初识密钥，再使用这个初始密钥对想要传输的数据进行加密，向服务器发送一个Complete CHLO 请求即可。这样就达到了0 RTT的数据传输。
所以，如果是有缓存的长期公钥，那么数据传输就会直接进行，准备时间是0 RTT
以上，通过使用Diffie-Hellman算法协商密钥，并且对加密和握手过程进行合并，大大减小连接过程的RTT ，使得基于QUIC的连接建立可以少到1 RTT甚至0 RTT。
以下，是Google官网上面的一张关于QUIC连接建立的流程图，可以帮助大家理解这个过程。
另外，通过以上关于握手建立的过程，我们也可以知道，QUIC在整个过程中通过加解密的方式很好的保证了安全性。
多路复用基于TCP的协议实现的HTTP有一个最大的问题那就是队头阻塞问题，那么，在这方面，QUIC是如何解决这个问题的呢？
TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。
但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。
类似于HTTP/2，QUIC在同一物理连接上可以有多个独立的逻辑数据流，这些数据流并行在同一个连接上传输，且多个数据流之间间的传输没有时序性要求，也不会互相影响。
数据流（Streams）在QUIC中提供了一个轻量级、有序的字节流的抽象化
QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序。这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！
也就是说同一个连接上面的多个数据流之间没有任何依赖（不要求按照顺序到达），即使某一个数据包没有达到，也只会影响自己这个数据流，并不会影响到到其他的数据流。
连接迁移对于TCP连接的识别，需要通过服务器和客户端过双方的ip和端口四个参数进行的。在网络切换的场景中，比如手机切换网络，那么自身的ip就会发生变化。这就导致之前的TCP连接就会失效，就需要重新建立。
这种场景对于移动端设备普及的今天来说，还是比较频繁的。
所以，在这一点上，QUIC进行了优化。
QUIC协议使用特有的UUID来标记每一次连接，在网络环境发生变化的时候，只要UUID不变，就能不需要握手，继续传输数据。
可靠性TCP之所以被称之为可靠链接，不仅仅是因为他有三次握手和四次关闭的过程，还因为他做了很多诸如流量控制、数据重传、拥塞控制等可靠性保证。
这也是为什么一直以来都是以TCP作为HTTP实现的重要协议的原因。
那么，QUIC想要取代TCP，就需要在这方面也做出努力，毕竟UDP自身是不具备这些能力的。
TCP拥塞控制是TCP避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。经典的算法实现有很多，诸如TCP Tahoe 和 Reno、TCP Vegas、TCP Hybla、TCP New Reno、TCP Westwood和Westwood+以及TCP BIC 和 CUBIC等等。
QUIC协议同样实现了拥塞控制。不依赖于特定的拥塞控制算法，并且提供了一个可插拔的接口，允许用户实验。默认使用了 TCP 协议的 Cubic 拥塞控制算法。
关于流量控制，QUIC提供了基于stream和connection两种级别的流量控制，既需要对单个 Stream 进行控制，又需要针对所有 Stream 进行总体控制。
QUIC的连接级流控，用以限制 QUIC 接收端愿意分配给连接的总缓冲区，避免服务器为某个客户端分配任意大的缓存。连接级流控与流级流控的过程基本相同，但转发数据和接收数据的偏移限制是所有流中的总和。
弊端以上，我们介绍了很多QUIC的相比较于TCP的优点，可以说这种协议相比较于TCP确实要优秀一些。
因为他是基于UDP的，并没有改变UDP协议本身，只是做了一些增强，虽然可以避开中间设备僵化的问题，但是，在推广上面也不是完全没有问题的。
首先，很多企业、运营商和组织对53端口（DNS）以外的UDP流量会进行拦截或者限流，因为这些流量近来常被滥用于攻击。
特别是一些现有的UDP协议和实现易受放大攻击（amplification attack）威胁，攻击者可以控制无辜的主机向受害者投放发送大量的流量。
所以，基于UDP的QUIC协议的传输可能会受到屏蔽。
另外，因为UDP一直以来定位都是不可靠连接，所以有很多中间设备对于他的支持和优化程度并不高，所以，出现丢包的可能性还是比较搞的。
总结下表是我总结的HTTP/2和HTTP/3的异同点，有一些本文介绍过，有一些个人认为并不是特别重要的，本文中并没有提及，大家感兴趣的可以自行学习下。
特性HTTP/2HTTP/3传输层协议TCP基于UDP的QUIC默认加密否是独立的数据流否是队头阻塞存在TCP队头阻塞无报头压缩HPACKQPACK握手时延TCP+TLS 的 1-3 RTT0-1 RTT连接迁移无有服务器推送有有多路复用有有流量控制有有数据重传有有拥塞控制有有参考资料：
https://http3-explained.haxx.se/
The QUIC Transport Protocol: Design and Internet-Scale Deployment
https://www.codenong.com/cs106840038/
https://nan01ab.github.io/2018/12/QUIC.html
https://medium.com/@chester.yw.chu/http-3-傳輸協議-quic-簡介-5f8806d6c8cd
关于作者：Hollis，一个对Coding有着独特追求的人，阿里巴巴技术专家，《程序员的三门课》联合作者，《Java工程师成神之路》系列文章作者。
如果您有任何意见、建议，或者想与作者交流，都可以关注公众号【Hollis】，直接后台给我留言。