WebSocket与HTTP通信协议
WebSocket与HTTP总结
您在互联网上的许多日常活动（从订餐到查找事实，再到在线与医生交谈）都是通过 WebSocket 或 HTTP 通信协议实现的。作为开发人员，在构建应用程序时，您应该使用以下哪些通信协议？当我们比较 WebSocket 和 HTTP 时有什么区别？简而言之，WebSocket 是一种全双工通信协议，相对较新，非常适合< i=3>应用内聊天、通知和语音或视频通话。另一方面，HTTP 作为一种半双工通信协议，已经存在了一段时间，自首次亮相以来一直是网站的基础。
在这次比较中，您将更多地了解这两种通信协议、它们的相似点和差异，并了解何时选择其中一种。让我们深入了解一下！
关于WebSocket连接
WebSocket 协议描述了客户端和服务器如何在全双工通道中进行通信。换句话说，客户端和服务器都可以通过长期连接同时发送和接收数据。这种类型的通信比 HTTP 轮询的开销更少，从而为应用程序提供了实时功能方面的多个优势。
WebSocket 连接的优点
双向通讯
由于连接双方都可以随时发送消息，因此当您需要快速来回移动大量数据时，WebSocket 连接是一个绝佳的选择。
想象一个连接多个客户端的简单聊天室。如果 WebSocket 服务器管理它们的对话，客户端会向服务器发送一条消息，然后服务器立即将其转发给所有其他连接的客户端。对于用户来说，他们可以实时地互相发送消息。
这是一个简单的版本：
更低的延迟
HTTP 连接中相对高频数据获取的常见模式是轮询，其中客户端定期请求新的服务器数据。也许这种通信方法的最大缺点是延迟 - 您必须在频繁或长时间运行的请求与高延迟之间进行折衷。
通过 WebSocket 连接，数据一旦可用就会立即发送。客户不需要一直请求它。结果是延迟大大降低，开销和网络流量也只占一小部分。
WebSocket 与 HTTP 通信图
持久连接
对于传统的 HTTP 连接，客户端发出请求，服务器发送响应后，连接将关闭。如果客户端需要更多数据，他们必须打开一个新连接。
请注意，尽管 HTTP/1.1 引入了允许重用 TCP/IP 连接的持久连接，但这种心理模型仍然很有帮助，而且大多是准确的。
通过 WebSocket 连接，客户端可以打开并使用单个连接来进行与服务器的所有 WebSocket 通信。这种持久连接允许低延迟、双向消息。
此 WebSocket 连接也可以是有状态的。 HTTP 连接是无状态的，这意味着每个请求都是单独处理的，不会保留有关之前发出的请求的信息。另一方面，WebSocket 由于其持久连接而具有状态性。
应用程序是否利用有状态功能完全取决于开发人员以及他们如何使用 WebSocket 连接。
关于HTTP连接
HTTP 协议被设计为请求-响应协议。客户端（例如浏览器）会向 Web 服务器发送 请求，而 Web 服务器会回复 response包含与请求对应的资源，例如HTML和CSS文件。当 HTTP 连接打开时，它们只是半双工，这意味着通信只能进行单向。一旦收到响应，连接通常会关闭。
HTTP/1.1 引入了持久连接，它重用 TCP/IP 连接，从而可以提高一些性能。然而，这些持久连接的具体情况因服务器而异，在大多数情况下，它们最终会根据不活动超时而关闭。因此，虽然这是对 HTTP 连接功能的一个受欢迎的补充，但这仍然不能与 WebSocket 连接进行直接比较。
HTTP 协议非常擅长其构建目的：响应请求。但是，它并不是为处理实时通信用例而构建的，例如聊天或实时事件流媒体，这是人们今天所期望的。
即便如此，HTTP 仍然比 WebSocket 协议有几个优势。
HTTP 连接的优点
简单性和普遍性
HTTP 连接的持久力来自于它的广泛采用和简单的可访问性。在 HTTP 的三个主要版本之间，几乎所有 Web 服务器和 Web 浏览器都可以某种形式利用该协议：
HTTP/1.1。 大约 35% 的网站仍在使用 HTTP/1.1 或更低版本。
HTTP/2。 39.3% 的网站使用。
HTTP/3。 25.7% 的网站使用。
无状态特性和缓存支持
由于 HTTP 请求是无状态且独立的，因此网站的性能可能会受益于缓存响应，尤其是在处理静态内容和资产时。缓存可以发生在不同的级别：
在浏览器中：这根本不需要联系服务器。
在边缘：这使用更靠近用户地理位置的服务器，与 CDN .
在服务器上：如果每次结果都相同，这可以让服务器避免昂贵的重新计算。
WebSocket 消息不能像 HTTP 响应那样容易缓存，因为它们是有状态的并且通常是上下文相关的。在大多数情况下，这些消息会经常更改，因此缓存无法发挥作用。
强大的安全机制
HTTP 协议的普遍存在意味着它已成为改善其安全状况的多项举措的主题。
HTTPS
原始的 HTTP 协议缺少一个重要的方面：请求和响应消息未加密，并且相对容易被恶意行为者拦截和读取。
HTTPS 可以缓解此问题，HTTPS 是 HTTP 的一种变体，它使用传输层安全性 (TLS) 或安全套接字层 (SSL) 来加密请求和响应。恶意行为者可能能够拦截您的数据包，但由于这种加密，他们将无法读取其内容。
HTTP 严格传输安全
另一个与 HTTP 相关的安全机制是 HTTP 严格传输安全 (HSTS)。 HSTS 允许服务器指定策略来帮助防止常见的安全问题，例如MITM 攻击、协议降级攻击 a>。cookie 劫持 和
站点可以通过 HTTPS 连接返回适当的标头来利用 HSTS，如下所示：
正确配置后，HSTS 可确保浏览器始终请求站点的 HTTPS 变体，即使用户单击了标准 HTTP 链接也是如此。因此，用户拥有一层安全保护，可以保护他们免受许多易于缓解的攻击。
WebSocket与HTTP：选择合适的协议
在支持 WebSocket 或 HTTP 协议之前，请考虑一下您正在构建的内容以及原因。请注意，每种通信协议在其他协议通常不足的几个领域都表现出色。
WebSocket 与 HTTP 连接之间的技术权衡
了解这两种通信协议之间的技术权衡可以让您深入了解哪一种最适合您的项目。
连接设置和管理
考虑随着时间的推移，您需要如何建立和管理连接。
对于 WebSocket，持久连接是通过客户端和服务器之间的握手建立的。即使消息之间存在明显的延迟，它也会在会话期间保持打开状态。
对于 HTTP，连接是通过握手建立的，然后用于请求-响应周期。 HTTP/1.1 允许将同一个 TCP/IP 连接重复用于多个请求-响应对，从而减少开销并改善延迟，但程度与 WebSocket 不同。连接仍将在相对较短的时间内关闭，从几秒到几分钟不等。
数据传输和编码
考虑您希望如何传输数据。
WebSocket 连接使用全双工双向通信 - 连接的任何一方都可以随时发送消息。 HTTP 连接使用半双工通信；一次只有一方可以通信，服务器的消息始终响应客户端的请求。
WebSocket 和 HTTP 都可以发送以基于文本的格式（例如 JSON、XML 和纯文本）编码的数据，以及二进制编码的数据。
错误处理和恢复
考虑哪些错误处理方法对用户影响最小。
WebSocket 连接可能会因各种原因而失败，包括应用程序代码中的错误。客户端会收到一个 错误事件，他们可以侦听该事件，并且您可以按照自己认为合适的方式处理此侦听器中的错误。但是，如果您的 WebSocket 服务器在应用程序代码内运行，则应用程序级别的致命错误可能会极大地影响应用程序实现优雅错误处理的能力。
当然，HTTP 连接可能会遇到类似的情况，但某些常见架构可以在错误处理方面提供优势。 HTTP 指定了服务器可以响应的一系列状态代码，以大致指示请求是否成功。 4xx 和 5xx 范围分别是为客户端和服务器错误保留的。
考虑一个 Web 应用程序，其中请求通过 NGINX 作为 Web 服务器和 PHP 处理NGINX a> 消息。HTTP 503 - 服务不可用 作为动态后端语言。假设应用程序逻辑中的某些内容导致致命错误或进程终止。这不会影响 NGINX 向客户端提供响应的能力，该响应很可能是
当然，这种分离确实取决于应用程序的架构。考虑类似的情况，您的应用程序和 Web 服务器在同一进程中一起实现，例如 Node.js Express 应用程序。这里的致命错误也会终止 Web 服务器，从而限制客户端收到的错误的有用性。
可扩展性
考虑您的应用程序的资源消耗需求。
WebSocket 连接被设计为高效工作。它们是事件驱动的——仅当有需要发送消息的内容时才会发送消息。
HTTP 连接可以通过长轮询实现类似于实时功能的功能，其中请求被发送并保持打开状态，直到出现某些情况为止来回应。这种实时通信的粗略近似有一些局限性，特别是在规模上。 HTTP 请求不能无限期地保持打开状态，这意味着客户端需要定期打开新的长轮询请求。随着时间的推移，处理所有这些长期 HTTP 请求的开销会不断增加。
使用HTTP 流，连接无限期地保持打开状态以促进连续的数据流。这在概念上类似于 WebSocket，但它仍然通过 HTTP 执行，并且仍然是单向的 - 客户端无法通过 HTTP 流向服务器发送消息。
WebSocket 与 HTTP 连接的性能注意事项
考虑您的应用程序的性能预期。
得益于持久连接，WebSocket 可以减少开销和延迟。这会带来更好的性能、更快的实时更新以及更少的处理能力，例如 HTTP 三向握手 和 HTTP 特定应用程序用于管理传入请求和身份验证/授权的代码。
由于 HTTP 通常必须在会话的生命周期内处理多个连接，因此与 WebSocket 相比，它自然会花费更多的时间和资源。
WebSocket 与 HTTP 连接的安全性
考虑哪一个对您来说最容易确保安全。
WebSocket 和 HTTP 连接在安全考虑方面类似。两者都有不安全和安全的变体，如果没有充分保护，两者都可能成为几种常见攻击的受害者。您还需要注意针对每种协议的特定攻击，例如针对 HTTP 的 跨站脚本攻击 和 针对 WebSocket 的跨站 WebSocket 劫持。
但是，如果您正确配置它们并使用 TLS 加密，则可以减轻大多数威胁，使这两种协议都足够安全。
通信协议的混合方法
通常，建议的方法是在您的系统中使用这两种协议，以发挥其最擅长的作用。这意味着对大多数标准网络流量使用 HTTP 连接，对任何需要实时通信的内容使用 WebSocket 连接，例如通知、。视频通话，或消息/聊天
您还可以考虑评估补充或替代技术；毕竟，WebSocket 和 HTTP 并不是实时通信的唯一选择。 WebRTC 与 WebSocket 类似，主要区别在于它用于实现点对点连接< /span> 不依赖服务器。这对于视频通话特别有用，允许参与者直接进行交流，而不会给您的服务器带来负载。
用于安全、可扩展、可靠的应用内通信的通信协议
您现在应该对如何使用 WebSocket 和 HTTP 通信协议有一个明确的了解。您已经看到了他们的优点和缺点，并且可以欣赏他们的权衡。
幸运的是，您无需二选一。这两种通信协议可以而且通常应该一起使用，让每个协议都能发挥其最擅长的作用。如果您需要在应用程序中实现实时通信和流媒体功能，请查看Sendbird。 Sendbird 的 API 和客户端 SDK 处理应用内聊天、通话直播。 Sendbird 的聊天服务抽象化了与长期发展和维护聊天系统相关的问题（例如大规模实时可靠且安全地运行）。这意味着您可以专注于应用程序的核心方面。
想尝试一下吗？ 免费注册 - 无需承诺或信用卡。
快乐的应用内通讯建设！ 📱