鑑於 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 點 客戶端、服務端 選擇的 加密算法) 計算出 相等的 對稱加密 的祕鑰
- 這樣 就可以使用 生成 祕鑰 進行加密數據 通訊了