WebSockets
这部分的文档包含了基于 Netty 的 Websocket
介绍 WebSocket
WebSocket 协议，https://datatracker.ietf.org/doc/html/rfc6455[RFC 6455]，提供了一种标准化的方式，在单个 TCP 连接上建立全双工、 双向通信通道，用于客户端和服务器之间。 它是一个与 HTTP 不同的 TCP 协议，但设计用于通过 HTTP 运行，使用端口 80 和 443，并允许重用现有的防火墙规则。
WebSocket 交互之前需要一个 HTTP 请求，该请求使用 HTTP Upgrade 头部进行升级，
或者在这种情况下，切换到 WebSocket 协议。以下示例展示了这样一个交互：
GET /today-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: http://localhost: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
WebSocket 可以使网页变得动态和交互。然而，在许多情况下，AJAX 和 HTTP 流或长轮询的组合可以提供简单有效的解决方案。
例如，新闻、邮件和社交信息源需要动态更新，但每隔几分钟进行更新可能完全没问题。另一方面，协作、游戏和金融应用程序需要更接近实时。
仅仅延迟不是决定性因素。如果消息量相对较低（例如，监视网络故障），HTTP 流或轮询可以提供有效的解决方案。 低延迟、高频率和高容量的组合使 WebSocket 的使用成为最佳选择。
还要注意，在互联网上，不受您控制的限制性代理可能会阻止 WebSocket 交互，要么是因为它们没有配置传递 Upgrade 标头，
要么是因为它们关闭了看似空闲的长连接。这意味着在防火墙内部使用 WebSocket 的内部应用程序比面向公众的应用程序更直接。