我正在使用 socket.io,它的设置很快(感谢他们使用页面上的示例),但我想了解更多关于幕后究竟发生了什么以及使它工作的技术是什么。
socket.io 的确切机制是什么?
它在端口 80 上还是单独的端口上?
它真的保持打开状态还是那部分是模拟的?
有没有办法分析每个套接字事件?(有点像使用 fiddler 来查看 ajax 调用中发生的情况)
我正在使用 socket.io,它的设置很快(感谢他们使用页面上的示例),但我想了解更多关于幕后究竟发生了什么以及使它工作的技术是什么。
socket.io 的确切机制是什么?
它在端口 80 上还是单独的端口上?
它真的保持打开状态还是那部分是模拟的?
有没有办法分析每个套接字事件?(有点像使用 fiddler 来查看 ajax 调用中发生的情况)
对于调试,您可能想尝试一下Theseus。
以下是socket.io SPEC的简短概述:
Socket.IO 旨在为许多浏览器和设备带来类似 WebSocket 的 API,并具有一些特定功能来帮助创建现实世界的实时应用程序和游戏。
- 多种传输支持(旧用户代理、移动浏览器等)。
- 同一连接下的多个套接字(命名空间)。
- 通过心跳检测断线。
- 可选的致谢。
- 带缓冲的重新连接支持(适用于移动设备或不良网络)
- 位于 HTTP 之上的轻量级协议。
Socket.IO 套接字剖析
Socket.IO 客户端首先决定用于连接的传输。
Socket.IO 套接字的状态可以是
disconnected
、disconnecting
和。connected
connecting
传输连接可以是
closed
、closing
、open
和opening
。一个简单的 HTTP 握手发生在 Socket.IO 连接的开始。如果握手成功,客户端会收到:
- 将为传输提供打开连接的会话 ID。
- 预期心跳的秒数 (
heartbeat timeout
)- 如果传输连接未重新打开
close timeout
(此时套接字被认为是连接的,并且传输被通知打开连接。
如果传输连接关闭,则两端都将缓冲消息,然后将它们适当地框起来,以便在连接恢复时将它们作为批处理发送。
如果在协商的超时时间内没有恢复连接,则认为套接字已断开连接。此时客户端可能决定重新连接套接字,这意味着新的握手。
如果您需要更多详细信息,可以在此处阅读规范的其余部分
JAM 的帖子很好地总结了 socket.io是什么;我想专门解决您的其他一些问题。
Socket.io 附加到一个实例http.Server
并向其添加处理程序。它不会自己监听网络端口;它只是将特定于 socket.io 的处理程序添加到现有的 HTTP 服务器。(但是,如果您io.listen()
使用数字呼叫,它会在内部创建一个新的 HTTP 服务器,该服务器侦听指定的端口并附加到该端口。)
如果它使用WebSockets传输,它确实保持打开状态。它还包括使用传统(长)轮询 ajax 请求的回退机制。所以答案取决于浏览器支持哪些 API。(如果有的话,您可以选择配置您想使用的回退。)
Fiddler 现在支持 websockets,Chrome 的开发者工具也支持: