关于java:OkHttp三责任链

前两篇文章，讲述了 OkHttp 的根底的应用与申请的调度状况，而明天就让咱们来看看 OkHttp 的精华之一 - 责任链模式。

后面的文章中咱们看到，当理论进行网络申请时，无论是同步申请还是异步申请都会应用getResponseWithInterceptorChain() 这个办法，所以咱们先从这个办法开始钻研。

  fun getResponseWithInterceptorChain(): Response {
    // Build a full stack of interceptors.
    // 增加各种拦截器 这个前面逐个介绍
    val interceptors = mutableListOf<Interceptor>()
    // 自定义的一个拦截器
    interceptors += client.interceptors
    // 零碎内置的拦截器
    interceptors += RetryAndFollowUpInterceptor(client)
    interceptors += BridgeInterceptor(client.cookieJar)
    interceptors += CacheInterceptor(client.cache)
    interceptors += ConnectInterceptor
    if (!forWebSocket) {interceptors += client.networkInterceptors}
    interceptors += CallServerInterceptor(forWebSocket)
    
    // 创立责任链
    val chain = RealInterceptorChain(interceptors, transmitter, null, 0, originalRequest, this,
        client.connectTimeoutMillis, client.readTimeoutMillis, client.writeTimeoutMillis)

    var calledNoMoreExchanges = false
    try {
      // 执行责任链
      val response = chain.proceed(originalRequest)
      if (transmitter.isCanceled) {response.closeQuietly()
        throw IOException("Canceled")
      }
      return response
    } catch (e: IOException) {
      calledNoMoreExchanges = true
      throw transmitter.noMoreExchanges(e) as Throwable
    } finally {if (!calledNoMoreExchanges) {transmitter.noMoreExchanges(null)
      }
    }
  }

咱们能够看到，该办法中将拦截器逐个增加汇合中，并创立了一个责任链，用 chain.proceed()办法来执行申请。

OkHttp 采纳 责任链的模式 来使每个性能离开，每个 Interceptor 自行实现本人的工作，并且将不属于本人的工作交给下一个，简化了各自的责任和逻辑。

接下来看看 proceed 的办法

 override fun proceed(request: Request): Response {return proceed(request, transmitter, exchange)
  }

  @Throws(IOException::class)
  fun proceed(request: Request, transmitter: Transmitter, exchange: Exchange?): Response {if (index >= interceptors.size) throw AssertionError()

    calls++

    ...
    
    // 获取下一个拦截器，链中的拦截器汇合 index+1
    // Call the next interceptor in the chain.
    val next = RealInterceptorChain(interceptors, transmitter, exchange,
        index + 1, request, call, connectTimeout, readTimeout, writeTimeout)
    val interceptor = interceptors[index]

    @Suppress("USELESS_ELVIS")
    // 执行以后的拦截器 - 如果在配置 okhttpClient，时没有设置 intercept 默认是先执行：retryAndFollowUpInterceptor 拦截器 `
    val response = interceptor.intercept(next) ?: throw NullPointerException("interceptor $interceptor returned null")

    ...

    return response
  }

在该办法中咱们能够看到递归调用了下一个拦截器，当所有拦截器调用结束后，返回咱们所得的 Response。每个拦截器都重写了 intercept（）办法，用以执行申请。

责任链的一个执行过程如下图

接下来让咱们剖析默认责任链的一个作用，并作出一些源码剖析。

其创立过程是在构建 newCall 对象时

private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
    this.client = client;
    this.originalRequest = originalRequest;
    this.forWebSocket = forWebSocket;
    this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);
  }
  ...
  @Override public Call newCall(Request request) {return RealCall.newRealCall(this, request, false /* for web socket */);
  }

简略看一下应用的过程
首先创立了 transmitter 对象，他封装了网络申请相干的信息：连接池，地址信息，网络申请，事件回调，负责网络连接的连贯、敞开，开释等操作。

    var request = chain.request()
    val realChain = chain as RealInterceptorChain
    val transmitter = realChain.transmitter()

而后则进入了网络连接的循环

    // 计数器 屡次相应的次数是由限度的，不同浏览器举荐的次数不同，还特别强调了 HTTP 1.0 协定举荐 5 次。var followUpCount = 0
    var priorResponse: Response? = null
    while (true) {
      // 筹备连贯
      transmitter.prepareToConnect(request)

      if (transmitter.isCanceled) {throw IOException("Canceled")
      }

      var response: Response
      var success = false
      try {
        // 失去最终的后果
        response = realChain.proceed(request, transmitter, null)
        success = true
      } catch (e: RouteException) {
        // The attempt to connect via a route failed. The request will not have been sent.
        // 连贯地址的异样，判断是否能可能复原，也就是是否要重试
        if (!recover(e.lastConnectException, transmitter, false, request)) {throw e.firstConnectException}
        continue
      } catch (e: IOException) {
        // An attempt to communicate with a server failed. The request may have been sent.
        // 连贯服务器的异样 判断网络申请是否曾经开始
        val requestSendStarted = e !is ConnectionShutdownException
        // 同上
        if (!recover(e, transmitter, requestSendStarted, request)) throw e
        continue
      } finally {
        // The network call threw an exception. Release any resources.
        // 开释资源
        if (!success) {transmitter.exchangeDoneDueToException()
        }
      }

      // Attach the prior response if it exists. Such responses never have a body.
      // 如果不为空保留到 Response 中
      if (priorResponse != null) {response = response.newBuilder()
            .priorResponse(priorResponse.newBuilder()
                .body(null)
                .build())
            .build()}

      val exchange = response.exchange
      val route = exchange?.connection()?.route()
      // 判断返回后果 response，是否须要持续欠缺申请，例如证书验证等等
      val followUp = followUpRequest(response, route)
      
      // 如果不须要持续欠缺网络申请，返回 response
      if (followUp == null) {if (exchange != null && exchange.isDuplex) {transmitter.timeoutEarlyExit()
        }
        return response
      }
      
      // 如果 body 内容只能发送一次 间接放回
      val followUpBody = followUp.body
      if (followUpBody != null && followUpBody.isOneShot()) {return response}

      response.body?.closeQuietly()
      if (transmitter.hasExchange()) {exchange?.detachWithViolence()
      }
      
      // 如果曾经超过最大的网络申请追加数，开释连贯，抛出协定异样
      if (++followUpCount > MAX_FOLLOW_UPS) {throw ProtocolException("Too many follow-up requests: $followUpCount")
      }
      // 更新下一次的网络申请对象
      request = followUp
      // 保留上一次的申请后果
      priorResponse = response
    }

而后就是重试阶段 recover（）的源码了

  /**
   * Report and attempt to recover from a failure to communicate with a server. Returns true if
   * `e` is recoverable, or false if the failure is permanent. Requests with a body can only
   * be recovered if the body is buffered or if the failure occurred before the request has been
   * sent.
   */
  private fun recover(
    e: IOException,
    transmitter: Transmitter,
    requestSendStarted: Boolean,
    userRequest: Request
  ): Boolean {
    // The application layer has forbidden retries.
    // 设置了不须要重试
    if (!client.retryOnConnectionFailure) return false

    // We can't send the request body again.
    // body 内容只能发送一次
    if (requestSendStarted && requestIsOneShot(e, userRequest)) return false

    // This exception is fatal.
    // 判断异样类型，是否要持续尝试，// 不会重试的类型：协定异样、Socketet 异样并且网络状况还没开始，ssl 认证异样
    if (!isRecoverable(e, requestSendStarted)) return false

    // No more routes to attempt.
    // 曾经没有其余可用的路由地址了
    if (!transmitter.canRetry()) return false
    // For failure recovery, use the same route selector with a new connection.
    // 其余放回 true
    return true
  }

咱们略微屡一下下面源码的流程：

首先应用了 transmitter 对象（重要），用以提供相应的网络连接相干的货色
而后开始连贯，而后又有着几种状况
- 连贯胜利，且无后续操作（如认证等），间接放回
- 连贯胜利，且有后续操作，则进入下一次循环
- 连贯失败，RouteException 和 IOException 异样，利用 recover（）判断是否重试，不要重试则开释资源，要重试则 continue；
- 连贯胜利，然而重试的次数超过限度，则有问题（能够本人创立拦截器来批改重试次数）。

这个拦截器的性能较为的简略，申请之前对响应头做了一些查看，并增加一些头，而后在申请之后对响应做一些解决（gzip 解压 or 设置 cookie）。

还是让咱们看一下源码。

  override fun intercept(chain: Interceptor.Chain): Response {val userRequest = chain.request()
    val requestBuilder = userRequest.newBuilder()
    
    // 如果咱们有 RequestBody, 会写一些 header 信息，如内容长度和内容类型等
    val body = userRequest.body
    if (body != null) {...}
    
    // 对一些必要的属性进行补充
    if (userRequest.header("Host") == null) {requestBuilder.header("Host", userRequest.url.toHostHeader())
    }

    if (userRequest.header("Connection") == null) {requestBuilder.header("Connection", "Keep-Alive")
    }

    // If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing
    // the transfer stream.
    // 默认的编码格局 gzip
    var transparentGzip = false
    if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
      transparentGzip = true
      requestBuilder.header("Accept-Encoding", "gzip")
    }
    
    // 把之前的 cookie 存在 header 里
    val cookies = cookieJar.loadForRequest(userRequest.url)
    if (cookies.isNotEmpty()) {requestBuilder.header("Cookie", cookieHeader(cookies))
    }

    if (userRequest.header("User-Agent") == null) {requestBuilder.header("User-Agent", userAgent)
    }
    
    // 失去 Response
    val networkResponse = chain.proceed(requestBuilder.build())
    
    // 保留新的 cookie
    cookieJar.receiveHeaders(userRequest.url, networkResponse.headers)

    val responseBuilder = networkResponse.newBuilder()
        .request(userRequest)
    
    // 如果应用的 gzip 编码，并且返回的 response 有 body 信息，对做相应的解决
    if (transparentGzip &&
        "gzip".equals(networkResponse.header("Content-Encoding"), ignoreCase = true) &&
        networkResponse.promisesBody()) {
      val responseBody = networkResponse.body
      if (responseBody != null) {val gzipSource = GzipSource(responseBody.source())
        val strippedHeaders = networkResponse.headers.newBuilder()
            .removeAll("Content-Encoding")
            .removeAll("Content-Length")
            .build()
        responseBuilder.headers(strippedHeaders)
        val contentType = networkResponse.header("Content-Type")
        responseBuilder.body(RealResponseBody(contentType, -1L, gzipSource.buffer()))
      }
    }

    return responseBuilder.build()}

在看这个拦截器的源码之前，咱们还得关注一件事件，OkHttp 的缓存是怎么缓存的呢？

OkHttp 中的Cache 类，采纳了 DiskLruCache，外部应用最近起码应用算法，优先淘汰最近工夫内起码次应用的缓存对象，它只有硬存缓存，并没有内存缓存，这是他缓存机制的一大缺点，当然咱们能够通过自定义缓存机制来解决这一问题。

在 OkHttp 中还存在一个 缓存策略 CacheStrategy
CacheStrategy 的外部工厂类 Factory 中有一个 getCandidate 办法，会依据理论的申请生成对应的 CacheStrategy 类返回，是个典型的简略工厂模式。其外部保护一个 request 和 response，通过指定 request 和 response 来通知 CacheInterceptor 是应用缓存还是应用网络申请，亦或两者同时应用。

理解完之后，咱们来看源码：

  override fun intercept(chain: Interceptor.Chain): Response {
    1. 如果设置缓存并且以后 request 有缓存，则从缓存 Cache 中获取以后申请 request 的缓存 response
    val cacheCandidate = cache?.get(chain.request())

    val now = System.currentTimeMillis()
    
    // 2. 传入的申请 request 和获取的缓存 response 通过缓存策略对象 CacheStragy 的工厂类 get 办法依据一些规定获取缓存策略 CacheStrategy
    //（这里的规定依据申请的 request 和缓存的 Response 的 header 头部信息生成的，比方是否有 noCache 标记位，是否是 immutable 不可变，缓存是否过期等等）val strategy = CacheStrategy.Factory(now, chain.request(), cacheCandidate).compute()
    // 3. 生成的 CacheStrategy 有 2 个变量，networkRequest 和 cacheRequest，如果 networkRequest 为 Null 示意不进行网络申请，如果 cacheResponse 为 null，则示意没有无效缓存 
    val networkRequest = strategy.networkRequest
    val cacheResponse = strategy.cacheResponse

    cache?.trackResponse(strategy)
    
    // 4. 缓存不可用，敞开
    if (cacheCandidate != null && cacheResponse == null) {
      // The cache candidate wasn't applicable. Close it.
      cacheCandidate.body?.closeQuietly()}

    // If we're forbidden from using the network and the cache is insufficient, fail.
    // 5. 如果 networkRequest 和 cacheResponse 都为 Null, 则示意不申请网络且缓存为 null，返回 504，申请失败
    if (networkRequest == null && cacheResponse == null) {return Response.Builder()
          .request(chain.request())
          .protocol(Protocol.HTTP_1_1)
          .code(HTTP_GATEWAY_TIMEOUT)
          .message("Unsatisfiable Request (only-if-cached)")
          .body(EMPTY_RESPONSE)
          .sentRequestAtMillis(-1L)
          .receivedResponseAtMillis(System.currentTimeMillis())
          .build()}

    // If we don't need the network, we're done.
    // 6. 如果不申请网络，但存在缓存，则不申请网络，间接返回缓存，完结，不执行下一个拦截器
    if (networkRequest == null) {return cacheResponse!!.newBuilder()
          .cacheResponse(stripBody(cacheResponse))
          .build()}
    
    // 7. 否则，申请网络，并调用下一个拦截器链，将申请转发到下一个拦截器
    var networkResponse: Response? = null
    try {networkResponse = chain.proceed(networkRequest)
    } finally {
      // If we're crashing on I/O or otherwise, don't leak the cache body.
      if (networkResponse == null && cacheCandidate != null) {cacheCandidate.body?.closeQuietly()
      }
    }
    
    //8. 申请网络，并且网络申请返回 HTTP_NOT_MODIFIED，阐明缓存无效，则合并网络响应和缓存后果，同时更新缓存
    // If we have a cache response too, then we're doing a conditional get.
    if (cacheResponse != null) {if (networkResponse?.code == HTTP_NOT_MODIFIED) {val response = cacheResponse.newBuilder()
            .headers(combine(cacheResponse.headers, networkResponse.headers))
            .sentRequestAtMillis(networkResponse.sentRequestAtMillis)
            .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis)
            // 清空之前的缓冲
            .cacheResponse(stripBody(cacheResponse))
            // 清空申请到的内容，因为内容没有扭转
            .networkResponse(stripBody(networkResponse))
            .build()

        networkResponse.body!!.close()

        // Update the cache after combining headers but before stripping the
        // Content-Encoding header (as performed by initContentStream()).
        cache!!.trackConditionalCacheHit()
        cache.update(cacheResponse, response)
        return response
      } else {cacheResponse.body?.closeQuietly()
      }
    }
    
    //9. 若没有缓存，则写入缓存
    val response = networkResponse!!.newBuilder()
        .cacheResponse(stripBody(cacheResponse))
        .networkResponse(stripBody(networkResponse))
        .build()

    if (cache != null) {if (response.promisesBody() && CacheStrategy.isCacheable(response, networkRequest)) {
        // Offer this request to the cache.
        val cacheRequest = cache.put(response)
        return cacheWritingResponse(cacheRequest, response)
      }
      // 如果申请的办法不须要缓存，移除缓存，例如 post，put
      if (HttpMethod.invalidatesCache(networkRequest.method)) {
        try {cache.remove(networkRequest)
        } catch (_: IOException) {// The cache cannot be written.}
      }
    }

    return response
  }

让咱们简略梳理一下缓存流程

从以后的 Request 中获取缓存，看是否有缓存
非网络申请时，需联合是否有缓存进行判断，如果有缓存，间接返回；如果没有缓存，放回 504
是网络申请时，如果放回 304，则做一个小的修补即可；否则依据缓存策略来判断是否要更新缓存（个别要）。

获取连贯这个过程较为简单，尽力来梳理这个过程。

首先咱们间接来看这个类的源码，不难发现这个类的源码较为简单，次要外围是 transmitter 的办法。

override fun intercept(chain: Interceptor.Chain): Response {
    val realChain = chain as RealInterceptorChain
    val request = realChain.request()
    val transmitter = realChain.transmitter()

    // We need the network to satisfy this request. Possibly for validating a conditional GET.
    val doExtensiveHealthChecks = request.method != "GET"
    
    // 利用重试的责任链生成的 transmitter 类 来获取连贯
    val exchange = transmitter.newExchange(chain, doExtensiveHealthChecks)

    return realChain.proceed(request, transmitter, exchange)
  }

而后咱们来看看这个类，transmitter

/** Returns a new exchange to carry a new request and response. */
  internal fun newExchange(chain: Interceptor.Chain, doExtensiveHealthChecks: Boolean): Exchange {
    ...// 做一些查看
       
    // 获取连贯 调配一个 Connection 和 HttpCodec，为最终的申请做筹备
    val codec = exchangeFinder!!.find(client, chain, doExtensiveHealthChecks)
    val result = Exchange(this, call, eventListener, exchangeFinder!!, codec)
    ...
  }

  fun find(
    client: OkHttpClient,
    chain: Interceptor.Chain,
    doExtensiveHealthChecks: Boolean
  ): ExchangeCodec {val connectTimeout = chain.connectTimeoutMillis()
    val readTimeout = chain.readTimeoutMillis()
    val writeTimeout = chain.writeTimeoutMillis()
    val pingIntervalMillis = client.pingIntervalMillis
    val connectionRetryEnabled = client.retryOnConnectionFailure

    try {
      // 获取连贯
      val resultConnection = findHealthyConnection(
          connectTimeout = connectTimeout,
          readTimeout = readTimeout,
          writeTimeout = writeTimeout,
          pingIntervalMillis = pingIntervalMillis,
          connectionRetryEnabled = connectionRetryEnabled,
          doExtensiveHealthChecks = doExtensiveHealthChecks
      )
      // 设置编码，有 Http1codec 和 Http2codec 两种形式 后者能够复用连贯
      return resultConnection.newCodec(client, chain)
    } catch (e: RouteException) {trackFailure()
      throw e
    } catch (e: IOException) {trackFailure()
      throw RouteException(e)
    }

  // 获取连贯
  @Throws(IOException::class)
  private fun findHealthyConnection(
    connectTimeout: Int,
    readTimeout: Int,
    writeTimeout: Int,
    pingIntervalMillis: Int,
    connectionRetryEnabled: Boolean,
    doExtensiveHealthChecks: Boolean
  ): RealConnection {while (true) {
      // 查找新连贯
      val candidate = findConnection(
          connectTimeout = connectTimeout,
          readTimeout = readTimeout,
          writeTimeout = writeTimeout,
          pingIntervalMillis = pingIntervalMillis,
          connectionRetryEnabled = connectionRetryEnabled
      )

      // If this is a brand new connection, we can skip the extensive health checks.
      // 如果是新连贯 则间接应用
      synchronized(connectionPool) {if (candidate.successCount == 0) {return candidate}
      }

      // Do a (potentially slow) check to confirm that the pooled connection is still good. If it
      // isn't, take it out of the pool and start again.
      // 判断连接池中连贯是否可用，如果不可用，则开释该连贯并从连接池中移除，并持续寻找可用连贯
      if (!candidate.isHealthy(doExtensiveHealthChecks)) {candidate.noNewExchanges()
        continue
      }

      return candidate
    }
  }

接着就是正式获取连贯这一步了，咱们从正文中能够看到，首先从曾经存在的 Connection 来选取连贯，而后从连接池中寻找，最初才是新建连贯。

  /**
   * Returns a connection to host a new stream. This prefers the existing connection if it exists,
   * then the pool, finally building a new connection.
   */
  @Throws(IOException::class)
  private fun findConnection(
    connectTimeout: Int,
    readTimeout: Int,
    writeTimeout: Int,
    pingIntervalMillis: Int,
    connectionRetryEnabled: Boolean
  ): RealConnection {
    var foundPooledConnection = false
    var result: RealConnection? = null
    var selectedRoute: Route? = null
    var releasedConnection: RealConnection?
    val toClose: Socket?
    synchronized(connectionPool) {if (transmitter.isCanceled) throw IOException("Canceled")
      hasStreamFailure = false // This is a fresh attempt.
·     
      // 对现有连贯做一个备份
      releasedConnection = transmitter.connection
      toClose = if (transmitter.connection != null && transmitter.connection!!.noNewExchanges) {
        // 失去要敞开的连贯的 socket
        transmitter.releaseConnectionNoEvents()} else {null}
      
      // 如果能够应用 则应用
      if (transmitter.connection != null) {
        // We had an already-allocated connection and it's good.
        result = transmitter.connection
        releasedConnection = null
      }
      
      // 如果没有能够用的连贯，从连接池中查找
      if (result == null) {
        // Attempt to get a connection from the pool.
        // 以 URL 为 key 查找
        if (connectionPool.transmitterAcquirePooledConnection(address, transmitter, null, false)) {
          foundPooledConnection = true
          result = transmitter.connection
        } else if (nextRouteToTry != null) {
          selectedRoute = nextRouteToTry
          nextRouteToTry = null
        } else if (retryCurrentRoute()) {selectedRoute = transmitter.connection!!.route() // 应用路由地址，能够是代理地址
        }
      }
    }
    // 敞开之前的 socket
    toClose?.closeQuietly()

    ... // 如果下面找到，间接返回
    if (result != null) {
      // If we found an already-allocated or pooled connection, we're done.
      return result!!
    }
    
    // If we need a route selection, make one. This is a blocking operation.
    var newRouteSelection = false
    // 抉择一个不空的路由
    if (selectedRoute == null && (routeSelection == null || !routeSelection!!.hasNext())) {
      newRouteSelection = true
      routeSelection = routeSelector.next()}

    var routes: List<Route>? = null
    synchronized(connectionPool) {if (transmitter.isCanceled) throw IOException("Canceled")

      if (newRouteSelection) {
        // Now that we have a set of IP addresses, make another attempt at getting a connection from
        // the pool. This could match due to connection coalescing.
        routes = routeSelection!!.routes
       
        // 依据 IP 地址和 Route 从连接池进行第二次查找
        if (connectionPool.transmitterAcquirePooledConnection(address, transmitter, routes, false)) {
          foundPooledConnection = true
          result = transmitter.connection
        }
      }

      if (!foundPooledConnection) {if (selectedRoute == null) {selectedRoute = routeSelection!!.next()
        }
        // 如果没有找到，再应用下一个路由汇合
        // Create a connection and assign it to this allocation immediately. This makes it possible
        // for an asynchronous cancel() to interrupt the handshake we're about to do.
        result = RealConnection(connectionPool, selectedRoute!!)
        connectingConnection = result
      }
    }

    // If we found a pooled connection on the 2nd time around, we're done.
    if (foundPooledConnection) {eventListener.connectionAcquired(call, result!!)
      return result!!
    }
    
    // 到这里还没找到连贯，那就去创立这个连贯
    // Do TCP + TLS handshakes. This is a blocking operation.
    result!!.connect(
        connectTimeout,
        readTimeout,
        writeTimeout,
        pingIntervalMillis,
        connectionRetryEnabled,
        call,
        eventListener
    )
    connectionPool.routeDatabase.connected(result!!.route())

    var socket: Socket? = null
    synchronized(connectionPool) {
      connectingConnection = null
      // Last attempt at connection coalescing, which only occurs if we attempted multiple
      // concurrent connections to the same host.
      // 如果 result 连贯是 http2.0 连贯,http2.0 反对一个连贯同时发动多个申请，这里做去重判断，避免创立多个
      if (connectionPool.transmitterAcquirePooledConnection(address, transmitter, routes, true)) {
        // We lost the race! Close the connection we created and return the pooled connection.
        result!!.noNewExchanges = true
        socket = result!!.socket()
        result = transmitter.connection

        // It's possible for us to obtain a coalesced connection that is immediately unhealthy. In
        // that case we will retry the route we just successfully connected with.
        nextRouteToTry = selectedRoute
      } else {connectionPool.put(result!!)
        transmitter.acquireConnectionNoEvents(result!!)
      }
    }
    socket?.closeQuietly()

    eventListener.connectionAcquired(call, result!!)
    return result!!

在这个源码中，呈现了几个新的类，路由 route 类，地址 address 类，咱们简略的来看看这两个类，
Address：封装了所有的能够拜访的地址信息，在这个类中还增加了代理和 dns 的相干信息（在 OkHttpClient 中设置好）proxySelector 能够为一个 URI 设置多个代理，如果地址连贯失败还回调 connectFailed；proxy 设置独自的全局代理，他的优先级高于 proxySelecttor；dns 用法和 proxySelecttor 相似，能够返回多个地址。

private Address createAddress(HttpUrl url) {
        SSLSocketFactory sslSocketFactory = null;
        HostnameVerifier hostnameVerifier = null;
        CertificatePinner certificatePinner = null;
        if (url.isHttps()) {sslSocketFactory = client.sslSocketFactory();
            hostnameVerifier = client.hostnameVerifier();
            certificatePinner = client.certificatePinner();}
 
        return new Address(url.host(), url.port(), client.dns(), client.socketFactory(),
                sslSocketFactory, hostnameVerifier, certificatePinner, client.proxyAuthenticator(),
                client.proxy(), client.protocols(), client.connectionSpecs(), client.proxySelector());
    }

Route 路由：对地址 Adress 的一个封装类
RouteSelector 路由选择器: 在 OKhttp 中其实其作用也就是返回一个可用的 Route 对象

咱们来大略梳理一下流程

首先对以后的流进行一个初步判断，满足则复用
不满足则，对连接池进行第一次的查找，此次查找中，route 类为空

connectionPool.transmitterAcquirePooledConnection(address, transmitter, null, false)

查找失去间接复用

查找不到则应用路由进行查找，查找设置的代理和 DNS 是否能找到相干的代理，如果找到则复用

connectionPool.transmitterAcquirePooledConnection(address, transmitter, routes, false)

上述路线都查找不到，间接新建一个连贯，放入连接池中，并把解析的 host 等信息保留到 Connection 中，不便下次复用。其中还要多做一步判断，如果是 HTTP2 同时发动的申请，要进行一个去重的操作。

下图是一个简要的连贯步骤。

首先取得后面 Intecepter 获取的信息
而后利用编码器写入 header 信息

  exchange.writeRequestHeaders(request)

判断是否要发送申请体，有申请体时，但冀望返回状态码是 100 时，则不发送。否则利用流封装后发送。

  var responseBuilder: Response.Builder? = null
    if (HttpMethod.permitsRequestBody(request.method) && requestBody != null) {
      // If there's a"Expect: 100-continue"header on the request, wait for a"HTTP/1.1 100
      // Continue"response before transmitting the request body. If we don't get that, return
      // what we did get (such as a 4xx response) without ever transmitting the request body.
      if ("100-continue".equals(request.header("Expect"), ignoreCase = true)) {exchange.flushRequest()
        responseHeadersStarted = true
        exchange.responseHeadersStart()
        responseBuilder = exchange.readResponseHeaders(true)
      }
      if (responseBuilder == null) {if (requestBody.isDuplex()) {
          // Prepare a duplex body so that the application can send a request body later.
          exchange.flushRequest()
          val bufferedRequestBody = exchange.createRequestBody(request, true).buffer()
          requestBody.writeTo(bufferedRequestBody)
        } else {
          // Write the request body if the "Expect: 100-continue" expectation was met.
          val bufferedRequestBody = exchange.createRequestBody(request, false).buffer()
          requestBody.writeTo(bufferedRequestBody)
          bufferedRequestBody.close()}
      } else {exchange.noRequestBody()
        if (!exchange.connection()!!.isMultiplexed) {
          // If the "Expect: 100-continue" expectation wasn't met, prevent the HTTP/1 connection
          // from being reused. Otherwise we're still obligated to transmit the request body to
          // leave the connection in a consistent state.
          exchange.noNewExchangesOnConnection()}
      }
    } else {exchange.noRequestBody()
    }

// 创立 response，把握手信息，和 request 等信息保留进去
@Override public Response intercept(Chain chain) throws IOException {
    ...
    // 写入 request 完结
    httpCodec.finishRequest();
    if (responseBuilder == null) {realChain.eventListener().responseHeadersStart(realChain.call());
      // 读取相应 response 的 header 信息
      responseBuilder = httpCodec.readResponseHeaders(false);
    }
 
    // 创立 response，把握手信息，和 request 等信息保留进去
    Response response = responseBuilder
        .request(request)
        .handshake(streamAllocation.connection().handshake())
        .sentRequestAtMillis(sentRequestMillis)
        .receivedResponseAtMillis(System.currentTimeMillis())
        .build();
    // 开始判断申请码
    int code = response.code();
    if (code == 100) {
      // 如果是 100，间接读取 header
      responseBuilder = httpCodec.readResponseHeaders(false);
      response = responseBuilder
              .request(request)
              // 握手
              .handshake(streamAllocation.connection().handshake())
              .sentRequestAtMillis(sentRequestMillis)
              .receivedResponseAtMillis(System.currentTimeMillis())
              .build();
 
      code = response.code();}
    ...
    // 判断申请码
    if (forWebSocket && code == 101) {
      // 客户端须要转换协定，这里须要设置一个空的 response
      response = response.newBuilder()
          .body(Util.EMPTY_RESPONSE)
          .build();} else {
      // 读取网络的 body
      response = response.newBuilder()
          .body(httpCodec.openResponseBody(response))
          .build();}
    // 如果 header 申请敞开连贯
    if ("close".equalsIgnoreCase(response.request().header("Connection"))
        || "close".equalsIgnoreCase(response.header("Connection"))) {
      // 敞开这个链接
      streamAllocation.noNewStreams();}
    // 非凡 code 判断
    if ((code == 204 || code == 205) && response.body().contentLength() > 0) {
      throw new ProtocolException("HTTP" + code + "had non-zero Content-Length:" + response.body().contentLength());
    }
 
    return response;
  }

如果想要理解具体的读取和写入流程，以我当初应用的 Http 2.0 为例：
连贯：Http2Connection；
流：Http2Stream；
编解码器：Http2Codec；
读操作：Http2Reader；
写操作：Http2Writer；
他们之间的关系：
1、Http2Connection 调用 Http2Reader 和 Http2Writer 来进行读写；
2、Http2Stream 调用 Http2Connection 进行读写；
3、Http2Codec 调用 Http2Connection 和 Http2Stream 进行操作；

咱们分三个阶段来简要介绍了 OkHttp 这个框架，因为当初程度无限，所以会存在疏漏。当前有些有新的发现，则再对其进行补充。

OkHttp（三）

责任链模式

RetryAndFollowUpInterceptor

BridgeIntecepter

CacheIntecepter

ConnectIntecepter（外围）

CallServerInterceptor

总结

站内搜索