IOS HTTP缓存小结

首先先了解一下http中是的缓存逻辑是如何处理的。
一般情况下客户端的缓存行为是由服务器控制的，客户端与服务器通过请求和响应头的相关字段进行交流，介绍一下相关字段。

http 1.0

Pragma
通用头（响应和请求头中都可以用，但是含义不同）
Pragma只对应no-cache，。用在请求头中，表示不使用缓存，直接从服务端获取资源（不存在304情况，直接返回资源），作为响应头，RFC2616文档说，Pragma : no-cache的行为并没有被定义，不能保证它的意义和Cache-Control:no-cache一致。

Expires
响应头
表示缓存过期的时刻
Expires:Fri, 11 Jun 2021 11:33:01 GMT

http 1.1

cache-control
通用头，可以控制缓存过期时间，是否每次校验，能否缓存
缓存请求指令

指令	参数	说明
no-cache	无	强制向源服务器再次验证
no-store	无	不缓存请求或响应的任何内容
max-age = [秒]	必须	响应的最大age值
max-stale(=[秒])	可省略	接受已过期的响应
min-fresh = [秒]	必须	期望在指定时间内的响应仍有效
no-transform	无	代理不可更改媒体类型
only-if-cached	无	从缓存获取资源
cache-extension		扩展位

缓存响应指令

指令	参数	说明
public	无	可向任意方提供响应的缓存
private	无	仅向指定用户提供返回响应
no-cache	无	使用缓存前必须到服务端校验
no-store	无	不缓存请求或响应的任何内容
no-transform	无	代理不可修改媒体类型
must-revalidate	无	可缓存但是必须再像源服务器进行确认（与no-cache的区别后面讲）
proxy-revalidate	无	要求中间缓存服务器对缓存的响应的有效性再次确认
max-age = [秒]	必须	响应的过期时间
s-maxage = [秒]	必须	公共缓存服务器响应的最大age值
cache-extension		扩展位

讲下我们常用的no-cache和must-revalidate的区别,
no-cache表示客户端不管数据是否过期都要向服务端校验，如果请求失败，会直接用缓存数据。
must-revalidate表示客户端的缓存数据如果没有过期（这点是根据max-age提供的相对时间判断的，是客户端逻辑），如果没过期不向服务端校验，如果过期了，则需要向服务端校验，但是如果请求失败了，也不会用缓存数据，这点与no-cache不同。取自WKWebView默认缓存策略与HTTP缓存协议

Last-Modified、if-Modified-Since

这两个成对使用，用于服务端校验资源是否过期。
响应头Last-Modified表示资源的最后修改时间，栗子：If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
请求头if-Modified-Since传入上次请求时返回的Last-Modified，服务端判断当前资源修改时间是否大于传入的资源修改时间，如果大于说明资源有修改返回200和最新的资源，否则说明资源没有修改返回304。

注意：如果响应没有返回cache-control：max-age或者Expires，那么客户端在下次请求时就没法判断缓存资源是否过期，这是就会根据Last-Modified触发一个启发式缓存，缓存时长=(date_value - last_modified_value) * 0.10，当然由上面讲的no-cache会禁用这种启发式缓存。

Etag、if-None-Match

Etag相当于是资源所对应的哈希值（指纹），例如：Etag: "5d8c72a5edda8d6a:3239
与if-None-Match成对使用，可对比资源的指纹来确认资源是否有变化。

IOS端上是如何处理的？

其实知道了上面这些我就很疑惑，因为端上没有处理过这种缓存逻辑？？但是有些缓存是确认存在的，原因就是IOS的网络框架中已经内置了HTTP协议标准的缓存逻辑，当我们使用默认缓存逻辑时，返回的304会自动转换成200，并且返回缓存数据，我们只需要处理请求成功和失败的逻辑即可，缓存对于端上是无感知的。
下面我们验证一下，下面代码请求了一张图片

- (void)func1{
    NSURL * url = [[NSURL alloc] initWithString:@"http://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1566462677&di=28ea1b4c506eb93b98d9d6d1191b9e81&imgtype=jpg&er=1&src=http%3A%2F%2Fb-ssl.duitang.com%2Fuploads%2Fitem%2F201605%2F28%2F20160528212429_c2HAm.jpeg"];
    NSMutableURLRequest * request = [[NSMutableURLRequest alloc] initWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:5];
    request.HTTPMethod = @"GET";
    NSURLSession * session = [NSURLSession sharedSession];
    NSURLSessionTask * task = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        NSHTTPURLResponse * httpResponse = (NSHTTPURLResponse *)response;
        self.lastModified = httpResponse.allHeaderFields[@"Last-Modified"];
        self.Etag = httpResponse.allHeaderFields[@"Etag"];
        if (httpResponse.statusCode == 304){
            NSCachedURLResponse * cacheRespose = [[NSURLCache sharedURLCache] cachedResponseForRequest:request];
            dispatch_async(dispatch_get_main_queue(), ^{
                self.imageView.image = [UIImage imageWithData:cacheRespose.data];
            });
        }else{
            dispatch_async(dispatch_get_main_queue(), ^{
                self.imageView.image = [UIImage imageWithData:data];
            });
        }
        
    }];
    [task resume];
    
}

我们看一下第二次requestHeader和responseHeader的数据：

requestHeader respondHeader

可以看到请求默认加上了if-None-Match和if-Modified-Since字段，但其实我们并没有手动添加，而responseHeader中返回的是304并且无数据，我们打印端上的httpResponse.statusCode发现返回的是200，正常返回数据，这就验证了上面说的哪一点。

至于其余的缓存策略可以看这里对NSURLRequestUseProtocolCachePolicy的理解