不少时候,AFNetworking都是目前iOS
开发者网络库中的不二选择。Github
上2W+
的star
数足见其流行程度。而从iOS7.0
开始,苹果推出了新的网络库继承者NSURLSession
后,AFNetworking
也坚决果断地加入了对其的支持。3.0+
更加只是提供了NSURLSession
的支持。git
咱们使用AFNetworking
的时候,可能会有不少的朋友都会采用如下的写法:github
AFHTTPSessionManager *sessionManager = [AFHTTPSessionManager manager]; sessionManager.requestSerializer = [AFHTTPRequestSerializer serializer]; sessionManager.responseSerializer = [AFHTTPResponseSerializer serializer]; [sessionManager GET:urlString parameters:parameters progress:progressBlock success:successHandler failure:failureHandler];
大概能够描述一下这个过程,每次开启一个网络请求时,首先新建一个AFHTTPSessionManager
,而后将相关的requestSerializer
和reponseSerializer
赋值;最后发起相应的GET/POST
等请求。sql
而若是是直接采用NSURLSession
来请求网络呢,咱们则常常会采用如下的写法:ruby
NSURLSession *session = [NSURLSession sessionWithConfiguration: [NSURLSessionConfiguration defaultSessionConfiguration] delegate:nil delegateQueue:[NSOperationQueue mainQueue]]; NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request completionHandler:completionHandler]; [dataTask resume];
这个过程其实和上面的基本一致。新建一个Session
,而后新建task
,激活task
,完成网络请求。服务器
那么如今问题来了。为何每次都须要新建一个SessionManager/Session
?若是在多个Task
请求的状况下,若是采起一个共享的SessionManager/Session
是否可行?若是可行,与以前每次新建SessionManager/Session
相比,孰优孰劣?网络
本篇文章会告诉您:
1. 为何要使用NSURLSession而不是NSURLConnection
2. 为何要用共享的SessionManager/Session
,而不是每次都启动一个新的 session
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
以快
著称。以下图,对相同图片、相同服务器的下载,在不一样协议下所需的时间: app
这里咱们并不打算展开HTTP /2
的原理,有兴趣的同窗能够Google之。根据2015的WWDC Session711,咱们知道iOS9+
,NSURLSession
开始正式支持HTTP /2
,也就意味着你的网络链接速度也能够有如上图那样的提高。
更人性化更优秀的API
设计,HTTP /2
的支持,这是否能成为你使用NSURLSession
的理由?至少它们成为了说服个人理由。
在回答这个问题之前,咱们先来聊聊网络的通信协议。咱们也都知道,HTTP
协议是基于TCP
协议的。因此在每次的HTTP
请求以前,客户端和服务器端,都先须要通过TCP
链接的三次握手,即每次请求以前,网络的数据都已经在客户端和服务器端之间来回了三次。以下图:
事实上在HTTP 0.9
, HTTP 1.0
协议的时代,每次HTTP的请求,都须要先通过TCP
的链接,而后才开始HTTP
的请求,这样一个流程图,咱们能够经过抓包看到:
那么,为了让咱们的请求更快,避免每次都产生一个TCP
三次握手,成了一个优化的选项。因而在HTTP 1.1
中,出现了Connection: keep-alive
这个选项。这个优化选项,可使得客户端和服务器端复用一个TCP
链接,从而减少每次的网络请求时间。
聊到这里,本章提出的问题,其实答案已经逐渐明了了。没错,共享的Session
将会复用TCP
的链接,而每次都新建Session
的操做将致使每次的网络请求都开启一个TCP
的三次握手。
从上面两张图,咱们能够清晰地看到,一样都是两次HTTP请求,共享Session
的代码在第二次网络请求时少了TCP
的三次握手的过程。即加速了整个网络的请求时间。
事实上,苹果的文档中,还对一个服务器最高的TCP
并发有相应的描述:
HTTPMaximumConnectionsPerHost Property
The maximum number of simultaneous connections to make to a given host.
Declaration
SWIFT
var HTTPMaximumConnectionsPerHost: Int
OBJECTIVE-C
@property NSInteger HTTPMaximumConnectionsPerHost
Discussion
This property determines the maximum number of simultaneous connections made to each host by tasks within sessions based on this configuration.
This limit is per session, so if you use multiple sessions, your app as a whole may exceed this limit. Additionally, depending on your connection to the Internet, a session may use a lower limit than the one you specify. The default value is 6 in OS X, or 4 in iOS. Availability Available in iOS 7.0 and later.
咱们能够看到,默认配置下,iOS
对于同一个IP服务器的并发最大为4
,OS X
为6
。而若是你没有使用共享的Session
,则可能会超过这个数。
所以,若是能用共享的Session
,仍是用共享的吧。有些许的网络加速,也是一件不错的事情,您说呢?