其他分享
首页 > 其他分享> > 【转载】在浏览器地址栏输入一个URL回车后,究竟会发生什么?

【转载】在浏览器地址栏输入一个URL回车后,究竟会发生什么?

作者:互联网

 

 

小明打开浏览器,输入idleleo.com敲回车键。

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

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

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

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

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

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

所以,小明输入的网址被浏览器补齐为“http://idleleo.com” 。

浏览器知道,TCP/IP快递公司那帮王八蛋,只有告诉它们收件人的IP地址,才会把快递送到收件人地址。告诉他们  “idleleo.com”如同对牛弹琴,它们不懂啊!

浏览器于是联系“黄页公司” DNS,请帮我查询一下“idleleo.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大叔家的快递。

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

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

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

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

对的,我们经常看到的网址如idleleo.com,完整的写法应该是 idleleo.com. 最后的那个“.”相当于树根,天下所有的叶子域名,都是树根的孩子、孩子的孩子....

根域名服务器全球一共多少台?

13台

1台不行吗?

万一根服务器挂了,会影响全球的域名查询系统。使用多台根服务器,可以提供物理冗余,分摊全球的域名查询任务。

DNS大叔知道13台根服务器的IP地址吗?

知道。

DNS大叔就会去联系13台根服务器的一员,查询自己想要的结果。

根服务器一看“idleleo.com.” ,知道是自己的孙子,却不知道其IP地址。但根服务器相信孙子的爸爸“com”会知道,于是告诉DNS大叔,请去联系我孙子的爸爸,他的IP地址是x.x.x.x。

DNS大叔锲而不舍地去联系孙子的爸爸,毫无疑问,爸爸肯定知道儿子的IP地址,儿子的名字都是自己起的,能不知道吗?

将结果告诉了DNS大叔,大叔如获至宝,立马将结果告诉了远在千里之外等待的DNS老实孩子,结果应该是这个样子的:

 

累死了,鼓捣了半天才算拿到服务器的IP地址,DNS把结果返回给浏览器。

浏览器再次联系TCP/IP快递公司,这次与其接洽的是TCP阿姨,TCP做事非常认真。

知道浏览器想要去拜访“47.96.6.248”,先和对方取得联系,看看对方在不在,这通常由三次握手实现的。

老阿姨:在家吗?想去拜访您。

对方:在的,欢迎啊。

老阿姨:马上到。

这一来二回的三次消息,也都需要IP司机来来回回运输三次,具体过程和上文IP司机运输DNS报文非常类似,就不再重复。

三次握手完成,TCP阿姨与对方建立了一个可靠的虚拟通道,浏览器很快知道了这个消息。

浏览器将http请求消息,打包好扔给TCP阿姨,阿姨在包裹上填上关键信息:

收件人门牌号  80

发件人门牌号  51235

然后也是联系IP司机来运输,过程不表。

包裹到达了目的地,服务器根据门牌号80,联系到了http server小姐姐。

小姐姐返回了一个消息:HTTP Redirect 消息,大意是,本公司服务器整体搬迁到https://www.idleleo.com上去了,请重新访问本司的新网址。

浏览器收到这个消息,立马前往https://www.idleleo.com,整个过程与http:/idleleo.com大体相似,接下来主要阐述不一样的地方。

TCP三次握手成功之后,浏览器将自己的打包好的包裹,不是直接给TCP阿姨,而是委托TLS安保大叔全权负责。

TLS安保大叔,首要的任务是确保包裹在运输过程中的安全,即包裹的内容保密,包裹内容不能被篡改、替换。

TLS大叔需要先和对方沟通安保措施,沟通的渠道,就是上文三次握手建立的渠道。

TLS大叔先发言:你好,我支持TLS版本1.2,以及我的认证算法、加密算法、数据校验算法,此外还有我的随机码,收到请回复。

TLS服务器回复:你好,我也支持1.2版本,那我们就使用xx认证算法、xx加密算法、xx数据校验算法,我的随机码是xx,来实现安保措施,你看好吗?

TLS大叔:没问题啊,能出示一下你的证件(数字证书)吗?

TLS服务器:okay,这是我的证件,请过目。

TLS大叔发现对方发过来两个证书:

证书1: “*.idleleo.com”,由Let's Encrypt Authority X3签名并颁发

证书2: “Let's Encrypt Authority X3”,由DST Root CA X3签名并颁发


验证过程如下:

1.用Let's Encrypt Authority X3的公钥解密证书2的签名

Let's Encrypt Authority X3作为一个权威CA,已经被浏览器预先安装在可信任根证书列表,那么我们信任该CA的一切,当然包括其公钥,在该证书里包含了明文的公钥,如下图所示:

在浏览器地址栏输入一个URL回车后,究竟会发生什么?



解开了,证明是该CA私钥加密的,由于CA私钥只有CA知道,证书有效,并信任
Let's Encrypt Authority X3 公钥

解不开,证明不是CA私钥加密,无效证书。


2. 用Let's Encrypt Authority X3的公钥解密证书1的签名

过程和步骤1同样的原理,如果2个步骤都验证成功,就有了idleleo.com的公钥。

TLS大叔还需要检查的证书有效期,再检查证书是否被吊销(CRL),如果一切都没有问题,进入下一个步骤。

TLS大叔用“*.idleleo.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高富帅的包裹。

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

标签:TLS,大叔,浏览器,URL,com,DNS,服务器,地址栏
来源: https://www.cnblogs.com/imPedro/p/11700396.html