WebSockets vs. HTTP 2021-11-07 默认分类 暂无评论 2831 次阅读 在实时应用程序中，不言而喻，我们需要从我们的服务器上尽快获得信息--从根本上说，经典的HTTP请求/响应范式并不能胜任这项工作。这是因为，无论是否有新的数据，服务器都会保持沉默，除非或直到消费者要求更新。 由于这种限制，出现了各种形式的黑客和变通方法，因为开发者试图使请求/响应模式适应更多的动态、实时网络的需求--其中一些已经正式化，并被广泛采用。 所有这些技术和方法--从彗星到HTTP长轮询--都有一个共同点：从本质上讲，它们旨在创造真正的实时（事件驱动）数据交换/通信的假象，所以当服务器有一些新数据时，它就会发送一个响应。 尽管HTTP不是一个事件驱动的协议，所以不是真正的实时性，但这些方法在特定的用例中实际上是很好的，比如Gmail聊天。然而，问题出现在低延迟的应用或规模上，主要是因为与HTTP相关的处理需求。 也就是说，在HTTP中，你必须不断地请求更新（并得到回应），这是非常耗费资源的。客户端建立一个连接，请求更新，从服务器得到一个响应，然后关闭连接。想象一下，这个过程被成千上万的并发用户无休止地重复--这对服务器来说是令人难以置信的大规模负担。 正是这些问题最终促使开发者Michael Carter和Ian Hickson开发了WebSockets--本质上是建立在设备的TCP/IP协议栈之上的一个薄的传输层。其目的是为网络应用提供一个本质上是TCP的通信层，尽可能地接近原始通信层，除了一些抽象的东西以消除某些基于安全的复杂问题和其他问题。 我们以前写过一篇关于WebSockets的概念性深入研究，以及涵盖了HTTP的演变，还有HTTP/2和HTTP/3的比较，所以我们在这里就不重提了。 相反，这篇文章将探讨一些用于绕过HTTP请求/响应范式在实时应用中的限制的技术，与之相关的一些问题，以及WebSockets如何帮助克服它们。 **HTTP** -------- HTTP本质上是客户端-服务器计算模型中的一个请求/响应协议，也是万维网的主要通信模式。最初的版本是由Tim Berners-Lee在1989年作为一个应用协议提出的，非常有限，并很快进行了修改，以支持更广泛的浏览器和服务器功能。 这些修改最终由HTTP工作组在1996年记录为HTTP/1.0（RFC 1945）--尽管HTTP/1.0不被认为是一个正式的规范或互联网标准。 **HTTP/1.1** ------------ - HTTP/1.1是网络浏览器和服务器最广泛支持的版本，它的到来是一个很大的进步，因为它实现了一些相当重要的优化和增强，从持久性和管道连接，到新的请求/响应头域。其中最主要的是两个头，它们是许多改进的基础，有助于实现一个更加动态、实时的网络。 Keep-Alive标头。 用于在主机之间建立持久的通信。这意味着连接可以被重复使用，用于一个以上的请求，这就明显减少了请求的延迟，因为在发送第一个请求之后，客户端不需要重新协商TCP 3-Way-Handshake连接。另一个积极的副作用是，一般来说，由于TCP的慢速启动机制，连接会随着时间而变快。在HTTP/1.1之前，你必须为每一个请求/响应对打开一个新的连接。 - 升级标头。用于将连接升级到一个增强的协议模式（如WebSockets）。 **HTTP轮询** ---------- HTTP轮询代表了经典的请求/响应机制的升级--尽管有各种版本的轮询，但只有长轮询才适用于实时应用。 例如，HTTP短轮询使用一个基于AJAX的计时器，以确保客户端设备以固定的时间间隔发送服务器请求。然而，服务器仍然会立即响应每个请求，要么提供新数据，要么在没有新数据的情况下发送一个 "空 "响应，然后关闭连接。因此，在实时应用中，当客户端需要在新数据出现时立即知道它时，它真的没有什么用。 正是这种限制导致了HTTP长轮询的发展，它本质上是一种旨在模拟服务器推送功能的技术。 我们已经在这里详细介绍了HTTP长轮询，但本质上长轮询是一种技术，服务器选择尽可能长时间地保持客户端的连接（通常长达20秒），只有在数据变得可用或达到超时阈值后才提供响应。 ![WeCom20211107-183458@2x.png][1] 长时间轮询的主要优点是，理论上讲，新的信息一出来就会被发送到客户端。然而，缺点是处理HTTP请求所带来的开销，这在规模上会产生一系列问题。 HTTP流媒体 HTTP流是一种推送式的数据传输技术，它允许网络服务器通过一个无限期开放的单一HTTP连接向客户端持续发送数据。从本质上讲，客户端提出一个HTTP请求，而服务器则推送出一个长度不确定的响应。 然而，虽然HTTP流是高性能的，易于消费，并且可以作为WebSockets的替代品，但它确实有局限性。从实时的角度来看，主要的问题是中间人可以中断连接--无论是通过超时还是仅仅因为它正在为多个请求提供 "轮流式 "服务--所以并不总是能够保证实时性。 HTTP/2.0 HTTP/2.0是从一个实验性协议--SPDY--发展而来的，该协议最初由谷歌在2009年宣布。到2015年，HTTP工作组以SPDY规范为起点，发布了HTTP/2.0的拟议标准。 我们以前曾详细介绍过HTTP/2.0，但它本质上是一种性能更新，旨在提高网络通信的速度。在实时通信方面的主要发展是：。 - 多路复用。数据不是以明文格式传输，而是被编码为二进制，并封装在框架内，可以沿着双向通道（称为流）进行多路复用--所有这些都通过一个TCP连接。这允许许多并行的请求/响应同时发生。 - 服务器推送。服务器推送是一种性能特征，允许服务器在客户端请求之前向符合HTTP/2的客户端发送响应。当服务器知道客户端需要 "推送 "的响应来完全处理原始请求时，这个功能就很有用。 尽管有了这些和其他的进步，但由于移动设备的大量使用，互联网流量的爆炸性增长使得HTTP/2.0难以提供流畅、透明的网络浏览体验--尤其是在实时应用程序及其用户不断增加的需求下。 **HTTP/2.0的优点** --------------- - 所有浏览器都支持HTTPS上的HTTP/2协议，并安装了SSL证书。 - HTTP/2允许客户端通过单个TCP连接并发发送所有请求。理论上，客户端应该能更快地收到资源。 - TCP是一个可靠、稳定的连接协议。 **HTTP/2.0的缺点** --------------- - 并发请求会增加服务器的负载。HTTP/2服务器可以接收大批量的请求，这可能导致请求超时。服务器负载激增的问题可以通过插入一个负载平衡器或代理服务器来解决，它可以对请求进行节流。 - 服务器对HTTP/2优先化的支持还不成熟。软件支持仍在发展中。一些CDN或负载均衡器可能无法正确支持优先级。 - HTTP/2推送功能的正确实施可能很棘手。 - HTTP/2解决了HTTP头线阻断问题，但TCP级阻断仍会造成问题。 HTTP/3.0 HTTP/3.0是HTTP的一个新迭代，自2018年以来一直在开发中，尽管在撰写本文时它仍然是一个标准草案（截至2020年10月），但一些浏览器已经在使用它了。 HTTP/3的目的是通过理顺HTTP/2的传输相关问题，在所有形式的设备上提供快速、可靠和安全的网络连接。为此，它使用了一个不同的传输层网络协议，称为QUIC，它在用户数据报协议（UDP）上运行，而不是以前所有版本的HTTP使用的TCP。 HTTP/3已经有一些潜在的问题开始出现了。比如说。 - 传输层的影响。过渡到HTTP/3不仅涉及到应用层的变化，而且还涉及到底层传输层的变化。因此，与它的前身相比，采用HTTP/3是一个更大的挑战。 - 可靠性和数据完整性问题。UDP一般适用于丢包可以接受的应用。这是因为UDP并不保证你的数据包会按顺序到达。事实上，它并不保证你的数据包会完全到达。因此，如果数据完整性对你的用例很重要，并且你正在使用HTTP/3，你将不得不建立机制来确保消息的排序和保证交付。 **HTTP/3.0优点** -------------- - 在UDP上运行的新的（不同的）传输协议QUIC的引入意味着理论上和目前实验上的延迟的减少。 - 因为UDP在协议栈中不执行错误检查和纠正，它适用于不需要或在应用中执行这些的情况。这意味着UDP避免了任何相关的开销。UDP经常被用于对时间敏感的应用，如实时系统，它不能等待数据包的重传，因此可以容忍一些丢弃的数据包。 **HTTP/3.0缺点** -------------- - 传输层的影响。过渡到HTTP/3不仅涉及到应用层的变化，而且还涉及到底层传输层的变化。因此，与它的前身相比，采用HTTP/3是一个更具挑战性。 - 可靠性问题。UDP应用往往缺乏可靠性，它必须接受会有一定程度的数据包丢失、重新排序、错误或重复。这取决于最终用户应用程序提供任何必要的握手，如实时确认消息已经收到。 - HTTP/3还没有完全标准化。 **WebSockets** -------------- ![WeCom20211107-183914@2x.png][2] 而与之前的请求没有任何关系。使用WebSockets的一个显著优势是，几乎每个浏览器都支持WebSockets。 WebSocket解决了HTTP的几个问题： - 双向协议--任何一个客户端/服务器都可以向对方发送消息（在HTTP中，请求总是由客户端发起，响应由服务器处理--使HTTP成为单向协议） - 全双工通信--客户端和服务器可以在同一时间内独立对话。 - 单一TCP连接--在一开始升级HTTP连接后，客户端和服务器在WebSocket连接的整个生命周期内都通过该同一TCP连接（持久连接）进行通信。 **WebSocket的优点** ---------------- - WebSocket是一个事件驱动的协议，这意味着你实际上可以将其用于真正的实时通信。与HTTP不同的是，你必须不断地请求更新，而使用WebSocket，一旦有更新，就立即发送。 - WebSockets保持一个单一的、持久的连接，同时消除了基于HTTP请求/响应的方法所产生的延时问题。 - WebSockets一般不使用XMLHttpRequest，因此，每次我们需要从服务器上获得更多信息时，都不会发送头信息。这反过来又减少了发送到服务器的昂贵的数据负载。 **WebSocket的缺点** ---------------- 当连接被终止时，WebSockets不会自动恢复--这是需要你自己实现的，这也是为什么有许多客户端库存在的部分原因。 2011年以前的浏览器无法支持WebSocket连接--但这一点越来越不重要。 **为什么WebSocket协议是更好的选择** ------------------------ 一般来说，在实时、持续通信的背景下，WebSockets将是更好的选择。 基于HTTP的技术往往对服务器的资源消耗更大，而WebSockets对服务器的占用极轻。 同时，像长轮询这样的方法也需要在服务器和设备之间进行多次跳转，而这些网关对一个典型的连接允许保持多长时间有不同的想法。如果它保持开放的时间过长，可能会有什么东西杀死它，甚至可能是在它正在做一些重要的事情的时候。 为什么你应该使用WebSockets来构建。 - Websockets是事件驱动的（与HTTP不同）。可以说，事件驱动是真正的实时性的先决条件。 - 全双工的异步消息传递。换句话说，客户端和服务器都可以独立地将消息流传给对方。 - 良好的安全模型（基于原点的安全模型） **Ably、WebSockets和HTTP** ------------------------ 大多数Ably的客户端库SDK使用WebSocket来建立与Ably的实时连接，然后使用简单的HTTP请求进行所有其他的REST操作，包括认证。 然而，客户端库SDK，如我们的Javascript浏览器库，被设计为根据浏览器和连接选择最佳的传输。通过支持更多的传输方式，并能够退回到最低限度的共同标准，Ably确保目前使用的几乎每一个浏览器都能够与Ably建立实时连接。我们的Javascript浏览器库目前支持以下传输方式，按性能从好到坏的顺序排列。 - WebSockets（截至2020年10月，全球98%的浏览器都支持） - XHR流 - XHR轮询 - JSONP轮询 然而，在实现对WebSockets的支持时，涉及到很多基于HTTP的技术，如长轮询作为一种退路。例如，除了客户端和服务器的实现细节外，你还必须建立对其他传输的支持，以确保对不同的客户端环境的强大支持，以及更广泛的关注，如认证和授权，保证消息交付，可靠的消息排序，历史消息保留，等等。 [1]: http://guobacai.com/usr/uploads/2021/11/964353833.png [2]: http://guobacai.com/usr/uploads/2021/11/3809040922.png 标签: websocket, 前端, http, http2.0, http3.0
评论已关闭