一.五大拦截器总体介绍
在前面分发器的介绍中，可以看到通过getResponseWithInterceptorChain这一个方法，就可以获得响应。这个方法里面是这样的
除了两个用户可以自己添加的拦截器之外，剩下的五个是默认的拦截器。他们之间是用责任链模式连接在一起
1.责任链模式
概念：责任链上的处理者负责处理请求，客户只需要将请求发送到责任链即可，无须关心请求的处理细节和请求的传递，所以职 责链将请求的发送者和请求的处理者解耦了。
比如点个外卖，它的流程是这样的
我不必关心内部是具体怎么给我做的饭，美团外卖只管提供平台和送餐，饭店只管接单和派单，厨师只管接收菜和做菜。他们之间是一个U型结构，类似于Android的事件分发。这五大拦截器之间也是责任链模式，具体可用一张图表示
2.五大拦截器的责任链模式抽取
我们建立这几个类和接口
上面五个是拦截器，Chain是链条类，负责串联这几个拦截器，Interceptor是接口，MyClass是程序入口。我们进入MyClass
这里首先创建了五个拦截器，然后通过Chain将五大拦截器串起来，index设为0，然后调用chain的processd方法
看下第一个拦截器的intercept方法
然后调用chain（索引值从1开始，也就是从第二个拦截器开始）的processd方法。再以此类推，直到调用了第五个拦截器的intercept方法
然后依次返回，一直到第一个。
也就是说先调用chain的processd方法，找到第一个拦截器，然后调用其intercept方法，然后再调用chain的processd方法，找到第二个拦截器，然后调用其intercept方法，然后再调用chain的processd方法，以此类推，直到找到第五个拦截器，调用其intercept方法，执行完了之后将结果依次返回到第一个拦截器。
3.各个拦截器的功能
①重试和重定向拦截器
它在交出(交给下一个拦截器)之前，负责判断是否需要重新发起请求（重试）；在获得了结果之后 ，会根据响应码判断是否需要重定向，如果满足条件那么就会重启执行所有拦截器。 （它是最早接收Request的，也是最晚接收Response的）
返回码是3xx的，就需要重定向了
②桥接拦截器
在交出之前，负责将HTTP协议必备的请求头，加入其中(如：Host)并添加一些默认的行为(如：GZIP压缩)；在获得了结果后，调用保存cookie接口并解析GZIP数据。
③缓存拦截器
顾名思义，交出之前读取并判断是否使用缓存；获得结果后判断是否缓存。
④连接拦截器
在交出之前，负责找到或者新建一个连接，并获得对应的socket流；在获得结果后不进行额外的处理。
⑤请求服务器拦截器
进行真正的与服务器的通信，向服务器发送数据，解析读取的响应数据。
二.RetryAndFollowUpInterceptor
重试和重定向拦截器。它对Request没有做什么特殊的操作，而是把重心放在了Response上面。直接看源码
可以看到它直接把request传进去的。
这里有几个值得注意的点
①整个重试和重定向过程是在一个while循环里面
②通过try catch来实现重试，具体是catch里面的continue
也就是请求异常的时候，会进入catch里面，如果recover方法返回true，那就可以重试。下面就进入这个recover方法看一看
1.recover判断是否可以重试
不允许重试的情况有四种
①通过其建造者模式，创建OkHttpClient的时候，给他配置了不可重试。
在其Builder类里面，有这么一个方法，传入false，就设置了不可重试
当然，如果不设置，默认情况下，是true，即可重试
②对某一次请求设置不可重试。（用的少）
上面那种情况是全局的，这个是某一次的。具体方法是自定义一个请求体，然后让其实现标识接口UnrepeatableRequestBody。
如图
③isRecoverable方法返回false，不可重试
我们看下isRecoverable方法
如果是协议异常，就不可重试
比如在CallServerInterceptor的这里
204和205的意思是响应体中没有内容，而后面的contentLength大于0又说响应体中有内容，所以协议冲突了，抛出异常。一般是服务器的原因
如果是请求时间过长，那么可以重试（比如发生网络波动了）
如果是证书不正确，或者不匹配，都不能重试
④有没有更多的路由
比如有A代理和B代理，A代理不行，可以试试B代理，两者都不行，就是没有路由了，就不能重试了所以，总结下重试的逻辑
如果OkHttpClient允许重试，isRecoverable方法返回true，且拥有更多的路线，才能进行重试。如图
所以重试的条件是很苛刻的。
2.重定向
假如成功获得响应，那么走出try catch，走下面，如图
如果返回的响应码是需要重定向的响应码，如301，302，则followUpRequest方法会解析响应头里面的location字段，并将location里面的url组建成一个新的request，返回，也就是让followUp接收。如果followUp为null，就是没有location，那就是不需要重定向。当然重定向的次数有限制，最多为20次，即MAX_FOLLOW_UPS除了30x的响应码，需要重定向之外，其他的有一些响应码需要特殊处理。如图
三.BridgeInterceptor
桥接拦截器，
它对Request的操作，就是帮我们添加各种请求头。如图
补全之后就将请求交给下一拦截器进行处理。得到响应后，主要干两个事情
1、保存cookie 2、如果使用gzip返回的数据，则使用 GzipSource 包装便于解析。
四.CacheInterceptor
缓存拦截器，只有GET请求可以使用，POST那些不行。且如果要使用它的缓存，就要在创建OkHttpClient的时候进行手动配置
当然，也可以指定某一次请求不使用缓存
他有一个核心类，就是缓存策略类即CacheStrategy。它会经过很复杂的逻辑判断，得到两个值，分别是networkRequest和cacheResponse。根据两者是否为null的组合，来判断到底是进行网络请求还是使用缓存。具体规则为
下面，具体看一下是如何得到最终的CacheStrategy的，也就是这一行代码干了什么事
进入get方法
进入getCandidate方法
里面就是具体怎么得到的CacheStrategy。逻辑很复杂，有些我也没有学习，这里找到了一些带注释的代码，供大家参考
private CacheStrategy getCandidate() {
// No cached response.
//todo 1、没有缓存,进行网络请求
if (cacheResponse == null) {
return new CacheStrategy(request, null);
}
//todo okhttp会保存ssl握手信息 Handshake ,如果这次发起了https请求，但是缓存的响应中没有握手信息，发起网络请求
//todo 2、https请求，但是没有握手信息,进行网络请求
//Drop the cached response if it's missing a required handshake.
if (request.isHttps() && cacheResponse.handshake() == null) {
return new CacheStrategy(request, null);
}
//todo 3、主要是通过响应码以及头部缓存控制字段判断响应能不能缓存，不能缓存那就进行网络请求
//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();
//todo 4、如果 请求包含：CacheControl:no-cache 需要与服务器验证缓存有效性
// 或者请求头包含 If-Modified-Since：时间 值为lastModified或者data 如果服务器没有在该头部指定的时间之后修改了请求的数据，服务器返回304(无修改)
// 或者请求头包含 If-None-Match：值就是Etag（资源标记）服务器将其与存在服务端的Etag值进行比较；如果匹配，返回304
// 请求头中只要存在三者中任意一个，进行网络请求
if (requestCaching.noCache() || hasConditions(request)) {
return new CacheStrategy(request, null);
}
//todo 5、如果缓存响应中存在 Cache-Control:immutable 响应内容将一直不会改变,可以使用缓存
CacheControl responseCaching = cacheResponse.cacheControl();
if (responseCaching.immutable()) {
return new CacheStrategy(null, cacheResponse);
}
//todo 6、根据 缓存响应的 控制缓存的响应头 判断是否允许使用缓存
// 6.1、获得缓存的响应从创建到现在的时间
long ageMillis = cacheResponseAge();
//todo
// 6.2、获取这个响应有效缓存的时长
long freshMillis = computeFreshnessLifetime();
if (requestCaching.maxAgeSeconds() != -1) {
//todo 如果请求中指定了 max-age 表示指定了能拿的缓存有效时长，就需要综合响应有效缓存时长与请求能拿缓存的时长，获得最小的能够使用响应缓存的时长
freshMillis = Math.min(freshMillis,
SECONDS.toMillis(requestCaching.maxAgeSeconds()));
}
//todo
// 6.3 请求包含 Cache-Control:min-fresh=[秒] 能够使用还未过指定时间的缓存 （请求认为的缓存有效时间）
long minFreshMillis = 0;
if (requestCaching.minFreshSeconds() != -1) {
minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
}
//todo
// 6.4
// 6.4.1、Cache-Control:must-revalidate 可缓存但必须再向源服务器进行确认
// 6.4.2、Cache-Control:max-stale=[秒] 缓存过期后还能使用指定的时长 如果未指定多少秒，则表示无论过期多长时间都可以；如果指定了，则只要是指定时间内就能使用缓存
// 前者会忽略后者，所以判断了不必须向服务器确认，再获得请求头中的max-stale
long maxStaleMillis = 0;
if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
}
//todo
// 6.5 不需要与服务器验证有效性 && 响应存在的时间+请求认为的缓存有效时间 小于 缓存有效时长+过期后还可以使用的时间
// 允许使用缓存
if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
Response.Builder builder = cacheResponse.newBuilder();
//todo 如果已过期，但未超过 过期后继续使用时长，那还可以继续使用，只用添加相应的头部字段
if (ageMillis + minFreshMillis >= freshMillis) {
builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
}
//todo 如果缓存已超过一天并且响应中没有设置过期时间也需要添加警告
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.
//todo 7、缓存过期了
String conditionName;
String conditionValue;
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.
}
//todo 如果设置了 If-None-Match/If-Modified-Since 服务器是可能返回304(无修改)的,则使用缓存的响应体
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);
}有一个比较重要的请求头/响应头，就是Cache-ControlCache-Control 可以在请求头存在，也能在响应头存在，对应的value可以设置多种组合：
1.max-age=[秒] ：资源最大有效时间;
2.public ：表明该资源可以被任何用户缓存，比如客户端，代理服务器等都可以缓存资源; 3.
3.private ：表明该资源只能被单个用户缓存，默认是private。
4.no-store ：资源不允许被缓存
3.no-cache ：(请求)不使用缓存，就是这一次不用，并不代表没有缓存
4.immutable ：(响应)资源不会改变
5.min-fresh=[秒] ：(请求)缓存最小新鲜度(用户认为这个缓存有效的时长) 8. must-revalidate ：(响应)不允许使用过期缓存
6.max-stale=[秒] ：(请求)缓存过期后多久内仍然有效
举例：假设存在max-age=100，min-fresh=20。这代表了用户认为这个缓存的响应，从服务器创建响应 到 能够缓
存使用的时间为100-20=80s。但是如果max-stale=100。这代表了缓存有效时间80s过后，仍然允许使用
100s，可以看成缓存有效时长为180s。
具体流程是这样的
总结一下
如果想使用缓存，首先用户要配置缓存，然后查看是否存在缓存，且要保持有握手信息。除此之外，看是否允许使用缓存，若允许，则看这次请求是否需要使用缓存，如果需要，则看返回体中是否有Cache-Control:immutable，若有，则说明缓存的资源没变，则再看看资源是否有效，也就是是否过期了。如果没过期，才能用缓存。使用缓存的话，就不需要使用下面的拦截器了，直接返回response
五.ConnectInterceptor
连接拦截器。说白了就是获取socket连接。该连接有可能是从socket连接池里面获取的
1.连接池ConnectionPool
首先看它的构造方法
第一个是最大闲置连接数，也就是说它最多维护多少个闲置连接，类似于线程池的核心线程数。后面就是其存活时间和单位了。往连接池中添加连接，使用的是put方法
如果是第一次调用put方法，就会启动cleanupRunnable，即专门清理闲置连接的一个线程
追踪里面的cleanUp方法
逻辑大概是这样：首先遍历所有的连接，得到闲置连接数和闲置了最长时间的连接。遍历完成后，如果闲置了最长时间的连接超过了5分钟（或者你自定义的其他时长），或者闲置连接数超过了5（或者你自定义的其他数目），则把这个闲置了最长时间的连接从连接池里面清除掉。具体逻辑在下面
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();
//todo 检查连接是否正在被使用
//If the connection is in use, keep searching.
if (pruneAndGetAllocationCount(connection, now) > 0) {
inUseConnectionCount++;
continue;
}
//todo 否则记录闲置连接数
idleConnectionCount++;
// If the connection is ready to be evicted, we're done.
//TODO 获得这个连接已经闲置多久
// 执行完遍历，获得闲置了最久的连接
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
}
//todo 超过了保活时间(5分钟) 或者池内闲置连接数量超过了(5个) 马上移除闲置了最久的连接，然后返回0，表示不等待，马上再次检查清理
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.
//todo 池内存在闲置连接，就等待 保活时间(5分钟)-最长闲置时间 =还能闲置多久 再检查
return keepAliveDurationNs - longestIdleDurationNs;
} else if (inUseConnectionCount > 0) {
// All connections are in use. It'll be at least the keep alive duration 'til we
// run again.
//todo 有使用中的连接，就等 5分钟 再检查
return keepAliveDurationNs;
} else {
// No connections, idle or in use.
//todo 都不满足，可能池内没任何连接,直接停止清理(put后会再次启动)
cleanupRunning = false;
return -1;
}
}
closeQuietly(longestIdleConnection.socket());
// Cleanup again immediately.
return 0;
}get方法
首先会遍历连接池里面的各个连接，判断ip端口等是否与要请求的相同，而且该连接是否空闲。都满足的时候，就可以复用。
比如进入isEligible看一看
public boolean isEligible(Address address, @Nullable Route route) {
// If this connection is not accepting new streams, we're done.
//todo 实际上就是在使用(对于http1.1)就不能复用
if (allocations.size() >= allocationLimit || noNewStreams) return false;
// If the non-host fields of the address don't overlap, we're done.
//todo 如果地址不同，不能复用。地址包括了配置的dns、代理、证书以及端口等等 (域名还没判断，所以下面马上判断域名)
if (!Internal.instance.equalsNonHost(this.route.address(), address)) return false;
// If the host exactly matches, we're done: this connection can carry the address.
//todo 都相同，那就可以复用了
if (address.url().host().equals(this.route().address().url().host())) {
return true; // This connection is a perfect match.
}
。。。。。
return true; // The caller's address can be carried by this connection.
}六.CallServerInterceptor
请求服务拦截器，这个拦截器就是完成HTTP协议报文的封装与解析。
有一个需要注意的点，就是需要上传大容量请求体的时候。可以用一个
请求头，代表了先询问服务器是否愿意接收发送请求体数据。
OkHttp是这样处理的
如果服务器允许则返回100，客户端继续发送请求体； 如果服务器不允许则直接返回给用户。 同时服务器也可能会忽略此请求头，一直无法读取应答，此时抛出超时异常。
