Okhttp 之HTTP 缓存实现

ゝ一纸荒年。 2022-05-27 05:46 241阅读 0赞

以前学习 `HTTP` 的时候呢，都是从书本中学习概念，但是从来没有在服务器端和客户端去实践过。 作为移动开发人员呢，我觉得还是有必要了解`HTTP`在客户端的实现。这篇文章讲述的是 `Okhttp` 在缓存方面的实现，这需要你对 `HTTP 缓存`有个概要的认识，然后我们结合 `Okhttp` 源码来看看如何实现客户端的 `HTTP` 缓存，方便以后与服务器开发人员交(装)流(B)。

# 设置缓存 #

sOkHttpClient = new OkHttpClient.Builder()
                .cache(new Cache(getCacheDir(), 10 * 1024 * 1024))
                .build();

很简单，只需要在创建 `Cache` 的时候指定缓存的目录和大小即可。这个缓存将会在 `CacheInterceptor` 中用到，`CacheInterceptor` 是在 `RealCall` 的 `getResponseWithInterceptorChain()` 方法中加入的

`RealCall.java`

Response getResponseWithInterceptorChain() throws IOException {
        // ...
    
        interceptors.add(new CacheInterceptor(client.internalCache()));
    
        // ...
    }

从缓存中获取响应和把响应写入缓存，这两个过程都是在 `CacheInterceptor.intercept()` 中执行的。

# 缓存未命中 #

缓存未命中是针对一个请求，没有从缓存中获取到响应。下面就分析这个情况。

`CacheInterceptor.java`

public Response intercept(Chain chain) throws IOException {
            // 从缓存中获取响应
            Response cacheCandidate = cache != null
                    ? cache.get(chain.request())
                    : null;
    
            long now = System.currentTimeMillis();
            // CacheStrategy 决定是从网络获取还是从缓存中获取
            CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
            Request networkRequest = strategy.networkRequest;
            Response cacheResponse = strategy.cacheResponse;
    
            if (cache != null) {
                // 用缓存记录请求的次数，网络请求次数/缓存命中次数
                cache.trackResponse(strategy);
            }
    
            // ...
    
            Response networkResponse = null;
            try {
       //从网络获取响应
                networkResponse = chain.proceed(networkRequest);
            } finally {
                // If we're crashing on I/O or otherwise, don't leak the cache body.
                if (networkResponse == null && cacheCandidate != null) {
                    closeQuietly(cacheCandidate.body());
                }
            }
    
            // ...
    
            Response response = networkResponse.newBuilder()
                    .cacheResponse(stripBody(cacheResponse))
                    // 去掉 body ，留下 start line 和 headers
                    .networkResponse(stripBody(networkResponse))
                    .build();
    
            if (cache != null) {
                // 如果有响应体，而且能缓存
                if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
                    // 加入缓存 
                    // Offer this request to the cache.
                    CacheRequest cacheRequest = cache.put(response);
                    // 把缓存写到响应中，并返回
                    return cacheWritingResponse(cacheRequest, response);
                }
    
                // 请求方法不能缓存，就移除缓存副本
                if (HttpMethod.invalidatesCache(networkRequest.method())) {
                    try {
                        cache.remove(networkRequest);
                    } catch (IOException ignored) {
                        // The cache cannot be written.
                    }
                }
            }
    
            return response;
        }

第`3`行，从缓存中获取响应，由于分析的缓存未命中的情况，此时为 `null`。

第`9`到`11`行，是从缓存策略中获取请求和响应，这里涉及到的是缓存的有效性和服务器再验证过程。由于分析的缓存未命中的情况，因此，`networkRequest` 也就是原请求，`cacheResponse` 为 `null`。

第 `15` 行，使用 `Cache` 来跟踪请求的次数，网络请求次数或缓存命中次数。源码如下

`Cache.java`

synchronized void trackResponse(CacheStrategy cacheStrategy) {
            requestCount++;
    
            if (cacheStrategy.networkRequest != null) {
                // If this is a conditional request, we'll increment hitCount if/when it hits.
                networkCount++;
            } else if (cacheStrategy.cacheResponse != null) {
                // This response uses the cache and not the network. That's a cache hit.
                hitCount++;
            }
        }

第 `22` 行表明缓存策略的缓存响应无效，就执行网络请求，这个请求过程并不在本文的分析范围内，因此不深究。

第 `32` 行，重新构造 `Response` 对象，加入 `cacheResponse` 和 `networkResponse` 属性。`stripBody()` 方法，其实就是把响应中的 `body`去掉，保留 `start line` 和 `headers`。

`Cache.java`

private static Response stripBody(Response response) {
            return response != null && response.body() != null
                ? response.newBuilder().body(null).build()
                : response;
        }

由于缓存未命中，因此 `cacheResponse()` 保存的值为 `null`。

第 `40` 行，可以看到有两个条件，一个是判断响应中是否有 `body`，一个是判断是否能进行缓存。一旦成立，就代表我们需要更新缓存。

首先看看 `HttpHeaders.hasBody(response)` 如何判断是否有 `body` 的。

`HttpHeaders.java`

/** Returns true if the response must have a (possibly 0-length) body. See RFC 7231. */
        public static boolean hasBody(Response response) {
            // HEAD requests never yield a body regardless of the response headers.
            if (response.request().method().equals("HEAD")) {
                return false;
            }
    
            int responseCode = response.code();
            if ((responseCode < HTTP_CONTINUE || responseCode >= 200)
                    && responseCode != HTTP_NO_CONTENT
                    && responseCode != HTTP_NOT_MODIFIED) {
                return true;
            }
    
            // If the Content-Length or Transfer-Encoding headers disagree with the response code, the
            // response is malformed. For best compatibility, we honor the headers.
            if (contentLength(response) != -1
                    || "chunked".equalsIgnoreCase(response.header("Transfer-Encoding"))) {
                return true;
            }
    
            return false;
        }

`HTTP` 的响应在哪些情况下是没有 `body`的？  
1. `HEAD` 请求是没有 `body`，但是可以有 `Content-Length` 属性。  
2. 响应码为 `1XX`, `204`, `304` 的响应是没有 `body`的。 `100~199` 的代表的是信息性状态码，用于客户端和服务器之间的信息交换，例如确认服务器是否可以处理客户端的 `body`。`204`代表 `No Content`，这个主要用于浏览器，向服务器提交数据，但是不需要浏览器展示数据更新后的页面。`304` 代表 `Not Modified`，这个用来对服务器进行有条件的请求，用来验证缓存资源的有效性，如果缓存资源有效，服务器会返回 `304`，并不带 `body`。

但是在 `HttpHeaders.hasBody()` 的方法中，它还处理了一种兼容的情况，对于那些不能带有 `body` 的状态码， 如果响应首部`Content-Length` 值不为 `-1` 或 `Transfer-Encoding` 为 `chunked`，也可以带有 `body`。(可能为兼容 HTTP/1.1 之前的协议？)

再来看看 `CacheStrategy.isCacheable()` 方法如何判断能够缓存的。

`CacheStrategy.java`

/** Returns true if {@code response} can be stored to later serve another request. */
        public static boolean isCacheable(Response response, Request request) {
            // Always go to network for uncacheable response codes (RFC 7231 section 6.1),
            // This implementation doesn't support caching partial content.
            switch (response.code()) {
                // https://tools.ietf.org/html/rfc7231#section-6.1
                case HTTP_OK: // 200
                case HTTP_NOT_AUTHORITATIVE: // 203
                case HTTP_NO_CONTENT: // 204
                case HTTP_MULT_CHOICE: // 300 
                case HTTP_MOVED_PERM:// 301
                case HTTP_NOT_FOUND: // 404
                case HTTP_BAD_METHOD: // 405
                case HTTP_GONE: // 410
                case HTTP_REQ_TOO_LONG: // 414
                case HTTP_NOT_IMPLEMENTED: // 501
                case StatusLine.HTTP_PERM_REDIRECT: // 308
                    // These codes can be cached unless headers forbid it.
                    break;
    
                case HTTP_MOVED_TEMP: // 302
                case StatusLine.HTTP_TEMP_REDIRECT: // 307
                    // These codes can only be cached with the right response headers.
                    // http://tools.ietf.org/html/rfc7234#section-3
                    // s-maxage is not checked because OkHttp is a private cache that should ignore s-maxage.
                    if (response.header("Expires") != null
                            || response.cacheControl().maxAgeSeconds() != -1
                            || response.cacheControl().isPublic()
                            || response.cacheControl().isPrivate()) {
                        break;
                    }
                    // Fall-through.
    
                default:
                    // All other codes cannot be cached.
                    return false;
            }
    
            // A 'no-store' directive on request or response prevents the response from being cached.
            return !response.cacheControl().noStore() && !request.cacheControl().noStore();
        }

从实现可以看出，除去这13种响应码，其它的响应码都是不可以进行缓存的。而这13种缓存，最终是由请求报文的响应报文的 `Cache-Control:no-store` 共同决定的，也就是 `CacheStrategy.isCacheable()` 最后一个 `return` 语句的效果。

> 1.  [https://tools.ietf.org/html/rfc7231\#section-6.1][https_tools.ietf.org_html_rfc7231_section-6.1] 和 [http://tools.ietf.org/html/rfc7234\#section-3][http_tools.ietf.org_html_rfc7234_section-3] 给出能够响应的状态码，但是好像并没有给全的样子。
> 2.  `CacheStrategy.isCacheable()` 并不能缓存范围请求(`Range`)的响应，也就状态码为 `206` 的响应。
> 3.  忽略共享缓存属性 `Cache-Control: s-maxage`，因为应用的缓存是私有缓存。

现在回到 `CacheInterceptor.intercept()` 的第 `43` 行，到这里代表了响应有 `body`，而且能够进行缓存，于是乎，把响应在缓存中添加一个副本。

`Cache.java`

CacheRequest put(Response response) {
            String requestMethod = response.request().method();
    
            if (HttpMethod.invalidatesCache(response.request().method())) {
                try {
                    remove(response.request());
                } catch (IOException ignored) {
                    // The cache cannot be written.
                }
                return null;
            }
            if (!requestMethod.equals("GET")) {
                // Don't cache non-GET responses. We're technically allowed to cache
                // HEAD requests and some POST requests, but the complexity of doing
                // so is high and the benefit is low.
                return null;
            }
    
            if (HttpHeaders.hasVaryAll(response)) {
                return null;
            }
    
            Cache.Entry entry = new Cache.Entry(response);
            DiskLruCache.Editor editor = null;
            try {
                editor = cache.edit(key(response.request().url()));
                if (editor == null) {
                    return null;
                }
                entry.writeTo(editor);
                return new Cache.CacheRequestImpl(editor);
            } catch (IOException e) {
                abortQuietly(editor);
                return null;
            }
        }

首先 `HttpMethod.invalidatesCache()` 第 `4` 行判断哪些请求方法的缓存是无效的。

`HttpMethod.java`

public static boolean invalidatesCache(String method) {
        return method.equals("POST")
            || method.equals("PATCH")
            || method.equals("PUT")
            || method.equals("DELETE")
            || method.equals("MOVE");     // WebDAV
      }

这些方法都是对服务器数据进行操作的方法，因此不需要缓存响应。如果已经缓存过，就需要删除缓存。 否则，后续的这些对服务器数据进行操作的方法可能就不会传达到服务器，可能经过缓存就返回了。

然后 `HttpMethod.invalidatesCache()` 第 `12` 行，也并没有缓存非 `GET` 的响应，从注释中可以看出，从技术角度看，是可以缓存 `HEAD` 和 某些 `POST` 请求的，然而由于过于复杂，缓存这些响应弊大于利，因此 `Okhttp` 并不会对这些请求进行缓存。

然后 `HttpMethod.invalidatesCache()` 第 `19` 行，如果响应头中带有 `Vary` 头部，也不进行缓存。 `Vary` 是协商首部，服务器会根据这个首部列出的其它首部列表决定响应。因此这个带有 `Vary` 首部的响应应该是不“稳定的”，没必要缓存(一脸懵B)。

`HttpMethod.invalidatesCache()` 最后把这个响应写入到 `Okhttp`的`DiskLruCache` 缓存中，但是不要以为是直接读取响应的 `body` ，然后写入缓存，它只是写入了 `start line` 和 `header` 的信息

`Cache.Entry`

public void writeTo(DiskLruCache.Editor editor) throws IOException {
          BufferedSink sink = Okio.buffer(editor.newSink(ENTRY_METADATA));
    
          sink.writeUtf8(url)
              .writeByte('\n');
          sink.writeUtf8(requestMethod)
              .writeByte('\n');
          sink.writeDecimalLong(varyHeaders.size())
              .writeByte('\n');
          for (int i = 0, size = varyHeaders.size(); i < size; i++) {
            sink.writeUtf8(varyHeaders.name(i))
                .writeUtf8(": ")
                .writeUtf8(varyHeaders.value(i))
                .writeByte('\n');
          }
    
          sink.writeUtf8(new StatusLine(protocol, code, message).toString())
              .writeByte('\n');
          sink.writeDecimalLong(responseHeaders.size() + 2)
              .writeByte('\n');
          for (int i = 0, size = responseHeaders.size(); i < size; i++) {
            sink.writeUtf8(responseHeaders.name(i))
                .writeUtf8(": ")
                .writeUtf8(responseHeaders.value(i))
                .writeByte('\n');
          }
          sink.writeUtf8(SENT_MILLIS)
              .writeUtf8(": ")
              .writeDecimalLong(sentRequestMillis)
              .writeByte('\n');
          sink.writeUtf8(RECEIVED_MILLIS)
              .writeUtf8(": ")
              .writeDecimalLong(receivedResponseMillis)
              .writeByte('\n');
    
          if (isHttps()) {
            sink.writeByte('\n');
            sink.writeUtf8(handshake.cipherSuite().javaName())
                .writeByte('\n');
            writeCertList(sink, handshake.peerCertificates());
            writeCertList(sink, handshake.localCertificates());
            sink.writeUtf8(handshake.tlsVersion().javaName()).writeByte('\n');
          }
          sink.close();
        }

从实现可以看出，它只是把 `url`, `method`, `Vary` 首部，`start line` 等等一些属性写入 `DiskLruCache`，然而并不包括 `body`。那么 `body` 在什么写入的呢？ 当然是用户开始读取的时候写入缓存。

注意 `HttpMethod.invalidatesCache()`第`31`行，它返回了一个 `CacheRequest` 接口的实现类，它提供了向缓存写入的接口。

现在回到 `CacheInterceptor.intercept()` 的第 `45` 行，`cacheWritingResponse()` 它会创建一个新的 `Source`，当用户开始读取数据的时候，就会向缓存中写入数据。

`CacheInterceptor.java`

private Response cacheWritingResponse(final CacheRequest cacheRequest, Response response)
                throws IOException {
            // Some apps return a null body; for compatibility we treat that like a null cache request.
            if (cacheRequest == null) return response;
            Sink cacheBodyUnbuffered = cacheRequest.body();
            if (cacheBodyUnbuffered == null) return response;
    
            final BufferedSource source = response.body().source();
            final BufferedSink cacheBody = Okio.buffer(cacheBodyUnbuffered);
    
            Source cacheWritingSource = new Source() {
                boolean cacheRequestClosed;
    
                @Override public long read(Buffer sink, long byteCount) throws IOException {
                    long bytesRead;
                    try {
                        bytesRead = source.read(sink, byteCount);
                    } catch (IOException e) {
                        if (!cacheRequestClosed) {
                            cacheRequestClosed = true;
                            cacheRequest.abort(); // Failed to write a complete cache response.
                        }
                        throw e;
                    }
    
                    if (bytesRead == -1) {
                        if (!cacheRequestClosed) {
                            cacheRequestClosed = true;
                            cacheBody.close(); // The cache response is complete!
                        }
                        return -1;
                    }
    
                    sink.copyTo(cacheBody.buffer(), sink.size() - bytesRead, bytesRead);
                    cacheBody.emitCompleteSegments();
                    return bytesRead;
                }
    
                @Override public Timeout timeout() {
                    return source.timeout();
                }
    
                @Override public void close() throws IOException {
                    if (!cacheRequestClosed
                            && !discard(this, HttpCodec.DISCARD_STREAM_TIMEOUT_MILLIS, MILLISECONDS)) {
                        cacheRequestClosed = true;
                        cacheRequest.abort();
                    }
                    source.close();
                }
            };
    
            String contentType = response.header("Content-Type");
            long contentLength = response.body().contentLength();
            return response.newBuilder()
                    .body(new RealResponseBody(contentType, contentLength, Okio.buffer(cacheWritingSource)))
                    .build();
        }

在前面的文章 [Okhttp 之 okio][Okhttp _ okio] 剖析过 `okio`，如果有这个基础，就可以看懂这段代码，这里我就不再解析了。 总之这段代码的作用就是当用户开始读取数据的时候，就会向缓存中写入数据。

# 缓存命中 #

缓存命中的情况比未命中的情况要复杂的多，因为这涉及到缓存验证问题，而缓存验证问题是由 `CacheStrategy` 决定的，因此重点就是这个 `CacheStragy` 类。先看下如何创建 `CacheStratety` 对象的。

`CacheInterceptor.java`

public Response intercept(Chain chain) throws IOException {
            Response cacheCandidate = cache != null
                    ? cache.get(chain.request())
                    : null;
    
            long now = System.currentTimeMillis();
    
            CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
            Request networkRequest = strategy.networkRequest;
            Response cacheResponse = strategy.cacheResponse;
    
            // ...
    
            return response;
        }

在 `CacheInterceptor.intercept()` 第 `8` 行， `CacheStrategy` 的 `Factory()`方法

`CacheStrategy.java`

public Factory(long nowMillis, Request request, Response cacheResponse) {
            this.nowMillis = nowMillis;
            this.request = request;
            this.cacheResponse = cacheResponse;
    
            if (cacheResponse != null) {
                this.sentRequestMillis = cacheResponse.sentRequestAtMillis();
                this.receivedResponseMillis = cacheResponse.receivedResponseAtMillis();
                Headers headers = cacheResponse.headers();
                for (int i = 0, size = headers.size(); i < size; i++) {
                    String fieldName = headers.name(i);
                    String value = headers.value(i);
                    if ("Date".equalsIgnoreCase(fieldName)) {
                        servedDate = HttpDate.parse(value);
                        servedDateString = value;
                    } else if ("Expires".equalsIgnoreCase(fieldName)) {
                        expires = HttpDate.parse(value);
                    } else if ("Last-Modified".equalsIgnoreCase(fieldName)) {
                        lastModified = HttpDate.parse(value);
                        lastModifiedString = value;
                    } else if ("ETag".equalsIgnoreCase(fieldName)) {
                        etag = value;
                    } else if ("Age".equalsIgnoreCase(fieldName)) {
                        ageSeconds = HttpHeaders.parseSeconds(value, -1);
                    }
                }
            }
        }

`CacheStrategy.Factor()` 方法其实就是解析一些用于验证缓存有效性的 `header`：`Date`, `Expires`, `Last-Modified`, `ETag`, `Age`。

现在再看看 `CacheStrategy.get()` 方法，它是用来获取 `CacheStrategy` 实例的。

`CacheStrategy.java`

public CacheStrategy get() {
            CacheStrategy candidate = getCandidate();
    
            // 如果请求只要求从缓存中获取响应，而缓存又没有相应的副本
            if (candidate.networkRequest != null && request.cacheControl().onlyIfCached()) {
                // We're forbidden from using the network and the cache is insufficient.
                return new CacheStrategy(null, null);
            }
    
            return candidate;
        }

而 `getCandidate()` 是用来验证缓存的有效性，要看懂这个方法，需要对 `HTTP 缓存` 有个全面的认识，这里来过一遍

`CacheStrategy.java`

private CacheStrategy getCandidate() {
            // No cached response.
            if (cacheResponse == null) {
                return new CacheStrategy(request, null);
            }
    
            // Drop the cached response if it's missing a required handshake.
            if (request.isHttps() && cacheResponse.handshake() == null) {
                return new CacheStrategy(request, null);
            }
    
            // If this response shouldn't have been stored, it should never be used
            // as a response source. This check should be redundant as long as the
            // persistence store is well-behaved and the rules are constant.
            if (!isCacheable(cacheResponse, request)) {
                return new CacheStrategy(request, null);
            }
    
            CacheControl requestCaching = request.cacheControl();
            if (requestCaching.noCache() || hasConditions(request)) {
                return new CacheStrategy(request, null);
            }
    
            CacheControl responseCaching = cacheResponse.cacheControl();
            if (responseCaching.immutable()) {
                return new CacheStrategy(null, cacheResponse);
            }
    
            long ageMillis = cacheResponseAge();
            long freshMillis = computeFreshnessLifetime();
    
            if (requestCaching.maxAgeSeconds() != -1) {
                freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds()));
            }
    
            long minFreshMillis = 0;
            if (requestCaching.minFreshSeconds() != -1) {
                minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
            }
    
            long maxStaleMillis = 0;
            if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
                maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
            }
    
            if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
                Response.Builder builder = cacheResponse.newBuilder();
                if (ageMillis + minFreshMillis >= freshMillis) {
                    builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
                }
                long oneDayMillis = 24 * 60 * 60 * 1000L;
                if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) {
                    builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\"");
                }
                return new CacheStrategy(null, builder.build());
            }
    
            // Find a condition to add to the request. If the condition is satisfied, the response body
            // will not be transmitted.
            String conditionName;
            String conditionValue;
            if (etag != null) {
                conditionName = "If-None-Match";
                conditionValue = etag;
            } else if (lastModified != null) {
                conditionName = "If-Modified-Since";
                conditionValue = lastModifiedString;
            } else if (servedDate != null) {
                conditionName = "If-Modified-Since";
                conditionValue = servedDateString;
            } else {
                return new CacheStrategy(request, null); // No condition! Make a regular request.
            }
    
            Headers.Builder conditionalRequestHeaders = request.headers().newBuilder();
            Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);
    
            Request conditionalRequest = request.newBuilder()
                    .headers(conditionalRequestHeaders.build())
                    .build();
            return new CacheStrategy(conditionalRequest, cacheResponse);
        }

第 `3` 行，这就是之前分析的缓存未命中的情况。

第 `8` 行，会对 `HTTPS` 协议的请求，如果没有 `handskake` 过程，就需要重新进行网络请求，也就是 `networkRequest=request`，而 `cacheResponse=null`。

第 `15` 行，排除了不能缓存的一些请求方法，这个 `isCacheable()` 方法在前面分析过。如果不能缓存，就只能执行网络请求，也就是 `networkRequest=request`，而 `cacheResponse=null`。

第 `20` 行，如果请求报文有 `Cache-Control:no-cache`属性，或者有条件首部(`If-Modified-Since` 和 `If-None-Match`)，就不能从缓存中直接获取，还是需要重新从网络获取。

第 `25` 行，如果响应报文有 `Cache-Control:immutable`属性，就直接从缓存中获取。

第 `25` 到 `56` 行，通过计算缓存资源的使用期和新鲜度，来估算缓存有效性，这个算法有点讲究，在 `<<HTTP权威指南>>` 的一书的 `7.11` 节，有对这个算法作详细的解释，这里就不去深究缓存算法了，有点烧脑。

第 `62` 到 `70` 行，分别用缓存响应的 `ETag`, `Last-Modified`, `Date`的 `header`属性进行条件请求验证，如果没有这些请求头，就直接做网络请求。

第 `75` 到 `76` 行，为 `OkhttpClient` 设置这些条件请求头。

第 `78` 到 `80` 行，为请求报文设置设置这些请求条件。

最后根据以上的种种情况，返回相应的 `CacheStrategy` 对象，也就是返回相应的策略，到底是直接用缓存，还是要直接用网络请求，还是要进行条件性请求验证。

现在明白了缓存的策略，那么我们再回头分析 `CacheInterceptor.intercept()` 的的缓存命中情况的代码

`CacheInterceptor.java`

public Response intercept(Chain chain) throws IOException {
            // 获取缓存
            Response cacheCandidate = cache != null
                    ? cache.get(chain.request())
                    : null;
    
            long now = System.currentTimeMillis();
    
            // 获取缓存策略
            CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
            Request networkRequest = strategy.networkRequest;
            Response cacheResponse = strategy.cacheResponse;
    
            if (cache != null) {
                // 记录缓存请求
                cache.trackResponse(strategy);
            }
    
            // 如果获取到缓存响应不为null，而缓存策略的缓存响应为null，证明缓存不可用，关闭它。
            if (cacheCandidate != null && cacheResponse == null) {
                closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
            }
    
            // 如果缓存策略禁止网络请求，同时缓存无效，直接返回504
            // If we're forbidden from using the network and the cache is insufficient, fail.
            if (networkRequest == null && cacheResponse == null) {
                return new Response.Builder()
                        .request(chain.request())
                        .protocol(Protocol.HTTP_1_1)
                        .code(504)
                        .message("Unsatisfiable Request (only-if-cached)")
                        .body(Util.EMPTY_RESPONSE)
                        .sentRequestAtMillis(-1L)
                        .receivedResponseAtMillis(System.currentTimeMillis())
                        .build();
            }
    
            // 如果不需要进行网络请求，同时响应不为null，就直接返回缓存中的副本
            // If we don't need the network, we're done.
            if (networkRequest == null) {
                return cacheResponse.newBuilder()
                        .cacheResponse(stripBody(cacheResponse))
                        .build();
            }
    
            // 进行网络请求
            Response networkResponse = null;
            try {
                networkResponse = chain.proceed(networkRequest);
            } finally {
                // If we're crashing on I/O or otherwise, don't leak the cache body.
                if (networkResponse == null && cacheCandidate != null) {
                    closeQuietly(cacheCandidate.body());
                }
            }
    
            // 更新缓存
            // If we have a cache response too, then we're doing a conditional get.
            if (cacheResponse != null) {
                if (networkResponse.code() == HTTP_NOT_MODIFIED) { // 服务器返回304 Not Modified，更新缓存
                    Response response = cacheResponse.newBuilder()
                            .headers(combine(cacheResponse.headers(), networkResponse.headers()))
                            .sentRequestAtMillis(networkResponse.sentRequestAtMillis())
                            .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
                            .cacheResponse(stripBody(cacheResponse))
                            .networkResponse(stripBody(networkResponse))
                            .build();
                    networkResponse.body().close();
    
                    // Update the cache after combining headers but before stripping the
                    // Content-Encoding header (as performed by initContentStream()).
                    cache.trackConditionalCacheHit();
                    cache.update(cacheResponse, response);
                    return response;
                } else { // 缓存无效，关闭缓存响应
                    closeQuietly(cacheResponse.body());
                }
            }
    
            // 如果缓存无效就需要重新构造 Response
            Response response = networkResponse.newBuilder()
                    .cacheResponse(stripBody(cacheResponse))
                    .networkResponse(stripBody(networkResponse))
                    .build();
    
            if (cache != null) {
                if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
                    // Offer this request to the cache.
                    CacheRequest cacheRequest = cache.put(response);
                    return cacheWritingResponse(cacheRequest, response);
                }
    
                if (HttpMethod.invalidatesCache(networkRequest.method())) {
                    try {
                        cache.remove(networkRequest);
                    } catch (IOException ignored) {
                        // The cache cannot be written.
                    }
                }
            }
    
            return response;
        }

当我们获取到了 `CacheStrategy` 缓存策略后，就可以获取 `networkRequest` 和 `cacheResponse`，也就是第 `9` 和 `10` 行所做的。那么组合 `networkRequest` 和 `cacheResponse` 就有四种情况了。  
1. `networkRequest = null`，`cacheResponse = null`，无效请求(`21` 到 `31`行)。  
2. `networkRequest = null`，`cacheResponse != null`，缓存有效，直接返回缓存，(`34` 到 `38` 行)。  
3. `networkRequest != null`，`cacheResponse = null`，就需要直接网络请求(`42`行)，然后重构响应，并更新缓存(`72`到 `91`行)。  
4. `networkRequest != null`，`cacheResponse != null`，就需要直接网络请求(`42`行)，然后根据服务器响应状态码，更新缓存或者重构缓存(`51`到 `91`行)。

# 结束 #

在实际的应用中，客户端缓存实际上很大部分取决于服务器的实现，然而很多时候，我们并没有控制服务器的能力，因而客户端的缓存很可能并没有用，比如你访问百度，虽然页面总是一样，但是我们手机端是不会缓存的，因为在响应报文中没有设置用于缓存的 `header`。 而一旦，我们能够与服务器开发人员交互，那么掌握客户端缓存的实现，就有助于我们与服务器开发人员更好的交(装)流(B)。

[https_tools.ietf.org_html_rfc7231_section-6.1]: https://tools.ietf.org/html/rfc7231#section-6.1
[http_tools.ietf.org_html_rfc7234_section-3]: http://tools.ietf.org/html/rfc7234#section-3
[Okhttp _ okio]: https://blog.csdn.net/zwlove5280/article/details/79820139