HTTP3 - Githubissues

HTTP/2 相比于 HTTP/1.1，确实大幅度提高了网页的安全性与性能，但 HTTP/2 推出也存在传输的队头阻塞、多路复用超时导致服务器压力上升的问题，因此出现了 HTTP/3 解决推出出现的问题。

HTTP的演化历程

1.HTTP/0.9、HTTP/1.0

1996年 HTTP/0.9 规范、1996年 HTTP/1.0规范的发布，该规范定义了基本 超文本传输协议。在 HTTP/1.0 中，客户端和服务器之间的每次请求/响应交换都会创建一个新的 TCP 连接，这意味着在每个请求 TCP 和 TLS 都要完成握手连接成本很高，所有请求都会产生延迟。

2.HTTP/1.1

1997年 HTTP/1.1 规范的发布，该规范相对于 HTTP/1.0 版本做了一些优化：

长连接，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，默认开启 Connection： keep-alive，优化每次请求都要创建连接的缺点。
缓存处理，引入更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用，在请求头引入了range 头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理，在 HTTP1.1 中新增了24 个错误状态响应码。
Host 头处理，HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。

HTTP1.1 相对于 HTTP/1.0 虽然做了比较多的优化，同时也引出了一些问题常见的 "队头堵塞"（Head-of-line blocking、明文传输、协议 Header 太大、keep-alive 使服务端带来大量的性能压力等。

3.SPDY 协议

2009 年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。SPDY 可以说是综合了 HTTPS 和 HTTP 两者有点于一体的传输协议，主要解决：

降低延迟，针对 HTTP 高延迟的问题，SPDY 优雅的采取了多路复用（multiplexing）。多路复用通过多个请求 stream 共享一个 tcp 连接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率。
请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY 允许给每个 request 设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的 html 内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
header 压缩。前面提到 HTTP1.x 的 header 很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
基于 HTTPS 的加密协议传输，大大提高了传输数据的可靠性。
服务端推送（server push），采用了 SPDY 的网页，例如我的网页有一个 sytle.css 的请求，在客户端收到 sytle.css 数据的同时，服务端会将 sytle.js 的文件推送给客户端，当客户端再次尝试获取 sytle.js 时就可以直接从缓存中获取到，不用再发请求了。

4.HTTP/2

HTTP/2 可以说是 SPDY 的升级版（其实原本也是基于 SPDY 设计的），但是 HTTP2.0 跟 SPDY 仍有不同的地方，主要是以下两点：

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

HTTP/2 的新特性:

二进制分帧：HTTP/2 的所有帧都采用二进制编码
多路复用 (Multiplexing)
请求优先级
header 压缩
服务端推送

数据流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。为了说明这个过程，我们需要了解 HTTP/2 的三个概念：

数据流(Stream)：已建立的连接内的双向字节流，可以承载一条或多条消息。
消息(Message)：与逻辑请求或响应消息对应的完整的一系列帧。
帧(Frame)：HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。

5.HTTP/3

Google 在推 SPDY 中意识到了传输层的队头阻塞的问题，同时也搞了一个基于 UDP 协议的 “QUIC” 协议，让 HTTP 跑在 UDP 上而不是 TCP 上。这个 “HTTP over QUIC” 就是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃，真正 “完美” 地解决了 “队头阻塞” 问题。

HTTP/3 之前叫作 HTTP over QUIC，再往前又叫 HTTP/2 over QUIC，HTTP/3 只是一种基于 QUIC（基于 UDP 的多路复用和安全传输）的 HTTP 新语法。HTTP/3 这个名称在第 17 版草案（ draft-ietf-quic-http-17 ）中正式启用，该草案于 2018 年 10 月底提出，在 11 月于曼谷举行的 IETF 103 大会期间进行了讨论并达成初步的共识。

我们知道 HTTP/1.1 和 HTTP/2 是基于 TCP 传输，HTTP/3 UDP 传输，为什么要选择这样的传输协议呢，来看一下 UDP 与 TCP 对比？

UDP

UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。

它有以下几个特点：

1.面向无连接

首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

具体来说就是：

在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作

2.有单播，多播，广播的功能

UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

3.UDP是面向报文的

发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文

4.不可靠性

首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。

并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。从上面的动态图可以得知，UDP只会把想发的数据报文一股脑的丢给对方，并不在意数据有无安全完整到达。

头部开销小，传输数据报文时是很高效的。

UDP 头部包含了以下几个数据：

两个十六位的端口号，分别为源端口（可选字段）和目标端口
整个数据报文的长度
整个数据报文的检验和（IPv4 可选字段），该字段用于发现头部信息和数据中的错误

因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的

TCP

当一台计算机想要与另一台计算机通讯时，两台计算机之间的通信需要畅通且可靠，这样才能保证正确收发数据。例如，当你想查看网页或查看电子邮件时，希望完整且按顺序查看网页，而不丢失任何内容。当你下载文件时，希望获得的是完整的文件，而不仅仅是文件的一部分，因为如果数据丢失或乱序，都不是你希望得到的结果，于是就用到了TCP。

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的RFC 793定义。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

1.TCP连接过程

如下图所示，可以看到建立一个TCP连接的过程为（三次握手的过程）:

第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

这里可能大家会有个疑惑：为什么 TCP 建立连接需要三次握手，而不是两次？这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。

2.TCP断开链接

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。

第一次握手

若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。

第二次握手

B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。

第三次握手

B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。

第四次握手

A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃）时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

3.TCP协议的特点

面向连接

面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。
仅支持单播传输

每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

面向字节流

TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

可靠传输

对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。
提供拥塞控制

当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞

TCP提供全双工通信

TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

TCP和UDP的比较

TCP向上层提供面向连接的可靠服务，UDP向上层提供无连接不可靠服务。
虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
对数据准确性要求高，速度可以相对较慢的，可以选用TCP

UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

Quic

Quic 全称 Quick UDP Internet Connections，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 Google 提出的使用 UDP 进行多路并发传输的协议，QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。

与 TCP 相比，使用 UDP 可以提供更大的灵活性，并且可以使 QUIC 完全于用户空间中实现——对协议实现的更新不像 TCP 那样需要绑定到操作系统更新。使用 QUIC，可以简单地将 HTTP 级别的流映射到 QUIC 流的顶部，从而获得HTTP/2 的所有好处，而不会产生前端阻塞。

QUIC 结合了典型的3次 TCP 握手和 TLS 1.3 的握手。结合了这些步骤意味着 QUIC 在默认情况下提供了加密和身份验证，并且可以更快地建立连接。换句话说，即使HTTP会话中的初始请求需要一个新的QUIC连接，在数据开始流动之前产生的延迟也低于使用 TLS 的 TCP 时的情况。

Quic 相比现在广泛应用的 TCP + TLS + HTTP/2 协议有如下优势：

减少了 TCP 三次握手及 TLS 握手时间。
改进的拥塞控制。
避免队头阻塞的多路复用。
连接迁移。
前向冗余纠错。

QUIC部署

目前 CDN 厂商在直播以及部分 HTTP 场景已经开始引入了 QUIC，若大家想尝试实践，可通过使用 Go语言写的 Caddy Web 服务器快速部署实践，它具有如下的一些功能：

配置简单：Caddy服务器的运行可以通过Caddyfile配置文件进行配置，Web服务配置起来非常简单。
自动的HTTPS：它可以自动地为我们申请 Let's Encrypt 域名证书，管理所有的密码学设施，并进行配置。
HTTP/2：默认支持HTTP/2（由Go标准库支持）
虚拟主机托管：Caddy支持TLS的SNI。SNI是在2006年加入TLS的一个TLS扩展。客户端在TLS握手的Client Hello消息中，通过SNI扩展将请求的资源的域名发送给服务器，服务器根据SNI的域名来下发TLS证书。这样就可以在具有单个公网IP的同一台主机上部署多个不同的域名的服务。可以为Caddy服务的不同域名配置不同的证书和密钥。
QUIC支持：Caddy实验性地支持QUIC协议，以获取更好的性能。
TLS session ticket key rotation for more secure connections
良好的可扩展性：因此Caddy非常方便针对自己的需求做定制。
随处运行：这主要与Go应用程序的特性有关。Go的模块都被编译为静态库，这使得Go的应用程序在编译为可执行文件时都是静态链接的，因而依赖的动态库极少，这使得部署使用非常方便。