在浏览器中输入网址后，会有哪些神奇的事情发生？

在浏览器中输入网址后，网站便打开了。

你可能想不到，就这一个简简单单的步骤，背后藏着多么复杂的技术步骤。

为了方便理解，我们请出本文的主人公赵四和刘能，通过他们的视角，来了解从用户输入网址，到打开网站到底经历了什么。

有一天，赵四听说刘能建了一个个人网站，想去一探究竟。于是他在浏览器中输入了zhaosi.com的域名并回车。

 

 

 

浏览器是刘能的小弟，刘能不论下什么命令，浏览器都会乖乖照做。但浏览器也是一个有原则的人，一些明显错误的命令，它会马上反馈给刘能，告诉他这是不对的。

浏览器首先会检查刘能输入的网址是否合法。如果刘能输入的网址zha.osi.com或者zhao@si.com那么浏览器会立即告诉刘能，这是不对的。

为了自己方便，刘能下达的命令经常很模糊，比如这次访问网站，他直接输入zhaosi.com，并没有告诉浏览器是用http协议还是https协议。

 

多嘴去问刘能又不太好，于是浏览器有自己的处理方法。如果老板没有明确告诉我，那么我就默认使用http协议，如果明确告诉我要使用https，那么就打开https://zhaosi.com这个网站。

以上只是万里长征的第一步。如果要建立刘能和赵四网站之间连接，打开zhaosi.com还有很长的路要走。

第一个拦路虎是TCP/IP，这是一家很大的公司，垄断了整个快递行业，如果你想寄快递，只能通过这家公司，大家也都只认它。

它还不怕挨罚，前两天阿里巴巴因垄断行为被罚180亿，TCP/IP只是笑笑不说话~

 

这家公司有一个规定：只认IP，不认网址（域名）。

你告诉TCP/IP要把这个包括寄到赵四的网站没用，必须告诉它准确的地址，精确到门牌号（IP）。

可刘能并不知道赵四的网站IP地址是多少，咋办？

于是浏览器找到了DNS公司，它的主营业务类似于114查号台。114可以帮忙查电话号码，而DNS可以帮忙查域名对应的IP地址。

 

刘能告诉DNS赵四的网站地址是zhaosi.com，委托它帮忙查询一下对应的IP地址，再联系TCP/IP。

DNS接受委托后，开始查询。先查查自己内存里的DNS Cache，没有找到！再查查本地硬盘的host文件，也没有找到。最后它只能联系自己的DNS服务器8.8.8.8。

漫长的查IP地址之路开始了。

DNS将自己的查询打好包。

收件人地址：8.8.8.8

寄件人：1.1.1.1

负责收件的是UDP，接过包裹后，他在上面写了几笔：

收件人53号

发件人56002号

之所以要写上门牌号，是因为一个地址可能对应很多个门牌号。

干完这些事后，他联系IP司机，请求他把包裹送到目的地。IP司机查了IP路由表，发现要出关，出关的要求是，司机必须知道MAC地址。

怎么办？IP司机想了一个好方法，问问当地的想到ARP不就行了？

ARP立马喊了一声，网关MAC地址妥妥的收入囊中：xx.xx.xx.xx.xx.xx

有了MAC地址，IP司机顺利出关，上了Internet高速公路，一路狂奔……

最终包裹到达DNS服务器，DNS服务器一看，zhaosi.com的IP地址，刚好在本地缓存里有，直接告诉浏览器即可。

如果本地缓存没有，怎么办？

DNS会向根域名服务器发起查询，他会先问根域名服务器：“你有zhaosi.com的IP地址吗？”

根域名服务器告诉他：“去com服务器找。”

接着他去问com服务器，一层层下来，终于知道zhaosi.com的IP地址了，最后再告诉浏览器。

历经千辛万苦，DNS不负使命，终于拿到IP地址，这下可以联系TCP/IP公司了。

根据TPC协议，刘能想要访问赵四的网站，必须先问赵四在不在，要对方在才行。通常的要这样联系对方：

“在吗？想去你家做客。”

赵四：“我在，欢迎啊！”

“好的，马上就到”

经过这三次对话（三次握手）后，包裹便可以顺利到达目的地。

 

刘能终于打开了赵四的个人网站。

刘能打死也不知道，自己一个动作，会产生如此复杂的计算量……