Firebase流式REST连接是否会计入并发连接限制？
在最近的一个问题中，有人指出Firebase定价文档指出：
REST API请求不计入您的连接限制
我理解（并欣赏）这个语句似乎意味着什么：针对REST API的GET，PUT，POST和DELETE请求通常用于对数据的非实时操作，例如下载数据以备份或批量计算。 这些通常是不常见的，相对短暂的操作，并且通常应该使实时数据连接的数量相形见绌。
但是，当我们查看Firebase的REST流API时，情况会有所不同。 与REST API的其余部分不同，流式传输显然适用于实时数据连接。
根据上面引用的文档，这些连接不应计入连接限制。 但根据Firebase开发人员对Google网上论坛的评论 ：
concurrent [connections]是实时客户端或流式REST
我强调的部分似乎暗示使用流式REST API的客户端确实计入连接限制。
为了测试，我编写了一个小型C＃客户端，它使用Firebase REST流API来监控节点：
var url = "https://.firebaseio.com/clock/.json"; var client = new WebClient(); client.Headers["Accept"] = "text/event-stream"; using (var stream = client.OpenRead(url)) { using (var reader = new StreamReader(stream)) { string line = null; while (null != (line = reader.ReadLine())) { (DateTime.Now.ToShortTimeString() + line).Dump(); } } } 启动此程序大约15分钟后，我的Firebase仪表板中的并发连接确实上升了1.运行第二个实例，再次增加了仪表板中的并发连接数。
因此，此测试似乎证实了Google网上论坛的暗示：REST流媒体客户端被视为并发连接。 有人可以在我的测试中证实这一点或发现一个缺陷吗？
你的假设是正确的。 通过REST API进行的流式调用确实会计算逻辑上应该计算的并发数（即它们保持打开套接字连接并创建额外的负载）。 针对REST API的非流式调用不计为并发连接。
我将查看定价页面，看看我们是否可以使文本更清晰一些。