WebSocket

本部分参考文档涵盖了对 Servlet 堆栈、WebSocket 消息传递的支持，包括原始 WebSocket 交互、通过 SockJS 进行的 WebSocket 模拟，以及通过 STOMP 作为 WebSocket 上的子协议进行的发布-订阅消息传递。

WebSocket 简介

WebSocket 协议，RFC 6455，提供了一种标准化方式，可以在客户端和服务器之间通过单个 TCP 连接建立全双工、双向通信通道。它与 HTTP 不同，但被设计为在 HTTP 上运行，使用端口 80 和 443，并允许重用现有的防火墙规则。

WebSocket 交互从一个 HTTP 请求开始，该请求使用 HTTP Upgrade 标头来升级，或者在本例中，切换到 WebSocket 协议。以下示例显示了这种交互

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket (1)
Connection: Upgrade (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: https://127.0.0.1:8080
1 Upgrade 标头。
2 使用 Upgrade 连接。

与通常的 200 状态代码不同，支持 WebSocket 的服务器将返回类似于以下内容的输出

HTTP/1.1 101 Switching Protocols (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
1 协议切换

成功握手后，HTTP 升级请求底层的 TCP 套接字将保持打开状态，以便客户端和服务器都可以继续发送和接收消息。

有关 WebSockets 工作原理的完整介绍超出了本文档的范围。请参阅 RFC 6455、HTML5 的 WebSocket 章节，或网络上的众多介绍和教程。

请注意，如果 WebSocket 服务器运行在 Web 服务器（例如 nginx）之后，您可能需要对其进行配置以将 WebSocket 升级请求传递到 WebSocket 服务器。同样，如果应用程序在云环境中运行，请查看云提供商有关 WebSocket 支持的说明。

HTTP 与 WebSocket

尽管 WebSocket 被设计为与 HTTP 兼容，并且从 HTTP 请求开始，但重要的是要了解这两种协议会导致截然不同的架构和应用程序编程模型。

在 HTTP 和 REST 中，应用程序被建模为多个 URL。为了与应用程序交互，客户端访问这些 URL，以请求-响应方式。服务器根据 HTTP URL、方法和标头将请求路由到相应的处理程序。

相比之下，在 WebSockets 中，通常只有一个 URL 用于初始连接。随后，所有应用程序消息都通过同一个 TCP 连接流动。这指向了一种完全不同的异步、事件驱动、消息传递架构。

WebSocket 也是一种低级传输协议，与 HTTP 不同，它没有为消息内容规定任何语义。这意味着，除非客户端和服务器就消息语义达成一致，否则无法路由或处理消息。

WebSocket 客户端和服务器可以通过 HTTP 握手请求中的 Sec-WebSocket-Protocol 标头协商使用更高级的消息传递协议（例如 STOMP）。在没有该标头的情况下，它们需要制定自己的约定。

何时使用 WebSockets

WebSockets 可以使网页变得动态和交互式。但是，在许多情况下，AJAX 和 HTTP 流式传输或长轮询的组合可以提供一个简单有效的解决方案。

例如，新闻、邮件和社交信息流需要动态更新，但每隔几分钟更新一次可能是完全可以的。另一方面，协作、游戏和金融应用程序需要更接近实时。

延迟本身并不是决定因素。如果消息量相对较低（例如，监控网络故障），HTTP 流式传输或轮询可以提供有效的解决方案。正是低延迟、高频率和高容量的结合，才使 WebSocket 的使用成为最佳选择。

还要记住，在互联网上，不受您控制的限制性代理可能会阻止 WebSocket 交互，要么是因为它们没有配置为传递 Upgrade 标头，要么是因为它们关闭了看起来处于空闲状态的长期连接。这意味着，在防火墙内部使用 WebSocket 进行内部应用程序的决策比面向公众的应用程序更加直接。

章节摘要