在B站看貓片被老板發現？不如按下F12學學HTTP

什么是HTTP

HTTP 全稱超?文本傳輸協議，也就是HyperText Transfer Protocol。其中我們常見的文本，圖片，視頻這些東西都可以用超文本進行表示，而我常看的貓片，也屬于超文本，所以大家不要再說我偷偷看貓片了，我只是在看超文本。HTTP只是定義了一套傳輸超文本的規則，只要符合了這一套規則，不管你是用iphone，還是用老爺機，都可以實現貓片的傳輸。

七層網絡

大概了解了HTTP后，給大家看看它在它們家族里的地位。HTTP位于應用層，跟它類似的協議還有常見的FTP協議，常見的某影天堂的下載鏈接曾經經常是以FTP開頭的。

HTTP報文格式

有點抽象？不知道說的啥？那實操一下，用wireshark抓包看一下貓片里的請求報文和響應報文具體長什么樣子吧
請求報文

GET /cmaskboss/164203142_30_1.enhance.webmask HTTP/1.1Host: upos-sz-staticks3.bilivideo.comConnection: keep-aliveUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36Accept: */*Origin: https://www.bilibili.comSec-Fetch-Site: cross-siteSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: https://www.bilibili.com/Accept-Encoding: identityAccept-Language: zh-CN,zh;q=0.9Range: bytes=0-16復制代碼這上面第一行的GET 就是請求方法，/cmaskboss/164203142_30_1.enhance.webmask 則是 URL , 而HTTP/1.1則是協議版本。接下來從Host開始到最后一行Range，都是Headers頭。
響應報文

HTTP/1.1 206 Partial ContentContent-Type: application/octet-streamContent-Length: 17Connection: keep-aliveServer: TengineETag: "92086de1e6d1d4791fb950a0ac7e30ba"Date: Sat, 30 Jan 2021 09:31:31 GMTLast-Modified: Sun, 04 Oct 2020 01:54:28 GMTExpires: Mon, 01 Mar 2021 09:31:31 GMTAge: 1018695Content-Range: bytes 0-16/353225Accept-Ranges: bytesX-Application-Context: applicationx-kss-request-id: 75bcbfa8ab194e3c825e89c81a912692x-kss-BucketOwner: MjAwMDAyMDEwNw==X-Info-StorageClass: -Content-MD5: kght4ebR1HkfuVCgrH4wug==X-Cache-Status: HIT from KS-CLOUD-JH-MP-01-03X-Cache-Status: HIT from KS-CLOUD-TJ-UN-14-13X-Cache-Status: HIT from KS-CLOUD-LF-UN-11-25Access-Control-Allow-Origin: https://www.bilibili.comAccess-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept,rangeX-Cdn-Request-ID: 7e2c783ca7d392624118593ec1dc66bc復制代碼類似請求報文，HTTP/1.1是協議版本，206是狀態碼，Partial Content 則是狀態描述符。接下來從Content-Type開始到最后一行X-Cdn-Request-ID都是Headers信息。
報文信息解讀

其實上面的抓包信息，在瀏覽器里按F12就能看到，之所以要用wireshark可能只是裝X效果比較好吧。按下F12看到的響應數據就跟下圖展示的那樣。

1.請求數據

2.響應數據

3.Request URL

URL是什么

URL 代表著是統一資源定位符（Uniform Resource Locator）。作用是為了告訴使用者某個資源在 Web 上的地址。這個資源可以是一個 HTML 頁面，一個 CSS 文檔，一幅圖像或一個貓片等等。上面我們請求貓片的URL就是 https://upos-sz-staticks3.bilivideo.com/cmaskboss/164203142_30_1.enhance.webmask 這里面細分，又可以分為好幾個部分。

協議部分

表示該URL的協議部分為http還是https，會用//為分隔符。上面的URL表示網頁用的是HTTPS協議，而上面提到的X影天堂用的則是ftp協議的下載鏈接。

域名部分

域名是upos-sz-staticks3.bilivideo.com，在發送請求前，會向DNS服務器解析IP，如果已經知道ip，還可以跳過DNS解析那一步，直接把IP當做域名部分使用。

端口部分

域名后面有些時候會帶有端口，和域名之間用:分隔，端口不是一個URL的必須的部分。當網址為http://時，默認端口為80
當網址為https://時，默認端口為443，以上兩種都可以省略端口號。上面的URL其實省略了443端口號。

從域名的第一個/開始到最后一個/為止，是虛擬目錄的部分。虛擬目錄也不是URL必須的部分，本例中的虛擬目錄是/cmaskboss/

文件名部分

從域名最后一個/開始到?為止，是文件名部分；如果沒有?，則是從域名最后一個/開始到#為止，是文件名部分；如果沒有?和#，那么就從域名的最后一個/從開始到結束，都是文件名部分。本例中的文件名是164203142_30_1.enhance.webmask，文件名也不是一個URL的必須部分。
URL 和 URI 的區別

URL:Uniform Resource Locator 統一資源定位符；
URI: Uniform Resource Identifier 統一資源標識符；

其實一直有個誤解，很多人以為URI是URL的子集，其實應該反過來。URL是URI的子集才對。簡單解釋下。假設"賣客"(URI)是一種資源，而"在迪麗亦巴的懷里"表明了一個位置。如果你想要找到（locate）賣客，那么你可以到"在迪麗亦巴懷里"找到賣客，而"在迪麗亦巴懷里的/賣客"才是我們常說的URL。而"在迪麗亦巴懷里的/賣客"（URL）顯然是"賣客"（URI）的子集，畢竟，"賣客"還可能是"在牛亦菲懷里的/賣客"（其他URL）。

4.Request Method

HTTP 定義了一組請求方法，以表明要對給定資源執行的操作。指示針對給定資源要執行的期望動作.。雖然他們也可以是名詞，但這些請求方法有時被稱為HTTP動詞.。每一個請求方法都實現了不同的語義。
這次請求B站貓片的請求里用的是GET，意味著獲取。但其實HTTP定義了多種請求方法，來滿足各種需求。除了Get，還有幾個POST、HEAD、OPTIONS、PUT、DELETE、TRACE 和 CONNECT。

常見的各個請求方法的具體功能如下：
GET

請求指定的頁面信息，并返回消息主體(body)+頭信息(header)。
HEAD：

HEAD和GET本質是一樣的，區別在于HEAD只返回頭信息(header)，不返回消息主體(body)。大家不要以為它沒用，它跟GET和POST一樣，在http/1.0的時候就存在了，實屬三元老之一了。主要用途

如果想要判斷某個資源是否存在，雖然用GET也能做到，但這里用HEAD還省下拿body的消耗，返回狀態碼200就是有404就是無
如果請求的是一個比較大的資源，比如一個超大視頻和文件，你只想知道它到底有多大，而不需要整個下載下來，這時候使用HEAD請求，返回的headers會帶有文件的大小（content-lenght）。

POST

向服務器提交數據。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。POST跟GET最常用，但最大的區別在于，POST每次調用都可能會修改數據，是非冪等的，而GET類似于只讀，是冪等的。
PUT：

這個方法比較少見。在HTTP規范中POST是非等冪的，多次調用會產生不同的結果。比如：創建一個用戶,由于網絡原因或是其他原因多創建了幾次,那么將會有多個用戶被創建。而PUT id/xiaobai 則會創建一個id為 xiaobai 的用戶，多次調用還是會創建的結果是一樣的，所以PUT是等冪的。但是一般為了避免造成心智負擔，實戰中也會使用POST替代PUT。
DELETE：

刪除某一個資源。基本上這個也很少見，一般實戰中如果是刪除操作，也是使用POST來替代。
OPTIONS：

options是什么

它用于獲取當前URL所支持的方法。若請求成功，則它會在HTTP響應頭部中帶上給各種“Allow”的頭，表明某個請求在對應的服務器中都支持哪種請求方法。比如下圖：

這里面需要關注的點有兩個

Request Header里的關鍵字段
Response Header里的關鍵字段

Options堪稱是網絡協議中的老實人，就好像老實人剛談了個女朋友，每次牽手前都要問下人家 “我可以牽你的手嗎？”， “我可以抱你嗎？”，得到了答應后才會下手。差點被這老實人氣質感動得留下了不爭氣的淚水。

什么時候需要使用options

在跨域（記住這個詞，待會解釋）的情況下，瀏覽器發起復雜請求前會自動發起 options 請求。跨域共享標準規范要求，對那些可能對服務器數據產生副作用的 HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 options 方法發起一個預檢請求，從而獲知服務端是否允許該跨域請求。服務器確認允許之后，才發起實際的 HTTP 請求。
這里提到了兩個關鍵詞：

跨域
復雜請求

什么是簡單請求和復雜請求。

某些請求不會觸發 CORS 預檢請求，這樣的請求一般稱為"簡單請求"，而會觸發預檢的請求則為"復雜請求"。

簡單請求
- 請求方法為GET、HEAD、POST
- 只有以下Headers字段AcceptAccept-LanguageContent-LanguageContent-TypeDPR/Downlink/Save-Data/Viewport-Width/Width (這些不常見，放在一起)
- Content-Type 只有以下三種application/x-www-form-urlencodedmultipart/form-datatext/plain
- 請求中的任意 XMLHttpRequestUpload 對象均沒有注冊任何事件監聽器；
- 請求中沒有使用 ReadableStream 對象。
復雜請求
- 不滿足簡單請求的，都是復雜請求

由此可見，因為上述請求在獲取B站資源的請求Headers里帶有 Access-Control-Request-Headers: range , 而range正好不在簡單請求的條件2中提到的Headers范圍里，因此屬于復雜請求，于是觸發預檢options請求。
什么是跨域

剛剛提到了一個詞叫跨域，那什么是跨域呢？在了解跨域之前，首先要了解一個概念：同源。所謂同源是指，域名、協議、端口均相同。

不明白沒關系，舉個例子。

需要特別注意的是，localhost和127.0.0.1雖然都指向本機，但也不屬于同源。
而非同源之間網頁調用就是我們所說的跨域。在瀏覽器同源策略限制下，向不同源發送XHR請求，瀏覽器認為該請求不受信任，禁止請求，具體表現為請求后不正常響應。
options帶來什么問題

由此可見，復雜請求的條件其實非常容易滿足，而一旦滿足復雜請求的條件，則瀏覽器便會發送2次請求（一次預檢options，一次復雜請求），這一次options就一來一回（一個RTT），顯然會導致延遲和不必要的網絡資源浪費，高并發情況下則可能為服務器帶來嚴重的性能消耗。

如何優化options

每次復雜請求前都會調用一次options，這其實非常沒有必要。因為大部分時候相同的請求，短時間內獲得的結果是不會變的，是否可以通過瀏覽器緩存省掉這一次查詢？
Access-Control-Max-Age就是優化這個流程中使用的一個Header。它的作用是當你每次請求options方法時，服務端返回調用支持的方法（Access-Control-Allow-Methods ）和Headers（Access-Control-Allow-Headers）有哪些，同時告訴你，它在接下來 Access-Control-Max-Age時間（單位是秒）里都支持，則這段時間內，不再需要使用options進行請求。特別注意的是，當Access-Control-Max-Age的值為-1時，表示禁用緩存，每一次請求都需要發送預檢請求，即用OPTIONS請求進行檢測。

5.Status Code

狀態碼是什么

HTTP Status Code是常說的HTTP狀態碼。當用戶訪問一個網頁時，瀏覽器會向網頁所在服務器發出請求。服務器則會根據請求作出響應，而狀態碼則是響應的一部分，代表著本次請求的結果。所有狀態碼的第一個數字代表了響應的大概含義，組合上第二第三個數字則可以表示更具體的原因。如果請求失敗了，通過這個狀態碼，大概初步判斷出這次請求失敗的原因。以下是五類狀態碼的含義。

狀態碼流程

可以根據以下流程圖了解下各類狀態碼間的關系。

2xx和3xx之間的流程關系

4xx的狀態流程

5xx的狀態流程

常見狀態碼介紹

200 OK

這是最常見的狀態碼。代表請求已成功，數據也正常返回。而B站貓片里雖然響應成功了，但卻不是200，而是206，是為什么呢，接下去繼續看看。

206 Partial Content

這個狀態碼在上面B站請求的響應結果。服務器已經成功處理了部分 GET 請求。類似于B站看視頻或者迅雷這類的 HTTP下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同時下載。

307 Temporary Redirect
內部重定向。重定向的意思是，當你輸入一個網址的時候，瀏覽器會自動幫你跳轉到另外一個網址上。比如，當你在瀏覽器輸入框輸入http://www.baidu.com/時。由于使用http并不安全，百度會自動幫你跳轉到它對應的https網頁上。而此時，需要重定向的地址，會通過Response Headers的Location返回
404 Not Found
請求失敗，請求所希望得到的資源未被在服務器上發現。出現這個錯誤的最有可能的原因是服務器端沒有這個頁面，或者是Request Method與注冊URL的Method不一致，比如我有一個URL在服務端注冊的Request Method 為 POST，但調用的時候卻錯誤用了GET，則也會出現404錯誤。
499 Client has closed connection
網絡請求過程中，由于服務端處理時間過長，客戶端超時。一般常見于，后端服務器處理時間過長，而客戶端也設置了一個超時等待時間，客戶端等得“不耐煩”了，主動關掉連接時報出。
502 Bad Gateway
服務器方面無法給予正常的響應。一般常見于服務器崩潰后，nginx 無法正常收到服務端的響應，給客戶端返回502狀態碼。
504 Gateway Timeout
網絡請求過程中，由于服務端處理時間過長，網關超時。一般常見于，后端服務器邏輯處理時間過長，甚至長于 nginx設置的最長等待時間時報錯。它跟 499 狀態碼非常像，區別在于499 表示的是客戶端超時，504是網關超時。如果是499超時，可以考慮修改客戶端的代碼調整超時時間，如果是504，則考慮調整nginx的超時配置。

6. Headers

Content-Length

Content-Length是HTTP的消息長度, 用十進制數字表示。Content-Length首部指出報文中消息的當前實際字節大小。如果消息文本進行了gzip壓縮的話， Content-Length指的就是壓縮后的大小而不是原始大小。
正常情況下Content-Length是不需要手動去設置的，大部分語言的網絡庫都會自動封裝好，但是如果在一些特殊情況下，出現Content-Length與實際要發送的消息大小不一致，就會出現一些問題。

如果Content-Length < 實際長度
下面啟動一個HTTP服務器，所有語言都一樣，示例里使用了golang。
package main import ( "fmt""io/ioutil""log""net/http" ) // w表示response對象，返回給客戶端的內容都在對象里處理// r表示客戶端請求對象，包含了請求頭，請求參數等等funcindex(w http.ResponseWriter, r *http.Request) { b, _ := ioutil.ReadAll(r.Body) fmt.Printf("request body=%#v, content_length=%v \nheaders=%v",string(b), r.ContentLength, r.Header) // 往w里寫入內容，就會在瀏覽器里輸出 fmt.Fprintf(w, string(b)) } funcmain() { // 設置路由，如果訪問/，則調用index方法 http.HandleFunc("/", index) // 啟動web服務，監聽9090端口 err := http.ListenAndServe(":9999", nil) if err != nil { log.Fatal("ListenAndServe: ", err) } } 復制代碼
在控制臺輸入
$ $ curl -L -X POST 'http://127.0.0.1:9999' -H 'Content-Type: application/json' -H 'Content-Length: 5' -d '1234567' | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 12 100 5 100 7 828 1160 --:--:-- --:--:-- --:--:-- 1400 12345 復制代碼
輸入的body是 1234567，共7個數字，但是輸入的 Content-Length為 5。到了服務器那，收到了 12345，共5個數字，數量上跟輸入的Content-Length一致。由此可見當Content-Length < 實際長度，消息會被截斷。
如果Content-Length > 實際長度
還是上面的服務端代碼，但是控制臺輸入以下命令
$ curl -L -X POST 'http://127.0.0.1:9999' -H 'Content-Type: application/json' -H 'Content-Length: 100' -d '1234567' | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 7 0 0 0 7 0 0 --:--:-- 0:01:19 --:--:-- 0 復制代碼
這次情況不太一樣，會發現請求一直阻塞沒有返回。這是因為輸入的body是 1234567，共7個數字，但是輸入的 Content-Length為 100。也就是服務端一直認為這次的body長度為100，但是目前只收到了部分消息（長度為7），剩余的長度為93的消息由于各種原因還在路上，因此選擇傻傻等待剩下的消息，就造成了上面提到的阻塞。

Range

視頻播放需要支持用戶調整播放進度，支持讓用戶選擇直接跳到中間部分開始播放。為了實現這個功能，需要通過HTTP Range Requests 協議用于指定需要獲取視頻片段。而 Request Header里的range頭則是用于指定要請求文件的起始和結束位置。

如果服務器不支持，直接忽略 Range 頭，瀏覽器會正常按流式加載整個視頻文件，以狀態碼 200 響應即可。另外，當我們在 html 中放一個 video 標簽，瀏覽器會直接發起一個 Range: bytes=0- 的請求，向服務器請求從開始到結尾的完整文件。
如果服務器支持 Range Requests，會讀取視頻文件，并將他的第 162653～242638 字節提取出來，響應碼為 206，則瀏覽器會在接收到足夠字節（比如當前播放進度往后推20s）時結束掉請求，以節省網絡流量；當播放進度繼續往前，緩存不夠時，瀏覽器會發起一個新的 Range Requests 請求，請求的 Range 直接從緩存結尾的字節開始，只加載剩余的部分文件。同時返回的Response Headers中有一個 content-range 的字段域，用于告訴了客戶端發送了多少數據。content-range 描述了響應覆蓋的范圍和整個實體長度。一般格式：Content-Range：開始字節位置-結束字節位置／文件大小（byte）。

Connection

長連接和短連接

Connection: close
表示請求響應完成之后立即關閉連接，這是HTTP/1.0請求的默認值。每次請求都經過“創建tcp連接 -> 請求資源 -> 響應資源 -> 釋放連接”這樣的過程
Connection: keep-alive
表示連接不立即關閉，可以繼續響應下一個請求。HTTP/1.1的請求默認使用一個持久連接。可以做到只建立一次連接，多次資源請求都復用該連接，完成后關閉。流程上是建立tcp連接 -> 請求資源 -> 響應資源 -> ... （保持連接）... -> 第n次請求資源 -> 第n次響應資源 -> 釋放連接。

在http1.1中Request Header和Reponse Header中都有可能出現一個Connection: keep-alive 頭信息。Request Header里的Connection: keep-alive 頭是為了告訴服務端，客戶端想要以長連接形式進行通信。而Response Header里的Connection: keep-alive 頭是服務端告訴客戶端，我的服務器支持以長連接的方式進行通信。如果不能使用長連接，會返回 Connection: close ，相當于告訴客戶端“我不支持長連接，你死了這條心，老老實實用短連接吧” 。
HTTP為什么要使用長連接

我們知道 HTTP 建立在 TCP 傳輸層協議之上，而 TCP 的建立需要三次握手，關閉需要四次揮手，這些步驟都需要時間，帶給 HTTP 的就是請求響應時延。如果使用短連接，那么每次數據傳輸都需要經歷一次上面提到的幾個步驟，如果能只連接一次，保持住這個連接不斷開，期間通信就可以省下建立連接和斷開連接的過程，對于提升HTTP性能有很大的幫助。

可以看到，在使用 Connection: close 通信時，每次都需要重新經歷一次握手揮手。可以通過 Connection: keep-alive 省下這部分的資源消耗。

長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的客戶來說，較適用長連接。但是在長連接的應用場景下，需要有一方主動關閉連接。如果客戶端和服務端之間的連接一直不關閉的話，連接數則會越來越多，嚴重的時候會造成資源占用過高。
解決方案也比較簡單。如果這些連接其實長時間內并沒有任何數據傳輸的話，那其實屬于空閑連接，這時候可以在服務端設置空閑連接的存活時間，超過一定時間后由服務端主動斷掉，從而保證無用連接及時釋放。

Cookies

Cookies是什么

Cookie 是瀏覽器訪問服務器后，服務器傳給瀏覽器的一段數據。里面一般帶有該瀏覽器的身份信息。
瀏覽器需要保存這段數據，不得輕易刪除。
此后每次瀏覽器訪問該服務器，都必須帶上這段數據。服務器用使用這段數據確認瀏覽器身份信息。

Cookie的作用

Cookie 一般有兩個作用。

識別用戶身份。
- 舉個例子。用戶 A 用瀏覽器訪問了“貓貓網”，“貓貓網”的服務器就會立刻給 A 返回一段Cookie數據，內含「uid=a」。
- 當 A 再次訪問“貓貓網”下的其他頁面時，比如跳轉到“貓貓交友評論”，就會附帶上「uid=a」這段數據。
- 同理，用戶 B 用瀏覽器訪問“貓貓網” 時，就給 B 分配了一段Cookie數據，內含「uid=b」。B 之后訪問“貓貓網”的時候，就會一直帶上「uid=b」這段數據。
- 因此“貓貓網”的服務器通過Cookie數據就能區分 A 和 B 兩個用戶了。
持久化用戶信息。
- 因為cookies的數據會被用戶瀏覽器保存到本地下。因此可以利用這一特點保持一些簡單的用戶數據。
- 比如一些博客網站，可以通過cookies記錄下用戶的性別年齡等信息，以此進行一些個性化展示。
- 當然上面提到的都是一些比較粗糙的場景，是為了方便大家理解cookies的功能。實際使用cookies會非常謹慎。

Referrer Policy 和 Referrer

Referrer是什么

Referrer 是HTTP請求header的報文頭，用于指明當前流量的來源參考頁面，常被用于分析用戶來源等信息。通過這個信息，我們可以知道訪客是怎么來到當前頁面的。比如在上面的請求截圖里，可以看出我是使用https://www.bilibili.com/訪問的視頻資源。
Referrer Policy 是什么

Referrer 字段，會用來指定該請求是從哪個頁面跳轉頁來的，里面的信息是瀏覽器填的。
而 Referrer Policy 則是用于控制Referrer信息傳不傳、傳哪些信息、在什么時候傳的策略。

為什么要這么麻煩呢？因為有些網站一些用戶敏感信息，比如 sessionid 或是 token 放在地址欄里，如果當做Referrer字段全部傳遞的話，那第三方網站就會拿到這些信息，會有一定的安全隱患。所以就有了 Referrer Policy，用于過濾 Referrer 報頭內容。
比如在上面的請求截圖里，可以看出我是使用strict-origin-when-cross-origin策略，含義是跨域時將當前頁面URL過濾掉參數及路徑部分，僅將協議、域名和端口（如果有的話）當作 Referrer。否則 Referrer 還是傳遞當前頁的全路徑。同時當發生降級（比如從 https:// 跳轉到 http:// ）時，不傳遞 Referrer 報頭。
Cache-control

什么是cache-control

cache-control，用于控制瀏覽器緩存。簡而言之，當某人訪問網站時，其瀏覽器將在本地保存某些資源，例如圖像和網站數據。當該用戶重新訪問同一網站時，緩存控制設置的規則會確定該用戶是否從本地緩存中加載這些資源，或者瀏覽器是否必須向服務器發送新資源的請求。
什么是瀏覽器緩存

瀏覽器緩存是指瀏覽器本地保存網站資源，以便不必再次通過網絡從服務器獲取它們。例如，“貓貓網”的背景圖像可以保存到本地緩存中，這樣在用戶第二次訪問該頁面時，該圖像將從用戶的本地文件加載，剩下網絡獲取資源的時間，頁面加載速度就會更快。
但是瀏覽器也不會永遠把這些網站資源放在本地，否則本地磁盤就會炸，所以會限定保存資源的時間，這叫生存時間（TTL）。如果 TTL 過期后用戶請求緩存的資源，瀏覽器必須再次通過網絡與服務器建立連接并重新下載這個資源。
常見的緩存控制策略

cache-control: private 具有“private”指令的響應只能由客戶端緩存，不能由中間代理（例如 CDN或代理）緩存。這些資源通常是包含私密數據的資源，例如顯示用戶個人信息的網站。
cache-control: public 相反，“public”指令表示資源可以由任何緩存存儲。
cache-control: no-store 帶有“no-store”指令的響應無法緩存到任何位置，也永不緩存。也就是說，用戶每次請求此數據時，都必須將請求發送到源站服務器以獲取新副本。此指令通常保留給包含極其敏感數據的資源，例如銀行帳戶信息。
cache-control: max-age 此指令指定了生存時間，也就是資源在下載后可以緩存多少秒鐘。例如，如果將最大期限設置為 1800，則首次從服務器請求資源后的 1800 秒（30 分鐘）內，后續請求都會向用戶提供該資源的緩存版本。如果 30 分鐘后用戶再次請求資源，則客戶端需要向服務器重新請求該資源。
cache-control: no-cache
從B站截圖里可以看出，使用的緩存控制指令是cache-control: no-cache。它表示，只有先檢查資源沒有更新版本后，才可使用所請求資源的緩存版本。那么問題來了，怎么判斷資源是否有更新版本呢？這就需要 ETag。

ETag

Etag是 Entity tag的縮寫，是服務端的一個資源版本的令牌標識。在 HTTP 響應頭中將其傳送到客戶端。每當資源更新時，此令牌會更新。

比如，瀏覽器第一次請求資源的時候，服務端返回了這個資源的ETag: "095933fff2323351d3b495f2f879616f1762f752"。
當瀏覽器再次請求這個資源的時候，瀏覽器會將If-None-Match: "095933fff2323351d3b495f2f879616f1762f752" 傳輸給服務端，服務端拿到該ETAG，對比資源是否發生變化。
- 如果資源未發生改變，則返回304HTTP狀態碼，不返回具體的資源。
- 否則表示資源已經更新，瀏覽器需要下載新版本以提供給用戶。
此過程可確保用戶始終獲得資源的最新版本，并且無需進行不必要的下載。

最后

果然B站是個充滿學習氛圍的地方，看個貓片都能學到這么多硬核知識。接下來我打算去舞蹈區看看有沒有適合你們的知識點。

我是賣客，有空？一起在知識的海洋里嗆水啊，懂我意思？

欧美日韩午夜_五月天激情综合_国产精品久久久久一区二区三区_色女人av_国产福利av_欧美日韩中

在B站看貓片被老板發現？不如按下F12學學HTTP