URLCache 设置不当影起的 App 故障
关于数据请求是几乎每个 App 会经常遇到的事，关于数据的 Request 与 Response 及 Cache 其实我们需要了解更多细节才能运用自如，排查问题更快。
很久之前，我时常遇到一部分用户能打开页面，一部用户却不能的情况。在排除网络，地域，机型，服务器状态完全正常的情况，一直无法解释其原因。客户也说不上来有什么区别，操作路径也是一样，只是过一段时间就自然恢复了，或重装等等解决。
直到最近的一次故障让我彻底将此类问题的原头分析了一遍，才有所顿悟。
故障
现象
服务�端因某种原因使所有 API 请求返回错误的，类似源代码的片段内容。几个小时后服务器恢复。不过部分用户使用时看到的仍然是出错页面，而其他用户又是正常。
影响范围
后来仔细分析发现，在服务器宕机的那段时间内，用户如果打开过 App ，则一直会看到出错页面。即使完全退出 App 再进入错误仍旧发生。如果这段时间内没有打开过 App 的用户，在之后打开的话，就会看到正常的页面。所以影响面是所有服务器出错这段时间内，打开过 App 的用户。
故障分析
表象分析
最初怀疑是不是服务器未完全恢复，这部分用户仍受到影响。或服务器给出了错误的缓存页面。后来通过查询网络请求日志，发现服务器未收到任何请求，包括网关服务器。 之后尝试让有此故障现象的设备重装 App ，结果发现一切又恢复正常。初步判断有可能是客户端缓存了页面，并将错误返回导致。但是这种错误页面或错误理伦上是不该有的，所以从源头开始排查。
数据请求 Request
数据请求，App 底层用的系统原生 URLRequest + URLSession 做的网络请求处理，所以排除第三库的问题。在 URLRequest 实例话的过程中，也没有设置特定的 cachePolicy ，所以也是默认的缓存策略。那关于系统的缓存策略有哪些，默认的缓存策略又是什么样的呢？
缓存策略 Cache
通过查询 API 我们发现有以下几种:useProtocolCachePolicy协议缓存（后面会详细介绍）。这是默认的
reloadIgnoringLocalCacheData 忽略本地缓存，也就是说不实用缓存，直接从原始资源加载。
reloadIgnoringLocalAndRemoteCacheData // Unimplemented在写这篇文章时 API 定义是"未实现"，所以这个忽略
returnCacheDataElseLoad 无论缓存是否过期，都使用缓存，如果缓存不存在则请求原始资源地址
returnCacheDataDontLoad 只用缓存，不请求网络资源。可用于类似"离线状态"
reloadRevalidatingCacheData 从原始地址确认缓存数据的合法性后，缓存数据就可以使用，否则从原始资源请求从本例来看，我们使用了默认的协议缓存策略。下面来看看这个策略是如何工作的。
协议缓存NSURLRequestUseProtocolCachePolicy
我们引用了官方给出的一张流程图来详细解释这个过程
从上至下我们可以看一下整个过程
1. 如果缓存内容不存在，不用说，直接发起原始请求了
2. 如果缓存内容存在，确定是否每次从原始资源地址检查。这依赖于 Response Header 里cach-control指定的内容
常见的值有 private、public、no-store、no-cache、must-revalidate、max-age等。
no-cache: 告诉浏览器、缓存服务器，不管本地副本是否过期，使用资源副本前，一定要到源服务器进行副本有效性校验。
must-revalidate：告诉浏览器、缓存服务器，本地副本过期前，可以使用本地副本；本地副本一旦过期，必须去源服务器进行有效性校验。
本例中 Response Header 没有指定 must-revalidate，所以条件是否。
[Response Header]
3. 如果结果为是，则发起 HEAD request 请求，查看内容是否有变更，"是"则请求网络数据，如果否就用缓存
4. 如果上面的结果是否，则查看 Response 是否失效 (stale?)
这里的失效算法算是黑盒了，不过还好发现了这篇文章，描述了如何计算出这个失效期限。
// 首先是计算 freshness_lifetime
freshness_lifetime = (date_value - last_modified) * 10% =>
// 例如:
([Sat, 09 Apr 2016 10:26:51 GMT] - [Sun, 17 Jan 2016 14:15:33 GMT]) * 10% =>
[82 days, 19 hours, 11 minutes and 18 seconds] * 10% => 7,153,878 * 10% = 715388 seconds = 8 days 6 hours 43 minutes 8 seconds
// 然后判断 response 是否失效是根据 freshness lifetime 是否大于 current age
response_isfresh = (freshness_lifetime > current_age)
// 这里的 current age 是根据当前时间 now 减去 Response Header 里的 date_value 来的
current_age = now - date_value
5. 如果计算的结果是失效的 stale 是 true ，则去发送 issue request 请求。如果是否返回缓存数据
缓存文件 Cache File默认的缓存文件存在于 ~/(App Sandbox)/Library/Caches/(bundle id)... 目录下，我们可以看到有以下几个文件 :
Cache.db 就是缓存文件的sqlite数据库文件 打开后你会发现以下几张表
cfurl_cache_blob_data
cfurl_cache_response 表里就存有了请求的资源 key , 如 https://.... 。还有时间戳等
cfurl_cache_receiver_data 里存有了缓存的 Response
cfurl_cache_schema_version
在本例里你会发现缓存的错误数据都在那。
故障发生的原因通过我们现有的错误 Response header 头里，我们会发现1. 我们使用默认的缓存协议，所以它根据上面的 header 来判断是否使用缓存数据
2. 通过上面 stale 公式的计算，也正好还在有效期内
3. 通过打开缓存数据库文件我们也发现了这些错误的数据结果 所以它根本没有向服务器请求任何数据，导致了这些用户一直打开的是错误页面。
那为什么它会缓存错误结果，而不是将错误数据丢弃呢。从上面我们也可以发现 status code 是 200，也就是说它当成了正常返回数据将其缓存了。
解决
1. 避免缓存无效的 Response
首先服务端对于错误的返回结果不能返回 200 status code
客户端要做强校验，对于返回的不规范的格式或非业务所需，直接 removeCachedResponse，
3. 设置强制清理缓存机制
可以由客户手动清理缓存，或由服务端控制清理
4. 区别对待不同的 API 请求 cache 策略
客户端与服务端对不同的请求设定不同的缓存策略，比如配置下发那些是强制刷新不缓存的。不经常变的资源可以设置更长的缓存期限
参考资料
A Primer In Http–caching And Its–native Support–by–ios
NSURLCache Uses a Disk Cache as of iOS 5
工具
