Okhttp3源码解析-拦截器RetryAndFollowUpInterceptor

Posted qinzishuai

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Okhttp3源码解析-拦截器RetryAndFollowUpInterceptor相关的知识,希望对你有一定的参考价值。

### 前言 回顾: [Okhttp的基本用法](https://www.jianshu.com/p/8e404d9c160f) [Okhttp3源码解析(1)-OkHttpClient分析](https://www.jianshu.com/p/bf1d01b79ce7) [Okhttp3源码解析(2)-Request分析](https://www.jianshu.com/p/5a85345c8ea7) [Okhttp3源码解析(3)-Call分析(整体流程)](https://www.jianshu.com/p/4ed79472797a) [Okhttp3源码解析(4)-拦截器与设计模式](https://www.jianshu.com/p/b8817597f269) 上节讲了拦截器与设计模式,今天讲`RetryAndFollowUpInterceptor`,如果我们没有去自定义拦截器, 那`RetryAndFollowUpInterceptor`是第一个拦截器。 ### 初始化 首先先看`RetryAndFollowUpInterceptor`被添加的位置: ![](https://img2018.cnblogs.com/blog/1312938/201908/1312938-20190829084744888-554996670.png) 初始化位置: call实例化方法中: ``` private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) this.client = client; this.originalRequest = originalRequest; this.forWebSocket = forWebSocket; this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket); ``` 找到了初始化的位置, 下面去`RetryAndFollowUpInterceptor`种分析! ### RetryAndFollowUpInterceptor解析 从上节我们就知道拦截器中的**intercept()是核心!** 这里贴出代码: ``` @Override public Response intercept(Chain chain) throws IOException Request request = chain.request(); RealInterceptorChain realChain = (RealInterceptorChain) chain; Call call = realChain.call(); EventListener eventListener = realChain.eventListener(); StreamAllocation streamAllocation = new StreamAllocation(client.connectionPool(), createAddress(request.url()), call, eventListener, callStackTrace); this.streamAllocation = streamAllocation; int followUpCount = 0; Response priorResponse = null; while (true) if (canceled) streamAllocation.release(); throw new IOException("Canceled"); Response response; boolean releaseConnection = true; try response = realChain.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(), streamAllocation, false, request)) throw e.getFirstConnectException(); 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, streamAllocation, requestSendStarted, request)) throw e; releaseConnection = false; continue; finally // We‘re throwing an unchecked exception. Release any resources. if (releaseConnection) streamAllocation.streamFailed(null); streamAllocation.release(); // Attach the prior response if it exists. Such responses never have a body. if (priorResponse != null) response = response.newBuilder() .priorResponse(priorResponse.newBuilder() .body(null) .build()) .build(); Request followUp; try followUp = followUpRequest(response, streamAllocation.route()); catch (IOException e) streamAllocation.release(); throw e; if (followUp == null) if (!forWebSocket) streamAllocation.release(); return response; closeQuietly(response.body()); 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()); 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?"); request = followUp; priorResponse = response; ``` 我先贴出一个`while循环`的流程图: ![](https://img2018.cnblogs.com/blog/1312938/201908/1312938-20190829084745296-805720763.png) 根据流程图和源码可以分析`RetryAndFollowUpInterceptor`主要做了以下内容,**后两点都是发生在`while循环`中**: - **初始化StreamAllocation 对象** - **网络请求-chain.proceed() ,对在请求时发生的异常进行捕获以及对应的重连机制** - **followUpRequest 对响应码进行处理** 下面可以逐块代码分析: ###### 1.初始化StreamAllocation 对象 `StreamAllocation`类是**协调三个实体之间的关系** 三个实体是:`Connections`,`Streams`,`Calls` 我们请求网络时需要传递它 ![](https://img2018.cnblogs.com/blog/1312938/201908/1312938-20190829084745679-501952792.png) `StreamAllocation`在这大家简单了解一下就可以了. ###### 2.网络请求时异常捕获-以及重连机制 网络请求如下: ``` response = realChain.proceed(request, streamAllocation, null, null); ``` 如果请求发现异常,我们通过try/catch捕获 ``` catch (RouteException e) // The attempt to connect via a route failed. The request will not have been sent. if (!recover(e.getLastConnectException(), streamAllocation, false, request)) throw e.getFirstConnectException(); 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, streamAllocation, requestSendStarted, request)) throw e; releaseConnection = false; continue; ``` -`RouteException` 路由异常 - `IOException` IO异常 捕获后都做了`recover()`重连判断,具体代码如下,就不细说了: ``` private boolean recover(IOException e, StreamAllocation streamAllocation, boolean requestSendStarted, Request userRequest) streamAllocation.streamFailed(e); // The application layer has forbidden retries. if (!client.retryOnConnectionFailure()) return false; // We can‘t send the request body again. if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody) return false; // This exception is fatal. if (!isRecoverable(e, requestSendStarted)) return false; // No more routes to attempt. if (!streamAllocation.hasMoreRoutes()) return false; // For failure recovery, use the same route selector with a new connection. return true; ``` 这里需要注意的是如果可以重连,执行 continue; `continue`含义: 继续循环,(不执行 循环体内`continue` 后面的语句,直接进行下一循环) ###### 3.` followUpRequest` 对响应码进行处理 先看看具体`followUpRequest `方法: ``` private Request followUpRequest(Response userResponse, Route route) throws IOException if (userResponse == null) throw new IllegalStateException(); int responseCode = userResponse.code(); final String method = userResponse.request().method(); switch (responseCode) 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); case HTTP_UNAUTHORIZED: return client.authenticator().authenticate(route, userResponse); case HTTP_PERM_REDIRECT: case HTTP_TEMP_REDIRECT: // "If the 307 or 308 status code is received in response to a request other than GET // or HEAD, the user agent MUST NOT automatically redirect the request" if (!method.equals("GET") && !method.equals("HEAD")) return null; // fall-through case HTTP_MULT_CHOICE: case HTTP_MOVED_PERM: case HTTP_MOVED_TEMP: case HTTP_SEE_OTHER: // Does the client allow redirects? if (!client.followRedirects()) return null; String location = userResponse.header("Location"); if (location == null) return null; HttpUrl url = userResponse.request().url().resolve(location); // Don‘t follow redirects to unsupported protocols. if (url == null) return null; // If configured, don‘t follow redirects between SSL and non-SSL. boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme()); if (!sameScheme && !client.followSslRedirects()) return null; // Most redirects don‘t include a request body. Request.Builder requestBuilder = userResponse.request().newBuilder(); if (HttpMethod.permitsRequestBody(method)) final boolean maintainBody = HttpMethod.redirectsWithBody(method); if (HttpMethod.redirectsToGet(method)) requestBuilder.method("GET", null); else RequestBody requestBody = maintainBody ? userResponse.request().body() : null; requestBuilder.method(method, requestBody); if (!maintainBody) requestBuilder.removeHeader("Transfer-Encoding"); requestBuilder.removeHeader("Content-Length"); requestBuilder.removeHeader("Content-Type"); // When redirecting across hosts, drop all authentication headers. This // is potentially annoying to the application layer since they have no // way to retain them. if (!sameConnection(userResponse, url)) requestBuilder.removeHeader("Authorization"); return requestBuilder.url(url).build(); case HTTP_CLIENT_TIMEOUT: // 408‘s are rare in practice, but some servers like HAProxy use this response code. The // spec says that we may repeat the request without modifications. Modern browsers also // repeat the request (even non-idempotent ones.) if (!client.retryOnConnectionFailure()) // The application layer has directed us not to retry the request. return null; if (userResponse.request().body() instanceof UnrepeatableRequestBody) return null; if (userResponse.priorResponse() != null && userResponse.priorResponse().code() == HTTP_CLIENT_TIMEOUT) // We attempted to retry and got another timeout. Give up. return null; if (retryAfter(userResponse, 0) > 0) return null; return userResponse.request(); case HTTP_UNAVAILABLE: if (userResponse.priorResponse() != null && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) // We attempted to retry and got another timeout. Give up. return null; if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) // specifically received an instruction to retry without delay return userResponse.request(); return null; default: return null; ``` 不难看出, 是根据响应码进行判断的。 - HTTP_PROXY_AUTH 407 代理身份验证 - HTTP_UNAUTHORIZED 401 未授权 - HTTP_PERM_REDIRECT 308 重定向 - HTTP_TEMP_REDIRECT 307 重定向 - HTTP_MULT_CHOICE 300 Multiple Choices - HTTP_MOVED_PERM 301 Moved Permanently - HTTP_MOVED_TEMP 302 Temporary Redirect - HTTP_SEE_OTHER 303 See Other - HTTP_CLIENT_TIMEOUT 408 Request Time-Out - HTTP_UNAVAILABLE 503 Service Unavailable 对于这些响应码都做了处理: 1.返回null ``` if (followUp == null) if (!forWebSocket) streamAllocation.release(); return response; ``` 2.其他异常情况直接抛异常了 强调: `MAX_FOLLOW_UPS`字段, 表示最大的重定向次数 ``` /** * How many redirects and auth challenges should we attempt? Chrome follows 21 redirects; Firefox, * curl, and wget follow 20; Safari follows 16; and HTTP/1.0 recommends 5. */ private static final int MAX_FOLLOW_UPS = 20; ``` ``` if (++followUpCount > MAX_FOLLOW_UPS) streamAllocation.release(); throw new ProtocolException("Too many follow-up requests: " + followUpCount); ``` 这节就说到这,希望对大家有所帮助..... ![](https://img2018.cnblogs.com/blog/1312938/201908/1312938-20190829084746645-654895211.png) 大家可以关注我的微信公众号:「秦子帅」一个有质量、有态度的公众号! ![公众号](https://img2018.cnblogs.com/blog/1312938/201908/1312938-20190829084746832-730035128.jpg)

以上是关于Okhttp3源码解析-拦截器RetryAndFollowUpInterceptor的主要内容,如果未能解决你的问题,请参考以下文章

OkHttp3 源码分析

OkHttp3 源码分析

OkHttp3 源码分析

OkHttp-RetryAndFollowUpInterceptor源码解析

OkHttp-CallServerInterceptor源码解析

OkHttp-CallServerInterceptor源码解析