浏览器DNS域名解析
-
浏览器缓存：浏览器会按照一定的频率缓存 DNS 记录。
-
操作系统缓存：如果浏览器缓存中找不到需要的 DNS 记录，那就去操作系统中找。
-
路由缓存：路由器也有 DNS 缓存。
-
ISP 的 DNS 服务器：ISP 是互联网服务提供商(Internet Service Provider)的简称，ISP 有专门的 DNS 服务器应对 DNS 查询请求。
-
根服务器：ISP 的 DNS 服务器还找不到的话，它就会向根服务器发出请求，进行递归查询（DNS 服务器先问根域名服务器.com 域名服务器的 IP 地址，然后再问.baidu 域名服务器，依次类推）
之后我们再来了解一下小知识
七层模型
通常我们的七层模型是应用层、 表示层、 会话层、 传输层、 网络层、 数据链路层、 物理层,通过UDP或者TCP方式去传输数据的步骤大致如下：
发送端(数据) -> 应用层 -> 传输层（UDP协议只会给数据增加一个UDP头标识）-> 网络层
接收端 -> 网络层（得到数据）-> 传输层(UDP去除报文头) -> 应用层
UDP 和 TCP 的区别是什么？
UDP
- 特性
-
UDP协议是面向无连接的，也就是说不需要在正式传递数据之前先建立双方的连接。
-
UDP只是数据报文的搬运工，不保证有序且不丢失的传递到对端。
-
UDP没有任何控制流量的算法。
我们这里剖析一下UDP的特性。第一点，面向无连接，也就是说不需要在发送数据之前进行三次握手，想发数据就可以发送，不会对数据报文进行任何的拆分和拼接；而第二点和第三点可以合在一起说，没有任何控制流量的算法，你可以理解为不会根据网络的信号延迟等问题调节数据传输的速率，也就是说，在客户端网络不太友好的时候，网络延迟，网络传输速率比UDP的传输速率更小，此时UDP不会进行调节数据传输的速率，那么在客户端接收这一部分数据就会出现问题，可能会丢失或者乱序。最明显的就是广大网友打游戏卡顿的时候，就是这种问题。
- 不可靠性
1.体现在无连接，想发送数据就发送数据。
2.接收到什么数据就传递什么数据，不会备份数据，也不会关心对方是否已经正确的接收到了数据。
3.没有拥塞控制，一直以恒定的速度发送数据，网络条件不好的时候，可能会造成数据包丢失。
- 高效
UDP的头部开销小，只有8字节，而TCP有至少20个字节
- 应用场景
通常用于直播、视频通话、实时性游戏等
TCP
特性
-
传输之前需要建立连接
-
通过各种算法保证数据的有序且可靠传输
-
有拥塞控制
TCP头部字段
1. Sequence number：序号，保证了数据报文都是有序的，接收端可以通过序号顺序拼接报文
2. Acknowledgement number：该序号表示接收端期望接受的下一个字节的编号是多少，同时也表示上一个数据已经接收到了
3. window size：窗口大小，表示还能接受多少字节数据，用于流量控制
4. 标识符：
· URG=1：表示当前的数据包是紧急数据，那么该数据包一定会位于当前传输的数据包的最前面
· ACK=1：表示确定当前数据有效
· PSH=1：表示接收端应该立即把当前的数据包交给应用层，而不是等到缓存区存满再就提交
· RST=1：表示当前的TCP连接出现了严重问题，可能需要重新请求报文
· SYN=1：当SYN=1，ACK=0，表示当前报文段是一个请求报文，当SYN=1，ACK=1，表示当前报文段是一个同意建立连接的应答报文
· FIN=1： 表示当前报文段是一个释放连接的请求
-三次握手
1. 客户端向服务端发送连接请求报文，该报文段中包含自身的数据通讯初识序号，请求发送之后，客户端便就进入 SYN-SENT状态
2. 服务端接收到连接请求报文后，如果同意连接，则会发送一个应答，该应答中包含自身的数据通讯初识序号，发送完后便进入到SYN-RECEIVED状态
3. 客户端接收到连接应答后，还要向服务端发送一个确认接收到应答的报文，客户端便进入到ESTABLISHED状态，服务端接收到此次应答后也进入到ESTABLISHED状态
面试官：为什么TCP建立连接需要三次握手，明明两次就可以建立连接？
答： 假设客户端发送连接请求A，但是因为网络原因造成了超时，这时TCP会启动超时重传机制，重新发一个连接请求B，此时请求B顺利到达服务端，服务端应答完成建立了连接，然后接收数据完成后断开连接。假设这时请求A在两端关闭之后又抵达了服务端，那么此时服务端会认为客户端又需要建立连接，从而应答该请求进入SYN-RECEIVED状态，但是客户端其实是CLOSED状态，如果没有第三次握手，那么服务端就会一直等待，造成资源浪费。所以需要第三次握手来确认客户端已经收到了服务端发送的响应报文，服务器才会进入待连接的状态，
- 四次挥手
1. 客户端向服务端发送连接释放请求
2. 服务端接收到连接释放请求后，会告诉应用层要释放TCP连接，然后应答该连接释放请求，服务端进入CLOSE_WAIT状态，此时服务端不在接受客户端发送的数据了，【但是此时服务端仍然可以向客户端发送数据】
3. 如果服务端还没发完数据，会继续发送，完毕后会向客户端发送连接释放请求，自己便进入LAST_ACK状态
4. 客户端接收到释放请求后，向服务端发送应答确认，此时客户端进入TIME_WAIT状态，该状态会持续2MSL（报文在网络中生存的最大时间）时间，若该时间段内没有服务端的请求，就会进入到CLOSED状态。服务端接受到应答后也会进入CLOSED状态
面试官：为什么客户端要进入 TIME_WAIT状态，等待2MSL时间才进入CLOSED状态？
答：为了保证服务端能收到客户端的确认应答，如果客户端直接进入CLOSED状态，最后的确认应答万一因为网络问题没有送达，那么就会造成服务端不能正常关闭。（防止网络问题，造成报文发送失败，所以等待一个报文在网络存在的最大时长）
总结
这就是面试官在面试的时候问的一些相关的问题，我是小白，咱们一起学习！
