我想了解更多关于websocket及其内部实现的信息.但仍然无法理解一些事情.我尝试使用谷歌搜索进行深入解释,但大多数只是给出了高级概述.以下是我的疑惑
1.据我所读,默认情况下,Web套接字服务器(C#/ C实现)使用端口80.虽然我们可以使用任何端口,但我们最好使用端口80,因为我们不会遇到任何防火墙问题.如果是这样,我们应该如何在同一个端口(80)上运行Web服务器和Web套接字服务器？
2.假设Web套接字服务器在端口81上运行,Web服务器在端口80上运行.
>因此,当浏览器发出初始握手HTTP请求(升级：websocket)时,此请求将发送到端口81.对吗？如果是这样,该请求(见下文)与HTTP协议没有任何关系.但我们仍然使用HTTP协议头.为什么？
GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com
>为什么他们使用当前在大多数浏览器中实现的相同websocket接口来发出与给定端口的直接TCP / IP连接,而没有任何HTTP内容？
3.对于从客户端/服务器发送/接收的数据,是否存在数据包大小限制或数据/缓冲区限制？如果是这种情况,我们是否需要构建数据框并自行处理？
4. websocket服务器是否始终需要是一个单独的服务/流程？将来网络服务器(IIS,apache)是否会支持在其进程空间内托管Web套接字服务器？
解决方法
>通过使用HTTP兼容的握手,您可以将WebSocket处理程序集成到您的Web服务器中,或者让Web服务器将websocket连接转发到专用的WebSocket服务器.
> WebSocket握手使用HTTP兼容握手,允许在同一端口上轻松处理这两种协议,并允许现有防火墙配置更轻松地支持WebSocket流量.此外,防止在HTTP请求的上下文中充分理解的跨端脚本攻击,因此WebSocket利用了这些知识.即使在建立连接之后,WebSocket也不是原始套接字连接.它是基于消息的协议,因此需要框架.此外,当从客户端(浏览器)发送到服务器时,框架被屏蔽,以减轻对行为不当的代理/缓存/中介的理论漏洞的担忧.
>协议本身的消息大小没有限制.消息可以拆分为多个帧.帧大小存在协议限制,但它是2 ^ 64字节.根据客户端/服务器实现,实际帧大小限制将更小.如果您要发送多兆字节的单个邮件,则可以考虑更改应用程序以使用较小的邮件,以最大限度地提高跨浏览器和跨服务器的支持.
> WebSocket处理绝对可以集成到Web服务器中,这是工作组设想的非常多的场景.例如,考虑 pywebsocket,它设计为独立运行或作为Apache中的mod_python模块运行.另一个例子,ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.
> WebSocket握手使用HTTP兼容握手,允许在同一端口上轻松处理这两种协议,并允许现有防火墙配置更轻松地支持WebSocket流量.此外,防止在HTTP请求的上下文中充分理解的跨端脚本攻击,因此WebSocket利用了这些知识.即使在建立连接之后,WebSocket也不是原始套接字连接.它是基于消息的协议,因此需要框架.此外,当从客户端(浏览器)发送到服务器时,框架被屏蔽,以减轻对行为不当的代理/缓存/中介的理论漏洞的担忧.
>协议本身的消息大小没有限制.消息可以拆分为多个帧.帧大小存在协议限制,但它是2 ^ 64字节.根据客户端/服务器实现,实际帧大小限制将更小.如果您要发送多兆字节的单个邮件,则可以考虑更改应用程序以使用较小的邮件,以最大限度地提高跨浏览器和跨服务器的支持.
> WebSocket处理绝对可以集成到Web服务器中,这是工作组设想的非常多的场景.例如,考虑 pywebsocket,它设计为独立运行或作为Apache中的mod_python模块运行.另一个例子,ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.
