How Does The Internet Work ?

假設(shè)有十臺電腦 每個(gè)電腦有9個(gè)插口
那么需要45根網(wǎng)線
太麻煩

如果把這些電腦都連到一臺路由器上
那么只需要10根網(wǎng)線

如果要連接成百上千臺電腦
那就需要路由器連路由器

有點(diǎn)接近互聯(lián)網(wǎng)了

在家里我們會發(fā)現(xiàn)有根線接了進(jìn)來
電話📞
電話也是一種網(wǎng)絡(luò)
為了連接這種網(wǎng)絡(luò)
需要調(diào)制解調(diào)器
就是 modem
可以把網(wǎng)絡(luò)信息變成modem可以處理的信息
反之亦然

所以我們可以 modem 連 modem
為了把信息從我們的網(wǎng)絡(luò)發(fā)到我們想要到達(dá)的地方
需要把網(wǎng)絡(luò)連接到 ISP （運(yùn)營商 互聯(lián)網(wǎng)服務(wù)提供商）
ISP管理這些路由器

所以互聯(lián)網(wǎng)大概就是
PCA - Router - Modem - ISP1（Modem-Router） - ISP2 - ISP3 - Modem - Router - PCB

PCA 要發(fā)給PCB發(fā)信息
那么PCA需要知道PCB的地址
即 IP地址 xxx.xxx.xxx.xxx 例如192.168.1.1

為了好記，用域名來代替他
例 google.com = 172.217.7.14

互聯(lián)網(wǎng)(Internet)是基礎(chǔ)設(shè)施
而網(wǎng)絡(luò)(Web)是建立再這種基礎(chǔ)設(shè)施之上的服務(wù)

Client ----Server
服務(wù)器是存儲網(wǎng)頁、站點(diǎn)、應(yīng)用的計(jì)算機(jī)
當(dāng)Client想要獲取一個(gè)網(wǎng)頁
就從服務(wù)器上下載到客戶端（電腦、手機(jī)）上的瀏覽器顯示

除了客戶端和服務(wù)器
還要了解：

舉個(gè)栗子

你聽說一點(diǎn)點(diǎn)的奶茶好喝，想喝，
但是具體是哪里的一點(diǎn)點(diǎn)呢，這時(shí)候打開地圖（DNS）一查，原來在福建福州啊（IP地址) ，于是下單，買了10杯奶茶，留下了姓名電話地址，并要求發(fā)順豐（HTTP）

讓我們視角轉(zhuǎn)到一點(diǎn)點(diǎn)奶茶店。

為了打包奶茶，在路途上不撒出來，有規(guī)定要先密封好，再用泡沫紙墊著，再用紙箱包著，再用透明膠捆著，再貼上快遞單，快遞單上寫明是什么奶茶，誰發(fā)的，發(fā)給誰，等信息，這大概就是TCP/IP 即定義數(shù)據(jù)如何傳輸?shù)?strong>通信協(xié)議
這一層層打包包裹和一層層拆包裹，因?yàn)橐粋€(gè)包裹要經(jīng)過好幾個(gè)快遞員手，所以數(shù)據(jù)包封裝也是這樣，
從上到下分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層

在數(shù)據(jù)（奶茶）上要加TCP頭部（快遞單 假設(shè)送到順豐公司）、順豐快遞員拿到后 再加上IP頭部（從順豐到村子所在地方）、再加上MAC頭部（到達(dá)家門口），最后的物理層其實(shí)是比特流，物理介質(zhì) 網(wǎng)線

快遞到了家門口，我說是順豐嗎，他說是順豐，這才收下快遞

1、瀏覽器在DNS服務(wù)器上找到存放網(wǎng)頁的服務(wù)器的實(shí)際地址（一點(diǎn)點(diǎn)店的位置）
2、瀏覽器發(fā)HTTP請求信息到服務(wù)器（下單）這條消息，客戶端和服務(wù)器之間傳遞的數(shù)據(jù)都是通過互聯(lián)網(wǎng)使用TCP/IP協(xié)議傳輸?shù)?br /> 3、服務(wù)器同意客戶端的請求后，返回”200 OK“的信息，然后將網(wǎng)頁的文件以數(shù)據(jù)包的形式傳輸?shù)綖g覽器（快遞回來）
4、瀏覽器將數(shù)據(jù)包聚集成完整的網(wǎng)頁然后呈現(xiàn)給你看（奶茶到了家門口）

村子肯定要通路 才能讓快遞進(jìn)來 （ 網(wǎng)絡(luò)連接 web）
村子到福州的路 就像互聯(lián)網(wǎng) 錯綜復(fù)雜

HTTP

1、基本知識

• 是什么？

  超文本傳輸協(xié)議，是一個(gè)在計(jì)算機(jī)世界里專門在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范。兩點(diǎn)不僅是服務(wù)器傳輸超文本到本地瀏覽器，也可以是服務(wù)器<–>服務(wù)器

• 狀態(tài)碼？

  1xx：提示信息，是協(xié)議處理中的中間狀態(tài)，實(shí)際用的比較少

  2xx：服務(wù)器成功處理客戶端的請求，成功碼
  200 OK ：表示一切正常，如果是非HEAD請求，服務(wù)器返回的響應(yīng)頭會有body數(shù)據(jù)
  204 No Content ：與200 OK 基本相同，但是響應(yīng)頭里沒有body數(shù)據(jù)
  206 Partial Content ：應(yīng)用于 HTTP 分塊下載或斷電續(xù)傳，表示響應(yīng)返回的 body 數(shù)據(jù)并不是資源的全部，而是其中的一部分，也是服務(wù)器處理成功的狀態(tài)。

  3xx:需要客戶端用新的URL重新發(fā)送請求獲取資源，也就是重定向
  301 Moved Permanently：永久重定向，說明請求的資源已經(jīng)不存在了，需改用新的 URL 再次訪問
  302 Moved Permanently：臨時(shí)重定向，說明請求的資源還在，但暫時(shí)需要用另一個(gè) URL 來訪問
  301 和 302 都會在響應(yīng)頭里使用字段 Location，指明后續(xù)要跳轉(zhuǎn)的 URL，瀏覽器會自動重定向新的 URL
  304 Not Modified：不具有跳轉(zhuǎn)的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，用于緩存控制。

  4xx ：表示客戶端發(fā)送的報(bào)文有誤，服務(wù)器無法處理，也就是錯誤碼的含義
  400 Bad Request：表示客戶端請求的報(bào)文有錯誤，但只是個(gè)籠統(tǒng)的錯誤。
  403 Forbidden：表示服務(wù)器禁止訪問資源，并不是客戶端的請求出錯
  404 Not Found：表示請求的資源在服務(wù)器上不存在或未找到，所以無法提供給客戶端

  5xx ：表示客戶端請求報(bào)文正確，但是服務(wù)器處理時(shí)內(nèi)部發(fā)生了錯誤，屬于服務(wù)器端的錯誤碼
  500 Internal Server Error：與 400 類型，是個(gè)籠統(tǒng)通用的錯誤碼，服務(wù)器發(fā)生了什么錯誤，我們并不知道。
  501 Not Implemented：表示客戶端請求的功能還不支持，類似“即將開業(yè)，敬請期待”的意思。
  502 Bad Gateway：通常是服務(wù)器作為網(wǎng)關(guān)或代理時(shí)返回的錯誤碼，表示服務(wù)器自身工作正常，訪問后端服務(wù)器發(fā)生了錯誤。
  503 Service Unavailable：表示服務(wù)器當(dāng)前很忙，暫時(shí)無法響應(yīng)服務(wù)器，類似“網(wǎng)絡(luò)服務(wù)正忙，請稍后重試”的意思。

• 常見字段？

  （1）Host 客戶端發(fā)送請求時(shí)，用來指定服務(wù)器的域名
  Host: http://www.A.com
  （2）Content-Length 服務(wù)器在返回?cái)?shù)據(jù)時(shí)，表明本次回應(yīng)的數(shù)據(jù)長度。
  Content-Length: 1000
  （3）Connection客戶端要求服務(wù)器使用 TCP 持久連接，以便其他請求復(fù)用。
  Connection: keep-alive
  （4）Content-Type 服務(wù)器回應(yīng)時(shí)，告訴客戶端，本次數(shù)據(jù)是什么格式。
  Content-Type: text/html; charset=utf-8
  客戶端請求的時(shí)候，可以使用 Accept 字段聲明自己可以接受哪些數(shù)據(jù)格式。Accept: */ *表示接受所有數(shù)據(jù)格式
  （5）Content-Encoding 服務(wù)器返回的數(shù)據(jù)使用了什么壓縮格式
  Content-Encoding: gzip
  Accept-Encoding: gzip, deflate

2、GET POST

• 區(qū)別 ？
  GET Get 方法的含義是請求從服務(wù)器獲取資源，這個(gè)資源可以是靜態(tài)的文本、頁面、圖片視頻等
  POST 向 URI 指定的資源提交數(shù)據(jù)(比如留言 瀏覽器就會執(zhí)行一次POST請求)，數(shù)據(jù)就放在報(bào)文的 body 里，通過TCP協(xié)議發(fā)送到服務(wù)器

• 都是安全和冪等的嗎？
  在 HTTP 協(xié)議里，所謂的「安全」是指請求方法不會「破壞」服務(wù)器上的資源。
  所謂的「冪等」，意思是多次執(zhí)行相同的操作，結(jié)果都是「相同」的。

  那么很明顯 GET 方法就是安全且冪等的，因?yàn)樗恰钢蛔x」操作，無論操作多少次，服務(wù)器上的數(shù)據(jù)都是安全的，且每次的結(jié)果都是相同的。
  POST 因?yàn)槭恰感略龌蛱峤粩?shù)據(jù)」的操作，會修改服務(wù)器上的資源，所以是不安全的，且多次提交數(shù)據(jù)就會創(chuàng)建多個(gè)資源，所以不是冪等的。

3、HTTP特性

• 優(yōu)點(diǎn) HTTP 最凸出的優(yōu)點(diǎn)是「簡單、靈活和易于擴(kuò)展、應(yīng)用廣泛和跨平臺」

• 缺點(diǎn) 無狀態(tài)、明文傳輸，同時(shí)還有一大缺點(diǎn)「不安全」
  無狀態(tài)的好處，因?yàn)榉?wù)器不會去記憶 HTTP 的狀態(tài)，所以不需要額外的資源來記錄狀態(tài)信息，這能減輕服務(wù)器的負(fù)擔(dān)，能夠把更多的 CPU 和內(nèi)存用來對外提供服務(wù)。
  無狀態(tài)的壞處，既然服務(wù)器沒有記憶能力，它在完成有關(guān)聯(lián)性的操作時(shí)會非常麻煩
  無狀態(tài)的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術(shù)
  Cookie 通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)
  明文傳輸?shù)?strong>好處 ，在傳輸過程中的信息，是可方便閱讀的，通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接肉眼查看，為我們調(diào)試工作帶了極大的便利性。
  明文傳輸?shù)?strong>壞處，HTTP 的所有信息都暴露在了光天化日下，相當(dāng)于信息裸奔。在傳輸?shù)穆L的過程中，信息的內(nèi)容都毫無隱私可言，很容易就能被竊取，如果里面有你的賬號密碼信息，那你號沒了。
  不安全：
  通信使用明文（不加密），內(nèi)容可能會被竊聽。比如，賬號信息容易泄漏，那你號沒了。
  不驗(yàn)證通信方的身份，因此有可能遭遇偽裝。比如，訪問假的淘寶、拼多多，那你錢沒了。
  無法證明報(bào)文的完整性，所以有可能已遭篡改。比如，網(wǎng)頁上植入垃圾廣告，視覺污染，眼沒了。
  HTTP 的安全問題，可以用HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層

• 性能？
  HTTP 協(xié)議是基于 TCP/IP，并且使用了「請求 - 應(yīng)答」的通信模式，所以性能的關(guān)鍵就在這兩點(diǎn)里
  早期 HTTP/1.0 性能上的一個(gè)很大的問題，那就是每發(fā)起一個(gè)請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，增加了通信開銷
  為了解決上述 TCP 連接問題，HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。
  管道網(wǎng)絡(luò)傳輸 即可在同一個(gè) TCP 連接里面，客戶端可以發(fā)起多個(gè)請求
  以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送 A 請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出 B 請求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出 A 請求和 B 請求。
  服務(wù)器還是按照順序，先回應(yīng) A 請求，完成后再回應(yīng) B 請求。要是 前面的回應(yīng)特別慢，后面就會有許多請求排隊(duì)等著。這稱為「隊(duì)頭堵塞」
  「請求 - 應(yīng)答」的模式加劇了 HTTP 的性能問題
  總之 HTTP/1.1 的性能一般般，后續(xù)的 HTTP/2 和 HTTP/3 就是在優(yōu)化 HTTP 的性能

4、HTTP HTTPS

• 區(qū)別 ？
  HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，存在安全風(fēng)險(xiǎn)的問題。
  HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 之間加入了 SSL/TLS 安全協(xié)議，使得報(bào)文能夠加密傳輸。
  HTTP 連接建立相對簡單， TCP 三次握手之后便可進(jìn)行 HTTP 的報(bào)文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進(jìn)行 SSL/TLS 的握手過程，才可進(jìn)入加密報(bào)文傳輸。
  HTTP 的端口號是 80，HTTPS 的端口號是 443
  HTTPS 協(xié)議需要向 CA（證書權(quán)威機(jī)構(gòu)）申請數(shù)字證書，來保證服務(wù)器的身份是可信的。

• HTTPS解決了HTTP什么問題 ？
  HTTP 由于是明文傳輸，所以安全上存在以下三個(gè)風(fēng)險(xiǎn)：
  竊聽風(fēng)險(xiǎn)，比如通信鏈路上可以獲取通信內(nèi)容，用戶號容易沒。
  篡改風(fēng)險(xiǎn)，比如強(qiáng)制入垃圾廣告，視覺污染，用戶眼容易瞎。
  偽裝風(fēng)險(xiǎn)，比如冒充淘寶網(wǎng)站，用戶錢容易沒。
  HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協(xié)議
  信息加密：交互信息無法被竊取
  校驗(yàn)機(jī)制：無法篡改通信內(nèi)容，篡改了就不能正常顯示，但百度「競價(jià)排名」依然可以搜索垃圾廣告。
  身份證書：證明淘寶是真的淘寶網(wǎng)

• HTTPS如何解決HTTP不安全問題的 ？
  HTTPS 采用的是對稱加密和非對稱加密結(jié)合的「混合加密」方式，解決了竊聽的風(fēng)險(xiǎn)
  非對稱加密密鑰，對稱加密數(shù)據(jù)

  摘要算法的方式來實(shí)現(xiàn)完整性，它能夠?yàn)閿?shù)據(jù)生成獨(dú)一無二的「指紋」，指紋用于校驗(yàn)數(shù)據(jù)的完整性，解決了篡改的風(fēng)險(xiǎn)
  
  客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。
  這就存在些問題，如何保證公鑰不被篡改和信任度？
  所以這里就需要借助第三方權(quán)威機(jī)構(gòu) CA （數(shù)字證書認(rèn)證機(jī)構(gòu)），將服務(wù)器公鑰放在數(shù)字證書（由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)）中，只要證書是可信的，公鑰就是可信的。

  通過數(shù)字證書的方式保證服務(wù)器公鑰的身份，解決冒充的風(fēng)險(xiǎn)
  

• HTTPS如何建立連接，交互了什么 ？
  SSL/TLS 協(xié)議基本流程：
  客戶端向服務(wù)器索要并驗(yàn)證服務(wù)器的公鑰。
  雙方協(xié)商生產(chǎn)「會話秘鑰」。
  雙方采用「會話秘鑰」進(jìn)行加密通信。

  前兩步是 SSL/TLS 的建立過程，也就是握手階段，四次通信
  ClientHello 客戶端向服務(wù)器發(fā)起加密通信請求
  （1）客戶端支持的 SSL/TLS 協(xié)議版本，如 TLS 1.2 版本。
  （2）客戶端生產(chǎn)的隨機(jī)數(shù)（Client Random），后面用于生產(chǎn)「會話秘鑰」。
  （3）客戶端支持的密碼套件列表，如 RSA 加密算法。
  SeverHello服務(wù)器收到客戶端請求后，向客戶端發(fā)出響應(yīng)
  （1）確認(rèn) SSL/ TLS 協(xié)議版本，如果服務(wù)器不支持，則關(guān)閉加密通信。
  （2）服務(wù)器生產(chǎn)的隨機(jī)數(shù)（Server Random），后面用于生產(chǎn)「會話秘鑰」。
  （3）確認(rèn)的密碼套件列表，如 RSA 加密算法。
  （4）服務(wù)器的數(shù)字證書。
  客戶端回應(yīng)客戶端收到服務(wù)器的回應(yīng)之后，首先通過瀏覽器或者操作系統(tǒng)中的 CA 公鑰，確認(rèn)服務(wù)器的數(shù)字證書的真實(shí)性，如果證書沒有問題，客戶端會從數(shù)字證書中取出服務(wù)器的公鑰，然后使用它加密報(bào)文，向服務(wù)器發(fā)送如下信息，
  （1）一個(gè)隨機(jī)數(shù)（pre-master key）。該隨機(jī)數(shù)會被服務(wù)器公鑰加密。
  （2）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。
  （3）客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)把之前所有內(nèi)容的發(fā)生的數(shù)據(jù)做個(gè)摘要，用來供服務(wù)端校驗(yàn)。
  服務(wù)器的最后回應(yīng)服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)（pre-master key）之后，通過協(xié)商的加密算法，計(jì)算出本次通信的「會話秘鑰」。然后，向客戶端發(fā)生最后的信息：
  （1）加密通信算法改變通知，表示隨后的信息都將用「會話秘鑰」加密通信。
  （2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)把之前所有內(nèi)容的發(fā)生的數(shù)據(jù)做個(gè)摘要，用來供客戶端校驗(yàn)。
  至此，整個(gè) SSL/TLS 的握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過用「會話秘鑰」加密內(nèi)容。

5、HTTP/1.1 HTTP/2 HTT/3演變

• 1.1比1.0 提高了什么性能 ？
  使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
  支持管道（pipeline）網(wǎng)絡(luò)傳輸，只要第一個(gè)請求發(fā)出去了，不必等其回來，就可以發(fā)第二個(gè)請求出去，可以減少整體的響應(yīng)時(shí)間。
  但 HTTP/1.1 還是有性能瓶頸：
  請求 / 響應(yīng)頭部（Header）未經(jīng)壓縮就發(fā)送，首部信息越多延遲越大。只能壓縮 Body 的部分；
  發(fā)送冗長的首部。每次互相發(fā)送相同的首部造成的浪費(fèi)較多；
  服務(wù)器是按請求的順序響應(yīng)的，如果服務(wù)器響應(yīng)慢，會招致客戶端一直請求不到數(shù)據(jù)，也就是隊(duì)頭阻塞；
  沒有請求優(yōu)先級控制；
  請求只能從客戶端開始，服務(wù)器只能被動響應(yīng)。

• HTTP/2 針對 1.1 做了什么優(yōu)化 ？
  HTTP/2 協(xié)議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的
  頭部壓縮 HTTP/2 會壓縮頭（Header）如果你同時(shí)發(fā)出多個(gè)請求，他們的頭是一樣的或是相似的，那么，協(xié)議會幫你消除重復(fù)的分。
  這就是所謂的 HPACK 算法：在客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會存入這個(gè)表，生成一個(gè)索引號，以后就不發(fā)送同樣字段了，只發(fā)送索引號，這樣就提高速度了。
  二進(jìn)制格式HTTP/2 不再像 HTTP/1.1 里的純文本形式的報(bào)文，而是全面采用了二進(jìn)制格式。頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為幀（frame）：頭信息幀和數(shù)據(jù)幀。
  
  二進(jìn)制增加了數(shù)據(jù)傳輸?shù)男?/p>

  數(shù)據(jù)流 Stream HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。
  每個(gè)請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流
  每個(gè)數(shù)據(jù)流都標(biāo)記著一個(gè)獨(dú)一無二的編號，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號為奇數(shù)， 服務(wù)器發(fā)出的數(shù)據(jù)流編號為偶數(shù)
  客戶端還可以指定數(shù)據(jù)流的優(yōu)先級。優(yōu)先級高的請求，服務(wù)器就先響應(yīng)該請求

  多路復(fù)用 HTTP/2 是可以在一個(gè)連接中并發(fā)多個(gè)請求或回應(yīng)，而不用按照順序一一對應(yīng)。
  移除了 HTTP/1.1 中的串行請求，不需要排隊(duì)等待，也就不會再出現(xiàn)「隊(duì)頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率。
  服務(wù)器推送 Server Push，也叫 Cache Push，HTTP/2 還在一定程度上改善了傳統(tǒng)的「請求 - 應(yīng)答」工作模式，服務(wù)不再是被動地響應(yīng)，也可以主動向客戶端發(fā)送消息。在瀏覽器剛請求 HTML 的時(shí)候，就提前把可能會用到的 JS、CSS 文件等靜態(tài)資源主動發(fā)給客戶端，減少延時(shí)的等待

• 2 有哪些缺陷 ？ 3 做了哪些優(yōu)化 ？

  HTTP/2 主要的問題在于：多個(gè) HTTP 請求在復(fù)用一個(gè) TCP 連接，下層的 TCP 協(xié)議是不知道有多少個(gè) HTTP 請求的。所以一旦發(fā)生了丟包現(xiàn)象，就會觸發(fā) TCP 的重傳機(jī)制，這樣在一個(gè) TCP 連接中的所有的 HTTP 請求都必須等待這個(gè)丟了的包被重傳回來。
  HTTP/1.1 中的管道（ pipeline）傳輸中如果有一個(gè)請求阻塞了，那么隊(duì)列后請求也統(tǒng)統(tǒng)被阻塞住了
  HTTP/2 多請求復(fù)用一個(gè)TCP連接，一旦發(fā)生丟包，就會阻塞住所有的 HTTP 請求。
  這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP！
  
  UDP 發(fā)生是不管順序，也不管丟包的，所以不會出現(xiàn) HTTP/1.1 的隊(duì)頭阻塞 和 HTTP/2 的一個(gè)丟包全部重傳問題。

  UDP 是不可靠傳輸?shù)?#xff0c;但基于 UDP 的 QUIC 協(xié)議 可以實(shí)現(xiàn)類似 TCP 的可靠性傳輸。
  QUIC 有自己的一套機(jī)制可以保證傳輸?shù)目煽啃缘摹．?dāng)某個(gè)流發(fā)生丟包時(shí)，只會阻塞這個(gè)流，其他流不會受到影響。
  TL3 升級成了最新的 1.3 版本，頭部壓縮算法也升級成了 QPack
  HTTPS 要建立一個(gè)連接，要花費(fèi) 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數(shù)。
  所以， QUIC 是一個(gè)在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復(fù)用的協(xié)議。
  QUIC 是新協(xié)議，對于很多網(wǎng)絡(luò)設(shè)備，根本不知道什么是 QUIC，只會當(dāng)做 UDP，這樣會出現(xiàn)新的問題。所以 HTTP/3 現(xiàn)在普及的進(jìn)度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。

總結(jié)

以上是生活随笔為你收集整理的前端学习/ Day1/HTTP简单易懂/GET POST/HTTP特性/HTTP与HTTPS/HTTP版本演变/加解密数字签名数字证书的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。