为什么WebSocket“握手后”可以与HTTP共享80端口？

我认为：

• 端口指定服务器上的程序。
• 当我们说to share a port，实际上意味着to have the requests processed by the same program listening on that port.

WebSocket 握手resemblesHTTP 格式，所以can可以被处理 HTTP 协议的服务器程序理解。所以发送握手请求就可以了port 80.

But after the handshake，WebSocket数据格式和HTTP格式完全不同，怎么还能发送到80端口呢？例如通过如下 URL：

ws://somehost:80/chat

结果如何？

我猜：

HTTP 程序是否看到端口 80 上的传入请求cannot be handled as HTTP，然后将其传递给WebSocket程序进行处理。如果是这样，如果有其他协议想要共享端口 80，比如 WebSocket2，如果没有办法识别正在使用的协议，HTTP 程序如何知道要传递到哪个协议。

ADD 1

基于jfriend00回复了，我画下图：

所以WebSocket和HTTP流量在同一个浏览器中实际上是通过different套接字连接。尽管它们都是通过连接到服务器的端口 80 开始的。

我想如果这个词WebSocket不包含socket在其中，会更容易理解它只是 TCP 协议之上的另一个应用程序级协议。

ADD 2

我根据以下内容将上图细化为下图jfriend00的进一步评论。 我想展示的是如何WebSocket通信和HTTP通信到同一台服务器coexist在浏览器中。

ADD 3

读完这个帖子后，我记得当服务器接受连接时，服务器端口不会改变：当服务器接受 TCP 连接时端口是否会更改？

所以图应该是这样的：

HTTP 的 TCP 连接和 WebSocket 的 TCP 连接应该使用不同的client ports.

当服务器侦听给定端口时，它正在侦听传入连接。当新的传入连接到达时，它会获得自己的套接字来运行。该套接字提供两个端点之间的连接。从那时起，该套接字完全独立于可能连接的所有其他套接字运行。

因此，一个传入的 http 请求可以指定“升级”标头并升级到 webSocket，然后两端都同意从此开始使用 webSocket 协议。同时，没有该升级标头的其他传入 http 请求仅被视为普通 http 请求。

如果您不太了解 webSocket 协议的工作原理，您可以全面了解它的连接方式here.

以下是主要步骤：

1. 请求 webSocket 连接的客户端通过端口 80 向服务器发送 HTTP 请求。
2. 该 HTTP 请求是一个完全合法的 HTTP 请求，但它包含一个标头Upgrade: websocket.
3. 如果服务器支持 webSocket 协议，那么它会使用合法的 HTTP 响应进行响应，其中包含 101 状态代码，其中包含标头Connection: Upgrade.
4. 此时，双方都将协议切换到 webSocket 协议，并且该套接字上的所有未来通信都使用 webSocket 帧的数据格式完成。

任何其他不包含以下内容的传入 HTTP 请求upgrade请求标头被视为正常的 HTTP 请求。

HTTP程序是否看到端口80上传入的请求不能 作为HTTP处理，然后将其传递给WebSocket程序 处理它。

不，第一个请求是合法的 HTTP 请求（只是其中有一个特殊的标头），并且发送回的响应是合法的 HTTP 响应。但是，在该响应之后，双方都将协议切换到 webSocket。因此，自定义标头用于告诉 Web 服务器此传入 HTTP 请求是建立 webSocket 连接的第一步。

如果是这样，如果有其他协议想要共享端口怎么办 80、比如说WebSocket2，HTTP程序怎么知道要传递哪个协议 如果没有办法识别正在使用的协议。

This upgrade只需指定不同的协议名称，该机制也可用于支持其他协议Upgrade: someOtherProtocol虽然我不知道有任何其他已经标准化的。