系列文章目录
一、OkHttp源码分析（1）- 总体框架介绍
二、OkHttp源码分析（2）- OkHttpClient - OkHttp的“ApplicationContext”
三、OkHttp源码分析（3）- Dispatcher - 线程资源管理和分配
四、OkHttp源码分析（4）- Call - 一次完整的用户请求封装
五、OkHttp源码分析（5）- Interceptor调用链 - Http协议通信流程的实现和扩展
六、OkHttp源码分析（6）- Transmitter - OkHttp的“CallContext”
七、OkHttp源码分析（7）- Exchange层 - 连接应用层实现和传输层实现
八、OkHttp源码分析（8）- OkHttpClient的对Connection的封装和管理
九、OkHttp源码分析（9）- OkHttpClient是如果通过java.net实现网络I/O的
文章目录
前言
首先我先介绍一下研究OkHttp源码的动机吧，之前学习netty的时候想自己写一个简单的HttpClient，但又不希望只是实现一次简单的Http收发。对于Http规范在字面上的体现，我相信大家都很熟悉，但是对于一个工程级别的HttpClient实现，怎么样才算合格甚至于完善？是否一定要实现全部的Http规范，还是只需要实现部分，同时这些规范又是如何在代码中落地的？对于这些我似乎都是一脸懵逼！所以接下来我就决定了两件事，第一是买一本《Http权威指南》作为枕头，第二就是准备研读OkHttp的源码。
我虽然做过一段时间的Android开发，但是现在已经转为后端了。对于OkHttp在Android端的一些新特性我可能已经不够了解了，同时在研读代码的时候，我也可能会带入后端的技术栈，比如类比一些实现的时候，可能举的就是后端框架的例子。
对于OkHttp的源码理解，多数都是我自己一行行去读的，然后再结合自己的知识体系去总结，水平有限，难免有错误的地方。对于OkHttp的源码分析，网上也有不少相关文章，因此小伙伴们可以相互参考和对比一下，再结合自己的思考，或许才能得到正确的理解，同时如果发现有什么不对的地方，也欢迎斧正，后面随着我自己的学习和理解我也会不断修正这些文章。
OkHttp源码版本：
OkHttp-3.14.10
OkHttp总体框架介绍
对于OkHttp整体框架的介绍，网上的文章有很多，同时也配有一些图解（当然很多都是一样的就是了），总体上我和大家的理解也是相近的。但是呢，我觉得还不够具体也不够完善，因为我想知道，如果我自己要实现一个HttpClient到底要做到什么程度？所以我希望能更加详细地去理解OKHttp的设计和实现。
下面这幅是我自己描绘的OkHttp框架层次图（图比较大可能需要鼠标左键图片才能看清楚）：
下面先来简单介绍一下OkHttp的各个层次，后面会有更加详细的文章专门去解读它们。
OkHttpClient
OkHttpClient在一个应用往往只会创建一个单例。
对外主要是两个功能：一个是可配置，比如你可以设置超时时间，配置自定义的CookieJar实现，配置多个自定义的Interceptor实现，添加事件监听等等；另外一个是提供newCall API，我们用的最多也是这个API。
对内它的配置会被全局范围内使用，同时也负责创建和管理一些全局单例对象，比如Dispatcher、ConnectionPool等。
所以OkHttpClient有点类似一个全局的应用上下文。
Dispatcher
Dispatcher主要管理异步请求任务策略，负责分配异步线程资源，控制异步连接数，只覆盖线程资源层面的逻辑，往下的执行过程对其来说是透明的。
而对于同步任务，Dispatcher只是简单记录当前运行的任务实体（RealCall），并且是由RealCall主动注册和注销。
Dispatcher是final类，不提供扩展接口，但是Dispatcher存在两个构造方法：Dispatcher()和Dispatcher(ExecutorService)。OkHttpClient默认会使用无参构造函数创建一个全局的单例对象，该对象使用内置的线程池来执行异步任务，如果用户想使用自定义线程池，那么可以通过使用有参构造函数创建一个新的Dispatcher对象，并且通过OkHttpClient.Builder设置进去。
Call
OkHttp一次用户请求任务的接口定义，有两个实现：RealCall和AsyncCall，前者是同步任务，后者是异步任务。
这里我之所以把Call称作为“一次用户请求”，是因为一次OkHttp请求和响应，中间可能夹着多个请求和响应，比如代理服务的认证、失败重试、重定向等等，但是这些对于OkHttp的使用者来说都是透明的，他们很多时候只需要感知最初的请求和最后的结果即可，而Call是包含中间这些所有的过程的，因此我把Call称为“一次用户请求”。
Interceptor调用链
Interceptor接口在OKHttp包下有5个内置实现，也就是上图中最大的那一个框。它们通过责任链的方式调用，实现了Http协议的整个流程，当然这个流程指的是应用层协议的流程，不包括底下传输层的实现。
Interceptor是可扩展可配置的，用户可以自定义实现Interceptor接口，并且通过OkHttpClient添加到Http流程的实现中去。
OKHttpClient有两个可配置的Interceptor集合（它们默认都是空的）：interceptors和networkInterceptors。interceptors会被添加到调用链的最前面；而networkInterceptors则会被添加到Socket连接之后，Socket读写数据之前。但是如果是WebSocket请求，networkInterceptors集合则不会被添加到调用链中去。
Response getResponseWithInterceptorChain() throws IOException {
// Build a full stack of interceptors.
List<Interceptor> interceptors = new ArrayList<>();
//用户自定义的拦截器会在请求最开始被调用，也就是递归的最上层
interceptors.addAll(client.interceptors());
//失败重试，代理认证、重定向等
interceptors.add(new RetryAndFollowUpInterceptor(client));
//重写请求和响应头，Cookie存储
interceptors.add(new BridgeInterceptor(client.cookieJar()));
//Http缓存流程实现
interceptors.add(new CacheInterceptor(client.internalCache()));
//发起Socket连接
interceptors.add(new ConnectInterceptor(client));
//Socket连接和数据读写之间，但是WebSocket请求不会添加这个拦截器集合
//可能WebSocket，数据通信走的是传输层，而Interceptor是应用层协议的接口？
if (!forWebSocket) {
interceptors.addAll(client.networkInterceptors());
}
//数据的读写，真正的网络I/O
interceptors.add(new CallServerInterceptor(forWebSocket));
...
}
Transmitter
Transmitter翻译过来有“传输者、传播者”的意思，所以在这里我还是用上下文来称呼它，作用域是整个Call任务。
Transmitter会在Interceptor调用链中相互传递，Interceptor会通过Transmitter对象的属性或者方法对底下的传输层进行操作，Transmitter对调用者屏蔽了传输层的实现细节，让Interceptor调用链专注于应用层协议的实现。
Transmitter管理着Call任务的很多状态（比如请求开始、请求结束、失败、取消等等），调用者随时可以获取Call的状态从而实现相应的逻辑处理，也可以根据处理的结果更新其状态。
Transmitter还持有用户配置，实现了超时回调机制等等。
Transmitter往下的代码耦合性挺强的，层次之间其实没有上面那图那么清晰，它直接会存在一些交叉，彼此之间相互调用，个人觉得这部分代码可读性是挺差的 - -！。同时多数类都是final类，并不向上提供接口，也就是这部分代码是不可扩展的，只是留有一些可配置的参数属性（比如：连接池最大空闲连接数），我不知道这是OkHttp历史版本迭代的原因，还是作者有意这样设计，如果有小伙伴对这方面有了解的话，希望可以留言跟大家分享一下。
Exchange层
这个名字是我直接根据它几个主要实现类的名称前缀来取的，可能不能很好表明这一层的具体功能。总的来说这一层主要负责连接应用层和传输层，例如：Http协议作为应用层协议，它的主要流程由上面的Interceptor调用链来实现，但是Interceptor不会直接和传输层的实现类打交道，而是通过Exchange提供的API去实现数据的读写。
Exchange层主要有三个类：Exchange、ExchangeFinder和ExchangeCodec，前两个都是Transmitter的属性，第三个有ExchangeFinder创建。
-
Exchange
Exchange代表着一次Request和Response，里面封装了应用层的读写方法，Interceptor调用链就是通过Transmitter获取的Exchange对象来进行读写操作。一次Request和Response，也即是上面的Interceptor调用链从RetryAndFollowUpInterceptor到CallServerInterceptor绕了一圈，但是一个Call任务并不代表仅仅只会绕一圈，比如你访问百度之前需要通过你公司的代理服务器，那么就可能在发送请求到百度之前，先发送一次Http请求到代理服务认证，认证通过了才会继续发送请求到百度，这样就绕了两圈了，也就是发送了两次Http请求，同理还有重定向也是一样。简单来说一次用户请求是一个Call，一个Call可能会发生多次Exchange，但是对于用户来说Exchange是透明的，只需要感知Call即可。 -
ExchangeCodec
OkHttp的编解码器，这是一个接口，具体实现有Http1ExchangeCodec和Http2ExchangeCodec。
下面这图展示的是Exchange、ExchangeCodec、Okio和网络I/O，在读写操作上的层次关系。
-
ExchangeFinder
ExchangeFinder类似一个工厂类，对外只提供一个方法，就是返回一个ExchangeCodec对象，下面这段代码能比较清楚展示Exchange、ExchangeCodec和ExchangeFinder三者之间的关系。
/** Returns a new exchange to carry a new request and response. */
Exchange newExchange(Interceptor.Chain chain, boolean doExtensiveHealthChecks) {
...
ExchangeCodec codec = exchangeFinder.find(client, chain, doExtensiveHealthChecks);
Exchange result = new Exchange(this, call, eventListener, exchangeFinder, codec);
...
}
同时ExchangeFinder还负责获取和创建RealConnection，ExchangeFinder和RealConnectionPool也有比较强的耦合关系，这个后面的文章会详细介绍。
链接
- Connection
Connection封装了Socket的连接操作，包括TCP连接，TLS连接，在代理隧道上构建Https连接等。一个连接创建成功后可以在存活时间内被反复使用，但是不能同时处理多个Call任务。获取Connection后，就可以通过Connection#socket()方法获取Socket对象进行读写操作。
Connection是一个接口，只有一个实现类RealConnection，但是Transmitter声明Connection属性的时候，并没有使用Connection而是直接使用RealConnection，所以实际上我们也无法对其进行扩展。 - RealConnectionPool
RealConnectionPool是一个finnal类，管理RealConnection的链接池。 - Route：路由，例如一个Url可能通过DNS能解析出2个Host，而这2个Host是需要通过代理才能访问的，而这个代理又有两台机器组成负载均衡，那这样就会产生4条线路，每条线路就会被封装成一个Route。
- RouteSelector：Route选择器，会对Route的选择上做一些优化，比如记录最近连接失败的Route，把它放到重试队列最底端，优先使用上次连接成功的Route等。
java.net
这一部分就是Java网络编程的内容，主要是Socket编程。主要类的类包括：Socket、SocketFactory、SSLSocketFactory、Proxy、ProxySelector、CertificateChainCleaner等，后面会有内容对这一部分进行分析。
总结
到这里，我就大体把OkHttp的层次设计概括了一遍，这些内容都是我自己读源码的理解，因此总会有不对的地方。其实读源码是必须自己打开编辑器去读的，你可以参考网上的文章，但是你如果不亲自去研读的话，是挺难理解的，也无法确定它的正确性。所以我也希望小伙伴能看了我的文章之后能够亲自去研读相关的源码，然后对比我的理解，大家相互交流，后面我也会继续带来这个系列的其他文章。