学习:TCP/UDP协议分析(TCP四次挥手)
前言:记录关于传输层TCP协议的四次挥手
参考文章:https://www.jianshu.com/p/ca64764e4a26
参考文章:https://www.cnblogs.com/zpchcbd/p/12291007.html
有关TCP标志位Flags
SYN标志:建立连接的请求标志位 ACK标志:针对请求确认的应答标志位 PSH(push传送) FIN标志:请求断开连接的标志位 RST(reset重置) URG(urgent紧急) Sequence number(顺序号码) Acknowledge number(确认号码)
TCP四次挥手抓包分析
大家要先知道TCP连接是双向的,在四次挥手中,前两次挥手用于断开一方方向的连接,后两次挥手用于断开另一方的方向的连接。
注意的是:谁先断不一定,比如HTTP请求中,若connection 模式为CLOSE,则服务器主动关闭TCP连接,客户端被动关闭连接,释放TCP连接;若connection 模式为keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求。
第一次挥手: 客户端先发送一个带有FIN(结束标志位)以及随机Sequence number
的数据包,然后客户端会进入FIN-WAIT-1状态
第二次挥手: 服务端收到后,返回一个带有ACK(确认标志位)的数据包,其中Acknowledge number
为第一次挥手数据包的SEQ+1
和再次随机的Sequence number
,服务端会进入CLOSE-WAIT(关闭等待)状态
,客户端收到该应答后,进入FIN-WAIT-2状态
,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
注意:第二次挥手完成后,客户端到服务端方向的连接已经释放,但服务端到客户端方向的连接仍然存在,服务器若发送数据,客户端依然要接受
第三次挥手: 所以此时服务端继续发送一个数据包为ACK确认标志位
、FIN结束标志位
、Acknowledge number
为第一次挥手数据包的SEQ+1
,再次随机的Sequence number
给客户端,服务端就进入了LAST-ACK(最后确认)状态
,等待客户端的确认。
第四次挥手: 客户端收到服务端的结束数据包之后,向服务器发送一个应答包ACK确认标志位
、Sequence number
为第三次挥手的Acknowledge number
、当前的Acknowledge number
为第三次握手的SEQ+ 1
,客户端就进入了TIME-WAIT(时间等待)状态,这个期间TCP连接还未释放,若该时间段内没有服务端的重发请求的话,客户端就进入CLOSED状态,服务端只要收到了客户端发出的确认,立即进入CLOSED状态
。
这里也可以看出服务端比客户端早结束通信过程,但并不是一定!
问题1:为什么握手是三次,而挥手时四次?
我这里举个场景,就比如打电话,A用户给B用户打电话,此时要开始进行结束通话了,A用户给B用户说我要挂电话了,然后B用户说我知道了,那么此时如果A用户接收到了就直接挂了电话,那么这种情况合适吗?
更好的情况下应该是这样子的,A用户给B用户说我要挂电话了,然后B用户说我知道了,那么此时B用户这个时候可能还会说些啥,然后B用户说你挂电话吧,然后A用户才挂电话,这样子的话就避免了可能B用户在临时突然还有什么话要说却被挂断的事情发生了
再举个例子就是,A下载B用户的数据,然后A告诉B用户说我要下了,然后B用户说我知道了,那么此时B用户应该是把该传输的数据传输完,然后再发个信号给用户A,此时A用户才真正的结束
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY