鑑於 http1.0 已經基本被淘汰了，我也沒有過多地關注1.0 的內容，而是從 http1.1 學起，這裏只是一個知識點的梳理
1、http1.1
- 在以前的文章中提到，瀏覽器 是有專門的 網絡進程的
- 在 http1.1 中，同一時間對於 同一個域名 只會保留 6 個 TCP 連接
- 在 請求中包含 keep-alive(瀏覽器默認給每個請求都加上了這個配置) 的前提下，請求會複用 之前的 TCP 連接
- 如果 不想 複用，可以再 請求頭上 加上 Connection: close
- 在 http1.1 中，提供了 對虛擬主機的支持，也就是 在同一個 ip 下，還可以有不同的 主機，主要是 通過 host 的請求頭配置
- 通過 chunk 機制來 動態地傳輸 要發送的內容，將 數據進行分割，攜帶上 每個數據塊 的長度，在最後 發一個 長度爲 0 的數據塊 表示 發送結束
- 同時 還有 cookie、cache-control 等 新式的 請求頭參數
但是 http1.1 還是有不少缺陷的
- TCP 啓動太慢了，三次握手
- 開啓了 多條的 TCP 之後，互相之間會競爭 帶寬，當需要下載 重要的資源的時候，反而會導致 用戶體驗差，比如 js、css 這些會阻塞 渲染的 資源
- TCP 負責的請求還是太少了，如果前面的請求太慢，後面的請求就會一直等待
2、http2.0
很多 國外的網站都是使用了 http2，那麼爲什麼要強調國外呢？
- 沒錯了 百度、淘寶 等 國內大型網站都還在使用 http1.1
- http2.0 最重要的 改進 在於 傳輸 的內容 都是 二進制字節流，而很多 的新特性 也是得益於 這個而發展出來的
- 多路複用，所謂多路複用，就是 這裏 不再維持 6 個TCP 了，而是 對於一個 域名 維持 一個 TCP 連接
- 在傳輸的過程中，給每個數據塊 加一個 對應 請求 的id，系統就可以根據 id 拼出來 想要的 返回結果
- 而在使用 多路複用 的前提下，就減少了 TCP 的連接，也減少了 三次握手的過程，自然也加快了速度
- 可以 設置請求的 優先級，比如 一個 網頁中，js、css 的優先級 比較高，可以在多路複用的傳輸過程中，可以優先傳輸 這一類的文件
- http2.0 是可以實現 服務器推送的，那麼 在 用戶請求 一個html 之後，服務器可以主動把 js、css文件推過來，減少了 主動請求的過程，這樣的話 用戶體驗自然更好
- http2.0 實現了 頭部壓縮，這個 沒什麼好多說的
http2.0 自然也是有缺陷的
在 TCP 連接中，由於 需要確保 請求發送出去了，那麼 就會對 發送出的 包進行檢驗，如果發生了丟包的事情，就會 重新發送。
而在這個重新發送的過程中，所有的 請求都會停止，等待 這個丟掉的包成功發送
3、HTTP3.0
關於這個協議，我瞭解的也不多
- 這個協議是在 UDP 的基礎上，重新實現的 QUIC 協議
- 集成了 TLS 加密的功能(https)
- 由於 基於 UDP ，就可以 握一次手，乃至於不握手了
4、https
- https 是在 http 協議和 TCP 協議之間，加上了 一層SSL/TLS 加密、解密的過程
- 現在 的 https 是對稱加密(雙方 握有相同的祕鑰) 和 非對稱加密(客戶端握有 公鑰，服務端握有 私鑰) 的配合使用
- 瀏覽器 生成 一個 client-random 隨機數 發送給 服務端(這裏還會帶上 可以使用的 加密算法列表)
- 服務端 保存 client-random ，然後生成 一個 service-random 隨機數，和 自己的數字證書 發送到 客戶端（這裏會 選擇 第3點帶上的 加密算法列表中的一個 返回給客戶端 ）
- 數字 證書有 明文部分，有 密文部分，明文部分 是使用hash 加密的，而 密文部分 是 CA 機構 使用自己的私鑰 加密的
- 客戶端 接收到 數字證書之後，使用 系統 內嵌 的 證書公鑰 解密 證書，獲得摘要信息(這裏還包括服務器 發送的 公鑰信息)，驗證 服務端 的域名信息等相關信息(也就是 明文 部分 和密文 部分一致)，知道了 這個服務端 確實是 我的服務端
- 客戶端再生成 pre-random 隨機數，利用 第6點 中提到的 公鑰信息 進行加密後，發送給 服務端
- 服務端 使用 私鑰 解密，這樣 客戶端 和 服務端 就都保存了 三分隨機數，client-random service-rendom pre-random ，用 約定好的 加密算法 (就是 第 3、4 點 客戶端、服務端 選擇的 加密算法) 計算出 相等的 對稱加密 的祕鑰
- 這樣 就可以使用 生成 祕鑰 進行加密數據 通訊了
