热爱技术
专注分享

当你在浏览器中输入了本站网址并回车后,产生了哪些技术步骤?

前段时间在知乎上了看一些网络方面的知识,发现知乎果然不愧是211,985才能入门的中文最高端的社区之一,大佬云集,讲得既生动又形象。由于博主工作上对网络方面有一定的了解,且在自学python的时候也接触过网络编程,在这里,我决定开一篇文章,借鉴一下知乎上的回答方式,来讲讲,当你在浏览器中输入本站域名并回车后,这背后到底发生来什么事情?

emmmm,大致总结归纳了下,发生的事情如下图:

network.jpg

看到这里,相信你一定是懵逼的。没错,哪怕你有一点网络知识的基础,看起来也是一脸懵逼的。为了跟大家生动形象地说明原理,下面,我就用拟人的手法,讲述从输入一个网址,到最终显示出页面,这背后所发生的事情。

 

某天,小明心血来潮,想去小伟博客看一下有没有更新新的博文,于是他打开了chrome浏览器,稍微回忆了一下网址,输入了:xiaoweigod.com,并按下了回车。

一 浏览器格式化检查

chrome检查了一下,嗯?这好像是一个蛮标准的网址。但如果小明输入的是xiaoweigod@com或者xiaoweigod.com1这样的,chrome就会无情的拒绝小明的提议,并提示他网址出错。

所以在第一步,浏览器对网址进行了格式化检验,确定这是一个有效的网址,才会进入下一步。

但是,在访问之前,浏览器必须知道,用了什么协议,是http呢,还是https呢?显然chrome对这种事情已经见怪不怪了,他有自己的一套方案,这里小明没有给定是什么协议的,于是chrome默认用了http协议,于是将网址修改成了:http://xiaoweigod.com

 

二 DNS分级查询

在互联网上,有一家名叫TCP/IP的快递公司,专门负责运送用户的包裹。于是chrome联系了TCP/IP快递公司,但却被告知:需要知道对方的IP地址,才能把包裹寄给对方!chrome并不是一个灰心的孩子,于是它找到了“黄页公司”-DNS。求DNS帮忙查询下“xiaoweigod.com”的IP地址是多少?

DNS于是着手开始查找。

首先看了下本地的hosts文件,没有找到对应!

然后看了下本地内存,也没有!

没办法,DNS只好联系了村口的一家名叫路由器的公司,192.168.1.1。路由器查看了下,最近村里没人访问过这个域名呀,要不你去市里的DNS公司问问?这是市里的DNS公司地址:114.114.114.114

于是DNS又联系了市里的DNS公司,却被告知最近市里最近也没人访问过这个域名。但是市里的DNS公司毕竟是专业的DNS公司,不会随便推卸责任,对DNS说,你等一等,我找我的上级查询下。

于是市里的DNS公司联系了它的上级,根域名服务器。这个根域名服务器可了不得,全球只有13台,掌控着全球的DNS根域名查询。市里的DNS公司找到了离他最近的根域名服务器,说:“老哥,麻烦帮我查下.com顶级域名的服务器地址。”

没过一会儿,根域名服务器回复道:“你好,你要查询的地址是1.2.3.4。”

于是市里的DNS公司又联系到了1.2.3.4,询问 xiaoweigod这个二级域名的域名服务器地址。

同样,1.2.3.4回复给了市里的DNS公司,地址是2.3.4.5。

市里的DNS公司又找2.3.4.5问了下,地址是:xiaoweigod.com.w.kunluncan.com。等等,这怎么是一个别名(CNAME)?

于是市里的DNS公司又不厌其烦的重复了上面的几个步骤,一级一级地查找了 com > kunluncan > w > com > xiaoweigod的域名服务器地址,一直找到了阿里云的CDN域名服务器,DNS联系了对方,对方回复道:“查询到25个IP地址,分别是xxxxxxxx,帮你找到了离你最近的地址,3.4.5.6,已经打包,收件人地址:114.114.114.114 发件人地址:3.3.3.3,已委托TCP/IP快递公司的UDP小哥发送给你。”

 

三 网关 ARP原理

UDP是这一行的老司机,随手在包裹上写着:

收件人门牌号:53

发件人门牌号:56002

因为UDP知道,同一个地址会有很多的门牌号,为了避免混淆,必须要写。

UDP随手联系了TCP/IP公司的货车司机,让他捎带一下这个包裹。

司机来了,把包裹放进了驾驶室,坐上车准备开车。

司机打开了导航(路由表),发现要出关(网关),但是要知道关口的编号(mac地址)。但是导航信息里并没有关口的编号。于是司机找到了当地的向导ARP,问这个关口的编号是多少?ARP吼了一嗓子,关口回复说:“我的编号是xxxxx”。司机很快就到达了关口,关口放行,载着快递,上了Internet高速公路,一路狂奔不止。

 

四 建立DNS缓存

市里的DNS公司收到结果后,又通过村口的路由器公司联系到了DNS,并把结果告诉给了对方。同时村口的路由器公司和DNS都在自己的小本本上默默地记下了这个对应关系。

最后,DNS又把结果告诉给了已经等得不耐烦的chrome了。

  

五 TCP的三次握手

知道了xiaoweigod.com的IP地址,chrome又立即联系了TCP/IP快递公司,快递公司派出了TCP小哥来接洽此时。和UDP小哥不同的是,TCP小哥是一个做事一丝不苟的人,知道chrome想要去拜访3.4.5.6,就要先和对方联系一下,确定在不在,这是通过TCP三次握手实现的。

TCP小哥:在吗?有人想要去拜访您。

对方:在啊,随时欢迎。

TCP小哥:马上到。

这三次消息,要通过TCP/IP公司的司机来来回回运输三次。DNS查询也是同样的道理,这里就不赘述了。

通过这三次握手,TCP小哥建立起了一条chrome到3.4.5.6的通道。

chrome将http请求消息(我是谁,要找谁等),打包给了TCP小哥,寄件人IP地址:2.2.2.2 门牌号:23755。收件人IP地址:3.4.5.6 门牌号:80

然后TCP小哥联系了司机,将包裹送到了3.4.5.6的80门牌号上。

 

六 Nginx的工作原理

3.4.5.6的80门牌号的门卫是nginx老大爷。老大爷一看,是送给家里的xiaoweigod.com的。

路上老大爷看了下nginx.conf里找人的顺序:首先找index.php,如果找不到就找index.htm,再找不到就找index.html。

于是敲开了xiaoweigod.com的门,里面只有index.html在家。index.html头也不回地告诉nginx老大爷,告诉chrome,我们已经搬家了,去找

https://www.xiaoweigod.com(强制跳转)。

 

七 https加密原理

chrome收到了这个消息,立马又重复了上面的所有步骤,联系了“黄页公司”DNS,费了很大一番周折,找到了 www.xiaoweigod.com的IP地址。

其实这两次访问,整体流程相似,不一样的地方如下:

查找到 www.xiaoweigod.com的IP地址后,chrome这回没有直接把包裹给TCP小哥,而是联系了TLS安保大叔,让他全权负责包裹的安全问题,确保包裹在运输过程中的安全,即包裹的内容保密,包裹内容不能被篡改、替换。

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

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

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

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

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

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

image.png

TLS大叔不放心,验证了下证书,过程如下:

1. 用DigiCert Global Root CA的公钥解密证书Encryption Everywhere DV的签名

作为一个权威CA,已经被浏览器预先安装在可信任根证书列表,那么我们信任该CA的一切,当然包括其公钥,在该证书里包含了明文的公钥。

解开了,证明是该CA私钥加密的,由于CA私钥只有CA知道,证书有效,并信任Encryption Everywhere DV的公钥。

2. 同样原理用Encryption Everywhere DV的公钥解密DigiCert Global Root CA的签名。

如果上述2个步骤都成功了,就有了xiaoweigod.com的公钥。

3. 再检查下证书的有效期,如果没有过期,那么进入下一个步骤。

TLS大叔用“xiaoweigod.com“公钥加密一段随机的字符串,发送给TLS服务器。

TLS服务器用自己的私钥解密,得到明文字符串。

至此,双方分享了这个神秘的字符串,双方还有早前分享的随机码(nonce),双方使用同样的算法,可以推导出相同的master key,进而推导session key、HMAC key

Session Key用于加密/解密数据, HMAC Key主要用于保护数据的完整性,以防被第三方篡改。

整个TLS沟通过程就算完成了,TLS大叔把浏览器扔给自己的包裹,外面加了一层保险箱,密码锁(session key)只有TLS大叔、TLS服务器知道。

然后TLS大叔把包裹给了TCP小哥,TCP小哥看了下包裹,没啥两样,就是收件人的门牌号从80变成了443。

包裹到达后,443门牌号的门卫是TLS服务器,TLS服务器用自己的密码打开了包裹,包裹里有个小纸条,上面写着“Application Data =http”,知道这是http的东西,于是转手又让nginx老大爷把包裹送到 www.xiaoweigod.com的房间。

 

八 CDN(内容分发网络)原理

这回nginx老大爷一看index.php不在家,但是留了个字条,说对方如果要图片这些静态资源,那么直接给他,如果要找我们,请到IP地址:5.6.7.8来找我。没办法,nginx老大爷又委托TLS大叔跟对方的服务器5.6.7.8的TLS对接了下,商量下包裹加密,又TCP/IP快递公司,把包裹寄到了5.6.7.8的443门牌,送给了index.php。index.php发现需要主页,这需要进行计算。于是找来了php家族,计算完了又把主页打包成了html样式,返回给了chrome。

chrome收到了html样式的包裹,这是一种标记语言,需要经过解释才能把原来的页面还原出来。

于是chrome又埋头计算,终于通过里面写的规则,把图片文字拼拼凑凑,拼成了一个完整的页面,展示给了小明。

 

小明怎么也不会想到,按下了一次回车,在后台居然触发了这么大的计算量。。。

 

后记

对于以上的内容,这里我用稍微专业点的语言解释一下:

访问网址,首先通过域名查询IP地址。

浏览器会先查询hosts文件,然后查询内存中是否有对应的DNS缓存。如果电脑连接路由器上网,而DNS又是自动获取的话,DNS服务器就会被指定为路由器(局域网网关),如果局域网中没人访问过这个地址,那么在路由器的内存中不会存在这条DNS解析记录。于是又往上查找各层级的DNS服务器,从家里到区,到城市的DNS服务器,能不能找到缓存,取决于这个区域有没有人访问过这个域名。一直查到最上层,如果都没有找到的话,就会请求根域名服务器,从找到com域名服务器地址,再从com上找到xiaoweigod二级域名服务器地址….以此类推,最终找到完整域名的服务器地址。

找到地址后,是一个CNAME形式,解析到了阿里云CDN的DNS服务器上,阿里云的DNS服务器又通过用户的访问IP判断出用户的地理位置,返回最靠近用户的CDN服务器地址。CDN通俗点说,就是把你的网站资源镜像到全国各地的服务器上,从而实现不同地区用户的访问加速。

用户通过这两层DNS查询后,得到了离自己最近的CDN服务器地址,访问这个地址,CDN服务器根据配置的缓存规则,返回了静态资源,其他则通过访问源服务器进行返回(CDN回源)。

因为对应xiaoweigod.com这个地址,我只放了一个index.html。访问这个页面,会自动跳转到 https://www.xiaoweigod.com。浏览器访问xiaoweigod.com后,又继续访问https://www.xiaoweigod.com,此时通过两次DNS查询,CDN返回图片,js,css等静态资源,然后php的内容则通过CDN回源,源服务器的php计算后,转化为html样式,返回给访问者。

 

你对 xiaoweigod.com的一次访问,一共触发了4次完整的DNS查询,1次www强行跳转,1次https强行跳转,1次CDN回源,2次CDN地址解析,更有数不清的资源文件从各个地方被传输到了你的电脑。这些都是通过TCP的三次握手协议,网关,ARP,UDP,nginx,CDN,DNS服务器联合工作。想想人类的智慧还真是可怕啊。。。

赞(9) 打赏
未经允许不得转载:小伟博客 » 当你在浏览器中输入了本站网址并回车后,产生了哪些技术步骤?

评论 4

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  1. #1

    右下角的小人挺有意思的

    SEO学习博客9个月前 (02-11)回复
    • misery

      哈哈哈哈哈 很可爱的看板娘

      misery9个月前 (02-15)回复
  2. #2

    学习了

    uv喷绘4个月前 (08-02)回复

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏