本故事纯属虚构,为了让这个问题变得通俗易懂,接下来派出男主角徐小唠出场,采用拟人的手法来阐述整个过程。


徐小唠某天刷知乎,看到有一个帖子挺火,问题的提出者是腾讯的总裁 Pony Ma,问题是这样的:
问题截图

于是徐小唠想去看看精彩评论,于是开始了网上冲浪之旅。。。

徐小唠打开浏览器,输入zhihu.com敲回车键。

在徐小唠眼里,浏览器是自己的小奴才,让你干啥就干啥。

浏览器才不这么看,鄙人也是有自己独立的人格的。老板的命令是对的,那自然照做。如果是错误的,就当老板放P!

如果徐小唠输入的是 “zhi hu.com” 或 “zhi@hu.com1”, 这些网址都是非法无效的,浏览器就要拒绝徐小唠的无理要求,提示徐小唠出错了。

所以,第一步是浏览器对用户输入的网址做初步的格式化检查,只有通过以上检查才会进入下一步。

浏览器是用http还是https访问服务器呢?

徐小唠并没有明确告知浏览器是用哪个协议,针对此种情况,浏览器有自己的预案,那就是默认使用http协议,除非徐小唠输入的是“https://zhihu.com” 。

所以,小明输入的网址被浏览器补齐为“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大叔家的快递。

喊大叔来收快递,大叔打开包裹一看,这个好回答啊,zhihu.com对应的IP地址正好在缓存里还热着呢,于是将其回复回去。

这个DNS大叔有一个特点,打破沙锅问到底的学习精神,俗称的一根筋。如果DNS大叔的本地缓存里查询没有,怎么办呢?

DNS大叔会去联系DNS域名系统的根服务器“.”

有读者会问,“.”代表的就是根服务器?

对的,我们经常看到的网址如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 消息,大意是,本公司服务器整体搬迁到zhihu.com上去了,请重新访问本司的新网址。

浏览器收到这个消息,立马前往zhihu.com,整个过程与https://www.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个步骤都验证成功,就有了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高富帅的包裹。

然后把包裹转交给高富帅,高富帅将zhihu.com主页返回,并最终到达浏览器。

徐小唠很快就搜索到本文开始的那个回答,徐小唠做梦都没有想到,自己的一次回车键,引发如此庞大的计算量。。。