简介

okhttp的网络请求采用interceptors链的模式。每一级interceptor只处理自己的工作，然后将剩余的工作，交给下一级interceptor。本文将主要阅读okhttp中的RetryAndFollowUpInterceptor，了解它的作用和工作原理。

RetryAndFollowUpInterceptor

顾名思义，RetryAndFollowUpInterceptor负责okhttp的请求失败的恢复和重定向。

核心的intercept方法分两段阅读：

  1. @Override public Response intercept(Chain chain) throws IOException {
  2.     Request request = chain.request();
  3.     RealInterceptorChain realChain = (RealInterceptorChain) chain;
  4.     Transmitter transmitter = realChain.transmitter();
  6.     int followUpCount = 0;
  7.     Response priorResponse = null;
  8.     while (true) {
  9.       transmitter.prepareToConnect(request);
  11.       if (transmitter.isCanceled()) {
  12.         throw new IOException("Canceled");
  13.       }
  15.       Response response;
  16.       boolean success = false;
  17.       try {
  18.         response = realChain.proceed(request, transmitter, null);
  19.         success = true;
  20.       } catch (RouteException e) {
  21.         // The attempt to connect via a route failed. The request will not have been sent.
  22.         if (!recover(e.getLastConnectException(), transmitter, false, request)) {
  23.           throw e.getFirstConnectException();
  24.         }
  25.         continue;
  26.       } catch (IOException e) {
  27.         // An attempt to communicate with a server failed. The request may have been sent.
  28.         boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
  29.         if (!recover(e, transmitter, requestSendStarted, request)) throw e;
  30.         continue;
  31.       } finally {
  32.         // The network call threw an exception. Release any resources.
  33.         if (!success) {
  34.           transmitter.exchangeDoneDueToException();
  35.         }
  36.       }
  37.       ...
  38.     }
  39.   }

前半段的逻辑中，RetryAndFollowUpInterceptor做了几件事：

  • 通过Transmitter准备连接
  • 执行请求链下一级
  • 处理了下一级请求链中的RouteException和IOException。

Transmitter的实现，以后的章节再单独讲解。此处略过。我们重点看一下，RetryAndFollowUpInterceptor如何处理两个异常。

RouteException

从注释中，我们可以看到，RouteException表示客户端连接路由失败。此时会调用recover方法，如果recover方法再失败，会抛出RouteException中的FirstConnectException。

我们看一下recover方法的实现：

  1. /**
  2.    * Report and attempt to recover from a failure to communicate with a server. Returns true if
  3.    * {@code e} is recoverable, or false if the failure is permanent. Requests with a body can only
  4.    * be recovered if the body is buffered or if the failure occurred before the request has been
  5.    * sent.
  6.    */
  7.   private boolean recover(IOException e, Transmitter transmitter,
  8.       boolean requestSendStarted, Request userRequest) {
  9.     // The application layer has forbidden retries.
  10.     if (!client.retryOnConnectionFailure()) return false;
  12.     // We can't send the request body again.
  13.     if (requestSendStarted && requestIsOneShot(e, userRequest)) return false;
  15.     // This exception is fatal.
  16.     if (!isRecoverable(e, requestSendStarted)) return false;
  18.     // No more routes to attempt.
  19.     if (!transmitter.canRetry()) return false;
  21.     // For failure recovery, use the same route selector with a new connection.
  22.     return true;
  23.   }

首先我们调用应用层的失败回调，如果应用层返回false，就不再进行重试。

然后，我们判断请求的返回，如果请求已经开始或请求限定，只能请求一次，我们也不再进行重试。其中，只能请求一次，可能是客户端自行设定的，也可能是请求返回了404。明确告知了文件不存在，也不会再重复请求。

接下来，是okhttp认为的致命错误，不会再重复请求的，都会在isRecoverable方法中。致命错误包括：协议错误、SSL校验错误等。

  1. private boolean isRecoverable(IOException e, boolean requestSendStarted) {
  2.     // If there was a protocol problem, don't recover.
  3.     if (e instanceof ProtocolException) {
  4.       return false;
  5.     }
  7.     // If there was an interruption don't recover, but if there was a timeout connecting to a route
  8.     // we should try the next route (if there is one).
  9.     if (e instanceof InterruptedIOException) {
  10.       return e instanceof SocketTimeoutException && !requestSendStarted;
  11.     }
  13.     // Look for known client-side or negotiation errors that are unlikely to be fixed by trying
  14.     // again with a different route.
  15.     if (e instanceof SSLHandshakeException) {
  16.       // If the problem was a CertificateException from the X509TrustManager,
  17.       // do not retry.
  18.       if (e.getCause() instanceof CertificateException) {
  19.         return false;
  20.       }
  21.     }
  22.     if (e instanceof SSLPeerUnverifiedException) {
  23.       // e.g. a certificate pinning error.
  24.       return false;
  25.     }
  27.     // An example of one we might want to retry with a different route is a problem connecting to a
  28.     // proxy and would manifest as a standard IOException. Unless it is one we know we should not
  29.     // retry, we return true and try a new route.
  30.     return true;
  31.   }

最后，在底层中寻找是否还有其他的Router可以尝试。

IOException

IOException表示连接已经建立，但读取内容时失败了。我们同样会进行recover尝试，由于代码逻辑一样，不再重复阅读。

在finally中，Transmitter会释放所有资源。

followUpRequest

接下来，我们看一下RetryAndFollowUpInterceptor中intercept后半段的实现：

  1. @Override public Response intercept(Chain chain) throws IOException {
  2.     Request request = chain.request();
  3.     RealInterceptorChain realChain = (RealInterceptorChain) chain;
  4.     Transmitter transmitter = realChain.transmitter();
  6.     int followUpCount = 0;
  7.     Response priorResponse = null;
  8.     while (true) {
  9.      ...
  11.       // Attach the prior response if it exists. Such responses never have a body.
  12.       if (priorResponse != null) {
  13.         response = response.newBuilder()
  14.             .priorResponse(priorResponse.newBuilder()
  15.                     .body(null)
  16.                     .build())
  17.             .build();
  18.       }
  20.       Exchange exchange = Internal.instance.exchange(response);
  21.       Route route = exchange != null ? exchange.connection().route() : null;
  22.       Request followUp = followUpRequest(response, route);
  24.       if (followUp == null) {
  25.         if (exchange != null && exchange.isDuplex()) {
  26.           transmitter.timeoutEarlyExit();
  27.         }
  28.         return response;
  29.       }
  31.       RequestBody followUpBody = followUp.body();
  32.       if (followUpBody != null && followUpBody.isOneShot()) {
  33.         return response;
  34.       }
  36.       closeQuietly(response.body());
  37.       if (transmitter.hasExchange()) {
  38.         exchange.detachWithViolence();
  39.       }
  41.       if (++followUpCount > MAX_FOLLOW_UPS) {
  42.         throw new ProtocolException("Too many follow-up requests: " + followUpCount);
  43.       }
  45.       request = followUp;
  46.       priorResponse = response;
  47.     }
  48.   }

我们拆开来看这段复杂的逻辑。大体上来说，这段逻辑主要是通过上次请求的返回，生成followUp。然后根据followUp的内容，判断是不是有效的返回。如果返回是有效的，就直接return请求的返回。如果返回无效，则request=followUp，重走while循环，重新请求。

所以这一段的核心逻辑在于followUpRequest方法。我们来看下followUpRequest的实现。

  1. /**
  2.    * Figures out the HTTP request to make in response to receiving {@code userResponse}. This will
  3.    * either add authentication headers, follow redirects or handle a client request timeout. If a
  4.    * follow-up is either unnecessary or not applicable, this returns null.
  5.    */
  6.   private Request followUpRequest(Response userResponse, @Nullable Route route) throws IOException {
  7.     if (userResponse == null) throw new IllegalStateException();
  8.     int responseCode = userResponse.code();
  10.     final String method = userResponse.request().method();
  11.     switch (responseCode) {
  12.       case HTTP_PROXY_AUTH:
  13.         Proxy selectedProxy = route != null
  14.             ? route.proxy()
  15.             : client.proxy();
  16.         if (selectedProxy.type() != Proxy.Type.HTTP) {
  17.           throw new ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy");
  18.         }
  19.         return client.proxyAuthenticator().authenticate(route, userResponse);
  21.       case HTTP_UNAUTHORIZED:
  22.         return client.authenticator().authenticate(route, userResponse);
  24.       case HTTP_PERM_REDIRECT:
  25.       case HTTP_TEMP_REDIRECT:
  26.         // "If the 307 or 308 status code is received in response to a request other than GET
  27.         // or HEAD, the user agent MUST NOT automatically redirect the request"
  28.         if (!method.equals("GET") && !method.equals("HEAD")) {
  29.           return null;
  30.         }
  31.         // fall-through
  32.       case HTTP_MULT_CHOICE:
  33.       case HTTP_MOVED_PERM:
  34.       case HTTP_MOVED_TEMP:
  35.       case HTTP_SEE_OTHER:
  36.         // Does the client allow redirects?
  37.         if (!client.followRedirects()) return null;
  39.         String location = userResponse.header("Location");
  40.         if (location == null) return null;
  41.         HttpUrl url = userResponse.request().url().resolve(location);
  43.         // Don't follow redirects to unsupported protocols.
  44.         if (url == null) return null;
  46.         // If configured, don't follow redirects between SSL and non-SSL.
  47.         boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
  48.         if (!sameScheme && !client.followSslRedirects()) return null;
  50.         // Most redirects don't include a request body.
  51.         Request.Builder requestBuilder = userResponse.request().newBuilder();
  52.         if (HttpMethod.permitsRequestBody(method)) {
  53.           final boolean maintainBody = HttpMethod.redirectsWithBody(method);
  54.           if (HttpMethod.redirectsToGet(method)) {
  55.             requestBuilder.method("GET", null);
  56.           } else {
  57.             RequestBody requestBody = maintainBody ? userResponse.request().body() : null;
  58.             requestBuilder.method(method, requestBody);
  59.           }
  60.           if (!maintainBody) {
  61.             requestBuilder.removeHeader("Transfer-Encoding");
  62.             requestBuilder.removeHeader("Content-Length");
  63.             requestBuilder.removeHeader("Content-Type");
  64.           }
  65.         }
  67.         // When redirecting across hosts, drop all authentication headers. This
  68.         // is potentially annoying to the application layer since they have no
  69.         // way to retain them.
  70.         if (!sameConnection(userResponse.request().url(), url)) {
  71.           requestBuilder.removeHeader("Authorization");
  72.         }
  74.         return requestBuilder.url(url).build();
  76.       case HTTP_CLIENT_TIMEOUT:
  77.         // 408's are rare in practice, but some servers like HAProxy use this response code. The
  78.         // spec says that we may repeat the request without modifications. Modern browsers also
  79.         // repeat the request (even non-idempotent ones.)
  80.         if (!client.retryOnConnectionFailure()) {
  81.           // The application layer has directed us not to retry the request.
  82.           return null;
  83.         }
  85.         RequestBody requestBody = userResponse.request().body();
  86.         if (requestBody != null && requestBody.isOneShot()) {
  87.           return null;
  88.         }
  90.         if (userResponse.priorResponse() != null
  91.             && userResponse.priorResponse().code() == HTTP_CLIENT_TIMEOUT) {
  92.           // We attempted to retry and got another timeout. Give up.
  93.           return null;
  94.         }
  96.         if (retryAfter(userResponse, 0) > 0) {
  97.           return null;
  98.         }
  100.         return userResponse.request();
  102.       case HTTP_UNAVAILABLE:
  103.         if (userResponse.priorResponse() != null
  104.             && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) {
  105.           // We attempted to retry and got another timeout. Give up.
  106.           return null;
  107.         }
  109.         if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
  110.           // specifically received an instruction to retry without delay
  111.           return userResponse.request();
  112.         }
  114.         return null;
  116.       default:
  117.         return null;
  118.     }
  119.   }

这段代码非常长，大部分是switch/case的各种返回码处理。followUpRequest方法从宏观上来讲，是输入response，生成新的requests。如果response的内容不需要重试，则直接返回null。如果需要重试，则根据response的内容，生成重试策略，返回重试发出的request。

其中，重定向和超时是最主要的重试情况。在处理重定向和超时时，okhttp进行了很多判断，排除了一些不必要重试的情况。如，location不存在，或者重定向的url协议头不一致等情况。

而followUpCount则是为了限制okhttp的重试次数。

总结

RetryAndFollowUpInterceptor在okhttp中承担了重试和重定向的逻辑。其中包括了，建立连接、读取内容失败的重试 和 完整读取请求返回后的重定向。针对各种返回码，okhttp对无需重试的一些场景进行了裁剪，减少了无效重试的概率。同时，对不规范的重定向返回进行的过滤和校验。

网络请求的场景复杂，在设计网络框架时，对于各种未知情况的处理，是一项比较有挑战的工作。okhttp作为一个高可用的网络框架，在RetryAndFollowUpInterceptor这一拦截器中，提供了一个异常处理的优秀范本。

当读者需要自己设计网络库时，可以参考okhttp中RetryAndFollowUpInterceptor对于异常处理的做法，避免一些难以预测和重现的问题。

如有问题，欢迎指正。