关于OkHttp(三)
2019-02-23 本文已影响0人
MY1112
前文 我们主要介绍了CallServerInterceptor和ConnectInterceptor，这里我们主要来聊聊CacheInterceptor、BridgeInterceptor和RetryAndFollowUpInterceptor.
CacheInterceptor
我们还是来看看其 intercept(Chain chain)方法：
@Override public Response intercept(Chain chain) throws IOException {
//cache 是OkHttpClient持有的，初始化CacheInterceptor时传进来，cache作为一个缓存候选项
Response cacheCandidate = cache != null
? cache.get(chain.request())
: null;
long now = System.currentTimeMillis();
// 把缓存候选项cache传到缓存策略类(CacheStrategy)里，进行一次"转化"，形成正在的缓存策略
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
//分别从缓存策略(CacheStrategy)里拿出网络请求(networkRequest)和缓存(cacheResponse )
Request networkRequest = strategy.networkRequest;
Response cacheResponse = strategy.cacheResponse;
if (cache != null) {
cache.trackResponse(strategy);
}
// 如果缓存候选者(cacheCandidate )！=null但是缓存策略不使用缓存，就说明缓存候选
// 者(cacheCandidate)已经失效了，关闭它
if (cacheCandidate != null && cacheResponse == null) {
closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
}
// If we're forbidden from using the network and the cache is insufficient, fail.
// 如果网络请求为null且缓存Response为null时，就新建一个504的Response直接返回
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();
}
// If we don't need the network, we're done.
// 如果networkRequest ==null，但是cacheResponse ！=null，就把这个cacheResponse 返回。
if (networkRequest == null) {
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
Response networkResponse = null;
try {
// 如果网络请求(networkRequest)不为null，那就执行到下个拦截器，以获取网络相应数据
networkResponse = chain.proceed(networkRequest);
} finally {
// If we're crashing on I/O or otherwise, don't leak the cache body.
// 如果出异常了，我们要关闭cache以防止泄露
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) {
// 如果网络响应状态是304(304代表客户端缓存还可以用的意思)，那就让缓存继续生效，网络响应也保留
if (networkResponse.code() == HTTP_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 = 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;
}
我们大致总结一下缓存拦截的基本流程：
- 如果在初始化OkhttpClient的时候配置缓存，则从缓存中取caceResponse 作为候选缓存；
- 将当前请求request和caceResponse 构建缓存策略（根据头信息，判断强制缓存，对比缓存等策略)；
- 候选缓存有效但是策划缓存无效时，就让候选缓存也关闭使其无效；
- 根据策略，如果策略request和策略caceResponse都为空，直接返回一个状态码为504，且body为Util.EMPTY_RESPONSE的空Respone对象
- 根据策略，如果策略request为空(就是不用网络)，有缓存就直接返回策略缓存；
- 前面个都没有返回，读取网络结果（跑下一个拦截器）；
- 接收到的网络结果，如果是code 304, 使用缓存，返回缓存结果（对比缓存）
- 读取网络结果；
- 对数据进行缓存；
- 返回网络读取的结果。
其实这里面还有很多细节的东西可以分析，这里只是大致看了一下缓存拦截的流程，后续有时间我再补上更多细节吧！
另外，推荐一篇关于Http缓存的文章http://www.cnblogs.com/chenqf/p/6386163.html
BridgeInterceptor
这个拦截器是比较简单的，只是处理请求头（header），将自定义的头和协议必需的头合在一起，如果有自定义使用自定义的，没有就生成默认头，如果你对Http头信息认知比较充分(不熟的可以去看看这个文章https://www.cnblogs.com/jiangxiaobo/p/5499488.html)，那非常容易理解这个类。其中里面相对复杂点的有2个，一个是Cookie的处理，一个是Gzip的处理。看一下主要方法intercept(Chain chain)
@Override public Response intercept(Chain chain) throws IOException {
Request userRequest = chain.request();
Request.Builder requestBuilder = userRequest.newBuilder();
RequestBody body = userRequest.body();
if (body != null) {
MediaType contentType = body.contentType();
if (contentType != null) {
requestBuilder.header("Content-Type", contentType.toString());
}
long contentLength = body.contentLength();
if (contentLength != -1) {
requestBuilder.header("Content-Length", Long.toString(contentLength));
requestBuilder.removeHeader("Transfer-Encoding");
} else {
requestBuilder.header("Transfer-Encoding", "chunked");
requestBuilder.removeHeader("Content-Length");
}
}
if (userRequest.header("Host") == null) {
requestBuilder.header("Host", hostHeader(userRequest.url(), false));
}
// 这个头信息必须要，使用者不设置，默认是保持连接的 Keep-Alive
if (userRequest.header("Connection") == null) {
requestBuilder.header("Connection", "Keep-Alive");
}
// If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing
// the transfer stream.
// Accept-Encoding ： 就是告诉服务器客户端能够接受的数据编码类型，OKHTTP 默认就是 GZIP 类型。
boolean transparentGzip = false;
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
transparentGzip = true;
requestBuilder.header("Accept-Encoding", "gzip");
}
// 创建OkHttpClient时候配置的cookieJar，
List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
if (!cookies.isEmpty()) {
requestBuilder.header("Cookie", cookieHeader(cookies));
}
if (userRequest.header("User-Agent") == null) {
requestBuilder.header("User-Agent", Version.userAgent());
}
// 上面是处理请求头信息
Response networkResponse = chain.proceed(requestBuilder.build());
// 下面是处理响应头信息
// 接受服务器返回的 Cookie，如果初始化时传入的Cookie是CookieJar.NO_COOKIES，那就意味着不接受任何
// Cookie，否则就会从把networkResponse.headers()里的Cookie信息保存下来
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
// 当服务器返回的数据是 GZIP 压缩的，那么客户端就进行解压操作
if (transparentGzip
&& "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
&& HttpHeaders.hasBody(networkResponse)) {
GzipSource responseBody = new GzipSource(networkResponse.body().source());
Headers strippedHeaders = networkResponse.headers().newBuilder()
.removeAll("Content-Encoding")
.removeAll("Content-Length")
.build();
responseBuilder.headers(strippedHeaders);
String contentType = networkResponse.header("Content-Type");
responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
}
return responseBuilder.build();
}
RetryAndFollowUpInterceptor
最后我们来聊聊RetryAndFollowUpInterceptor。官方对其是这样描述的：
This interceptor recovers from failures and follows redirects as necessary.
就是说这个拦截器在必要时可以将失败的请求恢复并重定向继续请求。如果你想很轻松的看懂里面的源码，最好先熟悉Http请求响应返回的Status Code。下面我来看看这个Interceptor的核心代码，即方法intercept(Chain chain)：
@Override
public Response intercept(Chain chain) throws IOException {
// 拿到Request
Request request = chain.request();
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Call call = realChain.call();
EventListener eventListener = realChain.eventListener();
// 第一次实例化StreamAllocation对象(这个类里主要做连接功能)，后面会依次把这个对象传递到后续的
// Interceptor
StreamAllocation streamAllocation = new StreamAllocation(client.connectionPool(),
createAddress(request.url()), call, eventListener, callStackTrace);
this.streamAllocation = streamAllocation;
int followUpCount = 0;
Response priorResponse = null;
// 无限循环，直到得到合适的Response
while (true) {
// 如果取消网络请求，就释放连接
if (canceled) {
streamAllocation.release(true);
throw new IOException("Canceled");
}
Response response;
boolean releaseConnection = true;
try {
// 往下递归传递网络请求，得到Response
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.
// RouteException是OkHttp自定义的异常类，包括建立连接时的各种异常情况，这个异常发生在
// Request发出去之前，也就是打开Socket失败，一般都是在ConnectInterceptor里。如果
// RouteException，尝试恢复，如果恢复失败throw一个Exception，否则continue当前循环，进入下一次
// 循环，此时 streamAllocation仍有效，在下一次循环时可用
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.
// 这个异常发生在 Request 请求发出并且读取 Response 响应的过程中，TCP 已经连接，或者 TLS 已
// 经成功握手后，连接资源准备完毕。主要发生在 CallServerInterceptor 中，通过建立好的通道，发送
// 请求并且读取响应的环节，如果恢复失败就throw e，否则continue，进入下一次循环，此时
// streamAllocation仍有效，在下一次循环时可用
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.
// 如果抛出了其他的exception，就直接回收连接
if (releaseConnection) {
streamAllocation.streamFailed(null);
streamAllocation.release(true);
}
}
// 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，至于如何构建和什么时候构建后续会说明
Request followUp;
try {
followUp = followUpRequest(response, streamAllocation.route());
} catch (IOException e) {
streamAllocation.release(true);
throw e;
}
// 如果重试的Request是空，那就释放连接，返回response
if (followUp == null) {
streamAllocation.release(true);
return response;
}
//如果重试的Request存在，那就把response关闭
closeQuietly(response.body());
// 超过最大重试次数，释放连接，抛出异常停止循环
if (++followUpCount > MAX_FOLLOW_UPS) {
streamAllocation.release(true);
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
// 请求已破坏掉，释放连接，抛出异常停止循环
if (followUp.body() instanceof UnrepeatableRequestBody) {
streamAllocation.release(true);
throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
}
// 如果响应的URL和请求相同就复用，否则释放连接(streamAllocation)，然后重建连接
if (!sameConnection(response, followUp.url())) {
streamAllocation.release(false);
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;
}
}
再来看看recover(...)方法：
/**
* Report and attempt to recover from a failure to communicate with a server. Returns true if
* {@code e} is recoverable, or false if the failure is permanent. Requests with a body can only
* be recovered if the body is buffered or if the failure occurred before the request has been
* sent.
*/
private boolean recover(IOException e, StreamAllocation streamAllocation,
boolean requestSendStarted, Request userRequest) {
// 该方法可以将这个失败的 route 记录下来，放到黑名单，进入黑名单的Route就会最后才被使用到，这样
// 命中正确的Route效率就会高。
streamAllocation.streamFailed(e);
// The application layer has forbidden retries.
// 用户设置不可重试就返回false
if (!client.retryOnConnectionFailure()) return false;
// We can't send the request body again.
// 请求不可重复(408时body是UnrepeatableRequestBody或者异常是FileNotFoundException时就不可重复)
if (requestSendStarted && requestIsUnrepeatable(e, userRequest)) return false;
// This exception is fatal.
// 不可恢复异常
if (!isRecoverable(e, requestSendStarted)) return false;
// No more routes to attempt.
// 没有更多的route
if (!streamAllocation.hasMoreRoutes()) return false;
// For failure recovery, use the same route selector with a new connection.
return true;
}
这个方法主要是判断连接(streamAllocation)是否可以恢复，可恢复意味着可以重连，如果可以恢复就返回true，否则返回false。其中用到了isRecoverable(...)方法，这个方法主要是处理不可恢复异常情况。
private boolean isRecoverable(IOException e, boolean requestSendStarted) {
// If there was a protocol problem, don't recover.
if (e instanceof ProtocolException) {
return false;
}
// If there was an interruption don't recover, but if there was a timeout connecting to a route
// we should try the next route (if there is one).
if (e instanceof InterruptedIOException) {
return e instanceof SocketTimeoutException && !requestSendStarted;
}
// Look for known client-side or negotiation errors that are unlikely to be fixed by trying
// again with a different route.
if (e instanceof SSLHandshakeException) {
// If the problem was a CertificateException from the X509TrustManager,
// do not retry.
if (e.getCause() instanceof CertificateException) {
return false;
}
}
if (e instanceof SSLPeerUnverifiedException) {
// e.g. a certificate pinning error.
return false;
}
// An example of one we might want to retry with a different route is a problem connecting to a
// proxy and would manifest as a standard IOException. Unless it is one we know we should not
// retry, we return true and try a new route.
return true;
}
从上面这个方法就可以看到，发生以下异常时，连接不可恢复：
- ProtocolException，这个异常在RealConnection 中创建 HTTPS 通过 HTTP 代理进行连接重试超过 21 次时会发生。
- InterruptedIOException
- CertificateException 引起的 SSLHandshakeException
- SSLPeerUnverifiedException
再来看看followUpRequest(...)方法：
/**
* Figures out the HTTP request to make in response to receiving {@code userResponse}. This will
* either add authentication headers, follow redirects or handle a client request timeout. If a
* follow-up is either unnecessary or not applicable, this returns null.
*/
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;
// 从头部信息里面 获取 Location 新的链接
String location = userResponse.header("Location");
if (location == null) return null;
// 生成一个新的 HttpUrl
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;
}
}
这个方法主要是获取重定向Request。
- 307和308时，如果不是 GET 或者 HEAD 请求不进行重定向；
- 300，301，302，303都重定向；
- 401会重定向；
- 407时且Proxy.Type.HTTP会重定向；
大体流程：
- 从响应中获取 “Location”
- 跳转到不支持协议不能重定向
- HTTPS 和 HTTP 之间的重定向，需要根据配置 followSslRedirects 来判断
- 去掉请求体，并响应地去掉 “Transfer-Encoding”，“Content-Length”，“Content-Type” 等头部信息
- 如果不是同一个连接（比如 host 不同），去掉授权头部 “Authorization”
