我正在阅读这篇文章：http ://blog.pusher.com/what-came-before-websockets /，下面的文字引起了我的注意：
XHR Streaming 在所有浏览器中都有效，XMLHttpRequest 对象的 responseText 将继续增长，直到连接关闭，这意味着最终必须强制重新连接以清除此缓冲区。
如果我理解正确，这是否意味着每当缓冲区达到一定大小时（顺便说一下，这里的实际大小是多少？），连接将自行重置以清除此缓冲区？换句话说，XHR 流与这个缓冲区的大小一样长？
有人可以确认这一点。
XMLHttpRequest 不是为以流方式使用而设计的。只要服务器发送更多数据，浏览器就会继续将其附加到responseTextXHR 对象中的字段。
因此，我很确定他们的意思是使用 XHR 进行流式传输的 JS 代码必须定期断开连接并打开一个新连接——否则由于保留所有接收到的数据而导致内存泄漏，以及浪费时间重新分配一个永远增长的字符串。
也就是说，限制是您必须实施才能获得可接受的长期性能的限制，而不是浏览器强加的限制。（很可能还有浏览器对响应大小施加的上限，但我不知道是否存在。）
实际上，连接会更早关闭，因为 Web 服务器、前端负载平衡器和 ISP 代理对于任何连接都将具有最长的生命周期。如果你想在移动浏览器上使用它，你必须使用 SSL，否则移动运营商代理将缓冲数据，当连接终止时，你将不会获得流式传输，而是整个响应。
浏览器对累积的正文文本有内部最大大小，但这很高，所以你不太可能点击它。在这种情况下，xhr 请求会引发错误并终止。
使用强大的重试逻辑实现您的代码。我建议使用 HTML5 EventSource 而不是使用普通的 XHR。您还可以搜索一些用于 EventSource 的 SHIM api 包装器，例如如何使用 XHR 进行流式传输。
Streaming 是 XHR 的扩展，它允许您在数据进入时检索数据片段。否则您必须等到收到整个消息。无论如何，它仍然有一个缓冲区要填充。实际上，它仅适用于少数浏览器。无论如何，Web 套接字通常是更好的选择。
使用常规 XHR，您可以有一个长轮询请求，其中服务器不发送任何东西，直到它有东西要发送。收到东西后，您可以让客户端重新发起请求。在最佳条件下，您可以让该请求永远持续下去，但您不能保证中间的某些东西不会终止连接。因此，对于长轮询，您通常希望服务器在一定时间后发送心跳以强制客户端更新连接（如 5 分钟）。