为什么在通过蜂窝网络下载图像时总是出现 NSURLConnection 超时? [英] Why do I always get NSURLConnection timeouts when downloading images over cellular networks?

查看:50
本文介绍了为什么在通过蜂窝网络下载图像时总是出现 NSURLConnection 超时?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的应用程序似乎在蜂窝网络上运行得非常糟糕 - 用户界面通常有微调器而不是图像,但并非总是如此.它使用由并发 NSOperations 驱动的 NSURLConnections.它在 WIFI 上运行良好 - 完全没有问题.

My app appears to work terribly over cellular networks - the UI often has spinners instead of images, but not always. It uses NSURLConnections driven by concurrent NSOperations. It works fine on WIFI - no problems at all.

我发现我收到了很多 NSURLConnection 超时,但不知道为什么.我如何追踪这个问题?

I discovered I'm getting many NSURLConnection timeouts, but have no idea why. How can I track this problem down?

推荐答案

为了追查问题,我首先测量了最大并发连接数,发现它一直在 55 左右.

To track down the problem, I first measured the maximum number of concurrent connections, and discovered that this was consistently around 55.

  • 将最大值减少到 10(通过设置操作队列最大值,减少超时,但仍然不完美

  • reduced the maximum to 10 (by setting the operation queue max value, less timeouts, but still not perfect

将最大值减少到 4 - 甚至更少的超时,但仍然有一些

reduced the maximum to 4 - even less timeouts but still got some

将最大值设置为 1 - 这必须起作用,对吗?不!

set the maximum to 1 - this has got to work, right? Nope!

有时应用程序可以在完全没有并发的情况下正常工作(最大 == 1),但它仍然有大约一半的时间失败.

Sometimes the app would work properly with no concurrency at all (max == 1), but it still failed about half the time.

因此,我与 Apple 发生了支持事件,并请了一位最有经验的工程师提供建议.根据他的建议,我尝试了以下操作:

So I burned a support incident with Apple and got one of there most experienced engineers to advise. Based on suggestions from him I tried the following:

  • 在不同运营商的蜂窝网络 (Verizon) 上运行该应用,并且运行良好.所以问题不是蜂窝本身(或 iOS)而是 AT&T 的蜂窝网络(纽约和新泽西都失败)

  • ran the app on a different carrier's cellular network (Verizon), and it worked perfectly. So the issue was not cellular per se (or iOS) but AT&T's cellular network (NY and NJ both fail)

从 http 切换到 https,现在它可以在 AT&T 上以完全并发的方式完美运行

switched from http to https, now it works flawless on AT&T with full concurrency

调查了 web 端点以确定其功能,结果证明它很差(稍后会详细介绍).我尝试了一个具有更多功能的不同 Web 端点,使用 http 解决了最初的问题.

investigated the web endpoint to determine its capabilities, which turned out to be pretty poor (more later). I tried a different web endpoint with more capabilities, and the original problem went away using http.

我从中学到的如下:

  • 使用 iOS5.1 或 iOS6 没有区别

  • there was no difference using iOS5.1 or iOS6

如果您在 AT&T 3G 上遇到此问题并且正在使用 http,请尝试切换到 https

if you have this problem on AT&T 3G and are using http, try switching to https

如果端点使用 HTTP1.0 并且不支持Connection: keep-alive",那么每个 http 请求都在建立和拆除 TCP 连接.我相信这种蜂窝网络的颠簸"是 AT&T 断开我的一些会话的原因,但当然无法确定这一点.

if the endpoint is using HTTP1.0 and does NOT support 'Connection: keep-alive', then every http request is setting up and tearing down a TCP connection. I believe this 'thrashing' of the cellular network is why AT&T was disconnecting some of my sessions, but of course have no way to know this for sure.

使用支持长连接的HTTP1.1服务,问题消失.在这种情况下,没有 TCP 连接抖动.

using a HTTP1.1 service that supports persistent connections, the problem disappeared. In this case there is no TCP connection thrashing.

一些 HTTP1.1 服务支持流水线",iOS 也是如此(使用 NSURLRequest 设置,HTTPShouldUsePipelining),如果我可以切换到这个,那么我的性能应该会大大提高

some HTTP1.1 services support 'pipelining', as does iOS (using the NSURLRequest setting, HTTPShouldUsePipelining), and if I can switch to this then my performance should greatly improve

有一个 WWDC 2012 视频讨论了如何提高网络性能:Session 706网络最佳实践"

there is a WWDC 2012 video that discusses how to improve network performance: Session 706 "Networking Best Practices"

编辑

所以当我剥洋葱时,这变得更奇怪了!经过进一步讨论,一些网络人员用 CloudFront 进行了测试,它确实接受了连接:保持活动".我昨天反复尝试让它工作,但不能.

So this just gets more bizarre as I peel the onion! After further discussion, some web people did a test with CloudFront, and it did accept 'Connection: keep-alive'. I tried over and over to get it to work yesterday, but could not.

网络专家建议我在使用 https 和 low 时尝试一下,看看它确实做到了!出于某种原因,当在 AT&T 3G 上使用http"时,该标头标签要么被删除,要么被忽略.我也用 Wifi 测试了我的应用程序.在除 AT&T/3G 之外的所有情况下,响应中都返回了连接".

The web expert suggest I try it when using https and low and behold it did! For some reason, when using 'http' over AT&T 3G, that header tag is either removed or ignored. I tested my app with Wifi too. In all cases but AT&T/3G the 'Connection' was returned in the response.

这篇关于为什么在通过蜂窝网络下载图像时总是出现 NSURLConnection 超时?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆