從輸入url到傳送請求發生了什麼

從輸入url到傳送請求經歷了一些事情，今天我們來總結一下。 簡單來說，共有以下幾個過程

• DNS域名解析
• 發起TCP連線
• 傳送HTTP請求
• 伺服器處理請求並返回HTTP報文
• 瀏覽器解析渲染頁面
• 連線結束

URL地址構成

DNS域名解析

什麼是域名解析

域名系統（英文：DomainNameSystem，縮寫：DNS）是網際網路的一項服務。它作為將域名和IP地址相互對映的一個分散式資料庫，能夠使人更方便地訪問網際網路

域名解析過程

• 系統會檢查瀏覽器快取中有沒有這個域名對應的解析過的 IP 地址，如果快取中有，這個解析過程就將結束。瀏覽器快取是受這個域名的失效時間和快取的空間大小控制的。
• 如果使用者的瀏覽器快取中沒有，瀏覽器會查詢作業系統快取中即為本地的 Host 檔案
• 路由器也可能會有快取。
• 作業系統將域名傳送至本地域名伺服器， 本地域名伺服器查詢自己的 DNS 快取，查詢成功則返回結果，失敗則發起一個迭代 DNS 解析請求
  1、本地域名伺服器 向 根域名伺服器，其雖然沒有每個域名的的具體資訊，但儲存了負責每個域，如 com、net、org等的解析的頂級域名伺服器的地址）發起請求，此處，根域名伺服器 返回 com 域的頂級域名伺服器的地址；
  2、本地域名伺服器 向 com 域的頂級域名伺服器發起請求，返回 baidu.com 域名伺服器地址；
  3、本地域名伺服器向 baidu.com 域名伺服器發起請求，得到 www.baidu.com 的 IP 地址；
• 本地域名伺服器 將得到的 IP 地址返回給作業系統，同時自己也將 IP 地址快取起來； 作業系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址快取起來；
• 至此，瀏覽器已經得到了域名對應的 IP 地址。

發起TCP連線

TCP/IP 五層協議

• 應用層：決定向使用者提供應用服務時通訊的活動。TCP/IP 協議族內預存了各類通用的應用服務。比如：FTP、DNS、HTTP 協議。
• 傳輸層：傳輸層對上層應用層，提供處於網路連線中的兩臺計算機之間的資料傳輸。在傳輸層有兩個性質不同的協議，分別是 TCP (Transmission Control Protocol，傳輸控制協議) 和 UDP (User Data Protocol，使用者資料包協議)
• 網路層：網路層用來處理在網路上流動的資料包。資料包是網路傳輸的最小資料單位。該層規定了通過怎樣的路徑到達對方計算機，並把資料包傳送給對方。與對方計算機通過多臺計算機或網路裝置進行傳輸時，網路層所起的作用就是在眾多的選項內選擇一條傳輸路線。
• 資料鏈路層: 在物理層提供位元流服務的基礎上，建立相鄰結點之間的資料鏈路，通過差錯控制提供資料幀 (Frame)在通道上無差錯的傳輸，並進行各電路上的動作系列。資料的單位稱為幀 (frame)
• 物理層：物理層建立在物理通訊介質的基礎上，作為系統和通訊介質的介面，用來實現資料鏈路實體間透明的位元 (bit) 流傳輸。只有該層為真實物理通訊，其它各層為虛擬通訊。

TCP協議

TCP協議全稱是傳輸控制協議是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議，由 IETF 的RFC 793定義。TCP 是面向連線的、可靠的流協議。流就是指不間斷的資料結構，你可以把它想象成排水管中的水流。

TCP連線過程（三次握手)

• 1、第一次握手：客戶端傳送syn包(Seq=x)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
• 2、第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也傳送一個SYN包（Seq=y），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
• 3、第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=y+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
• 握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主動關閉連線之前，TCP 連線都將被一直保持下去。

為什麼會採用三次握手，若採用二次握手可以嗎？ 四次呢？

• 建立連線的過程是利用客戶伺服器模式，假設主機A為客戶端，主機B為伺服器端。
  採用三次握手是為了防止失效的連線請求報文段突然又傳送到主機B，因而產生錯誤。失效的連線請求報文段是指：主機A發出的連線請求沒有收到主機B的確認，於是經過一段時間後，主機A又重新向主機B傳送連線請求，且建立成功，順序完成資料傳輸。考慮這樣一種特殊情況，主機A第一次傳送的連線請求並沒有丟失，而是因為網路節點導致延遲達到主機B，主機B以為是主機A又發起的新連線，於是主機B同意連線，並向主機A發回確認，但是此時主機A根本不會理會，主機B就一直在等待主機A傳送資料，導致主機B的資源浪費。
• 採用兩次握手不行，原因就是上面說的失效的連線請求的特殊情況。而在三次握手中， client和server都有一個發syn和收ack的過程， 雙方都是發後能收， 表明通訊則準備工作OK.
• 為什麼不是四次握手呢？ 大家應該知道通訊中著名的藍軍紅軍約定， 這個例子說明， 通訊不可能100%可靠， 而上面的三次握手已經做好了通訊的準備工作， 再增加握手， 並不能顯著提高可靠性， 而且也沒有必要。

TCP協議的特點

• 面向連線

面向連線，是指傳送資料之前必須在兩端建立連線。建立連線的方法是“三次握手”，這樣能建立可靠的連線。建立連線，是為資料的可靠傳輸打下了基礎。

• 僅支援單播傳輸

每條TCP傳輸連線只能有兩個端點，只能進行點對點的資料傳輸，不支援多播和廣播傳輸方式。

• 面向位元組流

TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以位元組流方式進行傳輸。

• 可靠傳輸

對於可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認(ACK)；如果傳送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的資料（假設丟失了）將會被重傳。

• 提供擁塞控制

當網路出現擁塞的時候，TCP能夠減小向網路注入資料的速率和數量，緩解擁塞

• TCP提供全雙工通訊

TCP允許通訊雙方的應用程式在任何時候都能傳送資料，因為TCP連線的兩端都設有快取，用來臨時存放雙向通訊的資料。當然，TCP可以立即傳送一個資料段，也可以快取一段時間以便一次傳送更多的資料段（最大的資料段大小取決於MSS）

UDP協議

UDP協議全稱是使用者資料包協議，在網路中它與TCP協議一樣用於處理資料包，是一種無連線的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。UDP有不提供資料包分組、組裝和不能對資料包進行排序的缺點，也就是說，當報文傳送之後，是無法得知其是否安全完整到達的。

UDP協議的特點

• 面向無連線

首先 UDP 是不需要和 TCP一樣在傳送資料前進行三次握手建立連線的，想發資料就可以開始傳送了。並且也只是資料包文的搬運工，不會對資料包文進行任何拆分和拼接操作。具體來說就是：

• 在傳送端，應用層將資料傳遞給傳輸層的 UDP 協議，UDP 只會給資料增加一個 UDP 頭標識下是 UDP 協議，然後就傳遞給網路層了
• 在接收端，網路層將資料傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作

• 有單播，多播，廣播的功能

UDP 不止支援一對一的傳輸方式，同樣支援一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

• UDP是面向報文的

傳送方的UDP對應用程式交下來的報文，在新增首部後就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。因此，應用程式必須選擇合適大小的報文

• 不可靠性

首先不可靠性體現在無連線上，通訊都不需要建立連線，想發就發，這樣的情況肯定不可靠。 並且收到什麼資料就傳遞什麼資料，並且也不會備份資料，傳送資料也不會關心對方是否已經正確接收到資料了。 再者網路環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恆定的速度傳送資料。即使網路條件不好，也不會對傳送速率進行調整。這樣實現的弊端就是在網路條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。UDP只會把想發的資料包文一股腦的丟給對方，並不在意資料有無安全完整到達。

• 頭部開銷小，傳輸資料包文時是很高效的。

UDP 頭部包含了以下幾個資料：

• 兩個十六位的埠號，分別為源埠（可選欄位）和目標埠
• 整個資料包文的長度
• 整個資料包文的檢驗和（IPv4 可選 欄位），該欄位用於發現頭部資訊和資料中的錯誤

QUIC協議

QUIC（Quick UDP Internet Connection）是谷歌制定的一種基於UDP的低時延的網際網路傳輸層協議。在2016年11月國際網際網路工程任務組(IETF)召開了第一次QUIC工作組會議，受到了業界的廣泛關注。這也意味著QUIC開始了它的標準化過程，其最終目的是在web上代替TCP和TLS協議，成為新一代傳輸層協議

QUIC很好地解決了當今傳輸層和應用層面臨的各種需求，包括處理更多的連線，安全性，和低延遲。QUIC融合了包括TCP，TLS，HTTP/2等協議的特性，但基於UDP傳輸。QUIC的一個主要目標就是減少連線延遲，當客戶端第一次連線伺服器時，QUIC只需要1RTT（Round-Trip Time）的延遲就可以建立可靠安全的連線,相對於TCP+TLS的1-3次RTT要更加快捷。之後客戶端可以在本地快取加密的認證資訊，在再次與伺服器建立連線時可以實現0-RTT的連線建立延遲。QUIC同時複用了HTTP/2協議的多路複用功能（Multiplexing），但由於QUIC基於UDP所以避免了HTTP/2的線頭阻塞（Head-of-Line Blocking）問題。因為QUIC基於UDP，執行在使用者域而不是系統核心，使得QUIC協議可以快速的更新和部署，從而很好地解決了TCP協議部署及更新的困難

TCP和UDP的比較

傳送HTTP請求

HTTP

HTTP（超文字傳輸協議） 是一種用於分散式、協作式和超媒體資訊系統的應用層協議。HTTP 是網際網路資料通訊的基礎。它是由全球資訊網協會（W3C）和網際網路工程任務組（IETF）進行協調製定了 HTTP 的標準，最終釋出了一系列的 RFC，並且在1999年6月公佈的 RFC 2616，定義了 HTTP 協議中現今廣泛使用的一個版本——HTTP 1.1。

HTTP 訪問過程

HTTP 屬於 TCP/IP 模型中的應用層協議，當瀏覽器與伺服器進行互相通訊時，需要先建立TCP 連線，之後伺服器才會接收瀏覽器的請求資訊，當接收到資訊之後，伺服器返回相應的資訊。最後瀏覽器接受對伺服器的資訊應答後，對這些資料進行解釋執行（下圖http 1.0 請求模式）

HTTP 1.0 時，瀏覽器每次訪問都要單獨建立連線，這會造成資源的浪費。

後來HTTP 1.1管線化(pipelining)理論，客戶端可以同時發出多個HTTP請求，可以在一次連線中處理多個請求，並且將多個請求重疊進行

• 注意：這個pipelining僅僅是限於理論場景下，大部分桌面瀏覽器仍然會選擇預設關閉HTTP pipelining！
• 所以現在使用HTTP1.1協議的應用，都是有可能會開多個TCP連線的！
  

HTTP Pipelining其實是把多個HTTP請求放到一個TCP連線中一一傳送，而在傳送過程中不需要等待伺服器對前一個請求的響應；只不過，客戶端還是要按照傳送請求的順序來接收響應！

• 在HTTP1.0中，傳送一次請求時，需要等待服務端響應了才可以繼續傳送請求。
• 在HTTP1.1中，傳送一次請求時，不需要等待服務端響應了就可以傳送請求了，但是回送資料給客戶端的時候，客戶端還是需要按照響應的順序來一一接收
• 所以說，無論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會出現阻塞的情況。從專業的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡稱：HOLB

SPDY：HTTP1.x的優化

2012年google如一聲驚雷提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性。具體如下：

• 降低延遲 針對HTTP高延遲的問題，SPDY優雅的採取了多路複用（multiplexing）。多路複用通過多個請求stream共享一個tcp連線的方式，解決了HOL blocking的問題，降低了延遲同時提高了頻寬的利用率。
• 請求優先順序（request prioritization） 多路複用帶來一個新的問題是，在連線共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設定優先順序，這樣重要的請求就會優先得到響應。比如瀏覽器載入首頁，首頁的html內容應該優先展示，之後才是各種靜態資原始檔，指令碼檔案等載入，這樣可以保證使用者能第一時間看到網頁內容。
• header壓縮 前面提到HTTP1.x的header很多時候都是重複多餘的。選擇合適的壓縮演算法可以減小包的大小和數量。
• 基於HTTPS的加密協議傳輸 大大提高了傳輸資料的可靠性
• 服務端推送（server push） 採用了SPDY的網頁，例如我的網頁有一個sytle.css的請求，在客戶端收到sytle.css資料的同時，服務端會將sytle.js的檔案推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從快取中獲取到，不用再發請求了。SPDY構成圖：

HTTP2

HTTP/2（超文字傳輸協議第2版，最初命名為HTTP 2.0），是HTTP協議的的第二個主要版本，使用於全球資訊網。HTTP/2是HTTP協議自1999年HTTP 1.1釋出後的首個更新，主要基於SPDY協議（是Google開發的基於TCP的應用層協議，用以最小化網路延遲，提升網路速度，優化使用者的網路使用體驗）

HTTP2.0和SPDY的區別：

• HTTP2.0 支援明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
• HTTP2.0 訊息頭的壓縮演算法採用 HPACK http2.github.io/http2-spec/… SPDY 採用的 DEFLATE zh.wikipedia.org/wiki/DEFLAT…

HTTP1.0 、HTTP1.1和HTTP2.0的對比

HTTP 協議特點

• 簡單、快速、靈活：當使用者想伺服器傳送請求時，只需傳送請求方法和路徑即可，HTTP 允許傳輸任意型別的資料物件。並且HTTP協議簡單易用，HTTP 伺服器規模小，保證了網路通訊的速度；
• 無連線、無狀態：HTTP協議限制每次連線只處理單個請求，當伺服器收到使用者請求後就會斷開連線，保證了傳輸時間的節省。同時HTTP協議對事務處理沒有記憶能力，如果後續的請求需要使用前面的資訊就必須重傳資料；
• 管線化和內容編碼：隨著管線化技術的出現，HTTP 請求比永續性連線速度更快，並且當某些報文的內容過大時，為了減少傳輸的時間，HTTP 會採取壓縮檔案的方式；
• HTTP 支援客戶/伺服器模式

從 HTTP 到 HTTPS

HTTP 協議由於其簡單快速、佔用資源少，一直被用於網站伺服器和瀏覽器之間進行資料傳輸。但是在資料傳輸的過程中也存在很明顯的問題，由於 HTTP 是明文協議，不會對資料進行任何方式的加密。當黑客攻擊竊取了網站伺服器和瀏覽器之間的傳輸報文的時，可以直接讀取傳輸的資訊，造成網站、使用者資料的洩密。因此 HTTP 不適用于敏感資訊的傳播，這個時候需要引入 HTTPS（超文字傳輸安全協議）。

HTTPS

HTTPS是一種以計算機網路安全通訊為目的的傳輸協議。在HTTP下加入了SSL/TLS層，從而具有了保護交換資料隱私和完整性和提供對網站伺服器身份認證的功能，簡單來說它就是安全版的 HTTP 。

HTTPS 訪問過程

HTTPS在進行資料傳輸之前會與網站伺服器和Web瀏覽器進行一次握手，在握手時確定雙方的加密密碼資訊。具體過程如下：

• 1、Web 瀏覽器將支援的加密資訊傳送給網站伺服器
• 2、網站伺服器會選擇出一套加密演算法和雜湊演算法，將驗證身份的資訊以證書（證書釋出CA機構、證書有效期、公鑰、證書所有者、簽名等）的形式傳送給Web瀏覽器；
• 3、當 Web 瀏覽器收到證書之後首先需要驗證證書的合法性，如果證書受到瀏覽器信任則在瀏覽器位址列會有標誌顯示，否則就會顯示不受信的標識。當證書受信之後，Web 瀏覽器會隨機生成一串密碼，並使用證書中的公鑰加密。之後就是使用約定好的雜湊演算法握手訊息，並生成隨機數對訊息進行加密，再將之前生成的資訊傳送給網站；
• 4、當網站伺服器接收到瀏覽器傳送過來的資料後，會使用網站本身的私鑰將資訊解密確定密碼，然後通過密碼解密Web瀏覽器傳送過來的握手資訊，並驗證雜湊是否與Web瀏覽器一致。然後伺服器會使用密碼加密新的握手資訊，傳送給瀏覽器；
• 5、最後瀏覽器解密並計算經過雜湊演算法加密的握手訊息，如果與服務傳送過來的雜湊一致，則此握手過程結束後，伺服器與瀏覽器會使用之前瀏覽器生成的隨機密碼和對稱加密演算法進行加密交換資料。

HTTPS 加密演算法

為了保護資料的安全，HTTPS 運用了非對稱加密：加密使用的金鑰和解密使用的金鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法效能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的資料長度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE 等。

從 HTTPS 到 HSTS

但是當網站傳輸協議從 HTTP 到 HTTPS 之後，資料傳輸真的安全了嗎？

由於使用者習慣，通常準備訪問某個網站時，在瀏覽器中只會輸入一個域名，而不會在域名前面加上 http:// 或者 https://，而是由瀏覽器自動填充，當前所有瀏覽器預設填充的都是http://。一般情況網站管理員會採用了 301/302 跳轉的方式由 HTTP 跳轉到 HTTPS，但是這個過程總使用到 HTTP 因此容易發生劫持，受到第三方的攻擊。

這個時候就需要用到 HSTS（HTTP 嚴格安全傳輸）

HSTS

HSTS(HTTP Strict-Transport-Security)它是一個Web安全策略機制，由國際網際網路工程組織 IETF 正在推行一種新的 Web 安全協議，網站採用 HSTS 後，使用者訪問時無需手動在位址列中輸入 HTTPS，瀏覽器會自動採用 HTTPS 訪問網站地址，從而保證使用者始終訪問到網站的加密連結，保護資料傳輸安全。

HSTS原理

HSTS 主要是通過伺服器傳送響應頭的方式來控制瀏覽器操作：

1、首先在伺服器響應頭中新增 HSTS 響應頭： Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload] 此響應頭只有在 https 訪問返回時才生效，其中[ ]中的參數列示可選 2、設定 max-age 引數，時間設定不宜過長，建議設定時間為 6 個月；

3、當使用者下次使用 HTTP 訪問，客戶端就會進行內部跳轉，並且能夠看到 307 Redirect Internel 的響應碼；

4、網站伺服器變成了 HTTPS 訪問源伺服器。

開啟 HSTS 後網站可以有效防範中間人的攻擊，同時也會省去網站 301/302 跳轉花費的時間，大大提升安全係數和使用者體驗。

HSTS 預載入列表（HSTS Preload List）

雖然 HSTS 可以很好的解決 HTTPS 降級攻擊，但是對於 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案。具體做法是在瀏覽器內建一份可以定期更新的列表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用 HTTPS 協議

如果要想把自己的域名加進這個預載入列表，需要滿足以下條件:

• 提供有效的證書。
• 將所有 HTTP 流量重定向到 HTTPS。
• 確保所有子域名都啟用了 HTTPS，特別是 www 子域。
• 輸出 HSTS 響應頭：
  1、max-age 至少需要 1 年（31536000 秒）。
  2、必須指定 includeSubdomains 引數；
  3、必須指定 preload 引數；
  4、如果您正在從 HTTPS 站點提供額外的重定向，則該重定向必須仍具有 HSTS 標頭（而不是其重定向到的頁面）。

傳送 HTTP 請求

傳送HTTP請求的過程就是構建HTTP請求報文並通過TCP協議中傳送到伺服器指定埠 請求報文由請求行，請求頭，請求體組成

• 請求行（Request Line）分為三個部分：請求方法、請求地址和協議及版本，以CRLF(rn)結束。 HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的兩種GET和POST，如果是RESTful介面的話一般會用到GET、POST、DELETE、PUT。

• 請求頭

HTTP代理原理

普通代理

HTTP 客戶端向代理髮送請求報文，代理伺服器需要正確地處理請求和連線（例如正確處理 Connection: keep-alive），同時向伺服器傳送請求，並將收到的響應轉發給客戶端。

客戶端通過代理訪問 A 網站，對於 A 來說，它會把代理當做客戶端，完全察覺不到真正客戶端的存在，這實現了隱藏客戶端 IP 的目的。當然代理也可以修改 HTTP 請求頭部，通過 X-Forwarded-IP 這樣的自定義頭部告訴服務端真正的客戶端 IP。但伺服器無法驗證這個自定義頭部真的是由代理新增，還是客戶端修改了請求頭，所以從 HTTP 頭部欄位獲取 IP 時，需要格外小心。
對於客戶端來說，實際上訪問的是代理，代理收到請求報文後，再向真正提供服務的伺服器發起請求，並將響應轉發給瀏覽器。這種情況一般被稱之為反向代理，它可以用來隱藏伺服器 IP 及埠。一般使用反向代理後，需要通過修改 DNS 讓域名解析到代理伺服器 IP，這時瀏覽器無法察覺到真正伺服器的存在，當然也就不需要修改配置了。反向代理是 Web 系統最為常見的一種部署方式。

隧道代理

HTTP 客戶端通過 CONNECT 方法請求隧道代理建立一條到達任意目的伺服器和埠的 TCP 連線，並對客戶端和伺服器之間的後繼資料進行盲轉發。

客戶端通過代理訪問 A 網站，瀏覽器首先通過 CONNECT 請求，讓代理建立一條到 A 網站的 TCP 連線；一旦 TCP 連線建好，代理無腦轉發後續流量即可。所以這種代理，理論上適用於任意基於 TCP 的應用層協議，HTTPS 網站使用的 TLS 協議當然也可以。這也是這種代理為什麼被稱為隧道的原因。對於 HTTPS 來說，客戶端透過代理直接跟服務端進行 TLS 握手協商金鑰，所以依然是安全的

解瀏覽器快取機制

• 強快取
  使用者傳送的請求，直接從客戶端快取中獲取，不傳送請求到伺服器，不與伺服器發生互動行為。

• 協商快取
  使用者傳送的請求，傳送到伺服器後，由伺服器判定是否從快取中獲取資源。

• 兩者共同點：客戶端獲得的資料最後都是從客戶端快取中獲得。

• 兩者的區別：從名字就可以看出，強快取不與伺服器互動，而協商快取則需要與伺服器互動。