上一篇我們說完了dispatcher分發(fā)器漫拭，我們知道了請求任務是如何分發(fā)出去的，那響應是如何獲取到的呢混稽？再看一下RealCall中的同步方法execute():

    @Override
    public Response execute() throws IOException {
        synchronized (this) {
            if (executed) throw new IllegalStateException("Already Executed");
            executed = true;
        }
        captureCallStackTrace();
        eventListener.callStart(this);
        try {
            client.dispatcher().executed(this);
            // 通過Response攔截器鏈得到網(wǎng)絡請求響應
            Response result = getResponseWithInterceptorChain();
            if (result == null) throw new IOException("Canceled");
            return result;
        } catch (IOException e) {
            eventListener.callFailed(this, e);
            throw e;
        } finally {
            client.dispatcher().finished(this);
        }
    }

可以看到一個方法getResponseWithInterceptorChain()采驻，點進去看看

    Response getResponseWithInterceptorChain() throws IOException {
        // 創(chuàng)建一個攔截器list.
        List<Interceptor> interceptors = new ArrayList<>();
        // 添加用戶自定義攔截器
        interceptors.addAll(client.interceptors());
        // 重試及重定向攔截器
        interceptors.add(retryAndFollowUpInterceptor);
        // 橋接攔截器
        interceptors.add(new BridgeInterceptor(client.cookieJar()));
        // 緩存攔截器
        interceptors.add(new CacheInterceptor(client.internalCache()));
        // 連接攔截器
        interceptors.add(new ConnectInterceptor(client));
        if (!forWebSocket) {
            // 用戶自定義網(wǎng)絡攔截器
            interceptors.addAll(client.networkInterceptors());
        }
        // 請求服務攔截器
        interceptors.add(new CallServerInterceptor(forWebSocket));

        Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
                originalRequest, this, eventListener, client.connectTimeoutMillis(),
                client.readTimeoutMillis(), client.writeTimeoutMillis());

        return chain.proceed(originalRequest);
    }

這里添加了一大堆攔截器，Okhttp默認有5個攔截器

• RetryAndFollowUpInterceptor 第一個接觸到請求匈勋，最后接觸到響應礼旅；負責判斷是否需要重新發(fā)起整個請求
• BridgeInterceptor 補全請求苗胀，并對響應進行額外處理
• CacheInterceptor 請求前查詢緩存唾琼，獲得響應并判斷是否需要緩存
• ConnectInterceptor 與服務器完成TCP連接
• CallServerInterceptor 與服務器通信；封裝請求數(shù)據(jù)與解析響應數(shù)據(jù)(如：HTTP報文)

我們先說一下攔截器鏈是如何工作的虏辫，看一張圖

攔截器責任鏈.png

如果上面看不懂先看這張

攔截器鏈舉例.png

        Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
                originalRequest, this, eventListener, client.connectTimeoutMillis(),
                client.readTimeoutMillis(), client.writeTimeoutMillis());

        return chain.proceed(originalRequest);

new了一個RealInterceptorChain對象，傳入 interceptors 攔截器集合总放，后面有一個參數(shù)index ：0呈宇，這個index就是攔截器集合的下標，意味著現(xiàn)在處理到第幾個攔截器了局雄，后面?zhèn)魅雘riginalRequest 也就是Request對象甥啄，最后
return chain.proceed(originalRequest)
來看看 chain.proceed(）方法，它是接口Interceptor.chain聲明的方法哎榴，實現(xiàn)類是RealInterceptorChain

@Override public Response proceed(Request request) throws IOException {
    return proceed(request, streamAllocation, httpCodec, connection);
  }

參數(shù)是Request 型豁，返回值類型是Response僵蛛，然后調用重載方法；

public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
      RealConnection connection) throws IOException {
    if (index >= interceptors.size()) throw new AssertionError();

    calls++;

    // If we already have a stream, confirm that the incoming request will use it.
    if (this.httpCodec != null && !this.connection.supportsUrl(request.url())) {
      throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)
          + " must retain the same host and port");
    }

    // If we already have a stream, confirm that this is the only call to chain.proceed().
    if (this.httpCodec != null && calls > 1) {
      throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)
          + " must call proceed() exactly once");
    }

    // 重點在這里迎变，經過一系列異常判斷后充尉，又new了一個RealInterceptorChain
    // 傳入interceptors， index + 1衣形， request等等
    RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
        connection, index + 1, request, call, eventListener, connectTimeout, readTimeout,
        writeTimeout);
    // 獲取到第一個攔截器驼侠，這里index是0，攔截器鏈從這里開始順序執(zhí)行
    Interceptor interceptor = interceptors.get(index);
    // 調用 interceptor的intercept方法谆吴， 拿到Response 
    Response response = interceptor.intercept(next);

    // 下面拿到 Respone 又是一頓異常判斷

    // Confirm that the next interceptor made its required call to chain.proceed().
    if (httpCodec != null && index + 1 < interceptors.size() && next.calls != 1) {
      throw new IllegalStateException("network interceptor " + interceptor
          + " must call proceed() exactly once");
    }

    // Confirm that the intercepted response isn't null.
    if (response == null) {
      throw new NullPointerException("interceptor " + interceptor + " returned null");
    }

    if (response.body() == null) {
      throw new IllegalStateException(
          "interceptor " + interceptor + " returned a response with no body");
    }

    return response;
  }

此時的index值是0倒源，這里既是入口也是出口，類似舉例中的政府發(fā)放補貼那個位置句狼，然后調用 Interceptor 的 intercept 方法笋熬，這里是第一個攔截器，相當于舉例中的省長攔截器腻菇，把補貼發(fā)放到省長手里胳螟，由省長開始第一次攔截處理。
再看一下 Interceptor 中的 intercept 方法筹吐，Interceptor是接口糖耸，攔截器必須實現(xiàn)它，這里我們找一個實現(xiàn)類 RetryAndFollowUpInterceptor 看一下

    @Override
    public Response intercept(Chain chain) throws IOException {

        Request request = chain.request();
        RealInterceptorChain realChain = (RealInterceptorChain) chain;
        ......
        Response priorResponse = null;
        while (true) {
            ......
            try {
                // 這里處理完又調回 RealInterceptorChain 的proceed方法
                response = realChain.proceed(request, streamAllocation, null, null);
                releaseConnection = false;
            } catch (RouteException e) {
               ......
            }
            ......
            return response;
        }
    }

看到這里就很明朗了丘薛，攔截器無非就一個套路嘉竟，在intercept方法中

public Response intercept(Chain chain){
     // todu 在這里處理request
     // 再次回到攔截器鏈的proceed方法，把request傳遞給下一個攔截器
     response = chain.proceed(request, streamAllocation, null, null);
     // todo 在這里處理response
     // 返回response給上一個攔截器
     return response;
}

這時回頭再看看我們舉得例子洋侨，類比攔截器處理過程

1舍扰、拿到補貼（Request）
2、克扣一點（處理Request）
3凰兑、把剩下的補貼發(fā)到下一級（傳遞給下個攔截器）
4妥粟、拿到下一級的收據(jù)反饋（拿到Response）
5、改一下數(shù)字（處理Response）
6吏够、把收據(jù)反饋給上一級（返回Response）
攔截結束。

責任鏈中每一個攔截器有著它自己的職責（單一職責原則）滩报，接下來分析每個攔截器負責的功能锅知。

1、RetryAndFollowUpInterceptor 重試及重定向攔截器

負責判斷用戶是否取消了請求脓钾，出現(xiàn)異常后是否需要重試售睹；在獲得了結果之后，會根據(jù)響應碼判斷是否需要重定向可训，如果滿足條件那么就會重啟執(zhí)行所有攔截器昌妹〈肥啵看代碼：

    @Override
    public Response intercept(Chain chain) throws IOException {

        Request request = chain.request();
        RealInterceptorChain realChain = (RealInterceptorChain) chain;
        Call call = realChain.call();
        EventListener eventListener = realChain.eventListener();

        /**
         * 管理類，維護了 與服務器的連接飞崖、數(shù)據(jù)流與請求三者的關系烂叔。真正使用的攔截器為 ConnectIntercepter
         */
        StreamAllocation streamAllocation = new StreamAllocation(client.connectionPool(),
                createAddress(request.url()), call, eventListener, callStackTrace);
        this.streamAllocation = streamAllocation;
        // 重試次數(shù)
        int followUpCount = 0;
        Response priorResponse = null;
        // while循環(huán)表示只要沒達到限制條件（如異常情況或者最大重試次數(shù)20次）就一直重試
        while (true) {
            // canceled表示請求是否被用戶主動取消，如果被取消直接拋異常退出
            if (canceled) {
                streamAllocation.release();
                throw new IOException("Canceled");
            }

            Response response;
            boolean releaseConnection = true;
            try {
                // 請求出現(xiàn)了異常固歪，那么releaseConnection依舊為true蒜鸡。
                response = realChain.proceed(request, streamAllocation, null, null);
                releaseConnection = false;
            } catch (RouteException e) {
                // 路由異常，連接未成功牢裳，請求還沒發(fā)出去
                //The attempt to connect via a route failed. The request will not have been sent.
                if (!recover(e.getLastConnectException(), streamAllocation, false, request)) {
                    throw e.getLastConnectException();
                }
                releaseConnection = false;
                continue;
            } catch (IOException e) {
                // 請求發(fā)出去了逢防，但是和服務器通信失敗了。(socket流正在讀寫數(shù)據(jù)的時候斷開連接)
                // ConnectionShutdownException只對HTTP2存在蒲讯。假定它就是false
                //An attempt to communicate with a server failed. The request may have been sent.
                boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
                if (!recover(e, streamAllocation, requestSendStarted, request)) throw e;
                releaseConnection = false;
                continue;
            } finally {
                // We're throwing an unchecked exception. Release any resources.
                // 不是前兩種的失敗忘朝，那直接關閉清理所有資源
                if (releaseConnection) {
                    streamAllocation.streamFailed(null);
                    streamAllocation.release();
                }
            }
            // 如果進過重試/重定向才成功的，則在本次響應中記錄上次響應的情況
            //Attach the prior response if it exists. Such responses never have a body.
            if (priorResponse != null) {
                response = response.newBuilder()
                        .priorResponse(
                                priorResponse.newBuilder()
                                        .body(null)
                                        .build()
                        )
                        .build();
            }
            // 處理3和4xx的一些狀態(tài)碼判帮，如301 302重定向
            Request followUp = followUpRequest(response, streamAllocation.route());
            if (followUp == null) {
                if (!forWebSocket) {
                    streamAllocation.release();
                }
                return response;
            }

            closeQuietly(response.body());

            // 限制最大 followup 次數(shù)為20次
            if (++followUpCount > MAX_FOLLOW_UPS) {
                streamAllocation.release();
                throw new ProtocolException("Too many follow-up requests: " + followUpCount);
            }

            if (followUp.body() instanceof UnrepeatableRequestBody) {
                streamAllocation.release();
                throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
            }
            // 判斷是不是可以復用同一份連接
            if (!sameConnection(response, followUp.url())) {
                streamAllocation.release();
                streamAllocation = new StreamAllocation(client.connectionPool(),
                        createAddress(followUp.url()), call, eventListener, callStackTrace);
                this.streamAllocation = streamAllocation;
            } else if (streamAllocation.codec() != null) {
                throw new IllegalStateException("Closing the body of " + response
                        + " didn't close its backing stream. Bad interceptor?");
            }

            request = followUp;
            priorResponse = response;
        }
    }

重試

下面這句代碼是被 try catch 包裹的
response = realChain.proceed(request, streamAllocation, null, null);
在請求過程中可能會出現(xiàn)2種異常情況

• RouteException 它是OkHttp自定義的一個 RuntimeException局嘁，如果請求時需要通過一個代理服務器轉發(fā)請求，在和代理服務器連接的時候出錯脊另，就會拋出一個RouteException导狡。
• IOException 和服務器通信失敗，比如socket流正在讀寫數(shù)據(jù)的時候斷開連接偎痛，拋出異常旱捧。

這兩個catch代碼塊中都有continue關鍵字，說明出現(xiàn)這兩種異常都可以觸發(fā)重試機制踩麦，但是中間還有個if 判斷 recover() 方法返回值 枚赡，只有它返回 true 才能重試，如果返回 false 直接拋出IOException谓谦，我們看看recover()：

    private boolean recover(IOException e, StreamAllocation streamAllocation,
                            boolean requestSendStarted, Request userRequest) {
        streamAllocation.streamFailed(e);

        //  1贫橙、在配置OkhttpClient是設置了不允許重試（默認允許），則一旦發(fā)生請求失敗就不再重試
        //The application layer has forbidden retries.
        if (!client.retryOnConnectionFailure()) return false;

        //  2反粥、由于requestSendStarted只在http2的io異常中為true卢肃，先不管http2
        //We can't send the request body again.
        if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody)
            return false;

        //  3、判斷是不是屬于重試的異常
        //This exception is fatal.
        if (!isRecoverable(e, requestSendStarted)) return false;

        //  4才顿、有沒有更多的路由
        //No more routes to attempt.
        if (!streamAllocation.hasMoreRoutes()) return false;

        // For failure recovery, use the same route selector with a new connection.
        return true;
    }

先說一下第4點莫湘，hasMoreRoutes()表示有沒有更多路線，比如一個域名dns可能解析出多個IP或者存在多個代理服務器的情況郑气，如果擁有多個路線幅垮，就可以換一個路線重試請求 。
再說一下第3點尾组，判斷是不是屬于重試的異常忙芒，調用 isRecoverable 方法：

    private boolean isRecoverable(IOException e, boolean requestSendStarted) {
        // If there was a protocol problem, don't recover.
        // 如果是協(xié)議異常 示弓，不重試
        if (e instanceof ProtocolException) {
            return false;
        }

        // If there was an interruption don't recover, but if there was a timeout connecting to a route
        // we should try the next route (if there is one).
        // 如果只是InterruptedIOException 不重試， 如果是超時異常SocketTimeoutException 可重試
        if (e instanceof InterruptedIOException) {
            return e instanceof SocketTimeoutException && !requestSendStarted;
        }

        // Look for known client-side or negotiation errors that are unlikely to be fixed by trying
        // again with a different route.
        //  證書不正確  可能證書格式損壞 有問題
        if (e instanceof SSLHandshakeException) {
            // If the problem was a CertificateException from the X509TrustManager,
            // do not retry.
            if (e.getCause() instanceof CertificateException) {
                return false;
            }
        }
        // 證書校驗失敗 不匹配
        if (e instanceof SSLPeerUnverifiedException) {
            // e.g. a certificate pinning error.
            return false;
        }

        // An example of one we might want to retry with a different route is a problem
        // connecting to a
        // proxy and would manifest as a standard IOException. Unless it is one we know we should
        // not
        // retry, we return true and try a new route.
        return true;
    }

看了這么一堆呵萨， 總結一張圖

重試機制.png

重定向
如果請求結束后沒有發(fā)生異常并不代表當前獲得的響應就是最終需要交給用戶的奏属，還需要進一步來判斷是否需要重定向的判斷。重定向的判斷位于 followUpRequest() 方法

    private Request followUpRequest(Response userResponse, Route route) throws IOException {
        if (userResponse == null) throw new IllegalStateException();
        int responseCode = userResponse.code();

        final String method = userResponse.request().method();
        switch (responseCode) {
            // 407 客戶端使用了HTTP代理服務器甘桑，在請求頭中添加 “Proxy-Authorization”拍皮，讓代理服務器授權
            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);
            // 401 需要身份驗證 有些服務器接口需要驗證使用者身份 在請求頭中添加 “Authorization” 
            case HTTP_UNAUTHORIZED:
                return client.authenticator().authenticate(route, userResponse);
            // 308 永久重定向 
            // 307 臨時重定向
            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"
                // 如果請求方式不是GET或者HEAD，框架不會自動重定向請求
                if (!method.equals("GET") && !method.equals("HEAD")) {
                    return null;
                }
                // fall-through
            // 300 301 302 303 
            case HTTP_MULT_CHOICE:
            case HTTP_MOVED_PERM:
            case HTTP_MOVED_TEMP:
            case HTTP_SEE_OTHER:
                // Does the client allow redirects?
                // 如果用戶不允許重定向跑杭，那就返回null
                if (!client.followRedirects()) return null;
                // 從響應頭取出location 
                String location = userResponse.header("Location");
                if (location == null) return null;
                // 根據(jù)location 配置新的請求 url
                HttpUrl url = userResponse.request().url().resolve(location);

                // Don't follow redirects to unsupported protocols.
                // 如果為null铆帽，說明協(xié)議有問題，取不出來HttpUrl德谅，那就返回null爹橱，不進行重定向
                if (url == null) return null;

                // If configured, don't follow redirects between SSL and non-SSL.
                // 如果重定向在http到https之間切換，需要檢查用戶是不是允許(默認允許)
                boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
                if (!sameScheme && !client.followSslRedirects()) return null;

                // Most redirects don't include a request body.
                Request.Builder requestBuilder = userResponse.request().newBuilder();
                    /**
                     *  重定向請求中 只要不是 PROPFIND 請求窄做，無論是POST還是其他的      方法都要改為GET請求方式愧驱，
                     *  即只有 PROPFIND 請求才能有請求體
                     */
                 //請求不是get與head
                if (HttpMethod.permitsRequestBody(method)) {
                    final boolean maintainBody = HttpMethod.redirectsWithBody(method);
                    // 除了 PROPFIND 請求之外都改成GET請求
                    if (HttpMethod.redirectsToGet(method)) {
                        requestBuilder.method("GET", null);
                    } else {
                        RequestBody requestBody = maintainBody ? userResponse.request().body() :
                                null;
                        requestBuilder.method(method, requestBody);
                    }
                    // 不是 PROPFIND 的請求，把請求頭中關于請求體的數(shù)據(jù)刪掉
                    if (!maintainBody) {
                        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();
            // 408 客戶端請求超時 
            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.)
                // 408 算是連接失敗了组砚，所以判斷用戶是不是允許重試
                if (!client.retryOnConnectionFailure()) {
                    // The application layer has directed us not to retry the request.
                    return null;
                }

                if (userResponse.request().body() instanceof UnrepeatableRequestBody) {
                    return null;
                }

                if (userResponse.priorResponse() != null
                        && userResponse.priorResponse().code() == HTTP_CLIENT_TIMEOUT) {
                    // We attempted to retry and got another timeout. Give up.
                    return null;
                }
                // 如果服務器告訴我們了 Retry-After 多久后重試，那框架不管了掏颊。
                if (retryAfter(userResponse, 0) > 0) {
                    return null;
                }

                return userResponse.request();
            // 503 服務不可用 和408差不多糟红，但是只在服務器告訴你 Retry-After：0（意思就是立即重試） 才重請求
            case HTTP_UNAVAILABLE:
                if (userResponse.priorResponse() != null
                        && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) {
                    // We attempted to retry and got another timeout. Give up.
                    return null;
                }

                if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
                    // specifically received an instruction to retry without delay
                    return userResponse.request();
                }

                return null;

            default:
                return null;
        }
    }

整個是否需要重定向的判斷內容很多，記不住乌叶，這很正常盆偿，關鍵在于理解他們的意思。如果此方法返回空准浴，那就表示不需要再重定向了事扭，直接返回響應；但是如果返回非空乐横，那就要重新請求返回的Request求橄，但是需要注意的是，我們的followup在攔截器中定義的最大次數(shù)為20次葡公。

重定向.png

總結
RetryAndFollowUpInterceptor是整個責任鏈中的第一個谈撒，這意味著它會是首次接觸到Request與最后接收到Response的角色，在這個攔截器中主要功能就是判斷是否需要重試與重定向匾南。

重試的前提是出現(xiàn)了RouteException或者IOException。一旦在后續(xù)的攔截器執(zhí)行過程中出現(xiàn)這兩個異常蛔外，就會通過recover方法進行判斷是否進行連接重試蛆楞。

重定向發(fā)生在重試的判定之后溯乒，如果不滿足重試的條件，還需要進一步調用followUpRequest根據(jù)Response 的響應碼(當然豹爹，如果直接請求失敗裆悄，Response都不存在就會拋出異常)。followup最大發(fā)生20次臂聋。

2光稼、BridgeInterceptor 橋接攔截器

BridgeInterceptor，連接應用程序和服務器的橋梁孩等，我們發(fā)出的請求將會經過它的處理才能發(fā)給服務器艾君，比如設置請求內容長度，編碼肄方，gzip壓縮冰垄，cookie等，獲取響應后保存Cookie等操作权她。

    @Override
    public Response intercept(Chain chain) throws IOException {
        Request userRequest = chain.request();
        Request.Builder requestBuilder = userRequest.newBuilder();

        RequestBody body = userRequest.body();
        if (body != null) {
            MediaType contentType = body.contentType();
            if (contentType != null) {
                requestBuilder.header("Content-Type", contentType.toString());
            }

            long contentLength = body.contentLength();
            if (contentLength != -1) {
                requestBuilder.header("Content-Length", Long.toString(contentLength));
                requestBuilder.removeHeader("Transfer-Encoding");
            } else {
                requestBuilder.header("Transfer-Encoding", "chunked");
                requestBuilder.removeHeader("Content-Length");
            }
        }

        if (userRequest.header("Host") == null) {
            requestBuilder.header("Host", hostHeader(userRequest.url(), false));
        }

        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.
        boolean transparentGzip = false;
        if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
            transparentGzip = true;
            requestBuilder.header("Accept-Encoding", "gzip");
        }

        List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
        if (!cookies.isEmpty()) {
            requestBuilder.header("Cookie", cookieHeader(cookies));
        }

        if (userRequest.header("User-Agent") == null) {
            requestBuilder.header("User-Agent", Version.userAgent());
        }

        Response networkResponse = chain.proceed(requestBuilder.build());

        HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());

        Response.Builder responseBuilder = networkResponse.newBuilder()
                .request(userRequest);

        if (transparentGzip
                && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
                && HttpHeaders.hasBody(networkResponse)) {
            GzipSource responseBody = new GzipSource(networkResponse.body().source());
            Headers strippedHeaders = networkResponse.headers().newBuilder()
                    .removeAll("Content-Encoding")
                    .removeAll("Content-Length")
                    .build();
            responseBuilder.headers(strippedHeaders);
            String contentType = networkResponse.header("Content-Type");
            responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
        }

        return responseBuilder.build();
    }

基本上就是將Request補全請求頭的操作虹茶， 就是下面這張表：

補全請求頭.png

然后得到響應后，主要干兩件事情：

1隅要、保存cookie蝴罪，在下次請求則會讀取對應的數(shù)據(jù)設置進入請求頭，默認的CookieJar不提供實現(xiàn)

2步清、如果使用gzip返回的數(shù)據(jù)要门，則使用GzipSource包裝便于解析。

總結
橋接攔截器的執(zhí)行邏輯主要就是以下幾點

對用戶構建的Request進行添加或者刪除相關頭部信息尼啡，以轉化成能夠真正進行網(wǎng)絡請求的Request 將符合網(wǎng)絡請求規(guī)范的Request交給下一個攔截器處理暂衡，并獲取Response 如果響應體經過了GZIP壓縮，那就需要解壓崖瞭，再構建成用戶可用的Response并返回

3狂巢、CacheInterceptor 緩存攔截器

在發(fā)出請求前，判斷是否命中緩存书聚。如果命中則可以不請求唧领，直接使用緩存的響應。 (只會存在Get請求的緩存)

    @Override
    public Response intercept(Chain chain) throws IOException {
        // 通過url的md5數(shù)據(jù) 從文件緩存查找 （GET請求才有緩存）
        Response cacheCandidate = cache != null
                ? cache.get(chain.request())
                : null;

        long now = System.currentTimeMillis();

        // 緩存策略:根據(jù)各種條件(請求頭)組成 請求與緩存
        CacheStrategy strategy =
                new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
        //
        Request networkRequest = strategy.networkRequest;
        Response cacheResponse = strategy.cacheResponse;

        if (cache != null) {
            cache.trackResponse(strategy);
        }

        if (cacheCandidate != null && cacheResponse == null) {
            closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
        }

        // 沒有網(wǎng)絡請求也沒有緩存
        //If we're forbidden from using the network and the cache is insufficient, fail.
        if (networkRequest == null && cacheResponse == null) {
            return new Response.Builder()
                    .request(chain.request())
                    .protocol(Protocol.HTTP_1_1)
                    .code(504)
                    .message("Unsatisfiable Request (only-if-cached)")
                    .body(Util.EMPTY_RESPONSE)
                    .sentRequestAtMillis(-1L)
                    .receivedResponseAtMillis(System.currentTimeMillis())
                    .build();
        }

        // 沒有請求雌续，肯定就要使用緩存
        //If we don't need the network, we're done.
        if (networkRequest == null) {
            return cacheResponse.newBuilder()
                    .cacheResponse(stripBody(cacheResponse))
                    .build();
        }

        // 去發(fā)起請求
        Response networkResponse = 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) {
                closeQuietly(cacheCandidate.body());
            }
        }

        // If we have a cache response too, then we're doing a conditional get.
        if (cacheResponse != null) {
            // 服務器返回304無修改斩个，那就使用緩存的響應修改了時間等數(shù)據(jù)后作為本次請求的響應
            if (networkResponse.code() == HTTP_NOT_MODIFIED) {
                Response 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 {
                closeQuietly(cacheResponse.body());
            }
        }

        // 走到這里說明緩存不可用 那就使用網(wǎng)絡的響應
        Response response = networkResponse.newBuilder()
                .cacheResponse(stripBody(cacheResponse))
                .networkResponse(stripBody(networkResponse))
                .build();
        // 進行緩存
        if (cache != null) {
            if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response,
                    networkRequest)) {
                // Offer this request to the cache.
                CacheRequest cacheRequest = cache.put(response);
                return cacheWritingResponse(cacheRequest, response);
            }

            if (HttpMethod.invalidatesCache(networkRequest.method())) {
                try {
                    cache.remove(networkRequest);
                } catch (IOException ignored) {
                    // The cache cannot be written.
                }
            }
        }

        return response;
    }

1、如果從緩存獲取的Response是null驯杜，那就需要使用網(wǎng)絡請求獲取響應受啥；
2、如果是Https請求，但是又丟失了握手信息滚局，那也不能使用緩存居暖，需要進行網(wǎng)絡請求；
3藤肢、如果判斷響應碼不能緩存且響應頭有no-store標識太闺，那就需要進行網(wǎng)絡請求；
4省骂、如果請求頭有no-cache標識或者有If-Modified-Since/If-None-Match略贮，那么需要進行網(wǎng)絡請求揽祥；
5俐末、如果響應頭沒有no-cache標識烹卒，且緩存時間沒有超過極限時間藐吮，那么可以使用緩存攒菠，不需要進行網(wǎng)絡請求；
6舱痘、如果緩存過期了旬盯，判斷響應頭是否設置Etag/Last-Modified/Date懊缺，沒有那就直接使用網(wǎng)絡請求否則需要考慮服務器返回304某弦；

并且桐汤，只要需要進行網(wǎng)絡請求，請求頭中就不能包含only-if-cached靶壮，否則框架直接返回504怔毛。
流程圖：

緩存.png

總結
主要流程就是查詢本地是否有當前Request的緩存，如果有緩存并且緩存有效（沒有過期）腾降，使用緩存拣度，否則發(fā)起網(wǎng)絡請求。

4、ConnectInterceptor 連接攔截器

功能是打開與目標服務器的連接抗果，以及Socket連接的緩存筋帖。

    @Override
    public Response intercept(Chain chain) throws IOException {
        RealInterceptorChain realChain = (RealInterceptorChain) chain;
        Request request = realChain.request();
        StreamAllocation streamAllocation = realChain.streamAllocation();

        // We need the network to satisfy this request. Possibly for validating a conditional GET.
        boolean doExtensiveHealthChecks = !request.method().equals("GET");
        HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks);
        RealConnection connection = streamAllocation.connection();

        return realChain.proceed(request, streamAllocation, httpCodec, connection);
    }

雖然代碼量很少，實際上大部分功能都封裝到其它類去了冤馏，這里只是調用而已日麸。
首先我們看到的StreamAllocation這個對象是在第一個攔截器：重定向攔截器創(chuàng)建的，但是真正使用的地方卻在這里逮光。

"當一個請求發(fā)出代箭，需要建立連接，連接建立后需要使用流用來讀寫數(shù)據(jù)"涕刚；而這個StreamAllocation就是協(xié)調請求嗡综、連接與數(shù)據(jù)流三者之間的關系，它負責為一次請求尋找連接杜漠，然后獲得流來實現(xiàn)網(wǎng)絡通信极景。

這里使用的newStream方法實際上就是去查找或者建立一個與請求主機有效的連接，返回的HttpCodec中包含了輸入輸出流驾茴，并且封裝了對HTTP請求報文的編碼與解碼盼樟，直接使用它就能夠與請求主機完成HTTP通信。

StreamAllocation 中簡單來說就是維護連接沟涨，
RealConnection 封裝了Socket與一個Socket連接池ConnectionPool 恤批。
ConnectionPool 連接池，類似線程池裹赴，只不過一個是緩存線程喜庞，一個是緩存Socke連接，內部維護了一個隊列棋返，當我們發(fā)起一次網(wǎng)絡請求和服務器建立了一個Socket連接延都，就將該連接緩存到連接池中，等下一次向同一主機發(fā)起請求時復用該連接睛竣。
復用條件:
1晰房、

        if (allocations.size() >= allocationLimit || noNewStreams) return false;

連接到達最大并發(fā)流或者連接不允許建立新的流；如http1.x正在使用的連接不能給其他人用(最大并發(fā)流為:1)或者連接被關閉射沟；那就不允許復用殊者；
2、

        if (!Internal.instance.equalsNonHost(this.route.address(), address)) return false;
        // If the host exactly matches, we're done: this connection can carry the address.
        if (address.url().host().equals(this.route().address().url().host())) {
            return true; // This connection is a perfect match.
        }

DNS验夯、代理猖吴、SSL證書、服務器域名挥转、端口完全相同則可復用海蔽；
如果上述條件都不滿足共屈，在HTTP/2的某些場景下可能仍可以復用(http2先不管)。

所以綜上党窜，如果在連接池中找到個連接參數(shù)一致并且未被關閉沒被占用的連接拗引，則可以復用。

連接池.png

當然連接是有有效期的幌衣，ConnectionPool中創(chuàng)建了一個線程池用于定期清理無效連接

清理連接.png

總結
這個攔截器中的所有實現(xiàn)都是為了獲得一份與目標服務器的連接矾削，在這個連接上進行HTTP數(shù)據(jù)的收發(fā)，以及Socket連接的緩存與清理泼掠。

5怔软、CallServerInterceptor 請求服務攔截器

利用HttpCodec發(fā)出請求到服務器并且解析生成Response。
說白了就是將請求頭择镇、請求體按照報文格式拼裝成字符串發(fā)送給服務器，并將返回的數(shù)據(jù)解析成Response對象返回給上一層攔截器括改。

總結
在這個攔截器中就是完成HTTP協(xié)議報文的封裝與解析腻豌。

攔截器總結

整個OkHttp功能的實現(xiàn)就在這五個默認的攔截器中，所以先理解攔截器模式的工作機制是先決條件嘱能。這五個攔截器分別為: 重試攔截器吝梅、橋接攔截器、緩存攔截器惹骂、連接攔截器苏携、請求服務攔截器。每一個攔截器負責的工作不一樣对粪，就好像工廠流水線右冻，最終經過這五道工序，就完成了最終的產品著拭。
但是與流水線不同的是纱扭，OkHttp中的攔截器每次發(fā)起請求都會在交給下一個攔截器之前干一些事情，在獲得了結果之后又干一些事情儡遮。整個過程在請求向是順序的乳蛾，而響應向則是逆序。

用戶也可以自定義自己的攔截器在請求過程中去處理自己想要的業(yè)務邏輯鄙币，比如打印Log肃叶、統(tǒng)一封裝Header等等。

當用戶發(fā)起一個請求后十嘿，會由任務分發(fā)起Dispatcher將請求包裝并交給重試攔截器處理因惭。

1、重試攔截器在交出(交給下一個攔截器)之前详幽，負責判斷用戶是否取消了請求筛欢；在獲得了結果之后浸锨，會根據(jù)響應碼判斷是否需要重定向，如果滿足條件那么就會重啟執(zhí)行所有攔截器版姑。

2柱搜、橋接攔截器在交出之前，負責將HTTP協(xié)議必備的請求頭加入其中(如：Host)并添加一些默認的行為(如：GZIP壓縮)剥险；在獲得了結果后聪蘸，調用保存cookie接口并解析GZIP數(shù)據(jù)。

3表制、緩存攔截器顧名思義健爬，交出之前讀取并判斷是否使用緩存；獲得結果后判斷是否緩存么介。

4娜遵、連接攔截器在交出之前，負責找到或者新建一個連接壤短，并獲得對應的socket流设拟；在獲得結果后不進行額外的處理。

5久脯、請求服務器攔截器進行真正的與服務器的通信纳胧，向服務器發(fā)送數(shù)據(jù)，解析讀取的響應數(shù)據(jù)帘撰。

在經過了這一系列的流程后跑慕，就完成了一次HTTP請求！