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

---

很多時候，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以快著稱。如下圖，對相同圖片、相同服務器的下載，在不同協議下所需的時間：

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服務器的並發最大為4，OS X為6。而如果你沒有使用共享的Session，則可能會超過這個數。

因此，如果能用共享的Session，還是用共享的吧。有些許的網絡加速，也是一件不錯的事情，您說呢？

結語

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

雖然只是一個簡單的東西，卻也有大文章。