okhttp源码解析(四):重试机制

前言

这一篇我们分析okhttp的重试机制,一般如果网络请求失败,我们会考虑连续请求多次,增大网络请求成功的概率,那么okhttp是怎么实现这个功能的呢?

正文

首先还是回到之前的InterceptorChain:

Response getResponseWithInterceptorChain() throws IOException {
    // Build a full stack of interceptors.
    List interceptors = new ArrayList<>();
    interceptors.addAll(client.interceptors());

    // 重试的Interceptor,在构造方法中创建
    interceptors.add(retryAndFollowUpInterceptor);

    // 其他的interceptor
    ...
    return chain.proceed(originalRequest);
  }

其中的RetryAndFollowUpInterceptor是负责重试的Interceptor,他处于责任链的顶端,负责网络请求的开始工作,也负责收尾的工作。

他的创建是在RealCall.java构造方法中:

private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
    this.client = client;
    this.originalRequest = originalRequest;
    this.forWebSocket = forWebSocket;
    this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);
  }

创建的时机就是我们调用OkhttpClient的newCall方法,每一次发起网络请求,我们都需要调用:

@Override public Call newCall(Request request) {
    return RealCall.newRealCall(this, request, false /* for web socket */);
  }

了解了他的创建过程,我们接着分析RetryAndFollowUpInterceptor的工作过程:

Request request = chain.request();
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Call call = realChain.call();
// 我们设置的eventListener回调
EventListener eventListener = realChain.eventListener();
// 从参数上看,可以推测StreamAllocation中保存了此次网络请求的信息
// 连接池(),地址,网络请求,eventListenenr
StreamAllocation streamAllocation = new StreamAllocation(client.connectionPool(),
                createAddress(request.url()), call, eventListener, callStackTrace);
this.streamAllocation = streamAllocation;

一开始,创建了StreamAllocation对象,他封装了网络请求相关的信息:连接池,地址信息,网络请求,事件回调,负责网络连接的连接、关闭,释放等操作。callStackTrace是一个Throwable对象,他主要是记录运行中异常信息,帮助我们识别网络请求的来源。

之后就进入到网络连接的循环,代码稍微有点长:

// 计数器
        int followUpCount = 0;
        Response priorResponse = null;
        // 开始进入while循环
        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.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, 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.
            // 如果不为空,保存到response中
            if (priorResponse != null) {
                response = response.newBuilder()
                        .priorResponse(priorResponse.newBuilder()
                                .body(null)
                                .build())
                        .build();
            }

            Request followUp;
            try {
                // 判断返回结果response,是否需要继续完善请求,例如证书验证等等
                followUp = followUpRequest(response, streamAllocation.route());
            } catch (IOException e) {
                streamAllocation.release();
                throw e;
            }
            // 如果不需要继续完善网络请求,返回response
            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);
            }
            // 如果body内容只能发送一次,释放连接
            if (followUp.body() instanceof UnrepeatableRequestBody) {
                streamAllocation.release();
                throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
            }
            // 如果返回response的URL地址和追加请求的url地址不一致
            if (!sameConnection(response, followUp.url())) {
                // 释放之前你的url地址连接
                streamAllocation.release();
                // 创建新的网络请求封装对象StreamAllocation
                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;
        }

followUpCount是用来记录我们发起网络请求的次数的,为什么我们发起一个网络请求,可能okhttp会发起多次呢?例如https的证书验证,我们需要经过:发起 -> 验证 -> 响应,三个步骤需要发起至少两次的请求,或者我们的网络请求被重定向,在我们第一次请求得到了新的地址后,再向新的地址发起网络请求。

但是多次相应的次数是有限制的,我们看一下okhttp的注释是怎么解释的:

/**
     * 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.
     */

不同的浏览器推荐的次数是不同的,还特别强调了HTTP 1.0协议推荐5次。不过我们一般也不会设置这么多次,这会导致网络请求的效率很低。

在网络请求中,不同的异常,重试的次数也不同,okhttp捕获了两种异常:RouteException和IOException。

RouteException:所有网络连接失败的异常,包括IOException中的连接失败异常;

IOException:除去连接异常的其他的IO异常。

这个时候我们需要判断是否需要重试:

private boolean recover(IOException e, StreamAllocation streamAllocation,
                            boolean requestSendStarted, Request userRequest) {
        streamAllocation.streamFailed(e);

        // The application layer has forbidden retries.
        // 如果设置了不需要重试,直接返回false
        if (!client.retryOnConnectionFailure()) return false;

        // We can't send the request body again.
        // 如果网络请求已经开始,并且body内容只可以发送一次
        if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody)
            return false;

        // This exception is fatal.
        // 判断异常类型,是否要继续尝试,
        // 不会重试的类型:协议异常、Socketet异常并且网络情况还没开始,ssl认证异常
        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.
        // 其他情况返回true
        return true;
}

其中的路由地址我们先忽略,这个之后我们还会讨论。假定没有其他路由地址的情况下:

1、连接失败,并不会重试;

2、如果连接成功,因为特定的IO异常(例如认证失败),也不会重试

其实这两种情况是可以理解的,如果连接异常,例如无网络状态,重试也只是毫秒级的任务,不会有特别明显的效果,如果是网络很慢,到了超时时间,应该让用户及时了解失败的原因,如果一味重试,用户就会等待多倍的超时时间,用户体验并不好。认证失败的情况就更不用多说了。

如果我们非要重试多次怎么办?

自定义Interceptor,增加计数器,重试到你满意就可以了:

/**
 * 重试拦截器
 */
public class RetryInterceptor implements Interceptor {

    /**
    * 最大重试次数
    */ 
    private int maxRetry;

    RetryInterceptor(int maxRetry) {
        this.maxRetry = maxRetry;
    }

    @Override
    public Response intercept(@NonNull Chain chain) throws IOException {
        Request request = chain.request();
        Response response = null;
        int count = 0;
        while (count < maxRetry) {
            try {
                //发起网络请求
                response = chain.proceed(request);
                // 得到结果跳出循环
                break;
            } catch (Exception e) {
                count ++;
                response = null;
            }
        }
        if(response == null){
            throw Exception
        }
        return response;
    }

}

这是一份伪代码,具体的逻辑大家可以自行完善。

总结

到这里okhttp的重试机制就分析结束了,我们发现只有在特定情况下,okhttp才会重试,如果想要自定义重试机制,可以设置Intercptor来解决这个问题。

接下来我们了解和研究一下okhttp的Dns。

你可能感兴趣的:(okhttp源码解析(四):重试机制)