AFNetworking3.0/NSURLSession的应用

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

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

 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等请求。

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

 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,而不是每次都启动一个新的

为什么要选择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以快著称。如下图,对相同图片、相同服务器的下载,在不同协议下所需的时间:

296122-d76449b90eebfc25.jpg

这里我们并不打算展开HTTP /2的原理,有兴趣的同学可以Google之。根据2015的WWDCSession711,我们知道iOS9+,NSURLSession
开始正式支持HTTP /2,也就意味着你的网络连接速度也可以有如上图那样的提升。
  更人性化更优秀的API设计,HTTP /2的支持,这是否能成为你使用NSURLSession的理由?至少它们成为了说服我的理由。

为什么要尽量共享Session,而不是每次新建Session
  在回答这个问题以前,我们先来聊聊网络的通讯协议。我们也都知道,HTTP协议是基于TCP协议的。所以在每次的HTTP请求之前,客户端和服务器端,都先需要经过TCP连接的三次握手,即每次请求之前,网络的数据都已经在客户端和服务器端之间来回了三次。如下图:

296122-f6932d96790bbd26.jpg

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

296122-2998a53099462670.jpg

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


296122-a554b8be10ca7189.jpg
296122-5a48e040e9b4371d.jpg

聊到这里,本章提出的问题,其实答案已经逐渐明了了。没错,共享的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,还是用共享的吧。有些许的网络加速,也是一件不错的事情,您说呢?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容