趁着马上就要面试的这个机会,将网络相关的知识进行一个串联复习。前端网络会在面试中遇到的问题其实并不是很多,核心的内容主要是TCP建立的的三次握手、TCP断开的四次挥手、DNS解析的过程、以及前端跨域等。话不多说,我们直接进入正题。
一、从URL到页面展示的过程
这是一道非常经典的前端网络面试题,“从在浏览器中输入网站并进入至页面展示的过程中网络层面发生了什么? ”。将浏览器与服务器分为两个主体,这道题便更容易进行描述:
- 首先,输入网址之后浏览器(客户端)会对输入的网址进行DNS解析,得到对应网站的IP地址。
- 客户端会与目标IP的服务器通过TCP三次握手建立TCP连接。
- 客户端向目标服务器发起对应的HTTP资源获取请求(HTTP请求建立在TCP连接的基础上)。
- 服务器返回对应的请求资源。
- 浏览器得到HTML资源,下载HTML中的静态资源。
- 浏览器引擎进行解析对应的资源,并通过浏览器的渲染引擎渲染页面。
- 客户端与服务器四次挥手,断开TCP连接。
上述便是从URL到页面展示的过程中发生的过程。从上述的过程中我们看到三个关键部分:三次握手、四次挥手以及DNS解析,接着我们从DNS解析的过程进行入手。
二、DNS域名解析
在认识DNS解析过程之前,我们应该清楚什么DNS(Domain Name Server 域名服务器)。举个简单的例子解释一下,比如说我们都知道的梦中豪宅”汤臣一品“。汤臣一品就可以理解为我们在页面中输入的网站名称,也就是域名。而实际上在地图上通过汤臣一品这个名称是无法直接找到它所在的地址的,因此我们需要通过”DNS解析“得到其真实的楼盘地址”上海市浦东新区花园石桥路28弄“。
那么将汤臣一品这个小区名称转换为上海市浦东新区花园石桥路28弄的过程,就相当于客户端将www.baidu.com转换为36.152.44.96这个IP地址的过程,这个过程便称之为DNS域名解析。
认识了什么是DNS、什么是DNS域名解析之后,我们需要认识到DNS解析有两种不同的方式,分别是递归查询与迭代查询。递归查询可以说是以本地域名服务器为中心(代理)进行域名的解析,而迭代查询则是以DNS客户端(本机)为中心进行域名的解析。具体的过程在小节中进行介绍。
1. 递归查询
递归查询是DNS默认的查询方式,这种方式的主要是通过根域名服务器至下级域名服务器递归查询对应DNS记录的一个过程。当根域名服务器中不存在对应结果,便会得到下一级对应权威域名服务器的IP地址,接着本地域名服务器会向根域名服务器返回的地址进行DNS查询,递归该过程直到从对应权威域名服务器得到DNS记录为止。得到记录后本地域名服务器会将记录缓存,再返回DNS客户端。
所有的查询过程都是通过本地DNS服务器完成的,相当于一个代理服务器,也是递归查询的一个特点,递归查询的示意图如下:
递归查询的具体流程:
- DNS客户端向DNS本地服务器查询目标域名的IP地址
- DNS本地服务器接收到查询请求后,首先查看本地的DNS缓存中是否存在对应的缓存,若存在则直接返回给DNS客户端。若不存在,则DNS本地服务器将相同的DNS查询请求发送给根域名服务器。
- 根域名服务器接收到查询请求后,将目标域名的顶级域名服务器IP地址返回给本地域名服务器。
- 本地域名服务器接收到对应地址后,重复步骤2向目标服务器发送相同的DNS查询请求。有可能从顶级域名服务器一直查询到三级、四级域名服务器,直到最终对应域名的权威域名服务器返回最终的查询记录给DNS本地域名服务器为止。待本地域名服务器将本次查询结果缓存后,将查询结果返回给DNS客户端。
2. 迭代查询
迭代查询与递归查询的流程大体是一致的,都是通过向根域名服务器至权威域名服务器查询DNS记录的过程。不同的便是,迭代查询的DNS查询请求都是由DNS客户端发出的,并不都是通过DNS本地服务器进行。迭代查询的示意图如下:
迭代查询的具体流程:
- DNS客户端向DNS本地服务器发起DNS查询请求。
- DNS本地服务器接收到请求后查询是否存在对应的缓存,若存在则直接返回。不存在则将根域名服务器的IP地址返回给DNS客户端。
- DNS客户端向根域名服务器发送相同的DNS查询请求。
- 根域名服务器接收到后返回对应的顶级域名服务器的IP地址。
- DNS客户端重复步骤2,直到查询到对应域名的权威域名服务器返回对应的DNS记录。
3. 总结
总而言之,递归查询与迭代查询之间的区别便是发送DNS查询的主体不同。打个比方,今天我丢了一把钥匙,递归查询就像我请了一位侦探来替我找这一把钥匙,与其他邻居之间的沟通都是由这个侦探完成,我只需要等待他找到钥匙之后交还给我。
迭代查询则是由我亲历亲为,我在一个个可能的地方寻找这一把钥匙,在这个过程中所有请求帮助的过程都是由我自己完成的。
三、TCP、三次握手、四次挥手
1.TCP
TCP(Transmission Control Protocol) 传输控制协议,是传输层的一种协议。TCP协议的特点是面向连接(发送数据前需要建立可靠连接) ,因此TCP协议建立的基础是三次握手,保证了数据传输的可靠性。同时TCP传输协议具备拥塞控制、重传机制、实时断开连接等机制,更加保证了数据在传输过程中的完整性。
TCP协议存在速度慢、效率低、占用资源以及容易受到攻击的缺点。
2.三次握手
三次握手是TCP协议用于建立可靠连接的一种方法,通常也称为TCP的“握手协议”。在三次握手中,两个通信的实体(例如客户端和服务器)通过发送和确认一系列特定的网络数据包(称为TCP报文段)以确认彼此之间的连接状态。
标识符与状态认识
在讲到三次握手之前,先与大家说明一下在三次握手的过程中可能出现的标识符、状态及其所要表达的含义。
- SYN:Synchronize Sequence Numbers 同步序列编号,是一个随机的序列号,用于表示发送方下一次要发送数据的序列号。
- ACK:Acknowledgement 确认字符,是一个确定序列号,值为上一条请求中的SYN+1,以确定连接的建立。
- SYN_SENT:在发送连接请求后等待匹配的连接请求,为客户端建立TCP连接的第一阶段。
- LISTEN:服务器监听客户端发送TCP连接请求的状态,服务器将长期处于LISTEN状态。
- SYN_REVD:服务器在接收客户端的连接请求后等待客户端确认连接的状态。
- ESTABLISHED:代表连接建立,可以进行数据传输的状态。客户端于向服务器发送确认请求后处于该状态,服务器于接收到客户端确认连接请求后处于该状态。
三次握手标准过程示意图
三次握手过程文字描述
- 第一次握手(SYN报文段):客户端向服务器发送一个SYN报文段,请求建立连接。此时客户端处于SYN_SENT状态,服务器处于LISTEN状态。
- 第二次握手(SYN-ACK报文段):服务器收到客户端的SYN报文段后,会向客户端发送一个SYN-ACK报文段,表示已经接受了连接请求。此时服务器处于SYN_RCVD状态,客户端处于ESTABLISHED状态。
- 第三次握手(ACK报文段):客户端收到服务器的SYN-ACK报文段后,会向服务器发送一个ACK报文段,用于确认建立连接。此时客户端处于ESTABLISHED状态,服务器也处于ESTABLISHED状态。
3.四次挥手
四次挥手是TCP协议用于关闭连接的一种方法,通常也称为TCP的“挥手协议”。在四次挥手中,两个通信的实体(例如客户端和服务器)通过发送和确认一系列特定的网络数据包(称为TCP报文段)来确认彼此之间的连接状态,从而安全地关闭连接。
标识符与状态认识
- FIN:FIN报文段的作用是告知对方自己已经完成了所有的数据传输,并且请求关闭连接。由主动关闭连接的一方发送。
- ESTABLISHED:连接建立状态。客户端与服务端默认处于该状态。
- FIN-WAIT-1:等待远程TCP的连接中断请求, 或先前的连接中断请求的确认。客户端发送FIN报文段(第一次挥手)后处于该状态。
- CLOSE-WAIT:等待中断请求。当服务端接收到客户端的关闭连接请求并发送确认报文段后处于该状态。
- FIN-WAIT-2:从远程TCP等待连接中断请求。客户端接收到服务端发来的ACK报文段之后客户端进入该状态。
- LAST-ACK:等待确认。当服务器完成所有数据传输后,向客户端发送FIN报文段后处于该状态。
- TIME-WAIT:等待远程接收。当客户端接收到服务端关闭报文并向服务器发送确认报文后处于该状态,将等待一段时间确保服务器接收到客户端发送的确认报文。
- CLOSE:连接关闭。客户端等待2MSL之后处于该状态,当服务端接收到客户端的关闭确认报文后处于该状态。
四次挥手示意图
四次挥手文字描述
- 客户端发送关闭请求报文(FIN报文段),此时客户端进入等待中断1(FIN-WAIT-1)状态。(第一次挥手)
- 服务端接收到客户端的请求报文后,向客户端发送确认报文(ACK报文段),此时服务端进入等待终端请求(CLOSE-WAIT)状态。(第二次挥手)
- 客户端接收到服务端的中断确认后,进入到等待中断2(FIN-WAIT-2)状态。服务端在这个阶段需要确认是否完成数据的传输,没有完成可继续发送。
- 服务端完成数据传输后向客户端发送关闭请求报文(FIN报文段),此时服务端进入等待确认(LAST-ACK)状态。(第三次挥手)
- 客户端接收到服务端发送的关闭请求报文后,向服务端发送关闭确认报文(ACK报文段),此时客户端进入到时间等待(TIME-WAIT)状态,将等待2MSL的时间,若期间服务端没有发送报文,则进入到关闭(CLOSE)状态。(第四次挥手)
- 当服务端接收到客户端发送的确认连接中断请求报文后,服务端进入关闭(CLOSE)状态。