Http WebSocket服务器如何处理多个传入连接请求？

根据：

HTTP升级标头请求服务器切换 从HTTP到WebSocket协议的应用层协议

客户端握手在IE10之间建立了HTTP-on-TCP连接 和服务器。在服务器返回其101响应后 应用层协议从HTTP切换到使用 先前建立的TCP连接

HTTP在这一点上完全不可能。使用 轻量级WebSocket wire协议，现在可以发送或删除消息 由任一端点随时接收

因此，我的理解是，在第一个客户端完成与服务器的握手后，服务器的80端口将被WebSocket协议垄断。HTTP不再在80端口上工作

那么，第二个客户端如何与服务器交换握手呢所有WebSocket握手都是HTTP格式。

加1 谢谢你迄今为止的所有答案。他们真的很有帮助

现在我了解到同一台服务器的80端口是由多个

TCP

连接共享的。这种共享是完全可以的，因为

TCP

连接由一个5元素元组标识，正如

Jan-Philip-Gehrcke

指出的那样

我想补充一些想法

WebSocket

和

HTTP

都只是应用程序级协议。通常，它们都依赖于

TCP

协议作为传输协议

为什么选择80端口？ WebSocket设计有意选择服务器的端口80进行握手和后续通信。我认为设计者希望使WebSocket通信从传输层的角度看像正常的HTTP通信（即服务器端口号仍然是80）。但是根据jfriend00的回答，这种伎俩并不总是愚弄网络基础设施

协议如何从HTTP转移到WebSocket？ 来自RFC 6455-WebSocket协议

基本上，它的目的是将原始TCP暴露给用户 考虑到Web的限制，尽可能地编写脚本。它也是 其设计方式使其服务器可以与HTTP共享一个端口 通过握手，服务器将成为有效的HTTP升级请求。一个 可以在概念上使用其他协议来建立客户机-服务器 消息传递，但WebSocket的目的是提供一个相对 可以与HTTP和部署的HTTP共存的简单协议 基础设施（如代理）和与TCP尽可能接近的基础设施 基于安全考虑，可安全使用此类基础设施， 有针对性的添加，以简化使用并保持简单 简单（例如添加消息语义）

因此，我认为我的以下说法是错误的：

握手请求模拟HTTP请求，但通信 我不知道。握手请求到达端口80上的服务器。 因为它是80端口，服务器将使用HTTP协议处理它。这就是为什么WebSocket握手请求必须采用HTTP格式。 如果是这样，我认为HTTP协议必须修改/扩展到 识别那些WebSocket特有的东西。否则它不会实现 它应该屈服于WebSocket协议

我认为应该这样理解：

WebSocket通信以来自的有效HTTP请求开始 客户端到服务器。因此，遵循HTTP协议的是服务器 解析握手请求并识别请求者 协议变更。是服务器切换协议。所以 HTTP协议不需要更改。HTTP协议甚至不需要 了解WebSocket

WebSocket与彗星 因此WebSocket不同于技术，因为WebSocket不局限于当前的HTTP领域来解决双向通信问题

加2

---

一个相关问题：

回答您的问题：同时处理到端口80的Websocket和HTTP连接

与处理到端口80的同步HTTP连接的方式完全相同！ 这意味着：在令人满意的TCP握手后，在serviceip:80上侦听的服务将继续生成一个新进程或线程，并将该连接的所有通信移交给它（或者像jfriend00正确指出的那样，通过执行与该事件相关联的回调来服务请求）

然后等待或处理队列中的下一个传入请求

如果您想知道HTTP 1.1和升级请求在所有这些方面起到了什么作用，那么这一点非常清楚：

WebSocket协议有两个部分：握手以建立 升级连接，然后进行实际数据传输。首先是客户 通过使用“升级：websocket”和 “连接：升级”标题，以及一些特定于协议的标题 标头以建立正在使用的版本并设置握手。 如果服务器支持该协议，则会以相同的方式进行响应 “升级：websocket”和“连接：升级”标题并完成 握手。握手成功完成后，数据 开始转移

只有Websocket服务通常没有内置到web服务器中，因此实际上并不打算在端口80中侦听，由于web服务器的透明转发，可以通过端口80进行访问。ApacheWeb服务器使用

当然，您也可以有一个具有内置web套接字实现的web服务器：，例如

这里的主要问题是：Websocket协议不是HTTP。它有不同的用途。它是一个独立的应用层通信协议，也建立在TCP之上（尽管