iOS 7 和 Mac OS X 10.9 Mavericks 中一個顯著的變化就是對 Foundation URL 加載系統的徹底重構。

現在已經有人在深入蘋果的網絡層基礎架構的地方做研究了，所以我想是時候來分享一些對于我對于這些新的 API 的看法和心得了，新的 API 將如何影響我們編寫程序，以及它們對于 API 設計理念的影響。

NSURLConnection

作為 Core Foundation / CFNetwork 框架的 API 之上的一個抽象，在 2003 年，隨著第一版的 Safari 的發布就發布了。NSURLConnection這個名字，實際上是指代的 Foundation 框架的 URL 加載系統中一系列有關聯的組件：NSURLRequest、NSURLResponse、NSURLProtocol、 NSURLCache、 NSHTTPCookieStorage、NSURLCredentialStorage 以及同名類 NSURLConnection。

NSURLRequest被傳遞給 NSURLConnection。被委托對象（遵守以前的非正式協議 <NSURLConnectionDelegate>和 <NSURLConnectionDataDelegate>）異步地返回一個 NSURLResponse以及包含服務器返回信息的 NSData。
在一個請求被發送到服務器之前，系統會先查詢共享的緩存信息，然后根據策略（policy）以及可用性（availability）的不同，一個已經被緩存的響應可能會被立即返回。如果沒有緩存的響應可用，則這個請求將根據我們指定的策略來緩存它的響應以便將來的請求可以使用。

在把請求發送給服務器的過程中，服務器可能會發出鑒權查詢（authentication challenge），這可以由共享的 cookie 或機密存儲（credential storage）來自動響應，或者由被委托對象來響應。發送中的請求也可以被注冊的 NSURLProtocol對象所攔截，以便在必要的時候無縫地改變其加載行為。
不管怎樣，NSURLConnection作為網絡基礎架構，已經服務了成千上萬的 iOS 和 Mac OS 程序，并且做的還算相當不錯。但是這些年，一些用例——尤其是在 iPhone 和 iPad 上面——已經對 NSURLConnection
的幾個核心概念提出了挑戰，讓蘋果有理由對它進行重構。
在 2013 的 WWDC 上，蘋果推出了 NSURLConnection的繼任者：NSURLSession。
和 NSURLConnection一樣，NSURLSession指的也不僅是同名類 NSURLSession，還包括一系列相互關聯的類。NSURLSession包括了與之前相同的組件，NSURLRequest與 NSURLCache，但是把 NSURLConnection替換成了 NSURLSession、NSURLSessionConfiguration以及 NSURLSessionTask的 3 個子類：NSURLSessionDataTask，NSURLSessionUploadTask，NSURLSessionDownloadTask。
與 NSURLConnection相比，NSURLsession最直接的改進就是可以配置每個 session 的緩存，協議，cookie，以及證書策略（credential policy），甚至跨程序共享這些信息。這將允許程序和網絡基礎框架之間相互獨立，不會發生干擾。每個 NSURLSession 對象都由一個 NSURLSessionConfiguration對象來進行初始化，后者指定了剛才提到的那些策略以及一些用來增強移動設備上性能的新選項。
NSURLSession中另一大塊就是 session task。它負責處理數據的加載以及文件和數據在客戶端與服務端之間的上傳和下載。NSURLSessionTask與 NSURLConnection
最大的相似之處在于它也負責數據的加載，最大的不同之處在于所有的 task 共享其創造者 NSURLSession
這一公共委托者（common delegate）。
我們先來深入探討 task，過后再來討論 NSURLSessionConfiguration。

NSURLSessionTask

NSURLsessionTask是一個抽象類，其下有 3 個實體子類可以直接使用：NSURLSessionDataTask、NSURLSessionUploadTask、NSURLSessionDownloadTask。這 3 個子類封裝了現代程序三個最基本的網絡任務：獲取數據，比如 JSON 或者 XML，上傳文件和下載文件。

NSURLSessionTask class diagram

NSURLSessionTask 的工廠方法

在 iOS 5 中，NSURLConnection添加了 sendAsynchronousRequest:queue:completionHandler:
這一方法，對于一次性使用的 request， 大大地簡化代碼，同時它也是 sendSynchronousRequest:returningResponse:error:
這個方法的異步替代品：

NSURL *URL = [NSURL URLWithString:@"http://example.com"];
 NSURLRequest *request = [NSURLRequest requestWithURL:URL]; 
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] 
completionHandler:^(NSURLResponse *response, NSData *data, NSError *error) { // ... }];

NSURLSession
在 task 的構造方法上延續了這一模式。不同的是，這里不會立即運行 task，而是將該 task 對象先返回，允許我們進一步的配置，然后可以使用 resume方法來讓它開始運行。
Data task 可以通過 NSURL或 NSURLRequest創建（使用前者相當于是使用一個對于該 URL 進行標準 GET請求的 NSURLRequest
，這是一種快捷方法）：

NSURL *URL = [NSURL URLWithString:@"http://example.com"]; 
NSURLRequest *request = [NSURLRequest requestWithURL:URL]; 
NSURLSession *session = [NSURLSession sharedSession]; 
NSURLSessionDataTask *task = [session dataTaskWithRequest:request 
completionHandler: ^(NSData *data, NSURLResponse *response, NSError *error) { // ... }];
 [task resume];

Upload task 的創建需要使用一個 request，另外加上一個要上傳的 NSData
對象或者是一個本地文件的路徑對應的 NSURL：

NSURL *URL = [NSURL URLWithString:@"http://example.com/upload"];
 NSURLRequest *request = [NSURLRequest requestWithURL:URL]; 
NSData *data = ...; NSURLSession *session = [NSURLSession sharedSession]; 
NSURLSessionUploadTask *uploadTask = [session uploadTaskWithRequest:request fromData:data 
completionHandler: ^(NSData *data, NSURLResponse *response, NSError *error) { // ... }];
 [uploadTask resume];

Download task 也需要一個 request，不同之處在于 completionHandler
這個 block。Data task 和 upload task 會在任務完成時一次性返回，但是 Download task 是將數據一點點地寫入本地的臨時文件。所以在 completionHandler這個 block 里，我們需要把文件從一個臨時地址移動到一個永久的地址保存起來：

NSURL *URL = [NSURL URLWithString:@"http://example.com/file.zip"]; 
NSURLRequest *request = [NSURLRequest requestWithURL:URL]; 
NSURLSession *session = [NSURLSession sharedSession]; 
NSURLSessionDownloadTask *downloadTask = [session downloadTaskWithRequest:request 
completionHandler: ^(NSURL *location, NSURLResponse *response, NSError *error) { NSString *documentsPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
NSURL *documentsDirectoryURL = [NSURL fileURLWithPath:documentsPath];
 NSURL *newFileLocation = [documentsDirectoryURL URLByAppendingPathComponent:[[response URL] lastPathComponent]];
 [[NSFileManager defaultManager] copyItemAtURL:location toURL:newFileLocation error:nil]; 
}]; 
[downloadTask resume];

編者注 原文中這塊代碼以及上文的表述中存有一些問題，詳見這個 issue，本文已進行更正，如果您有不同意見，歡迎在 Github 上給我們反饋。

NSURLSession 與 NSURLConnection 的 delegate 方法

總體而言，NSURLSession的 delegate 方法是 NSURLConnection
的演化的十年中對于 ad-hoc 模式的一個顯著改善。您可以查看這個映射表來進行一個完整的概覽。
以下是一些具體的觀察：
NSURLSession既擁有 seesion 的 delegate 方法，又擁有 task 的 delegate 方法用來處理鑒權查詢。session 的 delegate 方法處理連接層的問題，諸如服務器信任，客戶端證書的評估，NTLM 和 Kerberos 協議這類問題，而 task 的 delegate 則處理以網絡請求為基礎的問題，如 Basic，Digest，以及代理身份驗證（Proxy authentication）等。
在 NSURLConnection中有兩個 delegate 方法可以表明一個網絡請求已經結束：NSURLConnectionDataDelegate中的 -connectionDidFinishLoading:和 NSURLConnectionDelegate
中的 -connection:didFailWithError:，而在 NSURLSession
中改為一個 delegate 方法：NSURLSessionTaskDelegate
的 -URLSession:task:didCompleteWithError:

NSURLSession中表示傳輸多少字節的參數類型現在改為 int64_t，以前在 NSURLConnection中相應的參數的類型是 long long。
由于增加了 completionHandler:這個 block 作為參數，NSURLSession實際上給 Foundation 框架引入了一種全新的模式。這種模式允許 delegate 方法可以安全地在主線程與運行，而不會阻塞主線程；Delgate 只需要簡單地調用 dispatch_async就可以切換到后臺進行相關的操作，然后在操作完成時調用 completionHandler 即可。同時，它還可以有效地擁有多個返回值，而不需要我們使用笨拙的參數指針。以 NSURLSessionTaskDelegate 的 -URLSession:task:didReceiveChallenge:completionHandler:方法來舉例，completionHandler接受兩個參數：NSURLSessionAuthChallengeDisposition和 NSURLCredential
，前者為應對鑒權查詢的策略，后者為需要使用的證書（僅當前者——應對鑒權查詢的策略為使用證書，即 NSURLSessionAuthChallengeUseCredential時有效，否則該參數為 NULL）
想要查看更多關于 session task 的信息，可以查看 WWDC Session 705: "What’s New in Foundation Networking"

NSURLSessionConfiguration

NSURLSessionConfiguration對象用于對 NSURLSession對象進行初始化。NSURLSessionConfiguration對以前 NSMutableURLRequest
所提供的網絡請求層的設置選項進行了擴充，提供給我們相當大的靈活性和控制權。從指定可用網絡，到 cookie，安全性，緩存策略，再到使用自定義協議，啟動事件的設置，以及用于移動設備優化的幾個新屬性，你會發現使用 NSURLSessionConfiguration可以找到幾乎任何你想要進行配置的選項。
NSURLSession在初始化時會把配置它的 NSURLSessionConfiguration
對象進行一次 copy，并保存到自己的 configuration屬性中，而且這個屬性是只讀的。因此之后再修改最初配置 session 的那個 configuration 對象對于 session 是沒有影響的。也就是說，configuration 只在初始化時被讀取一次，之后都是不會變化的。
NSURLSessionConfiguration 的工廠方法NSURLSessionConfiguration
有三個類工廠方法，這很好地說明了 NSURLSession
設計時所考慮的不同的使用場景。
+defaultSessionConfiguration
返回一個標準的 configuration，這個配置實際上與 NSURLConnection的網絡堆棧（networking stack）是一樣的，具有相同的共享 NSHTTPCookieStorage，共享 NSURLCache
和共享 NSURLCredentialStorage。
+ephemeralSessionConfiguration
返回一個預設配置，這個配置中不會對緩存，Cookie 和證書進行持久性的存儲。這對于實現像秘密瀏覽這種功能來說是很理想的。

+backgroundSessionConfiguration:(NSString *)identifier

的獨特之處在于，它會創建一個后臺 session。后臺 session 不同于常規的，普通的 session，它甚至可以在應用程序掛起，退出或者崩潰的情況下運行上傳和下載任務。初始化時指定的標識符，被用于向任何可能在進程外恢復后臺傳輸的守護進程（daemon）提供上下文。
想要查看更多關于后臺 session 的信息，可以查看 WWDC Session 204: "What's New with Multitasking"

配置屬性

NSURLSessionConfiguration擁有 20 個配置屬性。熟練掌握這些配置屬性的用處，可以讓應用程序充分地利用其網絡環境。

基本配置

HTTPAdditionalHeaders
指定了一組默認的可以設置出站請求（outbound request）的數據頭。這對于跨 session 共享信息，如內容類型，語言，用戶代理和身份認證，是很有用的。

NSString *userPasswordString = [NSString stringWithFormat:@"%@:%@", user, password];
NSData * userPasswordData = [userPasswordString dataUsingEncoding:NSUTF8StringEncoding];
NSString *base64EncodedCredential = [userPasswordData base64EncodedStringWithOptions:0];
NSString *authString = [NSString stringWithFormat:@"Basic %@", base64EncodedCredential];
NSString *userAgentString = @"AppName/com.example.app (iPhone 5s; iOS 7.0.2; Scale/2.0)";
configuration.HTTPAdditionalHeaders = @{@"Accept": @"application/json", @"Accept-Language": @"en", @"Authorization": authString, @"User-Agent": userAgentString};

networkServiceType
對標準的網絡流量，網絡電話，語音，視頻，以及由一個后臺進程使用的流量進行了區分。大多數應用程序都不需要設置這個。
allowsCellularAccess和 discretionary
被用于節省通過蜂窩網絡連接的帶寬。對于后臺傳輸的情況，推薦大家使用 discretionary這個屬性，而不是 allowsCellularAccess，因為前者會把 WiFi 和電源的可用性考慮在內。
timeoutIntervalForRequest和 timeoutIntervalForResource
分別指定了對于請求和資源的超時間隔。許多開發人員試圖使用 timeoutInterval
去限制發送請求的總時間，但其實它真正的含義是：分組（packet）之間的時間。實際上我們應該使用 timeoutIntervalForResource
來規定整體超時的總時間，但應該只將其用于后臺傳輸，而不是用戶實際上可能想要去等待的任何東西。
HTTPMaximumConnectionsPerHost
是 Foundation 框架中 URL 加載系統的一個新的配置選項。它曾經被 NSURLConnection用于管理私有的連接池。現在有了 NSURLSession，開發者可以在需要時限制連接到特定主機的數量。
HTTPShouldUsePipelining
這個屬性在 NSMutableURLRequest
下也有，它可以被用于開啟 HTTP 管線化（HTTP pipelining），這可以顯著降低請求的加載時間，但是由于沒有被服務器廣泛支持，默認是禁用的。
sessionSendsLaunchEvents
是另一個新的屬性，該屬性指定該 session 是否應該從后臺啟動。
connectionProxyDictionary
指定了 session 連接中的代理服務器。同樣地，大多數面向消費者的應用程序都不需要代理，所以基本上不需要配置這個屬性。
關于連接代理的更多信息可以在 CFProxySupportReference 找到。

Cookie 策略

HTTPCookieStorage存儲了 session 所使用的 cookie。
默認情況下會使用 NSHTTPCookieShorage
的 +sharedHTTPCookieStorage這個單例對象，這與 NSURLConnection 是相同的。
HTTPCookieAcceptPolicy
決定了什么情況下 session 應該接受從服務器發出的 cookie。
HTTPShouldSetCookies
指定了請求是否應該使用 session 存儲的 cookie，即 HTTPCookieSorage 屬性的值。

安全策略

URLCredentialStorage
存儲了 session 所使用的證書。默認情況下會使用 NSURLCredentialStorage 的 +sharedCredentialStorage
這個單例對象，這與 NSURLConnection是相同的。
TLSMaximumSupportedProtocol和 TLSMinimumSupportedProtocol
確定 session 是否支持 SSL 協議。

緩存策略

URLCache
是 session 使用的緩存。默認情況下會使用 NSURLCache的 +sharedURLCache這個單例對象，這與 NSURLConnection
是相同的。
requestCachePolicy
指定了一個請求的緩存響應應該在什么時候返回。這相當于 NSURLRequest 的 -cachePolicy 方法。

自定義協議

protocolClasses
用來配置特定某個 session 所使用的自定義協議（該協議是 NSURLProtocol的子類）的數組。

結論

iOS 7 和 Mac OS X 10.9 Mavericks 中 URL 加載系統的變化，是對 NSURLConnection 進行深思熟慮后的一個自然而然的進化。總體而言，蘋果的 Foundation 框架團隊干了一件令人欽佩的的工作，他們研究并預測了移動開發者現有的和新興的用例，創造了能夠滿足日常任務而且非常好用的 API 。
盡管在這個體系結構中，某些決定對于可組合性和可擴展性而言是一種倒退，但是 NSURLSession 仍然是實現更高級別網絡功能的一個強大的基礎框架。
原文 From NSURLConnection to NSURLSession