OKHttp3源码解析

参考资源

• 官网
• 国内博客
• GitHub官网

鉴于一些关于OKHttp3源码的解析文档过于碎片化，本文系统的，由浅入深得，按照网络请求发起的流程顺序来讲解OkHttp3的源码。在自己学习的同时，给大家分享一些经验。

主要架构和流程

OKHttpClient、Call

OKHttp3在项目中发起网络请求的API如下：

okHttpClient.newCall(request).execute();

OKHttpClient类：

• OKHttpClient 里面组合了很多的类对象。其实是将OKHttp的很多功能模块，全部包装进这个类中，让这个类单独提供对外的API，这种设计叫做外观模式。

• 由于内部功能模块太多，使用了Builder模式(生成器模式)来构造。

它的方法只有一个：newCall.返回一个Call对象(一个准备好了的可以执行和取消的请求)。

Call接口：

public interface Call {
  
  Request request();
 
  //同步的方法，直接返回Response
  Response execute() throws IOException;
  
  //异步的，传入回调CallBack即可(接口，提供onFailure和onResponse方法)
  void enqueue(Callback responseCallback);
  
  void cancel();

  boolean isExecuted();

  boolean isCanceled();

  interface Factory {
    Call newCall(Request request);
  }
}

Call接口提供了内部接口Factory(用于将对象的创建延迟到该工厂类的子类中进行，从而实现动态的配置，工厂方法模式)。

实际的源码中，OKHttpClient实现了Call.Factory接口，返回了一个RealCall对象。

@Override 
public Call newCall(Request request) {
    return new RealCall(this, request);
}

RealCall里面的两个关键方法是：execute 和 enqueue。分别用于同步和异步得执行网络请求。后面会详细介绍。

请求Request、返回数据Response

Request：

    public final class Request {
      //url字符串和端口号信息，默认端口号：http为80，https为443.其他自定义信息
      private final HttpUrl url;
      
      //"get","post","head","delete","put"....
      private final String method;
      
      //包含了请求的头部信息，name和value对。最后的形势为：$name1+":"+$value1+"\n"+ $name2+":"+$value2+$name3+":"+$value3...
      private final Headers headers;
      
      //请求的数据内容
      private final RequestBody body;
      
      //请求的附加字段。对资源文件的一种摘要。保存在头部信息中：ETag: "5694c7ef-24dc"。客户端可以在二次请求的时候，在requst的头部添加缓存的tag信息（如If-None-Match:"5694c7ef-24dc"），服务端用改信息来判断数据是否发生变化。
      private final Object tag;
      
      //各种附值函数和Builder类
      ...
        
     ｝

其中内部类RequestBody: 请求的数据。抽象类:

    public abstract class RequestBody {
     
      ...
      
      //返回内容类型
      public abstract MediaType contentType();
    
      //返回内容长度
      public long contentLength() throws IOException {
        return -1;
      }
    
      //如何写入缓冲区。BufferedSink是第三方库okio对输入输出API的一个封装，不做详解。
      public abstract void writeTo(BufferedSink sink) throws IOException;

    }

OKHttp3中给出了两个requestBody的实现FormBody 和 MultipartBody，分别对应了两种不同的MIME类型："application/x-www-form-urlencoded"和"multipart/"+xxx.作为的默认实现。

Response：

    public final class Response implements Closeable {
      //网络请求的信息
      private final Request request;
      
      //网路协议，OkHttp3支持"http/1.0","http/1.1","h2"和"spdy/3.1"
      private final Protocol protocol;
      
      //返回状态码，包括404(Not found),200(OK),504(Gateway timeout)...
      private final int code;
      
      //状态信息，与状态码对应
      private final String message;
      
      //TLS(传输层安全协议)的握手信息（包含协议版本，密码套件(https://en.wikipedia.org/wiki/Cipher_suite)，证书列表
      private final Handshake handshake;
      
      //相应的头信息，格式与请求的头信息相同。
      private final Headers headers;
      
      //数据内容在ResponseBody中
      private final ResponseBody body;
      
      //网络返回的原声数据(如果未使用网络，则为null)
      private final Response networkResponse;
      
      //从cache中读取的网络原生数据
      private final Response cacheResponse;
      
      //网络重定向后的，存储的上一次网络请求返回的数据。
      private final Response priorResponse;
      
      //发起请求的时间轴
      private final long sentRequestAtMillis;
      
      //收到返回数据时的时间轴
      private final long receivedResponseAtMillis;
    
      //缓存控制指令，由服务端返回数据的中的Header信息指定，或者客户端发器请求的Header信息指定。key："Cache-Control"
      //详见<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9">RFC 2616,14.9</a>
      private volatile CacheControl cacheControl; // Lazily initialized.
        
      //各种附值函数和Builder类型          ...
    }

Note：所有网络请求的头部信息的key，不是随便写的。都是RFC协议规定的。request的header与response的header的标准都不同。具体的见 List of HTTP header fields。OKHttp的封装类Request和Response为了应用程序编程方便，会把一些常用的Header信息专门提取出来，作为局部变量。比如contentType，contentLength，code,message,cacheControl,tag...它们其实都是以name-value对的形势，存储在网络请求的头部信息中。

我们使用了retrofit2，它提供了接口converter将自定义的数据对象（各类自定义的request和response）和OKHttp3中网络请求的数据类型（ReqeustBody和ResponseBody）进行转换。
而converterFactory是converter的工厂模式，用来构建各种不同类型的converter。

故而可以添加converterFactory由retrofit完成requestBody和responseBody的构造。

这里对retrofit2不展开讨论，后续会出新的文章来详细讨论。仅仅介绍一下converterFacotry，以及它是如何构建OkHttp3中的RequestBody和ResponseBody的。

• Note: retrofit2中的Response与okhttp3中的response不同，前者是包含了后者。既retrofit2中的response是一层封装，内部才是真正的okhttp3种的response。

我们项目中的一个converterFacotry代码如下：

    public class RsaGsonConverterFactory extends Converter.Factory {
   
    //省略部分代码
    ...
    
    private final Gson gson;

    private RsaGsonConverterFactory(Gson gson) {
        if (gson == null) throw new NullPointerException("gson == null");
        this.gson = gson;
    } 
    //将返回的response的Type，注释，和retrofit的传进来，返回response的转换器。Gson只需要type就可以将responseBody转换为需要的类型。
    @Override
    public Converter<ResponseBody, ?> responseBodyConverter(Type type, Annotation[] annotations, Retrofit retrofit) {
        TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type));
        return new RsaGsonResponseBodyConverter<>(gson, adapter);
    }
    //将request的参数类型，参数注释，方法注释和retrofit传进来，返回request的转换器。Gson只需要type就可以将request对象转换为OKHttp3的reqeustBody类型。
    @Override
    public Converter<?, RequestBody> requestBodyConverter(Type type, Annotation[] parameterAnnotations, Annotation[] methodAnnotations, Retrofit retrofit) {
        TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type));
        return new RsaGsonRequestBodyConverter<>(gson, adapter);
    }
    }

该Factory(工厂方法模式，用于动态的创建对象)主要是用来生产response的converter和request的converter。显然我们使用了Gson作为数据转换的桥梁。分别对应如下两个类：

• response的converter(之所以命名为Rsa，是做了一层加解密)：

    public class RsaGsonResponseBodyConverter<T> implements Converter<ResponseBody, T> {
        private final Gson gson;
        private final TypeAdapter<T> adapter;
    
        RsaGsonResponseBodyConverter(Gson gson, TypeAdapter<T> adapter) {
            this.gson = gson;
            this.adapter = adapter;
        }
    
        @Override public T convert(ResponseBody value) throws IOException {
            JsonReader jsonReader = gson.newJsonReader(value.charStream());
            try {
                return adapter.read(jsonReader);
            } finally {
                value.close();
            }
        }
    }
  

直接将value中的值封装为JsonReader供Gson的TypeAdapter读取，获取转换后的对象。

• request的converter：

    final class RsaGsonRequestBodyConverter<T> implements Converter<T, RequestBody> {
        private static final MediaType MEDIA_TYPE = MediaType.parse("application/json; charset=UTF-8");
        private static final Charset UTF_8 = Charset.forName("UTF-8");
    
        private final Gson gson;
        private final TypeAdapter<T> adapter;
    
        RsaGsonRequestBodyConverter(Gson gson, TypeAdapter<T> adapter) {
            this.gson = gson;
            this.adapter = adapter;
        }
    
        @Override public RequestBody convert(T value) throws IOException {
    
            Buffer buffer = new Buffer();
            Writer writer = new OutputStreamWriter(buffer.outputStream(), UTF_8);
            JsonWriter jsonWriter = gson.newJsonWriter(writer);
    
            adapter.write(jsonWriter, value);
            jsonWriter.close();
            //如果是RsaReq的子类，则进行一层加密。
            if(value instanceof RsaReq){
               //加密过程
            }
            //不需要加密，则直接读取byte值，用来创建requestBody
            else {
                //这个构造方法是okhttp专门为okio服务的构造方法。
                return RequestBody.create(MEDIA_TYPE, buffer.readByteString());
            }
        }
    }   
  

上面的流操作使用的是第三方库okio。可以看到，retrofit，okhttp,okio这三个库是完全相互兼容并互相提供了专有的API。

请求的分发和线程池技术

OKHttpClient类中有个成员变量dispatcher负责请求的分发。既在真正的请求RealCall的execute方法中，使用dispatcher来执行任务：

• RealCall的execute方法：

    @Override 
    public Response execute() throws IOException {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    try {
      //使用dispatcher 来分发任务
      client.dispatcher().executed(this);
      Response result = getResponseWithInterceptorChain();
      if (result == null) throw new IOException("Canceled");
      return result;
    } finally {
      client.dispatcher().finished(this);
    }
    }
  

• RealCall的enqueue方法：

    @Override public void enqueue(Callback responseCallback) {
        synchronized (this) {
          if (executed) throw new IllegalStateException("Already Executed");
          executed = true;
        }
        //使用dispatcher来将人物加入队列
        client.dispatcher().enqueue(new AsyncCall(responseCallback));
      }
  

OKHttp3中分发器只有一个类 ——Dispathcer.

Dispathcer

(1) 其中包含了线程池executorService：

 public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
  }

参数：

• 0:核心线程数量。保持在线程池中的线程数量(即使已经空闲)，为0代表线程空闲后不会保留，等待一段时间后停止。
• Integer.MAX_VALUE: 线程池可容纳线程数量。
• 60，TimeUnit.SECONDS: 当线程池中的线程数大于核心线程数时，空闲的线程会等待60s后才会终止。如果小于，则会立刻停止。
• new SynchronousQueue<Runnable>():线程的等待队列。同步队列，按序排队，先来先服务。
  Util.threadFactory("OkHttp Dispatcher", false)： 线程工厂，直接创建一个名为 “OkHttp Dispathcer”的非守护线程。

(2) 执行同步的Call：直接加入runningSyncCalls队列中，实际上并没有执行该Call，交给外部执行。

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

(3) 将Call加入队列：如果当前正在执行的call数量大于maxRequests,64,或者该call的Host上的call超过maxRequestsPerHost，5，则加入readyAsyncCalls排队等待。否则加入runningAsyncCalls，并执行。

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

(4) 从ready到running的轮转，在每个call 结束的时候调用finished，并：

    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!");
          //每次remove完后，执行promoteCalls来轮转。
          if (promoteCalls) promoteCalls();
          runningCallsCount = runningCallsCount();
          idleCallback = this.idleCallback;
        }
        //线程池为空时，执行回调
        if (runningCallsCount == 0 && idleCallback != null) {
          idleCallback.run();
        }
      }

(5) 线程轮转：遍历readyAsyncCalls，将其中的calls添加到runningAysncCalls，直到后者满。

    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; 
        }
      }  

执行请求

同步的请求RealCall 实现了Call接口:
可以execute,enqueue和cancle。
异步的请求AsyncCall（RealCall的内部类）实现了Runnable接口:
只能run(调用了自定义函数execute).

execute 对比：

• RealCall：

  @Override public Response execute() throws IOException {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    try {
      //分发。实际上只是假如了队列，并没有执行
      client.dispatcher().executed(this);
      //实际上的执行。
      Response result = getResponseWithInterceptorChain();
      //返回结果
      if (result == null) throw new IOException("Canceled");
      return result;
    } finally {
      //执行完毕，finish
      client.dispatcher().finished(this);
    }
  }
  

• AsyncCall:

    @Override protected void execute() {
          boolean signalledCallback = false;
          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) {
            if (signalledCallback) {
              Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
            } else {
              responseCallback.onFailure(RealCall.this, e);
            }
          } finally {
            //执行完毕，finish
            client.dispatcher().finished(this);
          }
        }

实际上的执行函数都是getResponseWithInterceptorChain()：

    private Response getResponseWithInterceptorChain() throws IOException {
        //创建一个拦截器列表
        List<Interceptor> interceptors = new ArrayList<>();
        //优先处理自定义拦截器
        interceptors.addAll(client.interceptors());
        //失败重连拦截器
        interceptors.add(retryAndFollowUpInterceptor);
        //接口桥接拦截器(同时处理cookie逻辑)
        interceptors.add(new BridgeInterceptor(client.cookieJar()));
        //缓存拦截器
        interceptors.add(new CacheInterceptor(client.internalCache()));
        //分配连接拦截器
        interceptors.add(new ConnectInterceptor(client));
        //web的socket连接的网络配置拦截器
        if (!retryAndFollowUpInterceptor.isForWebSocket()) {
          interceptors.addAll(client.networkInterceptors());
        }
        //最后是连接服务器发起真正的网络请求的拦截器
        interceptors.add(new CallServerInterceptor(
            retryAndFollowUpInterceptor.isForWebSocket())); 
        Interceptor.Chain chain = new RealInterceptorChain(
            interceptors, null, null, null, 0, originalRequest);
        //流式执行并返回response
        return chain.proceed(originalRequest);
      }

这里的拦截器的作用：将一个流式工作分解为可配置的分段流程，既实现了逻辑解耦，又增强了灵活性，使得该流程清晰，可配置。

各个拦截器(Interceptor)

这里的拦截器有点像安卓里面的触控反馈的Interceptor。既一个网络请求，按一定的顺序，经由多个拦截器进行处理，该拦截器可以决定自己处理并且返回我的结果，也可以选择向下继续传递，让后面的拦截器处理返回它的结果。这个设计模式叫做责任链模式。

与Android中的触控反馈interceptor的设计略有不同的是，后者通过返回true 或者 false 来决定是否已经拦截。而OkHttp这里的拦截器通过函数调用的方式，讲参数传递给后面的拦截器的方式进行传递。这样做的好处是拦截器的逻辑比较灵活，可以在后面的拦截器处理完并返回结果后仍然执行自己的逻辑；缺点是逻辑没有前者清晰。

拦截器接口的源码：

public interface Interceptor {
 Response intercept(Chain chain) throws IOException;

 interface Chain {
   Request request();

   Response proceed(Request request) throws IOException;

   Connection connection();
 }
}

其中的Chain是用来传递的链。这里的传递逻辑伪代码如下：
代码的最外层逻辑

 Request request = new Request(){};
 
 
 Arrlist<Interceptor> incpts = new Arrlist();
 Interceptor icpt0 = new Interceptor(){ XXX };
 Interceptor icpt1 = new Interceptor(){ XXX };
 Interceptor icpt2 = new Interceptor(){ XXX };
 ...
 incpts.add(icpt0);
 incpts.add(icpt1);
 incpts.add(icpt2);
 
 Interceptor.Chain chain  = new MyChain(incpts);
 chain.proceed(request);

封装的Chain的内部逻辑

 public class MyChain implement Interceptor.Chain{
    Arrlist<Interceptor> incpts;
    int index = 0;
    
    public MyChain(Arrlist<Interceptor> incpts){
        this(incpts, 0);
    }
    
    public MyChain(Arrlist<Interceptor> incpts, int index){
        this.incpts = incpts;
        this.index =index;
    }
    
    public void setInterceptors(Arrlist<Interceptor> incpts ){
        this.incpts = incpts;
    }
 
    @override
    Response proceed(Request request) throws IOException{
            Response response = null;
            ...
            //取出第一个interceptor来处理
            Interceptor incpt = incpts.get(index);
            //生成下一个Chain，index标识当前Interceptor的位置。
            Interceptor.Chain nextChain = new MyChain(incpts,index+1);
            response =  incpt.intercept(nextChain);
            ...
            return response;
    }
  } 

各个Interceptor类中的实现：

public class MyInterceptor implement Intercetpor{
    @Override 
    public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
        //前置拦截逻辑
        ...
        Response response = chain.proceed(request);//传递Interceptor
        //后置拦截逻辑
        ...
        return response;
    }
}

在这个链中，最后的一个Interceptor一般用作生成最后的Response操作，它不会再继续传递给下一个。

• 失败重连以及重定向的拦截器：RetryAndFollowUpInterceptor

  失败重连拦截器核心源码：
  一个循环来不停的获取response。每循环一次都会获取下一个request，如果没有，则返回response，退出循环。而获取下一个request的逻辑，是根据上一个response返回的状态码，分别作处理。

intercept方法源码：

    @Override public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
    
        ...
    
        int followUpCount = 0;
        Response priorResponse = null;
        
        //循环入口
        while (true) {
          ...
    
          Response response = null;
          try {
            //一次请求处理，获得结果
            response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
          } catch (RouteException e) {
            ...
            continue;
          } catch (IOException e) {
            ...
            continue;
          } finally {
            ...
          }
    
          // 如果前一次请求结果不为空，讲它添加到新的请求结果中。通常第一次请求一定是异常请求结果，一定没有body。
          if (priorResponse != null) {
            response = response.newBuilder()
                .priorResponse(priorResponse.newBuilder()
                    .body(null)
                    .build())
                .build();
          }
          //获取后续的请求，比如验证，重定向，失败重连...
          Request followUp = followUpRequest(response);
    
          if (followUp == null) {
            ...
            //如果没有后续的请求了，直接返回请求结果
            return response;
          }
           ...      
          //
          request = followUp;
          priorResponse = response;
        }
      }

获取后续的的请求，比如验证，重定向，失败重连

private Request followUpRequest(Response userResponse) throws IOException {
    if (userResponse == null) throw new IllegalStateException();
    Connection connection = streamAllocation.connection();
    Route route = connection != null
        ? connection.route()
        : null;
    int responseCode = userResponse.code();

    final String method = userResponse.request().method();
    switch (responseCode) {
      case HTTP_PROXY_AUTH:
        Proxy selectedProxy = route != null
            ? route.proxy()
            : client.proxy();
        if (selectedProxy.type() != Proxy.Type.HTTP) {
          throw new ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy");
        }
        return client.proxyAuthenticator().authenticate(route, userResponse);

      case HTTP_UNAUTHORIZED:
        return client.authenticator().authenticate(route, userResponse);

      case HTTP_PERM_REDIRECT:
      case HTTP_TEMP_REDIRECT:
        // "If the 307 or 308 status code is received in response to a request other than GET
        // or HEAD, the user agent MUST NOT automatically redirect the request"
        if (!method.equals("GET") && !method.equals("HEAD")) {
          return null;
        }
        // fall-through
      case HTTP_MULT_CHOICE:
      case HTTP_MOVED_PERM:
      case HTTP_MOVED_TEMP:
      case HTTP_SEE_OTHER:
        // Does the client allow redirects?
        if (!client.followRedirects()) return null;

        String location = userResponse.header("Location");
        if (location == null) return null;
        HttpUrl url = userResponse.request().url().resolve(location);

        // Don't follow redirects to unsupported protocols.
        if (url == null) return null;

        // If configured, don't follow redirects between SSL and non-SSL.
        boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
        if (!sameScheme && !client.followSslRedirects()) return null;

        // Redirects don't include a request body.
        Request.Builder requestBuilder = userResponse.request().newBuilder();
        if (HttpMethod.permitsRequestBody(method)) {
          if (HttpMethod.redirectsToGet(method)) {
            requestBuilder.method("GET", null);
          } else {
            requestBuilder.method(method, null);
          }
          requestBuilder.removeHeader("Transfer-Encoding");
          requestBuilder.removeHeader("Content-Length");
          requestBuilder.removeHeader("Content-Type");
        }

        // When redirecting across hosts, drop all authentication headers. This
        // is potentially annoying to the application layer since they have no
        // way to retain them.
        if (!sameConnection(userResponse, url)) {
          requestBuilder.removeHeader("Authorization");
        }

        return requestBuilder.url(url).build();

      case HTTP_CLIENT_TIMEOUT:
        // 408's are rare in practice, but some servers like HAProxy use this response code. The
        // spec says that we may repeat the request without modifications. Modern browsers also
    // repeat the request (even non-idempotent ones.)
    if (userResponse.request().body() instanceof UnrepeatableRequestBody) {
      return null;
    }

    return userResponse.request();

  default:
    return null;
}

}

• 桥接拦截器BridgeInterceptor

桥接拦截器的主要作用是将：

1. 请求从应用层数据类型类型转化为网络调用层的数据类型。

   
   

2. 将网络层返回的数据类型 转化为 应用层数据类型。

        1. 保存最新的cookie(默认没有cookie，需要应用程序自己创建，详见
                    [Cookie的API]
                    (https://square.github.io/okhttp/3.x/okhttp/okhttp3/CookieJar.html)
                    和
                    [Cookie的持久化]
                    (https://segmentfault.com/a/1190000004345545))；
        2. 如果request中使用了"gzip"压缩，则进行Gzip解压。解压完毕后移除Header中的"Content-Encoding"和"Content-Length"（因为Header中的长度对应的是压缩前数据的长度，解压后长度变了，所以Header中长度信息实效了）；
        3. 返回response。
   

补充：Keep－Alive 连接：
HTTP中的keepalive连接在网络性能优化中，对于延迟降低与速度提升的有非常重要的作用。
通常我们进行http连接时，首先进行tcp握手，然后传输数据，最后释放

http连接

这种方法的确简单，但是在复杂的网络内容中就不够用了，创建socket需要进行3次握手，而释放socket需要2次握手(或者是4次)。重复的连接与释放tcp连接就像每次仅仅挤1mm的牙膏就合上牙膏盖子接着再打开接着挤一样。而每次连接大概是TTL一次的时间(也就是ping一次)，在TLS环境下消耗的时间就更多了。很明显，当访问复杂网络时，延时（而不是带宽）将成为非常重要的因素。
当然，上面的问题早已经解决了，在http中有一种叫做keepalive connections的机制，它可以在传输数据后仍然保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而不需要再次握手

Keep-Alive连接

在现代浏览器中，一般同时开启6～8个keepalive connections的socket连接，并保持一定的链路生命，当不需要时再关闭；而在服务器中，一般是由软件根据负载情况决定是否主动关闭。

• 缓存拦截器CacheInterceptor

缓存拦截器的主要作用是将请求 和 返回 关连得保存到缓存中。客户端与服务端根据一定的机制，在需要的时候使用缓存的数据作为网络请求的响应，节省了时间和带宽。

客户端与服务端之间的缓存机制：

• 作用：将HTPTP和HTTPS的网络返回数据缓存到文件系统中，以便在服务端数据没发生变化的情况下复用，节省时间和带宽；

• 工作原理：客户端发器网络请求，如果缓存文件中有一份与该请求匹配（URL相同）的完整的返回数据（比如上一次请求返回的结果），那么客户端就会发起一个带条件（例子，服务端第一次返回数据时，在response的Header中添加上次修改的时间信息：Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT；客户端再次请求的时候，在request的Header中添加这个时间信息：If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT）的获取资源的请求。此时服务端根据客户端请求的条件，来判断该请求对应的数据是否有更新。如果需要返回的数据没有变化，那么服务端直接返回 304 "not modified"。客户端如果收到响应码味304 的信息，则直接使用缓存数据。否则，服务端直接返回更新的数据。具体如下图所示：

  
  带缓存的网络请求流程

客户端缓存的实现：

OKHttp3的缓存类为Cache类，它实际上是一层缓存逻辑的包装类。内部有个专门负责缓存文件读写的类：DiskLruCache。于此同时，OKHttp3还定义了一个缓存接口：InternalCache。这个缓存接口类作为Cache的成员变量其所有的实现，都是调用了Cahce类的函数实现的。它们间具体的关系如下：

缓存的工作机制

InternalCache接口：

    public interface InternalCache {
      Response get(Request request) throws IOException;
    
      CacheRequest put(Response response) throws IOException;
    
      /**
       * 移除request相关的缓存数据
       */
      void remove(Request request) throws IOException;
    
      /**
       * 用网络返回的数据，更新缓存中数据
       */
      void update(Response cached, Response network);
    
      /** 统计网络请求的数据 */
      void trackConditionalCacheHit();
    
      /** 统计网络返回的数据 */
      void trackResponse(CacheStrategy cacheStrategy);
    }

Note:setInternalCache这个方法是不对应用程序开放的，应用程序只能使用cache(Cache cache)这个方法来设置缓存。并且，Cache内部的internalCache是final的，不能被修改。总结：internalCache这个接口虽然是public的，但实际上，应用程序是无法创建它，并附值到OkHttpClient中去的。

那么问题来了，为什么不用Cahce实现InternalCache这个接口，而是以组合的方式，在它的内部实现都调用了Cache的方法呢？
因为：

• 在Cache中，InternalCache接口的两个统计方法：trackConditionalCacheHit和trackResponse (之所以要统计，是为了查看缓存的效率。比如总的请求次数与缓存的命中次数。)需要用内置锁进行同步。
• Cache中，将trackConditionalCacheHit和trackResponse方法 从public变为为privite了。不允许子类重写，也不开放给应用程序。

Cache类：

• 将网络请求的文件读写操作委托给内部的DiskLruCache类来处理。

• 负责将url转换为对应的key。

• 负责数据统计：写成功计数，写中断计数，网络调用计数，请求数量计数，命中数量计数。

• 负责网络请求的数据对象Response 与 写入文件系统中的文本数据 之间的转换。使用内部类Entry来实现。具体如下：

    网络请求的文件流文本格式如下：
            {
                 http://google.com/foo
                 GET
                 2
                 Accept-Language: fr-CA
                 Accept-Charset: UTF-8
                 HTTP/1.1 200 OK
                 3
                 Content-Type: image/png
                 Content-Length: 100
                 Cache-Control: max-age=600
                 ...
              }     
    内存对象的Entry格式如下.
            private static final class Entry {
                private final String url;
                private final Headers varyHeaders;
                private final String requestMethod;
                private final Protocol protocol;
                private final int code;
                private final String message;
                ...
            ｝           
  

通过okio的读写API，实现它们之间灵活的切换。

DiskLruCache类：

简介：一个有限空间的文件缓存。

• 每个缓存数据都有一个string类型的key和一些固定数量的值。
• 缓存的数据保存在文件系统的一个目录下。这个目录必须是该缓存独占的：因为缓存运行时会删除和修改该目录下的文件，因而该缓存目录不能被其他线程使用。
• 缓存限制了总的文件大小。如果存储的大小超过了限制，会以LRU算法来移除一些数据。
• 可以通过edit,update方法来修改缓存数据。每次调用edit，都必须以commit或者abort结束。commit是原子操作。
• 客户端调用get方法来读取一个缓存文件的快照(存储了key,快照序列号，数据源和数据长度)。

缓存使用了日志文件(文件名为journal)来存储缓存的数据目录和操作记录。一个典型的日志文件的文本文档如下：

     //第一行为缓存的名字
     libcore.io.DiskLruCache                            
     1                                                    //缓存的版本
     100                                                 //应用版本
     2                                                   //值的数量          
     //缓存记录：操作 key 第一个数据的长度 第二个数据的长度    
     CLEAN 3400330d1dfc7f3f7f4b8d4d803dfcf6 832 21054    
     DIRTY 335c4c6028171cfddfbaae1a9c313c52
     CLEAN 335c4c6028171cfddfbaae1a9c313c52 3934 2342
     REMOVE 335c4c6028171cfddfbaae1a9c313c52
     DIRTY 1ab96a171faeeee38496d8b330771a7a
     CLEAN 1ab96a171faeeee38496d8b330771a7a 1600 234
     READ 335c4c6028171cfddfbaae1a9c313c52
     READ 3400330d1dfc7f3f7f4b8d4d803dfcf6

操作记录：状态＋key＋额外擦数

• CLEAN key param0 param1：该key的对应的数据为最新的有效数据，后续为额外的参数
• DIRTY key：该key对应的数据被创建或被修改。
• REMOVE key：该key对应的数据被删除。
• READ key：改key对应的数据被读取的记录。——用于LRU算法来统计哪些数据是最新的数据。

一些冗余的操作记录，比如DIRTY,REMOVE...比较多的时候(大于2000个，或者超过总数量)，会发器线程对该日志文件进行压缩(删除这些冗余的日志记录)。此时，会创建一个journal.tmp文件作为临时的文件，供缓存继续使用。同时还有个journal.bkp文件，用作journal文件的临时备份。
换文文件结构如下：

缓存的文件mu lu

工作原理：

• 每个缓存记录在内存中的对象封装为Entry类

     private final class Entry {         
       private final String key; //缓存对应的key
       
       private final long[] lengths; //文件的长度
       private final File[] cleanFiles; //有效的数据文件
       private final File[] dirtyFiles; //正在修改的数据文件
   
       private boolean readable;//是否可读
   
       private Editor currentEditor;//当前的编辑器。一个Entry一个时候只能被一个编辑器修改。
  
       private long sequenceNumber; //唯一序列号，相当于版本号，当内存中缓存数据发生变化时，该序列号会改变。
       
       ...    
       ｝
  

• 创建缓存快照对象，作为每次读取缓存时的一个内容快照对象：

     public final class Snapshot implements Closeable {
       private final String key;   //缓存的key
       private final long sequenceNumber; //创建快照的时候的缓存序列号
       private final Source[] sources;//数据源,okio的API，可以直接读取
       private final long[] lengths;//数据长度。
       ...
       ｝
  

  内容快照作为读去缓存的对象(而不是将Entry直接返回)的作用：
  (1). 内容快照的数据结构方式更便于数据的读取(将file转换为source)，并且隐藏了Entry的细节；
  (2). 内容快照在创建的时候记录了当时的Entry的序列号。因而可以用快照的序列号与缓存的序列号对比，如果序列号不相同，则说明缓存数据发生了修改，该条数据就是失效的。

• 缓存内容Entry的这种工作机制（单个editor，带有序列号的内容快照）以最小的代价，实现了单线程修改，多线程读写的数据对象（否则则需要使用复杂的锁机制）既添降低了逻辑的复杂性，又提高了性能（缺点就是高并发情况下，导致数据频繁失效，导致缓存的命中率降低）。
• 变化的序列号计数在很多涉及并发读取的机制都有使用。比如：SQlite的连接。

• DiskLruCache缓存文件工作流：

DiskLruCache缓存工作流

其返回的SnapShot数据快照，提供了Source接口(okio),供外部内类Cache直接转化为内存对象Cache.Entry。外部类进一步Canche.Entry转化外OKHttpClient使用的Response。

OkHttpClient从缓存中获取一个url对应的缓存数据的数据格式变化过程如下：

缓存数据格式变化过程

LRU的算法体现在：DiskLreCache的日志操作过程中，每一次读取缓存都产生一个READ的记录。由于缓存的初始化是按照日志文件的操作记录顺序来读取的，所以这相当于把这条缓存数据放置到了缓存队列的顶端，也就完成了LRU算法：last recent used，最近使用到的数据最新。

连接拦截器 和 最后的请求服务器的拦截器

这两个连接器基本上完成了最后发起网络请求的工作。追所以划分为两个拦截器，除了解耦之外，更重要的是在这两个流程之间还可以插入一个专门为WebSocket服务的拦截器( WebSocket一种在单个 TCP 连接上进行全双工通讯的协议,本文不做详解)。

关于OKHttp如何真正发起网络请求的，下面专门详细讲解。

发起网络请求

• 简介：OKHttp的网络请求的实现是socket(应用程序与网络层进行交互的API)。socket发起网络请求的流程一般是：
  (1). 创建socket对象;
  (2). 连接到目标网络;
  (3). 进行输入输出流操作。
• 在OKHttp框架里面，(1)(2)的实现，封装在connection接口中，具体的实现类是RealConnection。（3）是通过stream接口来实现，根据不同的网络协议，有Http1xStream和Http2xStream两个实现类。
• 由于创建网络连接的时间较久(如果是HTTP的话，需要进行三次握手)，而请求经常是频繁的碎片化的，所以为了提高网络连接的效率，OKHttp3实现了网络连接复用:

• 新建的连接connection会存放到一个缓存池connectionpool中。网络连接完成后不会立即释放，而是存活一段时间。网络连接存活状态下，如果有相同的目标连接，则复用该连接，用它来进行写入写出流操作。
• 统计每个connection上发起网络请求的次数，若次数为0，则一段时间后释放该连接。
• 每个网络请求对应一个stream，connection，connectionpool等数据，将它封装为StreamAllocation对象。

具体的流程见下图：

网络请求API流程

类之间的关系如下：

类之间的关系

几个主要的概念：

Connection:连接。

真正的底层实现网络连接的接口。它包含了连接的路线，物理层socket，连接协议，和握手信息。

public interface Connection {
  /** 返回连接线路信息(包涵url，dns，proxy) */
  Route route();

  /**
   * 返回连接使用的Socket(网络层到应用层之间的一层封装)
   */
  Socket socket();

  /**
   * 返回传输层安全协议的握手信息
   */
  Handshake handshake();

  /**
   * 返回网络协议：Http1.0,Http1.1,Http2.0...
   */
  Protocol protocol();
}

在OKHttp3中的实现：RealConnection.

• 包含了连接的信息，包括socket，它是与网络层交互的接口，真正实现网络连接；
• 内部维护了一个列表List<StreamAllocation>，相当于发起网络请求的引用计数容器。下面详细讨论。
• 包涵输入输出流，source和sink。但是Connection只负责将socket的操作，与source和sink建立起连接，针对source和sink的写入和读取操作，交给响应的Stream完成（解耦）。将socket封装为okio的代码：

    source = Okio.buffer(Okio.source(socket));
    sink = Okio.buffer(Okio.sink(socket));

这就将socket的读写操作标准华为okio的API。

• 还有个内部类framedConnection，专门用来处理Http2和SPDY(goole推出的网络协议)的（不详细讨论）。

Stream: 完成网络请求的读写流程功能。

接口，源码如下：

public interface HttpStream {


  /** 创建请求的输出流*/
  Sink createRequestBody(Request request, long contentLength);

  /** 写请求的头部信息(Header) */
  void writeRequestHeaders(Request request) throws IOException;

  /** 将请求写入sokcet */
  void finishRequest() throws IOException;

  /** 读取网络返回的头部信息(header)*/
  Response.Builder readResponseHeaders() throws IOException;

  /** 返回网络返回的数据 */
  ResponseBody openResponseBody(Response response) throws IOException;

  /**
   * 异步的取消，并释放相关的资源。(connect pool的线程会自动完成)
   */
  void cancel();
}

• 这个功能实际上是从connection中剥离出来：connection负责底层连接的实现，其写入request和读取response的功能交给stream来完成。
• 之所以需要将该功能解耦出来，一个重要的原因：根据不同的网络请求协议，request的写入和response的读出，具有不同的实现。比如http1,http2等，响应的类为Http1xStream，Http2xStream。

ConnectionPool:内存连接池

负责管理HTTP连接，可以复用相同Address（包括url，dns，port，是否加密,proxy等信息）的连接，以减少网络延迟。

• 维护了一个双端队列，默认的实现是：最多5个空闲的连接，这5个连接最多存活5分钟。
• 直到连接被清除，底层的socket连接才会释放。

StreamAllocation: 网络流的分配计数器(下文简称SA)

计数功能：
每发起一个网络请求，都会新建SA对象。由于连接connection可以被复用，所以一个connection可以对应多次网络请求，即多个SA。所以RealConnection中维护了一个SA的列表。每次创建新的SA的时候，会在对应的connection的列表＋1。以下情形下，会把列表－1，并释放SA对应的资源:

• 网络请求完成；
• 网络请求时发生异常；
• 重定向，则release原来的网络请求，并新建新的；
• 重定向次数超过限制(OKHttp3最大20)；
• 网络返回信息头部包涵"Connection:close"的信息；
• 网络返回的数据信息长度未知，则响应的connection不再分配stream。

该引用计数的列表的作用：统计一个connection对应的网络请求的数量，如果为空，则connection进入空闲，开始倒计时回收。未回收之前的connection都可以复用，降低网络延迟(因为创建和销毁连接的开销比较长，如果时HTTP，则需要三次握手)。

SA中的方法：

• newStream: 创建新的连接，并从connectionPool中找能够复用的connection，如果没有能复用的，则新建connection，并加入到connectionPool中。
• acquire：网络被创建，将对应的connection中SA的引用＋1.
• release：网络请求结束，将对应的connection中SA的引用－1.

最后的发起网络请求的代码

    @Override 
    public Response intercept(Chain chain) throws IOException {
    
        //获取httpstream对象，在之前的ConnectInterceptor中创建
        HttpStream httpStream = ((RealInterceptorChain) chain).httpStream();
        StreamAllocation streamAllocation = ((RealInterceptorChain) chain).streamAllocation();
        Request request = chain.request();
    
        long sentRequestMillis = System.currentTimeMillis();
        
        //写请求的header
        httpStream.writeRequestHeaders(request);
        
        //写请求的body
        if (HttpMethod.permitsRequestBody(request.method()) && request.body() != null) {
          Sink requestBodyOut = httpStream.createRequestBody(request, request.body().contentLength());
          BufferedSink bufferedRequestBody = Okio.buffer(requestBodyOut);
          request.body().writeTo(bufferedRequestBody);
          bufferedRequestBody.close();
        }
        
        //完成网络请求
        httpStream.finishRequest();
    
        //读取网络请求返回的header
        Response response = httpStream.readResponseHeaders()
            .request(request)
            .handshake(streamAllocation.connection().handshake())
            .sentRequestAtMillis(sentRequestMillis)
            .receivedResponseAtMillis(System.currentTimeMillis())
            .build();
    
        //读取网络请求返回的body
        if (!forWebSocket || response.code() != 101) {
          response = response.newBuilder()
              .body(httpStream.openResponseBody(response))
              .build();
        }
                    
        ...
        
        //返回结果
        return response;
        }  

深入网络请求Socket

未完待续...