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

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

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

URL地址構成

DNS域名解析

什麼是域名解析

域名系統（英文：DomainNameSystem，縮寫：DNS）是互聯網的一項服務。它做爲將域名和IP地址相互映射的一個分佈式數據庫，可以令人更方便地訪問互聯網

域名解析過程

• 系統會檢查瀏覽器緩存中有沒有這個域名對應的解析過的 IP 地址，若是緩存中有，這個解析過程就將結束。瀏覽器緩存是受這個域名的失效時間和緩存的空間大小控制的。
• 若是用戶的瀏覽器緩存中沒有，瀏覽器會查找操做系統緩存中即爲本地的 Host 文件
• 路由器也可能會有緩存。
• 操做系統將域名發送至本地域名服務器， 本地域名服務器查詢本身的 DNS 緩存，查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求
  一、本地域名服務器 向 根域名服務器，其雖然沒有每一個域名的的具體信息，但存儲了負責每一個域，如 com、net、org等的解析的頂級域名服務器的地址）發起請求，此處，根域名服務器 返回 com 域的頂級域名服務器的地址；
  二、本地域名服務器 向 com 域的頂級域名服務器發起請求，返回 baidu.com 域名服務器地址；
  三、本地域名服務器向 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鏈接過程（三次握手)

• 一、第一次握手：客戶端發送syn包(Seq=x)到服務器，並進入SYN_SEND狀態，等待服務器確認；
• 二、第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時本身也發送一個SYN包（Seq=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
• 三、第三次握手：客戶端收到服務器的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瀏覽器進行一次握手，在握手時肯定雙方的加密密碼信息。具體過程以下：

• 一、Web 瀏覽器將支持的加密信息發送給網站服務器
• 二、網站服務器會選擇出一套加密算法和哈希算法，將驗證身份的信息以證書（證書發佈CA機構、證書有效期、公鑰、證書全部者、簽名等）的形式發送給Web瀏覽器；
• 三、當 Web 瀏覽器收到證書以後首先須要驗證證書的合法性，若是證書受到瀏覽器信任則在瀏覽器地址欄會有標誌顯示，不然就會顯示不受信的標識。當證書受信以後，Web 瀏覽器會隨機生成一串密碼，並使用證書中的公鑰加密。以後就是使用約定好的哈希算法握手消息，並生成隨機數對消息進行加密，再將以前生成的信息發送給網站；
• 四、當網站服務器接收到瀏覽器發送過來的數據後，會使用網站自己的私鑰將信息解密肯定密碼，而後經過密碼解密Web瀏覽器發送過來的握手信息，並驗證哈希是否與Web瀏覽器一致。而後服務器會使用密碼加密新的握手信息，發送給瀏覽器；
• 五、最後瀏覽器解密並計算通過哈希算法加密的握手消息，若是與服務發送過來的哈希一致，則此握手過程結束後，服務器與瀏覽器會使用以前瀏覽器生成的隨機密碼和對稱加密算法進行加密交換數據。

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 主要是經過服務器發送響應頭的方式來控制瀏覽器操做：

一、首先在服務器響應頭中添加 HSTS 響應頭： Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload] 此響應頭只有在 https 訪問返回時才生效，其中[ ]中的參數表示可選 二、設置 max-age 參數，時間設置不宜過長，建議設置時間爲 6 個月；

三、當用戶下次使用 HTTP 訪問，客戶端就會進行內部跳轉，而且可以看到 307 Redirect Internel 的響應碼；

四、網站服務器變成了 HTTPS 訪問源服務器。

開啓 HSTS 後網站能夠有效防範中間人的攻擊，同時也會省去網站 301/302 跳轉花費的時間，大大提高安全係數和用戶體驗。

HSTS 預載入列表（HSTS Preload List）

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

若是要想把本身的域名加進這個預載入列表，須要知足如下條件:

• 提供有效的證書。
• 將全部 HTTP 流量重定向到 HTTPS。
• 確保全部子域名都啓用了 HTTPS，特別是 www 子域。
• 輸出 HSTS 響應頭：
  一、max-age 至少須要 1 年（31536000 秒）。
  二、必須指定 includeSubdomains 參數；
  三、必須指定 preload 參數；
  四、若是您正在從 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 握手協商密鑰，因此依然是安全的

解瀏覽器緩存機制

• 強緩存
  用戶發送的請求，直接從客戶端緩存中獲取，不發送請求到服務器，不與服務器發生交互行爲。

• 協商緩存
  用戶發送的請求，發送到服務器後，由服務器斷定是否從緩存中獲取資源。

• 二者共同點：客戶端得到的數據最後都是從客戶端緩存中得到。

• 二者的區別：從名字就能夠看出，強緩存不與服務器交互，而協商緩存則須要與服務器交互。