TCP 三次握手
图解
三次握手过程详解
第一次握手：
【客户端】向【服务端】发送连接请求报文，标记 ACK=1 ， SYN=1 ， 客户端序列号 seq=x ，客户端进入等待状态。
第二次握手：
1、【服务端】收到请求报文，将收到的报文缓存起来，缓存客户端 seq=x
2、【服务端】向【客户端】发送确认报文，生成一个【服务端】seq=y ，标记 ACK=1 ，SYN=1 ，【服务端】自己的序列号 seq=y ，确认序列号 ACK_Number=x+1 ，发送给【客户端】
第三次握手：
1、【客户端】收到服务端发送的确认报文，将收到的报文存起来，缓存【服务端】seq=y
2、【客户端】发送确认报文给【服务端】，标记 ACK=1，SYN=0 ，【客户端】自己的序列号 seq=x+1，确认序列号 ACK_Number=y+1
3、【客户端】、【服务端】都会进入 ESTABLISHED (连接已建立状态)
TCP 四次挥手
图解
四次挥手过程详解
第一次挥手：
1、【客户端】向【服务端】发送释放连接报文，并停止发送数据，主动关闭 TCP 连接
2、标记 FIN=1 ，【客户端序列号】 seq=x ，该序号等于前面已经传送过去的数据的最后一个字节的序号加 1
3、这时，客户端 FIN—WAIT-1 (终止等待 1)状态，等待服务端确认
第二次挥手：
1、【服务端】收到释放连接报文，将收到的报文缓存起来，缓存【客户端】 seq=x
2、【服务端】向【客户端】发出确认释放报文，标记 ACK=1 ，【服务端序列号】 seq=y ，确认序列号 ACK_Number=a+1
（a 为【服务端】前面已经传送过的数据的最后一个字节的序号）
3、此时【服务端】进入 CLOSE—WAIT (关闭等待)状态
4、此时 TCP 服务器进程应该通知上层的应用进程，因为【客户端】到【服务端】这个方向的连接就释放了，这时 TCP 处于半关闭状态，即【客户端】已经没有数据要发了。但【服务端】若发送数据，【客户端】仍要接受，也就是说从【服务端】到【客户端】这个方向的连接并没有关闭，这个状态可能会持续一些时间。
第三次挥手：
1、【客户端】收到【服务端】确认报文，并缓存起来
2、此时【客户端】进入 FIN—WAIT (终止等待 2)状态，等待【服务端】发起释放连接报文
3、如果【服务端】没有数据要发送给【客户端】了，【服务端】的应用进程就会通知 TCP 释放连接
4、此时【服务端】向【客户端】发送释放连接报文，标记 FIN=1 ，确认序列号 ACK_Number=a+1 (与第二次挥手的确认号一致)，【服务端序号】 seq=z+1 (z 为半关闭状态发送的数据的最后一个字节的序号)
5、此时【服务端】进入最后确认状态，等待【客户端】确认
第四次挥手：
1、【客户端】收到【服务端】释放连接请求，必须发出确认
2、【客户端】向【服务端】发送确认报文，标记 ACK=1 ，确认号序列号 ACK_Numbe=z+1+1 ，【客户端序号】 seq=x+1 (x 为第一次挥手的 seq)
3、此时【客户端】进入等待状态，必须经过时间等待计时器设置的时间 2 倍 MSL(报文最大生存时间)后，【客户端】才进入 CLOSED 状态。
MSL 叫做最长报文寿命，RFC 建议设为 2 分钟，实际应用中是 30 秒。
在这 2 倍 MSL 期间【客户端】进入 TIME—WAIT 状态后，要经过 4 分钟才能进入到 CLOSED 状态。
4、【服务端】只要收到了【客户端】的确认后，就进入了 CLOSED 状态
5、当【客户端】和【服务端】都进入 CLOSED 状态后，连接就完全释放了
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取