我应该在 80 以外的端口上使用 WebSocket 吗? [英] Shall I use WebSocket on ports other than 80?

问题描述

我应该在非 80 端口上使用 WebSocket 吗?它是否破坏了使用现有 Web/HTTP 基础设施的全部目的?而且我认为它不再符合 Web非 80 端口上的套接字这个名称.

如果我在其他端口上使用 WebSocket，为什么不直接使用 TCP?还是WebSocket协议本身有什么特别的好处?

而且由于当前的 WebSocket 握手是 HTTP UPGRADE 请求的形式，是否意味着我必须在端口上启用 HTTP 协议才能完成 WebSocket 握手?

解决方案

我应该在非 80 端口上使用 WebSocket 吗?它是否破坏了整个目的使用现有的 Web/HTTP 基础设施?我认为它不再适合非 80 端口上的 WebSocket 名称.

您可以在您的主机操作系统允许并且您的客户端将被允许连接到的任何端口上运行 webSocket 服务器.

但是，在端口 80(或 443)上运行它有许多优点.

1. 网络基础设施通常已经部署并在端口 80 上开放，用于从客户端所在的地方(如台式计算机、移动设备等)到服务器所在的地方(如数据中心)的出站连接.因此，为了在端口 80 上部署 webSocket 应用程序，通常不需要防火墙或路由器配置等中的新漏洞.可能需要更改配置以在不同端口上运行.例如，许多大型企业网络对可以在哪些端口上建立出站连接非常挑剔，并且仅针对某些标准和预期行为进行配置.某些公司网络可能不允许为 webSocket 连接选择非标准端口.这是使用端口 80 的重要原因(来自已锁定配置的专用网络的最大互操作性).

2. 许多从浏览器运行的 webSocket 应用程序希望利用现有的安全/登录/身份验证基础设施，这些基础设施已经在主机网页的 80 端口上使用.如果一切都在同一个端口上，那么使用完全相同的基础设施来检查 webSocket 连接的身份验证可能会更简单.

3. 一些用于 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 请求.

Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.

If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?

And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?

解决方案

Shall I use WebSocket on non-80 ports? Does it ruin the whole purpose of using existing web/HTTP infrastructures? And I think it no longer fits the name WebSocket on non-80 ports.

You can run a webSocket server on any port that your host OS allows and that your client will be allowed to connect to.

However, there are a number of advantages to running it on port 80 (or 443).

1. Networking infrastructure is generally already deployed and open on port 80 for outbound connections from the places that clients live (like desktop computers, mobile devices, etc...) to the places that servers live (like data centers). So, new holes in the firewall or router configurations, etc... are usually not required in order to deploy a webSocket app on port 80. Configuration changes may be required to run on different ports. For example, many large corporate networks are very picky about what ports outbound connections can be made on and are configured only for certain standard and expected behaviors. Picking a non-standard port for a webSocket connection may not be allowed from some corporate networks. This is the BIG reason to use port 80 (maximum interoperability from private networks that have locked down configurations).

2. Many webSocket apps running from the browser wish to leverage existing security/login/auth infrastructure already being used on port 80 for the host web page. Using that exact same infrastructure to check authentication of a webSocket connection may be simpler if everything is on the same port.

3. Some server infrastructures for webSockets (such as socket.io in node.js) use a combined server infrastructure (single process, one listener) to support both HTTP requests and webSockets. This is simpler if both are on the same port.

---

If I use WebSocket over other ports, why not just use TCP directly? Or is there any special benefits in the WebSocket protocol itself?

The webSocket protocol was originally defined to work from a browser to a server. There is no generic TCP access from a browser so if you want a persistent socket without custom browser add-ons, then a webSocket is what is offered. As compared to a plain TCP connection, the webSocket protocol offers the ability to leverage HTTP authentication and cookies, a standard way of doing app-level and end-to-end keep-alive ping/pong (TCP offers hop-level keep-alive, but not end-to-end), a built in framing protocol (you'd have to design your own packet formats in TCP) and a lot of libraries that support these higher level features. Basically, webSocket works at a higher level than TCP (using TCP under the covers) and offers more built-in features that most people find useful. For example, if using TCP, one of the first things you have to do is get or design a protocol (a means of expressing your data). This is already built-in with webSocket.

And since current WebSocket handshake is in the form of a HTTP UPGRADE request, does it mean I have to enable HTTP protocol on the port so that WebSocket handshake can be accomplished?

You MUST have an HTTP server running on the port that you wish to use webSocket on because all webSocket requests start with an HTTP request. It wouldn't have to be heavily featured HTTP server, but it does have to handle the initial HTTP request.

这篇关于我应该在 80 以外的端口上使用 WebSocket 吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！