好吧，我知道这听起​​来很普通。但是，我的意思是在一个AJAX的水平。我用萤火虫来跟踪的网络连接和岗位尝试，这是一个谜。有谁知道他们是如何做到的瞬间自动保存不断，不破坏网络/浏览器？

Okay, I know it sounds generic. But I mean on an AJAX level. I've tried using Firebug to track the NET connections and posts and it's a mystery. Does anyone know how they do the instant autosave constantly without DESTROYING the network / browser?

推荐答案

我的猜测（这只是一种猜测）是谷歌采用了推送服务。这似乎是给自己的聊天客户端（这也是在窗口内集成）是最可行的选择也使用此到交货实时信息与最小的延迟。

My guess (and this is only a guess) is that google uses a PUSH service. This seems like the most viable option given their chat client (which is also integrated within the window) also uses this to delivery "real time" messages with minimal latency.

我敢打赌，他们有一个整体的设置，管理所有相关的连接和发送标志来触发特定的元素。你不会看到连接trigers因为初始页面访问建立连接然后就挂在你的网页打开的整个期间。例如，

I'm betting they have a whole setup that manages everything connection related and send flags to trigger specific elements. You won't see connection trigers because the initial page visit establishes the connection then just hangs on the entire duration you have the page open. e.g.

您访问的页面 在浏览器建立[例] api.docs.google.com [/例]连接并保持打开 You visit the page The browser established a connection to [example]api.docs.google.com[/example] and remains open 在失去连接（超时等），在这种情况下，它重新建立 在浏览器窗口关闭

举例，我怎么看，典型的通信：

Example of, how I see, a typical communication:

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＆LT;＆可采用DocName GT; ＆LT;长度GT; ＆LT;内容＆gt; 。然后客户端触发 DOC_AUTOSAVE＆LT;＆可采用DocName GT; ＆LT;长度GT; ＆LT;内容＆GT; 。考虑到潜在的并发请求数，我敢打赌，他们守在请求/响应的背景，这样的东西后发送就可以匹配了。在这个例子中，它知道 IM_OK 相匹配的第二个请求（ IM ）和 AUTOSAVE_OK 第一个请求相匹配（ AUTOSAVE ） - 喜欢的东西怎么AOL的IM协议的原理

Where the DOC_FETCH command is saying I want the data. The server replies with the corresponding DOC_CONTENT <docname> <length> <contents>. Then the client triggers DOC_AUTOSAVE <docname> <length> <content>. Given the number of potential simultaneous requests, I would bet they keep the "context" in the requests/responses so after something is sent it can be matched up. In this example, it knows the IM_OK matches the second request (IM), and the AUTOSAVE_OK matches the first request (AUTOSAVE)--Something like how AOL's IM protocol works.

此外，这只是一种猜测

-

要证明这一点，使用类似空灵，看看你能看到的信息在后台传输。

To prove this, use something like ethereal and see if you can see the information transferring in the background.