如果你用的 AFNetworking
- (NSMutableURLRequest *)requestWithMethod:(NSString *)method path:(NSString *)path parameters:(NSDictionary *)parameters
//方法通过添加
[request setTimeoutInterval:10.0];
如果是 ASIHTTPRequest
[request setNumberOfTimesToRetryOnTimeout:2];
NSMutableURLRequest是NSURLRequest的子类，常用方法有
设置请求超时等待时间（超过这个时间就算超时，请求失败）
NSMutableURLRequest *urlRequest = [[NSMutableURLRequestalloc] initWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicytimeoutInterval:10]; NSURLConnection *_connection = [[NSURLConnectionalloc] initWithRequest:urlRequest delegate:selfstartImmediately:YES];
一个用来创建请求，一个用来将请求发送出去。然后我们实现 NSUrlConnectionDelegate 的几个回调函数就能完成整个流程了。
一般发送网络请求都会去设置一个超时时间，防止请求在那一直等待。根据不同的场景，我们还需要设置不同的超时时间。在上面的代码中我们设置了10秒超时。
上面的故事看起来很完美。但是 apple的开发人员在这里给我们挖了一个坑。
如果你的请求是个简单的“Get”请求，或者木有 body的“post”请求。一切都是那么完美，请求能够按照我们设定的时间自动超时。但是如果你发的是个“POST”请求，并且[urlRequest setHTTPBody:httpBody]; 那么，不好意思，你被潜规则了。
ios3.0 以后 苹果的sdk对这种情况做了调整，如果是post请求，并且设置了 httpBody，那么请求的超时时间就被默认设置为 240 秒了。就算你再使用[urlRequest setTimeoutInterval:10];也是无效的，我们可以再设置完成后再读取这个值，发现它不会变成10，依然保持240秒。于是乎，网络不稳定的时候，你的程序就可能会陷入漫长的等待。
发现这个问题后。我们通过自己起timer的方式来控制超时。具体怎么弄这里就不细说。只说下我们的策略。
我们将整个网络过程分为 链接建立，发送数据，数据发送完成等待回包，接收数据 4个阶段来控制具体的超时。
d
标签：ios,超时,请求
