HTTP/3即将到来, 紧随HTTP / 2之后，它本身也很年轻. 考虑到从HTTP / 1到现在用了16年.1到HTTP / 2，如果有人真的关心HTTP/3?

简短的回答是:是的，这很重要，你应该跟上它的速度. 这就像HTTP / 2对HTTP / 1的重大改变一样.1通过从ASCII切换到二进制. HTTP/3再次做了重大改变, 这一次是通过将底层传输从TCP切换到UDP.

虽然HTTP/3仍处于设计阶段，官方规范只是草案, 它已经被部署了，很有可能今天您的网络上就运行着它的一个版本.

但是HTTP/3的工作方式带来了一些新的难题. 还有，好处是什么? 网络工程师、系统管理员和开发人员需要知道什么?

主要问题:性能和效率

网站和应用开发者通常都希望自己的作品能被使用. 有时用户基础是有限的，但通常只是为了获得尽可能多的用户. 当然，一个网站越受欢迎，它的收入就越多.

网站加载时间延迟100毫秒会使转化率降低7%.

Akamai在线零售业绩报告:毫秒至关重要(2017)

换句话说, 销售额为40美元的电子商务网站,由于这种延误，每年将损失100万美元.

众所周知，网站的性能对网站变得更受欢迎至关重要. 网上购物研究 继续查找链接 之间的 增加弹跳率和更长的加载时间，以及 顾客忠诚度和网站在购物体验中的表现.

研究 我还发现:

• 47%的消费者希望网页在2秒或更短的时间内加载.
• 40%的人会放弃加载时间超过3秒的网站.

这就是网上购物者的耐心状态 十多年前. 所以性能是至关重要的，HTTP / 2和HTTP/3都意味着更好的网站性能.

HTTP / 2? 那是什么…?

理解HTTP / 2协议对于理解HTTP/3至关重要. 首先，为什么需要HTTP / 2?

HTTP / 2最初是一个名为SPDY的谷歌项目, 一项研究报告了web上最大的性能问题是 延迟. 作者的结论是“更多的带宽并不重要”:

如果我们在管道和互联网之间做一个类比，我们可以考虑 带宽 互联网的直径就像水管的直径. 水管越大，水量越大, 因此你可以在两点之间输送更多的水.

同时, 不管你的烟斗有多大, 如果管道是空的, 你想让水从一点流到另一点, 水通过管道需要时间. 用网络用语来说, 水从管道的一端流到另一端再流回来所花费的时间叫做时间 往返时间, or RTT.

迈克·贝尔奇

在这项研究中，减少页面加载时间是目标. 研究表明，最初增加带宽是有帮助的, 从1mbps到2mbps可以减少一半的页面加载时间. 然而，收益很快就会趋于稳定.

相比之下，减少延迟具有恒定的好处并获得最佳结果.

HTTP HOL:行首阻塞问题

HTTP / 1协议中延迟的主要原因是 head-of-line阻塞 问题. 网页(几乎总是)需要多种资源:CSS、JavaScript、字体、图像、AJAX/XMR等. 这意味着web浏览器需要向服务器发出多个请求. 然而，并不是所有的资源都是页面有用所必需的.

与HTTP / 1.浏览器必须完全完成一个请求, 包括完全接收响应, 在开始下一个请求之前. 一切都必须按顺序进行. 每个请求都会阻塞请求行，因此得名.

试图补偿HOL阻塞问题, 网络浏览器对单个服务器进行多个同时连接. 但是他们不得不随意限制这种行为:服务器, 工作站, 而且网络会因为连接过多而变得超负荷.

HTTP / 1.我介绍了一些改进来帮助解决这个问题. 最主要的是 流水线, 允许web浏览器启动新的请求，而不需要等待之前的请求完成. 这显著改善了低延迟环境中的加载时间.

但它仍然要求所有响应按照发出的顺序依次到达, 所以队伍的头仍然被挡住了. 令人惊讶的是，许多服务器仍然没有利用这个特性.

有趣的是,HTTP / 1.我也介绍过 维生, 它允许浏览器避免为每个HTTP请求创建新的TCP连接的开销. 这是解决tcp派生的性能问题的早期尝试. 它是如此无效，以至于大多数性能专家实际上都不赞成它，因为它会因为太多的非活动连接而使服务器陷入困境. 下面我们将仔细研究TCP，以及HTTP / 2是如何解决这个问题的.

HTTP / 2的HTTP HOL阻塞解决方案

HTTP / 2了 请求-响应多路复用 通过单个连接. 浏览器不仅可以在任何时候启动一个新的请求，而且 响应可以以任何顺序接收-阻塞在应用程序级别完全消除.

直接的结果是，这意味着精通HTTP / 2的web服务器可以最大限度地提高效率——稍后会详细介绍.

虽然请求-响应多路复用是HTTP / 2的主要特性, 它还包括其他几个重要特性. 读者可能会注意到它们在某种程度上是相关的.

HTTP / 2二进制帧

HTTP / 2将HTTP协议标准从低效的人类可读的ASCII请求-响应模型切换到高效 二元结构. 它不再只是一个请求和一个回应:

与HTTP / 2, 浏览器通过带有多个消息的双向流与服务器通信, 每个由多个帧组成.

HTTP / 2 HPACK(报头压缩)

HTTP / 2的新 头压缩使用HPACK格式，为大多数站点节省了大量带宽. 这是因为在连接中发送的请求的大多数头是相同的.

Cloudflare报告了显著的带宽节省 多亏了HPACK:

• 76%的输入报头压缩
• 总入口流量减少53%
• 出口报头压缩69%
• 1.出口总流量减少4%至15%

当然，使用更少的带宽通常意味着更快的网站.

HTTP / 2流优先级和服务器推送

这就是HTTP / 2的多路复用真正允许服务器最大化效率的地方. 多路复用确实有助于提供更快的资源.g.(如内存缓存的JavaScript)，然后才是较慢的(如JavaScript).g.、大图像、数据库生成的JSON等.). 但它也允许通过HTTP / 2的额外性能提升 流的优先级.

流优先级有助于确保页面几乎准备就绪的方面完全完成，而不必等待其他资源密集型请求完成. 这是通过加权依赖树实现的. 此树用于通知服务器应该为哪些响应分配最多的系统资源.

这对……尤其重要 渐进式web应用程序(pwa). 例如，假设一个页面有四个JavaScript文件. 两个用于页面功能，两个用于广告. 最糟糕的情况是加载一半的功能JS和一半的广告JS，然后继续加载大图, 在加载任何其他JS之前. 在这种情况下, 页面上的任何内容最初都不起作用, 因为所有东西都要等待最慢的资源.

使用流优先级, web浏览器可以指示服务器在发送任何广告JavaScript文件之前发送两个页面功能JS文件. 这样，用户就不必等到广告完全加载后才使用页面的功能. 尽管总体加载时间没有改善, 感知性能显著提高. 不幸的是, web浏览器中的这种行为主要还是算法的问题, 而不是被指定的 web开发人员.

同样，HTTP / 2的 服务器推送 特性允许服务器向浏览器发送尚未发出的请求的响应! 服务器可以利用传输中的间隙, 通过将服务器知道它将很快请求的资源预加载到浏览器中，有效地利用带宽. 这里的部分希望是消除资源内联的做法, 这只会使资源膨胀，使它们需要更长的加载时间.

不幸的是, 这两个功能都需要web开发人员仔细配置才能真正成功. 简单地启用它们 是不够的.

---

HTTP / 2显然带来了许多潜在的优势——其中一些优势比其他优势更便宜. 他们在现实世界中表现如何?

HTTP vs HTTP / 2采用

SPDY成立于2009年. HTTP / 2于2015年标准化. SPDY成为该代码的一个不稳定开发分支的名称, HTTP / 2将成为最终版本. 结果是SPDY已经过时了, 而HTTP / 2通常是每个人都遵循的标准.

标准化后, HTTP / 2(或“h2”)的采用率迅速增长到前1名的40%左右,000个网站. 这主要是由大型托管和云提供商代表他们的客户部署支持所驱动的. 不幸的是, 几年后, HTTP / 2的采用已经放缓，大部分互联网仍在使用HTTP / 1.

浏览器不支持HTTP / 2明文模式

有很多人要求HTTP / 2将加密作为标准的必要部分. 相反，该标准定义了加密(h2)和明文(h2c)模式. 因此，HTTP / 2可以完全取代HTTP / 1.

尽管标准, 目前所有的浏览器都只支持HTTP / 2加密连接，并有意不实现明文模式. 相反，浏览器依赖HTTP / 1向后兼容模式来访问不安全的服务器. 这是一种将网络默认为安全的意识形态推动的直接结果.

为什么HTTP / 3? 它有什么不同?

现在HTTP / 2修复了HTTP的行头阻塞问题, 协议开发人员已经将注意力转向了下一个最大的延迟驱动因素: TCP 排队头阻塞问题.

传输控制协议(TCP)

IP(因特网协议)网络是基于计算机相互发送数据包的思想. 数据包只是一些附加在顶部的寻址信息的数据.

但应用程序通常需要处理 流 的数据. 为了实现 这个错觉，传输控制协议(TCP)提供了应用 管 数据流可以通过它流动. 和大多数管道一样, 可以保证数据以进入管道的顺序退出管道, 也被称为“先入”, 先进先出法. 这些特性使得TCP非常有用并被广泛采用.

作为TCP提供的数据传递保证的一部分, 它必须能够处理各种各样的情况. 最复杂的问题之一是如何在网络过载时传递所有数据, 不会让大家的情况变得更糟. 这个算法叫做 拥塞控制 并且是Internet规范中不断发展的一部分. 没有足够的 拥塞控制，互联网就会陷入停顿.

1986年10月，互联网出现了一系列“拥塞崩溃”中的第一次.在此期间, 从LBL到加州大学伯克利分校(两地相距400码，三个IMP跳)的数据吞吐量从32 Kbps下降到40 bps.

V. 雅各布森(1988)

这就是TCP线首阻塞问题的由来.

TCP HOL阻塞问题

TCP拥塞控制通过实现 倒扣 和 重传 数据包机制，在检测到数据包丢失时使用. 退让的目的是帮助安抚网络. 重传确保数据最终被传递.

这意味着TCP数据可能会乱序到达目的地, 接收方有责任在将数据包重新组装到流中之前对其重新排序. 不幸的是, 这意味着一个丢失的数据包会导致整个TCP流暂停，而服务器等待它的重传. 因此，线的头部被阻塞.

谷歌的另一个项目旨在解决这个问题 引入一种叫做QUIC的协议.

QUIC协议是建立在UDP而不是TCP之上的，QUIC正在形成HTTP/3的基础.

什么是UDP?

用户数据报协议(UDP)是TCP的替代方案. 它不提供流的假象，也不提供TCP提供的相同保证. 而不是, 它只是提供了一种将数据放入数据包的简单方法, 把它发给另一台计算机, 然后发送出去. 它是 不可靠的, 无序，并且 不 配备任何形式的拥塞控制.

它的目的是轻量级的，并提供允许通信所需的最小功能. 这样应用程序就可以实现自己的保证. 这在实时应用程序中通常非常有用. 例如, 在电话中, 用户通常希望立即收到90%的数据, 而不是最终100%的数据.

HTTP/3的TCP HOL解决方案

解决TCP HOL阻塞问题需要的不仅仅是切换到UDP, 因为仍然有必要保证所有数据的传输，避免网络拥塞崩溃. QUIC协议旨在通过提供优化的HTTP over udp类型体验来实现所有这些.

由于QUIC接管了流管理、二进制帧等控制.在QUIC之上运行时，HTTP / 2要做的事情已经不多了. 这是QUIC + HTTP的新组合被标准化为HTTP/3的部分驱动因素.

注意:QUIC有很多版本, 因为该协议已经在生产环境中开发和部署了多年. 甚至还有一个谷歌专用的版本，叫做GQUIC. 像这样, 区分旧的QUIC协议和新的HTTP/3标准是很重要的.

总是加密

HTTP/3包含大量借用TLS的加密，但没有直接使用它. HTTP/3的主要实现挑战之一是需要修改TLS/SSL库以添加新需要的功能.

这种变化是因为HTTP/3在加密内容方面与HTTPS不同. 使用旧的HTTPS协议, 只有数据本身受TLS保护, 留下大量可见的传输元数据. 在HTTP/3中，数据和传输协议都受到保护. 这听起来像是一种安全功能，确实如此. 但这样做是为了避免HTTP / 2中存在的大量开销. 因此, 加密传输协议和数据实际上使协议更高效.

HTTP/3对网络基础设施的影响

HTTP/3并非没有争议. 主要关注的是网络基础设施.

客户端HTTP / 3

在客户端，UDP流量受到严重速率限制和/或阻塞是很常见的. 将这些限制应用于HTTP/3违背了协议的意义.

其次，HTTP被监视和/或拦截是很常见的. 即使是HTTPS流量, 网络定期观察协议的明文传输元素，以确定是否应该断开连接，以防止从特定网络或特定区域访问某些网站. 在一些国家，法律甚至规定某些服务提供商必须这样做. HTTP/3中的强制加密使得这是不可能的.

这不仅仅是政府层面的过滤. 许多大学, 公共图书馆, 学校, 而忧心忡忡的父母会主动选择屏蔽某些网站，或者至少记录下孩子访问过的网站. HTTP/3中的强制加密使得这是不可能的.

值得注意的是，有限过滤 is 目前可能. 这是因为服务器名称指示(SNI)字段携带网站的主机名，但不携带路径, 查询参数, 等.-仍未加密. 但随着ESNI(加密SNI)的引入，这种情况将在不久的将来发生变化。, 是最近加入TLS标准的吗.

服务器端的HTTP / 3

在服务器端, 最好的做法是阻止任何不需要流量的端口和协议, 这意味着服务器管理员现在需要为HTTP/3打开UDP 443, 而不是依赖于现有的TCP 443规则.

其次，网络基础设施可以建立TCP会话 黏糊糊的这意味着即使路由优先级发生变化，它们也将始终被路由到同一台服务器. 由于HTTP/3在udp(无会话)上运行，网络基础设施需要更新以跟踪HTTP/3特定的连接id, 它们没有被加密，是为了帮助粘接路由吗.

第三，对HTTP进行检查以检测滥用和监控是很常见的 常见的安全问题，检测和防止恶意软件和病毒的传播等. 由于HTTP/3的加密，这是不可能的. 仍然, 拦截设备拥有安全密钥副本的选项仍然是可能的, 假设设备实现HTTP/3支持.

最后, 很多管理员都反对管理更多的SSL证书, 不过现在的服务，比如 让我们加密 是可用的.

直到有广泛的接受, 解决这些问题的知名解决方案, 我认为很多大型网络可能会直接阻止HTTP/3.

HTTP/3对网络开发的影响

在这方面没什么好担心的. HTTP / 2的流优先级和服务器推送功能仍然存在于HTTP/3中. 对于web开发人员来说，这是值得的 熟悉这些特性 如果他们真的想优化他们的网站性能.

现在使用HTTP/3

谷歌Chrome浏览器的用户，或者开源的用户 铬 浏览器，已经设置为使用HTTP/3. 离生产质量的HTTP/3服务器版本还有一段路要走该规范 写这篇文章的时候还没有最终确定. 但与此同时，还有很多工具可供使用, 谷歌和Cloudflare都已经将支持推向了他们的生产环境.

最简单的方法是使用 球童 in 码头工人. 为此需要SSL证书，因此可公开访问的IP地址使事情变得容易. 步骤如下:

1. DNS设置. 获得一个在互联网上可用的主机名，例如.g. yourhostname.例子.com IN A 192.0.2.1.
2. 球童file创造. 它应该包含这些行:

    yourhostname.例子.com
    日志stdout
    错误stdout
    ext .html .htm .md .文本文件。
    浏览
    gzip
    tls youremailaddress@例子.com

1. 球童: docker运行-v cadyfile:/等/ cadyfile -p 80:80 -p 43:443 abiosoft/caddy——quic—or 外的码头工人, 球童——quic.
2. 运行启用了QUIC的chromium: 铬——enable-quic
3. (可选) 安装 a协议指示器扩展.
4. 导航到支持quic的服务器，其中应该可以看到文件浏览器.

开发人员还可以使用以下有用的工具测试他们的服务器:

• Keycdn的 HTTP / 2测试
• LiteSpeed的 HTTP3Check
• Qualys” SSL服务器测试

感谢阅读!

---