本文概述
HTTP/3即将问世, 紧随HTTP/2之后, HTTP/3本身还很年轻。从HTTP/1.1到HTTP/2花费了16年的时间, 有人真的应该关心HTTP/3吗？
简短的答案：是的, 这很重要, 你应该尽快掌握。就像HTTP/2通过将ASCII转换为二进制从HTTP/1.1进行重大更改一样。 HTTP/3再次进行了重大更改, 这一次是通过将基础传输从TCP切换到UDP进行的。
尽管HTTP/3仍处于设计阶段, 官方规范只是草案, 但已经在部署中, 很可能你会在今天的网络上找到运行它的版本。
但是HTTP/3的工作方式带来了一些新的难题。还有, 好处是什么？网络工程师, 系统管理员和开发人员需要知道什么？
TL; DR
- 更快的网站更成功。
- HTTP/2带来了巨大的性能提升, 因为它解决了HTTP行头阻塞问题(HOL)。它引入了请求/响应复用, 二进制成帧, 报头压缩, 流优先级划分和服务器推送。
- HTTP/3甚至更快, 因为它合并了所有HTTP/2, 并且还解决了TCP HOL阻塞问题。 HTTP/3仍然只是草案, 但已经在部署中。它更高效, 使用更少的资源(系统和网络), 需要加密(必须使用SSL证书)以及使用UDP。
- 尽管网络浏览器可能会在一段时间内继续支持旧版本的HTTP, 但是性能优势和搜索引擎优先使用HTTP/3的站点的优先级应推动新协议的采用。
- SPDY已过时, 使用它的任何人都应将其替换为HTTP/2。
- 今天的站点应该已经支持HTTP/1.1和HTTP/2。
- 在不久的将来, 网站所有者可能还会希望支持HTTP/3。但是, 它比HTTP/2更具争议性, 而且我们可能会看到许多较大的网络只是将其阻止而不是花时间去处理它。
主要问题：性能和效率
网站和应用程序开发人员通常会在实际使用他们的创作的情况下进行构建。有时受众群体是有限的, 但通常的想法只是吸引尽可能多的用户。自然, 网站变得越受欢迎, 它可以带来的收入就越多。
网站加载时间延迟100毫秒可能会导致转化率降低7％。 Akamai在线零售绩效报告：毫秒至关重要(2017年)
换句话说, 每天电子商务销售额为40, 000美元的电子商务网站由于这种延迟每年将损失一百万美元。
毫无疑问, 网站的性能对于变得越来越受欢迎至关重要。在线购物研究继续发现跳出率增加和加载时间延长之间的联系, 以及购物体验期间购物者的忠诚度和网站性能之间的联系。
研究还发现：
- 47％的消费者期望网页在2秒或更短的时间内加载。
- 40％的人放弃了耗时超过3秒的网站。
这就是十年前在线购物者的耐心状态。因此性能至关重要, HTTP/2和HTTP/3都意味着更好的网站性能。
HTTP/2？ …那是什么？
对HTTP/2协议的良好理解对于理解HTTP/3至关重要。首先, 为什么需要HTTP/2？
HTTP/2最初是一个名为SPDY的Google项目, 一项研究的结果表明, 网络上最大的性能问题是延迟。作者得出的结论是”更多的带宽无关紧要”：
如果我们将管道和Internet进行类比, 我们可以认为Internet的带宽就像水管的直径一样。较大的管道承载较大量的水, 因此你可以在两点之间输送更多的水。同时, 无论你的管道有多大, 如果管道是空的, 并且想要将水从一个点流到另一个点, 水流经管道都需要时间。用Internet的说法, 水从管道的一端流到另一端再返回的时间称为往返时间, 即RTT。迈克·贝尔谢
在研究中, 目标是减少页面加载时间。结果表明, 增加带宽最初会有所帮助, 因为从1 Mbps到2 Mbps可以将页面加载时间减半。但是, 好处很快就达到了高原。
相比之下, 减少等待时间将带来持续的收益并获得最佳结果。
HTTP HOL：标题行阻塞问题
HTTP/1协议中的延迟的主要原因是行头阻塞问题。网页(几乎总是)需要多种资源：CSS, JavaScript, 字体, 图像, AJAX / XMR等。这意味着Web浏览器需要向服务器发出多个请求。但是, 页面变得有用并不需要全部资源。
使用HTTP/1.0, 浏览器必须在开始下一个请求之前完全完成一个请求, 包括完全接收响应。一切都必须按顺序进行。每个请求都会阻塞请求行, 因此会阻塞名称。
为了弥补HOL阻塞问题, Web浏览器同时建立了到单个服务器的多个连接。但是他们不得不任意限制这种行为：服务器, 工作站和网络可能会因连接过多而变得超载。
HTTP/1.1引入了一些改进来帮助解决该问题。最主要的是流水线, 它允许Web浏览器启动新请求, 而无需等待先前的请求完成。这大大缩短了低延迟环境中的加载时间。
但是它仍然要求所有响应都按其顺序依次到达, 因此该行的头部仍然被阻塞。令人惊讶的是, 许多服务器仍未利用此功能。
有趣的是, HTTP/1.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格式的新标头压缩为大多数站点节省了大量带宽。这是因为大多数头对于连接内发送的请求都是相同的。
仅依靠HPACK, Cloudflare即可节省大量带宽：
- 入口标题压缩率达到76％
- 总入口流量减少53％
- 出口标头压缩69％
- 总出口流量减少1.4％至15％
当然, 使用较少的带宽通常意味着网站速度更快。
HTTP/2流优先级和服务器推送
在这里HTTP/2的多路复用确实可以使服务器最大程度地提高效率。多路复用确实有助于提供较快的资源(例如, 内存缓存的JavaScript), 而不是较慢的资源(例如, 大图像, 数据库生成的JSON等)。但它也可以通过HTTP/2的流优先级来进一步提高性能。
流优先级排序有助于确保完全准备好页面的几乎所有方面, 而不必等待其他资源密集型请求完成。这是通过加权依赖关系树完成的。该树用于通知服务器它应该分配最多的系统资源来服务的响应。
这对于渐进式Web应用程序(PWA)尤其重要。例如, 假设一个页面有四个JavaScript文件。两个用于页面功能, 两个用于广告。最坏的情况是先加载一半的功能JS和一半的广告JS, 然后再加载大图像, 然后再加载其余的JS。在这种情况下, 该页面上的任何内容最初都不起作用, 因为所有内容都必须等待最慢的资源。
借助流优先级, Web浏览器可以指示服务器在发送任何广告JavaScript文件之前先发送两个页面功能JS文件。这样, 用户在使用页面功能之前不必等待广告完全加载。尽管总加载时间没有改善, 但可以感觉到的性能已大大提高。不幸的是, Web浏览器中的这种行为仍主要是算法问题, 而不是由Web开发人员指定的。
同样, HTTP/2的服务器推送功能允许服务器将尚未发出的请求的响应发送到浏览器！服务器可以通过预加载浏览器知道服务器将很快请求的资源, 从而有效利用带宽来利用传输间隙。这里的部分希望是消除资源内联的做法, 这只会浪费资源, 并使它们需要更长的时间来加载。
不幸的是, 这两个功能都需要Web开发人员进行大量精心配置才能真正成功。仅启用它们是不够的。
HTTP/2显然带来了许多潜在的优势-其中一些优势比其他优势便宜。他们在现实世界中的表现如何？
HTTP与HTTP/2的采用
SPDY于2009年创建。HTTP/ 2于2015年标准化。SPDY成为代码不稳定开发分支的名称, 而HTTP/2成为最终版本。结果是SPDY已过时, HTTP/2通常是每个人都遵循的标准。
标准化之后, HTTP/2(或” h2″)的采用迅速增长到前1000个网站的约40％。这主要是由大型托管和云提供商代表他们的客户部署支持所驱动的。不幸的是, 几年后, HTTP/2的采用速度放慢了, 并且大多数Internet仍在HTTP/1上。
缺少浏览器对HTTP/2明文模式的支持
对于HTTP/2的调用很多, 以使加密成为标准的必需部分。相反, 该标准定义了加密(h2)和明文(h2c)模式。因此, HTTP/2可以完全替代HTTP/1。
尽管有该标准, 当前所有的Web浏览器仅支持通过加密连接的HTTP/2, 并且有意不实现明文模式。而是, 浏览器依靠HTTP/1向后兼容模式来访问不安全的服务器。这是意识形态推动默认情况下使网络安全的直接结果。
为什么使用HTTP/3？它有什么不同？
随着HTTP/2现在已经解决了HTTP头阻塞问题, 协议开发人员将注意力转移到了下一个最大的延迟驱动程序上：TCP头阻塞问题。
传输控制协议(TCP)
IP(互联网协议)网络基于计算机彼此发送数据包的思想。数据包只是在顶部附加了一些寻址信息的数据。
但是应用程序通常需要处理数据流。为了实现这种幻想, 传输控制协议(TCP)向应用程序提供了一条管道, 数据流可以通过该管道流动。与大多数管道一样, 可以保证数据将按照其进入的顺序退出管道, 也称为”先进先出”(FIFO)。这些特性使TCP变得非常有用并被广泛采用。
作为TCP提供的数据传递保证的一部分, 它必须能够处理各种情况。最复杂的问题之一是如何在网络过载时传送所有数据, 而不会使每个人的情况变得更糟。用于此的算法称为拥塞控制, 它是Internet规范不断发展的一部分。没有足够的拥塞控制, 互联网就会停顿下来。
86年10月, 互联网首次出现了一系列”拥塞崩溃”。在此期间, 从LBL到UC Berkeley(站点相距400码和三个IMP跳)的数据吞吐量从32 Kbps下降到40 bps。五·雅各布森(1988)
这就是TCP行头阻塞问题的出处。
TCP HOL阻塞问题
TCP拥塞控制通过对数据包实施退避和重传机制来工作, 每当检测到数据包丢失时都使用该机制。退避旨在帮助使网络平静。重传可确保最终传送数据。
这意味着TCP数据可能会无序到达目的地, 接收方有责任在将数据包重新组装到流中之前对其重新排序。不幸的是, 这意味着单个丢失的数据包可能导致整个TCP流在服务器等待其重新传输时暂停。因此, 线的头部被阻塞。
Google的另一个项目旨在通过引入称为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有许多版本, 因为该协议已经开发并在生产环境中部署了多年。甚至还有特定于Google的版本, 称为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中的强制加密使这成为不可能。
值得注意的是, 目前只能进行有限的过滤。这是因为服务器名称指示(SNI)字段(其中包含网站的主机名, 但未包含路径, 查询参数等)仍未加密。但是随着最近引入TLS标准的ESNI(加密的SNI)的引入, 这种情况将在不久的将来改变。
服务器端HTTP/3
在服务器端, 最佳做法是阻止所有不希望流量的端口和协议, 这意味着服务器管理员现在需要为HTTP/3打开UDP 443, 而不必依赖于现有的TCP 443规则。
其次, 网络基础结构可以使TCP会话具有粘性, 这意味着即使路由优先级发生变化, 它们也将始终被路由到同一服务器。由于HTTP/3在无会话的UDP上运行, 因此需要更新网络基础结构以跟踪特定于HTTP/3的连接ID, 而这些ID并未进行加密, 专门用于辅助路由。
第三, 检查HTTP以检测滥用情况, 监视常见的安全问题, 检测并防止恶意软件和病毒的传播等情况非常普遍。HTTP/ 3由于其加密而无法实现。不过, 假设设备实现了HTTP/3支持, 则拦截设备具有安全密钥副本的选项仍然可行。
最后, 许多管理员反对不得不管理更多的SSL证书, 尽管对于诸如”加密”之类的服务而言, 这已不再是一个问题。
在没有被广泛接受的知名解决方案来解决这些问题之前, 我认为许多大型网络可能会简单地阻止HTTP/3。
HTTP/3对Web开发的影响
在这方面不必担心。 HTTP/2的流优先级和服务器推送功能仍然存在于HTTP/3中。如果Web开发人员想要真正优化其网站性能, 则值得熟悉这些功能。
立即使用HTTP/3
Google Chrome或开放源代码Chromium浏览器的用户已设置为使用HTTP/3。 HTTP/3服务器的生产质量版本还有一点距离-在撰写本文时, 该规范尚未最终确定。但是与此同时, 有很多工具可以使用, Google和Cloudflare都已经将支持推向了他们的生产环境。
最简单的尝试方法是在Docker中使用Caddy。为此需要SSL证书, 因此可公开访问的IP地址使事情变得容易。这些步骤是：
- DNS设置。获取可在互联网上实时显示的有效主机名, 例如yourhostname.example.com在192.0.2.1中。
- 创建Caddyfile。它应该包含以下几行：
yourhostname.example.com
log stdout
errors stdout
ext .html .htm .md .txt
browse
gzip
tls [email protected]
- 运行Caddy：docker运行-v Caddyfile：/ etc / Caddyfile -p 80:80 -p 443：443 abiosoft / caddy –quic-或在Docker外部, caddy –quic。
- 在启用QUIC的情况下运行铬：chromium –enable-quic
- (可选)安装协议指示器扩展。
- 导航到启用QUIC的服务器, 在该服务器上应显示文件浏览器。
开发人员还可以使用以下有用的工具测试其服务器：
- Keycdn的HTTP/2测试
- LiteSpeed的HTTP3Check
- Qualys的SSL服务器测试
谢谢阅读！
作为Google Cloud合作伙伴, srcmini为公司提供开发解决方案, 并在其云之旅的每个阶段与他们合作。
