别说你会AFNetworking3.0/NSURLSession

2016-02-15 18:10:22 | 来源：玩转帮会 | 投稿：佚名 | 编辑：dations

原标题：别说你会AFNetworking3.0/NSURLSession

本文是投稿文章，作者圣迪

很多时候，AFNetworking都是目前iOS开发者网络库中的不二选择。Github上2W+的star数足见其流行程度。而从iOS7.0开始，苹果推出了新的网络库继承者NSURLSession后，AFNetworking也毫不犹豫地加入了对其的支持。3.0+更加只是提供了NSURLSession的支持。

我们使用AFNetworking的时候，可能会有很多的朋友都会采用以下的写法：

AFHTTPSessionManager*sessionManager=[AFHTTPSessionManagermanager];
sessionManager.requestSerializer=[AFHTTPRequestSerializerserializer];
sessionManager.responseSerializer=[AFHTTPResponseSerializerserializer];
[sessionManagerGET:urlString
parameters:parameters
progress:progressBlock
success:successHandler
failure:failureHandler];

大概可以描述一下这个过程，每次开启一个网络请求时，首先新建一个AFHTTPSessionManager，然后将相关的requestSerializer和reponseSerializer赋值；最后发起相应的GET/POST等请求。

而如果是直接采用NSURLSession来请求网络呢，我们则经常会采用以下的写法：

NSURLSession*session=[NSURLSession
sessionWithConfiguration:
[NSURLSessionConfigurationdefaultSessionConfiguration]
delegate:nil
delegateQueue:[NSOperationQueuemainQueue]];
NSURLSessionDataTask*dataTask=[sessiondataTaskWithRequest:request
completionHandler:completionHandler];
[dataTaskresume];

这个过程其实和上面的基本一致。新建一个Session，然后新建task，激活task，完成网络请求。

那么现在问题来了。为什么每次都需要新建一个SessionManager/Session？如果在多个Task请求的情况下，如果采取一个共享的SessionManager/Session是否可行？如果可行，与之前每次新建SessionManager/Session相比，孰优孰劣？

本篇文章会告诉您：
1. 为什么要使用NSURLSession而不是NSURLConnection
2. 为什么要用共享的SessionManager/Session，而不是每次都启动一个新的

为什么要选择NSURLSession

NSURLSession在iOS7.0时被Apple提出后，虽然Apple一直对其良好的API设计大力推广，然而其能够达到的效果，似乎一直都和NSURLConnection不相伯仲。

特别是在网络的Dependecy依赖处理上，由于AFNetworking优秀的架构设计，NSURLSession甚至还不如NSURLConnection好用。那么，有什么理由切换到NSURLSession？ 2015年的WWDC似乎告诉了我们答案。

HTTP /2, 2015年5月RFC 7540正式发表的下一代HTTP协议，是1999年来HTTP 1.1发布后的首个更新。相对于前一个版本，HTTP /2以快著称。如下图，对相同图片、相同服务器的预告，在不同协议下所需的时间：

http2

这里我们并不打算展开HTTP /2的原理，有兴趣的同学可以Google之。根据2015的WWDC Session711，我们知道iOS9+，NSURLSession开始正式支持HTTP /2，也就意味着你的网络连接速度也可以有如上图那样的提升。

更人性化更优秀的API设计，HTTP /2的支持，这是否能成为你使用NSURLSession的理由？至少它们成为了说服我的理由。

为什么要尽量共享Session，而不是每次新建Session

在回答这个问题以前，我们先来聊聊网络的通讯协议。我们也都知道，HTTP协议是基于TCP协议的。所以在每次的HTTP请求之前，客户端和服务器端，都先需要经过TCP连接的三次握手，即每次请求之前，网络的数据都已经在客户端和服务器端之间来回了三次。如下图：

TCP三次握手（图片来源于网络)

事实上在HTTP 0.9,HTTP 1.0协议的时代，每次HTTP的请求，都需要先经过TCP的连接，然后才开始HTTP的请求，这样一个流程图，我们可以通过抓包看到：

抓包

那么，为了让我们的请求更快，避免每次都产生一个TCP三次握手，成了一个优化的选项。于是在HTTP 1.1中，出现了Connection: keep-alive这个选项。这个优化选项，可以使得客户端和服务器端复用一个TCP连接，从而减小每次的网络请求时间。

非共享Session

共享Session

聊到这里，本章提出的问题，其实答案已经逐渐明了了。没错，共享的Session将会复用TCP的连接，而每次都新建Session的操作将导致每次的网络请求都开启一个TCP的三次握手。

从上面两张图，我们可以清晰地看到，同样都是两次HTTP请求，共享Session的代码在第二次网络请求时少了TCP的三次握手的过程。即加速了整个网络的请求时间。

事实上，苹果的文档中，还对一个服务器最高的TCP并发有相应的描述：

HTTPMaximumConnectionsPerHostProperty
Themaximumnumberofsimultaneousconnectionstomaketoagivenhost.
Declaration
SWIFT
varHTTPMaximumConnectionsPerHost:Int
OBJECTIVE-C
@propertyNSIntegerHTTPMaximumConnectionsPerHost
Discussion
Thispropertydeterminesthemaximumnumberofsimultaneousconnectionsmadetoeachhostbytaskswithinsessionsbasedonthisconfiguration.
Thislimitispersession,soifyouusemultiplesessions,yourappasawholemayexceedthislimit.Additionally,dependingonyourconnectiontotheInternet,asessionmayusealowerlimitthantheoneyouspecify.
Thedefaultvalueis6inOSX,or4iniOS.
Availability
AvailableiniOS7.0andlater.

我们可以看到，默认配置下，iOS对于同一个IP服务器的并发最大为4，OS X为6。而如果你没有使用共享的Session，则可能会超过这个数。

因此，如果能用共享的Session，还是用共享的吧。有些许的网络加速，也是一件不错的事情，您说呢？

结语

To be, or not to be, that is the question.

虽然只是一个简单的东西，却也有大文章。

tags：

相关：