📑前言
本文主要SpringBoot通过DevTools实现热部署的文章，如果有什么需要改进的地方还请大佬指出⛺️
🎬作者简介：大家好，我是青衿🥇
☁️博客首页：CSDN主页放风讲故事
🌄每日一句：努力一点，优秀一点
目录
文章目录
- 📑前言
- **目录**
- TCP首部格式？
- TCP 和 UDP 的区别
- 三次握手
- 为什么是三次握手，而不是其他的握手次数呢？
- 为什么要三次握手，难道四次或更多次不可以吗？
- 四次挥手
- 📑文章末尾
TCP首部格式？
字段的含义
源端口: 占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
目的端口： 占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
序号: 占32比特，取值范围[0,2^32-1]，序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号。
确认号： 占32比特，取值范围[0,2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。
确认标志位ACK： 取值为1时确认号字段才有效；取值为0时确认号字段无效。TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。
校验和： 占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
紧急指针： 占16比特，以字节为单位，用来指明紧急数据的长度。
填充： 由于选项的长度可变，因此使用填充来确保报文段首部能被4整除(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)。
ACK：
- 报文中的ACK标志设置为1，表示该报文可以对接收到的报文进行确认。
- 一般除了第一个请求连接的报文没有设置ACK外，其余报文基本上都设置了ACK，因为携带了ACK的报文需要对接收到的报文进行确认。
SYN：
- 报文当中的SYN被设置为1，表明该报文是一个连接建立的请求报文。
- 只有在连接建立阶段，SYN才被设置，正常通信时SYN不会被设置。
FIN：
- 报文当中的FIN被设置为1，表明该报文是一个连接断开的请求报文。
- 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置
TCP 和 UDP 的区别
三次握手
客户端与服务端建立连接的过程称为三次握手。
三次握手是 TCP 连接的建立过程。在握手之前，主动打开连接的客户端结束 CLOSE（关闭） 阶段，被动打开的服务器也结束 CLOSE（关闭） 阶段，并进入 LISTEN（监听） 阶段。随后进入三次握手阶段：
1.首先客户端向服务器发送TCP连接请求报文段，并等待服务器确认，其中：
●同步位SYN被设置为1, 表明这是一个TCP连接请求报文段。
●序号字段seq被设置了一个初始值x作为TCP客户进程所选择的初始序号。（x 一般取随机数）；
●随后客户端进入 SYN-SENT 阶段。
2.服务器接收到客户端发来的 TCP连接请求报文段后，进行确认后结束 LISTEN 阶段，并返回TCP连接请求确认报文段，其中：
●该报文段首部中的同步位SYN和确认位ACK 都设置为1，表明这是一个TCP连接请求确认报文段；
●序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号；
●确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号seq的确认，随后服务器端进入 SYN-RCVD 阶段。
3.客户端接收到发送的 TCP连接请求确认报文段后，明确了从客户端到服务器的数据传输是正常的，最后还要向TCP服务器进程发送一个普通的TCP 确认报文段，其中：
●该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段 。
●序号字段seq 被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x +1。
●确认号字段ack被设置为y + 1，这是对TCP服务器进程所选择的初始序号的确认。
●随后客户端进入 ESTABLISHED。
4.当服务器端收到来自客户端确认收到服务器数据的报文后，得知从服务器到客户端的数据传输是正常的，从而结束 SYN-RCVD 阶段，进入 ESTABLISHED 阶段，从而完成三次握手。
为什么是三次握手，而不是其他的握手次数呢？
1.防止已失效的连接请求报文段突然又传送到了TCP服务器进程因而导致错误和资源浪费。
●假设采用两报文握手，TCP客户进程发出一个TCP连接请求报文段，但是该报文段由于网络原因滞留了，这必然会造成该报文段的超时重传。
●假设重传的报文段被TCP服务器进程正常接收，TCP服务器进程给TCP客户进程发送一个TCP连接请求确认报文段，并进入连接已建立状态。他们可以相互传输数据，之后可以通过四报文挥手来释放连接，TCP双方都进入了关闭状态。
●一段时间后，失效的TCP连接请求报文段到达了TCP服务器进程，TCP服务器进程随即给TCP客户进程发送TCP连接请求确认报文段并进入连接已建立状态。
●但由于TCP客户进程并没有发起新的TCP连接请求，并且处于关闭状态，因此不会理会该报文段。而TCP服务器进程一直等待TCP客户进程发来数据，这将白白浪费TCP服务器进程所在主机的很多资源。
2.三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
●第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；
●第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
● 第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
●可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
3.告知对方自己的初始序号值，并确认收到对方的初始序号值。
●TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。
●这两个字段的值会在初始序号值的基础上递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。
为什么要三次握手，难道四次或更多次不可以吗？
因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值的确认，也就无需再第四次握手了。
●第一次握手：服务端确认“自己收、客户端发”报文功能正常。
●第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
●第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信
四次挥手
当双方结束通信，断开连接的过程称为四次挥手。
四次挥手即 TCP 连接的释放，这里假设客户端主动释放连接。在挥手之前主动释放连接的客户端结束ESTABLISHED 阶段，随后开始四次挥手：
1、首先客户端向服务器发送一段 TCP 报文表明其想要释放 TCP 连接，其中：
●终止位FIN和确认为ACK的值都被设置为1，表示请求释放连接；
●序号为 Seq = u；
●确认号ack = v；
●随后客户端进入 FIN-WAIT-1 阶段，即半关闭阶段，并且停止向服务端发送通信数据。
2、服务器接收到客户端请求断开连接的 FIN 报文后，结束 ESTABLISHED 阶段，进入 CLOSE-WAIT 阶段并返回一段 TCP 报文，其中：
● 标记位为 ACK = 1，表示接收到客户端释放连接的请求；
● 序号为 Seq = v；
●确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。
●随后服务器开始准备释放服务器端到客户端方向上的连接。
客户端收到服务器发送过来的 TCP 报文后，确认服务器已经收到了客户端连接释放的请求，随后客户端结束 FIN-WAIT-1 阶段，进入 FIN-WAIT-2 阶段。
3、服务器端在发出 ACK 确认报文后，服务器端会将遗留的待传数据传送给客户端，待传输完成后即经过 CLOSE-WAIT 阶段，便做好了释放服务器端到客户端的连接准备，再次向客户端发出一段 TCP 报文， 其中：
● 标记位为 FIN = 1 和 ACK = 1，表示已经准备好释放连接了；
●序号为 Seq = w；
● 确认号 ack = u + 1，这是对之前收到的TCP连接释放报文段的重复确认。
随后服务器端结束 CLOSE-WAIT 阶段，进入 LAST-ACK 阶段。并且停止向客户端发送数据。
4、客户端收到从服务器发来的 TCP 报文，确认了服务器已经做好释放连接的准备，于是结束 FIN-WAIT-2 阶段，进入 TIME-WAIT 阶段，并向服务器发送一段报文，其中：
●标记位为 ACK = 1，表示接收到服务器准备好释放连接的信号；
● 序号为 Seq= u + 1，表示是在已收到服务器报文的基础上，将其确认号 ack 值作为本段序号的值；
● 确认号为 ack= w + 1，这是对所收到的TCP连接释放报文段的确认。
随后客户端开始在 TIME-WAIT 阶段等待 2 MSL。服务器端收到从客户端发出的 TCP 报文之后结束LAST-ACK 阶段，进入 CLOSED 阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完 2 MSL 之后，结束 TIME-WAIT 阶段，进入 CLOSED 阶段，由此完成「四次挥手」。
📑文章末尾
