在浏览器中输入网址后，网站便打开了。
你可能想不到，就这一个简简单单的步骤，背后藏着多么复杂的技术步骤。
为了方便理解，我们请出本文的主人公赵四和刘能，通过他们的视角，来了解从用户输入网址，到打开网站到底经历了什么。
有一天，赵四听说刘能建了一个个人网站，想去一探究竟。于是他在浏览器中输入了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协议，刘能想要访问赵四的网站，必须先问赵四在不在，要对方在才行。通常的要这样联系对方：
| “在吗?想去你家做客。”
赵四：“我在，欢迎啊!” “好的，马上就到” |
经过这三次对话(三次握手)后，包裹便可以顺利到达目的地。
刘能终于打开了赵四的个人网站。
刘能打死也不知道，自己一个动作，会产生如此复杂的计算量……
