我应该在非 80 端口上使用 WebSocket 吗？它会破坏使用现有 Web/HTTP 基础设施的全部目的吗？而且我认为它不再适合名称 WebSocket on non-80 端口。
如果我在其他端口上使用 WebSocket，为什么不直接使用 TCP？还是 WebSocket 协议本身有什么特别的好处？
而且由于当前的 WebSocket 握手是 HTTP UPGRADE 请求的形式，是否意味着我必须在端口上启用 HTTP 协议才能完成 WebSocket 握手？
【问题讨论】：
标签： websocket spring-websocket
在我看来，是的，你可以。 80 是默认端口，但您可以随意更改。
【讨论】：
Web 视为HTTP 的同义词。
我应该在非 80 端口上使用 WebSocket 吗？它是否破坏了整个目的 使用现有的 Web/HTTP 基础设施？我认为它不再 适合非 80 端口上的名称 WebSocket。
您可以在您的主机操作系统允许并且您的客户端将被允许连接到的任何端口上运行 webSocket 服务器。
但是，在端口 80（或 443）上运行它有很多优点。
网络基础设施通常已经部署并在端口 80 上打开，用于从客户端所在位置（如台式计算机、移动设备等）到服务器所在位置（如数据中心）的出站连接.因此，防火墙或路由器配置等中的新漏洞通常不需要在端口 80 上部署 webSocket 应用程序。可能需要更改配置才能在不同的端口上运行。例如，许多大型企业网络对可以在哪些端口上进行出站连接非常挑剔，并且仅针对某些标准和预期行为进行配置。某些公司网络可能不允许为 webSocket 连接选择非标准端口。这是使用端口 80 的重要原因（与已锁定配置的专用网络的最大互操作性）。
许多从浏览器运行的 webSocket 应用程序希望利用已在端口 80 上用于主机网页的现有安全/登录/身份验证基础设施。如果一切都在同一个端口上，使用完全相同的基础设施来检查 webSocket 连接的身份验证可能会更简单。
一些用于 webSockets 的服务器基础设施（例如 node.js 中的 socket.io）使用组合的服务器基础设施（单个进程，一个侦听器）来支持 HTTP 请求和 webSockets。如果两者都在同一个端口上，这会更简单。
如果我在其他端口上使用 WebSocket，为什么不直接使用 TCP？要么 WebSocket 协议本身有什么特别的好处吗？
webSocket 协议最初被定义为从浏览器到服务器。没有来自浏览器的通用 TCP 访问，因此如果您想要一个没有自定义浏览器附加组件的持久套接字，那么提供的是 webSocket。与普通 TCP 连接相比，webSocket 协议提供了利用 HTTP 身份验证和 cookie 的能力，这是一种执行应用程序级和端到端保活 ping/pong 的标准方式（TCP 提供跳级保活，但不是端到端的），内置的帧协议（您必须在 TCP 中设计自己的数据包格式）和许多支持这些更高级别功能的库。基本上，webSocket 在比 TCP 更高的层次上工作（在底层使用 TCP）并提供了更多大多数人认为有用的内置功能。例如，如果使用 TCP，您要做的第一件事就是获取或设计一个协议（一种表达数据的方法）。这已经内置在 webSocket 中了。
而且由于当前的 WebSocket 握手是 HTTP UPGRADE 的形式 请求，这是否意味着我必须在端口上启用 HTTP 协议所以 那WebSocket握手可以完成吗？
您必须在希望使用 webSocket 的端口上运行 HTTP 服务器，因为所有 webSocket 请求都以 HTTP 请求开始。它不必是功能强大的 HTTP 服务器，但它确实必须处理初始 HTTP 请求。
【讨论】：
origin 标头服务器端以防止跨域访问。
如今，除了重定向到端口 443 (HTTPS) 之外，几乎没有理由使用端口 80 (HTTP)，因为认证（通过 LetsEncrypt 等服务）易于设置且免费。
此规则唯一可能的例外是本地开发和非面向互联网的服务。
我怀疑这是您的问题的意图。对此，我认为这样做会增加不必要的复杂性，而且没有明显的好处。它不会增加安全性，也不会让任何事情变得更容易。
但这确实意味着需要设置特定的防火墙例外来托管和连接到您的 websocket 服务器。这意味着从公司/学校/锁定环境访问您的服务的人可能无法使用它，除非他们能够以某种方式说服管理层这是强制性的。我怀疑以这种方式排除您的用户群有很多充分的理由。
但也没有什么能阻止你这样做......
【讨论】：