这是一个让我质疑自己的理智的问题，但我发布这个问题以防万一它是真实的，而不是我自己制造的问题。
我有一个使用 NSURLConnection 类向网络服务器发送请求的 iOS 应用程序。该对象被实例化并指示回调委托，委托接收相应的通知didReceiveResponse/didReceiveData/didFinishLoading/didFailWithError。实际上与在 Apple 的开发页面上发布的用于使用该类的代码相同。这些请求都是带有 JSON 数据的短 POST 传输；响应也是 JSON 格式的，并且来自 Apache Tomcat Java Servlet。
在大多数情况下，这一切都像宣传的那样工作。该应用程序向服务器发送一系列请求，以启动作业并轮询部分结果。大多数交换都很短，但有时当有部分结果可用时，结果最多可达 100-200Kb 左右。
操作系统以每次大约 10Kb 的块的形式将各个数据片段交还给或接受。传输本质上是即时的，因为它正在与 LAN 上的测试服务器通信。
然而：经过几十次投票操作后，运输速度几乎停滞不前。response/data.../finished 序列正常工作：网络服务器已交付其有效负载，但 iOS 应用程序正在接收 2896 个字节，块之间的周期为 20-30 秒。这是正确的数据，等待大约 5 分钟等待 130Kb 的数据确实可以确认它运行正常。
我所做的一切似乎都不能方便地解决它。我尝试使用响应块切换到“异步”调用方法；同样的结果。与远程网站而不是我的 LAN 测试部署交谈会得到相同的结果。在模拟器或 iPhone 中运行得到相同的结果。服务器返回内容长度并且不会尝试做任何奇怪的事情，比如保持连接处于活动状态。
改变轮询的频率几乎没有什么效果，除非我将轮询之间的延迟提高到 50 秒，否则一切正常，大概是因为它最终只轮询一次或两次。
一个符合这个观察的假设是 NSURLConnection 对象在它被释放后很长时间仍然存在，并且消耗资源。一旦达到某个限制，进度就会几乎停止。如果慢下来的连接真的完成了，后续的连接会再次正常工作，大概是因为它们已经被清理干净了。
那么这听起来对任何人来说都很熟悉吗？