ChenSoul

原文链接：https://ably.com/topic/http2

可以毫不夸张地说，超文本传输协议 (HTTP) 造就了我们所熟知的互联网。 HTTP 最初是由万维网的发明者蒂姆·伯纳斯·李 (Tim Berners-Lee) 于 1989 年提出的应用程序协议。第一个记录版本 HTTP/0.9 被称为单行协议。鉴于它催生了万维网，它现在可以被描述为有史以来最伟大的俏皮话。

随着我们对互联网的需求不断增长，HTTP 作为网络协议也必须不断发展才能提供可接受的性能。 HTTP/2 标志着一次重大改革，是自 1997 年 HTTP/1.1 ( RFC 2068 ) 提供以来第一个新的标准化。本文介绍了 HTTP/2 如何设计来克服 HTTP/1.1 的限制、新协议的实现、HTTP/2 的工作原理以及其自身的限制。

通过单个 TCP 连接的 HTTP/2 客户端-服务器。

出身卑微——HTTP 简史

HTTP/0.9 的“单行协议”由请求组成：方法GET后跟文档地址、可选端口地址，并以回车符和换行符结束。由一串 ASCII 字符组成的请求。只能传输 HTML 文件。没有 HTTP 标头、状态代码或错误代码。

进化的第一阶段必须很快到来。

HTTP/1.0 – 突破限制

为了克服 HTTP/0.9 的严重限制，浏览器和服务器独立修改了协议。一些关键的协议更改：

• 请求允许包含多个由换行符分隔的标头字段。
• 服务器发送了包含单个状态行的响应。
• 响应中添加了一个标头字段。响应标头对象由由换行符分隔的标头字段组成。
• 服务器可以使用 HTML 以外的文件进行响应。

这些修改没有以有序或商定的方式完成，导致 HTTP/0.9 的不同风格，进而导致互操作性问题。为了解决这些问题，HTTP 工作组成立，并于 1996 年发布了 HTTP/1.0（RFC 1945）。它是一个信息性 RFC，仅记录当时的所有用法。因此，HTTP/1.0 不被视为正式规范或互联网标准。

HTTP/1.0 请求/响应的代码示例

来自客户端的使用 GET 方法的请求

GET /contact HTTP/1.0
Host: www.ably.io
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Accept: text/*, text/html, text/html;level=1, */*Accept-Language: en-us

客户端通过 POST 方法发出请求

POST /contact HTTP/1.0
Host: www.ably.io
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Accept: text/*, text/html, text/html;level=1, */*Accept-Language: en-us
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

200 正常响应

HTTP/1.0 200 OK
Date: Wed, 24 Jun 2020 11:26:43 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Server: cloudflare

HTTP/1.1 – 给混乱带来（一些）秩序

到 1995 年，HTTP 标准的开发工作已经开始。 HTTP/1.1 首次在RFC 2068中定义，并于 1997 年 1 月发布。1999 年 5 月在RFC 2616下发布了改进和更新。

HTTP/1.1 引入了许多功能增强和性能优化，包括：

• 持久连接和管道连接
• 虚拟主机
• 内容协商、分块传输、压缩和解压缩、传输编码和缓存指令
• 字符集和语言标签
• 客户识别和 cookie
• 基本身份验证、摘要身份验证和安全 HTTP

HTTP/1.1 请求/响应的代码示例

来自客户端的使用 GET 方法的请求

GET /contact HTTP/1.1
Host: www.ably.io
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Accept: text/*, text/html, text/html;level=1, */*Accept-Language: en-us

客户端通过 POST 方法发出请求

POST /contact HTTP/1.1
Host: www.ably.io
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Accept: text/*, text/html, text/html;level=1, */*Accept-Language: en-us
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

200 正常响应

HTTP/1.1 200 OK
Date: Wed, 24 Jun 2020 11:59:14 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Server: cloudflare

HTTP/1.1 日益严重的问题

在新千年期间，在 HTTP/1.1 的支持下，互联网的使用稳步增长。与此同时，网站不断变得更大、更复杂。网络状况报告中的这张图表显示，2016 年 11 月至 2017 年 11 月期间，桌面网站的中值大小增加了 30.6%，而这些网站的移动版本增加了 32.3%。

2016 年 11 月之后的一年中，网站规模的增加开始推动 HTTP 的能力，加载时间考验着用户的耐心。来源：HTTP 档案：网络现状。

用户不喜欢加载缓慢的网站。截至 2019 年 11 月，从台式计算机访问的网站的首次内容绘制 (FCP) 的中位时间为 2.4 秒。对于移动设备，FCP 的中位时间为 6.4 秒。为了保持读者的注意力不被打扰，FCP 应该低于一秒。

大部分延迟是由于 HTTP/1.1 的限制造成的。让我们看看其中一些限制以及开发人员克服这些限制的技巧。

队头阻塞

当由于一个或多个数据包被阻止而导致一系列数据包被阻止时，队头阻止会增加网站响应时间。客户端使用 HTTP/1.1 向服务器发送请求，通过传输控制协议 (TCP) 连接，服务器必须返回完整的响应，然后才能再次使用连接。在响应完成之前，后续请求将无法使用 TCP 连接。

响应 2 和 3 被阻塞，直到响应 1 被重新传输和传递。改编自10.5 探索队头阻塞。

起初，浏览器只允许与服务器有两个并发连接，并且浏览器必须等待其中一个空闲，从而造成瓶颈。允许浏览器建立六个并发连接的解决方法只是推迟了问题的解决。

开发人员开始使用域分片将内容分割到多个子域。这使得浏览器可以同时下载更多资源，从而使网站加载速度更快。这是以增加开发复杂性和增加 TCP 连接设置开销为代价的。

流水线

管道是一种客户端向服务器发送多个请求而不等待响应的技术。但是，服务器必须按顺序响应请求，并且客户端和服务器都必须支持它才能工作。

较大或较慢的响应可能会阻止其后面的响应，从而破坏流水线。管道化的实施具有挑战性，因为许多中介和服务器没有正确处理它。

HTTP/2 中的管道可以防止队头阻塞性能问题。改编自HTTP/2 vs HTTP/1 - 哪个更快？

协议开销 – 重复标头和 cookie

HTTP是无状态协议，每个请求都是独立的。服务器和客户端交换额外的请求和响应元数据。浏览器发起的每个 HTTP 请求都会携带大约 700 字节的元数据。服务器使用 cookie 进行会话管理。在每个请求中添加 cookie 后，协议开销就会增加。

解决方法是开发人员使用“无 cookie”域来提供不需要 cookie 的静态文件，例如图像、CSS 和 JavaScript。

TCP慢启动

TCP 慢启动是该协议的一项功能，通过探测网络来确定可用容量。 HTTP over TCP 从一开始就没有使用全部带宽容量。小规模传输对于 TCP 来说是昂贵的。为了克服 TCP 缓慢启动的问题，开发人员使用了诸如连接 JavaScript 和 CSS 文件以及分割小图像等技巧。

HTTP/2 的演变

简单性是 HTTP 的核心原则。然而，实现的简单性是以性能为代价的。正如我们在上一节中看到的，HTTP/1.1 有许多固有的局限性。随着时间的推移，这些限制变得太多，HTTP 需要升级。

2009 年，Google 发布了SPDY，一个实验性协议。该项目有以下高级目标：

• 目标是页面加载时间减少 50%。
• 最大限度地降低部署复杂性。
• 避免网站作者对内容进行任何更改。
• 将有兴趣探索协议作为解决延迟问题的方法的志同道合的各方聚集在一起。

2009 年 11 月，Google 工程师宣布他们的加载时间加快了 55%。到 2012 年，SPDY 得到了 Chrome、Firefox 和 Opera 的支持。

HTTP 工作组注意到了这一点，并开始努力利用 SPDY 的经验教训。 2012年11月，HTTP/2征集提案，并以SPDY规范为起点。

在接下来的几年里，HTTP/2 和 SPDY 共同进化，其中 SPDY 作为实验分支。 HTTP/2 于 2015 年 5 月作为提议标准发布 ( RFC 7540 )。

底层：HTTP/2 的描述

从较高层面来看，HTTP/2 旨在解决 HTTP/1.1 的问题。让我们看一下 HTTP/2 是如何工作的。需要记住的一个重要方面是 HTTP/2 是 HTTP/1.1 的扩展，而不是替代品。它保留了HTTP/1.1的应用语义。功能、HTTP 方法、状态代码、URI 和标头字段保持不变。

HTTP/2 消息的结构

HTTP/2 具有高度结构化的格式，其中 HTTP 消息被格式化为数据包（称为帧），每个帧分配给一个流。 HTTP/2 帧具有特定的格式，包括在每个帧开头声明的长度以及帧头中的几个其他字段。

在许多方面，HTTP 帧与 TCP 数据包相似。读取 HTTP/2 帧遵循一个定义的过程：前 24 位是该数据包的长度，后面的 8 位定义帧类型，依此类推。

帧头之后是有效负载。这可以是 HTTP 标头或正文。这些也具有预先已知的特定格式。 HTTP/2 消息可以在一个或多个帧中发送。

相比之下，HTTP/1.1 是一种由 ASCII 文本行组成的非结构化格式。最终，它是一个字符流，而不是被专门分成单独的片段/框架（除了行的区别）。

HTTP/1.1 消息（或至少第一个 HTTP 请求/响应行和 HTTP 标头）通过一次读入一个字符来进行解析，直到到达新行字符。这很混乱，因为您事先不知道每行有多长。

在 HTTP/1.1 中，HTTP 主体长度的处理方式略有不同，因为它通常在 Content-Length HTTP 标头中定义。 HTTP/1.1 消息必须作为一个连续的数据流完整发送，并且在完成之前连接只能用于传输该消息。

每个 HTTP/2 连接都以 HTTP/1.1 启动，如果客户端支持 HTTP/2，连接就会升级。 HTTP/2 在客户端和服务器之间使用单个 TCP 连接，该连接在交互期间保持打开状态。

HTTP/2 设计特点

HTTP/2 引入了许多旨在提高性能的功能：

• 用二进制协议替换文本协议。二进制成帧层创建交错的通信流。
• 完全多路复用而不是有序和阻塞（这意味着它可以使用一个连接来实现并行性）。
• 流控制以确保流是非阻塞的。
• 流优先级可解决由多个请求和响应的分割和复用引起的问题。
• 标头压缩以减少开销。有关详细信息，请参阅标头压缩。
• 服务器推送。主动将响应从服务器“推送”到客户端缓存中。

二进制框架层

二进制成帧层负责 HTTP/2 中的所有性能增强，制定客户端和服务器之间消息封装和传输的协议。

HTTP/2 中添加到应用层的二进制成帧层。改编自HTTP/2 简介。

二进制成帧层将客户端和服务器之间的通信分成小块，并创建交错的双向通信流。由于二进制帧层，HTTP/2 使用单个 TCP 连接，该连接在交互期间保持打开状态。

在继续之前，让我们先看看 HTTP/2 中使用的一些术语。

HTTP/2 术语

**框架。**帧是 HTTP/2 中最小的通信单元。帧携带特定类型的数据，例如 HTTP 标头或有效负载。所有帧均以固定的 9 个八位字节标头开始。除其他内容外，标头字段还包含流标识符字段。标头后面是可变长度的有效负载。帧有效负载的最大大小为 2^24 - 1 个八位位组。

**信息。**消息是一个完整的 HTTP 请求或响应消息。消息由一个或多个帧组成。

**溪流。**流是客户端和服务器之间的双向帧流。流的一些重要特征是：

• 单个 HTTP/2 连接可以有多个并发打开的流。客户端和服务器可以从连接上的不同流发送帧。流可以由客户端和服务器共享。流也可以由单个对等方建立和使用。
• 任一端点都可以关闭流。
• 流中帧的顺序很重要。接收器按照接收帧的顺序处理帧。标头和数据帧的顺序具有语义意义。
• 一个整数标识流。标识整数由发起流的端点分配。

HTTP/2 中的多个连接打开流显示标头和数据帧。

全复用

二进制分帧层解决了队头阻塞的问题，使得HTTP/2完全复用。正如我们所提到的，二进制成帧层根据客户端和服务器之间发送的信息“块”创建交错的双向流。

客户端或服务器可以指定其他对等方可以发起的并发流的最大数量。对等方可以随时减少或增加此数字。

流量控制

此时，您一定想知道为什么单个 TCP 连接上的多路复用不会导致队头阻塞。

HTTP/2 使用流量控制方案来确保流是非阻塞的。流量控制只是一个整数，表示服务器、客户端或中介（如代理服务器）的缓冲能力。流量控制用于各个流和整个连接。对于新流和整个连接，流量控制窗口的初始值为 65,535 个八位位组。

对等方可以使用 WINDOW_UPDATE 帧来更改它可以缓冲的八位字节的值。服务器、客户端和中介体可以独立地通告其流量控制窗口并遵守其对等体设置的流量控制窗口。

HTTP/2 中的流量控制控制流的大小以防止队头阻塞。

流优先级

HTTP/2 协议允许将多个请求和响应分割成帧并进行复用。传输顺序对于性能变得至关重要。 HTTP/2 使用流优先级来解决这个问题。客户端使用两个规则创建优先级树：

• 一个流可以依赖于另一个流。如果没有给一个流明确的依赖关系，那么它依赖于根流。流具有父子关系。
• 所有相关流都可以被赋予 1 到 256 之间的整数权重。

HTTP/2 中的流权重和流依赖性。 改编自HTTP/2 简介。

父流在其从属流之前传递。同一父级的依赖流应该获得与其权重成比例的资源。但是，共享同一父级的从属流不会相互排序。

可以使用独占标志添加新级别的依赖关系。独占标志使流唯一依赖于其父流。最后，可以使用 PRIORITY 标志更改流优先级。

标头压缩

HTTP 请求包含标头和 cookie 数据，这会增加性能开销。 HTTP/2 使用 HPACK 压缩格式来压缩请求和响应元数据。传输的标头字段使用霍夫曼编码进行编码。 HTTP/2 要求客户端和服务器维护和更新先前见过的标头字段的索引列表。索引列表用作有效编码先前传输的值的参考。

服务器推送

服务器推送是一项性能功能，允许服务器在客户端请求响应之前将响应发送到符合 HTTP/2 的客户端。当服务器知道客户端需要“推送”响应来完全处理原始请求时，此功能非常有用。

服务器推送有可能通过利用网络空闲时间来提高性能。然而，如果实施不当，服务器推送可能会适得其反。

推送已经在客户端缓存中的资源会浪费带宽。浪费带宽有机会成本，因为它可以用于相关响应。

HTTP/2 的缓存摘要是解决此问题的拟议标准。同时，可以通过仅推送第一次访问并使用“缓存摘要”来解决该问题。

推送的资源与 HTML 的交付发生竞争，从而对页面加载时间产生不利影响。开发者可以通过限制推送资产的大小来避免这种情况。

使用 Node.js 运行 HTTP/2 服务器的代码示例

您可能需要更新 Node.js 版本才能使用 HTTP/2 模块。

需要考虑的一件重要事情是，目前没有浏览器支持不加密的 HTTP/2，这意味着我们需要将服务器配置为通过安全连接 (HTTPS) 工作。

大多数现代框架和服务器现在都支持 HTTP/2。以下是使用 Node.js 启动 HTTP/2 Web 服务器的简单示例：

const http2 = require('http2');
const fs = require('fs');
 
function onRequest (req, resp) {
    resp.end("Hello World");
}
 
const server = http2.createSecureServer({
  key: fs.readFileSync('localhost-privkey.pem'),
  cert: fs.readFileSync('localhost-cert.pem')
}, onRequest);
 
server.listen(8443);

运行代码后，打开您选择的支持 HTTP/2 的 Web 浏览器。然后，访问以下 URL：https://localhost:8443/stream。

HTTP/2 和 HTTP/1.x 之间的差异

非管道、管道和多路复用流中的流量比较。改编自LoadMaster - HTTP/2。

注意：

• HTTP/1.x 标头以纯文本形式传输，但 HTTP/2 会压缩标头。
• 服务器可以将客户端未请求的内容推送给客户端。
• 在 HTTP/1.1 中，发生错误时客户端无法重试非幂等请求。某些服务器处理可能在错误之前发生，重新尝试可能会产生不良影响。 HTTP/2 具有保证请求未被处理的机制。
• HTTP/2 可能会发生 TCP 线头阻塞，但如上图（对于多路复用 HTTP）所示，响应 2 可以在响应 1 之前完成。将响应 1 视为跨越 HTTP/2 数据帧的大型媒体文件，而响应2 是适合单个 HTTP/2 帧的少量文本。客户端将在响应 2 的第一帧之前接收到响应 1 的第一帧，但是 HTTP/2 对这些帧进行复用，客户端不必在获取响应 1 的第一个帧之前等待响应 1 的其他 99 帧（并且仅) 响应 2 的帧。然后响应 2 完成，同时响应 1 仍在发送。

实施 HTTP/2

目前，所有浏览器都支持 HTTPS 上的 HTTP/2 协议。要通过 HTTP/2 为应用程序提供服务，必须使用 SSL 证书配置 Web 服务器。您可以使用Let’s Encrypt快速启动并运行免费的 SSL 证书。

所有主要服务器软件都支持 HTTP/2：

• Apache Web Server 版本 2.4.17 或更高版本通过 mod_http2 支持 HTTP/2，无需添加补丁。可以从以下位置下载：https://httpd.apache.org/download.cgi#apache24。版本 2.4.12 通过 mod_h2 支持 HTTP/2。但是，必须对服务器的源代码应用补丁。
• NGiNX 版本 1.9.5 及更高版本支持 HTTP/2。从1.13.9版本开始支持Server Push。从以下位置下载最新、稳定和旧版本：http://nginx.org/en/download.html
• Microsoft IIS在 Windows 10 和 Windows Server 2016 中支持 HTTP/2。IIS 包含在 Windows 10 中，但默认情况下未打开。使用控制面板中的打开和关闭 Windows 功能链接，然后查找 Internet 信息服务。另请参阅iis.net。

陷阱：HTTP/2 的设计注意事项

HTTP/2 允许客户端通过单个 TCP 连接同时发送所有请求。理想情况下，客户端应该更快地接收资源。另一方面，并发请求会增加服务器的负载。对于 HTTP/1.1，请求是分散的。但使用 HTTP/2，服务器可以大批量接收请求，这可能会导致请求超时。服务器负载激增的问题可以通过插入负载均衡器或代理服务器来解决，这可以限制请求。

大多数浏览器限制到给定源（方案、主机和端口的组合）的并发连接数，并且 HTTP/1.1 连接必须在单个连接上串行处理。这意味着 HTTP/1.1 浏览器有效地限制了对该源的并发请求数量，这意味着用户的浏览器会限制对其服务器的请求并保持流量顺畅。

服务器对 HTTP/2 优先级的支持尚不成熟。软件支持仍在不断发展。某些 CDN 或负载均衡器可能无法正确支持优先级。

如果不明智地使用 HTTP/2 推送功能，弊大于利。例如，返回的访问者可能拥有文件的缓存副本，并且服务器不应推送资源。让服务器推送缓存感知可以解决这个问题。然而，缓存感知推送机制可能会变得复杂。

HTTP/2 解决了 HTTP/1.1 级别的队头阻塞问题。但是，TCP 流的数据包级队头阻塞仍然可以阻塞连接上的所有事务。

HTTP/2 的替代方案

以下技术可用作标准形式的 HTTP/2 的替代方案，以增强实时使用的性能。

WebSockets

WebSocket 构建于 HTTP/1.1 之上，提供完全双向通信。 WebSocket 协议提高了互联网通信的可能性，并实现了真正的实时网络。

WebSocket 是构建在设备 TCP/IP 堆栈之上的薄传输层。其目的是为 Web 应用程序开发人员提供本质上尽可能接近原始的 TCP 通信层，同时添加一些抽象以消除 Web 工作方式中可能存在的摩擦。

与 REST 相比，WebSocket 具有更高的效率，因为它们不需要为发送和接收的每条消息产生 HTTP 请求/响应开销。当客户端想要持续更新资源状态时，WebSockets 通常是一个不错的选择。

请参阅 Ably 主题WebSockets - 概念深入探讨了解更多详细信息，并参阅WebSockets 与 HTTP比较这两个框架。

MQTT（消息队列遥测传输）

广泛应用于物联网项目的应用层协议。它的适用性来自于其尺寸小、功耗低、数据包最小化以及易于实施。

MQTT 是一种网络协议，专门用于实现物联网 (IoT) 设备之间的高效通信。这是因为它尺寸小、功耗低、数据包最少并且易于实施。

除此之外，与 HTTP 不同的是，MQTT 不遵循请求/响应机制进行通信。相反，它使用发布-订阅范例 (pub/sub)。

请参阅 Ably 主题MQTT：概念深入探讨了解更多详细信息。

服务器发送的事件 (SSE)

SSE 是一种开放、轻量级、仅限订阅的事件驱动数据流协议。 SSE 通过 HTTP/1.1 和 HTTP/2 作为 HTTP 之上的层提供流事件。

SSE 连接只能将数据推送到浏览器（因此称为“服务器发送”）。可以从 SSE 中受益的应用程序的好例子是在线股票报价和社交媒体服务 Twitter 的更新时间表。

理想情况下，当从服务器请求数据时，一个简单的 XMLHttpRequest 就可以了。但是，在您希望使用 XHR 流保持连接打开的情况下，这会带来一系列开销，包括处理解析逻辑和连接管理。

在这种情况下，您可以使用 SSE。 SSE 提供了一个连接管理和解析逻辑层，使我们能够轻松地保持连接打开，同时服务器在新事件可用时将其推送到客户端。

实际上，可以使用 SSE 完成的所有操作也可以使用 WebSocket 完成。然而，对于某些类型的应用程序来说，使用 WebSocket 可能有些过大，并且使用 SSE 等协议可以更轻松地实现后端。

SSE 的另一个可能的优点是，它可以仅使用 JavaScript 来填充到本身不支持它的旧浏览器中。

有关更多详细信息，请参阅 Ably 主题服务器发送事件 (SSE)：概念深入探讨。

HTTP/3

HTTP/3 是 HTTP 的新迭代，自 2018 年以来一直在开发中，尽管在撰写本文时尚未标准化，但一些浏览器已经在使用它。

HTTP/3 的目标是通过解决 HTTP/2 的传输相关问题，在所有形式的设备上提供快速、可靠且安全的 Web 连接。为此，它使用了一种名为 QUIC 的不同传输层网络协议，该协议在用户数据报协议 (UDP) 互联网协议上运行，而不是在所有早期版本的 HTTP 中使用的 TCP。

请参阅 Ably 主题HTTP/3 Deep Dive了解更多详细信息或阅读HTTP/2 与 HTTP/3：比较。

结论

HTTP/2 针对速度进行了优化，从而带来更好的用户体验。使用 HTTP/2 还可以给开发人员带来快乐，因为不再需要使用域分片、资产串联和图像分割等技巧。这降低了开发复杂性。

与其前身相比，HTTP/2 使网页浏览变得更加容易和更快。它具有较低的带宽使用率，这意味着 HTTP/2 终于能够充分利用过去 16 年 IT 的最新发展，而 HTTP1.1 无法做到这一点。

HTTP/2 专注于性能，尤其是在用户端。此外，也不需要为绕过旧版本的问题而开发的许多技巧。

HTTP/2 专为 Web 流量而设计，特别是围绕服务 Web 内容的需求。然而，对于实时通信，特别是客户端和服务器之间的双向通信，WebSockets 和 MQTT 等协议更适合。

HTTP/2 和 Ably

Ably 是一个企业级发布/订阅消息平台。我们可以轻松高效地设计、快速交付和无缝扩展直接交付给最终用户的关键实时功能。每天，我们向数千家公司的数百万用户发送数十亿条实时消息。

我们为人们、组织和企业每天依赖的应用程序提供支持，例如Lightspeed System为超过 700 万学校拥有的设备提供的实时设备管理平台、Vitac为数亿多语言观众提供的针对奥运会和斯普利特奥运会等活动的实时字幕每月一万亿个功能标记的实时功能标记。

我们是唯一一个拥有一套内置服务来构建完整实时功能的pub/sub 平台：在送货上门应用程序上显示驾驶员的实时 GPS 位置，历史记录在打开体育应用程序时立即加载最新分数，流恢复会在交换网络时自动处理重新连接，并且我们的集成将 Ably 扩展到第三方云和系统，例如 AWS Kinesis 和 RabbitMQ。凭借 25 多个 SDK，我们针对网络、移动和物联网的每个主要平台。

我们的平台围绕可靠性的四大支柱进行数学建模，因此我们能够确保消息不会丢失，同时仍通过安全、可靠且高度可用的 全球边缘网络以低延迟传送。

从初创公司到工业巨头的开发人员都选择在 Ably 上进行构建，因为它们可以简化工程、最大限度地减少 DevOps 开销并提高开发速度。

进一步阅读

• WebSockets - A Conceptual Deep Dive
• The realtime web: evolution of the user experience
• MQTT: A Conceptual Deep Dive
• Server-Sent Events (SSE): A Conceptual Deep Dive
• HTTP evolution - HTTP3 Deep dive
• HTTP/2 vs HTTP/3: A Comparison
• WebSockets vs. HTTP

See also the Medium article: Exploring http2 (Part 2): with node-http2 core and hapijs