一个编写iOS代码的经典场景：用户进入某个Controller，发起Http网络请求从Server获取数据，在数据返回之前用户退出了Controller。此时是否需要Cancel之前发出的网络请求呢？
如果请求的数据只在当前Controller产生内容，结论当然是需要Cancel，虽然我知道不少iOS程序员因为偷懒而忘了取消。我们用工程的思维，深入本质，一起看下这背后都发生了什么，如果不Cancel会有哪些副作用。
我们可以把一个Http请求分为这几步：
第一步：三次握手
这一步会有三个packet产生，sync，sync+ack，ack。
第二步：客户端发送Http的request
此处根据请求类型产生的packet数量会有差异。
第三步：客户端接收Server的Http Response
根据Response的大小，产生的packet数量不相同，一般一个packet在1.5KB左右。
通过代码查看测试样本
我们在Demo项目中运行如下代码，再配合tcpdump抓包看看背后究竟发生了什么？
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration]; AFURLSessionManager *manager = [[AFURLSessionManager alloc] initWithSessionConfiguration:configuration]; NSURL *URL = [NSURL URLWithString:@"http://httpbin.org/get"]; NSURLRequest *request = [NSURLRequest requestWithURL:URL]; NSURLSessionDataTask *dataTask = [manager dataTaskWithRequest:request completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) { if (error) { NSLog(@"Error: %@", error); } else { NSLog(@"%@ %@", response, responseObject); } }]; [dataTask resume]; |
|
1 2 |
sudo tcpdump -i rvi0 -AAlnn src 23.22.14.18 or dst 23.22.14.18 |
下图是tcpdump获取的结果：
- 图中标号1，2，3表示的tcp三次握手。
- 标号4是客户端发送Http Get，标号5是Server Ack。
- 标号6是Server Response。
后面还有几个断开tcp连接的包被我省去了，前面这6个packet足以说明问题了。
上述三步中，前两步消耗的是用户上行的流量，第三步用的下行的流量。国内移动运营商对于上行和下行的流量都算在包月的总流量当中的，所以如果用户在第六个或者之后的Packet没有返回之前退出Controller的话，后续的Packet依然会通过连接，走下行通道，抵达我们的客户端，耗费用户的流量，Response往往还是一个请求的流量大头。
如果我们在请求返回之前，调用Cancel:
|
1 2 |
[dataTask cancel]; |
取消请求的话，客户端会发送如下一个Reset Packet断开当前的Http连接，阻止后续的流量产生：
所以结论是：如果不Cancel，请求完成之后通过回调找到delegate，如果是weak引用，Controller被释放，delegate变为nil，业务流程被中断，代码还算安全。但是会的的确确浪费一些用户流量。养成好习惯，自己产生的垃圾自己清理哦。
欢迎关注公众号：
