我应该在非80端口上使用WebSocket吗？它是否会破坏使用现有Web / HTTP基础架构的整个目的？我认为它不再适合非80端口上的 Web 套接字。
如果我在其他端口上使用WebSocket，为什么不直接使用TCP呢？或者WebSocket协议本身有什么特别的好处吗？
由于当前的WebSocket握手是HTTP UPGRADE请求的形式，这是否意味着我必须在端口上启用HTTP协议才能完成WebSocket握手？
答案 0 :(得分：69)
我应该在非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请求。
答案 1 :(得分：2)
这些天，除了重定向到端口443（HTTPS）之外，几乎没有其他理由使用端口80（HTTP），因为证书（通过LetsEncrypt之类的服务）易于设置且免费。
此规则唯一可能的例外是本地开发和面向非Internet的服务。
我怀疑这是您提出问题的目的。为此，我认为这样做会增加不必要的复杂性，并且没有明显的好处。它不会增加安全性，也不会使任何事情变得简单。
但这确实意味着需要对特定的防火墙例外进行托管和连接到您的Websocket服务器。这意味着从公司/学校/锁定环境访问您的服务的人们可能无法使用它，除非他们能够以某种方式使管理层说服它是强制性的。我怀疑有很多充分的理由以这种方式排除您的用户群。
但是也没有什么可以阻止您这样做...
答案 2 :(得分：1)
在我看来，是的，你可以。 80是默认端口，但您可以根据需要将其更改为任意端口。