我的猜测(这只是猜测)是谷歌使用PUSH服务.这似乎是最可行的选择,因为他们的聊天客户端(也集成在窗口中)也使用它来以最小的延迟传递“实时”消息.
我打赌他们有一个完整的设置管理所有相关的连接,并发送标志来触发特定的元素.您将看不到连接分支,因为初始页面访问建立了连接,然后在您打开页面的整个持续时间内挂起.例如
>您访问该页面
>浏览器建立了与[示例] api.docs.google.com [/ example]的连接并保持打开状态
>然后,客户端代码发送各种命令并接收各种响应.
>这些命令来回发送,直到您：
>丢失连接(超时等),在这种情况下重新建立连接
>浏览器窗口已关闭
我如何看待典型的沟通示例：
SERVER: CLIENT:
------- -------
DOC_FETCH mydocument.doc
DOC_CONTENT mydocument.doc 15616 ...
DOC_AUTOSAVE mydocument.doc 24335 ...
IM collaboratorName Hi Joe!
IM_OK collaboratorName OK
AUTOSAVE_OK mydocument.doc OK
DOC_FETCH命令说我想要数据.服务器回复相应的DOC_CONTENT< docname> <长度> <内容> ;.然后客户端触发DOC_AUTOSAVE< docname> <长度> <内容取代.考虑到潜在的同时请求的数量,我敢打赌他们在请求/响应中保留“上下文”,因此在发送内容之后它可以匹配.在此示例中,它知道IM_OK与第二个请求(IM)匹配,并且AUTOSAVE_OK与第一个请求(AUTOSAVE)匹配 - 类似于AOL的IM协议如何工作. 再次,这只是猜测. – 要证明这一点,请使用ethereal之类的内容,看看您是否可以在后台看到信息传输.
