享学课堂特邀作者：周周

转载请声明出处！

引子

OkHttp 知名第三方网络框架SDK，使用简单，性能优秀，但是内核并不简单，此系列文章，专挑硬核知识点详细讲解. 何为硬核，就是要想深入研究，你绝对绕不过去的知识点.

TIPS:声明：拦截器种细节太多，要一一讲解不太现实，所以我挑了其中最实用的一些要点加以总结。

本文接上一篇文章:

详细讲解 OKHttp的核心内容，拦截器。不过拦截器众多，有系统自带的，也有我们可以自己去自定义的。

这是网络请求执行的核心方法的起点，这里涉及了众多拦截器.

正文大纲

系统自带拦截器

1 重试与重定向拦截器 RetryAndFollowUpInterceptor

2 桥接拦截器 BridgeInterceptor

3 缓存拦截器 CacheInterceptor

4 连接拦截器 ConnectInterceptor

5 服务调用拦截器 CallServerInterceptor

正文

在详解拦截器之前，有必要先将 RealCall的 getResponseWithInterceptorChain() 方法最后两行展开说明：

Interceptor.Chain chain = new RealInterceptorChain( interceptors, null, null, null, 0, originalRequest);
return chain.proceed(originalRequest);

这里最终返回 一个Response，进入chain.proceed方法，最终索引到 RealInterceptorChain的proceed方法:

之后，我们追踪这个interceptor.intercept(next); ，发现是一个接口，找到实现类，有多个，进入其中的RetryAndFollowUpInterceptor，发现：

它这里又执行了 chain.proceed,于是又回到了RealInterceptorChain.proceed()方法,但是此时，刚才链条中的拦截器已经不再是原来的拦截器了，而是变成了第二个，因为每一次都index+1了（这里比较绕，类似递归，需要反复仔细体会）,依次类推，直到所有拦截器的intercept方法都执行完毕，直到链条中没有拦截器。就返回最后的Response。

这一段是okhttp责任链模式的核心，应该好理解。

系统自带拦截器

1. 重试与重定向拦截器 RetryAndFollowUpInterceptor

先说结论吧：

顾名思义，retry 重试， FollowUp 重定向 。这个拦截器处在所有拦截器的第一个，它是用来判定要不要对当前请求进行重试和重定向的，那么我们应该关心的是：什么时候重试，什么时候重定向。

并且，它会判断用户有没有取消请求，因为RealCall中有一个cancel方法，可以支持用户取消请求

（不过这里有两种情况，在请求发出之前取消，和 在之后取消。如果是在请求之前取消，那就直接不执行之后的过程，如果是在请求发出去之后取消，那么客户端就会丢弃这一次的response）

重试

RetryAndFollowUpInterceptor的核心方法 interceptor() :

 @Override public Response intercept(Chain chain) throws IOException {
 ...省略
 while (true) {
 ...省略
 try {
 response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
 releaseConnection = false;
 } catch (RouteException e) {
 // The attempt to connect via a route failed. The request will not have been sent.
 if (!recover(e.getLastConnectException(), false, request)) {
 throw e.getLastConnectException();
 }
 releaseConnection = false;
 continue;
 } catch (IOException e) {
 // An attempt to communicate with a server failed. The request may have been sent.
 boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
 if (!recover(e, requestSendStarted, request)) throw e;
 releaseConnection = false;
 continue;
 }
 ...省略
 if (followUp == null) {
 if (!forWebSocket) {
 streamAllocation.release();
 }
 return response;
 }
 ...省略
 }
 }

上面的代码中，我只保留了关键部分。其中有两个continue，一个return.

当请求到达了这个拦截器，它会进入一个while(true)循环，

• 当发生了RouteException 异常（这是由于请求尚未发出去，路由异常，连接未成功），就会去判断recover方法的返回值，根据返回值决定要不要continue.
• 当发生IOException(请求已经发出去，但是和服务器通信失败了)之后，同样去判断recover方法的返回值，根据返回值决定要不要continue.

如果这两个continue都没有执行，就有可能走到最后的return response结束本次请求.

那么 是不是要重试，其判断逻辑就在recover()方法内部：

private boolean recover(IOException e, StreamAllocation streamAllocation,
 boolean requestSendStarted, Request userRequest) {
 streamAllocation.streamFailed(e);
 //todo 1、在配置OkhttpClient是设置了不允许重试（默认允许），则一旦发生请求失败就不再重试
 //The application layer has forbidden retries.
 if (!client.retryOnConnectionFailure()) return false;
 //todo 2、由于requestSendStarted只在http2的io异常中为false，http1则是 true，
 //在http1的情况下，需要判定 body有没有实现UnrepeatableRequestBody接口,而body默认是没有实现，所以后续instanceOf不成立，不会走return false.
 //We can't send the request body again.
 if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody)
 return false;
 //todo 3、判断是不是属于重试的异常
 //This exception is fatal.
 if (!isRecoverable(e, requestSendStarted)) return false;
 //todo 4、有没有可以用来连接的路由路线
 //No more routes to attempt.
 if (!streamAllocation.hasMoreRoutes()) return false;
 // For failure recovery, use the same route selector with a new connection.
 return true;
 }

简单解读一下这个方法：

• 如果okhttpClient已经set了不允许重试，那么这里就返回false，不再重试。
• 如果requestSendStarted 只在http2.0的IO异常中是true，不过HTTP2.0还没普及，先不管他，这里默认通过。
• 判断是否是重试的异常，也就是说，是不是之前重试之后发生了异常。
• 这里解读一下，之前重试发生过异常，抛出了Exception，这个isRecoverable方法会根据这个异常去判定，是否还有必要去重试。
• 协议异常，如果发生了协议异常，那么没必要重试了，你的请求或者服务器本身可能就存在问题，再重试也是白瞎。
• 超时异常，只是超时而已，直接判定重试（这里requestSendStarted是http2才会为true，所以这里默认就是false）
• SSL异常，HTTPS证书出现问题，没必要重试。
• SSL握手未授权异常,也不必重试

private boolean isRecoverable(IOException e, boolean requestSendStarted) {
 // 出现协议异常，不能重试
 if (e instanceof ProtocolException) {
 return false;
 }
 // requestSendStarted认为它一直为false(不管http2),异常属于socket超时异常,直接判定可以重试
 if (e instanceof InterruptedIOException) {
 return e instanceof SocketTimeoutException && !requestSendStarted;
 }
 // SSL握手异常中，证书出现问题，不能重试
 if (e instanceof SSLHandshakeException) {
 if (e.getCause() instanceof CertificateException) {
 return false;
 }
 }
 // SSL握手未授权异常 不能重试
 if (e instanceof SSLPeerUnverifiedException) {
 return false;
 }
 return true;
}

• 有没有可以用来连接的路由路线,也就是说，如果当DNS解析域名的时候，返回了多个IP，那么这里可能一个一个去尝试重试，直到没有更多ip可用。

重定向

依然是RetryAndFollowUpInterceptor的核心方法 interceptor() 方法，这次我截取后半段:

public Response intercept(Chain chain) throws IOException {
 while (true) {
 ...省略前面的重试判定
 //todo 处理3和4xx的一些状态码，如301 302重定向
 Request followUp = followUpRequest(response, streamAllocation.route());
 if (followUp == null) {
 if (!forWebSocket) {
 streamAllocation.release();
 }
 return response;
 }
 closeQuietly(response.body());
 //todo 限制最大 followup 次数为20次
 if (++followUpCount > MAX_FOLLOW_UPS) {
 streamAllocation.release();
 throw new ProtocolException("Too many follow-up requests: " + followUpCount);
 }
 if (followUp.body() instanceof UnrepeatableRequestBody) {
 streamAllocation.release();
 throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
 }
 //todo 判断是不是可以复用同一份连接
 if (!sameConnection(response, followUp.url())) {
 streamAllocation.release();
 streamAllocation = new StreamAllocation(client.connectionPool(),
 createAddress(followUp.url()), call, eventListener, callStackTrace);
 this.streamAllocation = streamAllocation;
 } else if (streamAllocation.codec() != null) {
 throw new IllegalStateException("Closing the body of " + response
 + " didn't close its backing stream. Bad interceptor?");
 }
 }
}

上面源码中, followUpRequest() 方法中规定了哪些响应码可以重定向：

private Request followUpRequest(Response userResponse) throws IOException {
 if (userResponse == null) throw new IllegalStateException();
 Connection connection = streamAllocation.connection();
 Route route = connection != null
 ? connection.route()
 : null;
 int responseCode = userResponse.code();
 final String method = userResponse.request().method();
 switch (responseCode) {
 // 407 客户端使用了HTTP代理服务器，在请求头中添加 “Proxy-Authorization”，让代理服务器授权
 case HTTP_PROXY_AUTH:
 Proxy selectedProxy = route != null
 ? route.proxy()
 : client.proxy();
 if (selectedProxy.type() != Proxy.Type.HTTP) {
 throw new ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy");
 }
 return client.proxyAuthenticator().authenticate(route, userResponse);
 // 401 需要身份验证 有些服务器接口需要验证使用者身份 在请求头中添加 “Authorization” 
 case HTTP_UNAUTHORIZED:
 return client.authenticator().authenticate(route, userResponse);
 // 308 永久重定向 
 // 307 临时重定向
 case HTTP_PERM_REDIRECT:
 case HTTP_TEMP_REDIRECT:
 // 如果请求方式不是GET或者HEAD，框架不会自动重定向请求
 if (!method.equals("GET") && !method.equals("HEAD")) {
 return null;
 }
 // 300 301 302 303 
 case HTTP_MULT_CHOICE:
 case HTTP_MOVED_PERM:
 case HTTP_MOVED_TEMP:
 case HTTP_SEE_OTHER:
 // 如果用户不允许重定向，那就返回null
 if (!client.followRedirects()) return null;
 // 从响应头取出location 
 String location = userResponse.header("Location");
 if (location == null) return null;
 // 根据location 配置新的请求 url
 HttpUrl url = userResponse.request().url().resolve(location);
 // 如果为null，说明协议有问题，取不出来HttpUrl，那就返回null，不进行重定向
 if (url == null) return null;
 // 如果重定向在http到https之间切换，需要检查用户是不是允许(默认允许)
 boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
 if (!sameScheme && !client.followSslRedirects()) return null;
 Request.Builder requestBuilder = userResponse.request().newBuilder();
 /**
 * 重定向请求中 只要不是 PROPFIND 请求，无论是POST还是其他的方法都要改为GET请求方式，
 * 即只有 PROPFIND 请求才能有请求体
 */
 //请求不是get与head
 if (HttpMethod.permitsRequestBody(method)) {
 final boolean maintainBody = HttpMethod.redirectsWithBody(method);
 // 除了 PROPFIND 请求之外都改成GET请求
 if (HttpMethod.redirectsToGet(method)) {
 requestBuilder.method("GET", null);
 } else {
 RequestBody requestBody = maintainBody ? userResponse.request().body() : null;
 requestBuilder.method(method, requestBody);
 }
 // 不是 PROPFIND 的请求，把请求头中关于请求体的数据删掉
 if (!maintainBody) {
 requestBuilder.removeHeader("Transfer-Encoding");
 requestBuilder.removeHeader("Content-Length");
 requestBuilder.removeHeader("Content-Type");
 }
 }
 // 在跨主机重定向时，删除身份验证请求头
 if (!sameConnection(userResponse, url)) {
 requestBuilder.removeHeader("Authorization");
 }
 return requestBuilder.url(url).build();
 // 408 客户端请求超时 
 case HTTP_CLIENT_TIMEOUT:
 // 408 算是连接失败了，所以判断用户是不是允许重试
 if (!client.retryOnConnectionFailure()) {
 return null;
 }
 // UnrepeatableRequestBody实际并没发现有其他地方用到
 if (userResponse.request().body() instanceof UnrepeatableRequestBody) {
 return null;
 }
 // 如果是本身这次的响应就是重新请求的产物同时上一次之所以重请求还是因为408，那我们这次不再重请求了
 if (userResponse.priorResponse() != null
 && userResponse.priorResponse().code() == HTTP_CLIENT_TIMEOUT) {
 return null;
 }
 // 如果服务器告诉我们了 Retry-After 多久后重试，那框架不管了。
 if (retryAfter(userResponse, 0) > 0) {
 return null;
 }
 return userResponse.request();
 // 503 服务不可用 和408差不多，但是只在服务器告诉你 Retry-After：0（意思就是立即重试） 才重请求
 case HTTP_UNAVAILABLE:
 if (userResponse.priorResponse() != null
 && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) {
 return null;
 }
 if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
 return userResponse.request();
 }
 return null;
 default:
 return null;
 }
}

解读一下这个方法，它根据拿到的response的内容，判断他的响应码，决定要不要返回一个新的request，如果返回了新的request，那么外围(看RetryAndFollowUpInterceptor的intercept方法)的while(true)无限循环就会 使用新的request再次请求,完成重定向。细节上请查看上面代码的注释，来自一位高手，写的很详细。

大概做个结论：

• 响应码 3XX 一般都会返回一个 新的Request，而另外的 return null就是不允许重定向。
• followup最大发生20次

不过还是那句话，我们不是专门做网络架构或者优化，了解到 这一个拦截器的基本作用，重要节点即可，真要抠细节，谁也记不了那么清楚。

2. 桥接拦截器 BridgeInterceptor

这个可能是这5个当中最简单的一个拦截器了，它从上一层RetryAndFollowUpInterceptor拿到request之后，只做了一件事:补全请求头

我们使用OkHttp发送网络请求，一般只会 addHeader中写上我们业务相关的一些参数，而 真正的请求头远远没有那么简单。

服务器不只是要识别 业务参数，还要识别 请求类型，请求体的解析方式等，具体列举如下：

它在补全了请求头之后，交给下一个拦截器处理。在它得到响应之后，还会干两件事：

1、保存cookie，下一次同样域名的请求就会带上cookie到请求头中，但是这个要求我们自己在okHttpClient的CookieJar中实现具体过程。

2、如果使用gzip返回的数据，则使用GzipSource包装便于解析。

3. 缓存拦截器 CacheInterceptor

本文只介绍他的作用，因为内部逻辑太过复杂，必须单独成文讲解。

作用：判定缓存命中，如果命中，就使用缓存response给上一层拦截器，不必请求服务器，如果没有命中，就 发送网络请求。

接下一篇文章.

你的赞和关注是我继续创作的动力~