共享AFHTTPSessionManager 单例好处浅析

  不少时候,AFNetworking都是目前iOS开发者网络库中的不二选择。Github2W+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,而后将相关的requestSerializerreponseSerializer赋值;最后发起相应的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

  NSURLSessioniOS7.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


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并发有相应的描述:

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服务器的并发最大为4OS X6。而若是你没有使用共享的Session,则可能会超过这个数。

  所以,若是能用共享的Session,仍是用共享的吧。有些许的网络加速,也是一件不错的事情,您说呢?

 




参考连接:
1.http://www.jianshu.com/p/5969bbb4af9f

2.http://www.jianshu.com/p/a9bca62d8dab
相关文章
相关标签/搜索