从OkHttp的源码来看 HTTP

先来了解一下OkHttp的历史，最早是square公司觉得Android给的HttpClient这块的库不太好用，于是乎做了一层包装，再后来他们包装的这个库被Android官方给收回去了，而Android内部的HttpUrlConnection的实现用的其实是OkHttp的代码，而Okhttp是完全重新写的一套HTTP库，包含TCP、TLS的实现，最初是依赖于Google的那套网络框架，而现在完全不依赖了，最终还被Google给收购了，所以，好好了解OkHttp的本质是毋庸置疑的。

先上一下OkHttp的官网瞅下：

看一下它的简单用法：

好，咱们还是以上一节【https://www.cnblogs.com/webor2006/p/10502230.html】获取github的仓库为例，简单用一下OkHttp，如下：

首先增加OkHttp的依赖：

然后来访问这个接口“https://api.github.com/users/webor2006/repos”为例，看下OkHttp是如何来请求的：

运行一下：

其实原因是在build中木有指定Java的编译版本为Java8导致，因为OkHttp库中如今用到了Lambda表达式，所以指定一下：

再次运行：

ok，关于用法就到这，关于OkHttp的具体使用这里就不详细赘述啦，用一用就会了，重点是分析它的原理机制，直接开始看源码了，首先先看下它：

其中Request又是采用Builder模式来构建的，真的是无处不见Builder模式：

点进去看一下源码：

可以发现是由RealCall来返回的，很明显RealCall是Call的具体实现，所以点击RealCall.newRealCall看下它的源码：

其中为啥第二个参数名叫originalRequest，也就是在之后会对这个Request进行转型，所以这是一个最初始的状态；第三个参数涉及到了WebSocket，那啥叫WebSocket呢，百度百科一下：

也就是说它其实是HTTP的一种扩展，正常的HTTP服务器端是不可能主动给客户端消息推送的，而WebSocket一般是炒股交易的软件会用，因为消息会比较实时，通常软件是不会用到它的，了解一下既可。

接下来再继续：

那这个eventListener有啥用呢？HTTP请求过程中有各种状态，如TCP连接、SSL连接、请求等状态，它主要是用来记录这些状态用的，不重要，貌似这个方法比较简单，接着来就需要分析一下它了：

走进去：

很明显它的实现应该是在RealCall里面如下：

分析核心代码，首先调用eventListener中的一个状态方法：

然后接下来一句就是核心代码了：

这句代码涉及到三个东东：dispatcher()、enqueue()、AsyncCall，所以分别来了解一下：

dispatcher()：

那瞅一下Dispatcher类：

而它用到了线程池：

假如想要所有的请求一个个先后执行，那只要将上面的max设置为1既可。

enqueue()：

接下来则看一下它的源码：

这里有三个队列定义于Dispatcher类中，如下：

所以说Dispatcher类就是一个任务调度类。

AsyncCall：

enqueue方法参数中还涉及到此类，先来瞅一下：

貌似对于Runnable应该里面会有一个run()方法吧，可AsyncCall中木有看到，如它的结构所示：

那有可能定义在它的父类NamedRunnable中，所以瞅一下：

final class AsyncCall extends NamedRunnable {
    private final Callback responseCallback;
    private volatile AtomicInteger callsPerHost = new AtomicInteger(0);

    AsyncCall(Callback responseCallback) {
      super("OkHttp %s", redactedUrl());
      this.responseCallback = responseCallback;
    }

  　...

    @Override protected void execute() {
      boolean signalledCallback = false;
      timeout.enter();
      try {
        Response response = getResponseWithInterceptorChain();
        if (retryAndFollowUpInterceptor.isCanceled()) {
          signalledCallback = true;
          responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
        } else {
          signalledCallback = true;
          responseCallback.onResponse(RealCall.this, response);
        }
      } catch (IOException e) {
        e = timeoutExit(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);
      }
    }
  }

那这里面应该就是整个请求处理的关键，下面来搞定它：

不过这里暂且不深入分析它，先来总结一下enqueue()的整个流程：它会去调用Dispather.enqueue()方法，而这个方法会生成一个AsyncCall对象，最终会执行AsyncCall.execute()方法，然后最终再真正请求给出结果反馈。

另外对于OkHttp的经典使用除了enqueue()异常请求之外，还有一个execute()方法，它是同步的，也来大致瞅一下它的实现：

也就是enqueue()和execute()就是是否是同步的区别而已。

好，接下来则需要研究两个东东了：

一是OkHttpClient在实用角度（理解OkHttp跟Http的关系）需要理解一下它的配置项；

二是上面提到的拦截链。

好，先来瞅一下OkHttpClient这个类：

这个就是客户端告诉OkHttp支持HTTP的版本，就像浏览器能支持HTTP1.0、HTTP1.2，这个属性就是干这个用的。

所以这个是告诉OkHttp是否支持HTTP，还是支持HTTPS，而HTTPS要怎么支持，也就是对于HTTP的底层支持OkHttp全部都实现了，这就可以看出跟Retrofit的一个区别了，好，继续！

关于这俩在之后再详说，跟拦截器链有关，往下继续：

这个还记得么，回顾一下：

也就是它是用来创建eventListener的东东，往下：

关于它的使用场景在之前HTTPS中已经学习过了，这里简单点击瞅一下：

它是JDK中的接口，其中OkHttp的实现如下：

就不细看了，继续往下看：

对于有自签名的需求用它是非常合适的，这里来简单了解一下它的用法，文档上有描述，如下：

咱们来贴过来试一下：

其中增加了一个验证的选项，这样就不会使用本地根证书进行验证了，就会使用咱们自己的验证方式了，如下：

此时肯定会验证失败，运行如下：

03-15 23:01:48.172 24248-24267/com.okhttpstudy.study E/cexo: Failed!!!Certificate pinning failure!
      Peer certificate chain:
        sha256/uL6J3XldY7njtfGsRP7HZgYsrNPrDZXpG7kT7wfg1m0=: CN=www.baidu.cn,OU=service operation department,O=BeiJing Baidu Netcom Science Technology Co.\, Ltd,L=Beijing,C=CN
        sha256/5kJvNEMw0KjrCAu7eXY5HZdvyCS13BbA0VJG1RSP91w=: CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US
        sha256/r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E=: CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
      Pinned certificates for baidu.com:
        sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

其会在错误中会将此网站的所有签名信息都会列出来，此时要想自签名让其通过验证，则将错误提示的三个sha值添加到okhttpclient上，如下：

这个当有自签名的需求时还是比较好用滴。再继续：

那具体是怎么用它的呢？

简单瞅下它：

至此整个OkHttpClient的字段都过了一遍，很明显通过了解这些字段的含义能知道OkHttp底层做了好多事，清楚的能看到到处有http的身影。

接下来则需要研究Okhttp最核心的拦截器链啦，如下：

点进去瞅瞅它的实现：

其中首先是准备各种interceptor，如下：

接着将其生成一个InterceptorChain对像，如下：

用图来表达一下拦截器链：

最后执行拦截器链的proceed()，此时其实是这么个过程：

为啥要一个链呢？这里可以举一个汉堡相关的例子用来理解：有人打电话进来订了汉堡的餐，然后店老板将汉堡做好了并且给负责分发的员工，接着送餐员到店取了汉堡骑着电动送到订餐人的家里，然后送餐员将汉堡给了订餐的人，与此同时订餐人将钱给了送餐员，送餐员又拿着钱回到了店里，并从中拿了1块钱的提成，然后将剩下的钱全部交给了负责分发的店员，然后店员又将钱交给了店长，这就是一个链，店长是链的起点【做汉堡并分配给店员】和终点【从店员中拿到钱】。当一个事件比较复杂的时候采用链的方式会职责清晰，每一个链则就是拦截器。

其中关于proceed()这里还是以上面举的汉堡的店长为例进一步阐述一下：其实对于店长的proceed()过程就是“做汉堡并分发给店员--->等待收钱---->收钱之后装进自己的裤腰袋”，而结合图的第一个节点表示店长的链，其过程其实是这样：