http/2将淘汰websocket? http/3将使用udp? http新闻

WebSocket能否在HTTP / 2中存活？

原文: https://www.infoq.com/articles/websocket-and-http2-coexist/

我们正处于互联网所依赖的协议的重大转变之中：HTTP。这一变化提出了许多问题和疑虑，我们正在听取和阅读有关HTTP / 2的许多好（和坏）信息。虽然它提供了很多，但HTTP / 2并不能完全取代对现有推送/流技术的需求。

注意HTTP / 2的第一个重要事项是它不是所有HTTP的替代品。动词，状态代码和大多数标题将保持与今天相同。HTTP / 2的目的是提高数据在线路上的传输方式。

让我们来看看与HTTP 1.x相比的主要差异以及每个改进所解决的问题：

• HTTP / 2是一种二进制协议，其中HTTP 1.x是文本的。二进制协议的解析效率更高，因为只有一个代码路径，其中HTTP 1.x定义了4种不同的解析消息的方法。二进制协议在线路上也更节省空间。作为回报，人类更难以处理它们，因为它们不是人类可读的。权衡。
• HTTP / 2被多路复用以解决称为线头阻塞（HOL阻塞）的网络中的已知限制。当在单个TCP连接（即HTTP流水线）上发出多个请求时，HTTP 1.1可能会发生此问题。由于整个连接是有序和阻塞的（FIFO），慢速请求可以阻止连接，从而减慢所有后续请求。多路复用通过允许多个请求和响应同时在线上飞行来最终解决此问题。
• HTTP / 2使用标头压缩来减少开销。典型的1KB标头大小是常见的，主要是因为我们都必须接受cookie才能获得流畅的用户体验。传输1KB可能需要多次网络往返才能交换标头，并且由于HTTP 1.x的无状态特性，每次都会重新发送这些标头。TCP慢启动通过限制在第一轮往返期间可以发送的数据包的数量来使问题更严重，直到TCP有效地完成探测网络以找出可用容量并适当地调整其拥塞窗口。在这种情况下，压缩标头显着限制了所需的往返次数。
• HTTP / 2服务器推送允许服务器主动将响应发送到客户端缓存。在典型的HTTP 1.x工作流中，浏览器请求页面，服务器在响应中发送HTML，然后需要等待浏览器解析响应并发出其他请求以获取其他嵌入资源（JavaScript，CSS）等）。服务器推送允许服务器推测性地开始向客户端发送资源。在这里，浏览器不必解析HTML页面并找出要加载的其他资源; 相反，服务器可以立即开始发送它们。

现在，如果我们将HTTP / 2与WebSocket进行比较，我们可以看到很多相似之处：

鉴于这些改进和类似功能，很自然地会问：HTTP / 2是WebSocket或SSE等推送技术的替代品吗？

好吧，答案显然是否定的，原因很简单：正如我们上面所见，HTTP / 2引入了服务器推送，使服务器能够主动将资源发送到客户端缓存。但是，它不允许将数据推送到客户端应用程序本身。服务器推送仅由浏览器处理，不会弹出到应用程序代码，这意味着应用程序没有API来获取这些事件的通知。

这是服务器发送事件（SSE）变得非常有用的地方。SSE是一种机制，允许服务器在建立客户端 - 服务器连接后将数据异步推送到客户端。然后，只要有新的“数据块”可用，服务器就可以决定发送数据。它可以被视为单向发布 - 订阅模型。它还提供了一个标准的JavaScript客户端API，名为EventSource，在大多数现代浏览器中实现，作为W3C的HTML5标准的一部分。请注意，不支持EventSource API的浏览器可以轻松填充。

由于SSE基于HTTP，因此它与HTTP / 2非常吻合，可以结合使用以实现两者的最佳效果：HTTP / 2处理基于多路复用流的高效传输层和SSE，为应用程序提供API以启用推。

为了完全理解Streams和Multiplexing的全部内容，让我们先来看看IETF的定义：“stream”是在HTTP / 2连接中在客户端和服务器之间交换的独立的双向帧序列。其主要特征之一是单个HTTP / 2连接可以包含多个并发打开的流，其中任一端点交织来自多个流的帧。

为了避免让你第二次阅读上面的定义以确保你完全理解它（自己做了:-)），来自Nginx博客的这个模式清楚地解释了它：

如果您想在工作中尝试HTTP / 2多路复用，请在您喜欢的浏览器上打开开发人员终端的同时试用此演示。如果你不能确定你喜欢的浏览器是HTTP / 2兼容然而，有一个快看这里。

使用HTTP / 1你应该得到这样的东西：

浏览器并行打开多个HTTP 1.x连接以加速页面加载。浏览器对可以在域上打开的最大并发连接有不同的限制，但它们通常支持大约6个不同的连接。为了克服这种限制，可以使用诸如域分片之类的技术来跨多个域分发资源。这些技术（我们可以认为是黑客攻击）包括连接JavaScript和CSS文件，spriting图像和资源内联在HTTP / 2世界中会适得其反。这可能是考虑切换到HTTP / 2时的主要影响之一：消除几年内的优化/黑客攻击。

在尝试使用HTTP / 2时，我们看到浏览器使用单个多路复用连接，加载时间要快得多。

现在我们已经了解了多路复用的全部内容，我们必须记住SSE是基于HTTP的。这意味着使用HTTP / 2，不仅可以将多个SSE流交织到单个TCP连接上，还可以将多个客户端请求（客户端到服务器）的几个SSE流（服务器到客户端推送）交错。感谢HTTP / 2和SSE，我们现在拥有一个纯HTTP双向连接和一个简单的API，让应用程序代码注册到服务器推送。在将SSE与WebSocket进行比较时，缺乏双向功能通常被认为是一个主要缺点。感谢HTTP / 2不再是这样了。这开启了跳过WebSockets并坚持基于HTTP的信令的机会。

为初始问题提供一些答案：WebSocket能否在HTTP / 2中存活？

它肯定会，主要是因为它已经被很好地采用，并且在非常具体的用例中，它具有优势，因为它是从头开始构建的，具有较少的开销（头部）的双向功能。假设您需要从两端交换高吞吐量的消息，上游的数据流量几乎与下游相同（例如，需要让所有玩家保持同步的大型多人在线游戏）。WebSocket可能仍然是一个更好的选择。

如果您考虑显示实时市场新闻，市场数据，聊天应用程序等用例，依靠HTTP / 2 + SSE将为您提供高效的双向通信渠道，并保持留在HTTP世界的巨大优势：

• 在考虑与现有Web基础结构的兼容性时，WebSocket通常会成为痛苦的根源，因为它将HTTP连接升级为与HTTP无关的完全不同的协议。
• 规模和安全性：Web组件（防火墙，入侵检测，负载均衡器）的构建，维护和配置都考虑了HTTP，这是大型/关键应用程序在弹性，安全性和可伸缩性方面更喜欢的环境。

小贴士

• HTTP / 2不是HTTP的完全替代品。
• 诸如域分片，资源内联和图像精灵等黑客在HTTP / 2世界中会适得其反。
• HTTP / 2不能替代WebSocket或SSE等推送技术。
• HTTP / 2推送服务器只能由浏览器处理，而不能由应用程序处理。
• 结合HTTP / 2和SSE可提供高效的基于HTTP的双向通信。

WebSocket可能会继续使用，但SSE及其EventSource API与HTTP / 2的强大功能相结合将在大多数用例中提供相同的结果，只是更简单。

关于作者

Allan Denis在无线通信和分布式计算领域拥有超过10年的经验。在业余时间，他喜欢在法国的Alpes山谷骑自行车。Allan是Streamdata.io的首席技术官。

HTTP / 3用UDP替换TCP以提高网络速度，可靠性

原文: https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/

为站点和服务获得HTTP / 2的性能和安全性优势意味着进行体系结构更改，因为它颠覆了用于提高网站性能的分片等原则; 这可能就是为什么只有大约35％的网站目前使用HTTP / 2。

HTTP / 3加倍，提供非常相似的功能，但用UDP替换TCP。这一次可能需要对网络基础设施进行更根本的改变，以便利用比较差的连接和移动网络更好的性能，但对于大多数开发人员来说，这种改变将是透明的。

HTTP / 3是该协议的第三个主要版本，它包括TLS 1.3和一种称为QUIC（Quick UDP Internet Connection）的新传输协议; 根据最初由Google设计的2013协议，现在有多个贡献者和公司通过互联网工程任务组（IETF）参与其中。

不可靠是一个机会

放弃HTTP一直用于UDP的TCP连接并不像看起来那么奇怪。U有时会扩展为“不可靠”而不是用户数据报协议，因为它不保证消息传递或数据包顺序。但是对于今天的网络，这实际上是一个提高HTTP / 2引入的多路复用连接性能的机会。“凭借HTTP / 3，我们将在同一个旧的不可靠互联网之上构建一个新的可靠协议，” Cloudflare首席技术官John Graham-Cumming告诉New Stack。

HTTP / 2通过在同一连接上发送多个HTTP请求，允许应用程序同时处理请求，从而更好地利用网络带宽。但只有在网络运行良好时才能实现这些收益。“你可以最大限度地提高吞吐量和带宽，因为TCP可以达到它可以达到的最大速度，并且所有并行连接都能以最快的速度运行，”Graham-Cumming说。

这很好，直到网络连接出现打嗝，如网络拥塞或在移动网络上从一个小区移动到另一个小区并且数据包丢失。“TCP保证发送数据包的顺序是应用程序接收的顺序 - 所以如果你错过了，那么一切都必须停止，直到特定数据包被重新传输。如果将多个请求复用到单个TCP连接上，则所有这些请求都必须停止并等待，即使丢失的数据包可能只影响其中一个。

Graham-Cumming解释说，这种“线路阻塞问题”是TCP固有的问题，使用UDP通过允许应用程序控制数据包的重传来修复它。“它可以说'数据包丢失，但它只影响这一个数据流，而其他数据流可以继续运行'。”这使得QUIC 在恶劣的网络条件下更加强大。

HTTP / 3的连接迁移提议可以扩展在不同网络之间移动的稳健性，例如从Wi-Fi到移动宽带，这通常会因为IP地址的变化而破坏网络连接。“通过此提议，您和服务器之间的标识符将不是IP地址，而是协议本身内的标识符。这样您就可以在新网络上自动重启整个连接，这样您就可以无缝地从Wi-Fi转移到移动连接。原始互联网的一些假设是，存在相当固定的连接，我们现在正在进入一个非常移动的异构世界。“

Graham-Cumming解释说，HTTP / 3还直接集成了TLS，QUIC对数据包传输的额外控制也具有优势。“当事情通过互联网发送时，它们会被分解成数据包; 在TLS中，有一个传输数据缓冲区的概念。如果你想要真正有效率，你想要把所有这些事情排好; 这是一个请求，我将对它进行加密并通过互联网进行传输，以便一次性收到所有这些请求，并且不会分成较小的数据包，其中一些不会被延迟。如果您控制所有级别，如果您只是假设互联网是一种不可靠的发送数据包的方式，那么您可以控制发送内容的顺序，您可以控制加密它们的方式以及这些加密块如何传输。“

与HTTP服务器的初始连接将更快，因为HTTP / 3取出了通常需要建立连接的往返之一安全解释说，Mozilla首席工程师Martin Thomson是QUIC规范的编辑之一。

“使用TCP和TLS，连接设置以TCP握手开始：客户端发送SYN，服务器响应SYN + ACK，客户端使用ACK完成。然后在发送任何请求之前有一个TLS握手 - 它需要另一个类似的三个消息交换。QUIC在大多数情况下将其压缩到单个交换。一个关键特性是0-RTT，允许客户端立即发送请求; 这是TCP和TLS的一个选项，但你仍然需要等待TCP握手完成。“

默认安全

集成TLS还可以提高安全性，因为身份验证和加密是由网络协议提供的，而不是像TLS这样的高级协议提供的 - 并且在HTTP / 3中内置了TLS，使用它也不是可选的。Graham-Cumming指出：“业界正试图在默认情况下保证一切安全。” 当站点使用HTTPS时，浏览器现在会在站点没有加密连接时向您发出警告，而不是显示锁定。HTTP / 3和QUIC是这个方向的另一个举措。

“更多的QUIC是加密的，”汤姆森解释道。这包括攻击者可能尝试使用的元数据。“除了一些有助于将数据包识别为QUIC数据包的比特之外，未加密的QUIC数据包的唯一部分是连接的不透明标识符。这包括TCP和TLS无法保护的内容，例如确认（'我从你那里得到5个字节'）。“

Thomson还认为加密实际上将简化部署QUIC。将新协议部署到需要更新的防火墙，路由器，NAT和其他网络设备上的复杂性阻碍  了创建新的，更有效的传输协议以及延迟在浏览器中采用TLS 1.3的努力。“这是部署QUIC的部分原因。互联网往往会干扰新的协议，加密将保护QUIC免受干扰。“

他坚持认为，这是UDP是一个不错的选择的另一个原因。“新的协议不能直接部署在IP之上，如TCP或UDP，因为这需要更新的互联网。考虑更换或升级每个想要使用此新协议的房屋中的每个路由器的前景。UDP在这种情况下是理想的，因为它做得很少。它非常轻巧，因此我们可以在顶部构建所有必需的部件。UDP的主要缺点是已经显示阻止或降级UDP的少量网络。在极少数情况下，我们有HTTP / 2可以依靠。“

当用户访问站点时，他们的初始连接将通过HTTP或HTTP / 2，服务器将提供HTTP / 3作为替代; 了解提供该连接的标头的浏览器将记住它以供下次访问，但较旧的浏览器和设备将继续使用旧协议。格雷厄姆 - 卡明预测说：“我们预计HTTP / 2和1.1将会存在很长时间。”

网络变化

HTTP / 3可能有它的名字，但它仍在开发中; Graham-Cumming表示，情况稳定前几个月。尽管有一些HTTP / 3端点可用于测试Cloudflare等服务，但Facebook和Litespeed 已经证明  了它们在2018年11月的HTTP / 3实现之间的互操作性，浏览器和Web服务器还没有支持HTTP / 3（除了Chrome的实验支持）对于谷歌的原始版本的QUIC）。

一旦他们这样做，服务提供商和托管公司将遵循，但可能需要更新旧的网络设备。“对于UDP的NAT遍历并不像TCP那样发达，一些家庭路由设备会假设UDP用于流视频而不是网络，”Graham-Cumming说。

Thomson说，如果你托管自己的网络服务器，你还有更多工作要做。“服务器管理员会发现QUIC需要的不仅仅是软件升级。启用UDP将需要网络和负载平衡基础架构的新支持。“网络运营商可能需要研究可以在软件中实现的更智能的第4层负载平衡解决方案，如Facebook的Katran项目。

但是因为HTTP / 3旨在解决HTTP / 2的问题，所以对HTTP / 2进行的优化（如域分片的更改）将在可用时自动应用。如果是这样的话，Graham-Cumming希望它能够推动网络的发展。“我们希望的是更快的网络下载和API。它应该使互联网更加可靠和快速，并且希望对于开发者来说，我们可以获得更丰富的API和Web应用程序，因为我们可以通过这种新协议更多地依赖互联网。“

特征图像经由 Pixabay。