為了讓更多讀者理解這個問題，接下來派出男主角小明出場，采用擬人的手法來闡述整個過程。
小明聽說最近兩天知乎有一個貼文挺火，問題的提出者是騰訊的總裁 Pony Ma，有一個回答是這樣的：
於是小明想去看看精彩評論，於是開始了網上沖浪之旅。。。
小明開啟瀏覽器，輸入http://
zhihu.com
敲回車鍵。
在小明眼裏，瀏覽器是自己的小奴才，讓你幹啥就幹啥。
瀏覽器才不這麽看，鄙人也是有自己獨立的人格的。老板的命令是對的，那自然照做。如果是錯誤的，就當老板放P！
如果小明輸入的是 「zhi hu.com」 或 「[email protected]」, 這些網址都是非法無效的，瀏覽器就要拒絕小明的無理要求，提示小明出錯了。
所以，第一步是瀏覽器對使用者輸入的網址做初步的格式化檢查，只有透過以上檢查才會進入下一步。
瀏覽器是用http還是https存取伺服器呢？
小明並沒有明確告知瀏覽器是用哪個協定，針對此種情況，瀏覽器有自己的預案，那就是預設使用http協定，除非小明輸入的是「
https ://http://
zhihu.com
」。
所以，小明輸入的網址被瀏覽器補齊為「
http://
zhihu.com
」 。
瀏覽器知道，TCP/IP快遞公司那幫王八蛋，只有告訴它們收件人的IP地址，才會把快遞送到收件人地址。告訴他們 「zhihu.com」如同對牛彈琴，它們不懂啊！
瀏覽器於是聯系「黃頁公司」 DNS，請幫我查詢一下「zhihu.com」 的IP地址是多少？
DNS是個老實孩子，自己能查詢到的，絕不麻煩別人。
先查自己記憶體裏的DNS Cache，沒有！
再查本地硬碟裏的host檔，也沒有！
實在沒轍只有求人了，於是DNS硬著頭皮去聯系自己的DNS伺服器 8.8.8.8。
DNS將自己的查詢打好包，收件人地址為8.8.8.8，寄件人地址為1.1.1.1，DNS聯系TCP/IP快遞公司。
負責接洽的是UDP，UDP懶洋洋的躺在沙發上，隨手在包裹上刷刷寫了幾筆：
收件人門牌號 53
發件人門牌號 56002
之所以要有門牌號，是因為一個收件人地址可能會有多個門牌號，為了避免混淆。對於整天浸淫在快遞行業的UDP，太了解這個行業了。
UDP給貨車司機IP打電話：老四啊，有件快遞需要你捎帶一下。。。
IP司機來了，把包裹扔上車，坐上駕駛座，準備開車。
IP司機查詢了導航(IP路由表)，發現要出關(Gateway)，這個關口有點怪癖，需要司機知道其MAC地址，導航資訊裏竟然沒有。
於是IP司機找到了當地精靈ARP，老師傅，麻煩您帶帶路啊！
ARP沒有廢話，聲音洪亮地喊了一嗓子，閘道器你MAC地址多少啊，告訴老夫一聲！
很快傳來了閘道器的回答：我的MAC地址是xx.xx.xx.xx.xx.xx
有了關口的MAC地址，IP司機終於可以開車上路了。
很快就到達了關口，關口放行，IP司機載著快遞，上了Internet高速公路，一路狂奔不表。。。
到達目的地8.8.8.8，伺服器根據門牌號碼53，知道這是DNS Server大叔家的快遞。
喊大叔來收快遞，大叔開啟包裹一看，這個好回答啊，http://
zhihu.com
對應的IP地址正好在緩存裏還熱著呢，於是將其回復回去。
這個DNS大叔有一個特點，打破沙鍋問到底的學習精神，俗稱的一根筋。如果DNS大叔的本地緩存裏查詢沒有，怎麽辦呢？
DNS大叔會去聯系DNS網域名稱系統的根伺服器「.」
有讀者會問，「.」代表的就是根伺服器？
對的，我們經常看到的網址如http://
zhihu.com
，完整的寫法應該是
zhihu.com.
最後的那個「.」相當於樹根，天下所有的葉子網域名稱，都是樹根的孩子、孩子的孩子....
根網域名稱伺服器全球一共多少台？
13台
1台不行嗎？
萬一根伺服器掛了，會影響全球的網域名稱查詢系統。使用多台根伺服器，可以提供物理冗余，分攤全球的網域名稱查詢任務。
DNS大叔知道13台根伺服器的IP地址嗎？
知道。
DNS大叔就會去聯系13台根伺服器的一員，查詢自己想要的結果。
根伺服器一看「
zhihu.com.
」 ，知道是自己的孫子，卻不知道其IP地址。但根伺服器相信孫子的爸爸「com」會知道，於是告訴DNS大叔，請去聯系我孫子的爸爸，他的IP地址是x.x.x.x。
DNS大叔鍥而不舍地去聯系孫子的爸爸，毫無疑問，爸爸肯定知道兒子的IP地址，兒子的名字都是自己起的，能不知道嗎？
將結果告訴了DNS大叔，大叔如獲至寶，立馬將結果告訴了遠在千裏之外等待的DNS老實孩子，結果應該是這個樣子的：
累死了，鼓搗了半天才算拿到伺服器的IP地址，DNS把結果返回給瀏覽器。
瀏覽器再次聯系TCP/IP快遞公司，這次與其接洽的是TCP阿姨，TCP做事非常認真。
知道瀏覽器想要去拜訪「118.89.204.100」，先和對方取得聯系，看看對方在不在，這通常由三次握手實作的。
老阿姨：在家嗎？想去拜訪您。
對方：在的，歡迎啊。
老阿姨：馬上到。
這一來二回的三次訊息，也都需要IP司機來來回回運輸三次，具體過程和上文IP司機運輸DNS報文非常類似，就不再重復。
三次握手完成，TCP阿姨與對方建立了一個可靠的虛擬通道，瀏覽器很快知道了這個訊息。
瀏覽器將http請求訊息，打包好扔給TCP阿姨，阿姨在包裹上填上關鍵資訊：
收件人門牌號 80
發件人門牌號 51235
然後也是聯系IP司機來運輸，過程不表。
包裹到達了目的地，伺服器根據門牌號80，聯系到了http server小姐姐。
小姐姐返回了一個訊息：HTTP Redirect 訊息，大意是，本公司伺服器整體搬遷到https://www.
zhihu.com
上去了，請重新存取本司的新網址。
瀏覽器收到這個訊息，立馬前往https://www.
zhihu.com
，整個過程與http:/http://
zhihu.com
大體相似，接下來主要闡述不一樣的地方。
TCP三次握手成功之後，瀏覽器將自己的打包好的包裹，不是直接給TCP阿姨，而是委托TLS安保大叔全權負責。
TLS安保大叔，首要的任務是確保包裹在運輸過程中的安全，即包裹的內容保密，包裹內容不能被篡改、替換。
TLS大叔需要先和對方溝通安保措施，溝通的渠道，就是上文三次握手建立的渠道。
TLS大叔先發言：你好，我支持TLS版本1.2，以及我的認證演算法、加密演算法、數據校驗演算法，此外還有我的隨機碼，收到請回復。
TLS伺服器回復：你好，我也支持1.2版本，那我們就使用xx認證演算法、xx加密演算法、xx數據校驗演算法，我的隨機碼是xx，來實作安保措施，你看好嗎？
TLS大叔:沒問題啊，能出示一下你的證件(電子證書)嗎？
TLS伺服器：okay，這是我的證件，請過目。
TLS大叔發現對方發過來兩個證書：
證書1: 「*.zhihu.com」，由
GeoTrust RSA CA 2018
簽名並頒發
證書2: 「GeoTrust RSA CA 2018」，由
DigiCert Global Root CA
簽名並頒發
驗證過程如下：
1.用
DigiCert Global Root CA
的公鑰解密證書2的簽名
DigiCert Global Root CA
作為一個權威CA，已經被瀏覽器預先安裝在可信任根證書列表，那麽我們信任該CA的一切，當然包括其公鑰，在該證書裏包含了明文的公鑰，如下圖所示：
解開了，證明是該CA私鑰加密的，由於CA私鑰只有CA知道，證書有效，並信任
GeoTrust RSA CA 2018
公鑰
。
解不開，證明不是CA私鑰加密，無效證書。
2. 用
GeoTrust RSA CA 2018
的公鑰解密證書1的簽名
過程和步驟1同樣的原理，如果2個步驟都驗證成功，就有了http://
zhihu.com
的公鑰。
TLS大叔還需要檢查的證書有效期，再檢查證書是否被吊銷(
CRL
)，如果一切都沒有問題，進入下一個步驟。
TLS大叔用「*.zhihu.com」公鑰加密一段隨機的字串，發送給TLS伺服器。
TLS伺服器用自己的私鑰解密，得到明文字串。
至此，雙方分享了這個神秘的字串，雙方還有早前分享的隨機碼(nonce)，雙方使用同樣的演算法，可以推匯出相同的master key，進而推匯出session key、HMAC key。
Session Key用於加密/解密數據， HMAC Key主要用於保護數據的完整性，以防被第三方篡改。
整個TLS溝透過程就算完成了，TLS大叔把瀏覽器扔給自己的包裹，外面加了一層保險箱，密碼鎖（session key）只有TLS大叔、TLS伺服器知道。
然後把保險箱再扔給TCP阿姨，TCP阿姨一點也不在乎，運輸一個保險箱與一個普通包裹沒有任何區別，唯一的區別是收件人的門牌號變了：
收件人門牌號
443
然後保險箱就被運走了，很快就到達了目的地，伺服器老大爺一看門牌號443，知道這是TLS伺服器的快遞包裹。
TLS伺服器用密碼開啟了保險箱，取出了快遞。
在保險箱裏還有一個小紙條寫著「Application Data =http」, TLS伺服器知道這是HTTP Server高富帥的包裹。
然後把包裹轉交給高富帥，高富帥將http://www.
zhihu.com
主頁返回，並最終到達瀏覽器。
小明很快就搜尋到本文開始的那個回答，小明做夢都沒有想到，自己的一次回車鍵，引發如此龐大的計算量。。。
