在面試過(guò)程中，HTTP 被提問(wèn)的概率還是比較高的。我搜集了 5 大類 HTTP 面試常問(wèn)的題目，同時(shí)這 5 大類題跟 HTTP 的發(fā)展和演變關(guān)聯(lián)性是比較大的。
圖片來(lái)自 Pexels
下面我將通過(guò)問(wèn)答+圖解由淺入深幫助大家進(jìn)一步的學(xué)習(xí)和理解 HTTP 協(xié)議：
HTTP 基本概念
HTTP 是什么?描述一下，HTTP 是超文本傳輸協(xié)議，也就是HyperText Transfer Protocol。
能否詳細(xì)解釋「超文本傳輸協(xié)議」?HTTP 的名字「超文本協(xié)議傳輸」，它可以拆成三個(gè)部分：
協(xié)議
在生活中，我們也能隨處可見(jiàn)「協(xié)議」，例如：
生活中的協(xié)議，本質(zhì)上與計(jì)算機(jī)中的協(xié)議是相同的，協(xié)議的特點(diǎn):
針對(duì) HTTP 協(xié)議，我們可以這么理解。HTTP 是一個(gè)用在計(jì)算機(jī)世界里的協(xié)議。
它使用計(jì)算機(jī)能夠理解的語(yǔ)言確立了一種計(jì)算機(jī)之間交流通信的規(guī)范(兩個(gè)以上的參與者)，以及相關(guān)的各種控制和錯(cuò)誤處理方式(行為約定和規(guī)范)。
傳輸
所謂的「?jìng)鬏敗?，很好理解，就是把一堆東西從 A 點(diǎn)搬到 B 點(diǎn)，或者從 B 點(diǎn) 搬到 A 點(diǎn)。
別輕視了這個(gè)簡(jiǎn)單的動(dòng)作，它至少包含兩項(xiàng)重要的信息。HTTP 協(xié)議是一個(gè)雙向協(xié)議。
我們?cè)谏暇W(wǎng)沖浪時(shí)，瀏覽器是請(qǐng)求方 A ，百度網(wǎng)站就是應(yīng)答方 B。雙方約定用 HTTP 協(xié)議來(lái)通信，于是瀏覽器把請(qǐng)求數(shù)據(jù)發(fā)送給網(wǎng)站，網(wǎng)站再把一些數(shù)據(jù)返回給瀏覽器，最后由瀏覽器渲染在屏幕，就可以看到圖片、視頻了。
數(shù)據(jù)雖然是在 A 和 B 之間傳輸，但允許中間有中轉(zhuǎn)或接力。就好像第一排的同學(xué)想穿遞紙條給最后一排的同學(xué)，那么傳遞的過(guò)程中就需要經(jīng)過(guò)好多個(gè)同學(xué)(中間人)，這樣的傳輸方式就從「A < --- > B」，變成了「A <-> N <-> M <-> B」。
而在 HTTP 里，需要中間人遵從 HTTP 協(xié)議，只要不打擾基本的數(shù)據(jù)傳輸，就可以添加任意額外的東西。
針對(duì)傳輸，我們可以進(jìn)一步理解了 HTTP。HTTP 是一個(gè)在計(jì)算機(jī)世界里專門(mén)用來(lái)在兩點(diǎn)之間傳輸數(shù)據(jù)的約定和規(guī)范。
超文本
HTTP 傳輸?shù)膬?nèi)容是「超文本」。我們先來(lái)理解「文本」，在互聯(lián)網(wǎng)早期的時(shí)候只是簡(jiǎn)單的字符文字，但現(xiàn)在「文本」，它的涵義已經(jīng)可以擴(kuò)展為圖片、視頻、壓縮包等，在 HTTP 眼里這些都算做「文本」。
再來(lái)理解「超文本」，它就是超越了普通文本的文本，它是文字、圖片、視頻等的混合體最關(guān)鍵有超鏈接，能從一個(gè)超文本跳轉(zhuǎn)到另外一個(gè)超文本。
HTML 就是最常見(jiàn)的超文本了，它本身只是純文字文件，但內(nèi)部用很多標(biāo)簽定義了圖片、視頻等的鏈接，在經(jīng)過(guò)瀏覽器的解釋，呈現(xiàn)給我們的就是一個(gè)文字、有畫(huà)面的網(wǎng)頁(yè)了。
OK，經(jīng)過(guò)了對(duì) HTTP 里這三個(gè)名詞的詳細(xì)解釋，就可以給出比「超文本傳輸協(xié)議」這七個(gè)字更準(zhǔn)確更有技術(shù)含量的答案：HTTP 是一個(gè)在計(jì)算機(jī)世界里專門(mén)在「兩點(diǎn)」之間「?jìng)鬏敗刮淖?、圖片、音頻、視頻等「超文本」數(shù)據(jù)的「約定和規(guī)范」。
那「HTTP 是用于從互聯(lián)網(wǎng)服務(wù)器傳輸超文本到本地瀏覽器的協(xié)議 HTTP」 ，這種說(shuō)法正確嗎?
這種說(shuō)法是不正確的。因?yàn)橐部梢允恰阜?wù)器< -- >服務(wù)器」，所以采用兩點(diǎn)之間的描述會(huì)更準(zhǔn)確。HTTP 常見(jiàn)的狀態(tài)碼，有哪些?
五大類 HTTP 狀態(tài)碼
1xx：1xx 類狀態(tài)碼屬于提示信息，是協(xié)議處理中的一種中間狀態(tài)，實(shí)際用到的比較少。
2xx：2xx 類狀態(tài)碼表示服務(wù)器成功處理了客戶端的請(qǐng)求，也是我們最愿意看到的狀態(tài)。
「200 OK」是最常見(jiàn)的成功狀態(tài)碼，表示一切正常。如果是非 HEAD 請(qǐng)求，服務(wù)器返回的響應(yīng)頭都會(huì)有 body 數(shù)據(jù)。
「204 No Content」也是常見(jiàn)的成功狀態(tài)碼，與 200 OK 基本相同，但響應(yīng)頭沒(méi)有 body 數(shù)據(jù)。
「206 Partial Content」是應(yīng)用于 HTTP 分塊下載或斷電續(xù)傳，表示響應(yīng)返回的 body 數(shù)據(jù)并不是資源的全部，而是其中的一部分，也是服務(wù)器處理成功的狀態(tài)。
3xx：3xx 類狀態(tài)碼表示客戶端請(qǐng)求的資源發(fā)送了變動(dòng)，需要客戶端用新的 URL 重新發(fā)送請(qǐng)求獲取資源，也就是重定向。
「301 Moved Permanently」表示永久重定向，說(shuō)明請(qǐng)求的資源已經(jīng)不存在了，需改用新的 URL 再次訪問(wèn)。
「302 Found」表示臨時(shí)重定向，說(shuō)明請(qǐng)求的資源還在，但暫時(shí)需要用另一個(gè) URL 來(lái)訪問(wèn)。
301 和 302 都會(huì)在響應(yīng)頭里使用字段 Location，指明后續(xù)要跳轉(zhuǎn)的 URL，瀏覽器會(huì)自動(dòng)重定向新的 URL。
「304 Not Modified」不具有跳轉(zhuǎn)的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。
4xx：4xx 類狀態(tài)碼表示客戶端發(fā)送的報(bào)文有誤，服務(wù)器無(wú)法處理，也就是錯(cuò)誤碼的含義。
「400 Bad Request」表示客戶端請(qǐng)求的報(bào)文有錯(cuò)誤，但只是個(gè)籠統(tǒng)的錯(cuò)誤。
「403 Forbidden」表示服務(wù)器禁止訪問(wèn)資源，并不是客戶端的請(qǐng)求出錯(cuò)。
「404 Not Found」表示請(qǐng)求的資源在服務(wù)器上不存在或未找到，所以無(wú)法提供給客戶端。
5xx：5xx 類狀態(tài)碼表示客戶端請(qǐng)求報(bào)文正確，但是服務(wù)器處理時(shí)內(nèi)部發(fā)生了錯(cuò)誤，屬于服務(wù)器端的錯(cuò)誤碼。
「500 Internal Server Error」與 400 類型，是個(gè)籠統(tǒng)通用的錯(cuò)誤碼，服務(wù)器發(fā)生了什么錯(cuò)誤，我們并不知道。
「501 Not Implemented」表示客戶端請(qǐng)求的功能還不支持，類似“即將開(kāi)業(yè)，敬請(qǐng)期待”的意思。
「502 Bad Gateway」通常是服務(wù)器作為網(wǎng)關(guān)或代理時(shí)返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問(wèn)后端服務(wù)器發(fā)生了錯(cuò)誤。
「503 Service Unavailable」表示服務(wù)器當(dāng)前很忙，暫時(shí)無(wú)法響應(yīng)服務(wù)器，類似“網(wǎng)絡(luò)服務(wù)正忙，請(qǐng)稍后重試”的意思。
HTTP 常見(jiàn)字段有哪些?
①Host
客戶端發(fā)送請(qǐng)求時(shí)，用來(lái)指定服務(wù)器的域名。
Host: www.A.com 有了 Host 字段，就可以將請(qǐng)求發(fā)往「同一臺(tái)」服務(wù)器上的不同網(wǎng)站。
②Content-Length 字段
服務(wù)器在返回?cái)?shù)據(jù)時(shí)，會(huì)有 Content-Length 字段，表明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度。
Content-Length: 1000 如上面則是告訴瀏覽器，本次服務(wù)器回應(yīng)的數(shù)據(jù)長(zhǎng)度是 1000 個(gè)字節(jié)，后面的字節(jié)就屬于下一個(gè)回應(yīng)了。
③Connection 字段
Connection 字段最常用于客戶端要求服務(wù)器使用 TCP 持久連接，以便其他請(qǐng)求復(fù)用。
HTTP/1.1 版本的默認(rèn)連接都是持久連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。
Connection: keep-alive 一個(gè)可以復(fù)用的 TCP 連接就建立了，直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段。
④Content-Type 字段
Content-Type 字段用于服務(wù)器回應(yīng)時(shí)，告訴客戶端，本次數(shù)據(jù)是什么格式。
Content-Type: text/html; charset=utf-8 上面的類型表明，發(fā)送的是網(wǎng)頁(yè)，而且編碼是UTF-8。
客戶端請(qǐng)求的時(shí)候，可以使用 Accept 字段聲明自己可以接受哪些數(shù)據(jù)格式。
Accept: */* 上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。
⑤Content-Encoding 字段
Content-Encoding 字段說(shuō)明數(shù)據(jù)的壓縮方法。表示服務(wù)器返回的數(shù)據(jù)使用了什么壓縮格式。
Content-Encoding: gzip 上面表示服務(wù)器返回的數(shù)據(jù)采用了 gzip 方式壓縮，告知客戶端需要用此方式解壓。
客戶端在請(qǐng)求時(shí)，用 Accept-Encoding 字段說(shuō)明自己可以接受哪些壓縮方法。
Accept-Encoding: gzip, deflate GET 與 POST
說(shuō)一下 GET 和 POST 的區(qū)別?Get 方法的含義是請(qǐng)求從服務(wù)器獲取資源，這個(gè)資源可以是靜態(tài)的文本、頁(yè)面、圖片視頻等。
比如，你打開(kāi)我的文章，瀏覽器就會(huì)發(fā)送 GET 請(qǐng)求給服務(wù)器，服務(wù)器就會(huì)返回文章的所有文字及資源。
GET 請(qǐng)求
而POST 方法則是相反操作，它向 URI 指定的資源提交數(shù)據(jù)，數(shù)據(jù)就放在報(bào)文的 body 里。
比如，你在我文章底部，敲入了留言后點(diǎn)擊「提交」(暗示你們留言)，瀏覽器就會(huì)執(zhí)行一次 POST 請(qǐng)求，把你的留言文字放進(jìn)了報(bào)文 body 里，然后拼接好 POST 請(qǐng)求頭，通過(guò) TCP 協(xié)議發(fā)送給服務(wù)器。
POST 請(qǐng)求
GET 和 POST 方法都是安全和冪等的嗎?先說(shuō)明下安全和冪等的概念：
那么很明顯 GET 方法就是安全且冪等的，因?yàn)樗恰钢蛔x」操作，無(wú)論操作多少次，服務(wù)器上的數(shù)據(jù)都是安全的，且每次的結(jié)果都是相同的。
POST 因?yàn)槭恰感略龌蛱峤粩?shù)據(jù)」的操作，會(huì)修改服務(wù)器上的資源，所以是不安全的，且多次提交數(shù)據(jù)就會(huì)創(chuàng)建多個(gè)資源，所以不是冪等的。
HTTP 特性
你知道的 HTTP(1.1) 的優(yōu)點(diǎn)有哪些，怎么體現(xiàn)的?HTTP 最凸出的優(yōu)點(diǎn)是「簡(jiǎn)單、靈活和易于擴(kuò)展、應(yīng)用廣泛和跨平臺(tái)」。
①簡(jiǎn)單
HTTP 基本的報(bào)文格式就是 header + body，頭部信息也是 key-value 簡(jiǎn)單文本的形式，易于理解，降低了學(xué)習(xí)和使用的門(mén)檻。
②靈活和易于擴(kuò)展
HTTP協(xié)議里的各類請(qǐng)求方法、URI/URL、狀態(tài)碼、頭字段等每個(gè)組成要求都沒(méi)有被固定死，都允許開(kāi)發(fā)人員自定義和擴(kuò)充。
同時(shí) HTTP 由于是工作在應(yīng)用層( OSI 第七層)，則它下層可以隨意變化。
HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚至把 TCPP 層換成了基于 UDP 的 QUIC。
③應(yīng)用廣泛和跨平臺(tái)
互聯(lián)網(wǎng)發(fā)展至今，HTTP 的應(yīng)用范圍非常的廣泛，從臺(tái)式機(jī)的瀏覽器到手機(jī)上的各種 APP，從看新聞、刷貼吧到購(gòu)物、理財(cái)、吃雞，HTTP 的應(yīng)用片地開(kāi)花，同時(shí)天然具有跨平臺(tái)的優(yōu)越性。
那它的缺點(diǎn)呢?HTTP 協(xié)議里有優(yōu)缺點(diǎn)一體的雙刃劍，分別是「無(wú)狀態(tài)、明文傳輸」，同時(shí)還有一大缺點(diǎn)「不安全」。
①無(wú)狀態(tài)雙刃劍
無(wú)狀態(tài)的好處，因?yàn)榉?wù)器不會(huì)去記憶 HTTP 的狀態(tài)，所以不需要額外的資源來(lái)記錄狀態(tài)信息，這能減輕服務(wù)器的負(fù)擔(dān)，能夠把更多的 CPU 和內(nèi)存用來(lái)對(duì)外提供服務(wù)。
無(wú)狀態(tài)的壞處，既然服務(wù)器沒(méi)有記憶能力，它在完成有關(guān)聯(lián)性的操作時(shí)會(huì)非常麻煩。
例如登錄→添加購(gòu)物車→下單→結(jié)算→支付，這系列操作都要知道用戶的身份才行。但服務(wù)器不知道這些請(qǐng)求是有關(guān)聯(lián)的，每次都要問(wèn)一遍身份信息。
這樣每操作一次，都要驗(yàn)證信息，這樣的購(gòu)物體驗(yàn)還能愉快嗎?別問(wèn)，問(wèn)就是酸爽!
對(duì)于無(wú)狀態(tài)的問(wèn)題，解法方案有很多種，其中比較簡(jiǎn)單的方式用 Cookie 技術(shù)。
Cookie 通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫(xiě)入 Cookie 信息來(lái)控制客戶端的狀態(tài)。
相當(dāng)于，在客戶端第一次請(qǐng)求后，服務(wù)器會(huì)下發(fā)一個(gè)裝有客戶信息的「小貼紙」，后續(xù)客戶端請(qǐng)求服務(wù)器的時(shí)候，帶上「小貼紙」，服務(wù)器就能認(rèn)得了了。
Cookie 技術(shù)
②明文傳輸雙刃劍
明文意味著在傳輸過(guò)程中的信息，是可方便閱讀的，通過(guò)瀏覽器的 F12 控制臺(tái)或 Wireshark 抓包都可以直接肉眼查看，為我們調(diào)試工作帶了極大的便利性。
但是這正是這樣，HTTP 的所有信息都暴露在了光天化日下，相當(dāng)于信息裸奔。在傳輸?shù)穆L(zhǎng)的過(guò)程中，信息的內(nèi)容都毫無(wú)隱私可言，很容易就能被竊取，如果里面有你的賬號(hào)密碼信息，那你號(hào)沒(méi)了。
③不安全
HTTP 比較嚴(yán)重的缺點(diǎn)就是不安全：
HTTP 的安全問(wèn)題，可以用 HTTPS 的方式解決，也就是通過(guò)引入 SSL/TLS 層，使得在安全上達(dá)到了極致。
那你說(shuō)下 HTTP/1.1 的性能如何?HTTP 協(xié)議是基于 TCP/IP，并且使用了「請(qǐng)求 - 應(yīng)答」的通信模式，所以性能的關(guān)鍵就在這兩點(diǎn)里。
長(zhǎng)連接：早期 HTTP/1.0 性能上的一個(gè)很大的問(wèn)題，那就是每發(fā)起一個(gè)請(qǐng)求，都要新建一次 TCP 連接(三次握手)，而且是串行請(qǐng)求，做了無(wú)畏的 TCP 連接建立和斷開(kāi)，增加了通信開(kāi)銷。
為了解決上述 TCP 連接問(wèn)題，HTTP/1.1 提出了長(zhǎng)連接的通信方式，也叫持久連接。
這種方式的好處在于減少了 TCP 連接的重復(fù)建立和斷開(kāi)所造成的額外開(kāi)銷，減輕了服務(wù)器端的負(fù)載。
持久連接的特點(diǎn)是，只要任意一端沒(méi)有明確提出斷開(kāi)連接，則保持 TCP 連接狀態(tài)。
短連接與長(zhǎng)連接
管道網(wǎng)絡(luò)傳輸：HTTP/1.1 采用了長(zhǎng)連接的方式，這使得管道(pipeline)網(wǎng)絡(luò)傳輸成為了可能。
即可在同一個(gè) TCP 連接里面，客戶端可以發(fā)起多個(gè)請(qǐng)求，只要第一個(gè)請(qǐng)求發(fā)出去了，不必等其回來(lái)，就可以發(fā)第二個(gè)請(qǐng)求出去，可以減少整體的響應(yīng)時(shí)間。
舉例來(lái)說(shuō)，客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送 A 請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出 B 請(qǐng)求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出 A 請(qǐng)求和 B 請(qǐng)求。
管道網(wǎng)絡(luò)傳輸
但是服務(wù)器還是按照順序，先回應(yīng) A 請(qǐng)求，完成后再回應(yīng) B 請(qǐng)求。要是 前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。這稱為「隊(duì)頭堵塞」。
隊(duì)頭阻塞：「請(qǐng)求 - 應(yīng)答」的模式加劇了 HTTP 的性能問(wèn)題。
因?yàn)楫?dāng)順序發(fā)送的請(qǐng)求序列中的一個(gè)請(qǐng)求因?yàn)槟撤N原因被阻塞時(shí)，在后面排隊(duì)的所有請(qǐng)求也一同被阻塞了，會(huì)招致客戶端一直請(qǐng)求不到數(shù)據(jù)，這也就是「隊(duì)頭阻塞」。好比上班的路上塞車。
隊(duì)頭阻塞
總之 HTTP/1.1 的性能一般般，后續(xù)的 HTTP/2 和 HTTP/3 就是在優(yōu)化 HTTP 的性能。
HTTP 與 HTTPS
HTTP 與 HTTPS 有哪些區(qū)別?
HTTPS 解決了 HTTP 的哪些問(wèn)題?HTTP 由于是明文傳輸，所以安全上存在以下三個(gè)風(fēng)險(xiǎn)：
HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協(xié)議。
HTTP 與 HTTPS
可以很好的解決了上述的風(fēng)險(xiǎn)：
可見(jiàn)，只要自身不做「惡」，SSL/TLS 協(xié)議是能保證通信是安全的。
HTTPS 是如何解決上面的三個(gè)風(fēng)險(xiǎn)的?
①混合加密
通過(guò)混合加密的方式可以保證信息的機(jī)密性，解決了竊聽(tīng)的風(fēng)險(xiǎn)。
混合加密
HTTPS 采用的是對(duì)稱加密和非對(duì)稱加密結(jié)合的「混合加密」方式：
采用「混合加密」的方式的原因：
②摘要算法
摘要算法用來(lái)實(shí)現(xiàn)完整性，能夠?yàn)閿?shù)據(jù)生成獨(dú)一無(wú)二的「指紋」，用于校驗(yàn)數(shù)據(jù)的完整性，解決了篡改的風(fēng)險(xiǎn)。
校驗(yàn)完整性
客戶端在發(fā)送明文之前會(huì)通過(guò)摘要算法算出明文的「指紋」，發(fā)送的時(shí)候把「指紋 + 明文」一同加密成密文后，發(fā)送給服務(wù)器，服務(wù)器解密后，用相同的摘要算法算出發(fā)送過(guò)來(lái)的明文，通過(guò)比較客戶端攜帶的「指紋」和當(dāng)前算出的「指紋」做比較，若「指紋」相同，說(shuō)明數(shù)據(jù)是完整的。
③數(shù)字證書(shū)
客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。
這就存在些問(wèn)題，如何保證公鑰不被篡改和信任度?所以這里就需要借助第三方權(quán)威機(jī)構(gòu) CA (數(shù)字證書(shū)認(rèn)證機(jī)構(gòu))，將服務(wù)器公鑰放在數(shù)字證書(shū)(由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)頒發(fā))中，只要證書(shū)是可信的，公鑰就是可信的。
數(shù)字證書(shū)工作流程
通過(guò)數(shù)字證書(shū)的方式保證服務(wù)器公鑰的身份，解決冒充的風(fēng)險(xiǎn)。
HTTPS 是如何建立連接的?其間交互了什么?SSL/TLS 協(xié)議基本流程：
前兩步也就是 SSL/TLS 的建立過(guò)程，也就是握手階段。SSL/TLS 的「握手階段」涉及四次通信，可見(jiàn)下圖：
HTTPS 連接建立過(guò)程
SSL/TLS 協(xié)議建立的詳細(xì)流程：
①ClientHello
首先，由客戶端向服務(wù)器發(fā)起加密通信請(qǐng)求，也就是 ClientHello 請(qǐng)求。
在這一步，客戶端主要向服務(wù)器發(fā)送以下信息：
②SeverHello
服務(wù)器收到客戶端請(qǐng)求后，向客戶端發(fā)出響應(yīng)，也就是 SeverHello。
服務(wù)器回應(yīng)的內(nèi)容有如下內(nèi)容：
③客戶端回應(yīng)
客戶端收到服務(wù)器的回應(yīng)之后，首先通過(guò)瀏覽器或者操作系統(tǒng)中的 CA 公鑰，確認(rèn)服務(wù)器的數(shù)字證書(shū)的真實(shí)性。
如果證書(shū)沒(méi)有問(wèn)題，客戶端會(huì)從數(shù)字證書(shū)中取出服務(wù)器的公鑰，然后使用它加密報(bào)文，向服務(wù)器發(fā)送如下信息：
上面第一項(xiàng)的隨機(jī)數(shù)是整個(gè)握手階段的第三個(gè)隨機(jī)數(shù)，這樣服務(wù)器和客戶端就同時(shí)有三個(gè)隨機(jī)數(shù)，接著就用雙方協(xié)商的加密算法，各自生成本次通信的「會(huì)話秘鑰」。
④服務(wù)器的最后回應(yīng)
服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)(pre-master key)之后，通過(guò)協(xié)商的加密算法，計(jì)算出本次通信的「會(huì)話秘鑰」。
然后，向客戶端發(fā)生最后的信息：
至此，整個(gè) SSL/TLS 的握手階段全部結(jié)束。接下來(lái)，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過(guò)用「會(huì)話秘鑰」加密內(nèi)容。
HTTP/1.1、HTTP/2、HTTP/3 演變
說(shuō)說(shuō) HTTP/1.1 相比 HTTP/1.0 提高了什么性能?
HTTP/1.1 相比 HTTP/1.0 性能上的改進(jìn)：
但 HTTP/1.1 還是有性能瓶頸：
那上面的 HTTP/1.1 的性能瓶頸，HTTP/2 做了什么優(yōu)化?HTTP/2 協(xié)議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
那 HTTP/2 相比 HTTP/1.1 性能上的改進(jìn)：
①頭部壓縮
HTTP/2 會(huì)壓縮頭(Header)如果你同時(shí)發(fā)出多個(gè)請(qǐng)求，他們的頭是一樣的或是相似的，那么，協(xié)議會(huì)幫你消除重復(fù)的分。
這就是所謂的 HPACK 算法：在客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。
②二進(jìn)制格式
HTTP/2 不再像 HTTP/1.1 里的純文本形式的報(bào)文，而是全面采用了二進(jìn)制格式。
頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為幀(frame)：頭信息幀和數(shù)據(jù)幀。
報(bào)文區(qū)別
這樣雖然對(duì)人不友好，但是對(duì)計(jì)算機(jī)非常友好，因?yàn)橛?jì)算機(jī)只懂二進(jìn)制，那么收到報(bào)文后，無(wú)需再將明文的報(bào)文轉(zhuǎn)成二進(jìn)制，而是直接解析二進(jìn)制報(bào)文，這增加了數(shù)據(jù)傳輸?shù)男省?/p>
③數(shù)據(jù)流
HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。
每個(gè)請(qǐng)求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流(Stream)。
每個(gè)數(shù)據(jù)流都標(biāo)記著一個(gè)獨(dú)一無(wú)二的編號(hào)，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號(hào)為奇數(shù)， 服務(wù)器發(fā)出的數(shù)據(jù)流編號(hào)為偶數(shù)。
客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。優(yōu)先級(jí)高的請(qǐng)求，服務(wù)器就先響應(yīng)該請(qǐng)求。
HTT/1 ~ HTTP/2
④多路復(fù)用
HTTP/2 是可以在一個(gè)連接中并發(fā)多個(gè)請(qǐng)求或回應(yīng)，而不用按照順序一一對(duì)應(yīng)。移除了 HTTP/1.1 中的串行請(qǐng)求，不需要排隊(duì)等待，也就不會(huì)再出現(xiàn)「隊(duì)頭阻塞」問(wèn)題，降低了延遲，大幅度提高了連接的利用率。
舉例來(lái)說(shuō)，在一個(gè) TCP 連接里，服務(wù)器收到了客戶端 A 和 B 的兩個(gè)請(qǐng)求，如果發(fā)現(xiàn) A 處理過(guò)程非常耗時(shí)，于是就回應(yīng) A 請(qǐng)求已經(jīng)處理好的部分，接著回應(yīng) B 請(qǐng)求，完成后，再回應(yīng) A 請(qǐng)求剩下的部分。
多路復(fù)用
⑤服務(wù)器推送
HTTP/2 還在一定程度上改善了傳統(tǒng)的「請(qǐng)求 - 應(yīng)答」工作模式，服務(wù)不再是被動(dòng)地響應(yīng)，也可以主動(dòng)向客戶端發(fā)送消息。
舉例來(lái)說(shuō)，在瀏覽器剛請(qǐng)求 HTML 的時(shí)候，就提前把可能會(huì)用到的 JS、CSS 文件等靜態(tài)資源主動(dòng)發(fā)給客戶端，減少延時(shí)的等待，也就是服務(wù)器推送(Server Push，也叫 Cache Push)。
HTTP/2 有哪些缺陷?HTTP/3 做了哪些優(yōu)化?HTTP/2 主要的問(wèn)題在于：多個(gè) HTTP 請(qǐng)求在復(fù)用一個(gè) TCP 連接，下層的 TCP 協(xié)議是不知道有多少個(gè) HTTP 請(qǐng)求的。
所以一旦發(fā)生了丟包現(xiàn)象，就會(huì)觸發(fā) TCP 的重傳機(jī)制，這樣在一個(gè) TCP 連接中的所有的 HTTP 請(qǐng)求都必須等待這個(gè)丟了的包被重傳回來(lái)：
這都是基于 TCP 傳輸層的問(wèn)題，所以 HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP!
HTTP/1 ~ HTTP/3
UDP 發(fā)生是不管順序，也不管丟包的，所以不會(huì)出現(xiàn) HTTP/1.1 的隊(duì)頭阻塞 和 HTTP/2 的一個(gè)丟包全部重傳問(wèn)題。
大家都知道 UDP 是不可靠傳輸?shù)?，但基?UDP 的 QUIC 協(xié)議 可以實(shí)現(xiàn)類似 TCP 的可靠性傳輸：
TCP HTTPS(TLS/1.3) 和 QUIC HTTPS
所以， QUIC 是一個(gè)在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復(fù)用的協(xié)議。
QUIC 是新協(xié)議，對(duì)于很多網(wǎng)絡(luò)設(shè)備，根本不知道什么是 QUIC，只會(huì)當(dāng)做 UDP，這樣會(huì)出現(xiàn)新的問(wèn)題。
所以 HTTP/3 現(xiàn)在普及的進(jìn)度非常的緩慢，不知道未來(lái) UDP 是否能夠逆襲 TCP。
聯(lián)系客服
