Javascript XHR流媒体通过设计关闭连接？

我正在读这篇文章：，下面的文字引起了我的注意：

XHR流在所有浏览器中都能正常工作 XMLHttpRequest对象将继续增长，直到连接断开 关闭意味着重新连接最终必须被强制清除 这个缓冲区

如果我理解正确，这是否意味着每当缓冲区达到一定大小时（顺便问一下，这里的实际大小是多少？），连接都会自行重置以清除该缓冲区？换句话说，XHR流的寿命与这个缓冲区的大小一样长

---

有人能确认一下吗。

XMLHttpRequest不是设计用于流媒体方式的。只要服务器发送更多数据，浏览器就会继续将其附加到XHR对象中的

responseText

字段

因此，我很确定他们的意思是，使用XHR进行流式处理的JS代码必须定期断开连接并打开一个新的连接，否则会因为保留所有接收到的数据而泄漏内存，并浪费时间重新分配一个不断增长的字符串

---

也就是说，限制是为了获得可接受的长期性能而必须实现的限制，而不是浏览器强加的限制。（很可能浏览器对响应大小也有限制，但我不知道是否有。）

实际上，由于web服务器、前端负载平衡器和ISP代理将具有任何连接的最长生存期，因此连接将更早关闭。如果您想在移动浏览器中使用此功能，则必须使用SSL，否则移动运营商代理将缓冲数据，并且当连接终止时，您将不会得到流式传输，而是整个响应

浏览器有累积正文的内部最大大小，但这个值很高，所以你不太可能点击它。在这种情况下，xhr请求引发错误并终止

---

使用健壮的重试逻辑实现代码。我建议使用HTML5 EventSource，而不是使用普通的XHR。您还可以通过谷歌搜索EventSource的一些SHIM api包装器，例如如何使用XHR进行流式处理。

流式处理是XHR的一个扩展，它允许您在数据进入时检索数据片段。否则，您将不得不等到收到整个消息。无论如何，它仍然有一个缓冲区要填充。实际上，它只适用于少数浏览器。无论如何，Web套接字通常是更好的选择

---

使用常规XHR，您可以有一个很长的轮询请求，服务器在有东西要发送之前不会发送任何东西。当收到某个请求时，您可以让客户端重新启动该请求。在最佳条件下，您可以让该请求永远持续下去，但不能保证中间的某些内容不会中断连接。因此，对于长轮询，您通常希望服务器在一定时间后发送心跳信号，以迫使客户端续订连接（如5分钟）。

Yikes！如果是真的，这是疯狂的。这绝对有道理；web套接字可能更适合用于长期连接。您始终可以修改标头以具有

连接：close

内存泄漏在这里不是合适的术语；我们都知道内存分配在哪里：）@Jack我不同意；具体地说，我说内存泄漏是指包含不再使用的数据的内存最终不会被释放的任何情况（我认为垃圾收集器实现者会同意这一点）。您的定义要么是主观的（“如果不明显，那就是泄漏”），要么意味着垃圾收集程序根据定义不包含泄漏。（我希望这能澄清我的意思；我不打算就单词的定义进行争论。）在我看来，我们需要一个术语来描述代码产生的无限内存消耗，这个术语非常有效，但仍然完全疯狂：）@KevinReid，嘿，我以为我给了答案100分，为什么你只得到50分@skyork你没有选择奖励的答案，所以。