这种事情最好使用WebSockets http://www.html5rocks.com/en/tutorials/websockets/basics/现在，根据 CanIUse.Com 的说法是适用于所有主流浏览器 https://caniuse.com/#search=websocketsOpera Mini 除外（有关旧版或所有浏览器的更多详细信息，请参阅该链接，并单击“资源”选项卡以查看更多链接）。总而言之，IE 10+、Edge 12+、Firefox 11+（如果在 WebWorker 上下文中则为 38+）、Chrome 16+、Opera 12.1+、Safari 7+、Android 4.4+、Opera Mobile 12.1+ 支持 Websocket。
注意：您可能想了解Service Worker 和 Web Worker https://aarontgrogg.com/blog/2015/07/20/the-difference-between-service-workers-web-workers-and-websockets/同样，尽管它们有不同的用例和不同的能力。
它看起来像这样：
var connection = new WebSocket(
'ws://html5rocks.websocket.org/echo',
['soap', 'xmpp']
);
将一些事件处理程序立即附加到连接可以让您知道连接何时打开、何时收到传入消息或是否发生错误。
发送消息变得如此简单：
connection.send('your message');
connection.send(binaryData);
See WebSocket 简介：将套接字引入 Web http://www.html5rocks.com/en/tutorials/websockets/basics/有关如何执行此操作的完整说明。
ASP.Net 开发人员：如果由于某种原因您需要支持较旧的浏览器并且不想自己弄清楚如何处理那些不支持 WebSockets 的浏览器，请考虑使用诸如SignalR http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr.
针对旧浏览器的旧 EventSource API 答案
现在大多数浏览器都实现了事件源API http://www.w3.org/TR/eventsource/#the-eventsource-interface，这使得长轮询变得非常容易，只要可以使用内容类型传递流text/event-stream。较旧的浏览器或那些因任何原因无法设计流以具有该内容类型的开发人员可以使用一些帮助脚本 https://github.com/Yaffle/EventSource做同样的事情。
这是一个例子：
var jsonStream = new EventSource('https://example.com/yourstreamingservice')
jsonStream.onmessage = function (e) {
var message = JSON.parse(e.data);
// handle message
};
这基本上是我在下面概述的内容的完整版本。
对于非常老的浏览器来说，更老的服务流解决方案
您想要的称为长轮询。您需要一个自定义 AJAXonreadystatechange处理功能。您需要定期检查内容，而不是等到整个流完成（因为它永远不会完成）。请注意，您需要做一些繁重的工作才能在 IE 9 及更低版本中工作，使用iframe.
Roughly:
- 回复每一个
onreadystatechange事件并检查您分配给当前角色的流，以查看是否有足够的数据来消耗一个或多个离散事件。您需要使用 JavaScript 字符串处理函数自行解析流。可以使用 split、indexOf、正则表达式、循环等组合来完成此任务。
- 如果还没有足够的内容，则退出并等待下一个事件。
- 我非常确定每次
onreadystatechange处理程序火灾，responseText将是迄今为止已收到的所有数据。定义一个持久变量，用于保存尚未正确处理的第一个字符的位置。
- 一旦有足够的内容供一个或多个离散事件出现在流中，一次取出一个事件并将它们传递到 JSON 解析器以实际将文本呈现为对象。正常使用它们。
看看这个HTTP 流要点 https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88对于一种资源，或者流式传输作为轮询服务器的替代方案 http://softwareas.com/http-streaming-an-alternative-to-polling-the-server/在 SoftwareAs。如果您必须支持 IE 9 或更早版本，那么您需要使用iframe方法。
Here is 这本书Ajax 设计模式：使用编程和可用性模式创建 Web 2.0 站点 https://rads.stackoverflow.com/amzn/click/com/0596101805:
总之，服务流使 HTTP 流方法更加灵活，因为您可以流式传输任意内容而不是 Javascript 命令，并且因为您可以控制连接的生命周期。然而，它结合了两种在浏览器之间不一致的技术，并且存在可预测的可移植性问题。实验表明，页面流技术确实适用于 IE [9 及更早版本] 和 Firefox，但服务流仅适用于 Firefox，无论使用 XMLHTTPRequest 还是 IFrame。在第一种情况下，IE [9 及更早版本] 会抑制响应直至其完成，如果使用解决方法，则 IFrame 可以正常工作： IE [9 及更早版本] 在前 256 个字节之后接受来自服务器的消息，因此唯一的事情是要做的就是在发送消息之前发送 256 个虚拟字节。此后，所有消息都将按预期到达。因此，完整的服务流在 IE [9 及更早版本] 中也是可能的！
请注意，它是 2006 年的，所以它肯定已经过时了，但如果您必须支持较旧的浏览器，它仍然相关。
安全问题
普通的 AJAX 不能跨域，这意味着（现在我注意到你想从 twitter 流式传输）你将无法执行你所要求的操作。这可以通过 JSONP 来解决，但 JSONP 本质上不能进行服务流传输，而且 Twitter 也不提供这种服务。还有跨域资源共享 http://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing（CORS）但是 Twitter 不会为你设置这个——他们只会对附属于他们的域做这种事情。 CORS 需要现代浏览器。
因此，您唯一的选择是在您的 Web 服务器上创建一个代理服务，该服务为您执行对 twitter 的请求，然后分发数据。这只能从提供主页的同一域中完成。这样做还可以让您使用 iframe 技术创建一个适用于 IE 的版本。如果您不关心旧的 IE 版本，并且知道将发出请求的域，则可以自行实施 CORS 来克服域限制。
如果您完全控制客户端软件（例如，如果这是用于公司内部网），则还有另一种选择：将 Web 浏览器托管在已编译的本地执行应用程序的用户表单内。我只使用 C# 完成了此操作，但我认为其他语言也可以做到这一点。当您使用正确的浏览器对象时，因为它托管在 C# 应用程序内，所以 C# 应用程序可以克服跨域安全限制，读取和写入所有页面内容，无论它来自哪个域。我怀疑你的情况是这样的，但我想把这个选项放在这里，供其他可能会欣赏它的人使用。
