URL加载系统－－－－iOS工程师必须熟练掌握
当应用程序面临处理问题的抉择时，通常会选择*别的框架来解决这个问题。所以如果给定的任务是通过http://， https:// 或 ftp://进行通讯，那么与 NSURLConnection 相关的方法就是最好的选择了。苹果关于网络的类涵盖甚广，包括从URL加载、还存管理到认证与存储cookie等多个领域，完全可以满足现代Objective-C应用开发的需要：
| URL加载 | |
| NSURLConnection | |
| NSURLRequest | NSMutableURLRequest |
| NSURLResponse | NSHTTPURLResponse |
| 缓存管理 | |
| NSURLCache | |
| NSCacheURLRequest | |
| NSCachedURLResponse | |
| 认证 & 证书 | |
| NSURLCredential | |
| NSURLCredentialStorage | |
| NSURLAuthenticationChallenge | |
| NSURLProtectionSpace | |
| Cookie存储 | |
| NSHTTPCookie | |
| NSHTTPCookieStorage | |
| 协议支持 | |
| NSURLProtocol | |
虽然URL加载系统包含的内容众多，但代码的设计上却非常良好，没有把复杂的操作暴露出来，开发者只需要在用到的时候进行设置。任何通过 NSURLConnection 进行的请求都会被系统的其他部分所拦截，这也使得当可用时显式地从硬盘加载缓存成为了可能。
说到这里，我们就说说：NSURLProtocol。
NSURLProtocol NSURLProtocol或许是URL加载系统中最功能强大但同时也是最晦涩的部分了。它是一个抽象类，你可以通过子类化来定义新的或已经存在的URL加载行为。
听了我说了这些乱七八糟的如果你还没有抓狂，这里有一些关于_希望加载请求时不用改变其他部分代码_的例子，供你参考：
拦截图片加载请求，转为从本地文件加载
为了测试对HTTP返回内容进行mock和stub
对发出请求的header进行格式化
对发出的媒体请求进行签名
创建本地代理服务，用于数据变化时对URL请求的更改
故意制造畸形或非法返回数据来测试程序的鲁棒性
过滤请求和返回中的敏感信息
在既有协议基础上完成对 NSURLConnection的实现且与原逻辑不产生矛盾
再次强调 NSURLProtocol 核心思想最重要的一点：用了它，你不必改动应用在网络调用上的其他部分，就可以改变URL加载行为的全部细节。
或者这么说吧： NSURLProtocol 就是一个苹果允许的中间人攻击。
- 子类化NSURLProtocol
之前提到过 NSURLProtocol是一个抽象类，所以不能够直接使用必须被子类化之后才能使用。
- 让子类识别并控制请求
子类化 NSURLProtocol 的第一个任务就是告诉它要控制什么类型的网络请求。比如说如果你想要当本地有资源的时候请求直接使用本地资源文件，那么相关的请求应该对应已有资源的文件名。
这部分逻辑定义在 +canInitWithRequest: 中，如果返回 YES，该请求就会被其控制。返回 NO 则直接跳入下一Protocol。
- 提供请求规范
如果你想要用特定的某个方式来修改一个请求，应该使用 +canonicalRequestForRequest: 方法。每一个subclass都应该依据某一个规范，也就是说，一个protocol应该保证只有唯一的规范格式（虽然很多不同的请求可能是同一种规范格式）。
- 获取和设置请求的属性
NSURLProtocol提供方法允许你来添加、获取、删除一个request对象的任意metadata，而且不需要私有扩展或者方法欺骗(swizzle)：
+propertyForKey:inRequest:+setProperty:forKey:inRequest:+removePropertyForKey:inRequest:
在操作protocol时对尚未赋予特定信息的 NSURLRequest 进行操作时，上述方法都是特别重要的。这些对于和其他方法之间的状态传递也非常有用。
- 加载请求
你的子类中最重要的方法就是 -startLoading 和 -stopLoading。不同的自定义子类在调用这两个方法是会传入不同的内容，但共同点都是要围绕protocol客户端进行操作。
每个 NSURLProtocol 的子类实例都有一个 client 属性，该属性对URL加载系统进行相关操作。它不是NSURLConnection，但看起来和一个实现了NSURLConnectionDelegate 协议的对象非常相似。
<NSURLProtocolClient>
-URLProtocol:cachedResponseIsValid:-URLProtocol:didCancelAuthenticationChallenge:-URLProtocol:didFailWithError:-URLProtocol:didLoadData:-URLProtocol:didReceiveAuthenticationChallenge:-URLProtocol:didReceiveResponse:cacheStoragePolicy:-URLProtocol:wasRedirectedToRequest:redirectResponse:-URLProtocolDidFinishLoading:
在对 -startLoading 和 -stopLoading 的实现中，你需要在恰当的时候让 client 调用每一个delegate方法。简单来说就是连续调用那些方法，不过这是至关重要的。
向URL加载系统注册子类
- 最后，为了使用
NSURLProtocol子类，需要向URL加载系统进行注册。
当请求被加载时，系统会向每一个注册过的protocol询问：“Hey你能控制这个请求吗？”第一个通过 +canInitWithRequest: 回答为 YES 的protocol就会控制该请求。URL protocol会被以注册顺序的反序访问，所以当在 -application:didFinishLoadingWithOptions: 方法中调用 [NSURLProtocol registerClass:[MyURLProtocol class]]; 时，你自己写的protocol比其他内建的protocol拥有更高的优先级。
就像控制请求的URL加载系统一样， NSURLProtocol 也一样的无比强大，可以通过各种灵活的方式使用。它作为一个相对晦涩难解的类，我们挖掘出了它的潜力来让我们的代码更清爽健壮。
NSURLCache NSURLCache 为您的应用的 URL 请求提供了内存中以及磁盘上的综合缓存机制。 作为基础类库 URL 加载系统 的一部分，任何通过 NSURLConnection加载的请求都将被 NSURLCache 处理。网络缓存减少了需要向服务器发送请求的次数，同时也提升了离线或在低速网络中使用应用的体验。
当一个请求完成下载来自服务器的回应，一个缓存的回应将在本地保存。下一次同一个请求再发起时，本地保存的回应就会马上返回，不需要连接服务器。NSURLCache会 自动 且 透明 地返回回应。
- 初始化并设置一个共享的 URL 缓存
为了好好利用 NSURLCache，你需要初始化并设置一个共享的 URL 缓存。在 iOS 中这项工作需要在 -application:didFinishLaunchingWithOptions: 完成，而 Mac OS X 中是在 –applicationDidFinishLaunching:：
例如：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024
diskCapacity:20 * 1024 * 1024
diskPath:nil];
[NSURLCache setSharedURLCache:URLCache];
}
缓存策略由请求（客户端）和回应（服务端）分别指定。理解这些策略以及它们如何相互影响，是为您的应用程序找到最佳行为的关键。
NSURLRequestCachePolicy NSURLRequest 有个 cachePolicy属性，它根据以下常量指定了请求的缓存行为：
NSURLRequestUseProtocolCachePolicy：对特定的 URL 请求使用网络协议中实现的缓存逻辑。这是默认的策略。NSURLRequestReloadIgnoringLocalCacheData：数据需要从原始地址加载。不使用现有缓存。NSURLRequestReloadIgnoringLocalAndRemoteCacheData：不仅忽略本地缓存，同时也忽略代理服务器或其他中间介质目前已有的、协议允许的缓存。NSURLRequestReturnCacheDataElseLoad：无论缓存是否过期，先使用本地缓存数据。如果缓存中没有请求所对应的数据，那么从原始地址加载数据。NSURLRequestReturnCacheDataDontLoad：无论缓存是否过期，先使用本地缓存数据。如果缓存中没有请求所对应的数据，那么放弃从原始地址加载数据，请求视为失败（即：“离线”模式）。NSURLRequestReloadRevalidatingCacheData：从原始地址确认缓存数据的合法性后，缓存数据就可以使用，否则从原始地址加载。
你并不会惊奇于这些值不被透彻理解且经常搞混淆。
NSURLRequestReloadIgnoringLocalAndRemoteCacheData 和NSURLRequestReloadRevalidatingCacheData
根本没有实现（Link to Radar）更加加深了混乱程度！
关于NSURLRequestCachePolicy，以下才是你实际 需要了解的东西：
UseProtocolCachePolicy 默认行为
ReloadIgnoringLocalCacheData 不使用缓存
ReloadIgnoringLocalAndRemoteCacheData 我是认真地，不使用任何缓存
ReturnCacheDataElseLoad 使用缓存（不管它是否过期），如果缓存中没有，那从网络加载吧
ReturnCacheDataDontLoad 离线模式：使用缓存（不管它是否过期），但是不从网络加载
ReloadRevalidatingCacheData 在使用前去服务器验证
- HTTP 缓存语义
因为 NSURLConnection 被设计成支持多种协议——包括 FTP、HTTP、HTTPS——所以
URL 加载系统用一种协议无关的方式指定缓存。为了本文的目的，缓存用术语 HTTP 语义来解释。
- HTTP 请求和回应用
headers 来交换元数据，如字符编码、MIME 类型和缓存指令等。
Request Cache Headers
在默认情况下，NSURLRequest会用当前时间决定是否返回缓存的数据。为了更精确地控制，允许使用以下请求头：
If-Modified-Since - 这个请求头与 Last-Modified回应头相对应。把这个值设为同一终端最后一次请求时返回的 Last-Modified 字段的值。
If-None-Match - 这个请求头与与Etag 回应头相对应。使用同一终端最后一次请求的Etag 值。
Response Cache Headers
NSHTTPURLResponse 包含多个 HTTP 头，当然也包括以下指令来说明回应应当如何缓存：
Cache-Control- 这个头必须由服务器端指定以开启客户端的HTTP 缓存功能。这个头的值可能包含max-age（缓存多久），是公共public还是私有private，或者不缓存no-cache等信息。详情请参阅Cache-Controlsection of RFC 2616。
除了 Cache-Control 以外，服务器也可能发送一些附加的头用于根据需要有条件地请求（如上一节所提到的）：
Last-Modified-
这个头的值表明所请求的资源上次修改的时间。例如，一个客户端请求最近照片的时间线，/photos/timeline，Last-Modified的值可以是最近一张照片的拍摄时间。Etag- 这是 “entity tag”的缩写，它是一个表示所请求资源的内容的标识符。在实践中，Etag
的值可以是类似于资源的MD5之类的东西。这对于那些动态生成的、可能没有明显的Last-Modified
值的资源非常有用。
NSURLConnectionDelegate
一旦收到了服务器的回应，NSURLConnection 的代理就有机会在 -connection:willCacheResponse: 中指定缓存数据。
NSCachedURLResponse 是个包含NSURLResponse 以及它对应的缓存中的 NSData 的类。
在 -connection:willCacheResponse:中，cachedResponse 对象会根据 URL连接返回的结果自动创建。因为 NSCachedURLResponse没有可变部分，为了改变 cachedResponse 中的值必须构造一个新的对象，把改变过的值传入 –initWithResponse:data:userInfo:storagePolicy:
例如：
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
NSMutableDictionary *mutableUserInfo = [[cachedResponse userInfo] mutableCopy];
NSMutableData *mutableData = [[cachedResponse data] mutableCopy];
NSURLCacheStoragePolicy storagePolicy = NSURLCacheStorageAllowedInMemoryOnly;
// ...
return [[NSCachedURLResponse alloc] initWithResponse:[cachedResponse response]
data:mutableData
userInfo:mutableUserInfo
storagePolicy:storagePolicy];
}
如果 -connection:willCacheResponse: 返回 nil，回应将不会缓存。
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
return nil;
}
如果不实现此方法，NSURLConnection 就简单地使用本来要传入 -connection:willCacheResponse:的那个缓存对象，所以除非你需要改变一些值或者阻止缓存，否则这个代理方法不必实现。
- 注意事项
正如它那个毫无关系但是名字相近的小伙伴 NSCache 一样，NSURLCache 也是有一些特别的。在 iOS 5，磁盘缓存开始支持，但仅支持 HTTP，非 HTTPS（iOS 6中增加了此支持）。Peter Steinberger关于这个主题写了一篇优秀的文章(http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-as-of-ios5/)，在深入研究内部细节后实现他自己的 NSURLCache 子类(https://github.com/steipete/SDURLCache)。Daniel Pasco 在 Black Pixel 上的另一篇文章
http://blackpixel.com/blog/2012/05/caching-and-nsurlconnection.html 描述了一些与服务器通信时不设置缓存头的意外的默认行为。
NSURLCache 提醒着我们熟悉我们正在操作的系统是多么地重要。开发 iOS 或 Mac OS X 程序时，这些系统中的重中之重，非 URL Loading System莫属。
无数开发者尝试自己做一个简陋而脆弱的系统来实现网络缓存的功能，殊不知 NSURLCache 只要两行代码就能搞定且好上100倍。甚至更多开发者根本不知道网络缓存的好处，也从未尝试过，导致他们的应用向服务器作了无数不必要的网络请求。所以如果你想看到世界的变化，你想确保你有程序总以正确的方式开启，在 -application:didFinishLaunchingWithOptions:设置一个共享的 NSURLCache 吧。