Objective c NSURLConnection在约5分钟后忽略服务器响应–；没有超时

我遇到了一个与

NSURLConnection

有关的问题，我暂时无法解决该问题

我向服务器发出请求，但处理数据需要很长时间（平均约7分钟）。因此，客户端需要等待响应，因此，我尝试通过在

NSURLRequest

中设置长超时来保持HTTP连接打开。我现在不想采用基于投票的解决办法

请求代码：

- (void)sendNextExample
{
    url = ...
    json = ...

    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url
                                                           cachePolicy:NSURLRequestReloadIgnoringCacheData
                                                       timeoutInterval:600.0];
    [request setHTTPMethod:@"POST"];
    [request setHTTPBody:json];
    NSURLConnection *newConnection = [[NSURLConnection alloc] initWithRequest:request
                                                                     delegate:self
                                                             startImmediately:NO];
    if (!queue)
    {
        queue = [NSOperationQueue new];
    }
    [newConnection setDelegateQueue:queue];

    self.connectionStatus = @{@"index" : @(i), @"data" : [NSMutableData data]};
    [newConnection start];
}

处理代码（简化）：

问题是，我从未从服务器收到任何消息，连接超时（600秒后=10分钟，如

NSURLRequest

中所定义），即使该过程似乎在服务器端完成。在连接超时之前，任何时候都不会调用任何委托方法。

---

为了验证服务器进程并将数据正确返回到客户端，我使用curl执行了从完全相同的客户端到完全相同的服务器的多个请求：

curl -H "Content-Type: application/json" -X POST -d '{"foo":0.0, "bar":1.0}' serveraddress:8000

这些请求似乎按预期工作，即上述请求在7分钟后返回正确的数据：

{"bar":0.5, "baz":10.0} // expected data

因此，我怀疑罪魁祸首在于

NSURLConnection

，所有其他事情都是一样的

作为下一步，我使用不同持续时间的服务器端进程执行了几个请求，并发现

NSURLConnection

在请求后大约5分钟后开始忽略响应

---

那么问题自然是，有没有人经历过这种情况？这种行为是否正常/预期？

是否有任何原因（甚至可能是操作系统介导的）

NSURLConnection

会忽略一定时间后收到的数据，即使请求中正确设置了超时？任何可能导致此问题的精细印刷或未记录的“功能”？

最终，切换到

NSURLConnection

以外的东西，比如

AFNetworking

，会不会给我一个绕过这个明显的“限制”的机会

（当然，如果有任何关于如何以另一种方式执行所述任务的建议，也非常欢迎！）

---

为了清楚起见，客户端是Yosemite机器（Xcode 7），服务器是使用.Net 4.5（Windows 8机器）中的

HttpListener

编写的。该服务器已在其他场合进行了测试，并按预期工作

---

编辑：此问题发布半年多后，问题仍然存在。我通过调用cocoa的curl（不是优雅的，而是有效的）成功地完成了我的工作，因此无数次地验证了罪魁祸首确实存在于

NSURLConnection

。我最终得出结论，这是一个bug，并将发布它（如果我有时间这么做的话），但说实话，我没有抱太多希望

---

EDIT2：轮询显然是一种选择。但是，我不能使用轮询，因为我的一些请求需要非常快地返回（如果NSURLConnection失败，NSURLSession和基于它的所有请求都有可能返回，所以不，AFNetworking不应该有任何区别

我很好奇为什么要为每个请求创建一个单独的NSOperationQueue实例。这相当浪费资源；NSURLConnection本质上是异步的，因此它不会阻止操作队列，除非它运行回调代码。除非委托方法必须使用，否则很少有理由使用自己的操作队列出于某种原因，做一些严重的举重

无论哪种方式，甚至使用curl（如果确实需要，您可能只需要链接到libcurl，而不是运行单独的进程），这种设计从根本上说仍然存在问题，因为一旦你在一个糟糕的网络上结束，你就会在服务器完成处理你的请求之前很久超时。此外，如果连接似乎不再使用，一些基于NAT的防火墙可能会忘记映射，此时你的请求将永远不会完成

最好将方法更改为上载数据的方法，服务器为您提供一个URL，您可以在其中检查进度，您的客户端请求该URL，然后服务器提供状态。然后，您的客户端可以每隔一段时间重新检查一次状态，最终通过请求检索已处理的da来结束ta并删除服务器上的文件

---

如果您不介意在web服务器中保持线程运行，您还可以使用MIME多部分响应，这样当您请求该状态URL的内容时，web服务器每n秒发送一个新的状态blob，但这是否是一个好主意取决于您的服务器体系结构。

如果NSURLConnection失败，则很可能是错误的o将NSURLSession和基于它的一切，所以不，AFNetworking不应该有任何区别

我很好奇为什么要为每个请求创建一个单独的NSOperationQueue实例。这相当浪费资源；NSURLConnection本质上是异步的，因此它不会阻止操作队列，除非它运行回调代码。除非委托方法必须使用，否则很少有理由使用自己的操作队列出于某种原因，做一些严重的举重

无论哪种方式，甚至使用curl（如果确实需要，您可能只需要链接到libcurl，而不是运行单独的进程），这种设计从根本上说仍然存在问题，因为一旦你在一个糟糕的网络上结束，你就会在服务器完成处理你的请求之前很久超时。此外，如果连接似乎不再使用，一些基于NAT的防火墙可能会忘记映射，此时你的请求将永远不会完成

服务器提供的方法是，将上传数据的方法改为上传数据的方法

{"bar":0.5, "baz":10.0} // expected data