当前位置: 首页 > article >正文

四次挥手详解

文章目录

  • 一、四次挥手各状态
    • FIN_WAIT_1
    • CLOSE_WAIT
    • FIN_WAIT_2
    • LAST_ACK
    • TIME_WAIT
    • CLOSE
  • 二、双方同时调用close(),FIN_WAIT_1状态后进入CLOSING状态
    • CLOSING状态
  • 三、TIME_WAIT状态详解
    • (1) TIME_WAIT状态下的2MSL是什么
      • MSL (报文最大生存时间)
      • 为什么TIME__WAIT状态必须停留两倍MSL时间
    • (2) TIME_WAIT存在的意义
    • (3) 为什么会出现大量的TIME_WAIT状态
    • (4) TIME_WAIT状态的影响
      • 解决方法
  • 四、HTTP中一般服务端是请求断开方

在这里插入图片描述
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

一、四次挥手各状态

FIN_WAIT_1

当主动关闭方在ESTABLISHED状态时发送一个FIN,用来关闭数据传送,此时即进入到FIN_WAIT_1状态。

CLOSE_WAIT

处于ESTABILSHED状态的服务器收到FIN包,将发回一个ACK,确认序号为收到的序号加1。
CLOSE_WAIT: 这种状态表示在等待关闭。当对方发送FIN报文给自己,系统会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。如果还有数据发送给对方则可以在数据发送结束后再发送FIN报文来结束连接,所以这个状态是被断开方再等待自己数据发送结束后断开连接

FIN_WAIT_2

处于FIN_WAIT_1状态时,当接收到对方回应的ACK报文后,则进入到FIN_WAIT_2状态

LAST_ACK

被动关闭一方在发送FIN报文后,最后等待对方的ACK报文期间处于LAST_ACK状态

TIME_WAIT

time_wait 是「主动关闭 TCP 连接」一方的状态,可能是==「客服端」的,也可能是「服务器端」==的;
当TCP的一端发起主动关闭(收到 FIN 请求),即第3次握 手完成后,发送了第四次握手的ACK包后(最后的 ACK 是由「主动关闭连接」的一端发出的),就进入了TIME_WAIT状态。

CLOSE

当被动方收到ACK报文后,也即可以进入到CLOSED可用状态了。

二、双方同时调用close(),FIN_WAIT_1状态后进入CLOSING状态

在这里插入图片描述

CLOSING状态

CLOSING: 当发送FIN报文后进入fin_wait_1状态,过后并没有收到对方的ACK报文,反而也收到了对方的FIN报文。就是双方几乎在同时close一个SOCKET,然后就出现了双方同时发送FIN报文的情况,表示双方都正在关闭SOCKET连接。
closing状态收到ack报文以后即直接进入time_wait状态

三、TIME_WAIT状态详解

(1) TIME_WAIT状态下的2MSL是什么

MSL (报文最大生存时间)

任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。(IP 报文)
RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。

为什么TIME__WAIT状态必须停留两倍MSL时间

等待2MSL时间主要目的是怕最后一个 ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后,可以再发一个ACK应答包。

当连接处于2MSL等待阶段时,任何迟到的报文段都将被丢弃。

(2) TIME_WAIT存在的意义

可靠的实现 TCP 全双工连接的终止:
四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;

假设发起主动关闭方发送的ACK (4次交互的最后一个包)在网络中丢失,那么由于TCP的重传机制,被动关闭方需要重发FIN(第三次挥手),在该FIN到达主动发起方之前,client必须维护这条连接的状态(尽管它已调用过close),具体而言,就是这条TCP连接对应的(源IP,源端口)资源不能被立即释放或重新分配。直到对端重发的FIN达到,client也重发ACK后,该TCP连接才能恢复初始的CLOSED状态。如果主动方不进入TIME_WAIT以维护其连接状态,则当被动方重发的FIN达到时,主动方的TCP传输层会以RST包响应对方,这会被对方认为有错误发生(而事实上,这是正常的关闭连接过程,并非异常)。

处理延迟到达的报文:
由于路由器可能抖动,TCP 报文会延迟到达,为了避免「延迟到达的 TCP 报文被误认为是「新 TCP 连接」的数据,则,需要在允许新创建 TCP 连接之前,保持一个不可用的状态,等待所有延迟报文的消失,一般设置为 2 倍的 MSL(报文的最大生存时间),解决「延迟达到的 TCP 报文」问题。

TCP是流式的,所有包到达的顺序是不一致的,依靠序列号由TCP协议栈做顺序的拼接;假设如果一个新连接建立后旧连接的seq=1000包到达对端,可能会顶替掉新连接的seq=1000,造成错误

(3) 为什么会出现大量的TIME_WAIT状态

大量的短连接存在
TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间)

(4) TIME_WAIT状态的影响

time_wait 状态下,TCP 连接占用的端口,无法被再次使用, 要等到2MSL时间结束,才可继续使用,而TCP 端口数量上限是 6.5w(65535,16 bit)
大量 time_wait 状态存在,会导致新建 TCP 连接会出错,address already in use : connect 异常

解决方法

  • 服务器端允许 time_wait 状态的 socket 被重用
  • 缩减 time_wait 时间,设置为 1 MSL(即,2 mins)

四、HTTP中一般服务端是请求断开方

在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端,服务端你执行完成请求之后,是关闭连接还是保持连接,保持连接就意味着在保持连接期间,只能由客户端主动断开连接。还有一个keep-alive的头,设置的值就代表了服务端保持连接保持多久。

HTTP默认的Connection值为close,那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了

虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使TIME_WAIT降低了。


http://www.kler.cn/a/538928.html

相关文章:

  • 排序合集(一)
  • centos7 curl#6 - Could not resolve host mirrorlist.centos.org; 未知的错误 解决方案
  • Centos执行yum命令报错
  • Python分享20个Excel自动化脚本
  • 【实用教程】在 Android Studio 中连接 MuMu 模拟器
  • Unity抖音云启动测试:如何用cmd命令行启动exe
  • PID 算法简介(C语言)
  • Ai无限免费生成高质量ppt教程(deepseek+kimi)
  • 【数论】—— 欧拉函数
  • Linux下安装SVN服务端小白教程
  • 解锁Rust:融合多语言特性的编程利器
  • VLLM历次会议(2024.1)
  • 归一化与伪彩:LabVIEW图像处理的区别
  • ASAP Utilities:Excel 插件中的高效助手
  • (done) openMP学习 (Day10: Tasks 原语)
  • 【基于SprintBoot+Mybatis+Mysql】电脑商城项目之上传头像和新增收货地址
  • Elasticsearch入门技术:从零开始掌握全文搜索引擎
  • 深度理解如何使用DeepSeek-R1撰写论文:初学者指南
  • 校园网规划方案
  • 基于DeepSeek的具身智能高校实训解决方案——从DeepSeek+机器人到通用具身智能
  • DeepSeek JanusPro-7B本地安装-唯一正确版
  • 旋转位置编码(RoPE)公式详细推导过程
  • RocketMQ实战—8.营销系统业务和方案介绍
  • qt widget和qml界面集成到一起
  • 现代神经网络QA(LeNet/AlexNet/VGG/NiN/GooleNet/ResNet)-----一篇搞懂
  • Apache Commons Lang学习大纲