为什么WebSocket可以在“握手后”与HTTP共享80端口？ [英] Why WebSocket can share the 80 port with HTTP "after the handshake"?

问题描述

据我了解：

• 端口指定服务器上的程序。


• 我们说来共享一个端口，它实际上意味着让同一个程序在该端口上监听请求。

WebSocket握手类似于 HTTP格式，所以它 can 可以被处理HTTP协议的服务器程序理解。所以可以将握手请求发送到端口80 。

但握手后的 ，WebSocket数据格式与HTTP格式完全不同，它怎么还能发送到端口80？例如通过如下URL：

ws：// somehost：80 / chat

它是如何运作的？

我猜：

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

ADD 1

根据 jfriend00 的回复，我绘制了下图：

因此，同一浏览器中的WebSocket和HTTP流量实际上是通过不同的套接字连接来实现的。虽然它们都是从连接到服务器端口80开始的。

我认为如果 WebSocket 这个词不包含套接字在其中，将它更容易理解为TCP协议上的另一个应用程序级协议。

ADD 2

我根据 jfriend00 的进一步评论。
我想要展示的是在浏览器中如何将WebSocket通信和HTTP通信连接到同一服务器共存。

ADD 3

在阅读此主题后，我回想起服务器接受连接时服务器端口不会改变：

解决方案

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

因此，一个传入的http请求可以指定upgrade标头并升级到webSocket，然后两端同意从那时开始谈论webSocket协议。同时，没有该升级头的其他传入http请求仅被视为正常的http请求。

如果您不太了解webSocket协议的工作原理，您可以获得全面了解如何连接此处。

以下是主要步骤：

1. 请求webSocket连接的客户端发送在端口80上向服务器发出HTTP请求。


2. 该HTTP请求是完全合法的HTTP请求，但它上面包含一个标头升级：websocket 。


3. 如果服务器支持webSocket协议，那么它会使用合法的HTTP响应进行响应，其中包含一个包含标题<101 c $ c>的101状态代码连接：升级。


4. 此时，双方然后将协议切换到webSocket协议，并且该套接字上的所有未来通信都是d一个使用webSocket框架的数据格式。

任何其他不包含升级的传入HTTP请求请求标头被视为正常的HTTP请求。

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

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

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

这个升级机制也可用于支持其他协议指定不同的协议名称升级：someOtherProtocol 虽然我不知道其他任何标准化的。

As I understand:

• A port designates a program on the server.
• When we say to share a port, it actually means to have the requests processed by the same program listening on that port.

The WebSocket handshake resembles the HTTP format, so it can be understood by the server program that handles HTTP protocol. So it's OK to send the handshake request to port 80.

But after the handshake, the WebSocket data format is totally different from HTTP format, how could it still be sent to port 80? Such as via URL like below:

ws://somehost:80/chat

How does it work out?

My guess:

Does the HTTP program see that the incoming request on port 80 cannot be handled as HTTP, and then it will pass it to WebSocket program to process it. If so, what if there's some other protocol that wants to share port 80, say WebSocket2, how could HTTP program know which protocol to pass on to if there's not a way to identify the protocol being used.

ADD 1

Based on jfriend00's reply, I draw the following diagram:

So WebSocket and HTTP traffic in the same browser are actually carried out through different socket connections. Though they both start by connecting to server's port 80.

I think if the word WebSocket doesn't contain a socket in it, it will be easier to understand it as just another application level protocol over TCP protocol.

ADD 2

I refined the above diagram to below based on jfriend00's further comments. What I want to show is how WebSocket communication and HTTP communication to the same server coexist in a browser.

ADD 3

After reading this thread, I recalled that the server port doesn't change when server accept a connection: Does the port change when a TCP connection is accepted by a server?

So the diagram should be like this:

The TCP connection for HTTP and the TCP connection for WebSocket should be using different client ports.

解决方案

When a server listens on a given port, it is listening for incoming connections. When a new incoming connection arrives, it is given its own socket to run on. That socket provides the connection between the two endpoints. From then on, that socket runs completely independently from all other sockets that might also be connected.

So, one incoming http request can specify the "upgrade" header and get upgraded to webSocket and then both ends agree to talk the webSocket protocol from then on. Meanwhile, other incoming http requests without that upgrade header are treated only as normal http requests.

In case you don't quite understand how the webSocket protocol works, you can get a full look at how it connects here.

Here are the main steps:

1. The client requesting a webSocket connection, sends an HTTP request to the server on port 80.
2. That HTTP request is a perfectly legal HTTP request, but it has a header included on it Upgrade: websocket.
3. If the server supports the webSocket protocol, then it responds with a legal HTTP response with a 101 status code that includes a header Connection: Upgrade.
4. At that point, both sides then switch protocols to the webSocket protocol and all future communication on that socket is done using the data format for the webSocket frame.

Any other incoming HTTP requests that do not contain the upgrade request header are treated as normal HTTP requests.

Does the HTTP program see that the incoming request on port 80 cannot be handled as HTTP, and then it will pass it to WebSocket program to process it.

No, the first request IS a legal HTTP request (just with a special header in it) and the response sent back is a legal HTTP response. But, after that response, both sides switch protocols to webSocket. So a custom header is used to tell the web server that this incoming HTTP request is meant to be the first step in establishing a webSocket connection.

If so, what if there's some other protocol that wants to share port 80, say WebSocket2, how could HTTP program know which protocol to pass on to if there's not a way to identify the protocol being used.

This upgrade mechanism could be used to support other protocols too by just specifying a different protocol name Upgrade: someOtherProtocol though I'm not aware of any others that have been standardized.

这篇关于为什么WebSocket可以在“握手后”与HTTP共享80端口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！