前言

HTTP/3 即 QUIC（发音同Quick），通过发音我们就知道 HTTP/3 又可以让网站的速度更上一层楼。 HTTP/2 提速很重要的一点是使用了多路复用，一般来说同一域名下只需要一个 TCP 连接。但是如果当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1.1 了。

如果出现丢包的情况下，整个 TCP 便会要开始等待重传，导致了后面所有数据都阻塞了。但是对于 HTTP/1.1 来说，因为可以开启多个 TCP 连接，所以出现这种情况反到也就只影响其中你们一个连接而已，剩余的 TCP 连接还可以正常传输数据。

好嘛，有问题我们就解决问题，因为我们已经见识到了多路复用的好处，所以我们就去修改 TCP 协议，不过这已经是一件不可能完成的任务了。TCP 真的是太元老了，对 TCP 进行更新意味着要从操作系统上入手，那么整个协议将不会被所有的老系统所支持，新系统的推广何其艰难。

所以谷歌就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，因为 UDP 不需要三次握手，2016年，IETF开始致力于协议的标准化。将QUIC拆分为基于传输层的和应用层的协议。应用层协议被称为 HTTP-over-QUIC 在2018年11月，IETF宣布 HTTP-over-QUIC 被正式命名为HTTP / 3。

如果上面大段背景介绍觉得烦，我们直接看下文即可：

QUIC 协议有哪些优点，如何实现 0-RTT？
1. QUIC 协议在传输层就支持多路复用，避免了队头阻塞问题。
2. QUIC 协议基于 UDP，更自由更高效
3. QUIC 协议借鉴了 TFO 的思想，支持会话上下文缓存，方便恢复，具备实现 0-RTT 的可能
传统的 HTTP2 + SSL + TCP 协议栈有哪些缺点？
1. SSL 的会话恢复依然需要一个 RTT，而且难以合并到 TCP 层
2. TCP 的滑动窗口存在队头阻塞问题
3. TCP 的重传纠错会浪费一个 RTT
为什么 Google 要另起炉灶，基于 UDP 去做？
1. TCP 由操作系统实现，很难更新
2. UDP 非常高效，几乎没有性能负担
3. 将 QUIC 嵌入到 Chrome 中可以方便后续的升级迭代
QUIC的特性究竟有哪些？
1. 利用缓存，显著减少连接建立时间
2. 改善拥塞控制，拥塞控制从内核空间到用户空间
3. 没有 head of line 阻塞的多路复用
4. 前向纠错，减少重传
5. 连接平滑迁移，网络状态的变更不会影响连接断线。

改编自全栈养成计划和冰霜之地

实现

目前支持 QUIC 的 Web 服务软件主要是 LiteSpeed 和 Caddy，Nginx 尚不支持现有教程都是通过 Docker 结合 Nginx+Caddy 来实现，稳定性和可靠性都得打上问号。

所以我就比较推荐基于 LiteSpeed 的来实现了，LiteSpeed 是一款企业级商业 Web 服务，相比开源社区软件会有着更好的稳定性和可靠性。值得一提的是 HTTP/2 也是由 Lite Speed 率先实现的。

简单介绍：

LiteSpeed 即 LiteSpeed Web Server（简称 LSWS），是一款企业级商用 Web 服务软件，可以完美的 Apache HTTPD 兼容体验，.htaccess 规则可以直接兼容而不像 Nginx 需要重写，并兼容常用的mod扩展。得益于基于事件的架构优势，静态内容比Apache Httpd 快 5 倍，动态内容更是快 40 倍，HTTPS 访问快 3 倍并可以应用硬件加速器。

更多介绍请看：https://www.llstack.com/zh/LiteSpeed/

安装

这里我推荐通过 LLStack 一键包进行 Lite Speed 的安装。 安装教程：https://www.llstack.com/zh/install/

一、篇幅限制，这里以安装简单的轻量版为例。在 SSH 终端中输入：

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ivmm/LLStack/master/install.sh)" 2>&1 | tee llstack-all.log

我们安装完成：