OkHttp3源码详细解析

秒速五厘米 2023-07-17 07:07 75阅读 0赞

OkHttp是一个非常优秀的网络请求框架，已被谷歌加入到Android的源码中。目前比较流行的Retrofit也是默认使用OkHttp的。所以OkHttp的源码是一个不容错过的学习资源，学习源码之前，务必熟练使用这个框架，否则就是跟自己过不去。

use -> running source code -> reading & learning the source code.

# 1、初识 #

![Center][]

在早期的版本中，OkHttp支持Http1.0,1.1,SPDY协议，但是Http2协议的问世，导致OkHttp也做出了改变，OkHttp鼓励开发者使用HTTP2，不再对SPDY协议给予支持。另外，新版本的OkHttp还有一个新的亮点就是支持WebScoket，这样我们就可以非常方便的建立长连接了。 [关于Http各个版本的异同，可以查看这篇博客：http://blog.csdn.net/json\_it/article/details/78312311][Http_http_blog.csdn.net_json_it_article_details_78312311]

作为一个优秀的网络框架，OkHttp同样支持网络缓存，OkHttp的缓存基于DiskLruCache,对这个类不熟悉的可以 [这里学习][Link 1]。DiskLruCache虽然没有被收入到Android的源码中，但也是谷歌推荐的一个优秀的缓存框架。有时间可以自己学习源码，这里不再叙述。

在安全方便，OkHttp目前支持了如上图所示的TLS版本，以确保一个安全的Socket连接。

重试及重定向就不再说了，都知道什么意思，左上角给出了各浏览器或Http版本支持的重试或重定向次数。

# 2、流程（以同步请求为例） #

## 2.1、基本使用 ##

OkHttpClient client = new OkHttpClient(); 
        Request request = new Request.Builder().url("http://www.baidu.com") 
        .build(); 
        try { 
        Response response = client.newCall(request).execute(); 
        if (response.isSuccessful()) { 
        System.out.println("成功"); 
        } 
        } catch (IOException e) { 
        e.printStackTrace(); 
        }

## 2.2、同步请求流程 ##

![Center 1][]

在开始流程讲解之前，先了解一下三个概念的含义（以下来自源码注释）：

Connections：连接远程服务器的物理连接；

Streams：基于Connection的逻辑Http请求/响应对。一个连接可以承载多少个Stream都是有限制的，Http1.x连接只能承载一个Stream，而一个Http2.0连接可以承载多个Stream（支持并发请求，并发请求共用一个Connection）；

Calls：逻辑Stream序列，典型的例子是一个初始请求及其后续的请求。We prefer to keep all streams of a single call on the same  connection for better behavior and locality.

对于同步和异步请求，唯一的区别就是异步请求会放在线程池（ThreadPoolExecutor）中去执行，而同步请求则会在当前线程中执行，注意：同步请求会阻塞当前线程。

对于Http1.1，call - 1:1 - Stream - 1:1 - connection;

对于http2.0,call - 1:1 - Stream - N:1 - connection;

由上述流程图，我们可以直观的了解到一次基本的请求包括如下两个部分：call+interceptors。

call:最终的请求对象；

interceptors:这是OkHttp最核心的部分，一个请求会经过OkHttp的若干个拦截器进行处理，每一个拦截器都会完成一个功能模块，比如CacheInterceptor完成网络请求的缓存。一个Request经过拦截器链的处理之后，会得到最终的Response。

interceptors里面包括的东西很多东西，后续的源码分析就是以拦截器为主线来进行分析。

# 3、源码分析 #

还是以上面的这段最基本的用法作为源码分析的入口。

## 3.1、OkHttpClient ##

首先，我们生成了一个OKHttpClient对象，注意OKHttpClient对象的生成有两种方式：一种是我们使用的方式，另一种是使用建造者（Builder）模式 -- new OkHttpClient.Builder()....Build()。那么这两种方式有什么区别呢？

第一种：

public OkHttpClient() { 
        this(new Builder()); 
        } 
        public Builder() { 
        dispatcher = new Dispatcher(); 
        protocols = DEFAULT_PROTOCOLS; 
        connectionSpecs = DEFAULT_CONNECTION_SPECS; 
        eventListenerFactory = EventListener.factory(EventListener.NONE); 
        proxySelector = ProxySelector.getDefault(); 
        cookieJar = CookieJar.NO_COOKIES; 
        socketFactory = SocketFactory.getDefault(); 
        hostnameVerifier = OkHostnameVerifier.INSTANCE; 
        certificatePinner = CertificatePinner.DEFAULT; 
        proxyAuthenticator = Authenticator.NONE; 
        authenticator = Authenticator.NONE; 
        connectionPool = new ConnectionPool(); 
        dns = Dns.SYSTEM; 
        followSslRedirects = true; 
        followRedirects = true; 
        retryOnConnectionFailure = true; 
        connectTimeout = 10_000; 
        readTimeout = 10_000; 
        writeTimeout = 10_000; 
        pingInterval = 0; 
        }

可以看到我们简单的一句new OkHttpClient()，OkHttp就已经为我们做了很多工作，很多我们需要的参数在这里都获得默认值。各字段含义如下：

dispatcher：直译就是调度器的意思。主要作用是通过双端队列保存Calls（同步&异步Call），同时在线程池中执行异步请求。后面会详细解析该类。

protocols：默认支持的Http协议版本  --   Protocol.HTTP\_2, Protocol.HTTP\_1\_1；

connectionSpecs：OKHttp连接（Connection）配置 -- ConnectionSpec.MODERN\_TLS, ConnectionSpec.CLEARTEXT，我们分别看一下：

/** TLS 连接 */ 
        public static final ConnectionSpec MODERN_TLS = new Builder(true) 
        .cipherSuites(APPROVED_CIPHER_SUITES) 
        .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2, TlsVersion.TLS_1_1, TlsVersion.TLS_1_0) 
        .supportsTlsExtensions(true) 
        .build(); 
        /** 未加密、未认证的Http连接. */ 
        public static final ConnectionSpec CLEARTEXT = new Builder(false).build();

可以看出一个是针对TLS连接的配置，一个是针对普通的Http连接的配置；

eventListenerFactory ：一个Call的状态监听器，注意这个是okhttp新添加的功能，目前还不是最终版，在后面的版本中会发生改变的。

proxySelector ：使用默认的代理选择器；

cookieJar：默认是没有Cookie的；

socketFactory：使用默认的Socket工厂产生Socket；

hostnameVerifier、 certificatePinner、 proxyAuthenticator、 authenticator：安全相关的设置；

connectionPool ：连接池；后面会详细介绍；

dns:这个一看就知道，域名解析系统 domain name -> ip address；

pingInterval :这个就和WebSocket有关了。为了保持长连接，我们必须间隔一段时间发送一个ping指令进行保活；

第二种：默认的设置和第一种方式相同，但是我们可以利用建造者模式单独的设置每一个属性；

注意事项：OkHttpClient强烈建议全局单例使用，因为每一个OkHttpClient都有自己单独的连接池和线程池，复用连接池和线程池能够减少延迟、节省内存。

## 3.2、RealCall（生成一个Call） ##

在我们定义了请求对象request之后，我们需要生成一个Call对象，该对象代表了一个准备被执行的请求。Call是可以被取消的。Call对象代表了一个request/response 对（Stream）.还有就是一个Call只能被执行一次。执行同步请求，代码如下（RealCall的execute方法）：

@Override public Response execute() throws IOException { 
        synchronized (this) { 
        if (executed) throw new IllegalStateException("Already Executed"); 
        executed = true; 
        } 
        captureCallStackTrace(); 
        eventListener.callStart(this); 
        try { 
        client.dispatcher().executed(this); 
        Response result = getResponseWithInterceptorChain(); 
        if (result == null) throw new IOException("Canceled"); 
        return result; 
        } catch (IOException e) { 
        eventListener.callFailed(this, e); 
        throw e; 
        } finally { 
        client.dispatcher().finished(this); 
        } 
        }

解析：首先如果executed等于true，说明已经被执行，如果再次调用执行就抛出异常。这说明了一个Call只能被执行。注意此处同步请求与异步请求生成的Call对象的区别，执行

异步请求代码如下（RealCall的enqueue方法）：

@Override public void enqueue(Callback responseCallback) { 
        synchronized (this) { 
        if (executed) throw new IllegalStateException("Already Executed"); 
        executed = true; 
        } 
        captureCallStackTrace(); 
        eventListener.callStart(this); 
        client.dispatcher().enqueue(new AsyncCall(responseCallback)); 
        }

可以看到同步请求生成的是RealCall对象，而异步请求生成的是AsyncCall对象。AsyncCall说到底其实就是Runnable的子类。

接着上面继续分析，如果可以执行，则对当前请求添加监听器等操作，然后将请求Call对象放入调度器Dispatcher中。最后由拦截器链中的各个拦截器来对该请求进行处理，返回最终的Response。

## 3.3、Dispatcher(调度器) ##

Dispatcher是保存同步和异步Call的地方，并负责执行异步AsyncCall。

![Center 2][]

如上图，针对同步请求，Dispatcher使用了一个Deque保存了同步任务；针对异步请求，Dispatcher使用了两个Deque，一个保存准备执行的请求，一个保存正在执行的请求，为什么要用两个呢？因为Dispatcher默认支持最大的并发请求是64个，单个Host最多执行5个并发请求，如果超过，则Call会先被放入到readyAsyncCall中，当出现空闲的线程时，再将readyAsyncCall中的线程移入到runningAsynCalls中，执行请求。先看Dispatcher的流程，跟着流程读源码：

![Center 3][]

在3.2小节中，当一个请求是同步请求的请求的，可以看到执行了这句代码：client.dispatcher().executed(this);根据Dispatcher源码，看一下到底发生了什么？

synchronized void executed(RealCall call) { 
        runningSyncCalls.add(call); 
        }

可以看到，只是简单的将同步任务当到了runningSyncCalls集合中。

在经过拦截器的处理之后，得到了响应的Response，最终会执行finally语句块：

void finished(RealCall call) { 
        finished(runningSyncCalls, call, false); 
        } 
        private <T> void finished(Deque <T> calls, T call, boolean promoteCalls) { 
        int runningCallsCount; 
        Runnable idleCallback; 
        synchronized (this) { 
        if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");//将请求移除集合 
        if (promoteCalls) promoteCalls(); 
        ... 
        } 
        ... 
        }

对于同步请求，只是简单的将同步请求移除runningSyncCalls集合。promoteCalls参数是false，因此不会执行promoteCalls方法，promoteCalls方法用于遍历并执行异步请求待执行集合中的请求。

Dispatcher中，同步请求的逻辑还是比较简单的。异步请求的逻辑相对麻烦一些，但也不是很复杂。

在3.2小节，第二处代码是执行异步请求的逻辑，最关键的是最后依据代码：client.dispatcher().enqueue(new AsyncCall(responseCallback));紧跟着看一下enqueue方法中到底发生了什么：

synchronized void enqueue(AsyncCall call) { 
        if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) { 
        runningAsyncCalls.add(call); 
        executorService().execute(call); 
        } else { 
        readyAsyncCalls.add(call); 
        } 
        }

可以看到如果正在执行的请求总数<=64 && 单个Host正在执行的请求<=5，则将请求加入到runningAsyncCalls集合中，紧接着就是利用线程池执行该请求，否则就将该请求放入readyAsyncCalls集合中。上面我们已经说了，AsyncCall是Runnable的子类（间接），因此，在线程池中最终会调用AsyncCall的execute（）方法执行异步请求：

@Override protected void execute() { 
        boolean signalledCallback = false; 
        try { 
        Response response = getResponseWithInterceptorChain();//拦截器链 
        if (retryAndFollowUpInterceptor.isCanceled()) {//重试失败，回调onFailure方法 
        signalledCallback = true; 
        responseCallback.onFailure(RealCall.this, new IOException("Canceled")); 
        } else { 
        signalledCallback = true; 
        responseCallback.onResponse(RealCall.this, response); 
        } 
        } catch (IOException e) { 
        if (signalledCallback) { 
        // Do not signal the callback twice! 
        Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e); 
        } else { 
        eventListener.callFailed(RealCall.this, e); 
        responseCallback.onFailure(RealCall.this, e); 
        } 
        } finally { 
        client.dispatcher().finished(this);//结束 
        } 
        }

此处的执行逻辑和同步的执行逻辑基本相同，区别在最后一句代码：client.dispatcher().finished(this);因为这是一个异步任务，所以会调用另外一个finish方法：

void finished(AsyncCall call) { 
        finished(runningAsyncCalls, call, true); 
        }

private <T> void finished(Deque <T> calls, T call, boolean promoteCalls) { 
        int runningCallsCount; 
        Runnable idleCallback; 
        synchronized (this) { 
        if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");//将请求移除集合 
        if (promoteCalls) promoteCalls(); 
        ... 
        } 
        
        ... 
        }

可以看到最后一个参数是true，这意味着需要执行promoteCalls方法：

private void promoteCalls() { 
        if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity. 
        if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote. 
        
        for (Iterator <AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) { 
        AsyncCall call = i.next(); 
        
        if (runningCallsForHost(call) < maxRequestsPerHost) { 
        i.remove(); 
        runningAsyncCalls.add(call); 
        executorService().execute(call); 
        } 
        
        if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity. 
        } 
        }

该方法主要是遍历执行readyRunningCalls集合中待执行的请求，当然前提是正在执行的Call总数没有超过64，并且readyAsyncCalls集合不为空。如果readyAsyncCalls集合为空，则意味着请求差不多都执行了。放入runningAsyncCalls集合中的请求会继续走上述的流程，直到全部的请求被执行。

## 3.4、拦截器链 ##

在依次介绍各个拦截器之前，先介绍一个比较重要的类：RealInterceptorChain，直译就是拦截器链类；这个类在什么地方会用到呢？还是3.2节，RealCall的execute方法有这么一段代码：

Response result = getResponseWithInterceptorChain();

没错，在getResponseWithInterceptorChain();方法中我们就用到了这个RealInterceptorChain类。

Response getResponseWithInterceptorChain() throws IOException { 
         // Build a full stack of interceptors. 
         List <Interceptor> interceptors = new ArrayList <>(); 
         interceptors.addAll(client.interceptors()); 
         interceptors.add(retryAndFollowUpInterceptor); 
         interceptors.add(new BridgeInterceptor(client.cookieJar())); 
         interceptors.add(new CacheInterceptor(client.internalCache())); 
         interceptors.add(new ConnectInterceptor(client)); 
         if (!forWebSocket) { 
         interceptors.addAll(client.networkInterceptors()); 
         } 
         interceptors.add(new CallServerInterceptor(forWebSocket)); 
         
         Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0, 
         originalRequest, this, eventListener, client.connectTimeoutMillis(), 
         client.readTimeoutMillis(), client.writeTimeoutMillis()); 
         
         return chain.proceed(originalRequest); 
         }

可以看到，在该方法中，我们依次添加了用户自定义的interceptor、retryAndFollowUpInterceptor、BridgeInterceptor、CacheInterceptor、ConnectInterceptor、 networkInterceptors、CallServerInterceptor，并将这些拦截器传递给了这个RealInterceptorChain。拦截器之所以可以依次调用，并最终再从后先前返回Response，都依赖于RealInterceptorChain的proceed方法。

public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec, 
         RealConnection connection) throws IOException { 
         if (index >= interceptors.size()) throw new AssertionError(); 
         
         ...... 
         
         // Call the next interceptor in the chain. 
         RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec, 
         connection, index + 1, request, call, eventListener, connectTimeout, readTimeout, 
         writeTimeout); 
         Interceptor interceptor = interceptors.get(index); 
         Response response = interceptor.intercept(next); 
         
         ...... 
         
         return response; 
         }

该方法最核心的代码就是中间的这几句，执行当前拦截器的Intercept方法，并调用下一个（index+1）拦截器。下一个（index+1）拦截器的调用依赖于当前拦截器的Intercept方法中，对RealInterceptorChain的proceed方法的调用：

response = realChain.proceed(request, streamAllocation, null, null);

可以看到当前拦截器的Response依赖于下一个拦截器的Intercept的Response。因此，就会沿着这条拦截器链依次调用每一个拦截器，当执行到最后一个拦截器之后，就会沿着相反的方向依次返回Response，最终得到我们需要的“终极版”Response。

### 3.4.1、重试及 followup拦截器 ###

@Override 
         public Response intercept(Chain chain) throws IOException { 
         Request request = chain.request();//获取Request对象 
         RealInterceptorChain realChain = (RealInterceptorChain) chain;//获取拦截器链对象，用于后面的chain.proceed(...)方法 
         Call call = realChain.call(); 
         EventListener eventListener = realChain.eventListener();//监听器 
         
         streamAllocation = new StreamAllocation(client.connectionPool(), createAddress(request.url()), 
         call, eventListener, callStackTrace); 
         
         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(), 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;//继续重试 
         } 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 = response.newBuilder() 
         .priorResponse(priorResponse.newBuilder() 
         .body(null) 
         .build()) 
         .build(); 
         } 
         //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. 
         // followUpRequest方法的主要作用就是为新的重试Request添加验证头等内容 
         Request followUp = followUpRequest(response); 
         
         if (followUp == null) {//如果一个请求得到的响应code是200，则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); 
         } else if (streamAllocation.codec() != null) { 
         throw new IllegalStateException("Closing the body of " + response + " didn't close its backing stream. Bad interceptor?"); 
         } 
         //-------------------------------------------------------------------------------- 
         request = followUp;//得到处理之后的Request，以用来继续请求，在哪继续请求？肯定还是沿着拦截器链继续搞呗 
         priorResponse = response;//由priorResponse持有 
         } 
         } 
         }

该拦截器主要的作用就是重试及followup(这个followup咋翻译比较贴切呢？)。当一个请求由于各种原因失败了，如果是路由或者连接异常，则尝试恢复，否则，根据响应码（ResponseCode）,followup方法会对Request进行再处理以得到新的Request，然后沿着拦截器链继续新的Request。当然，如果responseCode是200的话，这些过程就结束了。注意看注释。

### 3.4.2、BridgeInterceptor ###

咸蛋少扯，上图：

![Center 4][]

BridgeInterceptor的主要作用就是为请求（request before）添加请求头，为响应（Response Before）添加响应头。看源码：

@Override public Response intercept(Chain chain) throws IOException { 
        Request userRequest = chain.request(); 
        Request.Builder requestBuilder = userRequest.newBuilder(); 
        //----------------------request---------------------------------------------- 
        RequestBody body = userRequest.body(); 
        if (body != null) { 
        MediaType contentType = body.contentType(); 
        if (contentType != null) {//添加Content-Type请求头 
        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)); 
        } 
        
        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. 
        boolean transparentGzip = false; 
        if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) { 
        transparentGzip = true; 
        requestBuilder.header("Accept-Encoding", "gzip"); 
        } 
        
        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()); 
        //----------------------------------response---------------------------------------------- 
        HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());//保存cookie 
        
        Response.Builder responseBuilder = networkResponse.newBuilder() 
        .request(userRequest); 
        
        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")//Content-Encoding、Content-Length不能用于Gzip解压缩 
        .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(); 
        }

这个拦截器的源码还是很简单的，不再详细叙述。

### 3.4.3、CacheInterceptor ###

在解析CacheInterceptor之前，先看一张关于Http缓存机制的图片（来源于网络）：

![Center 5][]

先看一下缓存的响应头：

![Center 6][]

（本模块前两个图均来自于http://blog.csdn.net/y874961524/article/details/61419716，感谢）

几个相关的字段先解释一下（估计都知道）：

Cache-control：标明缓存的最大存活时常；

Date：服务器告诉客户端，该资源的发送时间；

Expires：表示过期时间（该字段是1.0的东西，当cache-control和该字段同时存在的条件下，cache-control的优先级更高）；

Last-Modified：服务器告诉客户端，资源的最后修改时间；

还有一个字段，这个图没给出，就是E-Tag：当前资源在服务器的唯一标识，可用于判断资源的内容是否被修改了。

除以上响应头字段以外，还需了解两个相关的Request请求头：If-Modified-since、If-none-Match。这两个字段是和Last-Modified、E-Tag配合使用的。大致流程如下：

服务器收到请求时，会在200 OK中回送该资源的Last-Modified和ETag头（服务器支持缓存的情况下才会有这两个头哦），客户端将该资源保存在cache中，并记录这两个属性。当客户端需要发送相同的请求时，根据Date + Cache-control来判断是否缓存过期，如果过期了，会在请求中携带If-Modified-Since和If-None-Match两个头。两个头的值分别是响应中Last-Modified和ETag头的值。服务器通过这两个头判断本地资源未发生变化，客户端不需要重新下载，返回304响应。

看源码之前，先看几个与CacheInterceptor相关的比较重要的几个类：

![Center 7][]

CacheStrategy是一个缓存策略类，该类告诉CacheInterceptor是使用缓存还是使用网络请求；

Cache是封装了实际的缓存操作；

DiskLruCache:Cache基于DiskLruCache；

下面看一下CacheInterceptor的源码：

@Override public Response intercept(Chain chain) throws IOException { 
        Response cacheCandidate = cache != null 
        ? cache.get(chain.request())//以request的url而来key,获取缓存 
        : null; 
        
        long now = System.currentTimeMillis(); 
        //缓存策略类，该类决定了是使用缓存还是进行网络请求 
        CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get(); 
        Request networkRequest = strategy.networkRequest;//网络请求，如果为null就代表不用进行网络请求 
        Response cacheResponse = strategy.cacheResponse;//缓存响应，如果为null，则代表不使用缓存 
        
        if (cache != null) {//根据缓存策略，更新统计指标：请求次数、使用网络请求次数、使用缓存次数 
        cache.trackResponse(strategy); 
        } 
        //缓存不可用，关闭 
        if (cacheCandidate != null && cacheResponse == null) { 
        closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it. 
        } 
        //如果既无网络请求可用，又没有缓存，则返回504错误 
        // If we're forbidden from using the network and the cache is insufficient, fail. 
        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.缓存可用，直接返回缓存 
        if (networkRequest == null) { 
        return cacheResponse.newBuilder() 
        .cacheResponse(stripBody(cacheResponse)) 
        .build(); 
        } 
        
        Response networkResponse = null; 
        try { 
        networkResponse = chain.proceed(networkRequest);//进行网络请求，得到网络响应 
        } finally { 
        // If we're crashing on I/O or otherwise, don't leak the cache body. 
        if (networkResponse == null && cacheCandidate != null) { 
        closeQuietly(cacheCandidate.body()); 
        } 
        } 
        //HTTP_NOT_MODIFIED缓存有效，合并网络请求和缓存 
        // If we have a cache response too, then we're doing a conditional get. 
        if (cacheResponse != null) { 
        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; 
        }

上面源码中的注释已经解释的很清楚了，下面再简单的说一下流程：

根据缓存策略类返回的结果：

1、如果网络不可用并且无可用的有效缓存，则返回504错误；

2、继续，如果不需要网络请求，则直接使用缓存；

3、继续，如果需要网络可用，则进行网络请求；

4、继续，如果有缓存，并且网络请求返回HTTP\_NOT\_MODIFIED，说明缓存还是有效的，则合并网络响应和缓存结果。同时更新缓存；

5、继续，如果没有缓存，则写入新的缓存；

我们可以看到，CacheStrategy在CacheInterceptor中起到了很关键的作用。该类决定了是网络请求还是使用缓存。该类最关键的代码是getCandidate（）方法：

private CacheStrategy getCandidate() { 
        // No cached response. 
        if (cacheResponse == null) {//没有缓存，直接网络请求 
        return new CacheStrategy(request, null); 
        } 
        
        // Drop the cached response if it's missing a required handshake. 
        if (request.isHttps() && cacheResponse.handshake() == null) {//https，但没有握手，直接网络请求 
        return new CacheStrategy(request, null); 
        } 
        
        // If this response shouldn't have been stored, it should never be used 
        // as a response source. This check should be redundant as long as the 
        // persistence store is well-behaved and the rules are constant. 
        if (!isCacheable(cacheResponse, request)) {//不可缓存，直接网络请求 
        return new CacheStrategy(request, null); 
        } 
        
        CacheControl requestCaching = request.cacheControl(); 
        if (requestCaching.noCache() || hasConditions(request)) { 
        //请求头nocache或者请求头包含If-Modified-Since或者If-None-Match 
        //请求头包含If-Modified-Since或者If-None-Match意味着本地缓存过期，需要服务器验证 
        //本地缓存是不是还能继续使用 
        return new CacheStrategy(request, null); 
        } 
        
        CacheControl responseCaching = cacheResponse.cacheControl(); 
        if (responseCaching.immutable()) {//强制使用缓存 
        return new CacheStrategy(null, cacheResponse); 
        } 
        
        long ageMillis = cacheResponseAge(); 
        long freshMillis = computeFreshnessLifetime(); 
        
        if (requestCaching.maxAgeSeconds() != -1) { 
        freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds())); 
        } 
        
        long minFreshMillis = 0; 
        if (requestCaching.minFreshSeconds() != -1) { 
        minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds()); 
        } 
        
        long maxStaleMillis = 0; 
        if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) { 
        maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds()); 
        } 
        //可缓存，并且ageMillis + minFreshMillis < freshMillis + maxStaleMillis 
        // （意味着虽过期，但可用，只是会在响应头添加 warning） 
        if (! responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) { 
        Response.Builder builder = cacheResponse.newBuilder(); 
        if ( ageMillis + minFreshMillis >= freshMillis) { 
        builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\""); 
        } 
        long oneDayMillis = 24 * 60 * 60 * 1000L; 
        if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) { 
        builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\""); 
        } 
        return new CacheStrategy(null, builder.build());//使用缓存 
        } 
        
        // Find a condition to add to the request. If the condition is satisfied, the response body 
        // will not be transmitted. 
        String conditionName; 
        String conditionValue; 
        //流程走到这，说明缓存已经过期了 
        //添加请求头：If-Modified-Since或者If-None-Match 
        //etag与If-None-Match配合使用 
        //lastModified与If-Modified-Since配合使用 
        //前者和后者的值是相同的 
        //区别在于前者是响应头，后者是请求头。 
        //后者用于服务器进行资源比对，看看是资源是否改变了。 
        // 如果没有，则本地的资源虽过期还是可以用的 
        if (etag != null) { 
        conditionName = "If-None-Match"; 
        conditionValue = etag; 
        } else if (lastModified != null) { 
        conditionName = "If-Modified-Since"; 
        conditionValue = lastModifiedString; 
        } else if (servedDate != null) { 
        conditionName = "If-Modified-Since"; 
        conditionValue = servedDateString; 
        } else { 
        return new CacheStrategy(request, null); // No condition! Make a regular request. 
        } 
        
        Headers.Builder conditionalRequestHeaders = request.headers().newBuilder(); 
        Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue); 
        
        Request conditionalRequest = request.newBuilder() 
        .headers(conditionalRequestHeaders.build()) 
        .build(); 
        return new CacheStrategy(conditionalRequest, cacheResponse); 
        }

大致流程如下：（if-else的关系呀）

1、没有缓存，直接网络请求；

2、如果是https，但没有握手，直接网络请求；

3、不可缓存，直接网络请求；

4、请求头nocache或者请求头包含If-Modified-Since或者If-None-Match，则需要服务器验证本地缓存是不是还能继续使用，直接网络请求；  
5、可缓存，并且ageMillis + minFreshMillis < freshMillis + maxStaleMillis（意味着虽过期，但可用，只是会在响应头添加warning），则使用缓存；

6、缓存已经过期，添加请求头：If-Modified-Since或者If-None-Match，进行网络请求；

### 3.4.4、ConnectInterceptor（核心，连接池） ###

ConnectInterceptor器如其名，是一个连接相关的拦截器。这个拦截器是这几个拦截器里面代码最少的。但是少并不意味着很简单。先看一下ConnectIntercepor中比较重要的几个类及其含义：

![Center 8][]

RouteDataBase：这是一个关于路由信息的白名单和黑名单类，处于黑名单的路由信息会被避免不必要的尝试；

RealConnecton：Connect子类，主要实现连接的建立等工作；

ConnectionPool:连接池，实现连接的复用；

这里再说一下Connection和Stream的关系：Http1.x是1:1的关系,而Http2是1对多的关系。就是说一个http1.x连接只能被一个请求使用，而一个Http2连接是对应多个Stream的，多个Stream的意思是Http2连接支持并发请求，即一个连接可以被多个请求同时使用的。

还有，Http1.1的keep-alive机制的作用是保证连接使用完不关闭，当下一次请求与连接的Host相同的时候，连接可以直接使用，不用再次创建（节省资源，提高了性能）。

StreamAllocation：直译就是流分配。流是什么呢？我们知道Connection是一个连接远程服务器的物理Socket连接，而Stream则是基于Connection的逻辑Http 请求/响应对。StreamAllocation会通过ConnectPool获取或者新生成一个RealConnection来得到一个连接到Server的Connection连接，同时会生成一个HttpCodec用于下一个CallServerInterceptor，以完成最终的请求；

HttpCodec： Encodes HTTP requests and decodes HTTP responses。（源码注释哦）。针对不同的版本，OkHttp为我们提供了HttpCodec1（Http1.x）和HttpCodec2(Http2).

一句话概括就是：分配一个Connection和HttpCodec，为最终的请求做准备。

/** Opens a connection to the target server and proceeds to the next interceptor. */ 
        public final class ConnectInterceptor implements Interceptor { 
        public final OkHttpClient client; 
        
        public ConnectInterceptor(OkHttpClient client) { 
        this.client = client; 
        } 
        
        @Override public Response intercept(Chain chain) throws IOException { 
        RealInterceptorChain realChain = (RealInterceptorChain) chain; 
        Request request = realChain.request(); 
        StreamAllocation streamAllocation = realChain.streamAllocation(); 
        
        // We need the network to satisfy this request. Possibly for validating a conditional GET. 
        //我们需要网络来满足这个请求。可能是为了验证一个条件GET请求（缓存验证等）。 
        boolean doExtensiveHealthChecks = !request.method().equals("GET"); 
        HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks); 
        RealConnection connection = streamAllocation.connection(); 
        
        return realChain.proceed(request, streamAllocation, httpCodec, connection); 
        } 
        }

代码量是不是很少？是的。表面上看起来很少，实际上大部分的功能都被封装到其他的类里面去了，此处只是调用。所以为了代码的可读性和可维护性，该封装的还是乖乖的封装吧。

核心代码就两行：

HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks); 
        RealConnection connection = streamAllocation.connection();

可以看出，主要的工作是由StreamAllocation完成。我们来看看这个StreamAllocation的newStream和connection（）到底做了什么。

public HttpCodec newStream( 
        OkHttpClient client, Interceptor.Chain chain, boolean doExtensiveHealthChecks) { 
        int connectTimeout = chain.connectTimeoutMillis(); 
        int readTimeout = chain.readTimeoutMillis(); 
        int writeTimeout = chain.writeTimeoutMillis(); 
        boolean connectionRetryEnabled = client.retryOnConnectionFailure(); 
        
        try { 
        RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout, 
        writeTimeout, connectionRetryEnabled, doExtensiveHealthChecks); 
        HttpCodec resultCodec = resultConnection.newCodec(client, chain, this); 
        
        synchronized (connectionPool) { 
        codec = resultCodec; 
        return resultCodec; 
        } 
        } catch (IOException e) { 
        throw new RouteException(e); 
        } 
        }

可以看到，最关键的一步就是findHealthyConnection，这个方法的主要的作用就是找到一个可用的连接（如果连接不可用，这个过程会一直持续哦）。

private RealConnection findHealthyConnection(int connectTimeout, int readTimeout, 
        int writeTimeout, boolean connectionRetryEnabled, boolean doExtensiveHealthChecks) 
        throws IOException { 
        while (true) { 
        RealConnection candidate = findConnection(connectTimeout, readTimeout, writeTimeout, 
        connectionRetryEnabled); 
        
        // If this is a brand new connection, we can skip the extensive health checks.如果是一个新的连接，直接返回就好了 
        synchronized (connectionPool) { 
        if (candidate.successCount == 0) { 
        return candidate; 
        } 
        } 
        
        // Do a (potentially slow) check to confirm that the pooled connection is still good. If it 
        // isn't, take it out of the pool and start again. 
        if (!candidate.isHealthy(doExtensiveHealthChecks)) {//判断连接是否好使 
        noNewStreams();//连接不好使的话，移除连接池 
        continue;//不healthy，就一直持续的呀 
        } 
        
        return candidate; 
        } 
        }

上述代码还是很容易理解的，唯一让我有点费解的就是这个noNewsStream方法。刚开始看名字有点蒙圈。啥叫noNewStream嘞，看源码（其实应该先看findConnection的源码的，但是先搞懂这个地方，对后面的理解有益无害的）：

public void noNewStreams() { 
         Socket socket; 
         Connection releasedConnection; 
         synchronized (connectionPool) { 
         releasedConnection = connection; 
         socket = deallocate(true, false, false);// noNewStreams, released, streamFinished核心方法 
         if (connection != null) releasedConnection = null; 
         } 
         closeQuietly(socket);//关闭socket 
         if (releasedConnection != null) { 
         eventListener.connectionReleased(call, releasedConnection);//监听回调 
         } 
         }

上述关键代码是deallocate:

private Socket deallocate(boolean noNewStreams, boolean released, boolean streamFinished) { 
         assert (Thread.holdsLock(connectionPool)); 
         //以noNewStreams为true, released为false, streamFinished为false;为例 
         if (streamFinished) { 
         this.codec = null; 
         } 
         if (released) { 
         this.released = true; 
         } 
         Socket socket = null; 
         if (connection != null) { 
         if (noNewStreams) { 
         //noNewStreams是RealConnection的属性，源码的注释是这么说的： 
         //如果为true，则这个连接就不会再创建新的Stream了，一旦设置成true，就会一直是true 
         //搜索整个源码，该属性设置的地方如下： 
         //evitAll：关闭和移除连接池中所有的空闲连接（如果连接空闲(即连接上的Stream数为0)，则noNewStreams为true）； 
         //pruneAndGetAllocationCount：移除内存泄漏的连接及获取连接的Stream分配数； 
         //streamFailed：Stream分配失败； 
         //综上，这个属性的作用是禁止无效连接创建新的Stream的 
         connection.noNewStreams = true; 
         } 
         if (this.codec == null && (this.released || connection.noNewStreams)) { 
         release(connection);//释放Connection承载的StreamAllocations资源（connection.allocations） 
         if (connection.allocations.isEmpty()) { 
         connection.idleAtNanos = System.nanoTime(); 
         //connectionBecameIdle:通知线程池该连接是空闲连接，可以移除或者作为待移除对象。 
         if (Internal.instance.connectionBecameIdle(connectionPool, connection)) { 
         socket = connection.socket(); 
         } 
         } 
         connection = null; 
         } 
         } 
         return socket;//返回待关闭的Socket对象 
         }

需要说的都写在了上面源码的注释里面了，不再多说了。

接着看findConnection方法，好吧，继续，源码有点长，不过我都给注释了，看起来应该也不会很难。

private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout, 
         boolean connectionRetryEnabled) throws IOException { 
         boolean foundPooledConnection = false; 
         RealConnection result = null; 
         Route selectedRoute = null; 
         Connection releasedConnection; 
         Socket toClose; 
         synchronized (connectionPool) { 
         //----------排除异常情况---------------- 
         if (released) throw new IllegalStateException("released"); 
         if (codec != null) throw new IllegalStateException("codec != null"); 
         if (canceled) throw new IOException("Canceled"); 
         
         // Attempt to use an already-allocated connection. We need to be careful here because our 
         // already-allocated connection may have been restricted from creating new streams. 
         releasedConnection = this.connection; 
         //这个方法的作用，与deallocate作用一样 
         //如果连接不能创建Stream，则释放资源，返回待关闭的close Socket 
         toClose = releaseIfNoNewStreams(); 
         //经过releaseIfNoNewStreams，如果connection不为null，则连接是可用的 
         if (this.connection != null) { 
         // We had an already-allocated connection and it's good. 
         //存在可使用的已分配连接 
         result = this.connection; 
         releasedConnection = null;//为null值，则说明这个连接是有效的 
         } 
         if (!reportedAcquired) { 
         // If the connection was never reported acquired, don't report it as released! 
         releasedConnection = null; 
         } 
         
         if (result == null) {//没有可使用的连接，去连接池中找 
         // Attempt to get a connection from the pool.//首先通过ConnectionPool,Address,StreamAllocation从连接池获取连接, 
         // 连接池后面会单独讲解************* 
         Internal.instance.get(connectionPool, address, this, null);//ConnectionPool,Address,StreamAllocation,Route 
         if (connection != null) { 
         foundPooledConnection = true; 
         result = connection; 
         } else { 
         selectedRoute = route; 
         } 
         } 
         } 
         closeQuietly(toClose); 
         
         if (releasedConnection != null) { 
         eventListener.connectionReleased(call, releasedConnection); 
         } 
         if (foundPooledConnection) { 
         eventListener.connectionAcquired(call, result); 
         } 
         if (result != null) { 
         // If we found an already-allocated or pooled connection, we're done. 
         return result;//找到了一个已分配或者连接池中的连接，此过程结束，返回 
         } 
         //否则，我们需要一个路由信息，这是一个阻塞的操作 
         // If we need a route selection, make one. This is a blocking operation. 
         boolean newRouteSelection = false; 
         if (selectedRoute == null && (routeSelection == null || !routeSelection.hasNext())) { 
         newRouteSelection = true; 
         routeSelection = routeSelector.next(); 
         } 
         
         synchronized (connectionPool) { 
         if (canceled) throw new IOException("Canceled"); 
         
         if (newRouteSelection) { 
         // Now that we have a set of IP addresses, make another attempt at getting a connection from 
         // the pool. This could match due to connection coalescing. 
         //提供更加全面的路由信息，再次从连接池中获取连接 
         List <Route> routes = routeSelection.getAll(); 
         for (int i = 0, size = routes.size(); i < size; i++) { 
         Route route = routes.get(i); 
         Internal.instance.get(connectionPool, address, this, route); 
         if (connection != null) { 
         foundPooledConnection = true; 
         result = connection; 
         this.route = route; 
         break; 
         } 
         } 
         } 
         //*实在是没找到，只能生成新的连接******了 
         if (!foundPooledConnection) { 
         if (selectedRoute == null) { 
         selectedRoute = routeSelection.next(); 
         } 
         
         // Create a connection and assign it to this allocation immediately. This makes it possible 
         // for an asynchronous cancel() to interrupt the handshake we're about to do. 
         route = selectedRoute; 
         refusedStreamCount = 0; 
         result = new RealConnection(connectionPool, selectedRoute); 
         acquire(result, false);//添加connection的StreamAllocation添加到connection.allocations集合中***** 
         } 
         } 
         
         // If we found a pooled connection on the 2nd time around, we're done. 
         //如果连接是从连接池中找到的，说明是可复用的。不是新生成的，因为新生成的连接， 
         // 需要去连接服务器之后才能可用呀 
         if (foundPooledConnection) { 
         eventListener.connectionAcquired(call, result); 
         return result; 
         } 
         
         // Do TCP + TLS handshakes. This is a blocking operation.//连接Server 
         result.connect( 
         connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled, call, eventListener); 
         routeDatabase().connected(result.route());//将路由信息添加到routeDatabase中。 
         
         Socket socket = null; 
         synchronized (connectionPool) { 
         reportedAcquired = true; 
         
         // Pool the connection. 
         Internal.instance.put(connectionPool, result);//将新生成的连接放入连接池中 
         
         // If another multiplexed connection to the same address was created concurrently, then 
         // release this connection and acquire that one. 
         //如果是一个http2连接，由于http2连接应具有多路复用特性， 
         // 因此，我们需要确保http2连接的多路复用特性 
         if (result.isMultiplexed()) { 
         //deduplicate:确保http2连接的多路复用特性，重复的连接将被剔除 
         socket = Internal.instance.deduplicate(connectionPool, address, this); 
         result = connection; 
         } 
         } 
         closeQuietly(socket); 
         
         eventListener.connectionAcquired(call, result); 
         return result; 
         }

上述代码加了很多注释，可以看一下。为了更加快速的了解其过程，画了一个流程图，跟着流程图来一步一步的解析（没有什么是一张图解决不了的，如果不能，那么就两张O(∩\_∩)O）。

![Center 9][]

a）排除连接不可用情况

private Socket releaseIfNoNewStreams() { 
         assert (Thread.holdsLock(connectionPool)); 
         RealConnection allocatedConnection = this.connection; 
         if (allocatedConnection != null && allocatedConnection.noNewStreams) { 
         return deallocate(false, false, true); 
         } 
         return null; 
         }

这个方法是说如果连接处于nonewStream状态，则释放该连接。否则，该连接是可用的。关于noNewStream和deallocate方法前面已经解释的很清楚了。

b）判断连接是否可用

经过releaseIfNoNewStreams方法，如果connection不为null，则一定是可用的。

//经过releaseIfNoNewStreams，如果connection不为null，则连接是可用的 
         if (this.connection != null) { 
         // We had an already-allocated connection and it's good. 
         //存在可使用的已分配连接 
         result = this.connection; 
         releasedConnection = null;//为null值，则说明这个连接是有效的 
         }

c）第一次连接池查找（没有提供路由信息）

Internal.instance.get(connectionPool, address, this, null);//ConnectionPool,Address,StreamAllocation,Route 
         if (connection != null) { 
         foundPooledConnection = true; 
         result = connection; 
         }

如果查找到了，则将查找到的连接赋值给result。

d）遍历路由表，进行二次查找

List <Route> routes = routeSelection.getAll(); 
         for (int i = 0, size = routes.size(); i < size; i++) { 
         Route route = routes.get(i); 
         Internal.instance.get(connectionPool, address, this, route); 
         if (connection != null) { 
         foundPooledConnection = true; 
         result = connection; 
         this.route = route; 
         break; 
         } 
         }

f）如果还是没找到，则只能创建新的连接了

result = new RealConnection(connectionPool, selectedRoute); 
         acquire(result, false);//添加connection的StreamAllocation添加到connection.allocations集合中*****

g）新的连接，连接服务器

// Do TCP + TLS handshakes. This is a blocking operation.//连接Server（connect方法涉及Socket的建立等） 
         result.connect( 
         connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled, call, eventListener); 
         routeDatabase().connected(result.route());//将路由信息添加到routeDatabase中。

h）新的连接放入线程池

// Pool the connection. 
         Internal.instance.put(connectionPool, result);//将新生成的连接放入连接池中

i）如果连接是一个HTTP2连接，则需要确保多路复用的特性

//如果是一个http2连接，由于http2连接应具有多路复用特性， 
         // 因此，我们需要确保http2连接的多路复用特性 
         if (result.isMultiplexed()) { 
         //deduplicate:确保http2连接的多路复用特性，重复的连接将被剔除 
         socket = Internal.instance.deduplicate(connectionPool, address, this); 
         result = connection; 
         }

在Connectinterceptor中，起到关键作用的就是ConnectionPool，既然这么关键我们就来看看这个连接池吧。

![Center 10][]

\-------------------------------------------------------------------------------------------------------------------------------------------------------------

在目前的版本下，连接池默认是可以保持5个空闲的连接。这些空闲的连接如果超过5分钟不被使用，则将被连接池移除。

当然，这些默认的数值在未来的okhttp版本中，会被改变的。另外，这两个数值支持开发人员修改。

\-------------------------------------------------------------------------------------------------------------------------------------------------------------

ConnectionPool中比较关键的几个点，线程池（ThreadPoolExecutor）、队列（Deque）、路由记录表；

线程池：用于支持连接池的cleanup任务，清除idle线程；

队列：存放待复用的连接；

路由记录表：前面已讲，不再叙述；

对于连接池，开发人员最感兴趣的肯定的：存、取、清除；

a）存

void put(RealConnection connection) { 
         assert (Thread.holdsLock(this)); 
         if (!cleanupRunning) { 
         cleanupRunning = true; 
         executor.execute(cleanupRunnable); 
         } 
         connections.add(connection); 
         }

可以看到，在放入连接到connections(Deque)之前，可能是需要执行连接池的“清洁”任务的。连接存入连接池的操作很简单，主要看一下这个cleanUp到底做了些什么？

long cleanup(long now) { 
         int inUseConnectionCount = 0; 
         int idleConnectionCount = 0; 
         RealConnection longestIdleConnection = null; 
         long longestIdleDurationNs = Long.MIN_VALUE; 
         
         // Find either a connection to evict, or the time that the next eviction is due. 
         synchronized (this) { 
         for (Iterator <RealConnection> i = connections.iterator(); i.hasNext(); ) { 
         RealConnection connection = i.next(); 
         
         // If the connection is in use, keep searching. 
         if (pruneAndGetAllocationCount(connection, now) > 0) { 
         inUseConnectionCount++;//线程池中处于使用状态的连接数 
         continue; 
         } 
         
         idleConnectionCount++;//处于空闲状态的连接数 
         
         // If the connection is ready to be evicted, we're done. 
         long idleDurationNs = now - connection.idleAtNanos; 
         //寻找空闲最久的那个连接 
         if (idleDurationNs > longestIdleDurationNs) { 
         longestIdleDurationNs = idleDurationNs; 
         longestIdleConnection = connection; 
         } 
         } 
         //空闲最久的那个连接 
         //如果空闲时间大于keepAliveDurationNs（默认5分钟） 
         //或者空闲的连接总数大于maxIdleConnections（默认5个） 
         //--->执行移除操作 
         if (longestIdleDurationNs >= this.keepAliveDurationNs 
         || idleConnectionCount > this.maxIdleConnections) { 
         // We've found a connection to evict. Remove it from the list, then close it below (outside 
         // of the synchronized block). 
         connections.remove(longestIdleConnection); 
         } else if (idleConnectionCount > 0) { 
         // A connection will be ready to evict soon. 
         return keepAliveDurationNs - longestIdleDurationNs;//空闲最久的那个连接的空闲时长与keepAliveDurationNs的差值 
         } else if (inUseConnectionCount > 0) { 
         // All connections are in use. It'll be at least the keep alive duration 'til we run again. 
         return keepAliveDurationNs; 
         } else { 
         // No connections, idle or in use. 
         cleanupRunning = false; 
         return -1; 
         } 
         } 
         
         closeQuietly(longestIdleConnection.socket());//关闭Socket 
         
         // Cleanup again immediately. 
         return 0; 
         }

这个方法根据两个指标还决定是否移除空闲时间最长的空闲连接：大于最大空闲值或者空闲连接数超过最大值，则移除空闲时间最长的控线连接。cleanUp方法的执行也依赖于另外一个比较重要的方法：pruneAndGetAllocationCount，该方法的作用是移除发生泄漏的StreamAllocation，统计连接中正在使用的StreamAllocation个数。这个方法的源码不看了，有兴趣的自行品尝吧。

b）取

RealConnection get(Address address, StreamAllocation streamAllocation, Route route) { 
         assert (Thread.holdsLock(this)); 
         for (RealConnection connection : connections) { 
         //isEligible判断一个连接（address+route对应的） 
         // 是否还能携带一个StreamAllocation。如果有，说明这个连接可用 
         if (connection.isEligible(address, route)) {//isEligible也是一个重要方法，最好看一下源码 
         streamAllocation.acquire(connection, true);//将StreamAllocation添加到connection.allocations中 
         return connection; 
         } 
         } 
         return null; 
         }

首先，判断address对应的Connection是否还能承载一个新的StreamAllocation，如果可以得话，我们就将这个streamAllocation添加到connection.allocations中。最后返回这个Connection。

c）移除

public void evictAll() { 
         List <RealConnection> evictedConnections = new ArrayList <>(); 
         synchronized (this) { 
         for (Iterator <RealConnection> i = connections.iterator(); i.hasNext(); ) { 
         RealConnection connection = i.next(); 
         if (connection.allocations.isEmpty()) { 
         connection.noNewStreams = true; 
         evictedConnections.add(connection); 
         i.remove(); 
         } 
         } 
         } 
         
         for (RealConnection connection : evictedConnections) { 
         closeQuietly(connection.socket()); 
         } 
         }

这个就很简单了。不再叙述。

### 3.4.5、CallServerInterceptor ###

该拦截器就是利用HttpCodec完成最终请求的发送。

# 4、总结 #

okhttp是一个Http+Htttp2客户端，适用于Android + Java 应用。其整体的架构如下：

（此图来源于https://yq.aliyun.com/articles/78105?spm=5176.100239.blogcont78104.10.FlPFWr，感谢）

![Center 11][]

整体分析完之后，再看这个整体架构，感觉上图画的十分清晰。

云栖社区的这篇 [《OkHtp 3.7源码分析》][OkHtp 3.7]写的相当不错。有时间的可以阅读以下。

[Center]: /images/20230528/7339a7caed7148d3befaeb6d6e1ed560.png
[Http_http_blog.csdn.net_json_it_article_details_78312311]: http://blog.csdn.net/json_it/article/details/78312311
[Link 1]: http://blog.csdn.net/guolin_blog/article/details/28863651
[Center 1]: /images/20230528/79356040889a4b45927bc9dfb97a9b51.png
[Center 2]: /images/20230528/be12eb5744664af49b117a91a81e7ef0.png
[Center 3]: /images/20230528/804a254785f549448397829739207702.png
[Center 4]: /images/20230528/3f1fe1dd93244e0da5f16641def107fc.png
[Center 5]: /images/20230528/86aa17fbc6f34a5396cbe992748e2559.png
[Center 6]: /images/20230528/e1b5ebf9c44443c08e139371c0c37dfa.png
[Center 7]: /images/20230528/0ee8e849079849d8b115933e7108de40.png
[Center 8]: /images/20230528/6f1e2bcb4af944c2b81e11656d918553.png
[Center 9]: /images/20230528/d9067b2bc0314907bbd0b58157bc8202.png
[Center 10]: /images/20230528/1de25ceecba440e8892debcc733b0592.png
[Center 11]: /images/20230528/aff6342853ab49199afd5c10f38ca97a.png
[OkHtp 3.7]: https://yq.aliyun.com/articles/78105?spm=5176.100239.blogcont78104.10.FlPFWr