這篇指南描述了在Foundation框架中和URL交互的類，以及使用標準的網絡協議和服務器通信。這些類一起被叫做URL loading system
URL loading system是類和協議的集合，允許你的App可以通過URL訪問內容。這個技術的核心就是NSURL類，這讓你的App操作他們指向的URLs和資源。
為了協助這個類，Foundation框架提供了一組豐富的類集合。這讓你能夠加載一個URL的內容，上傳數據到服務端，管理cookie的存儲，控制返回值的緩存，處理證書的存儲，用App指定的方式認證，寫一個自定義的協議擴展。
URL loading system通過下面的協議提供訪問資源的支持：
- 文件傳輸協議（ftp://）
- 超文本傳輸協議（http://）
- 超文本傳輸協議和加密（https://）
- 本地文件資源定位協議（file:///）
- 數據資源定位（data://）
通過使用用戶的設置，可以讓它支持代理服務和SOCKS通道
Important：在App平臺中，網絡安全被叫做App Transport Security（ATS），這個適用于App和App extension，并且是默認可用的。它通過App網絡鏈接使用的標準協議和難以被人破解密碼防護來確保用戶隱私的安全、數據的完整。更多的信息，請見NSAppTransportSecurity
Note：除了URL loading system，OS X和iOS提供了API可以在其他應用中打開自己的App。例如 Safari。這些API在這篇文章中沒有被提到。
關于在OS X中加載服務的信息，可以閱讀Launch Services Programming Guide
關于OS X中的NSWorkSpace類中 openURL:方法的相關信息可以閱讀NSWorkspace Class Reference
關于iOS中的UIApplication類中 openURL:方法的相關信息可以閱讀UIApplication Class Reference
總綱
URL loading system中包括 大量使用重要的helper類來加載RUL的 類，helper類和加載URL的類一起使用來改變它們的行為。主要的hepler類被分為5類：協議支持（protocol support），證書認證（authentication and credentials），cookie存儲（cookie storage），配置管理（configuration mangement）和 緩存管理（cache mangement）。
<img src="http://upload-images.jianshu.io/upload_images/1086250-d41a7174c55ea6e2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="nsobject_hierarchy" width=10px height=10px />
URL Loading
在URL loading system中被使用最多的類（功能）就是允許你的app從原文件地址取回URL中的內容。你可以用NSURLSession類實現。你指定使用的方法很大程度上取決于你是希望接收到的數據是放到內存中還是下載到本地（磁盤中）。
抓取內容作為數據（在內存中）（Downloading Content as a File） (In Memory)
在較高的抽象層級上有兩個方法來獲取URL數據
- 對于一個簡單的請求，要使用
NSURLSessionAPI來從URL對象中直接獲取數據，無論數據是一個NSData對象還是一個在磁盤上的文件。 - 對于更復雜的請求，請求上傳數據。要提供一個
NSURLRequest對象(或者是其可變的子類NSMutableURLRequest)給NSURLSession
無論你選擇哪種方法，你的app可以通過下面兩種方式獲得數據
- 提供一個完成后的回調閉包。URL的加載類將會在它完成從服務端取回數據的操作和調用這個閉包。
- 提供一個自定義的delegate。URL的加載類將會在當它從服務端收到數據的時候按需求的調用你的delegate。如果有需要，你的app可以對不斷變化的數據進行響應。
除了數據本身，URL還可以為閉包或者delegate提供一個相應的對象，里面包裝了和請求相關的原數據。例如 MIME類、請求內容長度。
相關章節:Using NSURLSession
什么是MIME:在維基百科是這樣描述的
Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email to support:
- Text in character sets other than ASCII
- Non-text attachments: audio, video, images, application programs etc.
- Message bodies with multiple parts
- Header information in non-ASCII character sets
Although MIME was designed mainly for SMTP, the content types defined by MIME standards are also of importance in communication protocols outside of email, such as HTTP for the World Wide Web
大概意思：MIME全稱是Multipurpose Internet Mail Extensions（多目標的因特網郵件協議補充），它是因特網的一個標準，為了達到如下目標：
- 字符集的文本顯示，而不總是ASCII
- 非文本的附件傳輸：音頻、視頻、圖片、程序等
- 多部分組成的消息體
- 非ASCII集的頭信息
雖然MIME是被設計出來發送郵件的，現在被MIME標準定義的內容類型在Email之外的協議交流上也是很重要的，例如，萬維網的HTTP協議。
下載內容到文件（Downloading Content as a File）
在一個較高的抽象層級上，我們有兩種方法來下載URL里面的內容到文件中
- 對于一個簡單的請求，要使用
NSURLSessionAPI來從URL對象中直接獲取數據，無論數據是一個NSData對象還是一個在磁盤上的文件。 - 對于更復雜的請求，請求上傳數據。要提供一個
NSURLRequest對象(或者是其可變的子類NSMutableURLRequest)給NSURLSession
Note：通過
NSURLSession實例開始的一個下載，下載結果是不會自動被緩存的。如果你想要緩存下載結果，你的app必須自己用NSURLSession寫數據到磁盤中。
相關章節：Using NSURLSession
幫助類（Helper Classes）
URL加載類使用兩個helper類來提供另外的元數據，一個是為了請求本身(NSURLRequest)，另一個是為了服務端的響應數據(NSURLResponse)。
URL請求（URL Requests）
一個NSURLRequest類通過一種獨立出協議的方式，包裝了一個URL和一些指定協議的屬性。
當app客戶端實例出一個鏈接或者使用
NSMutableURLrequest來下載的時候，request會發生一個深層次的拷貝（deep copy）。在下載被初始化之后，發生在request上的變化不會對下載產生影響。
一些協議提供了指定協議的屬性。例如，HTTP協議添加方法到NSURLRequest，方法返回了HTTP請求的主體（body），請求頭（heasers）和轉換方法（transfer method）。它同樣添加一些方法到NSMutableURLRequest來設置那些值。URL請求的實現細節的描述將會貫穿本博客
添加方法理解為：一些HTTP協議需要的屬性或者方法需要在request中有對應的體現
響應元數據（Response Metadata）
對于一個請求從服務端的響應可以看作兩個部分：描述內容的元數據和內容數據本身。在大多是協議中元數據是最普遍的，它被包裝在NSURLReponse類中，并由MIME類、預期響應的內容長度、文本編碼和提供響應的URL組成。協議指定了NSURLResponse的子類，它能夠提供另外的元數據。例如，NSHTTPURLResponse存儲了頭（headers）和狀態碼（status code），這些都被網絡服務返回。
Important：只有為了響應的元數據被存貯在NSURLResponse對象中。各種URL加載類提供它們自己的響應數據為他們的app，無論是通過delegate還是閉包。
一個NSCachedURLResponse實例包裝了NSURLResponse對象、URL內容數據、還有一些被你app提供的其他信息。詳見 緩存管理細節
URL請求的實現細節的描述將會貫穿本博客
重定向和其他的請求變化（Redirection and Other Request Changes）
一些協議例如：HTTP，為服務端提供了一種方法來告訴你的app，內容已經被移動到一個不同的URL中。URL的加載類可以通知他們的代理當這種事情發生的時候。如果你的app提供了一個較友好的delegate，你的app可以決定是否要重定向，從重定向的地址中返回數據或者直接返回一個錯誤。
證書認證（Authentication and Credentials）
一些服務會約束訪問核心的內容，需用用戶通過提供一些證明的方式來認證。- 一個客戶端證書，用戶名和密碼，還有一些其他的。為了能夠獲得訪問權。在網絡服務的場景下，約束的內容被分到一個地方。這個地方需要一組認證的憑證才能訪問。認證（特別是證書的）同樣在其他的地方被用來檢測是否信任。為了評估你的app是否信任server的服務。
URL loading system提供了一些類。你的app可以指定認證的持續時間，是只針對于一個請求，還是只在app啟動的時間，或者永久的保存在用戶的鑰匙串中。
認證憑證以一種持久存儲的方式被保存在用戶鑰匙串中，來讓所有的app共享。
NSURLCredential類包裝了由認證信息（例如：用戶名和密碼）組成的憑證，并持久化數據。NSURLProtectionSpace類代表了一個區域，一個需要特殊認證的區域。一個被保護的區域，可以是只對一種URL的訪問，網絡服務中的某些地方，被指定的訪問策略等。
NSURLCredentialStorage對象為session管理憑證的存儲，并提供NSURLCredential對象到相對應的NSURLProtectionSpace對象的映射。一個憑證只有在認證成功的時候才被存儲。
NSURLAuthenticationChallenge類包裝了需要實現NSURLProtocol的信息，為了認證一個請求：一個被準備好的憑證，保護區域的調用，錯誤或者響應。協議用來檢測被需要的憑證，大量的認證嘗試被執行。一個NSURLAuthenticationChallenge實例同樣指定了對象來初始化認證。初始化對象，像渲染一樣被引用，并且必須符合NSURLAuthenticaionChallengeSender協議
NSURLAuthenticaionChallenge實例通過NSURLProtocol的字類被使用，來通知URL loading system認證是必須的。他們同樣提供了NSURLSession的delgate方法，來減少自定義認證處理的難度。
緩存管理（Cache Management）
URL loading system提供了磁盤上和內存中的存儲，允許app減少對網絡的依賴。并提供了快速的響應對于之前緩存的數據。緩存在每個app的底層。緩存需要NSURLSession根據被 NSURLRequest和NSURLSessionConfiguration對象指定的緩存策略來查找。
NSURLCache類提供了方法來配置緩存的大小和在磁盤上緩存的位置。它同樣提供了方法來管理 NSCachedURLResponse對象的集合，它包含了緩存的response。
一個NSCacheURLResponse對象包裝了 NSURLResponse對象和URL內容數據。NSCachedURLResponse同樣提供了一個用戶信息的字典。這樣你的app可以使用它來緩存任何自定義的數據。不是所有的協議實現都支持response緩存。現在只有http和https支持。
一個NSURLSession對象能夠控制是否response需要被緩存。是否response應該被緩存到內存中通過實現URLSession:dataTask:willCacheResponse:completionHandler: delegate方法。
Cookes存儲（Cookie Storage）
由于http協議是無狀態的，客戶端經常使用cookie來提供一個持久的數據存儲，通過URL請求。
URL loading system提供了創建和管理cookie的接口，來做為http請求的一部分發送cookie。為了在網絡服務響應的時候收到cookie
OS X和iOS提供了NSHTTPCookieStorage類，它提供了管理 NSHTTPCookie對象集合的接口。在OS X中cookie的存儲在所有app中都被共享；在iOS只能在一個app中使用。
相關章節：Cookie Storage
協議支持（Protocol Support）
URL loading system支持http、https、file、ftp和data協議。但是URL loading system同樣允許你的app注冊你自己的類來支持另外的app層的網絡協議。你可以同樣添加協議指定的屬性到URL request中和URL response中。
校驗：LinkRober
本文譯自About the URL Loading System
有翻譯不準確的的地方或有待改進的地方歡迎指正??????
