HTTP請求的整個流程以及HTTPS可靠性的簡介。

自從開始寫科普類文章，我感覺已經一發而不可收拾了??

公司在開會好無聊→_→就寫一下 http 請求的整個流程和 https 的原理吧。

http 請求要經過三個部分

1 客戶端 就是用戶

2 網路提供商 例如電信網通

3 服務端 網站數據存放的地點

打個比方，在瀏覽器地址欄中輸入 http://www.example.com

這是個人類能看懂的名稱，但是在網路上並不靠這個區分計算機，而是靠 ip 地址

用戶瀏覽器首先在本地緩存中查找這個域名對應的 ip ，如果找不到就交給系統，系統首先會在 hosts 中查找對應的 ip ，找不到的話，就會請求 DNS 伺服器

在連接網路的時候，如果用戶不手動設置，會自動使用網路運營商分配的 DNS 伺服器。

如果 DNS 伺服器也沒有該域名的緩存，則會向上一級 DNS 伺服器請求，假設全都沒有，則最後會遞歸到根域名伺服器，全球只有 13 組根域名伺服器。根域名伺服器不存儲 ip 地址，只存儲其他的 DNS 伺服器。

打個比方， http://www.example.com 提交到根域名伺服器之後，他會說 以 .com 結尾的都歸 A 管，然後找到 A ，A說，以 http://example.com 結尾的都歸 B 管，然後找到 B ，B 會告訴你 http://www.example.com 的 ip 地址

所謂的 DNS 污染，就是 DNS 伺服器不返回正確的 ip 地址，比如 http://www.example.com 的 ip 地址是 192.168.1.1 ，DNS 告訴你是 192.168.1.2

，你也不知道→_→

知道了 ip 地址以後，瀏覽器就會請求該 ip 地址。

而請求的數據，經過好多個路由 從你家裡的路由器開始，到運營商的路由，再往上，到最頂上以後再往下。就跟 DNS 查詢差不多。最後才到達伺服器。伺服器返回的數據也如此。

由於 http 請求是明文的，因此這條鏈路上的任意一個路由，都可以任意修改數據，沒有任何安全可言。

然後 HTTPS 就誕生了。在這裡要提到對稱加密和非對稱加密。

對稱加密 數據使用 A 密鑰加密，變成加密後的數據，加密後的數據使用 A 密鑰解密，變成數據。

這裡就存在一個問題，由於 HTTP 是明文，如果採用對稱加密，那麼如何傳輸密鑰？如果也通過不加密的 HTTP 鏈路傳輸，別人知道了密鑰，還是能隨便改數據。

非對稱加密 數據使用 A 密鑰加密，變成加密後的數據，然後加密後的數據經過 B 密鑰解密，變成明文。然後相反的，數據經過 B 加密以後，也能通過 A 解密。這樣只要伺服器把 A 密鑰公布到網上，別人就能使用 A 密鑰加密，然後伺服器使用 B 密鑰解密，就行了，這樣中間的不法分子即使知道 A 密鑰，也沒辦法隨便修改數據。

不過由於非對稱加密速度太慢，所以一般實現都是，使用非對稱加密加密密鑰，然後使用新的密鑰進行對稱加密的通訊。

但是，這裡還有一個問題。

假如中間人把 A 密鑰攔截下來，把數據攔截下來，把數據解密，然後把數據用自己的非對稱密鑰加密後，跟自己的密鑰一起發過去，最後數據還是會在中間人這裡中轉，相當於沒什麼卵用。

為了防止這種情況，必須保證自己收到的密鑰就是伺服器發出的密鑰而不是中間人的密鑰。

在這裡就會涉及到證書→_→說的稍微簡單點

伺服器把自己的域名，ip，公鑰放在一起，用非對稱加密加密上，發送過去

理論上來說這樣還是能被上述方法攔截

然後再加密，理論上還是被攔截

一直加密，雖然說不管加密多少層都是會被攔截的，但是這邊目的不是為了不被攔截，而是為了減少數目。

打個比方，世界上有一億個網站，假如每100個網站共用一個密鑰加密，再每一百個密鑰共用一個密鑰加密，最後就只剩一個需要信任的公鑰了。

而這一個需要信任的公鑰是內置在操作系統中，內置在瀏覽器中，不經過網路發布。

只要確定了這個公鑰值得信任，那以他加密的下屬的100個公鑰也值得信任了，以此類推。最後就知道這個域名是不是對應這個 ip ，是不是對應該網站的公鑰。順便也解決了 DNS 的污染問題。

這個鏈路就叫做證書信任鏈。

不過在實際情況中，並不是只有一個跟 CA，一般都有很多，而且不同瀏覽器，不同操作系統內置的跟 CA也不一定一樣，但是大部分還是一樣的，所以說，上次 Chrome 覺得 某根 CA 亂髮證書，所以把它從Chrome證書庫里吊銷掉了→_→

大概就這麼多，手機打字好麻煩，有時間再查漏補缺，加加圖改改錯什麼的。
推薦閱讀：