前端應該知道的http

時間  2019-11-08
標籤 前端 應該 知道 http 欄目 HTTP/TCP 简体版
原文   原文鏈接
做爲互聯網通訊協議的一員老將，HTTP 協議走到今天已經經歷了三次版本的變更，如今最新的版本是 HTTP2.0，相信你們早已耳熟能詳。今天就給你們好好介紹一下 HTTP 的前世此生。

一、http的歷史簡介

先簡單的介紹一下，後面再具體詳解css

1.一、HTTP/0.9

HTTP 的最先版本誕生在 1991 年，這個最先版本和如今比起來極其簡單，沒有 HTTP 頭，沒有狀態碼，甚至版本號也沒有，後來它的版本號才被定爲 0.9 來和其餘版本的 HTTP 區分。HTTP/0.9 只支持一種方法—— Get，請求只有一行。html

GET /hello.html

響應也是很是簡單的，只包含 html 文檔自己。前端

<HTML>
Hello world
</HTML>

當 TCP 創建鏈接以後，服務器向客戶端返回 HTML 格式的字符串。發送完畢後，就關閉 TCP 鏈接。因爲沒有狀態碼和錯誤代碼，若是服務器處理的時候發生錯誤，只會傳回一個特殊的包含問題描述信息的 HTML 文件。這就是最先的 HTTP/0.9 版本。nginx

1.二、HTTP/1.0

1996 年，HTTP/1.0 版本發佈，大大豐富了 HTTP 的傳輸內容，除了文字，還能夠發送圖片、視頻等，這爲互聯網的發展奠基了基礎。相比 HTTP/0.9，HTTP/1.0 主要有以下特性：git

  • 請求與響應支持 HTTP 頭，增長了狀態碼，響應對象的一開始是一個響應狀態行
  • 協議版本信息須要隨着請求一塊兒發送，支持 HEAD，POST 方法

支持傳輸 HTML 文件之外其餘類型的內容 一個典型的 HTTP/1.0 的請求像這樣：github

GET /hello.html HTTP/1.0
User-Agent:NCSA_Mosaic/2.0(Windows3.1)

200 OK
Date: Tue, 15 Nov 1996 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html

<HTML>
一個包含圖片的頁面
<IMGSRC="/smile.gif">
</HTML>

1.三、HTTP/1.1

在 HTTP/1.0 發佈幾個月後，HTTP/1.1 就發佈了。HTTP/1.1 更多的是做爲對 HTTP/1.0 的完善，在 HTTP1.1 中，主要具備以下改進：面試

  • 能夠複用鏈接
  • 增長 pipeline
  • chunked 編碼傳輸
  • 引入更多緩存控制機制
  • 引入內容協商機制
  • 請求消息和響應消息都支持 Host 頭域
  • 新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法

1.四、 HTTPS

HTTPS 是以安全爲目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL。算法

HTTPS 協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。 HTTPS 和 HTTP 的區別主要以下：數據庫

  • HTTPS 協議使用 ca 申請證書，因爲免費證書較少，須要必定費用。
  • HTTP 是明文傳輸，HTTPS 則是具備安全性的 SSL 加密傳輸協議。
  • HTTP 和 HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是 80，後者是 443。

1.五、SPDY

在 2010 年到 2015 年，谷歌經過實踐一個實驗性的 SPDY 協議，證實了一個在客戶端和服務器端交換數據的另類方式。其收集了瀏覽器和服務器端的開發者的焦點問題，明確了響應數量的增長和解決複雜的數據傳輸。在啓動 SPDY 這個項目時預設的目標是：segmentfault

  • 頁面加載時間 (PLT) 減小 50%。
  • 無需網站做者修改任何內容。
  • 將部署複雜性降至最低，無需變動網絡基礎設施。
  • 與開源社區合做開發這個新協議。
  • 收集真實性能數據，驗證這個實驗性協議是否有效。

爲了達到下降目標，減小頁面加載時間的目標，SPDY 引入了一個新的二進制分幀數據層，以實現多向請求和響應、優先次序、最小化及消除沒必要要的網絡延遲，目的是更有效地利用底層 TCP 鏈接。

1.六、 HTTP/2.0

時間來到 2015 年，HTTP/2.0 問世。先來介紹一下 HTTP/2.0 的特色吧：

  • 使用二進制分幀層
  • 多路複用
  • 數據流優先級
  • 服務端推送
  • 頭部壓縮

二、http原理詳解

HTTP協議是構建在TCP/IP協議之上的，是TCP/IP協議的一個子集，因此要理解HTTP協議，有必要先了解下TCP/IP協議相關的知識。

2.1 TCP/IP協議

TCP/IP協議族是由一個四層協議組成的系統，這四層分別爲：應用層、傳輸層、網絡層和數據鏈路層
圖片描述

分層的好處是把各個相對獨立的功能解耦，層與層之間經過規定好的接口來通訊。若是之後須要修改或者重寫某一個層的實現，只要接口保持不變也不會影響到其餘層的功能。接下來，咱們將會介紹各個層的主要做用。
1) 應用層
應用層通常是咱們編寫的應用程序，其決定了向用戶提供的應用服務。應用層能夠經過系統調用與傳輸層進行通訊。
處於應用層的協議很是多，好比：FTP（File Transfer Protocol，文件傳輸協議）、DNS（Domain Name System，域名系統）和咱們本章討論的HTTP（HyperText Transfer Protocol，超文本傳輸協議）等。
2) 傳輸層
傳輸層經過系統調用嚮應用層提供處於網絡鏈接中的兩臺計算機之間的數據傳輸功能。
在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）。
3) 網絡層
網絡層用來處理在網絡上流動的數據包，數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（傳輸路線）到達對方計算機，並把數據包傳輸給對方。IP協議
4) 鏈路層
鏈路層用來處理鏈接網絡的硬件部分，包括控制操做系統、硬件設備驅動、NIC（Network Interface Card，網絡適配器）以及光纖等物理可見部分。硬件上的範疇均在鏈路層的做用範圍以內。

數據包封裝
上層協議數據是如何轉變爲下層協議數據的呢？這是經過封裝（encapsulate）來實現的。應用程序數據在發送到物理網絡以前，會沿着協議棧從上往下傳遞。每層協議都將在上層協議數據的基礎上加上本身的頭部信息（鏈路層還會加上尾部信息），覺得實現該層功能提供必要的信息.
圖片描述
發送端發送數據時，數據會從上層傳輸到下層，且每通過一層都會被打上該層的頭部信息。而接收端接收數據時，數據會從下層傳輸到上層，傳輸前會把下層的頭部信息刪除.

因爲下層協議的頭部信息對上層協議是沒有實際的用途，因此在下層協議傳輸數據給上層協議的時候會把該層的頭部信息去掉，這個封裝過程對於上層協議來講是徹底透明的。這樣作的好處是，應用層只須要關心應用服務的實現，而不用管底層的實現。

TCP三次握手
從上面的介紹可知，傳輸層協議主要有兩個：TCP協議和UDP協議。TCP協議相對於UDP協議的特色是：TCP協議提供面向鏈接、字節流和可靠的傳輸。

圖片描述

  • 第一次握手：客戶端發送帶有SYN標誌的鏈接請求報文段，而後進入SYN_SEND狀態，等待服務端的確認。
  • 第二次握手：服務端接收到客戶端的SYN報文段後，須要發送ACK信息對這個SYN報文段進行確認。同時，還要發送本身的SYN請求信息。服務端會將上述的信息放到一個報文段（SYN+ACK報文段）中，一併發送給客戶端，此時服務端將會進入SYN_RECV狀態。
  • 第三次握手：客戶端接收到服務端的SYN+ACK報文段後，會想服務端發送ACK確認報文段，這個報文段發送完畢後，客戶端和服務端都進入ESTABLISHED狀態，完成TCP三次握手。

當三次握手完成後，TCP協議會爲鏈接雙方維持鏈接狀態。爲了保證數據傳輸成功，接收端在接收到數據包後必須發送ACK報文做爲確認。若是在指定的時間內（這個時間稱爲從新發送超時時間），發送端沒有接收到接收端的ACK報文，那麼就會重發超時的數據。

2.二、 DNS 域名解析

當你在瀏覽器的地址欄輸入 https://juejin.im 後會發生什麼，你們在心中確定是有一個大概的，這裏我將 DNS 域名解析 這個步驟詳細的講一遍。在講概念以前我先放上一張經典的圖文供你們思考一分鐘。
圖片描述
查找域名對應的 IP 地址的具體過程

  1. 瀏覽器搜索本身的 DNS 緩存（瀏覽器維護一張域名與 IP 地址的對應表）；若是沒有命中，進入下一步；
  2. 搜索操做系統中的 DNS 緩存；若是沒有命中，進入下一步；
  3. 搜索操做系統的 hosts 文件（ Windows 環境下，維護一張域名與 IP 地址的對應表）；若是沒有命中，進入下一步；

  4. 列表項目

    • 操做系統將域名發送至 LDNS （本地區域名服務器），LDNS 查詢本身的 DNS 緩存（通常命中率在 80% 左右），查找成功則返回結果，失敗則發起一個迭代 DNS 解析請求：
    • LDNS向 Root Name Server（根域名服務器，如com、net、im 等的頂級域名服務器的地址）發起請求，此處，Root Name Server 返回 im 域的頂級域名服務器的地址；
    • LDNS 向 im 域的頂級域名服務器發起請求，返回 juejin.im 域名服務器地址；
    • LDNS 向 juejin.im 域名服務器發起請求，獲得 juejin.im 的 IP 地址；
    • LDNS 將獲得的 IP 地址返回給操做系統，同時本身也將 IP 地址緩存起來；操做系統將 IP 地址返回給瀏覽器，同時本身也將 IP 地址緩存起來。

http工做的簡單過程

  • 地址解析： 這一步比較重要的是上面的DNS解析
  • 封裝HTTP請求數據包： 把以上部分結合本機本身的信息，封裝成一個HTTP請求數據包
  • 封裝成TCP包，創建TCP鏈接（TCP的三次握手）
  • 客戶機發送請求命令
  • 服務器響應
  • 服務器關閉TCP鏈接

2.三、http請求方法

一些常見的http請求方法。

  • GET： 用於獲取數據
  • POST： 用於將實體提交到指定的資源，一般致使狀態或服務器上的反作用的更改
  • HEAD： 與GET請求的響應相同的響應，但沒有響應體
  • PUT： 用於建立或更新指定資源
  • DELETE： 刪除指定的資源

關於get與post的一些區別。能夠看個人另外一篇文章面試經典之http中get與post的區別

2.四、 http緩存

http很重要的一點還有他的緩存機制。關於這部分的內容能夠看一下我以前的文章瀏覽器緩存看這一篇就夠了。這裏就不在贅述了。

2.五、狀態碼

這裏主要講一些經常使用的狀態碼

一、 301 永久轉移
當你想換域名的時候，就可使用301，如以前的域名叫www.renfed.com，後來換了一個新域名fed.renren.com，但願用戶訪問老域名的時候可以自動跳轉到新的域名，那麼就可使用nginx返回301：

server {
    listen       80;
    server_name  www.renfed.com;
    root         /home/fed/wordpress;
    return       301 https://fed.renren.com$request_uri;
}

瀏覽器收到301以後，就會自動跳轉了。搜索引擎在爬的時候若是發現是301，在若干天以後它會把以前收錄的網頁的域名給換了。

還有一個場景，若是但願訪問http的時候自動跳轉到https也是能夠用301，由於若是直接在瀏覽器地址欄輸入域名而後按回車，前面沒有帶https，那麼是默認的http協議，這個時候咱們但願用戶可以訪問安全的https的，不要訪問http的，因此要作一個重定向，也可使用301，如：

server {
    listen       80; 
    server_name  fed.renren.com;

    if ($scheme != "https") {
         return 301 https://$host$request_uri;
    }   
}

二、302 Found 資源暫時轉移
不少短連接跳轉長連接就是使用的302，以下圖所示：
圖片描述
三、304 Not Modified 沒有修改
這個主要在上面的緩存哪裏出現的比較多。若是服務器沒有修改。就會使用瀏覽器的緩存。

圖片描述
四、400 Bad Request 請求無效
當必要參數缺失、參數格式不對時，後端一般會返回400，以下圖所示：
圖片描述

五、403 Forbidden 拒絕服務
服務可以理解你的請求，包括傳參正確，可是拒絕提供服務。例如，服務容許直接訪問靜態文件，可是不容許訪問某個目錄：
圖片描述
不然，別人對你服務器上的文件就一覽無遺了。
403和401的區別在於，401是沒有認證，沒有登錄驗證之類的錯誤。

六、500 內部服務器錯誤
如業務代碼出現了異常沒有捕獲，被tomcat捕獲了，就會返回500錯誤：
圖片描述
如：數據庫字段長度限制爲30個字符，若是沒有判斷直接插入一條31個字符的記錄，就會致使數據庫拋異常，若是異常沒有捕獲處理，就直接返回500。

當服務完全掛了，連返回都沒有的時候，那麼就是502了。

七、502 Bad Gateway 網關錯誤
圖片描述
這種狀況是由於nginx收到請求，可是請求沒有打過去，多是由於業務服務掛了，或者是打過去的端口號寫錯了

八、504 Gateway Timeout 網關超時
一般是由於服務處理請求過久，致使超時，如PHP服務默認的請求響應最長處理時間爲30s，若是超過30s，將會掛掉，返回504，以下圖所示：
圖片描述

2.六、HTTP的基本優化

影響一個HTTP網絡請求的因素主要有兩個：帶寬和延遲。

  • 帶寬
    若是說咱們還停留在撥號上網的階段，帶寬可能會成爲一個比較嚴重影響請求的問題，可是如今網絡基礎建設已經使得帶寬獲得極大的提高，咱們再也不會擔憂由帶寬而影響網速，那麼就只剩下延遲了。
  • 延遲
    一、瀏覽器阻塞（HOL blocking）：瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。
    二、DNS 查詢（DNS Lookup）：瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。
    三、創建鏈接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大

http的發展也就是在不斷地優化這些方向上的問題。

三、http1.1

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

  • 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
  • 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。
  • 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
  • Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。
  • 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

雖然 HTTP/1.1 已經優化了不少點，做爲一個目前使用最普遍的協議版本，已經可以知足不少網絡需求，可是隨着網頁變得愈來愈複雜，甚至演變成爲獨立的應用，HTTP/1.1 逐漸暴露出了一些問題：

  • 在傳輸數據時，每次都要從新創建鏈接，對移動端特別不友好
  • 傳輸內容是明文，不夠安全
  • header 內容過大，每次請求 header 變化不大，形成浪費
  • keep-alive 給服務端帶來性能壓力 爲了解決這些問題，HTTPS 和 SPDY 應運而生。

四、HTTPS

HTTPS 是以安全爲目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL。
圖片描述

  • HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
  • HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。
  • HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
  • HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

五、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構成圖：

圖片描述
SPDY位於HTTP之下，TCP和SSL之上，這樣能夠輕鬆兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可使用已有的SSL功能。

六、HTTP2.0

HTTP2.0能夠說是SPDY的升級版（其實本來也是基於SPDY設計的），可是，HTTP2.0 跟 SPDY 仍有不一樣的地方，以下：
HTTP2.0和SPDY的區別：

  • HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
  • HTTP2.0 消息頭的壓縮算法採用 HPACK，而非 SPDY 採用的 DEFLATE

HTTP/2 新特性

6.一、二進制傳輸

HTTP/2 採用二進制格式傳輸數據，而非 HTTP 1.x 的文本格式，二進制協議解析起來更高效。 HTTP / 1 的請求和響應報文，都是由起始行，首部和實體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請求和響應數據分割爲更小的幀，而且它們採用二進制編碼。

接下來咱們介紹幾個重要的概念：

  • 流：流是鏈接中的一個虛擬信道，能夠承載雙向的消息；每一個流都有一個惟一的整數標識符（一、2…N）；
  • 消息：是指邏輯上的 HTTP 消息，好比請求、響應等，由一或多個幀組成。
  • 幀：HTTP 2.0 通訊的最小單位，每一個幀包含幀首部，至少也會標識出當前幀所屬的流，承載着特定類型的數據，如 HTTP 首部、負荷，等等

圖片描述

HTTP/2 中，同域名下全部通訊都在單個鏈接上完成，該鏈接能夠承載任意數量的雙向數據流。每一個數據流都以消息的形式發送，而消息又由一個或多個幀組成。多個幀之間能夠亂序發送，根據幀首部的流標識能夠從新組裝。

6.二、多路複用

在 HTTP/2 中引入了多路複用的技術。多路複用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，同時也接更容易實現全速傳輸，畢竟新開一個 TCP 鏈接都須要慢慢提高傳輸速度。

在 HTTP/2 中，有了二進制分幀以後，HTTP /2 再也不依賴 TCP 連接去實現多流並行了，在 HTTP/2中：

  • 同域名下全部通訊都在單個鏈接上完成。
  • 單個鏈接能夠承載任意數量的雙向數據流。
  • 數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間能夠亂序發送，由於根據幀首部的流標識能夠從新組裝。

這一特性，使性能有了極大提高：

  • 同個域名只須要佔用一個 TCP 鏈接，使用一個鏈接並行發送多個請求和響應,消除了因多個 TCP 鏈接而帶來的延時和內存消耗。
  • 並行交錯地發送多個請求，請求之間互不影響。
  • 並行交錯地發送多個響應，響應之間互不干擾。
  • 在HTTP/2中，每一個請求均可以帶一個31bit的優先值，0表示最高優先級， 數值越大優先級越低。有了這個優先值，客戶端和服務器就能夠在處理不一樣的流時採起不一樣的策略，以最優的方式發送流、消息和幀。

圖片描述
如上圖所示，多路複用的技術能夠只經過一個 TCP 鏈接就能夠傳輸全部的請求數據。

6.三、Header 壓縮

在 HTTP/1 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。

爲了減小這塊的資源消耗並提高性能， HTTP/2對這些首部採起了壓縮策略：

  • HTTP/2在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵－值對，對於相同的數據，再也不經過每次請求和響應發送；
  • 首部表在HTTP/2的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新;
  • 每一個新的首部鍵－值對要麼被追加到當前表的末尾，要麼替換表中以前的值

例以下圖中的兩個請求， 請求一發送了全部的頭部字段，第二個請求則只須要發送差別數據，這樣能夠減小冗餘數據，下降開銷
圖片描述

6.四、服務端推送（Server Push）

Server Push即服務端能經過push的方式將客戶端須要的內容預先推送過去，也叫「cache push」。

能夠想象如下狀況，某些資源客戶端是必定會請求的，這時就能夠採起服務端 push 的技術，提早給客戶端推送必要的資源，這樣就能夠相對減小一點延遲時間。固然在瀏覽器兼容的狀況下你也可使用 prefetch。

例如服務端能夠主動把JS和CSS文件推送給客戶端，而不須要客戶端解析HTML時再發送這些請求。
圖片描述

服務端能夠主動推送，客戶端也有權利選擇是否接收。若是服務端推送的資源已經被瀏覽器緩存過，瀏覽器能夠經過發送RST_STREAM幀來拒收。主動推送也遵照同源策略，換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是通過雙方確認才行。

後續更多文章將在個人 github第一時間發佈，歡迎關注。

參考

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程