OkHttp原理解析

OkHttp 3.10.0版本，最新OkHttp為：4.0.1邏輯與3版本并沒(méi)有太大變化，但是改為kotlin實(shí)現(xiàn)。

OkHttp介紹

OkHttp是當(dāng)下Android使用最頻繁的網(wǎng)絡(luò)請(qǐng)求框架，由Square公司開(kāi)源。Google在Android4.4以后開(kāi)始將源碼中的HttpURLConnection底層實(shí)現(xiàn)替換為OKHttp，同時(shí)現(xiàn)在流行的Retrofit框架底層同樣是使用OKHttp的。

優(yōu)點(diǎn):

• 支持Spdy、Http1.X、Http2、Quic以及WebSocket
• 連接池復(fù)用底層TCP(Socket)，減少請(qǐng)求延時(shí)
• 無(wú)縫的支持GZIP減少數(shù)據(jù)流量
• 緩存響應(yīng)數(shù)據(jù)減少重復(fù)的網(wǎng)絡(luò)請(qǐng)求
• 請(qǐng)求失敗自動(dòng)重試主機(jī)的其他ip，自動(dòng)重定向
• …….

使用流程

[圖片上傳失敗...(image-8e958d-1572367003543)]

在使用OkHttp發(fā)起一次請(qǐng)求時(shí)，對(duì)于使用者最少存在OkHttpClient、Request與Call三個(gè)角色。其中OkHttpClient和Request的創(chuàng)建可以使用它為我們提供的Builder（建造者模式）。而Call則是把Request交給OkHttpClient之后返回的一個(gè)已準(zhǔn)備好執(zhí)行的請(qǐng)求。

建造者模式：將一個(gè)復(fù)雜的構(gòu)建與其表示相分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。實(shí)例化OKHttpClient和Request的時(shí)候，因?yàn)橛刑嗟膶傩孕枰O(shè)置，而且開(kāi)發(fā)者的需求組合千變?nèi)f化，使用建造者模式可以讓用戶不需要關(guān)心這個(gè)類的內(nèi)部細(xì)節(jié)，配置好后，建造者會(huì)幫助我們按部就班的初始化表示對(duì)象

同時(shí)OkHttp在設(shè)計(jì)時(shí)采用的門面模式，將整個(gè)系統(tǒng)的復(fù)雜性給隱藏起來(lái)，將子系統(tǒng)接口通過(guò)一個(gè)客戶端OkHttpClient統(tǒng)一暴露出來(lái)。

OkHttpClient中全是一些配置，比如代理的配置、ssl證書(shū)的配置等。而Call本身是一個(gè)接口，我們獲得的實(shí)現(xiàn)為:RealCall

static RealCall newRealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
    // Safely publish the Call instance to the EventListener.
    RealCall call = new RealCall(client, originalRequest, forWebSocket);
    call.eventListener = client.eventListenerFactory().create(call);
    return call;
}

Call的execute代表了同步請(qǐng)求，而enqueue則代表異步請(qǐng)求。兩者唯一區(qū)別在于一個(gè)會(huì)直接發(fā)起網(wǎng)絡(luò)請(qǐng)求，而另一個(gè)使用OkHttp內(nèi)置的線程池來(lái)進(jìn)行。這就涉及到OkHttp的任務(wù)分發(fā)器。

分發(fā)器

Dispatcher，分發(fā)器就是來(lái)調(diào)配請(qǐng)求任務(wù)的，內(nèi)部會(huì)包含一個(gè)線程池。可以在創(chuàng)建OkHttpClient時(shí)，傳遞我們自己定義的線程池來(lái)創(chuàng)建分發(fā)器。

這個(gè)Dispatcher中的成員有:

//異步請(qǐng)求同時(shí)存在的最大請(qǐng)求
private int maxRequests = 64;
//異步請(qǐng)求同一域名同時(shí)存在的最大請(qǐng)求
private int maxRequestsPerHost = 5;
//閑置任務(wù)(沒(méi)有請(qǐng)求時(shí)可執(zhí)行一些任務(wù)，由使用者設(shè)置)
private @Nullable Runnable idleCallback;

//異步請(qǐng)求使用的線程池
private @Nullable ExecutorService executorService;

//異步請(qǐng)求等待執(zhí)行隊(duì)列
private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();

//異步請(qǐng)求正在執(zhí)行隊(duì)列
private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();

//同步請(qǐng)求正在執(zhí)行隊(duì)列
private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();

同步請(qǐng)求

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

因?yàn)橥秸?qǐng)求不需要線程池，也不存在任何限制。所以分發(fā)器僅做一下記錄。

異步請(qǐng)求

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

當(dāng)正在執(zhí)行的任務(wù)未超過(guò)最大限制64，同時(shí)runningCallsForHost(call) < maxRequestsPerHost同一Host的請(qǐng)求不超過(guò)5個(gè)，則會(huì)添加到正在執(zhí)行隊(duì)列，同時(shí)提交給線程池。否則先加入等待隊(duì)列。

加入線程池直接執(zhí)行沒(méi)啥好說(shuō)的，但是如果加入等待隊(duì)列后，就需要等待有空閑名額才開(kāi)始執(zhí)行。因此每次執(zhí)行完一個(gè)請(qǐng)求后，都會(huì)調(diào)用分發(fā)器的finished方法

//異步請(qǐng)求調(diào)用
void finished(AsyncCall call) {
    finished(runningAsyncCalls, call, true);
}
//同步請(qǐng)求調(diào)用
void finished(RealCall call) {
    finished(runningSyncCalls, call, false);
}

private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
    int runningCallsCount;
    Runnable idleCallback;
    synchronized (this) {
        //不管異步還是同步，執(zhí)行完后都要從隊(duì)列移除(runningSyncCalls/runningAsyncCalls)
        if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
        if (promoteCalls) promoteCalls();
        //異步任務(wù)和同步任務(wù)正在執(zhí)行的和
        runningCallsCount = runningCallsCount();
        idleCallback = this.idleCallback;
    }
    // 沒(méi)有任務(wù)執(zhí)行執(zhí)行閑置任務(wù)
    if (runningCallsCount == 0 && idleCallback != null) {
        idleCallback.run();
    }
}

需要注意的是 只有異步任務(wù)才會(huì)存在限制與等待，所以在執(zhí)行完了移除正在執(zhí)行隊(duì)列中的元素后，異步任務(wù)結(jié)束會(huì)執(zhí)行promoteCalls()。很顯然這個(gè)方法肯定會(huì)重新調(diào)配請(qǐng)求。

private void promoteCalls() {
    //如果任務(wù)滿了直接返回
    if (runningAsyncCalls.size() >= maxRequests) return; 
    //沒(méi)有等待執(zhí)行的任務(wù)，返回
    if (readyAsyncCalls.isEmpty()) return; 
    //遍歷等待執(zhí)行隊(duì)列
    for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
        AsyncCall call = i.next();
        //等待任務(wù)想要執(zhí)行，還需要滿足：這個(gè)等待任務(wù)請(qǐng)求的Host不能已經(jīng)存在5個(gè)了
        if (runningCallsForHost(call) < maxRequestsPerHost) {
            i.remove();
            runningAsyncCalls.add(call);
            executorService().execute(call);
        }

        if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity.
    }
}

在滿足條件下，會(huì)把等待隊(duì)列中的任務(wù)移動(dòng)到runningAsyncCalls并交給線程池執(zhí)行。所以分發(fā)器到這里就完了。邏輯上還是非常簡(jiǎn)單的。

請(qǐng)求流程

用戶是不需要直接操作任務(wù)分發(fā)器的，獲得的RealCall中就分別提供了execute與enqueue來(lái)開(kāi)始同步請(qǐng)求或異步請(qǐng)求。

@Override public Response execute() throws IOException {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    try {
      //調(diào)用分發(fā)器
      client.dispatcher().executed(this);
      //執(zhí)行請(qǐng)求
      Response result = getResponseWithInterceptorChain();
      if (result == null) throw new IOException("Canceled");
      return result;
    } catch (IOException e) {
      eventListener.callFailed(this, e);
      throw e;
    } finally {
      //請(qǐng)求完成
      client.dispatcher().finished(this);
    }
}

異步請(qǐng)求的后續(xù)同時(shí)是調(diào)用getResponseWithInterceptorChain()來(lái)執(zhí)行請(qǐng)求

@Override
public void enqueue(Callback responseCallback) {
    synchronized (this) {
        if (executed) throw new IllegalStateException("Already Executed");
        executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    //調(diào)用分發(fā)器
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
}

如果該RealCall已經(jīng)執(zhí)行過(guò)了，再次執(zhí)行是不允許的。異步請(qǐng)求會(huì)把一個(gè)AsyncCall提交給分發(fā)器。

AsyncCall實(shí)際上是一個(gè)Runnable的子類,使用線程啟動(dòng)一個(gè)Runnable時(shí)會(huì)執(zhí)行run方法，在AsyncCall中被重定向到execute方法:

final class AsyncCall extends NamedRunnable {
    private final Callback responseCallback;

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

    //線程池執(zhí)行
    @Override
    protected void execute() {
     boolean signalledCallback = false;
      try {
        Response response = getResponseWithInterceptorChain();
       //.......
      } catch (IOException e) {
       //......
      } finally {
        //請(qǐng)求完成
        client.dispatcher().finished(this);
      }
    }
}

public abstract class NamedRunnable implements Runnable {
    protected final String name;

    public NamedRunnable(String format, Object... args) {
        this.name = Util.format(format, args);
    }

    @Override
    public final void run() {
        String oldName = Thread.currentThread().getName();
        Thread.currentThread().setName(name);
        try {
            execute();
        } finally {
            Thread.currentThread().setName(oldName);
        }
    }

    protected abstract void execute();
}

同時(shí)AsyncCall也是RealCall的普通內(nèi)部類，這意味著它是持有外部類RealCall的引用，可以獲得直接調(diào)用外部類的方法。

可以看到無(wú)論是同步還是異步請(qǐng)求實(shí)際上真正執(zhí)行請(qǐng)求的工作都在getResponseWithInterceptorChain()中。這個(gè)方法就是整個(gè)OkHttp的核心：攔截器責(zé)任鏈。但是在介紹責(zé)任鏈之前，我們?cè)賮?lái)回顧一下線程池的基礎(chǔ)知識(shí)。

分發(fā)器線程池

前面我們提過(guò)，分發(fā)器就是來(lái)調(diào)配請(qǐng)求任務(wù)的，內(nèi)部會(huì)包含一個(gè)線程池。當(dāng)異步請(qǐng)求時(shí)，會(huì)將請(qǐng)求任務(wù)交給線程池來(lái)執(zhí)行。那分發(fā)器中默認(rèn)的線程池是如何定義的呢？為什么要這么定義？

public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(
                            0,                  //核心線程
                            Integer.MAX_VALUE,  //最大線程
                            60,                 //空閑線程閑置時(shí)間
                            TimeUnit.SECONDS,   //閑置時(shí)間單位
                            new SynchronousQueue<Runnable>(), //線程等待隊(duì)列
                            Util.threadFactory("OkHttp Dispatcher", false) //線程創(chuàng)建工廠
      );
    }
    return executorService;
}

在OkHttp的分發(fā)器中的線程池定義如上，其實(shí)就和Executors.newCachedThreadPool()創(chuàng)建的線程一樣。首先核心線程為0，表示線程池不會(huì)一直為我們緩存線程，線程池中所有線程都是在60s內(nèi)沒(méi)有工作就會(huì)被回收。而最大線程Integer.MAX_VALUE與等待隊(duì)列SynchronousQueue的組合能夠得到最大的吞吐量。即當(dāng)需要線程池執(zhí)行任務(wù)時(shí)，如果不存在空閑線程不需要等待，馬上新建線程執(zhí)行任務(wù)！等待隊(duì)列的不同指定了線程池的不同排隊(duì)機(jī)制。一般來(lái)說(shuō)，等待隊(duì)列BlockingQueue有：ArrayBlockingQueue、LinkedBlockingQueue與SynchronousQueue。

假設(shè)向線程池提交任務(wù)時(shí)，核心線程都被占用的情況下：

ArrayBlockingQueue：基于數(shù)組的阻塞隊(duì)列，初始化需要指定固定大小。

? 當(dāng)使用此隊(duì)列時(shí)，向線程池提交任務(wù)，會(huì)首先加入到等待隊(duì)列中，當(dāng)?shù)却?duì)列滿了之后，再次提交任務(wù)，嘗試加入隊(duì)列就會(huì)失敗，這時(shí)就會(huì)檢查如果當(dāng)前線程池中的線程數(shù)未達(dá)到最大線程，則會(huì)新建線程執(zhí)行新提交的任務(wù)。所以最終可能出現(xiàn)后提交的任務(wù)先執(zhí)行，而先提交的任務(wù)一直在等待。

LinkedBlockingQueue：基于鏈表實(shí)現(xiàn)的阻塞隊(duì)列，初始化可以指定大小，也可以不指定。

? 當(dāng)指定大小后，行為就和ArrayBlockingQueu一致。而如果未指定大小，則會(huì)使用默認(rèn)的Integer.MAX_VALUE作為隊(duì)列大小。這時(shí)候就會(huì)出現(xiàn)線程池的最大線程數(shù)參數(shù)無(wú)用，因?yàn)闊o(wú)論如何，向線程池提交任務(wù)加入等待隊(duì)列都會(huì)成功。最終意味著所有任務(wù)都是在核心線程執(zhí)行。如果核心線程一直被占，那就一直等待。

SynchronousQueue : 無(wú)容量的隊(duì)列。

? 使用此隊(duì)列意味著希望獲得最大并發(fā)量。因?yàn)闊o(wú)論如何，向線程池提交任務(wù)，往隊(duì)列提交任務(wù)都會(huì)失敗。而失敗后如果沒(méi)有空閑的非核心線程，就會(huì)檢查如果當(dāng)前線程池中的線程數(shù)未達(dá)到最大線程，則會(huì)新建線程執(zhí)行新提交的任務(wù)。完全沒(méi)有任何等待，唯一制約它的就是最大線程數(shù)的個(gè)數(shù)。因此一般配合Integer.MAX_VALUE就實(shí)現(xiàn)了真正的無(wú)等待。

但是需要注意的時(shí)，我們都知道，進(jìn)程的內(nèi)存是存在限制的，而每一個(gè)線程都需要分配一定的內(nèi)存。所以線程并不能無(wú)限個(gè)數(shù)。那么當(dāng)設(shè)置最大線程數(shù)為Integer.MAX_VALUE時(shí)，OkHttp同時(shí)還有最大請(qǐng)求任務(wù)執(zhí)行個(gè)數(shù): 64的限制。這樣即解決了這個(gè)問(wèn)題同時(shí)也能獲得最大吞吐。

攔截器責(zé)任鏈

OkHttp最核心的工作是在getResponseWithInterceptorChain()中進(jìn)行，在進(jìn)入這個(gè)方法分析之前，我們先來(lái)了解什么是責(zé)任鏈模式，因?yàn)榇朔椒ň褪抢玫呢?zé)任鏈模式完成一步步的請(qǐng)求。

責(zé)任鏈顧名思義就是由一系列的負(fù)責(zé)者構(gòu)成的一個(gè)鏈條，類似于工廠流水線，你們懂的，很多同學(xué)的男朋友/女朋友就是這么來(lái)的。

責(zé)任鏈模式

為請(qǐng)求創(chuàng)建了一個(gè)接收者對(duì)象的鏈。這種模式給予請(qǐng)求的類型，對(duì)請(qǐng)求的發(fā)送者和接收者進(jìn)行解耦。在這種模式中，通常每個(gè)接收者都包含對(duì)另一個(gè)接收者的引用。如果一個(gè)對(duì)象不能處理該請(qǐng)求，那么它會(huì)把相同的請(qǐng)求傳給下一個(gè)接收者，依此類推。比如：

七夕節(jié)剛過(guò)去。周周同學(xué)（我也不知道為什么第一個(gè)想到的就是周周同學(xué)）在讀書(shū)的時(shí)候就是單身狗一條，看到自習(xí)室每天都很多美女后，每天晚上跑去自習(xí)都干同一件事情。

周周每天晚上都坐到自習(xí)室最后一排，找張紙條寫上：“Hi,可以做我的女朋友嗎？我的特長(zhǎng)就是特別的長(zhǎng)，如果不愿意請(qǐng)向前傳”。紙條就一個(gè)接一個(gè)的傳上去了，最后傳給了掃地阿姨。最后和掃地阿姨過(guò)上了幸福的生活，這真是一個(gè)....令人高興的故事。

那整個(gè)過(guò)程是什么樣子的呢？

//傳送者
abstract class Transmit{
    //責(zé)任鏈中下一個(gè)傳遞者
    protected Transmit nextTransmit;
    
    boolean request(String msg);
    
    public void setNextTransmit(Transmit transmit){
        nextTransmit = transmit;
    }
}

public class Zero extends Transmit{
    public boolean request(String msg){
        boolean resp = nextTransmit.request(msg); 
        return resp;
    }
}

public class Alvin extends Transmit{
    public boolean request(String msg){
        boolean resp = nextTransmit.request(); 
        return resp;
    }
}

public class Lucy extends Transmit{
    public boolean request(String msg){
       return true;
    }
}
                           
private static Transmit getTransmits(){
 
      Transmit zero = new Zero();
      Transmit alvin = new Alvin();
      Lucy lucy = new Lucy();
 
      zero.setNextTransmit(alvin);
      alvin.setNextTransmit(lucy);
 
      return errorLogger;  
   }
 
public static void main(String[] args) {
      Transmit transmit = getTransmits();
}

在責(zé)任鏈模式中，每一個(gè)對(duì)象對(duì)其下家的引用而接起來(lái)形成一條鏈。請(qǐng)求在這個(gè)鏈上傳遞，直到鏈上的某一個(gè)對(duì)象決定處理此請(qǐng)求?？蛻舨⒉恢梨溕系哪囊粋€(gè)對(duì)象最終處理這個(gè)請(qǐng)求，系統(tǒng)可以在不影響客戶端的 情況下動(dòng)態(tài)的重新組織鏈和分配責(zé)任。處理者有兩個(gè)選擇：承擔(dān)責(zé)任或者把責(zé)任推給下家。一個(gè)請(qǐng)求可以最終不被任何接收端對(duì)象所接受。

攔截器流程

而OkHttp中的getResponseWithInterceptorChain()中經(jīng)歷的流程為

[圖片上傳失敗...(image-f4ed8d-1572367003543)]

請(qǐng)求會(huì)被交給責(zé)任鏈中的一個(gè)個(gè)攔截器。默認(rèn)情況下有五大攔截器：

1. RetryAndFollowUpInterceptor

   第一個(gè)接觸到請(qǐng)求，最后接觸到響應(yīng)；負(fù)責(zé)判斷是否需要重新發(fā)起整個(gè)請(qǐng)求

2. BridgeInterceptor

   補(bǔ)全請(qǐng)求，并對(duì)響應(yīng)進(jìn)行額外處理

3. CacheInterceptor

   請(qǐng)求前查詢緩存，獲得響應(yīng)并判斷是否需要緩存

4. ConnectInterceptor

   與服務(wù)器完成TCP連接

5. CallServerInterceptor

   與服務(wù)器通信；封裝請(qǐng)求數(shù)據(jù)與解析響應(yīng)數(shù)據(jù)(如：HTTP報(bào)文)

攔截器詳情

一、重試及重定向攔截器

第一個(gè)攔截器:RetryAndFollowUpInterceptor，主要就是完成兩件事情：重試與重定向。

重試

請(qǐng)求階段發(fā)生了 RouteException 或者 IOException會(huì)進(jìn)行判斷是否重新發(fā)起請(qǐng)求。

RouteException

catch (RouteException e) {
    //todo 路由異常，連接未成功，請(qǐng)求還沒(méi)發(fā)出去
    if (!recover(e.getLastConnectException(), streamAllocation, false, request)) {
        throw e.getLastConnectException();
    }
    releaseConnection = false;
    continue;
} 

IOException

catch (IOException e) {
    //todo 請(qǐng)求發(fā)出去了，但是和服務(wù)器通信失敗了。(socket流正在讀寫數(shù)據(jù)的時(shí)候斷開(kāi)連接)
    // ConnectionShutdownException只對(duì)HTTP2存在。假定它就是false
    boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
    if (!recover(e, streamAllocation, requestSendStarted, request)) throw e;
        releaseConnection = false;
        continue;
} 

兩個(gè)異常都是根據(jù)recover 方法判斷是否能夠進(jìn)行重試，如果返回true，則表示允許重試。

private boolean recover(IOException e, StreamAllocation streamAllocation,
                            boolean requestSendStarted, Request userRequest) {
    streamAllocation.streamFailed(e);
    //todo 1、在配置OkhttpClient是設(shè)置了不允許重試（默認(rèn)允許），則一旦發(fā)生請(qǐng)求失敗就不再重試
    if (!client.retryOnConnectionFailure()) return false;
    //todo 2、由于requestSendStarted只在http2的io異常中為true，先不管http2
    if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody)
        return false;

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

    //todo 4、有沒(méi)有可以用來(lái)連接的路由路線
    if (!streamAllocation.hasMoreRoutes()) return false;

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

所以首先使用者在不禁止重試的前提下，如果出現(xiàn)了某些異常，并且存在更多的路由線路，則會(huì)嘗試換條線路進(jìn)行請(qǐng)求的重試。其中某些異常是在isRecoverable中進(jìn)行判斷:

private boolean isRecoverable(IOException e, boolean requestSendStarted) {
    // 出現(xiàn)協(xié)議異常，不能重試
    if (e instanceof ProtocolException) {
      return false;
    }

    // requestSendStarted認(rèn)為它一直為false(不管http2),異常屬于socket超時(shí)異常,直接判定可以重試
    if (e instanceof InterruptedIOException) {
      return e instanceof SocketTimeoutException && !requestSendStarted;
    }

    // SSL握手異常中，證書(shū)出現(xiàn)問(wèn)題，不能重試
    if (e instanceof SSLHandshakeException) {
      if (e.getCause() instanceof CertificateException) {
        return false;
      }
    }
    // SSL握手未授權(quán)異常 不能重試
    if (e instanceof SSLPeerUnverifiedException) {
      return false;
    }
    return true;
}

1、協(xié)議異常，如果是那么直接判定不能重試;（你的請(qǐng)求或者服務(wù)器的響應(yīng)本身就存在問(wèn)題，沒(méi)有按照http協(xié)議來(lái)定義數(shù)據(jù)，再重試也沒(méi)用）

2、超時(shí)異常，可能由于網(wǎng)絡(luò)波動(dòng)造成了Socket管道的超時(shí)，那有什么理由不重試？(后續(xù)還會(huì)涉及到路由)

3、SSL證書(shū)異常/SSL驗(yàn)證失敗異常，前者是證書(shū)驗(yàn)證失敗，后者可能就是壓根就沒(méi)證書(shū)，或者證書(shū)數(shù)據(jù)不正確，那還怎么重試

經(jīng)過(guò)了異常的判定之后，如果仍然允許進(jìn)行重試，就會(huì)再檢查當(dāng)前有沒(méi)有可用路由路線來(lái)進(jìn)行連接。簡(jiǎn)單來(lái)說(shuō)，比如 DNS 對(duì)域名解析后可能會(huì)返回多個(gè) IP，在一個(gè)IP失敗后，嘗試另一個(gè)IP進(jìn)行重試。

重定向

如果請(qǐng)求結(jié)束后沒(méi)有發(fā)生異常并不代表當(dāng)前獲得的響應(yīng)就是最終需要交給用戶的，還需要進(jìn)一步來(lái)判斷是否需要重定向的判斷。重定向的判斷位于followUpRequest方法

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) {
      // 407 客戶端使用了HTTP代理服務(wù)器，在請(qǐng)求頭中添加 “Proxy-Authorization”，讓代理服務(wù)器授權(quán)
      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 需要身份驗(yàn)證 有些服務(wù)器接口需要驗(yàn)證使用者身份 在請(qǐng)求頭中添加 “Authorization” 
      case HTTP_UNAUTHORIZED:
        return client.authenticator().authenticate(route, userResponse);
      // 308 永久重定向 
      // 307 臨時(shí)重定向
      case HTTP_PERM_REDIRECT:
      case HTTP_TEMP_REDIRECT:
        // 如果請(qǐng)求方式不是GET或者HEAD，框架不會(huì)自動(dòng)重定向請(qǐng)求
        if (!method.equals("GET") && !method.equals("HEAD")) {
          return null;
        }
      // 300 301 302 303 
      case HTTP_MULT_CHOICE:
      case HTTP_MOVED_PERM:
      case HTTP_MOVED_TEMP:
      case HTTP_SEE_OTHER:
        // 如果用戶不允許重定向，那就返回null
        if (!client.followRedirects()) return null;
        // 從響應(yīng)頭取出location 
        String location = userResponse.header("Location");
        if (location == null) return null;
        // 根據(jù)location 配置新的請(qǐng)求 url
        HttpUrl url = userResponse.request().url().resolve(location);
        // 如果為null，說(shuō)明協(xié)議有問(wèn)題，取不出來(lái)HttpUrl，那就返回null，不進(jìn)行重定向
        if (url == null) return null;
        // 如果重定向在http到https之間切換，需要檢查用戶是不是允許(默認(rèn)允許)
        boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
        if (!sameScheme && !client.followSslRedirects()) return null;

        Request.Builder requestBuilder = userResponse.request().newBuilder();
        /**
         *  重定向請(qǐng)求中 只要不是 PROPFIND 請(qǐng)求，無(wú)論是POST還是其他的方法都要改為GET請(qǐng)求方式，
         *  即只有 PROPFIND 請(qǐng)求才能有請(qǐng)求體
         */
        //請(qǐng)求不是get與head
        if (HttpMethod.permitsRequestBody(method)) {
          final boolean maintainBody = HttpMethod.redirectsWithBody(method);
           // 除了 PROPFIND 請(qǐng)求之外都改成GET請(qǐng)求
          if (HttpMethod.redirectsToGet(method)) {
            requestBuilder.method("GET", null);
          } else {
            RequestBody requestBody = maintainBody ? userResponse.request().body() : null;
            requestBuilder.method(method, requestBody);
          }
          // 不是 PROPFIND 的請(qǐng)求，把請(qǐng)求頭中關(guān)于請(qǐng)求體的數(shù)據(jù)刪掉
          if (!maintainBody) {
            requestBuilder.removeHeader("Transfer-Encoding");
            requestBuilder.removeHeader("Content-Length");
            requestBuilder.removeHeader("Content-Type");
          }
        }

        // 在跨主機(jī)重定向時(shí)，刪除身份驗(yàn)證請(qǐng)求頭
        if (!sameConnection(userResponse, url)) {
          requestBuilder.removeHeader("Authorization");
        }

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

      // 408 客戶端請(qǐng)求超時(shí) 
      case HTTP_CLIENT_TIMEOUT:
        // 408 算是連接失敗了，所以判斷用戶是不是允許重試
        if (!client.retryOnConnectionFailure()) {
            return null;
        }
        // UnrepeatableRequestBody實(shí)際并沒(méi)發(fā)現(xiàn)有其他地方用到
        if (userResponse.request().body() instanceof UnrepeatableRequestBody) {
            return null;
        }
        // 如果是本身這次的響應(yīng)就是重新請(qǐng)求的產(chǎn)物同時(shí)上一次之所以重請(qǐng)求還是因?yàn)?08，那我們這次不再重請(qǐng)求了
        if (userResponse.priorResponse() != null
                        && userResponse.priorResponse().code() == HTTP_CLIENT_TIMEOUT) {
            return null;
        }
        // 如果服務(wù)器告訴我們了 Retry-After 多久后重試，那框架不管了。
        if (retryAfter(userResponse, 0) > 0) {
            return null;
        }
        return userResponse.request();
       // 503 服務(wù)不可用 和408差不多，但是只在服務(wù)器告訴你 Retry-After：0（意思就是立即重試） 才重請(qǐng)求
       case HTTP_UNAVAILABLE:
        if (userResponse.priorResponse() != null
                        && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) {
            return null;
         }

         if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
            return userResponse.request();
         }

         return null;
      default:
        return null;
    }
}

整個(gè)是否需要重定向的判斷內(nèi)容很多，記不住，這很正常，關(guān)鍵在于理解他們的意思。如果此方法返回空，那就表示不需要再重定向了，直接返回響應(yīng)；但是如果返回非空，那就要重新請(qǐng)求返回的Request，但是需要注意的是，我們的followup在攔截器中定義的最大次數(shù)為20次。

總結(jié)

本攔截器是整個(gè)責(zé)任鏈中的第一個(gè)，這意味著它會(huì)是首次接觸到Request與最后接收到Response的角色，在這個(gè)攔截器中主要功能就是判斷是否需要重試與重定向。

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

重定向發(fā)生在重試的判定之后，如果不滿足重試的條件，還需要進(jìn)一步調(diào)用followUpRequest根據(jù)Response 的響應(yīng)碼(當(dāng)然，如果直接請(qǐng)求失敗，Response都不存在就會(huì)拋出異常)。followup最大發(fā)生20次。

二、橋接攔截器

BridgeInterceptor，連接應(yīng)用程序和服務(wù)器的橋梁，我們發(fā)出的請(qǐng)求將會(huì)經(jīng)過(guò)它的處理才能發(fā)給服務(wù)器，比如設(shè)置請(qǐng)求內(nèi)容長(zhǎng)度，編碼，gzip壓縮，cookie等，獲取響應(yīng)后保存Cookie等操作。這個(gè)攔截器相對(duì)比較簡(jiǎn)單。

補(bǔ)全請(qǐng)求頭:

在補(bǔ)全了請(qǐng)求頭后交給下一個(gè)攔截器處理，得到響應(yīng)后，主要干兩件事情：

1、保存cookie，在下次請(qǐng)求則會(huì)讀取對(duì)應(yīng)的數(shù)據(jù)設(shè)置進(jìn)入請(qǐng)求頭，默認(rèn)的CookieJar不提供實(shí)現(xiàn)

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

總結(jié)

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

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

三、緩存攔截器

CacheInterceptor，在發(fā)出請(qǐng)求前，判斷是否命中緩存。如果命中則可以不請(qǐng)求，直接使用緩存的響應(yīng)。 (只會(huì)存在Get請(qǐng)求的緩存)

步驟為:

1、從緩存中獲得對(duì)應(yīng)請(qǐng)求的響應(yīng)緩存

2、創(chuàng)建CacheStrategy ,創(chuàng)建時(shí)會(huì)判斷是否能夠使用緩存，在CacheStrategy 中存在兩個(gè)成員:networkRequest與cacheResponse。他們的組合如下:

3、交給下一個(gè)責(zé)任鏈繼續(xù)處理

4、后續(xù)工作，返回304則用緩存的響應(yīng)；否則使用網(wǎng)絡(luò)響應(yīng)并緩存本次響應(yīng)（只緩存Get請(qǐng)求的響應(yīng)）

緩存攔截器的工作說(shuō)起來(lái)比較簡(jiǎn)單，但是具體的實(shí)現(xiàn)，需要處理的內(nèi)容很多。在緩存攔截器中判斷是否可以使用緩存，或是請(qǐng)求服務(wù)器都是通過(guò)CacheStrategy判斷。

緩存策略

CacheStrategy。首先需要認(rèn)識(shí)幾個(gè)請(qǐng)求頭與響應(yīng)頭

其中Cache-Control可以在請(qǐng)求頭存在，也能在響應(yīng)頭存在，對(duì)應(yīng)的value可以設(shè)置多種組合：

1. max-age=[秒] ：資源最大有效時(shí)間;
2. public ：表明該資源可以被任何用戶緩存，比如客戶端，代理服務(wù)器等都可以緩存資源;
3. private：表明該資源只能被單個(gè)用戶緩存，默認(rèn)是private。
4. no-store：資源不允許被緩存
5. no-cache：(請(qǐng)求)不使用緩存
6. immutable：(響應(yīng))資源不會(huì)改變
7. min-fresh=[秒]：(請(qǐng)求)緩存最小新鮮度(用戶認(rèn)為這個(gè)緩存有效的時(shí)長(zhǎng))
8. must-revalidate：(響應(yīng))不允許使用過(guò)期緩存
9. max-stale=[秒]：(請(qǐng)求)緩存過(guò)期后多久內(nèi)仍然有效

假設(shè)存在max-age=100，min-fresh=20。這代表了用戶認(rèn)為這個(gè)緩存的響應(yīng)，從服務(wù)器創(chuàng)建響應(yīng) 到 能夠緩存使用的時(shí)間為100-20=80s。但是如果max-stale=100。這代表了緩存有效時(shí)間80s過(guò)后，仍然允許使用100s，可以看成緩存有效時(shí)長(zhǎng)為180s。

[圖片上傳失敗...(image-b71ccd-1572367003543)]

詳細(xì)流程

如果從緩存中獲得了本次請(qǐng)求URL對(duì)應(yīng)的Response，首先會(huì)從響應(yīng)中獲得以上數(shù)據(jù)備用。

public Factory(long nowMillis, Request request, Response cacheResponse) {
            this.nowMillis = nowMillis;
            this.request = request;
            this.cacheResponse = cacheResponse;

            if (cacheResponse != null) {
                //對(duì)應(yīng)響應(yīng)的請(qǐng)求發(fā)出的本地時(shí)間 和 接收到響應(yīng)的本地時(shí)間
                this.sentRequestMillis = cacheResponse.sentRequestAtMillis();
                this.receivedResponseMillis = cacheResponse.receivedResponseAtMillis();
                Headers headers = cacheResponse.headers();
                for (int i = 0, size = headers.size(); i < size; i++) {
                    String fieldName = headers.name(i);
                    String value = headers.value(i);
                    if ("Date".equalsIgnoreCase(fieldName)) {
                        servedDate = HttpDate.parse(value);
                        servedDateString = value;
                    } else if ("Expires".equalsIgnoreCase(fieldName)) {
                        expires = HttpDate.parse(value);
                    } else if ("Last-Modified".equalsIgnoreCase(fieldName)) {
                        lastModified = HttpDate.parse(value);
                        lastModifiedString = value;
                    } else if ("ETag".equalsIgnoreCase(fieldName)) {
                        etag = value;
                    } else if ("Age".equalsIgnoreCase(fieldName)) {
                        ageSeconds = HttpHeaders.parseSeconds(value, -1);
                    }
                }
            }
        }

判斷緩存的命中會(huì)使用get()方法

public CacheStrategy get() {
    CacheStrategy candidate = getCandidate();
    //todo 如果可以使用緩存，那networkRequest必定為null；指定了只使用緩存但是networkRequest又不為null，沖突。那就gg(攔截器返回504)
    if (candidate.networkRequest != null && request.cacheControl().onlyIfCached()) {
        // We're forbidden from using the network and the cache is insufficient.
        return new CacheStrategy(null, null);
    }
    return candidate;
}

方法中調(diào)用getCandidate()方法來(lái)完成真正的緩存判斷。

1、緩存是否存在

整個(gè)方法中的第一個(gè)判斷是緩存是不是存在：

if (cacheResponse == null) {
    return new CacheStrategy(request, null);
}

cacheResponse是從緩存中找到的響應(yīng)，如果為null，那就表示沒(méi)有找到對(duì)應(yīng)的緩存，創(chuàng)建的CacheStrategy實(shí)例對(duì)象只存在networkRequest，這代表了需要發(fā)起網(wǎng)絡(luò)請(qǐng)求。

2、https請(qǐng)求的緩存

繼續(xù)往下走意味著cacheResponse必定存在，但是它不一定能用。后續(xù)進(jìn)行有效性的一系列判斷

if (request.isHttps() && cacheResponse.handshake() == null) {
    return new CacheStrategy(request, null);
}

如果本次請(qǐng)求是HTTPS，但是緩存中沒(méi)有對(duì)應(yīng)的握手信息，那么緩存無(wú)效。

3、響應(yīng)碼以及響應(yīng)頭

if (!isCacheable(cacheResponse, request)) {
    return new CacheStrategy(request, null);
}

整個(gè)邏輯都在isCacheable中，他的內(nèi)容是:

public static boolean isCacheable(Response response, Request request) {
        // Always go to network for uncacheable response codes (RFC 7231 section 6.1),
        // This implementation doesn't support caching partial content.
        switch (response.code()) {
            case HTTP_OK:
            case HTTP_NOT_AUTHORITATIVE:
            case HTTP_NO_CONTENT:
            case HTTP_MULT_CHOICE:
            case HTTP_MOVED_PERM:
            case HTTP_NOT_FOUND:
            case HTTP_BAD_METHOD:
            case HTTP_GONE:
            case HTTP_REQ_TOO_LONG:
            case HTTP_NOT_IMPLEMENTED:
            case StatusLine.HTTP_PERM_REDIRECT:
                // These codes can be cached unless headers forbid it.
                break;

            case HTTP_MOVED_TEMP:
            case StatusLine.HTTP_TEMP_REDIRECT:
                // These codes can only be cached with the right response headers.
                // http://tools.ietf.org/html/rfc7234#section-3
                // s-maxage is not checked because OkHttp is a private cache that should ignore
                // s-maxage.
                if (response.header("Expires") != null
                        || response.cacheControl().maxAgeSeconds() != -1
                        || response.cacheControl().isPublic()
                        || response.cacheControl().isPrivate()) {
                    break;
                }
                // Fall-through.
            default:
                // All other codes cannot be cached.
                return false;
        }

        // A 'no-store' directive on request or response prevents the response from being cached.
        return !response.cacheControl().noStore() && !request.cacheControl().noStore();
}

緩存響應(yīng)中的響應(yīng)碼為 200, 203, 204, 300, 301, 404, 405, 410, 414, 501, 308 的情況下,只判斷服務(wù)器是不是給了 Cache-Control: no-store (資源不能被緩存)，所以如果服務(wù)器給到了這個(gè)響應(yīng)頭，那就和前面兩個(gè)判定一致(緩存不可用)。否則繼續(xù)進(jìn)一步判斷緩存是否可用

而如果響應(yīng)碼是302/307(重定向)，則需要進(jìn)一步判斷是不是存在一些允許緩存的響應(yīng)頭。根據(jù)注解中的給到的文檔http://tools.ietf.org/html/rfc7234#section-3中的描述，如果存在Expires或者Cache-Control的值為：

1. max-age=[秒] ：資源最大有效時(shí)間;
2. public ：表明該資源可以被任何用戶緩存，比如客戶端，代理服務(wù)器等都可以緩存資源;
3. private：表明該資源只能被單個(gè)用戶緩存，默認(rèn)是private。

同時(shí)不存在Cache-Control: no-store，那就可以繼續(xù)進(jìn)一步判斷緩存是否可用。

所以綜合來(lái)看判定優(yōu)先級(jí)如下：

1、響應(yīng)碼不為 200, 203, 204, 300, 301, 404, 405, 410, 414, 501, 308，302，307 緩存不可用;

2、當(dāng)響應(yīng)碼為302或者307時(shí)，未包含某些響應(yīng)頭，則緩存不可用;

3、當(dāng)存在Cache-Control: no-store響應(yīng)頭則緩存不可用。

如果響應(yīng)緩存可用，進(jìn)一步再判斷緩存有效性

4、用戶的請(qǐng)求配置

CacheControl requestCaching = request.cacheControl();
if (requestCaching.noCache() || hasConditions(request)) {
    return new CacheStrategy(request, null);
}
private static boolean hasConditions(Request request) {
    return request.header("If-Modified-Since") != null || request.header("If-None-Match") != null;
}

走到這一步，OkHttp需要先對(duì)用戶本次發(fā)起的Request進(jìn)行判定，如果用戶指定了Cache-Control: no-cache(不使用緩存)的請(qǐng)求頭或者請(qǐng)求頭包含 If-Modified-Since或If-None-Match(請(qǐng)求驗(yàn)證)，那么就不允許使用緩存。

這意味著如果用戶請(qǐng)求頭中包含了這些內(nèi)容，那就必須向服務(wù)器發(fā)起請(qǐng)求。但是需要注意的是，OkHttp并不會(huì)緩存304的響應(yīng)，如果是此種情況，即用戶主動(dòng)要求與服務(wù)器發(fā)起請(qǐng)求，服務(wù)器返回的304(無(wú)響應(yīng)體)，則直接把304的響應(yīng)返回給用戶：“既然你主動(dòng)要求，我就只告知你本次請(qǐng)求結(jié)果”。而如果不包含這些請(qǐng)求頭，那繼續(xù)判定緩存有效性。

5、資源是否不變

CacheControl responseCaching = cacheResponse.cacheControl();
if (responseCaching.immutable()) {
    return new CacheStrategy(null, cacheResponse);
}

如果緩存的響應(yīng)中包含Cache-Control: immutable，這意味著對(duì)應(yīng)請(qǐng)求的響應(yīng)內(nèi)容將一直不會(huì)改變。此時(shí)就可以直接使用緩存。否則繼續(xù)判斷緩存是否可用

6、響應(yīng)的緩存有效期

這一步為進(jìn)一步根據(jù)緩存響應(yīng)中的一些信息判定緩存是否處于有效期內(nèi)。如果滿足：

緩存存活時(shí)間 < 緩存新鮮度 - 緩存最小新鮮度 + 過(guò)期后繼續(xù)使用時(shí)長(zhǎng)

代表可以使用緩存。其中新鮮度可以理解為有效時(shí)間，而這里的 "緩存新鮮度-緩存最小新鮮度" 就代表了緩存真正有效的時(shí)間。

// 6.1、獲得緩存的響應(yīng)從創(chuàng)建到現(xiàn)在的時(shí)間
long ageMillis = cacheResponseAge();
//todo
// 6.2、獲取這個(gè)響應(yīng)有效緩存的時(shí)長(zhǎng)
long freshMillis = computeFreshnessLifetime();
if (requestCaching.maxAgeSeconds() != -1) {
//todo 如果請(qǐng)求中指定了 max-age 表示指定了能拿的緩存有效時(shí)長(zhǎng)，就需要綜合響應(yīng)有效緩存時(shí)長(zhǎng)與請(qǐng)求能拿緩存的時(shí)長(zhǎng)，獲得最小的能夠使用響應(yīng)緩存的時(shí)長(zhǎng)
        freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds()));
}
// 6.3 請(qǐng)求包含  Cache-Control:min-fresh=[秒]  能夠使用還未過(guò)指定時(shí)間的緩存 （請(qǐng)求認(rèn)為的緩存有效時(shí)間）
long minFreshMillis = 0;
if (requestCaching.minFreshSeconds() != -1) {
    minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
}
// 6.4
//  6.4.1、Cache-Control:must-revalidate 可緩存但必須再向源服務(wù)器進(jìn)行確認(rèn)
//  6.4.2、Cache-Control:max-stale=[秒] 緩存過(guò)期后還能使用指定的時(shí)長(zhǎng)  如果未指定多少秒，則表示無(wú)論過(guò)期多長(zhǎng)時(shí)間都可以；如果指定了，則只要是指定時(shí)間內(nèi)就能使用緩存
    // 前者會(huì)忽略后者，所以判斷了不必須向服務(wù)器確認(rèn)，再獲得請(qǐng)求頭中的max-stale
long maxStaleMillis = 0;
if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
    maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
}

// 6.5 不需要與服務(wù)器驗(yàn)證有效性 && 響應(yīng)存在的時(shí)間+請(qǐng)求認(rèn)為的緩存有效時(shí)間 小于 緩存有效時(shí)長(zhǎng)+過(guò)期后還可以使用的時(shí)間
// 允許使用緩存
if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
    Response.Builder builder = cacheResponse.newBuilder();
    //todo 如果已過(guò)期，但未超過(guò) 過(guò)期后繼續(xù)使用時(shí)長(zhǎng)，那還可以繼續(xù)使用，只用添加相應(yīng)的頭部字段
    if (ageMillis + minFreshMillis >= freshMillis) {
        builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
    }
    //todo 如果緩存已超過(guò)一天并且響應(yīng)中沒(méi)有設(shè)置過(guò)期時(shí)間也需要添加警告
    long oneDayMillis = 24 * 60 * 60 * 1000L;
    if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) {
        builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\"");
    }
    return new CacheStrategy(null, builder.build());
}

6.1、緩存到現(xiàn)在存活的時(shí)間：ageMillis

首先cacheResponseAge()方法獲得了響應(yīng)大概存在了多久:

long ageMillis = cacheResponseAge();

private long cacheResponseAge() {
    long apparentReceivedAge = servedDate != null
                    ? Math.max(0, receivedResponseMillis - servedDate.getTime())
                    : 0;
    long receivedAge = ageSeconds != -1
                    ? Math.max(apparentReceivedAge, SECONDS.toMillis(ageSeconds))
                    : apparentReceivedAge;
    long responseDuration = receivedResponseMillis - sentRequestMillis;
    long residentDuration = nowMillis - receivedResponseMillis;
    return receivedAge + responseDuration + residentDuration;
}

1、apparentReceivedAge代表了客戶端收到響應(yīng)到服務(wù)器發(fā)出響應(yīng)的一個(gè)時(shí)間差

seredData是從緩存中獲得的Data響應(yīng)頭對(duì)應(yīng)的時(shí)間（服務(wù)器發(fā)出本響應(yīng)的時(shí)間）；
receivedResponseMillis為本次響應(yīng)對(duì)應(yīng)的客戶端發(fā)出請(qǐng)求的時(shí)間

2、receivedAge是代表了客戶端的緩存，在收到時(shí)就已經(jīng)存在多久了

ageSeconds是從緩存中獲得的Age響應(yīng)頭對(duì)應(yīng)的秒數(shù) (本地緩存的響應(yīng)是由服務(wù)器的緩存返回，這個(gè)緩存在服務(wù)器存在的時(shí)間)

ageSeconds與上一步計(jì)算結(jié)果apparentReceivedAge的最大值為收到響應(yīng)時(shí)，這個(gè)響應(yīng)數(shù)據(jù)已經(jīng)存在多久。

假設(shè)我們發(fā)出請(qǐng)求時(shí)，服務(wù)器存在一個(gè)緩存，其中 Data: 0點(diǎn)。
此時(shí)，客戶端在1小時(shí)候發(fā)起請(qǐng)求，此時(shí)由服務(wù)器在緩存中插入Age: 1小時(shí)并返回給客戶端，此時(shí)客戶端計(jì)算的receivedAge就是1小時(shí)，這就代表了客戶端的緩存在收到時(shí)就已經(jīng)存在多久了。（不代表到本次請(qǐng)求時(shí)存在多久了）

3、responseDuration是緩存對(duì)應(yīng)的請(qǐng)求，在發(fā)送請(qǐng)求與接收請(qǐng)求之間的時(shí)間差

4、residentDuration是這個(gè)緩存接收到的時(shí)間到現(xiàn)在的一個(gè)時(shí)間差

receivedAge + responseDuration + residentDuration所代表的意義就是：

緩存在客戶端收到時(shí)就已經(jīng)存在的時(shí)間 + 請(qǐng)求過(guò)程中花費(fèi)的時(shí)間 + 本次請(qǐng)求距離緩存獲得的時(shí)間，就是緩存真正存在了多久。

6.2、緩存新鮮度(有效時(shí)間)：freshMillis

long freshMillis = computeFreshnessLifetime();

private long computeFreshnessLifetime() {
    CacheControl responseCaching = cacheResponse.cacheControl();
            
    if (responseCaching.maxAgeSeconds() != -1) {
        return SECONDS.toMillis(responseCaching.maxAgeSeconds());
    } else if (expires != null) {
        long servedMillis = servedDate != null ? servedDate.getTime() : receivedResponseMillis;
        long delta = expires.getTime() - servedMillis;
        return delta > 0 ? delta : 0;
    } else if (lastModified != null && cacheResponse.request().url().query() == null) {
        // As recommended by the HTTP RFC and implemented in Firefox, the
        // max age of a document should be defaulted to 10% of the
        // document's age at the time it was served. Default expiration
        // dates aren't used for URIs containing a query.
        long servedMillis = servedDate != null ? servedDate.getTime() : sentRequestMillis;
        long delta = servedMillis - lastModified.getTime();
        return delta > 0 ? (delta / 10) : 0;
    }
    return 0;
}

緩存新鮮度(有效時(shí)長(zhǎng))的判定會(huì)有幾種情況，按優(yōu)先級(jí)排列如下:

1、緩存響應(yīng)包含Cache-Control: max-age=[秒]資源最大有效時(shí)間

2、緩存響應(yīng)包含Expires: 時(shí)間，則通過(guò)Data或接收該響應(yīng)時(shí)間計(jì)算資源有效時(shí)間

3、緩存響應(yīng)包含Last-Modified: 時(shí)間，則通過(guò)Data或發(fā)送該響應(yīng)對(duì)應(yīng)請(qǐng)求的時(shí)間計(jì)算資源有效時(shí)間；并且根據(jù)建議以及在Firefox瀏覽器的實(shí)現(xiàn)，使用得到結(jié)果的10%來(lái)作為資源的有效時(shí)間。

6.3、緩存最小新鮮度：minFreshMillis

long minFreshMillis = 0;
if (requestCaching.minFreshSeconds() != -1) {
    minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
}

如果用戶的請(qǐng)求頭中包含Cache-Control: min-fresh=[秒]，代表用戶認(rèn)為這個(gè)緩存有效的時(shí)長(zhǎng)。假設(shè)本身緩存新鮮度為: 100毫秒，而緩存最小新鮮度為：10毫秒，那么緩存真正有效時(shí)間為90毫秒。

6.4、緩存過(guò)期后仍有效時(shí)長(zhǎng)：maxStaleMillis

long maxStaleMillis = 0;
if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
    maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
}

這個(gè)判斷中第一個(gè)條件為緩存的響應(yīng)中沒(méi)有包含Cache-Control: must-revalidate(不可用過(guò)期資源)，獲得用戶請(qǐng)求頭中包含Cache-Control: max-stale=[秒]緩存過(guò)期后仍有效的時(shí)長(zhǎng)。

6.5、判定緩存是否有效

if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
    Response.Builder builder = cacheResponse.newBuilder();
    //todo 如果已過(guò)期，但未超過(guò) 過(guò)期后繼續(xù)使用時(shí)長(zhǎng)，那還可以繼續(xù)使用，只用添加相應(yīng)的頭部字段
    if (ageMillis + minFreshMillis >= freshMillis) {
        builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
    }
    //todo 如果緩存已超過(guò)一天并且響應(yīng)中沒(méi)有設(shè)置過(guò)期時(shí)間也需要添加警告
    long oneDayMillis = 24 * 60 * 60 * 1000L;
    if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) {
        builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\"");
    }
    return new CacheStrategy(null, builder.build());
}

最后利用上4步產(chǎn)生的值，只要緩存的響應(yīng)未指定no-cache忽略緩存，如果：

緩存存活時(shí)間+緩存最小新鮮度 < 緩存新鮮度+過(guò)期后繼續(xù)使用時(shí)長(zhǎng)，代表可以使用緩存。

假設(shè) 緩存到現(xiàn)在存活了：100 毫秒;
用戶認(rèn)為緩存有效時(shí)間(緩存最小新鮮度)為：10 毫秒;
緩存新鮮度為: 100 毫秒;
緩存過(guò)期后仍能使用: 0 毫秒;
這些條件下，首先緩存的真實(shí)有效時(shí)間為: 90毫秒，而緩存已經(jīng)過(guò)了這個(gè)時(shí)間，所以無(wú)法使用緩存。

不等式可以轉(zhuǎn)換為: 緩存存活時(shí)間 < 緩存新鮮度 - 緩存最小新鮮度 + 過(guò)期后繼續(xù)使用時(shí)長(zhǎng)，即
存活時(shí)間 < 緩存有效時(shí)間 + 過(guò)期后繼續(xù)使用時(shí)間

總體來(lái)說(shuō)，只要不忽略緩存并且緩存未過(guò)期，則使用緩存。

7、緩存過(guò)期處理

String conditionName;
String conditionValue;
if (etag != null) {
    conditionName = "If-None-Match";
    conditionValue = etag;
} else if (lastModified != null) {
    conditionName = "If-Modified-Since";
    conditionValue = lastModifiedString;
} else if (servedDate != null) {
    conditionName = "If-Modified-Since";
    conditionValue = servedDateString;
} else {
    //意味著無(wú)法與服務(wù)器發(fā)起比較，只能重新請(qǐng)求
    return new CacheStrategy(request, null); // No condition! Make a regular request.
}

//添加請(qǐng)求頭
Headers.Builder conditionalRequestHeaders = request.headers().newBuilder();
Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);
Request conditionalRequest = request.newBuilder()
    .headers(conditionalRequestHeaders.build())
    .build();
return new CacheStrategy(conditionalRequest, cacheResponse);

如果繼續(xù)執(zhí)行，表示緩存已經(jīng)過(guò)期無(wú)法使用。此時(shí)我們判定緩存的響應(yīng)中如果存在Etag，則使用If-None-Match交給服務(wù)器進(jìn)行驗(yàn)證；如果存在Last-Modified或者Data，則使用If-Modified-Since交給服務(wù)器驗(yàn)證。服務(wù)器如果無(wú)修改則會(huì)返回304，這時(shí)候注意：

由于是緩存過(guò)期而發(fā)起的請(qǐng)求(與第4個(gè)判斷用戶的主動(dòng)設(shè)置不同)，如果服務(wù)器返回304，那框架會(huì)自動(dòng)更新緩存，所以此時(shí)CacheStrategy既包含networkRequest也包含cacheResponse

8、收尾

至此，緩存的判定結(jié)束，攔截器中只需要判斷CacheStrategy中networkRequest與cacheResponse的不同組合就能夠判斷是否允許使用緩存。

但是需要注意的是，如果用戶在創(chuàng)建請(qǐng)求時(shí)，配置了onlyIfCached這意味著用戶這次希望這個(gè)請(qǐng)求只從緩存獲得，不需要發(fā)起請(qǐng)求。那如果生成的CacheStrategy存在networkRequest這意味著肯定會(huì)發(fā)起請(qǐng)求，此時(shí)出現(xiàn)沖突！那會(huì)直接給到攔截器一個(gè)既沒(méi)有networkRequest又沒(méi)有cacheResponse的對(duì)象。攔截器直接返回用戶504！

//緩存策略 get 方法
if (candidate.networkRequest != null && request.cacheControl().onlyIfCached()) {
    // We're forbidden from using the network and the cache is insufficient.
    return new CacheStrategy(null, null);
}

//緩存攔截器
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();
}

9、總結(jié)

1、如果從緩存獲取的Response是null，那就需要使用網(wǎng)絡(luò)請(qǐng)求獲取響應(yīng)；
2、如果是Https請(qǐng)求，但是又丟失了握手信息，那也不能使用緩存，需要進(jìn)行網(wǎng)絡(luò)請(qǐng)求；
3、如果判斷響應(yīng)碼不能緩存且響應(yīng)頭有no-store標(biāo)識(shí)，那就需要進(jìn)行網(wǎng)絡(luò)請(qǐng)求；
4、如果請(qǐng)求頭有no-cache標(biāo)識(shí)或者有If-Modified-Since/If-None-Match，那么需要進(jìn)行網(wǎng)絡(luò)請(qǐng)求；
5、如果響應(yīng)頭沒(méi)有no-cache標(biāo)識(shí)，且緩存時(shí)間沒(méi)有超過(guò)極限時(shí)間，那么可以使用緩存，不需要進(jìn)行網(wǎng)絡(luò)請(qǐng)求；
6、如果緩存過(guò)期了，判斷響應(yīng)頭是否設(shè)置Etag/Last-Modified/Date，沒(méi)有那就直接使用網(wǎng)絡(luò)請(qǐng)求否則需要考慮服務(wù)器返回304；

并且，只要需要進(jìn)行網(wǎng)絡(luò)請(qǐng)求，請(qǐng)求頭中就不能包含only-if-cached，否則框架直接返回504！

緩存攔截器本身主要邏輯其實(shí)都在緩存策略中，攔截器本身邏輯非常簡(jiǎn)單，如果確定需要發(fā)起網(wǎng)絡(luò)請(qǐng)求，則下一個(gè)攔截器為ConnectInterceptor

四、連接攔截器

ConnectInterceptor，打開(kāi)與目標(biāo)服務(wù)器的連接，并執(zhí)行下一個(gè)攔截器。它簡(jiǎn)短的可以直接完整貼在這里：

public final class ConnectInterceptor implements Interceptor {
  public final OkHttpClient client;

  public ConnectInterceptor(OkHttpClient client) {
    this.client = client;
  }

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

雖然代碼量很少，實(shí)際上大部分功能都封裝到其它類去了，這里只是調(diào)用而已。

首先我們看到的StreamAllocation這個(gè)對(duì)象是在第一個(gè)攔截器：重定向攔截器創(chuàng)建的，但是真正使用的地方卻在這里。

"當(dāng)一個(gè)請(qǐng)求發(fā)出，需要建立連接，連接建立后需要使用流用來(lái)讀寫數(shù)據(jù)"；而這個(gè)StreamAllocation就是協(xié)調(diào)請(qǐng)求、連接與數(shù)據(jù)流三者之間的關(guān)系，它負(fù)責(zé)為一次請(qǐng)求尋找連接，然后獲得流來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)通信。

這里使用的newStream方法實(shí)際上就是去查找或者建立一個(gè)與請(qǐng)求主機(jī)有效的連接，返回的HttpCodec中包含了輸入輸出流，并且封裝了對(duì)HTTP請(qǐng)求報(bào)文的編碼與解碼，直接使用它就能夠與請(qǐng)求主機(jī)完成HTTP通信。

StreamAllocation中簡(jiǎn)單來(lái)說(shuō)就是維護(hù)連接：RealConnection——封裝了Socket與一個(gè)Socket連接池?？蓮?fù)用的RealConnection需要：

public boolean isEligible(Address address, @Nullable Route route) {
    // If this connection is not accepting new streams, we're done.
    if (allocations.size() >= allocationLimit || noNewStreams) return false;

    // If the non-host fields of the address don't overlap, we're done.
    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.
    }

    // At this point we don't have a hostname match. But we still be able to carry the request if
    // our connection coalescing requirements are met. See also:
    // https://hpbn.co/optimizing-application-delivery/#eliminate-domain-sharding
    // https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

    // 1. This connection must be HTTP/2.
    if (http2Connection == null) return false;

    // 2. The routes must share an IP address. This requires us to have a DNS address for both
    // hosts, which only happens after route planning. We can't coalesce connections that use a
    // proxy, since proxies don't tell us the origin server's IP address.
    if (route == null) return false;
    if (route.proxy().type() != Proxy.Type.DIRECT) return false;
    if (this.route.proxy().type() != Proxy.Type.DIRECT) return false;
    if (!this.route.socketAddress().equals(route.socketAddress())) return false;

    // 3. This connection's server certificate's must cover the new host.
    if (route.address().hostnameVerifier() != OkHostnameVerifier.INSTANCE) return false;
    if (!supportsUrl(address.url())) return false;

    // 4. Certificate pinning must match the host.
    try {
      address.certificatePinner().check(address.url().host(), handshake().peerCertificates());
    } catch (SSLPeerUnverifiedException e) {
      return false;
    }

    return true; // The caller's address can be carried by this connection.
  }

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

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

2、

if (!Internal.instance.equalsNonHost(this.route.address(), address)) return false;
if (address.url().host().equals(this.route().address().url().host())) {
      return true; // This connection is a perfect match.
}

DNS、代理、SSL證書(shū)、服務(wù)器域名、端口完全相同則可復(fù)用；

如果上述條件都不滿足，在HTTP/2的某些場(chǎng)景下可能仍可以復(fù)用(http2先不管)。

所以綜上，如果在連接池中找到個(gè)連接參數(shù)一致并且未被關(guān)閉沒(méi)被占用的連接，則可以復(fù)用。

總結(jié)

這個(gè)攔截器中的所有實(shí)現(xiàn)都是為了獲得一份與目標(biāo)服務(wù)器的連接，在這個(gè)連接上進(jìn)行HTTP數(shù)據(jù)的收發(fā)。

五、請(qǐng)求服務(wù)器攔截器

CallServerInterceptor，利用HttpCodec發(fā)出請(qǐng)求到服務(wù)器并且解析生成Response。

首先調(diào)用httpCodec.writeRequestHeaders(request); 將請(qǐng)求頭寫入到緩存中(直到調(diào)用flushRequest()才真正發(fā)送給服務(wù)器)。然后馬上進(jìn)行第一個(gè)邏輯判斷

Response.Builder responseBuilder = null;
if (HttpMethod.permitsRequestBody(request.method()) && request.body() != 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".equalsIgnoreCase(request.header("Expect"))) {
        httpCodec.flushRequest();
        realChain.eventListener().responseHeadersStart(realChain.call());
        responseBuilder = httpCodec.readResponseHeaders(true);
    }
    if (responseBuilder == null) {
        // Write the request body if the "Expect: 100-continue" expectation was met.
        realChain.eventListener().requestBodyStart(realChain.call());
        long contentLength = request.body().contentLength();
        CountingSink requestBodyOut =
                        new CountingSink(httpCodec.createRequestBody(request, contentLength));
        BufferedSink bufferedRequestBody = Okio.buffer(requestBodyOut);

        request.body().writeTo(bufferedRequestBody);
        bufferedRequestBody.close();
        realChain.eventListener().requestBodyEnd(realChain.call(),requestBodyOut.successfulCount);
    } else if (!connection.isMultiplexed()) { 
        //HTTP2多路復(fù)用，不需要關(guān)閉socket，不管！
        // 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.
        streamAllocation.noNewStreams();
    }
}
httpCodec.finishRequest();

整個(gè)if都和一個(gè)請(qǐng)求頭有關(guān)： Expect: 100-continue。這個(gè)請(qǐng)求頭代表了在發(fā)送請(qǐng)求體之前需要和服務(wù)器確定是否愿意接受客戶端發(fā)送的請(qǐng)求體。所以permitsRequestBody判斷為是否會(huì)攜帶請(qǐng)求體的方式(POST)，如果命中if，則會(huì)先給服務(wù)器發(fā)起一次查詢是否愿意接收請(qǐng)求體，這時(shí)候如果服務(wù)器愿意會(huì)響應(yīng)100(沒(méi)有響應(yīng)體，responseBuilder 即為nul)。這時(shí)候才能夠繼續(xù)發(fā)送剩余請(qǐng)求數(shù)據(jù)。

但是如果服務(wù)器不同意接受請(qǐng)求體，那么我們就需要標(biāo)記該連接不能再被復(fù)用，調(diào)用noNewStreams()關(guān)閉相關(guān)的Socket。

后續(xù)代碼為:

if (responseBuilder == null) {
    realChain.eventListener().responseHeadersStart(realChain.call());
    responseBuilder = httpCodec.readResponseHeaders(false);
}

Response response = responseBuilder
                .request(request)
                .handshake(streamAllocation.connection().handshake())
                .sentRequestAtMillis(sentRequestMillis)
                .receivedResponseAtMillis(System.currentTimeMillis())
                .build();

這時(shí)responseBuilder的情況即為：

1、POST方式請(qǐng)求，請(qǐng)求頭中包含Expect，服務(wù)器允許接受請(qǐng)求體，并且已經(jīng)發(fā)出了請(qǐng)求體，responseBuilder為null;

2、POST方式請(qǐng)求，請(qǐng)求頭中包含Expect，服務(wù)器不允許接受請(qǐng)求體，responseBuilder不為null

3、POST方式請(qǐng)求，未包含Expect，直接發(fā)出請(qǐng)求體，responseBuilder為null;

4、POST方式請(qǐng)求，沒(méi)有請(qǐng)求體，responseBuilder為null;

5、GET方式請(qǐng)求，responseBuilder為null;

對(duì)應(yīng)上面的5種情況，讀取響應(yīng)頭并且組成響應(yīng)Response，注意：此Response沒(méi)有響應(yīng)體。同時(shí)需要注意的是，如果服務(wù)器接受 Expect: 100-continue這是不是意味著我們發(fā)起了兩次Request？那此時(shí)的響應(yīng)頭是第一次查詢服務(wù)器是否支持接受請(qǐng)求體的，而不是真正的請(qǐng)求對(duì)應(yīng)的結(jié)果響應(yīng)。所以緊接著:

int code = response.code();
if (code == 100) {
    // server sent a 100-continue even though we did not request one.
    // try again to read the actual response
    responseBuilder = httpCodec.readResponseHeaders(false);

    response = responseBuilder
                    .request(request)
                    .handshake(streamAllocation.connection().handshake())
                    .sentRequestAtMillis(sentRequestMillis)
                    .receivedResponseAtMillis(System.currentTimeMillis())
                    .build();

    code = response.code();
}

如果響應(yīng)是100，這代表了是請(qǐng)求Expect: 100-continue成功的響應(yīng)，需要馬上再次讀取一份響應(yīng)頭，這才是真正的請(qǐng)求對(duì)應(yīng)結(jié)果響應(yīng)頭。

然后收尾

if (forWebSocket && code == 101) {
// Connection is upgrading, but we need to ensure interceptors see a non-null
// response body.
    response = response.newBuilder()
                    .body(Util.EMPTY_RESPONSE)
                    .build();
} else {
    response = response.newBuilder()
                    .body(httpCodec.openResponseBody(response))
                    .build();
}

if ("close".equalsIgnoreCase(response.request().header("Connection"))
                || "close".equalsIgnoreCase(response.header("Connection"))) {
    streamAllocation.noNewStreams();
}

if ((code == 204 || code == 205) && response.body().contentLength() > 0) {
    throw new ProtocolException(
        "HTTP " + code + " had non-zero Content-Length: " +  response.body().contentLength());
}
return response；

forWebSocket代表websocket的請(qǐng)求，我們直接進(jìn)入else，這里就是讀取響應(yīng)體數(shù)據(jù)。然后判斷請(qǐng)求和服務(wù)器是不是都希望長(zhǎng)連接，一旦有一方指明close，那么就需要關(guān)閉socket。而如果服務(wù)器返回204/205，一般情況而言不會(huì)存在這些返回碼，但是一旦出現(xiàn)這意味著沒(méi)有響應(yīng)體，但是解析到的響應(yīng)頭中包含Content-Lenght且不為0，這表響應(yīng)體的數(shù)據(jù)字節(jié)長(zhǎng)度。此時(shí)出現(xiàn)了沖突，直接拋出協(xié)議異常！

總結(jié)

在這個(gè)攔截器中就是完成HTTP協(xié)議報(bào)文的封裝與解析。

OkHttp總結(jié)

整個(gè)OkHttp功能的實(shí)現(xiàn)就在這五個(gè)默認(rèn)的攔截器中，所以先理解攔截器模式的工作機(jī)制是先決條件。這五個(gè)攔截器分別為: 重試攔截器、橋接攔截器、緩存攔截器、連接攔截器、請(qǐng)求服務(wù)攔截器。每一個(gè)攔截器負(fù)責(zé)的工作不一樣，就好像工廠流水線，最終經(jīng)過(guò)這五道工序，就完成了最終的產(chǎn)品。

但是與流水線不同的是，OkHttp中的攔截器每次發(fā)起請(qǐng)求都會(huì)在交給下一個(gè)攔截器之前干一些事情，在獲得了結(jié)果之后又干一些事情。整個(gè)過(guò)程在請(qǐng)求向是順序的，而響應(yīng)向則是逆序。

當(dāng)用戶發(fā)起一個(gè)請(qǐng)求后，會(huì)由任務(wù)分發(fā)起Dispatcher將請(qǐng)求包裝并交給重試攔截器處理。

1、重試攔截器在交出(交給下一個(gè)攔截器)之前，負(fù)責(zé)判斷用戶是否取消了請(qǐng)求；在獲得了結(jié)果之后，會(huì)根據(jù)響應(yīng)碼判斷是否需要重定向，如果滿足條件那么就會(huì)重啟執(zhí)行所有攔截器。

2、橋接攔截器在交出之前，負(fù)責(zé)將HTTP協(xié)議必備的請(qǐng)求頭加入其中(如：Host)并添加一些默認(rèn)的行為(如：GZIP壓縮)；在獲得了結(jié)果后，調(diào)用保存cookie接口并解析GZIP數(shù)據(jù)。

3、緩存攔截器顧名思義，交出之前讀取并判斷是否使用緩存；獲得結(jié)果后判斷是否緩存。

4、連接攔截器在交出之前，負(fù)責(zé)找到或者新建一個(gè)連接，并獲得對(duì)應(yīng)的socket流；在獲得結(jié)果后不進(jìn)行額外的處理。

5、請(qǐng)求服務(wù)器攔截器進(jìn)行真正的與服務(wù)器的通信，向服務(wù)器發(fā)送數(shù)據(jù)，解析讀取的響應(yīng)數(shù)據(jù)。

在經(jīng)過(guò)了這一系列的流程后，就完成了一次HTTP請(qǐng)求！

補(bǔ)充: 代理

在使用OkHttp時(shí)，如果用戶在創(chuàng)建OkHttpClient時(shí)，配置了proxy或者proxySelector，則會(huì)使用配置的代理，并且proxy優(yōu)先級(jí)高于proxySelector。而如果未配置，則會(huì)獲取機(jī)器配置的代理并使用。

//JDK : ProxySelector
try {
    URI uri = new URI("http://restapi.amap.com");
    List<Proxy> proxyList = ProxySelector.getDefault().select(uri);
    System.out.println(proxyList.get(0).address());
    System.out.println(proxyList.get(0).type());
} catch (URISyntaxException e) {
    e.printStackTrace();
}

因此，如果我們不需要自己的App中的請(qǐng)求走代理，則可以配置一個(gè)proxy(Proxy.NO_PROXY)，這樣也可以避免被抓包。NO_PROXY的定義如下：

public static final Proxy NO_PROXY = new Proxy();
private Proxy() {
    this.type = Proxy.Type.DIRECT;
    this.sa = null;
}

代理在Java中對(duì)應(yīng)的抽象類有三種類型:

public static enum Type {
        DIRECT,
        HTTP,
        SOCKS;
    private Type() {
    }
}

DIRECT：無(wú)代理，HTTP：http代理，SOCKS：socks代理。第一種自然不用多說(shuō)，而Http代理與Socks代理有什么區(qū)別？

對(duì)于Socks代理，在HTTP的場(chǎng)景下，代理服務(wù)器完成TCP數(shù)據(jù)包的轉(zhuǎn)發(fā)工作;
而Http代理服務(wù)器，在轉(zhuǎn)發(fā)數(shù)據(jù)之外，還會(huì)解析HTTP的請(qǐng)求及響應(yīng)，并根據(jù)請(qǐng)求及響應(yīng)的內(nèi)容做一些處理。

RealConnection的connectSocket方法:

//如果是Socks代理則 new Socket(proxy); 否則相當(dāng)于直接:new Socket()
rawSocket = proxy.type() == Proxy.Type.DIRECT || proxy.type() == Proxy.Type.HTTP
                ? address.socketFactory().createSocket()
                : new Socket(proxy);
//connect方法
socket.connect(address);

設(shè)置了SOCKS代理的情況下，創(chuàng)建Socket時(shí)，為其傳入proxy，連接時(shí)還是以HTTP服務(wù)器為目標(biāo)地址；但是如果設(shè)置的是Http代理，創(chuàng)建Socket是與Http代理服務(wù)器建立連接。

在connect方法時(shí)傳遞的address來(lái)自于下面的集合inetSocketAddresses
RouteSelector的resetNextInetSocketAddress方法：

private void resetNextInetSocketAddress(Proxy proxy) throws IOException {
    // ......
    if (proxy.type() == Proxy.Type.DIRECT || proxy.type() == Proxy.Type.SOCKS) {
        //無(wú)代理和socks代理，使用http服務(wù)器域名與端口
      socketHost = address.url().host();
      socketPort = address.url().port();
    } else {
      SocketAddress proxyAddress = proxy.address();
      if (!(proxyAddress instanceof InetSocketAddress)) {
        throw new IllegalArgumentException(
            "Proxy.address() is not an " + "InetSocketAddress: " + proxyAddress.getClass());
      }
      InetSocketAddress proxySocketAddress = (InetSocketAddress) proxyAddress;
      socketHost = getHostString(proxySocketAddress);
      socketPort = proxySocketAddress.getPort();
    }

    // ......

    if (proxy.type() == Proxy.Type.SOCKS) {
        //socks代理 connect http服務(wù)器 （DNS沒(méi)用，由代理服務(wù)器解析域名）
      inetSocketAddresses.add(InetSocketAddress.createUnresolved(socketHost, socketPort));
    } else {
        //無(wú)代理，dns解析http服務(wù)器
        //http代理,dns解析http代理服務(wù)器
      List<InetAddress> addresses = address.dns().lookup(socketHost);
      //......
      for (int i = 0, size = addresses.size(); i < size; i++) {
        InetAddress inetAddress = addresses.get(i);
        inetSocketAddresses.add(new InetSocketAddress(inetAddress, socketPort));
      }
    }
}

設(shè)置代理時(shí)，Http服務(wù)器的域名解析會(huì)被交給代理服務(wù)器執(zhí)行。但是如果是設(shè)置了Http代理，會(huì)對(duì)Http代理服務(wù)器的域名使用OkhttpClient配置的dns解析代理服務(wù)器，Http服務(wù)器的域名解析被交給代理服務(wù)器解析。

上述代碼就是代理與DNS在OkHttp中的使用，但是還有一點(diǎn)需要注意，Http代理也分成兩種類型：普通代理與隧道代理。

其中普通代理不需要額外的操作，扮演「中間人」的角色，在兩端之間來(lái)回傳遞報(bào)文。這個(gè)“中間人”在收到客戶端發(fā)送的請(qǐng)求報(bào)文時(shí)，需要正確的處理請(qǐng)求和連接狀態(tài)，同時(shí)向服務(wù)器發(fā)送新的請(qǐng)求，在收到響應(yīng)后，將響應(yīng)結(jié)果包裝成一個(gè)響應(yīng)體返回給客戶端。在普通代理的流程中，代理兩端都是有可能察覺(jué)不到"中間人“的存在。

但是隧道代理不再作為中間人，無(wú)法改寫客戶端的請(qǐng)求，而僅僅是在建立連接后，將客戶端的請(qǐng)求，通過(guò)建立好的隧道，無(wú)腦的轉(zhuǎn)發(fā)給終端服務(wù)器。隧道代理需要發(fā)起Http CONNECT請(qǐng)求，這種請(qǐng)求方式?jīng)]有請(qǐng)求體，僅供代理服務(wù)器使用，并不會(huì)傳遞給終端服務(wù)器。請(qǐng)求頭 部分一旦結(jié)束，后面的所有數(shù)據(jù)，都被視為應(yīng)該轉(zhuǎn)發(fā)給終端服務(wù)器的數(shù)據(jù)，代理需要把他們無(wú)腦的直接轉(zhuǎn)發(fā)，直到從客戶端的 TCP 讀通道關(guān)閉。CONNECT 的響應(yīng)報(bào)文，在代理服務(wù)器和終端服務(wù)器建立連接后，可以向客戶端返回一個(gè) 200 Connect established 的狀態(tài)碼，以此表示和終端服務(wù)器的連接，建立成功。

RealConnection的connect方法

if (route.requiresTunnel()) {         
    connectTunnel(connectTimeout, readTimeout, writeTimeout, call, eventListener);
    if (rawSocket == null) {
        // We were unable to connect the tunnel but properly closed down our
        // resources.
        break;
    }
} else {
    connectSocket(connectTimeout, readTimeout, call, eventListener);
}

requiresTunnel方法的判定為：當(dāng)前請(qǐng)求為https并且存在http代理，這時(shí)候connectTunnel中會(huì)發(fā)起:

CONNECT xxxx HTTP/1.1
Host: xxxx
Proxy-Connection: Keep-Alive
User-Agent: okhttp/${version}

的請(qǐng)求，連接成功代理服務(wù)器會(huì)返回200；如果返回407表示代理服務(wù)器需要鑒權(quán)(如：付費(fèi)代理)，這時(shí)需要在請(qǐng)求頭中加入Proxy-Authorization：

 Authenticator authenticator = new Authenticator() {
        @Nullable
        @Override
        public Request authenticate(Route route, Response response) throws IOException {
          if(response.code == 407){
            //代理鑒權(quán)
            String credential = Credentials.basic("代理服務(wù)用戶名", "代理服務(wù)密碼");
            return response.request().newBuilder()
                    .header("Proxy-Authorization", credential)
                    .build();
          }
          return null;
        }
      };
new OkHttpClient.Builder().proxyAuthenticator(authenticator);