[网络协议]听说你是玩网络的？那这些知识你应该知道【基础篇(二)】

欢迎访问我的blog http://www.codinglemon.cn/

立个flag，8月20日前整理出所有面试常见问题，包括有：
Java基础、JVM、多线程、Spring、Redis、MySQL、Zookeeper、Dubbo、RokectMQ、分布式锁、算法。

3.网络篇

3.1 OSI协议与TCP/IP协议（不是特别常问）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KKZ1UKTp-1626856511500)(http://www.codinglemon.cn/upload/2021/07/image-4bcf24cc332241ceaed93430e5989b4b.png)]
一般我们中和OSI七层协议与TCP/IP四层协议，中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构。简单介绍一下各个层的作用：

1. 应用层：应用层的任务是通过应用进程间的交互来完成特定网络应用。例如域名系统DNS、HTTP协议、SMTP协议等。
2. 运输层：运输层的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。
   运输层主要使用以下两种协议:
   1. 传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
   2. 用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。
3. 网络层：在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。由于网络层使用IP 协议，因此分组也叫 IP 数据报 ，简称数据报。
4. 数据链路层：数据链路层通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
5. 物理层：物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。

3.2 TCP 三次握手和四次挥手(问网络必问！)

3.2.1 TCP三次握手

TCP 是面向连接的协议，所以使用 TCP 前必须先建立连接，而建立连接是通过三次握手而进行的。

1. 第一次握手：建立连接时，客户端发送syn包（seq=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

2. 第二次握手：服务器收到syn包，必须确认客户端的SYN（ack=j+1），同时自己也发送一个SYN包（seq=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。

3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。（注意：第三次握手时可以携带数据的，前两次不行，因为还没有确定是否连接成功）

总结：

1. 第一次： client–>server: SYN, seq = j , 状态：SYN_SENT
2. 第二次： server–>client: SYN+ACK, ack = j+1, seq = k, 状态： SYN_RECV
3. 第三次： client–>server: ACK, ack = k+1 状态：ESTABLISHED

3.2.2 为什么是三次握手？不是两次、四次？

有三方面的原因：

1. 阻止历史重复连接的初始化：客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下：

   1. 一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
   2. 那么此时服务端就会回一个 SYN + ACK 报文给客户端；
   3. 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
      如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接。

2. 同步双方初始序列号：TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：

   • 接收方可以去除重复的数据；
   • 接收方可以根据数据包的序列号按序接收；
   • 可以标识发送出去的数据包中， 哪些是已经被对方收到的；

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

3. 避免资源浪费：如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

总结：

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因：

• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；

• 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

3.2.3 TCP四次挥手

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态

• 服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。

• 客户端在经过 2MSL 一段时间后，自动进入 CLOSE状态，至此客户端也完成连接的关闭。

总结：

1. 第一次：client–>server: FIN = 1 , seq = u, 状态：ESTABLISHED
2. 第二次： server–>client: ACK = 1, seq = v, ack = u+1, 状态：CLOSED_WAIT_1
3. 第三次： server -->client: 单向数据传送，FIN = 1，ACK = 1,seq = w, ack = u+1, 状态：CLOSED_WAIT_2
4. 第四次： client–>server: ACK = 1, seq = u+1, ack = w+1,状态：TIME_WAIT

3.2.4 为什么挥手需要四次？

再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

• 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。

3.2.5 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们知道网络是不可靠的，有可以最后一个ACK丢失，一旦最后一个ACK丢失，那么连接没有完全关闭，服务端就要保持这个连接，但是客户端已经关闭了，这样会消耗服务端的资源。
所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

3.2.6 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

3.3 超时重传、拥塞控制、滑动窗口

3.3.1 超时重传

TCP每发送一个报文段，就会为这个报文段开启一个定时器，如果定时器溢出时仍然没有收到接收端的应答报文，那么TCP就认为这个报文段在传输过程中丢失，然后重新发送这个报文段。这便是超时重传机制。

3.3.2 拥塞控制

超时重传是为了解决数据丢失的问题，而数据丢失的原因很大程序上是由于传输路径拥塞导致的。在正常的传输过程中，数据是从一个路由器跳到下一个路由器，每个路由器都有自己的缓冲区，新来的数据会存放在缓冲区中，与此同时路由器也在不断地将缓冲区中的数据发送给下一个路由器。但是如果某个路由器接收数据的速率大于发送数据的速率，就会导致缓冲区数据累积，最终填满缓冲区。此时如果再有数据到来，缓冲区已经无法容纳它们，只能将它们丢掉，造成数据丢失。

有4种常用的缓解拥塞的算法：

1. 慢启动算法：慢启动算法的核心思想是当连接刚建立时允许发送的报文段个数很少，随后不断增加允许发送的报文段个数直到规定的阀值
2. 拥塞避免算法：拥塞避免算法是当拥塞窗口增长到一定程度时采取的一种算法，该算法的核心思想是减缓拥塞窗口的增加速度，每接收到一个应答就将拥塞窗口加一
3. 快速重传算法：快速重传算法的核心思想就是当发送端接收到了三个相同的应答报文（携带的希望下次接收的序列号相同）时，就假设以该序列号结尾的那个报文段丢失，所以发送端不必等到定时器溢出就会重传丢失的报文段
4. 快速恢复算法：快速重传算法仅仅是为了尽早发现丢失报文段并重传，并不能确定网络发生拥塞（如果发生严重的拥塞，就不会一连有好几个报文段到达接收端，也就不会一连收到接收端发来的好几个重复应答报文段），所以不会执行慢启动算法将拥塞窗口降为1。

3.3.3 滑动窗口

滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。

3.4 键入网址后，期间发生了什么？（常问）

1. 浏览器做的第一步工作是解析 URL。
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O5VUCnGL-1626856511506)(http://www.codinglemon.cn/upload/2021/07/image-09c93eb7957248598a77fba104c7b613.png)]

2. 生产 HTTP 请求信息：对 URL 进行解析之后，浏览器确定了 Web 服务器和文件名，接下来就是根据这些信息来生成 HTTP 请求消息了。

3. 真实地址查询 —— DNS：查询服务器域名对应的 IP 地址

   1. 客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。

   2. 本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器，根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。

   3. 根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，给 .com 顶级域名服务器地址。

   4. 本地 DNS 收到顶级域名服务器的地址后，发起请求查询www.server.com 的 IP 地址。

   5. 顶级域名服务器告知 www.server.com 区域的权威 DNS 服务器的地址。

   6. 本地 DNS 于是转向问权威 DNS 服务器，查询www.server.com对应的IP。

   7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。

   8. 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

4. 把 HTTP 的传输工作交给操作系统中的协议栈：把 HTTP 的传输工作交给操作系统中的协议栈。

5. 协议栈的内部分为几个部分，分别承担不同的工作。上下关系是有一定的规则的，上面的部分会向下面的部分委托工作，下面的部分收到委托的工作并执行。

6. 协议栈上半部分的两块分别是负责收发数据的 TCP 和 UDP 协议，它们会接受应用层的委托执行收发数据的操作。

7. 协议栈的下面一半是用 IP 协议控制网络包收发操作，上传数据时，数据被切分成一块块的网络包。

8. 在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。

9. 如果 HTTP 请求消息比较长，超过了 MSS 的长度， TCP 就需要把 HTTP 的数据拆解一块块的数据发送，拆分出来的每一块数据都会被放进单独的网络包中。也就是在每个被拆分的数据加上 TCP 头信息，然后交给 IP 模块来发送数据。

10. 连接成功后发送HTTP(s)请求。

11. web服务器接收请求，决定使用哪个请求处理程序（接受请求并生成HTML）

12. 请求处理程序获取请求头的参数和cookies，并更新信息。

13. 生成HTML压缩并返回。

14. 浏览器获取并显示，遇到其他需要的资源，再向服务器请求。

3.5 HTTP和HTTPS

3.5.1 HTTP

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

3.5.2 HTTPS

HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。

3.6 序列化

序列化：将对象写入到IO流中
反序列化：从IO流中恢复对象
意义：序列化机制允许将实现序列化的Java对象转换位字节序列，这些字节序列可以保存在磁盘上，或通过网络传输，以达到以后恢复成原来的对象。序列化机制使得对象可以脱离程序的运行而独立存在。
使用场景：所有可在网络上传输的对象都必须是可序列化的，比如RMI（remote method invoke,即远程方法调用），传入的参数或返回的对象都是可序列化的，否则会出错；所有需要保存到磁盘的java对象都必须是可序列化的。通常建议：程序创建的每个JavaBean类都实现Serializeable接口。