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个阶段来控制具体的超时。
设置我们的标准超时时间为 N （系统默认为 10秒，网络模块通过暴露相关接口，调用方可自由设置）
链接建立链接超时时间： N * 1.5
每数据包发送超时时间： N * 1.5
数据发送完成等带回包超时： N * 2
每数据包接收超时时间： N * 1
以上超时分别在 NSUrlConnectionDelegate 的各个回调阶段进行相关设置就能达到比较精细的控制。
特别说明下，为什么数据发送完成后等待回包的超时会设置的比较长。因为在实际测试过程中发现发包完成到接收到第一个数据包比较耗时，一般httpbody越大越明显，初步猜测是网络模块在发送数据缓冲区的数据，所以这里做了特殊的控制。
哦了。罗嗦了半天，终于说完了。希望能对大家有帮助。能跳过这个坑。
