我正在使用socket.io,并且安装迅速(这要归功于其用法页面上的示例),但我想了解有关幕后到底发生了什么以及使它起作用的技术的更多信息。
socket.io的确切机制是什么?
是在80端口还是另一个端口上?
它真的保持打开状态或被模拟吗?
有没有一种方法可以分析每个套接字事件?(有点像使用提琴手来查看ajax调用中发生的情况)
我正在使用socket.io,并且安装迅速(这要归功于其用法页面上的示例),但我想了解有关幕后到底发生了什么以及使它起作用的技术的更多信息。
socket.io的确切机制是什么?
是在80端口还是另一个端口上?
它真的保持打开状态或被模拟吗?
有没有一种方法可以分析每个套接字事件?(有点像使用提琴手来查看ajax调用中发生的情况)
Answers:
为了进行调试,您可能需要尝试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现在支持websocket,Chrome的开发人员工具也支持:
