通過谷歌瀏覽器調(diào)試工具---查看請求資源的信息數(shù)據(jù)

以https://segmentfault.com/a/11...為例：

一撵割、General

1、Request URL 請求資源地址

ke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Request URL: https://ws.segmentfault.com:8443/socket.io/?EIO=3&transport=polling&t=OF1q877&sid=sBBmpTQAsbsb3ddGBOQ2

請求資源地址辙芍，需要注意的是url連接的?號后面拼接的字符串啡彬，和GET請求拼接字符串的性質(zhì)一樣，說明了這個POST請求發(fā)送的字符串?dāng)?shù)據(jù)故硅。這段字符串對應(yīng)Payload的內(nèi)容：

2庶灿、Request Method 請求方法

Request Method: POST

請求的方法，GET或者POST吃衅，其他的幾個方法HEAD往踢、PUT...

3、Status Code 狀態(tài)碼

Status Code: 200

HTTP狀態(tài)碼徘层。

常用的狀態(tài)碼有：200 OK峻呕、201 Created利职、301 Moved Permanently、302 Move Temporarily瘦癌、304 Not Modified眼耀、401 Unauthorized、404 Not Found佩憾、500 Internal Server Error哮伟、503 Service Unavailable

4、Remote Address 遠(yuǎn)程地址

Remote Address: 42.81.54.35:8443

資源服務(wù)器的ip地址和端口號妄帘。什么意思呢楞黄？這個地址在該IP地址和端口的服務(wù)器上放著。從這里獲取過來的抡驼。

大家需要注意的是：我訪問的是https://segmentfault.com/a/11...這個地址鬼廓，首先端口號肯定不是8443，而是https協(xié)議默認(rèn)端口號443致盟。說明這個請求是跨域獲取的資源碎税。

順便看一下IP是否一樣：IP是42.81.54.35，是和這條請求的Remote Address一樣的IP馏锡。

從這里看這條請求確實跨域了雷蹂，這里是發(fā)送ajax的POST請求，通過服務(wù)器的配置進(jìn)行的跨域杯道。下面的屬性中也會有關(guān)于跨域的信息匪煌，我們繼續(xù)往下看。

link標(biāo)簽的href党巾、img標(biāo)簽的src萎庭、script標(biāo)簽src 都具有跨域功能。是GET請求齿拂。

5驳规、Referrer Policy Referrer策略

Referrer Policy: strict-origin-when-cross-origin

Referrer-Policy 用來監(jiān)管哪些訪問來源信息——會在 Referer中發(fā)送。應(yīng)該被包含在生成的請求當(dāng)中署海。

Referrer-Policy是一個Referrer策略吗购，根據(jù)該策略值保證了哪些信息可以出現(xiàn)在Referer中。

在Request Headers請求頭中叹侄，有個referer屬性：

Referer對應(yīng)的信息巩搏，是由Referrer-Policy決定的，那么Referrer-Policy還有哪些設(shè)置呢趾代？

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

1） Referrer-Policy: no-referrer

整個 Referer 首部會被移除贯底。訪問來源信息不隨著請求一起發(fā)送。即：在請求頭Request Headers中不會顯示Referer屬性。

2）Referrer-Policy: no-referrer-when-downgrade （默認(rèn)值）

在沒有指定任何策略的情況下用戶代理的默認(rèn)行為禽捆。在同等安全級別的情況下笙什，引用頁面的地址會被發(fā)送(HTTPS->HTTPS)，但是在降級的情況下不會被發(fā)送 (HTTPS->HTTP)胚想。

3）Referrer-Policy: origin

在任何情況下琐凭，僅發(fā)送文件的源作為引用地址。比如：我們發(fā)送https://segmentfault.com/a/11...請求浊服，只會把https://segmentfault.com/作為Referer的值统屈。

4）Referrer-Policy: origin-when-cross-origin

對于同源的請求，會發(fā)送完整的URL作為引用地址牙躺，但是對于非同源請求（跨域請求）僅發(fā)送文件的源愁憔。

5）Referrer-Policy: same-origin

對于同源的請求會發(fā)送引用地址，但是對于非同源請求則不發(fā)送引用地址信息孽拷。

6）Referrer-Policy: strict-origin

在同等安全級別的情況下吨掌，發(fā)送文件的源作為引用地址(HTTPS->HTTPS)，但是在降級的情況下不會發(fā)送 (HTTPS->HTTP)脓恕。

7）Referrer-Policy: strict-origin-when-cross-origin

對于同源的請求膜宋，會發(fā)送完整的URL作為引用地址；在同等安全級別的情況下炼幔，發(fā)送文件的源作為引用地址(HTTPS->HTTPS)秋茫；在降級的情況下不發(fā)送此首部 (HTTPS->HTTP)。

8）Referrer-Policy: unsafe-url

無論是同源請求還是非同源請求江掩，都發(fā)送完整的 URL（移除參數(shù)信息之后）作為引用地址学辱。這項設(shè)置會將受 TLS 安全協(xié)議保護(hù)的資源的源和路徑信息泄露給非安全的源服務(wù)器。進(jìn)行此項設(shè)置的時候要慎重考慮环形。

參考文檔：https://developer.mozilla.org...

二、Response Headers 響應(yīng)頭

1衙傀、access-control-allow-credentials: true

Credentials：證書抬吟。該字段可選。它的值是一個布爾值统抬，表示是否允許發(fā)送Cookie火本。

默認(rèn)情況下，Cookie不包括在CORS（跨域）請求之中聪建。設(shè)為true钙畔，即表示服務(wù)器明確許可，Cookie可以包含在CORS請求中金麸，一起發(fā)給服務(wù)器擎析。這個值也只能設(shè)為true，如果服務(wù)器不要瀏覽器發(fā)送Cookie挥下，刪除該字段即可揍魂。

參考文章：https://blog.csdn.net/java_gr...

2桨醋、Access-Control-Allow-Headers

首部字段用于預(yù)檢請求的響應(yīng)。其指明了實際請求中允許攜帶的首部字段现斋。值為逗號分割的列表喜最。

Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

表明服務(wù)器允許請求中攜帶字段 X-PINGOTHER 與 Content-Type。

3庄蹋、Access-Control-Allow-Methods

首部字段用于預(yù)檢請求的響應(yīng)瞬内。其指明了實際請求所允許使用的 HTTP 方法。

Access-Control-Allow-Methods: GET, POST,OPTIONS

4限书、access-control-allow-origin

access-control-allow-origin: https://segmentfault.com

指定服務(wù)器可以跨域的源虫蝶。

還記得Request URL嗎，我們請求的資源url是：https://segmentfault.com:8443/蔗包。但是我們訪問的服務(wù)器是：https://segmentfault.com:443/秉扑。所以說該請求是跨域的。

原因是：Access-Control-Allow-Origin 響應(yīng)頭指定了該響應(yīng)的資源是否被允許與給定的origin共享调限。https://segmentfault.com:8443/的資源共享給https://segmentfault.com的源舟陆。

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>

1）表示：對于不需具備憑證（credentials）的請求，服務(wù)器會以*作為通配符耻矮，從而允許所有域都具有訪問資源的權(quán)限秦躯。如需允許所有源的請求都可以訪問該服務(wù)的資源，也可以設(shè)置值為*裆装，但是這樣太危險踱承，服務(wù)器也不應(yīng)該且不會這么配置。

2）<origin> 表示：一個具體的源哨免【セ睿客戶端在該域獲取資源時，可以跨域獲取別的服務(wù)器的資源琢唾。

參考文檔：https://developer.mozilla.org...

5载荔、Access-Control-Expose-Headers

在跨源訪問時，XMLHttpRequest對象的getResponseHeader()方法只能拿到一些最基本的響應(yīng)頭采桃，Cache-Control懒熙、Content-Language、Content-Type普办、Expires工扎、Last-Modified、Pragma衔蹲，如果要訪問其他頭肢娘，則需要服務(wù)器設(shè)置本響應(yīng)頭。

Access-Control-Expose-Headers 頭讓服務(wù)器把允許瀏覽器訪問的頭放入白名單，例如：

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Head

這樣瀏覽器就能夠通過getResponseHeader()訪問X-My-Custom-Header和 X-Another-Custom-Header 響應(yīng)頭了蔬浙。

6猪落、cf-cache-status 【Cloudflare 頁面緩存CDN服務(wù)】

目的：可以大大減少源服務(wù)器的負(fù)載開支，使得你的站點能夠承載更多的訪客及流量畴博。

1）狀態(tài)解釋如下：

• cf-cache-status:HIT（完成緩存）
  則說明該頁面已經(jīng)完全緩存笨忌。
• cf-cache-status:DYNAMIC （動態(tài)）
  如果是“DYNAMIC”則說明，該站可能只開啟了小云朵俱病，并沒有配置整站完全緩存官疲。
• cf-cache-status:BYPASS （繞過）
  如果是“BYPASS”則說明，該站針對這個頁面設(shè)置了繞過亮隙，不允許緩存途凫。

2）Cloudflare的緩存機(jī)制
假設(shè)你的站點有 www.yigeyi.org/1.html 和 www.yigeyi.org/2.html 兩個頁面。

當(dāng)訪客A 訪問1.html這個頁面的時候溢吻，首先會經(jīng)由Cloudflare维费，這個時候你的頁面規(guī)則就起作用了。

Cloudflare會發(fā)現(xiàn)促王，吼吼犀盟，這個站有個1.html 我給它緩存下來，并且轉(zhuǎn)發(fā)給A蝇狼。

當(dāng)訪客B 在Edge Cache過期時間之前阅畴，重復(fù)訪問1.html的時候。
Cloudflare會思考一下迅耘。哈哈哈贱枣，這個1.html我有。不用麻煩源站了颤专。我直接給到B就可以了纽哥。

這就是所謂的命中率，如果這個頁面被完全命中栖秕，那么B訪問1.html雖然得到了網(wǎng)頁昵仅，但是是由Cloudflare直接提供的。你的源站甚至連客戶的IP都統(tǒng)計不到累魔。

但是，2.html 這個頁面在你的規(guī)則建立開始時從未有任何訪客訪問過够滑。那么Cloudflare也不知道這個頁面的存在垦写，也不會緩存。除非等到真的有人訪問過彰触，Cloudflare才會發(fā)現(xiàn)梯投，并對其進(jìn)行緩存。

參考文檔：https://cloud.tencent.com/dev...

7、cf-ray

橫杠后面的字母代表了CDN節(jié)點機(jī)房的縮寫分蓖。

CF-RAY 標(biāo)頭可跟蹤通過 Cloudflare 網(wǎng)絡(luò)的網(wǎng)站請求尔艇。對問題進(jìn)行故障排除時，將 Web 請求的 CF-RAY 提供給 Cloudflare 支持么鹤。

8终娃、server

Cloudflare是一家美國的跨國科技企業(yè)，總部位于舊金山蒸甜，在英國倫敦亦設(shè)有辦事處棠耕。Cloudflare以向客戶提供網(wǎng)站安全管理、性能優(yōu)化及相關(guān)的技術(shù)支持為主要業(yè)務(wù)柠新。

9窍荧、Connection: keep-alive

連接保持活性。

http1.1的特點恨憎，連接保持活性蕊退，不直接斷開連接，保持一段時間憔恳。在http1.0協(xié)議中瓤荔，每個請求通過TCP協(xié)議連接，三次握手后喇嘱，連接成功茉贡，進(jìn)行發(fā)送請求和數(shù)據(jù)響應(yīng)。服務(wù)器響應(yīng)結(jié)束后者铜，直接斷開連接腔丧。如果客戶端再發(fā)送新的請求，需要重新建立TCP連接作烟。

而在http1.1協(xié)議中愉粤，當(dāng)一個請求和響應(yīng)完成后，不會直接斷開連接拿撩，而是等待幾秒衣厘。如果客戶端還有請求需要發(fā)送給服務(wù)器，那么就使用這個TCP通道压恒。從而減少了每次請求時創(chuàng)建新的TCP握手時間影暴。

10、Keep-Alive: timeout=5

保持活性的時間探赫。

正如上面Connection屬性所提到的型宙，需要設(shè)置保持活性的時間。時間為5秒伦吠。

11妆兑、Content-Type: text/html

響應(yīng)文本的類型魂拦。

根據(jù)每個請求的資源類型不同，服務(wù)器響應(yīng)該資源的時候搁嗓，要告知瀏覽器這個資源是什么類型的芯勘。比如：文本、圖片腺逛、html資源荷愕、css資源、js資源屉来、音頻資源路翻、視頻資源等等。

Content-Type（內(nèi)容類型）茄靠，用于定義網(wǎng)絡(luò)文件的類型和網(wǎng)頁的編碼茂契，決定瀏覽器將以什么形式、什么編碼讀取這個文件慨绳，Content-Type 標(biāo)頭告訴客戶端實際返回的內(nèi)容的內(nèi)容類型掉冶。

有時也會攜帶編碼格式。

Content-Type: text/html脐雪；charset=UTF-8

關(guān)于UTF-8編碼格式可參考這篇文章：ASCII碼厌小、Unicode碼、UTF-8編碼

12战秋、Content-Length: 2

響應(yīng)內(nèi)容的長度璧亚，指的是http協(xié)議中body的長度。

參考文檔：https://blog.csdn.net/zxl1990...

13脂信、content-encoding: gzip

Content-Encoding 是一個實體消息首部癣蟋，用于對特定媒體類型的數(shù)據(jù)進(jìn)行壓縮。當(dāng)這個首部出現(xiàn)的時候狰闪，它的值表示消息主體進(jìn)行了何種方式的內(nèi)容編碼轉(zhuǎn)換疯搅。這個消息首部用來告知客戶端應(yīng)該怎樣解碼才能獲取在 Content-Type 中標(biāo)示的媒體類型內(nèi)容。

一般建議對數(shù)據(jù)盡可能地進(jìn)行壓縮埋泵，因此才有了這個消息首部的出現(xiàn)幔欧。不過對于特定類型的文件來說，比如jpeg圖片文件丽声，已經(jīng)是進(jìn)行過壓縮的了礁蔗。有時候再次進(jìn)行額外的壓縮無助于負(fù)載體積的減小，反而有可能會使其增大雁社。

Accept-Encoding 和Content-Encoding是HTTP中用來對采用哪種編碼格式傳輸正文進(jìn)行協(xié)定的一對頭部字段瘦麸。

工作原理如下:

• 1）首先瀏覽器（也就是客戶端）發(fā)送請求時，通過Accept-Encoding帶上自己支持的內(nèi)容編碼格式列表歧胁；
• 2）服務(wù)端在接收到請求后滋饲，從中挑選出一種用來對響應(yīng)信息進(jìn)行編碼，并通過Content-Encoding來說明服務(wù)端選定的編碼信息
• 3）瀏覽器在拿到響應(yīng)正文后喊巍，依據(jù)Content-Encoding進(jìn)行解壓屠缭。

參考文檔：https://blog.csdn.net/u014569...

14、set-cookie

set-cookie: io=sBBmpTQAsbsb3ddGBOQ2; Path=/; HttpOnly

Set-Cookie是服務(wù)器響應(yīng)設(shè)置的cookie值崭参。即服務(wù)器寫入瀏覽器的cookie值

Path=/是路徑呵曹，一個string代表cookie的路徑。寫入到了根目錄下何暮，即本例中的https://segmentfault.com/本地對應(yīng)的域名根目錄下奄喂。

HttpOnly，一個boolean值海洼，HttpOnly=true或HttpOnly=false跨新。true表示cookie被標(biāo)記為HttpOnly（即，客戶端腳本無法訪問cookie）坏逢，false表示Set-Cookie不標(biāo)記HttpOnly域帐，即客戶端可以修改該cookie值。

如果您在cookie中設(shè)置了HttpOnly屬性是整，那么通過js腳本將無法讀取到cookie信息肖揣，這樣能有效的防止XSS攻擊。

參考文章：https://developer.mozilla.org...

15浮入、date

date: Mon, 10 Oct 2022 12:13:31 GMT

服務(wù)器的時間龙优，注意獲取的是GMT格林威治時間，比北京時間慢8小時事秀。

16彤断、Transfer-Encoding

Transfer-Encoding: chunked

分塊傳輸編碼（Chunked transfer encoding）是超文本傳輸協(xié)議（HTTP）中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端的數(shù)據(jù)可以分成多個部分秽晚。分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供瓦糟。

Content-Encoding 和 Transfer-Encoding 二者經(jīng)常會結(jié)合來用，其實就是針對 Transfer-Encoding 的分塊再進(jìn)行 Content-Encoding壓縮赴蝇。

參考文檔：分塊編碼

17菩浙、Vary

Vary: Origin

1）Vary是作為響應(yīng)頭由服務(wù)器端返回數(shù)據(jù)時添加的頭部信息；

2）Vary頭的內(nèi)容來自于當(dāng)前請求的Request頭部Key句伶，比如Accept-Encoding树肃、User-Agent等；

3）緩存服務(wù)器進(jìn)行某接口的網(wǎng)絡(luò)請求結(jié)果數(shù)據(jù)緩存時炭庙，會將Vary一起緩存厢岂；

4）HTTP請求，緩存中Vary的內(nèi)容會作為當(dāng)前緩存數(shù)據(jù)是否可以作為請求結(jié)果返回給客戶端的判斷依據(jù)楚堤；

5）HTTP請求疫蔓，響應(yīng)數(shù)據(jù)中的Vary用來判斷當(dāng)前緩存中同請求的數(shù)據(jù)的Vary是否失效含懊，如果緩存中的Vary與服務(wù)器剛拿到的Vary不一致，則可以進(jìn)行更新衅胀。

6）當(dāng)Vary的值為“”岔乔，意味著請求頭中的所有信息都不可作為是否從緩存服務(wù)器拿數(shù)據(jù)的判斷依據(jù)。*

18滚躯、X-Request-Id

用戶請求日志關(guān)聯(lián) 項目間請求日志關(guān)聯(lián)雏门。查詢?nèi)罩荆挪閱栴}掸掏。

19茁影、Cache-Control

資源緩存。

Cache-Control 通用消息頭字段丧凤，被用于在http請求和響應(yīng)中募闲，通過指定指令來實現(xiàn)緩存機(jī)制。緩存指令是單向的息裸，這意味著在請求中設(shè)置的指令蝇更，不一定被包含在響應(yīng)中。緩存是在本地磁盤中呼盆，所以下次獲取該資源的時候年扩，from disk cache。從磁盤緩存中獲取访圃。

[圖片上傳失敗...(image-78230-1702461788274)]

指令不區(qū)分大小寫厨幻，并且具有可選參數(shù)，可以用令牌或者帶引號的字符串語法腿时。多個指令以逗號分隔况脆。如上圖示例所展示

1）在請求頭中

客戶端可以在HTTP請求中使用的標(biāo)準(zhǔn) Cache-Control 指令。

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache 
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached 

2）在響應(yīng)頭中

服務(wù)器可以在響應(yīng)中使用的標(biāo)準(zhǔn) Cache-Control 指令批糟。

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds> 

概述：四個指令和四個到期時間設(shè)置

指令：

• public

表明響應(yīng)可以被任何對象（包括：發(fā)送請求的客戶端格了，代理服務(wù)器，等等）緩存徽鼎，即使是通常不可緩存的內(nèi)容盛末。（例如：1.該響應(yīng)沒有max-age指令或Expires消息頭；2. 該響應(yīng)對應(yīng)的請求方法是 POST 否淤。）

• private

表明響應(yīng)只能被單個用戶緩存悄但，不能作為共享緩存（即代理服務(wù)器不能緩存它）。私有緩存可以緩存響應(yīng)內(nèi)容石抡，比如：對應(yīng)用戶的本地瀏覽器檐嚣。

• no-cache

在發(fā)布緩存副本之前，強制要求緩存把請求提交給原始服務(wù)器進(jìn)行驗證(協(xié)商緩存驗證)啰扛。

• no-store

緩存不應(yīng)存儲有關(guān)客戶端請求或服務(wù)器響應(yīng)的任何內(nèi)容嚎京，即不使用任何緩存嗡贺。</pre>

到期時間：

max-age=<seconds>

設(shè)置緩存存儲的最大周期，超過這個時間緩存被認(rèn)為過期(單位秒)挖藏。與Expires相反暑刃，時間是相對于請求的時間。

s-maxage=<seconds>

覆蓋max-age或者Expires頭膜眠，但是僅適用于共享緩存(比如各個代理)，私有緩存會忽略它溜嗜。

max-stale[=<seconds>]

表明客戶端愿意接收一個已經(jīng)過期的資源宵膨。可以設(shè)置一個可選的秒數(shù)炸宵，表示響應(yīng)不能已經(jīng)過時超過該給定的時間辟躏。

min-fresh=<seconds>

表示客戶端希望獲取一個能在指定的秒數(shù)內(nèi)保持其最新狀態(tài)的響應(yīng)。

關(guān)于上面截圖示例中土全，access-control-allow-origin：*

大家注意捎琐，這是一個js文件，放在思否的服務(wù)器中的js文件裹匙，是完全開放的瑞凑，可以被任何源獲取。

地址如下：

Request URL: https://www.googletagmanager.com/gtag/js?id=UA-918487-8

我們可以通過本地的html代碼的script標(biāo)簽來獲取該資源概页。比如：

<script src="https://www.googletagmanager.com/gtag/js?id=UA-918487-8"></script>

實際上服務(wù)器對靜態(tài)資源的設(shè)置都是完全開放的籽御，比如圖片、css惰匙、js文件技掏，設(shè)置的access-control-allow-origin:*

額外補充：靜態(tài)內(nèi)容，服務(wù)器只是發(fā)送文件项鬼，這種操作所耗CPU開銷非常小哑梳。

三、Request Headers 請求頭

請求頭是客戶端發(fā)送給服務(wù)器的相關(guān)信息绘盟，大部分信息開發(fā)人員都可以配置鸠真，但是有的即使你配置了，客戶端瀏覽器也會無視奥此，客戶端會根據(jù)http協(xié)議弧哎，走默認(rèn)的設(shè)置。

禁止修改的Request Headers

禁止修改的消息首部指的是不能在代碼中通過編程的方式進(jìn)行修改的HTTP協(xié)議消息首部稚虎。本文僅討論相關(guān)的HTTP請求首部（關(guān)于禁止修改的響應(yīng)首部撤嫩，請參考 Forbidden response header name）。

用戶代理對這些消息首部保留全部控制權(quán)蠢终，應(yīng)用程序無法設(shè)置它們序攘。

禁止修改的消息首部包括以 Proxy- 和 Sec- 開頭的消息首部茴她，以及下面列出的消息首部：

1. Accept-Charset
2. Accept-Encoding
3. Access-Control-Request-Headers
4. Access-Control-Request-Method
5. Connection
6. Content-Length
7. Cookie
8. Cookie2
9. Date
10. DNT
11. Expect
12. Host
13. Keep-Alive
14. Origin
15. Proxy-
16. Sec-
17. Referer
18. TE
19. Trailer
20. Transfer-Encoding
21. Upgrade
22. Via

本文示例中的Request Headers：

1、Accept

客戶端告知服務(wù)器程奠，客戶端可以處理的內(nèi)容類型丈牢，壓縮方式，系統(tǒng)語言瞄沙。

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

------HTTP/2相關(guān) ------

HTTP/2 將頭部壓縮作為改進(jìn)重點己沛，不過 HTTP/2 并沒有使用傳統(tǒng)的字符串壓縮算法，而是開發(fā)了專門的 HPACK 算法距境。

為什么要新開發(fā)一個算法呢申尼？

因為傳統(tǒng)的字符串壓縮算法并沒有考慮客戶端與服務(wù)端之間多次請求的數(shù)據(jù)交互數(shù)據(jù)大量重復(fù)的問題，如果通過在客戶端和服務(wù)器兩端建立兩個一樣“字典”來存儲 Header 的 Key-Value 數(shù)據(jù)垫桂，那么在下次使用該數(shù)據(jù)的時候只要傳輸索引號就可以了师幕，另外還對整數(shù)和字符串采用了哈夫曼編碼來進(jìn)一步壓縮，整體可以達(dá)到 50%~90% 的高壓縮率诬滩。

HPACK 它是一個有狀態(tài)的算法霹粥，需要客戶端和服務(wù)器各自維護(hù)一份索引表。

HTTP/2 還把 HTTP/1.1 中起始行里面的方法名疼鸟、請求路徑后控、狀態(tài)碼等也統(tǒng)一轉(zhuǎn)換成了頭字段的形式，將其命名為：pseudo-header fields愚臀，并在其名字前面加了一個“:”忆蚀，比如“:method”、“:status”分別表示的是請求方法和狀態(tài)碼姑裂。

參考文檔：https://zhuanlan.zhihu.com/p/...

1） Accept

Accept 請求頭用來告知（服務(wù)器）客戶端可以處理的內(nèi)容類型馋袜，這種內(nèi)容類型用MIME類型來表示。借助內(nèi)容協(xié)商機(jī)制, 服務(wù)器可以從諸多備選項中選擇一項進(jìn)行應(yīng)用舶斧，并使用 Content-Type 應(yīng)答頭通知客戶端它的選擇欣鳖。瀏覽器會基于請求的上下文來為這個請求頭設(shè)置合適的值，比如獲取一個CSS層疊樣式表時值與獲取圖片茴厉、視頻或腳本文件時的值是不同的泽台。

<MIME_type>/<MIME_subtype>：單一精確的 MIME 類型, 例如text/html.

<MIME_type>/*：一類 MIME 類型, 但是沒有指明子類。 image/* 可以用來指代 image/png, image/svg, image/gif 以及任何其他的圖片類型矾缓。

*/*：任意類型的 MIME 類型怀酷。一般都設(shè)置該值，因為瀏覽器可以處理的類型太多嗜闻。

MIME類型：瀏覽器可以解析的資源類型蜕依，比如：

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/*
application/json
application/javascript
application/ecmascript
application/octet-stream
…

參考文檔：https://developer.mozilla.org...

2）Accept-Encoding: gzip, deflate, br

HTTP 請求頭 Accept-Encoding 會將客戶端能夠理解的內(nèi)容編碼方式——通常是某種壓縮算法——進(jìn)行通知（給服務(wù)端）友瘤。通過內(nèi)容協(xié)商的方式，服務(wù)端會選擇一個客戶端提議的方式檐束，使用并在響應(yīng)頭 Content-Encoding 中通知客戶端該選擇辫秧。

即使客戶端和服務(wù)器都支持相同的壓縮算法，在 identity 指令可以被接受的情況下被丧，服務(wù)器也可以選擇對響應(yīng)主體不進(jìn)行壓縮盟戏。導(dǎo)致這種情況出現(xiàn)的兩種常見的情形是：

• 要發(fā)送的數(shù)據(jù)已經(jīng)經(jīng)過壓縮，再次進(jìn)行壓縮不會導(dǎo)致被傳輸?shù)臄?shù)據(jù)量更小甥桂。一些圖像格式的文件會存在這種情況抓半；
• 服務(wù)器超載，無法承受壓縮需求導(dǎo)致的計算開銷格嘁。通常，如果服務(wù)器使用超過80%的計算能力廊移，微軟建議不要壓縮糕簿。

只要 identity —— 表示不需要進(jìn)行任何編碼——沒有被明確禁止使用（通過 identity;q=0 指令或是 *;q=0 而沒有為 identity 明確指定權(quán)重值），則服務(wù)器禁止返回表示客戶端錯誤的 406 Not Acceptable 響應(yīng)狡孔。

• gzip
  表示采用 Lempel-Ziv coding (LZ77) 壓縮算法懂诗，以及32位CRC校驗的編碼方式。這個編碼方式最初由 UNIX 平臺上的 gzip 程序采用苗膝。出于兼容性的考慮殃恒， HTTP/1.1 標(biāo)準(zhǔn)提議支持這種編碼方式的服務(wù)器應(yīng)該識別作為別名的 x-gzip 指令。

• compress
  采用 Lempel-Ziv-Welch (LZW) 壓縮算法辱揭。這個名稱來自UNIX系統(tǒng)的 compress 程序离唐，該程序?qū)崿F(xiàn)了前述算法。
  與其同名程序已經(jīng)在大部分UNIX發(fā)行版中消失一樣问窃，這種內(nèi)容編碼方式已經(jīng)被大部分瀏覽器棄用亥鬓，部分因為專利問題（這項專利在2003年到期）。

• deflate
  采用 zlib 結(jié)構(gòu) (在 RFC 1950 中規(guī)定)域庇，和 deflate 壓縮算法(在 RFC 1951 中規(guī)定)嵌戈。

• identity
  用于指代自身（例如：未經(jīng)過壓縮和修改）。除非特別指明听皿，這個標(biāo)記始終可以被接受熟呛。

• br
  表示采用 Brotli 算法的編碼方式。

3）Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Accept-Language 請求頭允許客戶端聲明它可以理解的自然語言尉姨，以及優(yōu)先選擇的區(qū)域方言庵朝。

;q= (q因子權(quán)重) 值代表優(yōu)先順序，用相對質(zhì)量價值表示，又稱作權(quán)重偿短。

2欣孤、Content

下面三個Response Headers也有設(shè)置，客戶端發(fā)送請求時告知服務(wù)器關(guān)于Content的相關(guān)信息

Connection: keep-alive
Content-Length: 53
Content-type: text/plain;charset=UTF-8

3昔逗、cookie

cookie: _ga=GA1.1.1502755452.1660028234; PHPSESSID=012c1773970ddd37d36c9888b26900cf; Hm_lvt_e23800c454aa573c0ccb16b52665ac26=1663037940,1663740113,1665302702; Hm_lpvt_e23800c454aa573c0ccb16b52665ac26=1665404010; io=sBBmpTQAsbsb3ddGBOQ2; _ga_MJYFRXB3ZX=GS1.1.1665401366.8.1.1665404010.0.0.0

瀏覽器在發(fā)送請求時降传，默認(rèn)會帶上cookie。Cookie 是一個請求首部勾怒，其中含有先前由服務(wù)器通過 Set-Cookie 首部投放并存儲到客戶端的 HTTP cookies婆排。

參考文檔：https://developer.mozilla.org...

4、Host

Host: segmentfault.com:8443

Host是請求資源地址Host主機(jī)服務(wù)器笔链。即通過url請求獲取的資源是來自Host主機(jī)服務(wù)器段只。

5、Origin

origin: https://segmentfault.com

Origin源鉴扫，正如上面所提到的赞枕，源就是客戶端網(wǎng)頁頁面的那個服務(wù)器。

6坪创、pragma

pragma: no-cache

跟Cache-Control: no-cache相同炕婶。Pragma: no-cache兼容http 1.0 ，Cache-Control: no-cache是http 1.1提供的莱预。

因此柠掂，Pragma: no-cache可以應(yīng)用到http 1.0 和http 1.1，而Cache-Control: no-cache只能應(yīng)用于http 1.1.

6依沮、Referer

referer: https://segmentfault.com/

根據(jù)Referrer-Policy來決定Referer展示多少內(nèi)容涯贞，甚至是不展示。

Referer 請求頭包含了當(dāng)前請求頁面的來源頁面的地址危喉，即表示當(dāng)前頁面是通過此來源頁面里的鏈接進(jìn)入的宋渔。服務(wù)端一般使用 Referer 請求頭識別訪問來源，可能會以此進(jìn)行統(tǒng)計分析姥饰、日志記錄以及緩存優(yōu)化等傻谁。示例：

Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript

在以下兩種情況下，Referer 不會被發(fā)送：

• 來源頁面采用的協(xié)議為表示本地文件的 "file" 或者 "data" URI列粪；比如：用瀏覽器打開本地的html文件時审磁，file:///D:/Technology-stack/test.html
• 當(dāng)前請求頁面采用的是非安全協(xié)議HTTP，而來源頁面采用的是安全協(xié)議（HTTPS）岂座。即源服務(wù)器是https态蒂，跨域服務(wù)器是http，不會發(fā)送Referer费什。

7钾恢、User-Agent

user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

User-Agent 首部包含了一個特征字符串，用來讓網(wǎng)絡(luò)協(xié)議的對端來識別發(fā)起請求的用戶代理軟件的應(yīng)用類型、操作系統(tǒng)瘩蚪、軟件開發(fā)商以及版本號泉懦。

User-Agent會告訴網(wǎng)站服務(wù)器，訪問者是通過什么工具來請求的疹瘦，如果是爬蟲請求崩哩，一般會拒絕，如果是用戶瀏覽器言沐，就會應(yīng)答邓嘹。

作用：可用于網(wǎng)站站點數(shù)據(jù)統(tǒng)計；統(tǒng)計用戶瀏覽器使用情況险胰。

window發(fā)起的請求汹押，User-Agent:  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.193 Safari/537.36

iPhone-X發(fā)起的請求，user-agent:  Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1

Android發(fā)起的請求起便，User-Agent:  Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.193 Mobile Safari/537.36

瀏覽器通常使用的格式為：包含了瀏覽器的信息棚贾，比如window還是iPhone、Android榆综。瀏覽器的類型鸟悴、瀏覽器的版本、瀏覽器的內(nèi)核等等信息奖年。

User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>

參考文檔：https://blog.csdn.net/xinyuan...

8、sec-

只要包含前綴 Sec- 都屬于應(yīng)用程序禁止修改的HTTP消息頭沛贪，用戶代理保留全部對它們的控制權(quán)陋守。

···
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
···

1）sec-ch-ua:
用來代替?zhèn)鹘y(tǒng)的 user-agent 的，原來的 user-agent 因為只是一個字符串利赋，各個瀏覽器及歷史版本造成識別服務(wù)端不太兼容水评。為了能讓服務(wù)端明確請求的信息，所以提出這個來升級媚送。

2）sec-ch-ua-mobile:
安全相關(guān)中燥， 是否是移動設(shè)備

• Sec-CH-UA-Mobile: ?0，否塘偎；
• Sec-CH-UA-Mobile: ?1疗涉，是；

3）sec-ch-ua-platform:
用戶代理運行 的平臺或操作系統(tǒng)吟秩。

以下字符串之一："Android", "Chrome OS", "Chromium OS", "iOS", "Linux", "macOS", "Windows", 或"Unknown".

4）sec-fetch-dest:
安全相關(guān)咱扣，如何使用獲取的數(shù)據(jù)。

獲取元數(shù)據(jù)請求標(biāo)頭指示請求的目的地涵防。那是原始獲取請求的發(fā)起者闹伪，它是獲取的數(shù)據(jù)將在哪里（以及如何）使用。

這允許服務(wù)器根據(jù)請求是否適合預(yù)期的使用方式來確定是否為請求提供服務(wù)。例如偏瓤，帶有audio目的地的請求應(yīng)該請求音頻數(shù)據(jù)杀怠，而不是其他類型的資源（例如，包含敏感用戶信息的文檔）厅克。

參考文檔：https://developer.mozilla.org...

5）sec-fetch-mode:
安全相關(guān)赔退，獲取元數(shù)據(jù)請求標(biāo)頭指示請求的模式。

參考文檔：https://developer.mozilla.org...

6）sec-fetch-site:
安全相關(guān)已骇，獲取元數(shù)據(jù)請求標(biāo)頭指示請求發(fā)起者的來源和所請求資源的來源之間的關(guān)系离钝。

換句話說，此標(biāo)頭告訴服務(wù)器對資源的請求是來自同一來源褪储、同一站點卵渴、不同站點還是“用戶發(fā)起的”請求。然后鲤竹，服務(wù)器可以使用此信息來決定是否應(yīng)允許該請求浪读。

默認(rèn)情況下通常允許同源請求，但是對于來自其他源的請求會發(fā)生什么可能進(jìn)一步取決于請求的資源或其他Fetch 元數(shù)據(jù)請求標(biāo)頭中的信息辛藻。默認(rèn)情況下碘橘，應(yīng)使用403響應(yīng)代碼拒絕不接受的請求。

參考文檔：https://developer.mozilla.org...