图解
三次握手过程详解
- 第一次握手:
【客户端】向【服务端】发送连接请求报文,标记 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 状态后,连接就完全释放了
软件测试学习资料领取:https://csx-t231.github.io/eh2.html