關於http 的知識總結

鑑於 http1.0 已經基本被淘汰了，我也沒有過多地關注1.0 的內容，而是從 http1.1 學起，這裡只是乙個知識點的梳理

在以前的文章中提到，瀏覽器是有專門的網路程序的

在 http1.1 中，同一時間對於同乙個網域名稱只會保留 6 個 tcp 連線

在請求中包含 keep-alive(瀏覽器預設給每個請求都加上了這個配置) 的前提下，請求會復用之前的 tcp 連線

如果不想復用，可以再請求頭上加上 connection: close

在 http1.1 中，提供了對虛擬主機的支援，也就是在同乙個 ip 下，還可以有不同的主機，主要是通過 host 的請求頭配置

通過 chunk 機制來動態地傳輸要傳送的內容，將資料進行分割，攜帶上每個資料塊的長度，在最後發乙個長度為 0 的資料塊表示傳送結束

同時還有 cookie、cache-control 等新式的請求頭引數

但是 http1.1 還是有不少缺陷的

tcp 啟動太慢了，三次握手

tcp 負責的請求還是太少了，如果前面的請求太慢，後面的請求就會一直等待

很多國外的**都是使用了 http2，那麼為什麼要強調國外呢？

http2.0 最重要的改進在於傳輸的內容都是二進位制位元組流，而很多的新特性也是得益於這個而發展出來的

多路復用，所謂多路復用，就是這裡不再維持 6 個tcp 了，而是對於乙個網域名稱維持乙個 tcp 連線

在傳輸的過程中，給每個資料塊加乙個對應請求的id，系統就可以根據 id 拼出來想要的返回結果

而在使用多路復用的前提下，就減少了 tcp 的連線，也減少了三次握手的過程，自然也加快了速度

可以設定請求的優先順序，比如乙個網頁中，js、css 的優先順序比較高，可以在多路復用的傳輸過程中，可以優先傳輸這一類的檔案

http2.0 是可以實現伺服器推送的，那麼在使用者請求乙個html 之後，伺服器可以主動把 js、css檔案推過來，減少了主動請求的過程，這樣的話使用者體驗自然更好

http2.0 實現了頭部壓縮，這個沒什麼好多說的

對於 http/2 來說，乙個網域名稱使用乙個 tcp 連線才能夠獲得最佳效能，如果開多個網域名稱，就會浪費頻寬和伺服器資源，也會降低 http/2 的效率，所以「網域名稱收縮」在 http/2 裡是必須要做的。

http2.0 自然也是有缺陷的

在 tcp 連線中，由於需要確保請求傳送出去了，那麼就會對傳送出的包進行檢驗，如果發生了丟包的事情，就會重新傳送。

而在這個重新傳送的過程中，所有的請求都會停止，等待這個丟掉的包成功傳送

關於這個協議，我了解的也不多

這個協議是在 udp 的基礎上，重新實現的 quic 協議

整合了 tls 加密的功能(https)

由於基於 udp ，就可以握一次手，乃至於不握手了

https 是在 http 協議和 tcp 協議之間，加上了一層ssl/tls 加密、解密的過程

先是進行了 tcp 的三次握手

現在的 https 是對稱加密(雙方握有相同的秘鑰) 和非對稱加密(客戶端握有公鑰，服務端握有私鑰) 的配合使用

瀏覽器生成乙個 client-random 隨機數傳送給服務端(這裡還會帶上可以使用的加密演算法列表)①

服務端儲存 client-random ，然後生成乙個 service-random 隨機數，和自己的數字證書傳送到客戶端（這裡會選擇第3點帶上的加密演算法列表中的乙個返回給客戶端）②

數字證書有明文部分，有密文部分，明文部分是使用hash 加密的，而密文部分是 ca 機構使用自己的私鑰加密的

客戶端接收到數字證書之後，使用系統內嵌的證書公鑰解密證書，獲得摘要資訊(這裡還包括伺服器傳送的公鑰資訊)，驗證服務端的網域名稱資訊等相關資訊(也就是明文部分和密文部分一致)，知道了這個服務端確實是我的服務端

客戶端再生成pre-random 隨機數，利用第6點中提到的公鑰資訊進行加密後，傳送給服務端 ③

服務端使用私鑰解密，這樣客戶端和服務端就都儲存了三分隨機數，client-random service-rendom pre-random ，用約定好的加密演算法 (就是第 3、4 點客戶端、服務端選擇的加密演算法) 計算出相等的對稱加密的秘鑰

這樣就可以使用生成秘鑰進行加密資料通訊了

所以加上 tcp 的三次握手，https 一共經歷了6 次握手才能夠共享乙個金鑰