注我的微信公眾號(hào)：后端技術(shù)漫談

不定期推送關(guān)于后端開發(fā)、爬蟲、算法題、數(shù)據(jù)結(jié)構(gòu)方面的原創(chuàng)技術(shù)文章，以及生活中的逸聞趣事。

我目前是一名后端開發(fā)工程師。主要關(guān)注后端開發(fā)，數(shù)據(jù)安全，網(wǎng)絡(luò)爬蟲，物聯(lián)網(wǎng)，邊緣計(jì)算等方向。

原創(chuàng)博客主要內(nèi)容

• Java知識(shí)點(diǎn)復(fù)習(xí)全手冊(cè)
• Leetcode算法題解析
• 劍指offer算法題解析
• SpringCloud菜鳥入門實(shí)戰(zhàn)系列
• SpringBoot菜鳥入門實(shí)戰(zhàn)系列
• Python爬蟲相關(guān)技術(shù)文章
• 后端開發(fā)相關(guān)技術(shù)文章

image

前言

本文快速回顧了常考的的知識(shí)點(diǎn)，用作面試復(fù)習(xí)，事半功倍。

上篇主要內(nèi)容： 狀態(tài)碼、Http1.0/1.1/2.0、Https、GET和POST

下篇主要內(nèi)容： Web攻擊技術(shù)、HTTP基礎(chǔ)概念、HTTP Header詳解、HTTP應(yīng)用

面試知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)

全復(fù)習(xí)手冊(cè)文章導(dǎo)航

Csdn全復(fù)習(xí)手冊(cè)文章導(dǎo)航：

https://blog.csdn.net/qqxx6661/article/details/86775594

已發(fā)布知識(shí)點(diǎn)復(fù)習(xí)手冊(cè)

• Java基礎(chǔ)知識(shí)點(diǎn)面試手冊(cè)
• Java容器（List、Set、Map）知識(shí)點(diǎn)快速復(fù)習(xí)手冊(cè)
• Java并發(fā)知識(shí)點(diǎn)快速復(fù)習(xí)手冊(cè)（上）
• Java并發(fā)知識(shí)點(diǎn)快速復(fù)習(xí)手冊(cè)（下）
• Java虛擬機(jī)知識(shí)點(diǎn)快速復(fù)習(xí)手冊(cè)（上）
• Java虛擬機(jī)知識(shí)點(diǎn)快速復(fù)習(xí)手冊(cè)（下）
• 快速梳理23種常用的設(shè)計(jì)模式
• Redis基礎(chǔ)知識(shí)點(diǎn)面試手冊(cè)
• Leetcode題解分類匯總（前150題）
• 面試常問的小算法總結(jié)
• 查找算法總結(jié)及其部分算法實(shí)現(xiàn)Python/Java
• 排序算法實(shí)現(xiàn)與總結(jié)Python/Java
• ……等（請(qǐng)查看全復(fù)習(xí)手冊(cè)導(dǎo)航）

本文參考

本文內(nèi)容主要參考來自CyC2018的Github倉庫：CS-Notes

有刪減，修改，補(bǔ)充額外增加內(nèi)容

本作品采用知識(shí)共享署名-非商業(yè)性使用 4.0 國際許可協(xié)議進(jìn)行許可。

--------------------正文-----------------------

狀態(tài)碼

圖片文件夾兩張圖

有拓展參考：https://zhuanlan.zhihu.com/p/34648453

狀態(tài)碼 類別 原因短語 1XX Informational（信息性狀態(tài)碼） 接收的請(qǐng)求正在處理 2XX Success（成功狀態(tài)碼） 請(qǐng)求正常處理完畢 3XX Redirection（重定向狀態(tài)碼） 需要進(jìn)行附加操作以完成請(qǐng)求 4XX Client Error（客戶端錯(cuò)誤狀態(tài)碼） 服務(wù)器無法處理請(qǐng)求 5XX Server Error（服務(wù)器錯(cuò)誤狀態(tài)碼） 服務(wù)器處理請(qǐng)求出錯(cuò)

1XX 信息

• 100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)。
• 101 Switching Protocols 協(xié)議升級(jí)：請(qǐng)求者要求服務(wù)器切換協(xié)議，服務(wù)器確認(rèn)并準(zhǔn)備切換 主要用于websocket：表示服務(wù)端接受 WebSocket 協(xié)議的客戶端連接 也可以用于http2的升級(jí)。

2XX 成功

• 200 OK
• 204 No Content ：請(qǐng)求已經(jīng)成功處理，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息，而不需要返回?cái)?shù)據(jù)時(shí)使用。
• 206 Partial Content ：表示客戶端進(jìn)行了范圍請(qǐng)求。響應(yīng)報(bào)文包含由 Content-Range 指定范圍的實(shí)體內(nèi)容。

3XX 重定向

• 301 Moved Permanently ：永久性重定向
• 302 Found ：臨時(shí)性重定向
• 303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源。 注：雖然 HTTP 協(xié)議規(guī)定 301、302 狀態(tài)下重定向時(shí)不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會(huì)在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法。
• 304 Not Modified ：如果請(qǐng)求報(bào)文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務(wù)器會(huì)返回 304 狀態(tài)碼。 瀏覽器緩存分為強(qiáng)制緩存和協(xié)商緩存，優(yōu)先讀取強(qiáng)制緩存。 強(qiáng)制緩存分為expires和cache-control： expires是一個(gè)特定的時(shí)間，是比較舊的標(biāo)準(zhǔn)。 cache-control通常是一個(gè)具體的時(shí)間長度，比較新，優(yōu)先級(jí)也比較高。 協(xié)商緩存包括etag和last-modified： last-modified的設(shè)置標(biāo)準(zhǔn)是資源的上次修改時(shí)間 etag是為了應(yīng)對(duì)資源修改時(shí)間可能很頻繁的情況出現(xiàn)的，是基于資源的內(nèi)容計(jì)算出來的值，因此優(yōu)先級(jí)也較高。 如果 Last-Modified 和 ETag 同時(shí)被使用，則要求它們的驗(yàn)證都必須通過才會(huì)返回304，若其中某個(gè)驗(yàn)證沒通過，則服務(wù)器會(huì)按常規(guī)返回資源實(shí)體及200狀態(tài)碼。 協(xié)商緩存與強(qiáng)制緩存的區(qū)別在于強(qiáng)制緩存不需要訪問服務(wù)器，返回結(jié)果是200，協(xié)商緩存需要訪問服務(wù)器，命中協(xié)商緩存的話，返回結(jié)果是304。 步驟：客戶端發(fā)送附帶條件的請(qǐng)求時(shí)（if-matched,if-modified-since,if-none-match,if-range,if-unmodified-since任一個(gè)）服務(wù)器端允許請(qǐng)求訪問資源，但因發(fā)生請(qǐng)求未滿足條件的情況后，直接返回304Modified（服務(wù)器端資源未改變，可直接使用客戶端未過期的緩存）。 補(bǔ)充網(wǎng)頁：expires/cache-control/last-modified/etag詳解以及解釋為何應(yīng)chrome該顯示304卻顯示200：
  http://www.cnblogs.com/vajoy/p/5341664.html
• 307 Temporary Redirect ：臨時(shí)重定向，與 302 的含義類似，但是 307 要求瀏覽器不允許把重定向請(qǐng)求的 POST 方法改成 GET 方法。 關(guān)于303和307：https://blog.csdn.net/liuxingen/article/details/51511034 303、307其實(shí)就是把原來301、302不”合法”的處理動(dòng)作給”合法化”，因?yàn)榘l(fā)現(xiàn)大家都不太遵守，所以干脆就增加一條規(guī)定。 額外功能：也用于hsts跳轉(zhuǎn)。hsts全稱HTTP嚴(yán)格傳輸安全（HTTP Strict Transport Security，縮寫：HSTS） 功能是要求瀏覽器下次訪問該站點(diǎn)時(shí)使用https來訪問，而不再需要先是http再轉(zhuǎn)https。這樣可以避免ssl剝離攻擊：即攻擊者在用戶使用http訪問的過程中進(jìn)行攻擊，對(duì)服務(wù)器冒充自己是用戶，在攻擊者和服務(wù)器中使用https訪問，在用戶和服務(wù)器中使用http訪問。具體使用方法是在服務(wù)器響應(yīng)頭中添加Strict-Transport-Security，可以設(shè)置 max-age。

4XX 客戶端錯(cuò)誤

• 400 Bad Request ：請(qǐng)求報(bào)文中存在語法錯(cuò)誤。提交json時(shí)，如果json格式有問題，接收端接收json，也會(huì)出現(xiàn)400 bad request。比如常見的json串，數(shù)組不應(yīng)該有",但是有"了。
• 401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC 認(rèn)證、DIGEST 認(rèn)證）。如果之前已進(jìn)行過一次請(qǐng)求，則表示用戶認(rèn)證失敗。
• 403 Forbidden ：請(qǐng)求被拒絕，服務(wù)器端沒有必要給出拒絕的詳細(xì)理由。
• 404 Not Found
• 405 method not allowed
  問題原因：請(qǐng)求的方式（get、post、delete）方法與后臺(tái)規(guī)定的方式不符合。比如： 后臺(tái)方法規(guī)定的請(qǐng)求方式只接受get，如果用post請(qǐng)求，就會(huì)出現(xiàn) 405 method not allowed的提示
• 408 請(qǐng)求超時(shí)

5XX 服務(wù)器錯(cuò)誤

• 500： Internal Server Error ：服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤。
• 502：Bad Gateway：進(jìn)程響應(yīng)的內(nèi)容是nginx無法理解的響應(yīng)
• 503 Service Unavilable ：服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無法處理請(qǐng)求。（瞬時(shí)請(qǐng)求量過大）
• 504：Gateway Time-out：進(jìn)程阻塞超過nginx的時(shí)間閾值返回504
• 505：不支持該http版本

Http1.0/1.1/2.0

參考：

1. https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A
2. https://github.com/CyC2018/Interview-Notebook/blob/master/notes/HTTP.md

1.1相比1.0

長連接和流水線（Pipelining）處理

HTTP 1.1支持長連接（PersistentConnection）和管線化（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。

如果要斷開 TCP 連接，需要由客戶端或者服務(wù)器端提出斷開，使用 Connection : close

在HTTP1.1中默認(rèn)開啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)。

Host頭處理/虛擬主機(jī)

在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。（Host頭域指定請(qǐng)求資源的Intenet主機(jī)和端口號(hào)，必須表示請(qǐng)求url的原始服務(wù)器或網(wǎng)關(guān)的位置。）

• 在http 1.1中不能缺失host字段,如果缺失, 服務(wù)器返回400 bad request，http1.1中不能缺失host字段，但host字段可以是空值。
• 在http 1.0中可以缺失host字段。

支持分塊傳輸編碼

HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

另一種解釋：可以把數(shù)據(jù)分割成多塊，讓瀏覽器逐步顯示頁面。

錯(cuò)誤通知的管理/新增狀態(tài)碼

在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如：

• 409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；
• 410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

緩存處理（協(xié)商緩存）

在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)。

HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

新增緩存處理指令 max-age

支持同時(shí)打開多個(gè) TCP 連接

新增狀態(tài)碼 100

2.0相比1.1

https://mp.weixin.qq.com/s/NMhNVDP47npMqx5ruVy43w

HTTP/1.x 缺陷

HTTP/1.x 實(shí)現(xiàn)簡單是以犧牲性能為代價(jià)的：

• 客戶端需要使用多個(gè)連接才能實(shí)現(xiàn)并發(fā)和縮短延遲；
• 不會(huì)壓縮請(qǐng)求和響應(yīng)首部，從而導(dǎo)致不必要的網(wǎng)絡(luò)流量；
• 不支持有效的資源優(yōu)先級(jí)，致使底層 TCP 連接的利用率低下。

二進(jìn)制分幀層

HTTP/2.0 將報(bào)文分成 HEADERS 幀和 DATA 幀，它們都是二進(jìn)制格式的。

在通信過程中，只會(huì)有一個(gè) TCP 連接存在，它承載了任意數(shù)量的雙向數(shù)據(jù)流（Stream）。

• 一個(gè)數(shù)據(jù)流（Stream）都有一個(gè)唯一標(biāo)識(shí)符和可選的優(yōu)先級(jí)信息，用于承載雙向信息。
• 消息（Message）是與邏輯請(qǐng)求或響應(yīng)對(duì)應(yīng)的完整的一系列幀。
• 幀（Frame）是最小的通信單位，來自不同數(shù)據(jù)流的幀可以交錯(cuò)發(fā)送，然后再根據(jù)每個(gè)幀頭的數(shù)據(jù)流標(biāo)識(shí)符重新組裝。

在這里插入圖片描述

和1.1區(qū)別在于：

• HTTP1.x的解析是基于文本。基于文本協(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多
• 二進(jìn)制則不同，只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯。

在這里插入圖片描述

在這里插入圖片描述

二進(jìn)制分幀：多路復(fù)用（MultiPlexing）

即連接共享，即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面。

• 單連接多資源的方式，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大；
• 由于減少TCP 慢啟動(dòng)時(shí)間，提高傳輸?shù)乃俣取?/strong>

HTTP2.0的多路復(fù)用和HTTP1.X中的長連接復(fù)用有什么區(qū)別？

關(guān)鍵點(diǎn)：一個(gè)是串行，一個(gè)是并行，一個(gè)阻塞不影響其他request。

header壓縮

如上文中所言，對(duì)前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

在這里插入圖片描述

在這里插入圖片描述

服務(wù)端推送（server push）

同SPDY一樣，HTTP2.0也具有server push功能。

在這里插入圖片描述

在這里插入圖片描述

SPYD相比1.1

多路復(fù)用

針對(duì)HTTP高延遲的問題，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）。多路復(fù)用通過多個(gè)請(qǐng)求stream共享一個(gè)tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時(shí)提高了帶寬的利用率。

請(qǐng)求優(yōu)先級(jí)（request prioritization）

多路復(fù)用帶來一個(gè)新的問題是，在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí)，這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁內(nèi)容。

header壓縮

前面提到HTTP1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。

服務(wù)端推送（server push）

采用了SPDY的網(wǎng)頁，例如我的網(wǎng)頁有一個(gè)sytle.css的請(qǐng)求，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)，服務(wù)端會(huì)將sytle.js的文件推送給客戶端，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到，不用再發(fā)請(qǐng)求了。

基于HTTPS的加密協(xié)議傳輸

大大提高了傳輸數(shù)據(jù)的可靠性。

HTTP2.0和SPDY的區(qū)別

• HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用 HTTPS
• HTTP2.0 消息頭的壓縮算法采用 HPACK http://http2.github.io/http2-spec/compression.html
• SPDY 消息頭的壓縮算法采用 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE

HTTPs

HTTPS和HTTP的區(qū)別主要如下：

1、https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

3、用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證、完整性保護(hù)的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。
　　
　　

HTTP 有以下安全性問題：

• 內(nèi)容可能會(huì)被竊聽；
• 通信方的身份有可能遭遇偽裝；
• 報(bào)文有可能遭篡改。

HTTPs 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是說 HTTPs 使用了隧道進(jìn)行通信。

隧道：它是將原始IP包（其報(bào)頭包含原始發(fā)送者和最終目的地）封裝在另一個(gè)數(shù)據(jù)包（稱為封裝的IP包）的數(shù)據(jù)凈荷中進(jìn)行傳輸。使用隧道的原因是在不兼容的網(wǎng)絡(luò)上傳輸數(shù)據(jù)，或在不安全網(wǎng)絡(luò)上提供一個(gè)安全路徑。

通過使用 SSL，HTTPs 具有了：

加密（防竊聽）、認(rèn)證（防偽裝）和完整性保護(hù)（防篡改）

在這里插入圖片描述

HTTPs認(rèn)證

請(qǐng)看下面加黑字體是重點(diǎn)：

在這里插入圖片描述

• 服務(wù)方 S 向第三方機(jī)構(gòu)CA提交公鑰、組織信息、個(gè)人信息(域名)等信息并申請(qǐng)認(rèn)證；
• CA 通過線上、線下等多種手段驗(yàn)證申請(qǐng)者提供信息的真實(shí)性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等；
• 如信息審核通過，CA 會(huì)向申請(qǐng)者簽發(fā)認(rèn)證文件-證書。
  簽名的產(chǎn)生算法：首先，使用散列函數(shù)計(jì)算公開的明文信息的信息摘要，然后，采用 CA 的私鑰對(duì)信息摘要進(jìn)行簽名；

客戶端：

• 客戶端 C 向服務(wù)器 S 發(fā)出請(qǐng)求時(shí)，S 返回證書文件；
• 客戶端 C 讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計(jì)算得到信息摘要，然后，利用對(duì)應(yīng) CA 的公鑰解密簽名數(shù)據(jù)，
• 對(duì)比證書的信息摘要（明文的信息摘要和簽名解密后的一致），如果一致，則可以確認(rèn)證書的合法性，即公鑰合法；
• 客戶端然后驗(yàn)證證書相關(guān)的域名信息、有效時(shí)間等信息；
• 客戶端會(huì)內(nèi)置信任 CA 的證書信息(包含公鑰)，如果CA不被信任，則找不到對(duì)應(yīng) CA 的證書，證書也會(huì)被判定非法。

在這個(gè)過程注意幾點(diǎn)：

• 1.申請(qǐng)證書不需要提供私鑰，確保私鑰永遠(yuǎn)只能服務(wù)器掌握；
• 2.證書的合法性仍然依賴于非對(duì)稱加密算法，證書主要是增加了服務(wù)器信息以及簽名；
• 3.內(nèi)置 CA 對(duì)應(yīng)的證書稱為根證書，頒發(fā)者和使用者相同，自己為自己簽名，即自簽名證書；
• 4.證書=網(wǎng)站公鑰+申請(qǐng)者與頒發(fā)者信息+簽名；

HTTPs認(rèn)證后的傳輸

HTTPs 采用混合的加密機(jī)制，使用公開密鑰加密用于傳輸對(duì)稱密鑰來保證安全性，之后使用對(duì)稱密鑰加密進(jìn)行通信來保證效率。（下圖中的 Session Key 就是對(duì)稱密鑰）

在這里插入圖片描述

完整性保護(hù)

SSL 提供報(bào)文摘要功能來進(jìn)行完整性保護(hù)。

HTTP 也提供了 MD5 報(bào)文摘要功能，但是卻不是安全的。例如報(bào)文內(nèi)容被篡改之后，同時(shí)重新計(jì)算 MD5 的值，通信接收方是無法意識(shí)到發(fā)生篡改。

HTTPs 的報(bào)文摘要功能之所以安全，是因?yàn)樗Y(jié)合了加密和認(rèn)證這兩個(gè)操作。試想一下，加密之后的報(bào)文，遭到篡改之后，也很難重新計(jì)算報(bào)文摘要，因?yàn)闊o法輕易獲取明文。

HTTPs 的缺點(diǎn)

• 因?yàn)樾枰M(jìn)行加密解密等過程，因此速度會(huì)更慢；
• 需要支付證書授權(quán)的高費(fèi)用。

GET 和 POST 的區(qū)別

作用

GET 用于獲取資源，而 POST 用于傳輸實(shí)體主體。

參數(shù)

• GET 的傳參方式相比于 POST 安全性較差，因?yàn)?GET 傳的參數(shù)在 URL 中是可見的，可能會(huì)泄露私密信息。
• 并且 GET 只支持 ASCII 字符，因此 GET 的參數(shù)中如果存在中文等字符就需要先進(jìn)行編碼，例如中文會(huì)轉(zhuǎn)換為%E4%B8%AD%E6%96%87，而空格會(huì)轉(zhuǎn)換為%20。POST 支持標(biāo)準(zhǔn)字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

• 不能因?yàn)?POST 參數(shù)存儲(chǔ)在實(shí)體主體中就認(rèn)為它的安全性更高，因?yàn)檎諛涌梢酝ㄟ^一些抓包工具（Fiddler）查看。

安全

安全的 HTTP 方法不會(huì)改變服務(wù)器狀態(tài)，也就是說它只是可讀的。GET 方法是安全的，而 POST 卻不是

因?yàn)?POST 的目的是傳送實(shí)體主體內(nèi)容，這個(gè)內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個(gè)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫中，因此狀態(tài)也就發(fā)生了改變。

安全的方法除了 GET 之外還有：HEAD、OPTIONS。

不安全的方法除了 POST 之外還有 PUT、DELETE。

冪等性

冪等的 HTTP 方法，同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。

GET，HEAD，PUT 和 DELETE 等方法都是冪等的，

而POST 方法不是。所有的安全方法也都是冪等的。

可緩存

• 請(qǐng)求報(bào)文的 HTTP 方法本身是可緩存的，包括 GET 和 HEAD
• 但是 PUT 和 DELETE 不可緩存，POST 在多數(shù)情況下不可緩存的。

XMLHttpRequest

為了闡述 POST 和 GET 的另一個(gè)區(qū)別，需要先了解 XMLHttpRequest：

XMLHttpRequest 是一個(gè) API，它為客戶端提供了在客戶端和服務(wù)器之間傳輸數(shù)據(jù)的功能。它提供了一個(gè)通過 URL 來獲取數(shù)據(jù)的簡單方式，并且不會(huì)使整個(gè)頁面刷新。這使得網(wǎng)頁只更新一部分頁面而不會(huì)打擾到用戶。XMLHttpRequest 在 AJAX 中被大量使用。

在使用 XMLHttpRequest 的 POST 方法時(shí)，瀏覽器會(huì)先發(fā)送 Header 再發(fā)送 Data。

但并不是所有瀏覽器會(huì)這么做，例如火狐就不會(huì)。而 GET 方法 Header 和 Data 會(huì)一起發(fā)送。

關(guān)注我

我是一名后端開發(fā)工程師。主要關(guān)注后端開發(fā)，數(shù)據(jù)安全，網(wǎng)絡(luò)爬蟲，物聯(lián)網(wǎng)，邊緣計(jì)算等方向，歡迎交流。

各大平臺(tái)都可以找到我

• Github：@qqxx6661
• CSDN：@Rude3Knife
• 知乎：@Zhendong
• 簡書：@蠻三刀把刀
• 掘金：@蠻三刀把刀

原創(chuàng)博客主要內(nèi)容

• Java知識(shí)點(diǎn)復(fù)習(xí)全手冊(cè)
• Leetcode算法題解析
• 劍指offer算法題解析
• SpringBoot菜鳥入門實(shí)戰(zhàn)系列
• SpringCloud菜鳥入門實(shí)戰(zhàn)系列
• 爬蟲相關(guān)技術(shù)文章
• 后端開發(fā)相關(guān)技術(shù)文章
• 逸聞趣事/好書分享/個(gè)人興趣

個(gè)人公眾號(hào)：后端技術(shù)漫談

如果文章對(duì)你有幫助，不妨收藏起來并轉(zhuǎn)發(fā)給您的朋友們~

下文章來源于一口LINUX

我是程序員小賤

從面試出發(fā)，解剖各個(gè)知識(shí)點(diǎn)，讓我們向上成長！這里除了學(xué)習(xí)，還有音樂，生活攝影，籃球等，期待你的加入！

本文將從以下幾個(gè)方面進(jìn)行分享。其中包括HTTP發(fā)展史，HTTP緩存代理機(jī)制，常用的web攻擊，HTTP和HTTPS的流量識(shí)別，網(wǎng)絡(luò)協(xié)議學(xué)習(xí)的工具推薦以及高頻HTTP與HTTPS的高頻面試題題解等，開工。

提綱

1989年，蒂姆·伯納斯 - 李（Tim Berners-Lee）在論文中提出可以在互聯(lián)網(wǎng)上構(gòu)建超鏈接文檔，并提出了三點(diǎn).

URI：統(tǒng)一資源標(biāo)識(shí)符。互聯(lián)網(wǎng)的唯一ID

HTML：超文本文檔

HTTP:傳輸超文本的文本傳輸協(xié)議

1 HTTP應(yīng)用在哪兒

學(xué)習(xí)一門知識(shí)，采用五分鐘時(shí)間看看這個(gè)知識(shí)是干啥的可能會(huì)更加有目的性。HTTP可謂無處不在，這里例舉出幾個(gè)。

HTTP應(yīng)用場景

2 HTTP是什么

HTTP(hypertext transport protocol)翻譯過來為"超文本傳輸協(xié)議"，文本可以理解為簡單的字符文字組合，也可以理解為更為復(fù)雜的音頻或者圖像等。那么將這個(gè)詞語拆分為三個(gè)部分。

超文本傳輸協(xié)議

"超文本"和"文本"相比多了一個(gè)字"超"，這樣看來比文本豐富，因?yàn)樗梢詫⒍喾N文本/圖像等進(jìn)行混合，更重要的是可以從一個(gè)文本跳轉(zhuǎn)到另一個(gè)文本(文本連接)。

"傳輸"，傳輸?shù)倪^程中需要溝通，溝通即可能一對(duì)一溝通也可能一對(duì)多溝通(進(jìn)行內(nèi)容協(xié)商)，無論怎么樣，參加溝通的人數(shù)>1，想盡一切一切辦法更快更好的完成相應(yīng)的任務(wù)。

"協(xié)議"，無規(guī)矩不成方圓，做機(jī)密項(xiàng)目之前需要簽署保密協(xié)議，找工作要簽"三方協(xié)議"，三方協(xié)議是學(xué)校，公司，和個(gè)人組成的協(xié)議，都是為了讓大家受一定的約束，違反了即有相應(yīng)的懲罰。

三方協(xié)議

3 不同版本的HTTP

HTTP/0.9

當(dāng)時(shí)網(wǎng)絡(luò)資源匱乏，0.9版本相對(duì)簡單，采用純文本格式，且設(shè)置為只讀，所以當(dāng)時(shí)只能使用"Get"的方式從服務(wù)器獲得HTML文檔，響應(yīng)以后則關(guān)閉。如下圖所示

GET /Mysite.html

響應(yīng)中只包含了文檔本身。響應(yīng)內(nèi)容無響應(yīng)頭，無錯(cuò)誤碼，無狀態(tài)碼，可以說是"裸奔"。

<HTML>
Hello world
</HTML>
HTTP/1.0

此時(shí)HTTP/0.9請(qǐng)求過程如下

• 應(yīng)用層的HTTP建立在傳輸層的TCP之上并運(yùn)用TCP可靠性等特性，先三次握手建立連接
• 客戶端請(qǐng)求建立連接(此時(shí)只有GET)
• 服務(wù)端響應(yīng)請(qǐng)求，數(shù)據(jù)以 ASCII 字符流返回給客戶端
• 傳輸完成，斷開連接。

HTTP 0.9

HTTP1.0

隨著時(shí)代的進(jìn)步，僅僅文本的傳輸無法滿足需求，更多情況需要采用圖文的方式才能生動(dòng)的表達(dá)出自己的觀點(diǎn)。隨著1995年開發(fā)出Apache，同時(shí)其他的多媒體等技術(shù)發(fā)展迅速，從而進(jìn)一步的促使HTTP新功能的出現(xiàn)。HTTP1.0在1996年誕生，增加了一下幾個(gè)方面：

• 之前只有Get方法，現(xiàn)在增加Post(加參數(shù))，Head方法
• 加入?yún)f(xié)議版本號(hào)，同時(shí)添加文件處理類型
• 加入HTTP Header，讓HTTP處理請(qǐng)求更加靈活
• 增加響應(yīng)狀態(tài)碼，標(biāo)記出錯(cuò)的原因
• 提供國際化(不同語言)支持

典型的請(qǐng)求過程

GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)

200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML> 
一個(gè)包含圖片的頁面
  <IMG SRC="/image.gif">
</HTML>

HTTP1.0通信過程

HTTP1.0

HTTP /1.1

1995年是不平凡的一年，網(wǎng)景公司和微軟開啟瀏覽器大戰(zhàn)，誰都想當(dāng)老大。1999年HTTP/1.1發(fā)布并成為標(biāo)準(zhǔn)，寫入RFC，以為以后不管是網(wǎng)關(guān)還是APP等，只要你要使用HTTP，就得遵守這個(gè)標(biāo)準(zhǔn)。

• 繼續(xù)增加了PUT等方法
• 允許持久連接

隨著文件越來越大，圖片等信息越來越復(fù)雜，如果每一次上傳下載文件都需要建立連接斷開連接的過程將增加大量的開銷。為此，提出了持久連接，也就是一次TCP連接可以具有多個(gè)HTTP請(qǐng)求。當(dāng)然持久連接是可選擇的，如果考慮關(guān)閉，只需要使用Connecttion:close關(guān)閉即可。長連接如下圖所示

長連接

• 強(qiáng)制要求Host頭

我們知道，在電商系統(tǒng)中，經(jīng)常會(huì)因?yàn)榇黉N活動(dòng)導(dǎo)致流量飆升，為了緩解流量，其中有種方法即加緩存或者加服務(wù)器。如果是單臺(tái)服務(wù)器負(fù)載過大，數(shù)據(jù)庫可能分庫分表。數(shù)據(jù)結(jié)構(gòu)算法中分而治之方法亦是如此。那么HTTP中，同樣的道理，如果文件太大，就大文件切分為小文件塊發(fā)送。

HTTP /2

HTTP/1.1的出現(xiàn)，幾年間出來大量牛掰的互聯(lián)網(wǎng)公司，發(fā)展實(shí)在是太快，但是HTTP1.1中這幾點(diǎn)成為詬病

• 原因1 TCP自帶慢啟動(dòng)

顧名思義，"慢啟動(dòng)"從0到1循循漸進(jìn)。轎車啟動(dòng)不會(huì)按下按鈕就直接起飛，而是緩慢調(diào)節(jié)到適合的速度。這不是挺好的？為什么會(huì)帶來性能問題呢。我們知道一個(gè)頁面有靜態(tài)數(shù)據(jù)，動(dòng)態(tài)頁面，很多小文件在加載的過程中就會(huì)直接發(fā)起請(qǐng)求，這樣導(dǎo)致太多的請(qǐng)求都會(huì)經(jīng)歷慢啟動(dòng)過程，花費(fèi)時(shí)間太多。

• 原因2 多條TCP連接帶寬競爭

帶寬固定，多條TCP連接同時(shí)發(fā)起競爭帶寬資源，由于各個(gè)TCP連接之間沒有通信機(jī)制，也無法得知哪些資源優(yōu)先級(jí)更高，從而導(dǎo)致想快速下載的資源反而延遲下載。

• 原因3 頭部阻塞

阻塞，在網(wǎng)絡(luò)編程中，我們采用異步，多路復(fù)用(epoll)方式盡量讓cpu少等待多干事。在HTTP1.1中，雖然大家共用了一條TCP通道，但是第一個(gè)請(qǐng)求沒有結(jié)束，第二請(qǐng)求就可能阻塞等待，也就是說不能同時(shí)發(fā)送接收數(shù)據(jù)。那么一個(gè)網(wǎng)頁很多數(shù)據(jù)文件，如果能夠同時(shí)發(fā)出請(qǐng)求，讓部分?jǐn)?shù)據(jù)文件能夠得到響應(yīng)并預(yù)處理，這樣就大大的利用了帶寬和cpu的資源。基于這些因素，在HTTP2中出現(xiàn)了新的方案

如何解決頭部阻塞呢？

HTTP是一問一答的模式，大家都在這個(gè)隊(duì)列排隊(duì)導(dǎo)致堵塞，那就多個(gè)隊(duì)列并發(fā)進(jìn)行，也就是"對(duì)同一個(gè)域名發(fā)起多個(gè)長連接"。舉個(gè)例子，在火車站排隊(duì)買票的時(shí)候，如果只有一個(gè)窗口可用，大家只能苦等，多開幾個(gè)窗口就可緩解這個(gè)問題。

這個(gè)時(shí)候用戶數(shù) * 并發(fā)數(shù)(上限6-8)已經(jīng)不錯(cuò)得效果，但是互聯(lián)網(wǎng)速度太快，火車站就這么大，窗口也就這么多，怎么辦，建新的火車站進(jìn)行分流(大部分城市都有什么東站 西站)。在這里叫做"域名分片"，使用多個(gè)域名，這些域名指向同一服務(wù)器。

HTTP/3

HTTP/2看似很完美了吧，但是Google輪子哥可不服，其他人在研究HTTP/2的時(shí)候，它們就在琢磨QUIC。那QUIC有啥牛掰的地方呢

QUIC是Google開發(fā)的一個(gè)基于UDP且能像TCP一樣具有可靠性特點(diǎn)的協(xié)議。具備像HTTP/2一樣的應(yīng)用數(shù)據(jù)二進(jìn)制分幀傳輸。其主要解決的問題有兩個(gè)。

1. 進(jìn)一步解決線頭阻塞問題。通過獨(dú)立不同流，讓各個(gè)流之間實(shí)現(xiàn)相互獨(dú)立傳輸，互不干擾
2. 切換網(wǎng)絡(luò)時(shí)的連接保持。wifi和3G/4G經(jīng)常需要來回切換。基于TCP的協(xié)議，會(huì)因?yàn)榫W(wǎng)絡(luò)的切換導(dǎo)致IP地址的改變。而基于UDP的QUIC協(xié)議，及時(shí)切換也可以恢復(fù)之前與服務(wù)器的連接。(這里推薦大家可以去看看MPTCP)

4 HTTP報(bào)文詳解

客戶端與服務(wù)端進(jìn)行交互的信息為報(bào)文。客戶端為請(qǐng)求報(bào)文，服務(wù)端為響應(yīng)報(bào)文。我們先用wireshark抓一個(gè)博客看看

報(bào)文層次結(jié)構(gòu)

GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip

請(qǐng)求報(bào)文

請(qǐng)求報(bào)文

請(qǐng)求報(bào)文通常由三部分組成：

起始行：描述請(qǐng)求或者響應(yīng)的基本信息

頭部字段集合：key-value形式說明報(bào)文

消息正文：實(shí)際傳輸諸如圖片等信息。具體如下圖試試

1 請(qǐng)求方法：一共有八種方法選擇，如下圖所示。采用不同的方法獲取不同的資源

HTTP請(qǐng)求方法詳解

說一下非常常見的幾種請(qǐng)求方法

Get：從服務(wù)器中取資源。可以請(qǐng)求圖片，視頻等

HEAD:和Get類似，但是從服務(wù)器請(qǐng)求的資源不會(huì)返回請(qǐng)求的實(shí)體數(shù)據(jù)，只會(huì)返回響應(yīng)頭

POST/PUT：對(duì)應(yīng)于GET，向服務(wù)器發(fā)送數(shù)據(jù)

2 URI

統(tǒng)一資源標(biāo)識(shí)符(Uniform Resource Identifier),嚴(yán)格來說不等于網(wǎng)址，它包含URL和URN，可是URL太出名了以致于URL="網(wǎng)址"。無論開發(fā)，測試運(yùn)維配置都離不開URI,所以好好掌握。

網(wǎng)絡(luò)層的IP主要目的是解決路由和尋址。現(xiàn)在的IP地址按照"."分割，總共2的32次方大約42億。對(duì)于計(jì)算機(jī)來說比較方便，但是對(duì)于人類來說還是不容易記憶，此時(shí)出現(xiàn)DNS了，他把IP地址映射為我們平時(shí)常見的"redis.org"，按照"."分割域名，從左到右級(jí)別越高，最右邊為"頂級(jí)域名"。如下圖所示

域名體系

好了，現(xiàn)在TCP提供可靠(數(shù)據(jù)不丟失)且字節(jié)流(數(shù)據(jù)完整性)，而且也有方便我們記憶的域名，但是互聯(lián)網(wǎng)資源千萬種，也不知道訪問什么(圖片，文字，視頻一大堆)，這個(gè)時(shí)候URI(統(tǒng)一資源標(biāo)識(shí)符)出現(xiàn)了，那長啥樣？

URI格式

協(xié)議名:HTTP協(xié)議，另外還有ftp等協(xié)議。告知訪問資源時(shí)使用什么協(xié)議。

緊接著是分隔符:"://"

主機(jī)名：標(biāo)記互聯(lián)網(wǎng)主機(jī)，可以是IP也可以是域名，如果不寫端口則使用默認(rèn)端口，例如HTTP為80，HTTPS為443.

登錄認(rèn)證信息：登錄主機(jī)時(shí)的用戶名密碼(不建議，直接告訴了別人你的隱私信息)

主機(jī)名：此處可以是域名也可以是IP，如果不寫端口號(hào)則是默認(rèn)端口。比如HTTP默認(rèn)端口為80，HTTPS默認(rèn)端口為443

資源所在位置：資源在主機(jī)上的位置，使用“/”分隔多級(jí)目錄，在這里是“/en/download.html”。注意，必須"/"開頭

參數(shù)：用"?"開始，表示額外的請(qǐng)求要求。通常使用"key=value"的方式存在，如果多個(gè)"key=value"則使用"&"相連。

看幾個(gè)例子

http://nginx.org/en/download.html

file:///E:/Demo/index/

這里注意是三個(gè)"///"，因?yàn)榍懊?#34;://"作為分隔符，資源路徑按照"/"開頭。

既然規(guī)則這么多，對(duì)于接收方而言需要完成的解析也需要遵守規(guī)則，全球用戶很多使用HTTP，每個(gè)國家地區(qū)所使用語言不同，HTTP為了能對(duì)其進(jìn)行統(tǒng)一處理，引入了URI編碼，方法比較簡單，將非ASCII或者特殊字符全部轉(zhuǎn)換為十六進(jìn)制字節(jié)值，同時(shí)在前面加入"%"。比如空格被轉(zhuǎn)換為"%20","中國"就編碼為"%E4%B8%AD%E5%9B%BD%0A"。

3 請(qǐng)求體

響應(yīng)報(bào)文

響應(yīng)報(bào)文

狀態(tài)行----服務(wù)器響應(yīng)的狀態(tài)

<1> 版本號(hào)：使用的HTTP什么版本

<2> 狀態(tài)碼：不同數(shù)字代表不同的結(jié)果，就如我們?cè)诰幋a時(shí)，通過返回不同的值代表不同的語義。

狀態(tài)碼一共分為5類。

1××：處于中間狀態(tài)，還需后續(xù)操作

2××：成功收到報(bào)文并正確處理

"200 OK"

最常見的成功狀態(tài)碼，表示一切正常，客戶端獲得期許的處理結(jié)果。如果不是Head請(qǐng)求，那么在響應(yīng)頭中通常會(huì)有body數(shù)據(jù)。

"204 No Content"

這個(gè)的含義和"200"很相似，不同之處在于它的響應(yīng)頭中沒有body數(shù)據(jù)。

"206 Partial Content"

是 HTTP 分塊下載或斷點(diǎn)續(xù)傳的基礎(chǔ)，在客戶端發(fā)送“范圍請(qǐng)求”、要求獲取資源的部分?jǐn)?shù)據(jù)時(shí)出現(xiàn)，它與 200 一樣，也是服務(wù)器成功處理了請(qǐng)求，但 body 里的數(shù)據(jù)不是資源的全部，而是其中的一部分。狀態(tài)碼 206 通常還會(huì)伴隨著頭字段“Content-Range”，表示響應(yīng)報(bào)文里 body 數(shù)據(jù)的具體范圍，供客戶端確認(rèn)，例如“Content-Range: bytes 0-99/5000”，意思是此次獲取的是總計(jì) 5000 個(gè)字節(jié)的前 100 個(gè)字節(jié)。

3××：重定向到其他資源位置

"301 Moved Permanently"

“永久重定向”，意思是本地請(qǐng)求的資源以及不存在，使用新的URI再次訪問。

“302 Found”

“Moved Temporarily”，“臨時(shí)重定向”，臨時(shí)則所請(qǐng)求的資源暫時(shí)還在，但是目前需要用另一個(gè)URI訪問。

301 和 302 通過在字段Location中表明需要跳轉(zhuǎn)的URI。兩者最大的不同在于一個(gè)是臨時(shí)改變，一個(gè)是永久改變。舉個(gè)例子，有時(shí)候需要將網(wǎng)站全部升級(jí)為HTTPS，這種永久性改變就需要配置永久的"301"。有時(shí)候晚上更新系統(tǒng)，系統(tǒng)暫時(shí)不可用，可以配置"302"臨時(shí)訪問，此時(shí)不會(huì)做緩存優(yōu)化，第二天還會(huì)訪問原來的地址。

“304 Not Modified”

運(yùn)用于緩存控制。它用于 If-Modified-Since 等條件請(qǐng)求，表示資源未修改，可以理解成“重定向已到緩存的文件”（即“緩存重定向”）。

4××：請(qǐng)求報(bào)文有誤，服務(wù)器無法處理

"400 Bad Request”

通用錯(cuò)誤碼，表示請(qǐng)求報(bào)文有錯(cuò)誤，但是這個(gè)錯(cuò)誤過于籠統(tǒng)。不知道是客戶端還是哪里的錯(cuò)誤，所以在實(shí)際應(yīng)用中，通常會(huì)返回含有明確含義的狀態(tài)碼。

“403 Forbidden”

注意了，這一個(gè)是表示服務(wù)器禁止訪問資源。原因比如涉及到敏感詞匯、法律禁止等。當(dāng)然，如果能讓客戶端有一個(gè)清晰的認(rèn)識(shí)，可以考慮說明拒絕的原因并返回即可。

“404 Not Found”

這可能是我們都知道且都不想看到的狀態(tài)碼之一，它的本意是想要的資源在本地未找到從而無法提供給服務(wù)端，但是現(xiàn)在，只要服務(wù)器"耍脾氣"就會(huì)給你返回 404，而我們也無從得知后面到底是真的未找到，還是有什么別的原因，

"405 Method Not Allowed"

獲取資源的方法好幾種，我們可以對(duì)某些方法進(jìn)行限制。例如不允許 POST 只能 GET；

"406 Not Acceptable"

客戶端資源無法滿足客戶端請(qǐng)求的條件，例如請(qǐng)求需要中文但只有英文；

"408 Request Timeout"

請(qǐng)求超時(shí)，服務(wù)器等待了過長的時(shí)間；

"409 Conflict"：

多個(gè)請(qǐng)求發(fā)生了沖突，可以理解為多線程并發(fā)時(shí)的競態(tài)；

413 Request Entity Too Large：

請(qǐng)求報(bào)文里的 body 太大；

414 Request-URI Too Long：請(qǐng)求行里的 URI 太大；

429 Too Many Requests：客戶端發(fā)送了太多的請(qǐng)求，
通常是由于服務(wù)器的限連策略；

431 Request Header Fields Too Large：請(qǐng)求頭某個(gè)字
段或總體太大；

5××：服務(wù)器錯(cuò)誤，服務(wù)器對(duì)請(qǐng)求出的時(shí)候發(fā)生內(nèi)部錯(cuò)誤。

“500 Internal Server Error”

和400 類似，屬于一個(gè)通用的錯(cuò)誤碼，但是服務(wù)器到底是什么錯(cuò)誤我們不得而知。其實(shí)這是好事，盡量少的將服務(wù)器資源暴露外網(wǎng)，盡量保證服務(wù)器的安全。

“502 Bad Gateway”

通常是服務(wù)器作為網(wǎng)關(guān)或者代理時(shí)返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問后端服務(wù)器時(shí)發(fā)生了錯(cuò)誤，但具體的錯(cuò)誤原因也是不知道的。

“503 Service Unavailable”

表示服務(wù)器當(dāng)前很忙，暫時(shí)無法響應(yīng)服務(wù)，我們上網(wǎng)時(shí)有時(shí)候遇到的“網(wǎng)絡(luò)服務(wù)正忙，請(qǐng)稍后重試”的提示信息就是狀態(tài)碼 503。

503 是一個(gè)“臨時(shí)”的狀態(tài)，

暫時(shí)比較忙，稍后提供服務(wù)。在響應(yīng)報(bào)文中的“Retry-After”字段，指示客戶端可以在多久以后再次嘗試發(fā)送請(qǐng)求。

4 請(qǐng)求體

上面大部分都是涉及到header部分，還有非常重要的body，everybody

頭字段注意事項(xiàng)

<1> 字段名不區(qū)分大小寫，例如“Host”也可以寫成“host”，但首字母大寫的可讀性更好；

<2> 字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不能使用下劃線"_"。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正確的字段名；

<3> 字段名后面必須緊接著“:”，不能有空格，而":"后的字段值前可以有多個(gè)空格；

<4> 字段的順序是沒有意義的，可以任意排列不影響語義；

<5> 字段原則上不能重復(fù)，除非這個(gè)字段本身的語義允許，例如 Set-Cookie。

HTTP的body常常被分為這幾種的類別

<1> text:超文本text/html,純文本text/plain

<2> audio/video:音視頻數(shù)據(jù)

<3> application: 可能是文本，也可能是二進(jìn)制，交給上層應(yīng)用處理

<4> image: 圖像文件。image/png等

但是帶寬一定，數(shù)據(jù)大了通常考慮使用壓縮算法進(jìn)行壓縮，在HTTP中使用Encoding type表示，常用的壓縮方式有下面幾種

<1> gzip:

一種數(shù)據(jù)格式，默認(rèn)且目前僅使用deflate算法壓縮data部分

<2> deflate:

deflate是一種壓縮算法，是huffman編碼的一種加強(qiáng)

<3> br:

br通過變種的LZ77算法、Huffman編碼以及二階文本建模等方式進(jìn)行數(shù)據(jù)壓縮，其他壓縮算法相比，它有著更高的壓塑壓縮效率

使用相應(yīng)的壓縮方法在帶寬一定的情況下確實(shí)有不錯(cuò)的效果，但是gzip等主要針對(duì)文件壓縮效果不錯(cuò)，但是對(duì)視頻就不行了。這個(gè)時(shí)候是不是可以使用數(shù)據(jù)結(jié)構(gòu)中常用的分而治之，大化小再合并的方式呢，

文件拆分

ok，在報(bào)文中使用"Transer-Encoding:chunked"表示，代表body部分?jǐn)?shù)據(jù)是分塊傳輸的。另外在body中存在一個(gè)content-length字段表示body的長度，兩者不能共存，另外很多時(shí)候是流式數(shù)據(jù)，body中沒有指明content-length，這個(gè)時(shí)候一般就是chunked傳輸了。

現(xiàn)在可以通過采用分塊的方式增強(qiáng)帶寬的利用率，那他的編碼規(guī)則如何呢

<1> 每一個(gè)分塊包含長度和數(shù)據(jù)塊

<2> 長度頭按照CRLF結(jié)束

<3> 數(shù)據(jù)塊在長度快后，且最后CRLF結(jié)尾

<4> 使用長度0表示結(jié)束，"0\r\n\r\n"

我們還是看圖加深印象

chunked分塊

分塊解決了咋們一部分問題，但是有的時(shí)候我們想截?cái)喟l(fā)送怎么辦呢。在HTTP中提供了使用字段“Accept - Ranges: bytes”，明確告知客戶端：“我是支持范圍請(qǐng)求的”。那么Range范圍是怎樣的呢，Range從0開始計(jì)算，比如Range:0-5則讀取前6個(gè)字節(jié)，服務(wù)器收到了這個(gè)請(qǐng)求，將如何回應(yīng)呢

<1> 合法性檢查。比如一共只有20字節(jié)，但是請(qǐng)求range：100-200。此時(shí)會(huì)返回416----"范圍請(qǐng)求有誤"

<2> 范圍正常，則返回216，表示請(qǐng)求數(shù)據(jù)知識(shí)一部分

<3> 服務(wù)器端在相應(yīng)投資端增加Content-Range,格式"bytes x-y/length"。

敲黑板：斷點(diǎn)續(xù)傳怎么操作？

<1> 查看服務(wù)器是否支持范圍請(qǐng)求并記錄文件大小

<2> 多個(gè)線程分別負(fù)責(zé)不同的range

<3> 下載同時(shí)記錄進(jìn)度，即使因?yàn)榫W(wǎng)絡(luò)等原因中斷也沒事，Range請(qǐng)求剩余即可

現(xiàn)在我們通過MIME-TYPE和Encoding-type可以知道body部分的類型，下一步將是對(duì)內(nèi)容進(jìn)行協(xié)商。HTTP中，請(qǐng)求體中使用Accept告訴服務(wù)端需要什么類型數(shù)據(jù)(我能處理哪些類型數(shù)據(jù))，響應(yīng)頭中使用Content表明發(fā)送了什么類型數(shù)據(jù)，具體如下圖所示

好了，為了各個(gè)國家民族順利友好的溝通和明確的區(qū)分。HTTP請(qǐng)求頭中使用"type-subtype"，注意此時(shí)分隔符是"-"。比如en-GB表示英式英語，zh-CN表示常用的漢語，那對(duì)于客戶端而言，它通過Accept-Language來標(biāo)記自己可以理解的自然語言，對(duì)應(yīng)的服務(wù)端使用Content-Language表明實(shí)體數(shù)據(jù)使用的語言類型，如下圖所示。

字符集和編碼

Cookie機(jī)制

HTTP是無狀態(tài)、無記憶的，Cookie機(jī)制的出現(xiàn)讓其有記憶功能，是怎么個(gè)實(shí)現(xiàn)呢

Cookie

從上圖我們可以知道Cookie是由瀏覽器負(fù)責(zé)存儲(chǔ)，并不是操作系統(tǒng)負(fù)責(zé)，我們換個(gè)瀏覽器打開同樣的網(wǎng)頁，服務(wù)就認(rèn)不出來了。

Cookie常見的應(yīng)用一個(gè)是身份識(shí)別，一個(gè)是廣告追蹤，比如我們?cè)谠L問網(wǎng)頁視頻或者圖片的時(shí)候，廣告商會(huì)悄悄給我們Cookie打上標(biāo)記，方便做關(guān)聯(lián)分析和行為分析，從而給我推薦一些相關(guān)內(nèi)容。

HTTP代理

之前介紹的都是一問一答的情景，但是在大部分的情況下都會(huì)存在多臺(tái)服務(wù)器進(jìn)行通信服務(wù)。其中比較常見的就是在請(qǐng)求方與應(yīng)答方中間增加一個(gè)中間代理。

代理

代理作為中間位置，相對(duì)請(qǐng)求方為服務(wù)端，相當(dāng)于后端服務(wù)端為請(qǐng)求方。代理常見的功能為負(fù)載均衡。在負(fù)載均衡中需要區(qū)分正向代理與反向代理，其中也就會(huì)涉及調(diào)度算法，比如輪詢，一致性哈希等。

正向代理與反向代理

那么問題來了，代理作為隱藏身份，相當(dāng)于隱藏了真實(shí)的客戶端與服務(wù)端，那在是不是

5 HTTPS

好人占多數(shù)，壞人也不少。總有些要搞壞事，因?yàn)镠TTP是明文，所以需要想辦法保護(hù)明文，從而出現(xiàn)了https。

安全是什么

安全四要素

機(jī)密性

對(duì)信息進(jìn)行保密，只能可信的人可以訪問(讓我想起時(shí)間管理者)。

完整性

數(shù)據(jù)在傳輸過程中內(nèi)容不被"篡改"。雖然機(jī)密性對(duì)數(shù)據(jù)進(jìn)行保密了，但是有上策也有下策(hack)

身份認(rèn)證

證明自己的身份是本人，保證其消息發(fā)給可信的人

不可否認(rèn)

君子一言駟馬難追，說話算數(shù)，說過的話做過的事要有所保證

HTTPS

HTTP和HTTPS

從上圖我們知道HTTPS無非是在傳輸層和應(yīng)用層中間加了一層TLS，正是TLS緊跟當(dāng)代密碼學(xué)的步伐，盡全力的保障用戶的安全。老規(guī)矩，我們用wireshark看看長什么樣子。

TLS

可以看出在交互的過程中多了不少新東西，了解TLS,TLS由SSL握手協(xié)議，SSL修改密碼規(guī)范協(xié)議，SSL警報(bào)協(xié)議，SSL記錄協(xié)議組成。

TLS組成

SSL握手協(xié)議：

相對(duì)于三次握手

記錄協(xié)議

記錄為TLS發(fā)送接收數(shù)據(jù)的基本單位。它的自協(xié)議需要通過記錄協(xié)議發(fā)出。如果多個(gè)紀(jì)錄數(shù)據(jù)則可以一個(gè)TCP包一次性發(fā)出。

警報(bào)協(xié)議

類似HTTP狀態(tài)碼，通過反饋不同的消息進(jìn)行不同的策略。

變更密碼規(guī)范協(xié)議

告訴對(duì)方，從此刻開始，后續(xù)的數(shù)據(jù)將使用加密算法進(jìn)行加密再傳輸。

對(duì)稱加密與非對(duì)稱加密

對(duì)稱加密

對(duì)稱加密，顧名思義，加密方與解密方使用同一鑰匙(秘鑰)。具體一些就是，發(fā)送方通過使用相應(yīng)的加密算法和秘鑰，對(duì)將要發(fā)送的信息進(jìn)行加密；對(duì)于接收方而言，使用解密算法和相同的秘鑰解鎖信息，從而有能力閱讀信息。

對(duì)稱加密

非對(duì)稱加密

在對(duì)稱加密中，發(fā)送方與接收方使用相同的秘鑰。那么在非對(duì)稱加密中則是發(fā)送方與接收方使用的不同的秘鑰。其主要解決的問題是防止在秘鑰協(xié)商的過程中發(fā)生泄漏。比如在對(duì)稱加密中，小藍(lán)將需要發(fā)送的消息加密，然后告訴你密碼是123balala,ok,對(duì)于其他人而言，很容易就能劫持到密碼是123balala。那么在非對(duì)稱的情況下，小藍(lán)告訴所有人密碼是123balala,對(duì)于中間人而言，拿到也沒用，因?yàn)闆]有私鑰。所以，非對(duì)稱密鑰其實(shí)主要解決了密鑰分發(fā)的難題。如下圖

非對(duì)稱加密

其實(shí)我們經(jīng)常都在使用非對(duì)稱加密，比如使用多臺(tái)服務(wù)器搭建大數(shù)據(jù)平臺(tái)hadoop，為了方便多臺(tái)機(jī)器設(shè)置免密登錄，是不是就會(huì)涉及到秘鑰分發(fā)。再比如搭建docker集群也會(huì)使用相關(guān)非對(duì)稱加密算法。

混合加密

非對(duì)稱加密算法，大多數(shù)是從數(shù)學(xué)問題演變而來，運(yùn)算速度較慢。混合加密所謂取長補(bǔ)短。通信過程中使用RSA等解決密鑰交換問題，然后使用隨機(jī)數(shù)產(chǎn)生的在對(duì)稱算法中的會(huì)話密鑰，最后使用加密。對(duì)方使用私鑰解密得到的密文取出會(huì)話秘鑰，這樣就實(shí)現(xiàn)了密鑰交換。

混合加密

通過混淆加密等方式完成了機(jī)密性任務(wù)，作為Hack只需要偽造發(fā)布公鑰或者作為之間人竊聽密文。但是我們知道安全是四要素，還需要保證數(shù)據(jù)的完整性，身份認(rèn)證等。

摘要

摘要算法可以理解為一種特殊的"單向"加密算法，無密鑰，不可逆。在平時(shí)項(xiàng)目中，應(yīng)該大家都是用過MD5，SHA-1。但是在TLS中使用SHA-2。

假設(shè)小A轉(zhuǎn)賬5000給小C，小A加上SHA-2摘要。網(wǎng)站計(jì)算摘要并對(duì)比，如果一致則完整可信。

摘要可信

此時(shí)小B想修改小A給的money，這個(gè)時(shí)候網(wǎng)站計(jì)算摘要就會(huì)發(fā)現(xiàn)不一樣，不可信

摘要不可信

HTTPS請(qǐng)求建立連接過程

HTTP握手過程

注意：

1. 首先通過非對(duì)稱加密建立通信過程
2. 在握手階段，為什么使用3個(gè)隨機(jī)數(shù)，一方面防止「隨機(jī)數(shù) C」被猜出，另一方增加Session key隨機(jī)性
3. Client發(fā)出支持的「對(duì)稱/非對(duì)稱加密」算法
4. server返回選用的「對(duì)稱/非對(duì)稱加密」算法
5. Client對(duì)算法進(jìn)行確認(rèn)
6. Server對(duì)算法進(jìn)行確認(rèn)

根據(jù)wireshak結(jié)果，對(duì)TLS進(jìn)一步剖析。TCP三次握手建立連接，作為禮貌，Client先打招呼"Client Hello"。里面包含了Client的版本號(hào)、所支持的密碼套件和隨機(jī)數(shù)，如下圖所示

Client Hello

Server端表示尊重，回復(fù)"Server Hello",同時(shí)進(jìn)行版本校對(duì)，給出隨機(jī)數(shù)(Server Random)，從Client算法列表中選擇一個(gè)密碼套件，在這里選擇的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。

cipher Suite

這里的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什么意思呢

密碼套件選擇橢圓曲線加RSA、AES、SHA256

雙方通過證書驗(yàn)證身份。因?yàn)楸緳C(jī)服務(wù)器選用了ECDHE算法，為了實(shí)現(xiàn)密鑰交換算法，它會(huì)發(fā)送證書后把橢圓曲線的公鑰（Server Params）連帶"Server Key Exchange"消息發(fā)送出去。

Server Key Exchange

意思是，剛才混合加密套件比較復(fù)雜，給你個(gè)算法參數(shù)，好好記住，別弄丟了。

ServerHelloDone

隨后服務(wù)端回復(fù)"hello done"告知打招呼完畢

打完招呼完畢后，客戶端對(duì)證書進(jìn)行核實(shí)。然后根據(jù)密碼套件也生成橢圓曲線的公鑰，用"Client Key Exchange"消息發(fā)給服務(wù)器

Client Key Exchange

此時(shí)客戶端和服務(wù)端都有了密鑰交換的兩個(gè)參數(shù)(Client Params、ServerParams），然后通過 ECDHE 算法算出了一個(gè)新的值，叫“Pre-Master”

有了主密鑰和會(huì)話密鑰，客戶端發(fā)送“Change Cipher Spec”和“Finished”消息，最后將所有消息加上摘要發(fā)送給服務(wù)器驗(yàn)證。

服務(wù)器同樣發(fā)送“Change Cipher Spec”和“Finished”消息，握手結(jié)束，開始進(jìn)行HTTP請(qǐng)求與響應(yīng)

4 初探域名

我們知道域名的出現(xiàn)讓我們更容易記憶，按照"."分割，越靠近右邊級(jí)別越高。域名本質(zhì)是一個(gè)名字空間系統(tǒng)，采用多級(jí)域名的方式區(qū)分不同的國家，公司等，作為一種身份的標(biāo)識(shí)。

根域名服務(wù)器（Root DNS Server）：管理頂級(jí)域名服務(wù)器，返回“com”“net”“cn”等頂級(jí)域名服務(wù)器的 IP 地址；

頂級(jí)域名服務(wù)器（Top-level DNS Server）：管理各自域名下的權(quán)威域名服務(wù)器，比如
com 頂級(jí)域名服務(wù)器可以返回 apple.com 域名服務(wù)器的 IP 地址；

權(quán)威域名服務(wù)器（Authoritative DNS Server）：管理自己域名下主機(jī)的 IP 地址，比如apple.com 權(quán)威域名服務(wù)器可以返回 www.apple.com 的 IP 地址**

6 HTTP特點(diǎn)小結(jié)

寫到這里，說它簡單是假的，簡單的東西通常更具有擴(kuò)展的可能性。根據(jù)需求的變更，越來越復(fù)雜。

1：靈活且易擴(kuò)展，他的頭部字段很多都是可定制且可擴(kuò)展

2：應(yīng)用廣泛。各個(gè)領(lǐng)域都有涉及。"跨平臺(tái)，跨語言"

3：無狀態(tài)。沒有記憶功能，少功能即少占用資源。另外無狀態(tài)更容易搭建集群，通過負(fù)載均衡將請(qǐng)求轉(zhuǎn)發(fā)到任意一臺(tái)服務(wù)器。缺點(diǎn)是無法支持需要連續(xù)步驟的"事務(wù)"操作。我們知道TCP協(xié)議有11種狀態(tài)，不同狀態(tài)代表通信過程中不同的含義。同樣操作系統(tǒng)中的進(jìn)程也有執(zhí)行，就緒，活動(dòng)阻塞等多種狀態(tài)。但是HTTP全程都是"懵逼"無狀態(tài)。比如小華請(qǐng)求服務(wù)器獲取視頻X，服務(wù)器覺得可行就發(fā)給小華。小華還想獲取視頻Y，這時(shí)服務(wù)器不會(huì)記錄之前的狀態(tài)，也就不知道這兩個(gè)請(qǐng)求是否是同一個(gè)，所以小華還得告訴服務(wù)器自己的身份。

4：明文。優(yōu)點(diǎn)是能讓開發(fā)人員通過wireshark工具更直觀的調(diào)試。缺點(diǎn)即裸奔互聯(lián)網(wǎng)，沒隱私可言。

5:可靠傳輸。HTTP為應(yīng)用層協(xié)議，基于TCP/IP，而TCP為“可靠”傳輸協(xié)議，因此HTTP能在請(qǐng)求應(yīng)答中"可靠"傳輸數(shù)據(jù)。

6：應(yīng)用層協(xié)議。應(yīng)用層協(xié)議很多，其中常用的郵件協(xié)議SMTP，上傳下載文件ftp，默認(rèn)端口22/23，SSH遠(yuǎn)程登錄(XSHELL)。這些應(yīng)用層協(xié)議都太專一，而HTTP通過各種頭部字段，實(shí)體數(shù)據(jù)的組合，并綜合緩存代理等功能，不得不說是網(wǎng)絡(luò)中的冠希哥。

7 HTTP識(shí)別(還原)

這里說的識(shí)別，通過代碼層面(libpcap封裝)實(shí)現(xiàn)HTTP的識(shí)別，也能進(jìn)一步體現(xiàn)TCP/IP協(xié)議棧的分層特性。先看回憶一下IP頭部格式。

IP頭部

注意頭部中的協(xié)議字段，如果此字段值為0x0600則為TCP分組。當(dāng)知道了是TCP分組后，是不是可以通過TCP頭部中端口(80)就可以判斷為HTTP呢，不能的，很多情況都會(huì)使用動(dòng)態(tài)端口的方式進(jìn)行部署。此時(shí)可以通過HTTP中的關(guān)鍵字進(jìn)行判斷。如果為HTTP，再通過頭部字段中的"Content-type"，charset等確認(rèn)文本信息，編碼方式，最后采用解碼算法進(jìn)行還原。

8 HTTPS(密文)識(shí)別

方法一也是比較直接的方法是直接通過抓包工具，插件配置即可。這里想給大家分享另一種思路和在Linux持續(xù)捕包的方法。

• 數(shù)據(jù)集采集

使用python的dpkt庫(pip install dpkt即可)，dpkt庫方便對(duì)每一層協(xié)議進(jìn)行拆解，同時(shí)也能進(jìn)行流的拆分以及特征的提取。下面舉一個(gè)通過無頭瀏覽的方式自動(dòng)化采集流量(ps如果需要較大規(guī)模的流量采集則可以考慮使用docker集群的方式)

Read_pcap

• 根據(jù)所提特征生成npz(實(shí)際上是numpy提供的數(shù)組存儲(chǔ)方式)
• 使用開源skearn庫進(jìn)行模型訓(xùn)練并識(shí)別預(yù)測，此處假設(shè)使用SVM(僅使用默認(rèn)參數(shù))

SVM

• 識(shí)別結(jié)果(參數(shù)進(jìn)行適度調(diào)整定會(huì)更好的效果)

識(shí)別結(jié)果

9 HTTP面試題測試

希望大家看完本文，下面的這些面試是不是可以秒殺了

• Get和Post區(qū)別
• HTTP與HTTPS區(qū)別
• HTTP通信過程
• 游覽器輸入一個(gè)地址。到頁面展示中間經(jīng)歷了哪些步驟？
• cookies機(jī)制和session機(jī)制的區(qū)別：
• HTTP請(qǐng)求報(bào)文與響應(yīng)報(bào)文格式
• 一次完整的HTTP請(qǐng)求所經(jīng)歷的7個(gè)步驟
• HTTP優(yōu)化方案
• 不同版本的HTTP區(qū)別
• HTTP優(yōu)點(diǎn)缺點(diǎn)
• URI和URL的區(qū)別
• 如何判斷是否為http
• HTTP 1.1引入分塊傳輸編碼提供了以下幾點(diǎn)好處
• 長連接與短連接的區(qū)別，以及應(yīng)用場景
• 常見web攻擊
• 站內(nèi)跳轉(zhuǎn)和外部重定向有何區(qū)別
• HTTP的keep-alive是干什么的？
• 關(guān)于Http 2.0 你知道多少？
• 講講304緩存的原理
• HTTP與RPC異同
• 從傳輸協(xié)議來說

RPC既可以基于TCP也可以基于HTTP協(xié)議，但是HTTP通常都是基于HTTP

• 從性能消耗來說

RPC可以基于thrift實(shí)現(xiàn)高效二進(jìn)制傳輸。HTTP大部分通過json實(shí)現(xiàn)，無論從字節(jié)大小還是序列化耗時(shí)都比t'hrift耗時(shí)

• 從負(fù)載均衡來說

RPC基本上自帶負(fù)載均衡策略，而HTTP需要配置Nginx實(shí)現(xiàn)。

天，Google Chrome 103 發(fā)布了，其中包含一系列新功能。 值得注意的功能之一就是HTTP狀態(tài)碼103的引入。順便說一下，http 103狀態(tài)碼跟chrome 103版本不是一回事。

來自Mozilla Developer Network文檔，HTTP 103 Early Hints是信息響應(yīng)狀態(tài)代碼，主要用于與Link標(biāo)頭一起使用，以允許用戶在服務(wù)器仍在準(zhǔn)備響應(yīng)時(shí)開始預(yù)加載資源。HTTP 103 可用于通過使用鏈接 rel=preload 配置 HTTP 標(biāo)頭字段來優(yōu)化頁面速度。

如何工作？

通常，當(dāng)瀏覽器發(fā)送請(qǐng)求時(shí)，服務(wù)器會(huì)立刻接收并處理請(qǐng)求，然后發(fā)送 HTTP 200 OK 響應(yīng)，如下所示。

使用 HTTP 103 Early Hints，頁面渲染速度還有提升空間。

一旦服務(wù)器更新了 HTTP 103，當(dāng)瀏覽器發(fā)送請(qǐng)求時(shí)，如果服務(wù)器知道請(qǐng)求內(nèi)容中需要 style.css 或 script.js 等資源，那么它會(huì)提前用 HTTP 103 Hint（響應(yīng)）提示瀏覽器去預(yù)加載一些內(nèi)容，如下所示。

103提示完成之后，它將向?yàn)g覽器發(fā)送正常的 HTTP 200 OK。當(dāng)瀏覽器預(yù)先加載內(nèi)容時(shí)，此過程將有助于提高頁面渲染速度。

如上所述，此功能需要更新服務(wù)器。請(qǐng)自行查看如何配置對(duì)應(yīng)的Web服務(wù)器來啟用它。

這個(gè)103提示僅適用于 HTTP/2 和 HTTP/3。

它僅支持 200、301、304 響應(yīng)返回碼。

此外，它適用于具有 preconnect 或 preload rel 類型的響應(yīng)鏈接標(biāo)頭。

看下圖的例子，curl了一個(gè)頁面，開始它先返回了103代碼和一些需要preload的資源，這時(shí)候，瀏覽器不需要等待請(qǐng)求完全返回就可以開始加載它們。然后服務(wù)器200正常返回請(qǐng)求的資源，這就是為什么可以提高渲染速度。

結(jié)論

正如您所了解的，HTTP 103 早期提示通過提示瀏覽器預(yù)加載資源來幫助優(yōu)化頁面呈現(xiàn)時(shí)間。