根据这里:
HTTP Upgrade标头请求服务器将应用层协议从HTTP切换到WebSocket协议.
客户端握手在IE10和服务器之间建立了HTTP-on-TCP连接.在服务器返回其101响应之后,应用层协议从HTTP切换到使用先前建立的TCP连接的WebSockets.
此时HTTP完全脱离了图片.使用轻量级WebSocket线协议,任何端点现在都可以随时发送或接收消息.
所以,我的理解是,在第一个客户端完成与服务器的握手后,服务器的80端口将被WebSocket协议垄断.并且HTTP不再在80端口上运行.
那么第二个客户端如何与服务器交换握手.所有WebSocket握手都是HTTP格式.
谢谢你到目前为止的所有答案.他们真的很有帮助.
现在我明白同一台服务器的80端口是由多个连接共享的TCP.这种共享完全没问题,因为TCP连接是由5元素元组标识Jan-Philip Gehrcke出来的.
我想补充几点想法.
这两个WebSocket和HTTP仅仅是应用层协议.通常他们都依赖TCP协议作为他们的运输.
WebSocket设计有意为握手和后续通信选择服务器的端口80 .我认为设计人员希望从传输级别的角度看 WebSocket通信看起来像普通的HTTP通信(即服务器端口号仍然是80).但根据jfriend00答案,这个技巧并不总是欺骗网络基础设施.
来自RFC 6455 - WebSocket协议
基本上,考虑到Web的限制,它应尽可能地将原始TCP暴露给脚本.它的设计也使其服务器可以与HTTP服务器共享一个端口,使其握手成为有效的HTTP升级请求.可以在概念上使用其他协议来建立客户端 - 服务器消息传递,但WebSockets的目的是提供一个相对简单的协议,该协议可以与HTTP和部署的HTTP基础结构(例如代理)共存,并且尽可能安全地接近TCP.在给定安全性考虑的情况下使用此类基础结构,通过有针对性的添加来简化使用并简化简单事务(例如添加消息语义).
所以我认为我在下面的陈述中错了:
握手请求模仿 HTTP请求,但后面的通信没有.握手请求到达端口80上的服务器. 由于它是80端口,服务器将使用HTTP协议对其进行处理.这就是为什么WebSocket握手请求必须是HTTP格式的原因. 如果是这样,我认为必须修改/扩展HTTP协议以识别那些特定于WebSocket的东西.否则它将无法实现它应该屈服于 WebSocket协议.
我认为应该这样理解:
WebSocket通信以从客户端到服务器的有效 …