WebSockets
本参考文档的这一部分介绍了对 Servlet 栈的支持、WebSocket 消息传递（包括原始 WebSocket 交互）、通过 SockJS 实现的 WebSocket 模拟以及通过 STOMP 作为 WebSocket 子协议实现的发布-订阅消息传递。
WebSocket 简介
WebSocket 协议，RFC 6455，提供了一种标准化方法，用于通过单个 TCP 连接在客户端和服务器之间建立全双工、双向通信通道。它与 HTTP 是一种不同的 TCP 协议，但旨在通过 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://:8080| 1 | Upgrade 头。 |
| 2 | 使用 Upgrade 连接。 |
具有 WebSocket 支持的服务器会返回类似于以下内容的输出，而不是通常的 200 状态码
HTTP/1.1 101 Switching Protocols (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp| 1 | 协议切换 |
成功握手后，HTTP 升级请求底层的 TCP 套接字保持打开状态，客户端和服务器都可以继续发送和接收消息。
关于 WebSocket 工作原理的完整介绍超出了本文档的范围。请参阅 RFC 6455、HTML5 的 WebSocket 章或网络上许多介绍和教程中的任何一个。
请注意，如果 WebSocket 服务器运行在 Web 服务器（例如 Nginx）后面，您可能需要配置它以将 WebSocket 升级请求传递给 WebSocket 服务器。同样，如果应用程序在云环境中运行，请查看云提供商关于 WebSocket 支持的说明。
HTTP 与 WebSocket
尽管 WebSocket 被设计为与 HTTP 兼容并以 HTTP 请求开始，但了解这两种协议会导致非常不同的架构和应用程序编程模型是很重要的。
在 HTTP 和 REST 中，应用程序被建模为许多 URL。为了与应用程序交互，客户端以请求-响应的方式访问这些 URL。服务器根据 HTTP URL、方法和头将请求路由到适当的处理程序。
相比之下，在 WebSocket 中，通常只有一个 URL 用于初始连接。随后，所有应用程序消息都在同一 TCP 连接上传输。这指向了一种完全不同的异步、事件驱动的消息传递架构。
WebSocket 也是一种低级传输协议，与 HTTP 不同，它不规定消息内容的任何语义。这意味着，除非客户端和服务器就消息语义达成一致，否则无法路由或处理消息。
WebSocket 客户端和服务器可以通过 HTTP 握手请求上的 Sec-WebSocket-Protocol 头协商使用更高级别的消息协议（例如 STOMP）。如果不存在，它们需要自己制定约定。
何时使用 WebSockets
WebSockets 可以使网页具有动态性和交互性。然而，在许多情况下，AJAX 和 HTTP 流或长轮询的组合可以提供一个简单有效的解决方案。
例如，新闻、邮件和社交订阅源需要动态更新，但每隔几分钟更新一次可能完全可以接受。另一方面，协作、游戏和金融应用程序需要更接近实时。
仅延迟本身并不是决定性因素。如果消息量相对较低（例如，监控网络故障），HTTP 流或轮询可以提供有效的解决方案。低延迟、高频率和高流量的组合是使用 WebSocket 的最佳理由。
还要记住，在互联网上，您无法控制的限制性代理可能会阻止 WebSocket 交互，要么是因为它们未配置为传递 Upgrade 头，要么是因为它们关闭了看起来空闲的长时间连接。这意味着，在防火墙内部的内部应用程序中使用 WebSocket 是一个比面向公众的应用程序更直接的决策。
