关于数据请求是几乎每个 App 会经常遇到的事,关于数据的 Request 与 Response 及 Cache 其实我们需要了解更多细节才能运用自如,排查问题更快。

很久之前,我时常遇到一部分用户能打开页面,一部用户却不能的情况。在排除网络,地域,机型,服务器状态完全正常的情况,一直无法解释其原因。客户也说不上来有什么区别,操作路径也是一样,只是过一段时间就自然恢复了,或重装等等解决。

直到最近的一次故障让我彻底将此类问题的原头分析了一遍,才有所顿悟。

  1. 故障
    1. 现象
      服务端因某种原因使所有 API 请求返回错误的,类似源代码的片段内容。几个小时后服务器恢复。不过部分用户使用时看到的仍然是出错页面,而其他用户又是正常。
    2. 影响范围
      后来仔细分析发现,在服务器宕机的那段时间内,用户如果打开过 App ,则一直会看到出错页面。即使完全退出 App 再进入错误仍旧发生。如果这段时间内没有打开过 App 的用户,在之后打开的话,就会看到正常的页面。所以影响面是所有服务器出错这段时间内,打开过 App 的用户。
  2. 故障分析
    1. 表象分析
      最初怀疑是不是服务器未完全恢复,这部分用户仍受到影响。或服务器给出了错误的缓存页面。后来通过查询网络请求日志,发现服务器未收到任何请求,包括网关服务器。 之后尝试让有此故障现象的设备重装 App ,结果发现一切又恢复正常。初步判断有可能是客户端缓存了页面,并将错误返回导致。但是这种错误页面或错误理伦上是不该有的,所以从源头开始排查。
    2. 数据请求 Request
      数据请求,App 底层用的系统原生 URLRequest + URLSession 做的网络请求处理,所以排除第三库的问题。在 URLRequest 实例话的过程中,也没有设置特定的 cachePolicy ,所以也是默认的缓存策略。那关于系统的缓存策略有哪些,默认的缓存策略又是什么样的呢?
    3. 缓存策略 Cache
      通过查询 API 我们发现有以下几种:
      useProtocolCachePolicy 协议缓存(后面会详细介绍)。这是默认的
      reloadIgnoringLocalCacheData 忽略本地缓存,也就是说不实用缓存,直接从原始资源加载。
      reloadIgnoringLocalAndRemoteCacheData // Unimplemented 在写这篇文章时 API 定义是”未实现”,所以这个忽略
      returnCacheDataElseLoad 无论缓存是否过期,都使用缓存,如果缓存不存在则请求原始资源地址
      returnCacheDataDontLoad 只用缓存,不请求网络资源。可用于类似”离线状态”
      reloadRevalidatingCacheData 从原始地址确认缓存数据的合法性后,缓存数据就可以使用,否则从原始资源请求从本例来看,我们使用了默认的协议缓存策略。下面来看看这个策略是如何工作的。
    4. 协议缓存 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
      [Response Header]

      3. 如果结果为是,则发起 HEAD request 请求,查看内容是否有变更,”是”则请求网络数据,如果否就用缓存
      4. 如果上面的结果是否,则查看 Response 是否失效 (stale?)

      这里的失效算法算是黑盒了,不过还好发现篇文章,描述了如何计算出这个失效期限。

      5. 如果计算的结果是失效的 stale 是 true ,则去发送 issue request 请求。如果是否返回缓存数据

    5. 缓存文件 Cache File默认的缓存文件存在于 ~/(App Sandbox)/Library/Caches/(bundle id)… 目录下,我们可以看到有以下几个文件 :Screen Shot 2017-03-09 at 2.44.41 PM
      Cache.db 就是缓存文件的sqlite数据库文件 打开后你会发现以下几张表
      cfurl_cache_blob_data
      cfurl_cache_response   表里就存有了请求的资源 key , 如 https://…. 。还有时间戳等
      cfurl_cache_receiver_data  里存有了缓存的 Response.
      cfurl_cache_schema_version在本例里你会发现缓存的错误数据都在那。
    6. 故障发生的原因通过我们现有的错误 Response header 头里,我们会发现1. 我们使用默认的缓存协议,所以它根据上面的 header 来判断是否使用缓存数据
      2. 通过上面 stale 公式的计算,也正好还在有效期内
      3. 通过打开缓存数据库文件我们也发现了这些错误的数据结果 所以它根本没有向服务器请求任何数据,导致了这些用户一直打开的是错误页面。那为什么它会缓存错误结果,而不是将错误数据丢弃呢。从上面我们也可以发现 status code 是 200,也就是说它当成了正常返回数据将其缓存了。
  3. 解决
    1. 避免缓存无效的 Response首先服务端对于错误的返回结果不能返回 200 status code
      客户端要做强校验,对于返回的不规范的格式或非业务所需,直接 removeCachedResponse
    2. 设置强制清理缓存机制可以由客户手动清理缓存,或由服务端控制清理
    3. 区别对待不同的 API 请求 cache 策略客户端与服务端对不同的请求设定不同的缓存策略,比如配置下发那些是强制刷新不缓存的。不经常变的资源可以设置更长的缓存期限

 

参考资料

NSURLCache

iOS5 Built-In HTTP DiskCache

A Primer In Http–caching And Its–native Support–by–ios

NSURLCache Uses a Disk Cache as of iOS 5

工具

iOS SDK 原生抓包工具

 

Written by square