一、TCP的三次握手
1. 三次握手的过程详解
参考文章：https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
其中比较重要的字段有：
（1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：
URG：紧急指针（urgent pointer）有效。
ACK：确认序号有效。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
FIN：释放一个连接。
需要注意的是：
不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1，两端配对。
1.”三次握手”的详解
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：
（1）第一次：客户端向服务端发送一段TCP报文
- SYN=1, Seq=X
（2）第二次：服务端接收到该报文后，返回一段TCP报文
- SYN=1 , ACK=1 ,Seq=y，ack=x+1
表示这是一条连接、确认报文，数据起始序列号为y，应答上一条 Seq =x 的报文
当客户端收到来自服务端的确认后，那么客户端就明确了自己客户端到服务器端的数据传输时正常可用的。
（3）第三次：客户端接收到服务端的确认后，明确了服务端可以接收到我的数据，并发送最后一条报文
- ACK=1 , Seq=X+1，ack=y+1
这是一条客户端发送给服务端的确认报文。
当服务器接收到来自客户端确认的确认之后，就明确了自己服务器端到客户端的数据传输是正常可用的。
举个栗子：把客户端比作男孩，服务器比作女孩。用他们的交往来说明“三次握手”过程：
（1）男孩喜欢女孩，于是写了一封信告诉女孩：我爱你，请和我交往吧！;写完信之后，男孩焦急地等待，因为不知道信能否顺利传达给女孩。
（2）女孩收到男孩的情书后，心花怒放，原来我们是两情相悦呀！于是给男孩写了一封回信：我收到你的情书了，也明白了你的心意，其实，我也喜欢你！我愿意和你交往！;
写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。
（3）男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！
女孩收到男孩的回信之后，也很开心，因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意，之后就快乐地交流起来了~~
这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。
2. 为什么要进行第三次握手？
由此比喻举例来论证，如果没有第三次握手，那么，服务端就不知道我的 “这封信” 到底有没有安全送到 客户端手中。这期间服务端就是一直处于焦急等待结果的状态，（创建连接也不是，关闭连接也不是，服务端的端口还得一直打开），
可能第二次握手的信息在链路中丢失了，等到客户端因超时重传重新发出请求时，服务器就会重新开启一个端口连接。那么服务器端上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器端开销的严重浪费。
还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。
所以我们需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待。
总结：
“第三次握手”是客户端向服务器端发送数据，就是要告诉服务器，客户端有没有收到服务器“第二次握手”的数据。
若是 “收到了” 的信息，服务器接收后明确了对方的情况和自己回信的情况，就正常建立TCP连接，
否则建立TCP连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。
二、TCP的四次挥手
1. 四次挥手的过程详解
（1）首先客户端想要释放连接，向服务器端发送一段TCP报文
- FIN=1 , seq=u
随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在 客户端到服务器端方向 上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
（2）服务器端接收TCP报文后，确认了客户端想要释放连接，随后服务器端进入CLOSE-WAIT阶段（半关闭状态），并返回一段TCP报文，
- FIN=1, ACK=1,seq=v，ack=u+1
随后服务器端开始准备释放服务器端到客户端方向上的连接。
客户端收到 “第二次挥手”，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段。
前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了对方的情况。于是，可以确认关闭客户端到服务器端方向上的连接了
（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报，
- FIN=1 , ACK=1, seq=w, ack=u+1
随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
（4）客户端收到“第三次挥手”后，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：
- ACK=1,seq=u+1 ， ack=w+1
随后客户端开始在TIME-WAIT阶段等待2MSL
后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道对方了解了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。
2. 为什么“握手”是三次，“挥手”却要四次？
TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是第三次握手传输的。为何建立连接时一起传输，释放连接时却要分开传输？
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先在第二次挥手时只返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，在第三次挥手时才能返回FIN释放连接报文。
所以是“三次握手”，“四次挥手”。
总结：四次挥手，多出来的一次是因为被动方不能立即处理还待发送的数据，需要一定的时间处理，所以将释放连接分为了两个步骤（也就是第二次挥手、第三次挥手），一是用来确认我得知了释放连接的消息，二是经过一段时间后我真正的要释放连接了。
3. 为什么客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。
所以客户端在发送完“第四次挥手”后，会设置一个时长为2MSL的计时器。
MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
-
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
-
如果客户端在2MSL内，再次收到了来自服务器端 “第三次挥手” ，说明服务器端由于各种原因没有接收“第四次挥手”。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
-
否则客户端在2MSL内没有再次收到“第三次挥手”的重传，说明“第四次挥手”成功，客户端可以进入CLOSED阶段。
所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因