OKHTTP

OkHttp

1.Okhttp 基本实现原理

OkHttp 主要是通过 5 个[拦截器]和 3 个双端队列（2 个异步队列，1 个同步队列）工作。内部实现通过一个责任链模式完成，将网络请求的各个阶段封装到各个链条中，实现了各层的解耦。

# Dispatcher
//异步任务等待队列
private val readyAsyncCalls = ArrayDeque()
//异步任务队列
private val runningAsyncCalls = ArrayDeque()
//同步任务队列
private val runningSyncCalls = ArrayDeque()

OkHttp 的底层是通过 Socket 发送 HTTP 请求与接受响应，但是 OkHttp 实现了连接池的概念，即对于同一主机的多个请求，可以公用一个 Socket 连接，而不是每次发送完 HTTP 请求就关闭底层的 Socket，这样就实现了连接池的概念。而 OkHttp 对 Socket 的读写操作使用的 OkIo 库进行了一层封装。

执行流程：

• 通过构建者构建出OkHttpClient对象,再通过newCall方法获得RealCall请求对象.
• 通过RealCall发起同步或异步请求,而决定是异步还是同步请求的是由线程分发器dispatcher来决定.
• 当发起同步请求时会将请求加入到同步队列中依次执行,所以会阻塞UI线程,需要开启子线程执行.
• 当发起异步请求时会创建一个线程池,并且判断请求队列是否大于最大请求队列64,请求主机数是否大于5,如果大于请求添加到异步等待队列中,否则添加到异步执行队列,并执行任务.

他实现了一个RealInterceptorChain，它持有了按照顺序构建列表interceptors ，先放入用户自定义的interceptors，然后依次放入RetryAndFollowUpInterceptor、BridgeInterceptor、CacheInterceptor、ConnectInterceptor、CallServerInterceptor，注意有一个参数index=0 。
然后调用了RealInterceptorChain.proceed()方法：

可以发现，RealInterceptorChain会先找到interceptors 的第一个（interceptor ），然后再取interceptors 后面的子集，copy一个新的RealInterceptorChain（next），调用interceptor.intercept(next)。
interceptor.intercept(next)内部一般又回去调用 proceed(request: Request)，形成了递归。但是interceptors 会逐渐的往后减少。这就是典型的责任链模式，每一级的interceptor调用到下一级的interceptor，可以修改request或Response 。
OKHTTP的ConnectInterceptor 内部是用的Socket和服务端建立链接的，Socket是TCP的编程API，遵循HTTP报文协议就可以用Socket和服务端进行HTTP通信了。同时Socket还可以复用。
普通的80端口HTTP链接，用普通的Socket即可，443端口的HTTPS链接，就要用val socket: Socket = SSLSocketFactory.getDefault().createSocket("www.baidu.com",443)

image.png

2. OKHTTP的拦截器分析

image.png

addInterceptor与addNetworkInterceptor的区别

二者通常的叫法为应用拦截器和网络拦截器，从整个责任链路来看，应用拦截器是最先执行的拦截器，也就是用户自己设置request属性后的原始请求，而网络拦截器位于ConnectInterceptor和CallServerInterceptor之间，此时网络链路已经准备好，只等待发送请求数据。

1. 首先，应用拦截器在RetryAndFollowUpInterceptor和CacheInterceptor之前，所以一旦发生错误重试或者网络重定向，网络拦截器可能执行多次，因为相当于进行了二次请求，但是应用拦截器永远只会触发一次。另外如果在CacheInterceptor中命中了缓存就不需要走网络请求了，因此会存在短路网络拦截器的情况。
2. 其次，如上文提到除了CallServerInterceptor，每个拦截器都应该至少调用一次realChain.proceed方法。实际上在应用拦截器这层可以多次调用proceed方法（本地异常重试）或者不调用proceed方法（中断），但是网络拦截器这层连接已经准备好，可且仅可调用一次proceed方法。
3. 最后，从使用场景看，应用拦截器因为只会调用一次，通常用于统计客户端的网络请求发起情况；而网络拦截器一次调用代表了一定会发起一次网络通信，因此通常可用于统计网络链路上传输的数据。

3. 网络缓存机制CacheInterceptor

HTTP缓存原理

在HTTP 1.0时代，响应使用Expires头标识缓存的有效期，其值是一个绝对时间，比如Expires:Thu,31 Dec 2020 23:59:59 GMT。当客户端再次发出网络请求时可比较当前时间
和上次响应的expires时间进行比较，来决定是使用缓存还是发起新的请求。
使用Expires头最大的问题是它依赖客户端的本地时间，如果用户自己修改了本地时间，就会导致无法准确的判断缓存是否过期。
因此，从HTTP 1.1 开始使用Cache-Control头表示缓存状态，它的优先级高于Expires，常见的取值为下面的一个或多个。

• private，默认值，标识那些私有的业务逻辑数据，比如根据用户行为下发的推荐数据。该模式下网络链路中的代理服务器等节点不应该缓存这部分数据，因为没有实际意义。
• public 与private相反，public用于标识那些通用的业务数据，比如获取新闻列表，所有人看到的都是同一份数据，因此客户端、代理服务器都可以缓存。
• no-cache 可进行缓存，但在客户端使用缓存前必须要去服务端进行缓存资源有效性的验证，即下文的对比缓存部分，我们稍后介绍。
• max-age 表示缓存时长单位为秒，指一个时间段，比如一年，通常用于不经常变化的静态资源。
• no-store 任何节点禁止使用缓存。

强制缓存
在上述缓存头规约基础之上，强制缓存是指网络请求响应header标识了Expires或Cache-Control带了max-age信息，而此时客户端计算缓存并未过期，则可以直接使用本地缓存内容，而不用真正的发起一次网络请求。
协商缓存
强制缓存最大的问题是，一旦服务端资源有更新，直到缓存时间截止前，客户端无法获取到最新的资源（除非请求时手动添加no-store头），另外大部分情况下服务器的资源无法直接确定缓存失效时间，所以使用对比缓存更灵活一些。
使用Last-Modify / If-Modify-Since头实现协商缓存，具体方法是服务端响应头添加Last-Modify头标识资源的最后修改时间，单位为秒，当客户端再次发起请求时添加If-Modify-Since头并赋值为上次请求拿到的Last-Modify头的值。
服务端收到请求后自行判断缓存资源是否仍然有效，如果有效则返回状态码304同时body体为空，否则下发最新的资源数据。客户端如果发现状态码是304，则取出本地的缓存数据作为响应。

OKHttp不支持的缓存情况
最后需要注意的一点是，OKHttp默认只支持get请求的缓存。
对于标准的RESTful请求，GET就是用来获取数据，最适合使用缓存，而对于数据的其他操作缓存意义不大或者根本不需要缓存。也是基于此在仅支持GET请求的条件下，OKHTTP使用request URL作为缓存的key（当然还会经过一系列摘要算法）。