为了让更多读者理解这个问题，接下来派出男主角小明出场，采用拟人的手法来阐述整个过程。
小明听说最近两天知乎有一个帖子挺火，问题的提出者是腾讯的总裁 Pony Ma，有一个回答是这样的：
于是小明想去看看精彩评论，于是开始了网上冲浪之旅。。。
小明打开浏览器，输入http://zhihu.com敲回车键。
在小明眼里，浏览器是自己的小奴才，让你干啥就干啥。
浏览器才不这么看，鄙人也是有自己独立的人格的。老板的命令是对的，那自然照做。如果是错误的，就当老板放 P！
如果小明输入的是 “zhi hu.com” 或 “zhi@hu.com1”, 这些网址都是非法无效的，浏览器就要拒绝小明的无理要求，提示小明出错了。
所以，第一步是浏览器对用户输入的网址做初步的格式化检查，只有通过以上检查才会进入下一步。
浏览器是用 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 主页返回，并最终到达浏览器。
小明很快就搜索到本文开始的那个回答，小明做梦都没有想到，自己的一次回车键，引发如此庞大的计算量。。。
微信扫一扫 
