在过去的几天里，我试图调试d00m的网络错误。我开始耗尽想法/线索，我希望其他SO用户有宝贵的经验，可能是有用的。我希望能够提供所有相关信息，但我个人无法控制服务器环境。
整个事情开始于用户注意到我们应用中的几个"网络错误"。错误似乎是随机发生的，没有任何与互联网连接，iOS版本或后端更新相关的明显模式。在后台发生的两个错误是:
Error Domain=NSURLErrorDomain Code=-1001 "The request timed out."
和更常见的
Error Domain=kCFErrorDomainCFNetwork Code=-1005 "The network connection was lost.
在调试了几天之后，我已经设法通过触发大约来重现这些错误(随机发生)。10个随机(GET和POST)请求，每个请求之间有一个随机睡眠计时器(设置为1-20秒)。然而，它只发生在时期。我最近几天的经历是，当一个"错误周期"开始时，我每运行一次或两次代码就会得到两个错误中的一个(这意味着错误率为1/10或1/20请求)。这个错误率持续几个小时，然后错误消失几个小时，然后一切重新开始。
关于设置的一些快速事实:
- 发生在设备和模拟器上
- 发生在iOS 8.4和iOS 7.1 -尽管v. 8.4是我用于测试的主要版本。
- 我们使用
NSURLSession作为我们的网络请求。我们还包括AFNetworking(更新到最新版本)，但我们只使用SSL固定的安全部分。即使SSL绑定完全关闭，错误仍然发生。
我在过去的几天里写下了一些发现:
- 它似乎只发生在我们的生产环境中，它与我们的登台环境有一些不同的配置。这使我认为它可能与这里和这里讨论的
keep-alive错误有关。但是，我们的ops部门已经建立了一个新的登台环境，发送与生产环境相同的keep-alive头，但是这并没有使错误发生在登台环境上。 - 我们的Android版本的应用程序无法使用相同的请求设置重现错误。此外，我们还没有收到任何关于Android应用中"网络错误"的客户问题。
我的直觉告诉我，这与服务器环境和iOS中的HTTP实现有关。然而，我无法找到一个令人信服的模式来证明任何事情。我使用一个简单的Rails脚本进行了相同的设置，当下一次"错误期"发生时，我将准备尝试在iOS之外复制它。当发生这种情况时，我会更新问题。
我不是在寻找涉及重置wifi设置，关闭模拟器或类似的解决方案，因为我不认为这是生产环境中可行的解决方案。我也考虑过在GitHub问题中提到的重试循环修复，但我认为这是最后的手段。
如果你需要更多的信息，请告诉我。根据我的经验，这些类型的问题通常指向大量的数据包丢失，特别是在蜂窝网络中，多径干扰和其他问题的微小变化可能会导致可靠传输流量的差异。
另一个想到的可能性是低质量的NAT实现，在不太可能的情况下，你的服务器的超时时间足够长，导致NAT放弃TCP连接。
无论哪种方式，唯一确定发生了什么的方法是进行数据包跟踪。要做到这一点，需要通过有线连接将Mac连接到互联网，启用Wi-Fi网络共享功能，并将iOS设备连接到该Wi-Fi网络。然后运行Wireshark，让它监控网桥接口。说明:
http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/从那里，您应该能够准确地看到正在发送的内容和时间。这可能有助于理解为什么它失败了。
好吧，我花了很多时间调查类似的问题。
1005可能是由已知的iOS错误引起的，有几个修复。例如添加header"Connection"值为"close"。更多信息
1001是一个不同的故事。在我的情况下，问题是服务器上的防火墙奇怪(坏?)。当短时间内有很多(不是很多)请求时，它会禁止设备。
如果你遇到类似的问题，我相信你可以做简单的测试。
- 在循环中发送大量请求(取决于防火墙设置)(假设在1秒内发送50个请求)。
- 关闭/杀死应用程序(这将关闭与服务器的连接)
- (可选)等一会儿(比如60秒)
- 重新启动应用程序并尝试发送请求
如果你现在所有的下一个请求都超时了，你可能有同样的问题，你应该和服务器人员谈谈。
PS:如果你没有访问服务器，你可以给用户的信息，他应该重启设备上的wifi退出超时循环。在某些情况下，这可能是最后的手段。