打开浏览器输入URL发生了什么(详细)

​    又到周六了~今天没恰到鸡(吐槽下PUBG怎么每周都更新。。每次还这么大动不动好几个g外挂还这么多。。。)，因为PUBG得更新很久突然想玩一下弹弹堂怀念一下，结果忘密码了，点找回密码密保问题是“你的梦想是什么”，试一个不对试一个不对试一个不对，我才反应过来，原来我忘记的不是密码。。是青春

    本来今天想鸽以咏志的，想想还是坚持一下写一下吧

每个经历过面试的人应该都回答过，打开浏览器输入URL发生了什么，当然了，腿哥肯定是没经历过，毕竟腿哥是被保送的

应用层 DNS域名解析服务

浏览器先检查自身缓存中有没有被解析过的这个域名对应的ip地址，如果浏览器缓存中没有，则会检查操作系统缓存(hosts文件)中有没有对应的已解析过的结果。没有的话再去依次找路由器缓存、本地DNS服务器

DNS中递归查询和迭代查询的区别

1、 递归查询：一般客户机和服务器之间属递归查询，即当客户机向DNS服务器发出请求后，若DNS服务器本身不能解析，则会向另外的DNS服务器发出查询请求，得到结果后转交客户机。

2、 迭代查询（反复查询）：一般DNS服务器之间属迭代查询，如：若DNS2不能响应DNS1的请求，则它会将DNS3的IP给DNS2，以便其再向DNS3发出请求。

传输层TCP传输报文 （三次握手）

• 第一次握手：建立连接

　　客户端发送连接请求报文段，将SYN（同步序列编号（Synchronize Sequence Numbers））值设为1，Sequence Number为x。客户端进入SYN_SEND状态，等待服务器的确认。

• 第二次握手：服务器收到SYN报文段

　　服务器收到客户端SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number(确认号)为x+1(Sequence Number+1)。同时，自己还要发送SYN请求信息，将SYN值设为1，Sequence Number设为y。服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，服务器进入SYN_RECV状态。

• 第三次握手：客户端收到SYN+ACK报文段

　　客户端收到服务器的SYN+ACK报文段后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

        为什么是三次握手
        在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误
“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

网络层IP协议查询MAC地址

    IP协议的作用是把TCP分割好的各种数据包传送给接收方。而要保证确实能传到接收方还需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一对应的关系，一个网络设备的IP地址可以更换，但是MAC地址一般是固定不变的。ARP协议可以将IP地址解析成对应的MAC地址。当通信的双方不在同一个局域网时，需要多次中转才能到达最终的目标，在中转的过程中需要通过下一个中转站的MAC地址来搜索下一个中转目标。在找到对方的MAC地址后，就将数据发送到数据链路层传输。这时，客户端发送请求的阶段结束。服务端收到请求数据打包返回给客户端，浏览器再根据Content-type资源解析，如果是HTML则渲染成页面展示

    

关注微信公众号：在下uptown