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

大厂面试:TCP四次挥手,可以变成三次吗?

上周有位读者面美团时被问到TCP 四次挥手中能不能把第二次的 ACK 报文 放到第三次 FIN 报文一起发送虽然我们在学习 TCP 挥手时学到的是需要四次来完成 TCP 挥手但是在一些情况下 TCP 四次挥手是可以变成 TCP 三次挥手的。而且在用 wireshark 工具抓包的时候我们也会常看到 TCP 挥手过程是三次而不是四次如下图先来回答为什么 RFC 文档里定义 TCP 挥手过程是要四次再来回答什么情况下什么情况会出现三次挥手为什么 TCP 挥手需要四次TCP 四次挥手的过程如下具体过程客户端主动调用关闭连接的函数于是就会发送 FIN 报文这个 FIN 报文代表客户端不会再发送数据了进入 FIN_WAIT_1 状态服务端收到了 FIN 报文然后马上回复一个 ACK 确认报文此时服务端进入 CLOSE_WAIT 状态。在收到 FIN 报文的时候TCP 协议栈会为 FIN 包插入一个文件结束符 EOF 到接收缓冲区中服务端应用程序可以通过 read 调用来感知这个 FIN 包这个 EOF 会被放在已排队等候的其他已接收的数据之后所以必须要得继续 read 接收缓冲区已接收的数据接着当服务端在 read 数据的时候最后自然就会读到 EOF接着read() 就会返回 0这时服务端应用程序如果有数据要发送的话就发完数据后才调用关闭连接的函数如果服务端应用程序没有数据要发送的话可以直接调用关闭连接的函数这时服务端就会发一个 FIN 包这个 FIN 报文代表服务端不会再发送数据了之后处于 LAST_ACK 状态客户端接收到服务端的 FIN 包并发送 ACK 确认包给服务端此时客户端将进入 TIME_WAIT 状态服务端收到 ACK 确认包后就进入了最后的 CLOSE 状态客户端经过 2MSL 时间之后也进入 CLOSE 状态你可以看到每个方向都需要一个 FIN 和一个 ACK因此通常被称为四次挥手。为什么 TCP 挥手需要四次呢服务器收到客户端的 FIN 报文时内核会马上回一个 ACK 应答报文但是服务端应用程序可能还有数据要发送所以并不能马上发送 FIN 报文而是将发送 FIN 报文的控制权交给服务端应用程序如果服务端应用程序有数据要发送的话就发完数据后才调用关闭连接的函数如果服务端应用程序没有数据要发送的话可以直接调用关闭连接的函数从上面过程可知是否要发送第三次挥手的控制权不在内核而是在被动关闭方上图的服务端的应用程序因为应用程序可能还有数据要发送由应用程序决定什么时候调用关闭连接的函数当调用了关闭连接的函数内核就会发送 FIN 报文了所以服务端的 ACK 和 FIN 一般都会分开发送。FIN 报文一定得调用关闭连接的函数才会发送吗不一定。如果进程退出了不管是不是正常退出还是异常退出如进程崩溃内核都会发送 FIN 报文与对方完成四次挥手。粗暴关闭 vs 优雅关闭前面介绍 TCP 四次挥手的时候并没有详细介绍关闭连接的函数其实关闭的连接的函数有两种函数close 函数同时 socket 关闭发送方向和读取方向也就是 socket 不再有发送和接收数据的能力shutdown 函数可以指定 socket 只关闭发送方向而不关闭读取方向也就是 socket 不再有发送数据的能力但是还是具有接收数据的能力如果客户端是用 close 函数来关闭连接那么在 TCP 四次挥手过程中如果收到了服务端发送的数据由于客户端已经不再具有发送和接收数据的能力所以客户端的内核会回 RST 报文给服务端然后内核会释放连接这时就不会经历完成的 TCP 四次挥手所以我们常说调用 close 是粗暴的关闭。当服务端收到 RST 后内核就会释放连接当服务端应用程序再次发起读操作或者写操作时就能感知到连接已经被释放了如果是读操作则会返回 RST 的报错也就是我们常见的Connection reset by peer。如果是写操作那么程序会产生 SIGPIPE 信号应用层代码可以捕获并处理信号如果不处理则默认情况下进程会终止异常退出。相对的shutdown 函数因为可以指定只关闭发送方向而不关闭读取方向所以即使在 TCP 四次挥手过程中如果收到了服务端发送的数据客户端也是可以正常读取到该数据的然后就会经历完整的 TCP 四次挥手所以我们常说调用 shutdown 是优雅的关闭。但是注意shutdown 函数也可以指定「只关闭读取方向而不关闭发送方向」但是这时候内核是不会发送 FIN 报文的因为发送 FIN 报文是意味着我方将不再发送任何数据而shutdown 如果指定「不关闭发送方向」就意味着 socket 还有发送数据的能力所以内核就不会发送 FIN。什么情况会出现三次挥手当被动关闭方上图的服务端在 TCP 挥手过程中「没有数据要发送」并且「开启了 TCP 延迟确认机制」那么第二和第三次挥手就会合并传输这样就出现了三次挥手。然后因为 TCP 延迟确认机制是默认开启的所以导致我们抓包时看见三次挥手的次数比四次挥手还多。什么是 TCP 延迟确认机制当发送没有携带数据的 ACK它的网络效率也是很低的因为它也有 40 个字节的 IP 头 和 TCP 头但却没有携带数据报文。为了解决 ACK 传输效率低问题所以就衍生出了TCP 延迟确认。TCP 延迟确认的策略当有响应数据要发送时ACK 会随着响应数据一起立刻发送给对方当没有响应数据要发送时ACK 将会延迟一段时间以等待是否有响应数据可以一起发送如果在延迟等待发送 ACK 期间对方的第二个数据报文又到达了这时就会立刻发送 ACK延迟等待的时间是在 Linux 内核中定义的如下图关键就需要 HZ 这个数值大小HZ 是跟系统的时钟频率有关每个操作系统都不一样在我的 Linux 系统中 HZ 大小是 1000如下图知道了 HZ 的大小那么就可以算出最大延迟确认时间是 200 ms 1000/5最短延迟确认时间是 40 ms 1000/25怎么关闭 TCP 延迟确认机制如果要关闭 TCP 延迟确认机制可以在 Socket 设置里启用 TCP_QUICKACK启用 TCP_QUICKACK就相当于关闭 TCP 延迟确认机制。// 1 表示开启 TCP_QUICKACK即关闭 TCP 延迟确认机制 int value 1; setsockopt(socketfd, IPPROTO_TCP, TCP_QUICKACK, (char*) value, sizeof(int));实验验证实验一接下来来给大家做个实验验证这个结论当被动关闭方上图的服务端在 TCP 挥手过程中「没有数据要发送」并且「开启了 TCP 延迟确认机制」那么第二和第三次挥手就会合并传输这样就出现了三次挥手。服务端的代码如下做的事情很简单就读取数据然后当 read 返回 0 的时候就马上调用 close 关闭连接。因为 TCP 延迟确认机制是默认开启的所以不需要特殊设置。#include stdlib.h #include stdio.h #include errno.h #include string.h #include netdb.h #include sys/types.h #include netinet/in.h #include sys/socket.h #include netinet/tcp.h #define MAXLINE 1024 int main(int argc, char *argv[]) { // 1. 创建一个监听 socket int listenfd socket(AF_INET, SOCK_STREAM, 0); if(listenfd 0) { fprintf(stderr, socket error : %s\n, strerror(errno)); return -1; } // 2. 初始化服务器地址和端口 struct sockaddr_in server_addr; bzero(server_addr, sizeof(struct sockaddr_in)); server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr htonl(INADDR_ANY); server_addr.sin_port htons(8888); // 3. 绑定地址端口 if(bind(listenfd, (struct sockaddr *)(server_addr), sizeof(struct sockaddr)) 0) { fprintf(stderr,bind error:%s\n, strerror(errno)); return -1; } printf(begin listen....\n); // 4. 开始监听 if(listen(listenfd, 128)) { fprintf(stderr, listen error:%s\n\a, strerror(errno)); exit(1); } // 5. 获取已连接的socket struct sockaddr_in client_addr; socklen_t client_addrlen sizeof(client_addr); int clientfd accept(listenfd, (struct sockaddr *)client_addr, client_addrlen); if(clientfd 0) { fprintf(stderr, accept error:%s\n\a, strerror(errno)); exit(1); } printf(accept success\n); char message[MAXLINE] {0}; while(1) { //6. 读取客户端发送的数据 int n read(clientfd, message, MAXLINE); if(n 0) { // 读取错误 fprintf(stderr, read error:%s\n\a, strerror(errno)); break; } else if(n 0) { // 返回 0 代表读到 FIN 报文 fprintf(stderr, client closed \n); close(clientfd); // 没有数据要发送立马关闭连接 break; } message[n] 0; printf(received %d bytes: %s\n, n, message); } close(listenfd); return 0; }客户端代码如下做的事情也很简单与服务端连接成功后就发送数据给服务端然后睡眠一秒后就调用 close 关闭连接所以客户端是主动关闭方#include stdlib.h #include stdio.h #include errno.h #include string.h #include netdb.h #include sys/types.h #include netinet/in.h #include sys/socket.h int main(int argc, char *argv[]) { // 1. 创建一个监听 socket int connectfd socket(AF_INET, SOCK_STREAM, 0); if(connectfd 0) { fprintf(stderr, socket error : %s\n, strerror(errno)); return -1; } // 2. 初始化服务器地址和端口 struct sockaddr_in server_addr; bzero(server_addr, sizeof(struct sockaddr_in)); server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr inet_addr(127.0.0.1); server_addr.sin_port htons(8888); // 3. 连接服务器 if(connect(connectfd, (struct sockaddr *)(server_addr), sizeof(server_addr)) 0) { fprintf(stderr,connect error:%s\n, strerror(errno)); return -1; } printf(connect success\n); char sendline[64] hello, i am xiaolin; //4. 发送数据 int ret send(connectfd, sendline, strlen(sendline), 0); if(ret ! strlen(sendline)) { fprintf(stderr,send data error:%s\n, strerror(errno)); return -1; } printf(already send %d bytes\n, ret); sleep(1); //5. 关闭连接 close(connectfd); return 0; }编译服务端和客户端的代码先启用服务端然后用 tcpdump 工具开始抓包命令如下tcpdump -i lo tcp and port 8888 -s0 -w /home/tcp_close.pcap然后启用客户端可以看到与服务端连接成功后发完数据就退出了。此时服务端的输出接下来我们来看看抓包的结果。可以看到TCP 挥手次数是 3 次。所以下面这个结论是没问题的。结论当被动关闭方上图的服务端在 TCP 挥手过程中「没有数据要发送」并且「开启了 TCP 延迟确认机制默认会开启」那么第二和第三次挥手就会合并传输这样就出现了三次挥手。实验二我们再做一次实验来看看关闭 TCP 延迟确认机制会出现四次挥手吗客户端代码保持不变服务端代码需要增加一点东西。在上面服务端代码中增加了打开了 TCP_QUICKACK 快速应答机制的代码如下编译好服务端代码后就开始运行服务端和客户端的代码同时用 tcpdump 进行抓包。抓包的结果如下可以看到是四次挥手。所以当被动关闭方上图的服务端在 TCP 挥手过程中「没有数据要发送」同时「关闭了 TCP 延迟确认机制」那么就会是四次挥手。设置 TCP_QUICKACK 的代码为什么要放在 read 返回 0 之后我也是多次实验才发现在 bind 之前设置 TCP_QUICKACK 是不生效的只有在 read 返回 0 的时候设置 TCP_QUICKACK 才会出现四次挥手。网上查了下资料说设置 TCP_QUICKACK 并不是永久的所以每次读取数据的时候如果想要立刻回 ACK那就得在每次读取数据之后重新设置 TCP_QUICKACK。而我这里的实验目的是为了当收到客户端的 FIN 报文第一次挥手后立马回 ACK 报文所以就在 read 返回 0 的时候设置 TCP_QUICKACK。当然实际应用中没人会在我这个位置设置 TCP_QUICKACK因为操作系统都通过 TCP 延迟确认机制帮我们把四次挥手优化成了三次挥手了这本来就是一件好事呀。总结当被动关闭方在 TCP 挥手过程中如果「没有数据要发送」同时「没有开启 TCP_QUICKACK默认情况就是没有开启没有开启 TCP_QUICKACK等于就是在使用 TCP 延迟确认机制」那么第二和第三次挥手就会合并传输这样就出现了三次挥手。‍‍所以出现三次挥手现象是因为 TCP 延迟确认机制导致的。完

相关文章:

大厂面试:TCP四次挥手,可以变成三次吗?

上周有位读者面美团时,被问到:TCP 四次挥手中,能不能把第二次的 ACK 报文, 放到第三次 FIN 报文一起发送?虽然我们在学习 TCP 挥手时,学到的是需要四次来完成 TCP 挥手,但是在一些情况下&#x…...

从录制到执行:利用Scripting Tracker与Python实现SAP GUI自动化操作

1. 为什么需要SAP GUI自动化? 每天重复点击几十次相同的按钮,填写上百个雷同的表单——这是很多SAP用户的真实工作状态。作为企业级ERP系统,SAP的操作往往需要大量人工交互,效率低下且容易出错。我曾在某制造业客户现场见过这样的…...

【Blender】别再只会 “搭积木”!Blender 点线面编辑,新手建模的真正起点

🫧个人主页:小年糕是糕手 💫个人专栏:《C》《Linux》《数据结构》《Blender》 🎨你不能左右天气,但你可以改变心情;你不能改变过去,但你可以决定未来! 目录 从 “搭积木…...

生成式AI实时响应延迟突增?立即执行这7步链路压测诊断法(含eBPF追踪脚本模板)

第一章:生成式AI应用实时通信方案 2026奇点智能技术大会(https://ml-summit.org) 生成式AI应用对低延迟、高并发的实时通信能力提出全新要求——模型推理流式响应需与前端交互无缝衔接,用户输入、中间思考(thinking tokens)、结构…...

空洞骑士模组管理终极指南:Scarab一键安装与智能依赖解析

空洞骑士模组管理终极指南:Scarab一键安装与智能依赖解析 【免费下载链接】Scarab An installer for Hollow Knight mods written in Avalonia. 项目地址: https://gitcode.com/gh_mirrors/sc/Scarab Scarab是一款专为《空洞骑士》设计的开源模组管理器&…...

雨雾天锥桶识别掉点50%?YOLOv11+轻量去雾实战,召回率从42%提升至92%

一、项目背景:恶劣天气下的自动驾驶痛点 上个月在做园区自动驾驶巡检项目时,遇到了一个致命问题:晴天时道路锥桶识别准确率能到98%,但一到小雨或者大雾天,召回率直接跌到42%,经常出现漏检导致车辆撞上锥桶的…...

016、LangChain进阶:Memory、Retriever与工程化组织,才是你真正该补的部分

上一篇我们讲的是:如何把LangChain放进RAG,怎样真正地将知识库问答组织成一条可以维护的工程链路。 如果你已经打通了最短的那条链路,那么接下来你大概率会遇到两个比较实际的问题: 用户追问第二句的时候,系统却好像突然忘记了? 为什么同样是“检索资料”,项目一复杂了…...

新能源汽车整车控制器VCU学习模型:初学者的快速入门指南

新能源汽车整车控制器VCU学习模型,适用于初学者。 1、模型包含高压上下电,行驶模式管理,能量回馈,充电模式管理,附件管理,远程控制,诊断辅助功能。 2、软件说明书(控制策略说明书&am…...

YOLO+ByteTrack路口违章抓拍实战:多目标稳定追踪与违章判定

一、项目背景与目标 路口违章抓拍是智能交通的核心应用,但传统方案存在两个痛点:一是多目标遮挡时追踪ID频繁切换,导致轨迹断裂;二是违章判定依赖复杂的硬件设备,部署成本高。 本文将用YOLOv11做检测ByteTrack做追踪&a…...

瑞萨RZN2L EtherCAT从机配置全流程:从TwinCAT3驱动到IO测试(避坑指南)

瑞萨RZN2L EtherCAT从机配置实战:从环境搭建到IO测试的完整避坑手册 工业自动化领域的技术迭代从未停歇,而EtherCAT作为实时以太网通信协议中的佼佼者,其配置过程却常常让工程师们头疼不已。特别是当面对瑞萨RZN2L这样的工业级MPU时&#xff…...

智能排版:核心功能解析与效率提升实践指南

当前内容产业进入多平台分发时代,据2024年内容创作者生存报告显示,平均每个运营人员每月要适配至少8个不同渠道的内容,排版相关工作占日常工作量的42%,大量本该投入内容创意的时间被机械劳动挤占。运营人员要反复调整图文比例适配…...

Android音频调试实战:用dumpsys media.audio_flinger揪出音频卡顿的元凶

Android音频调试实战:用dumpsys media.audio_flinger揪出音频卡顿的元凶 当你在开发一款音乐播放应用时,突然收到用户反馈说音频播放时有明显的卡顿和杂音。作为开发者,你可能会感到一头雾水——是应用层的问题?还是系统底层的问题…...

数据库基础概念与体系结构 - 软考备战(二十九)

数据库系统(一) 参考资料: 终于有人把数据库讲明白了 - 数据集成与治理 - 博客园 数据库基础知识总结 | JavaGuide 一文读懂数据库中的DB、DBMS、DBS、DBAS-云社区-华为云 数据库(一):三级模式与两级映…...

AI辅助排版:设计领域的应用方法与落地实践

数字化内容生产节奏不断加快,品牌方对内容输出的频率和质量要求同步提升。不少中小设计团队因为排版效率不足,无法承接高频次的内容输出需求。特别是电商大促节点,不少中小团队一周要承接近百套商品详情页、平台活动海报、新媒体种草内容的排…...

从Urbannav真值话题到NavSatFix:手把手教你转换GPS数据格式用于ROS定位评估

从Urbannav真值到NavSatFix:ROS定位评估中的GPS数据格式转换实战 在自动驾驶和机器人定位领域,数据格式的统一性常常成为算法评估中的"最后一公里"难题。当我们使用Urbannav这类专业数据集进行多传感器融合定位算法的精度评估时,经…...

如何把MAX31865的精度榨干?STM32驱动PT100三线制测温的校准与优化实战

如何将MAX31865的精度发挥到极致:PT100三线制高精度测温实战指南 在工业自动化、实验室设备以及精密仪器控制领域,温度测量的准确性往往直接影响整个系统的可靠性和产品质量。MAX31865作为一款专为RTD(电阻温度检测器)设计的信号调…...

不止于分词:用SpringBoot+HanLP 1.7.7快速构建一个简易文本分析服务

构建企业级文本分析服务:SpringBoot与HanLP深度整合实践 在数字化转型浪潮中,文本数据处理能力已成为企业智能化升级的基础设施。传统单机版NLP工具虽然功能强大,却难以满足分布式系统的调用需求。本文将展示如何将HanLP这一优秀的中文处理工…...

从冠军方案拆解:在Jane Street预测赛中,如何用AE+MLP+XGBoost玩转模型融合?

从冠军方案拆解:在Jane Street预测赛中,如何用AEMLPXGBoost玩转模型融合? 金融时序数据预测一直是量化交易领域的核心挑战。Jane Street Market Prediction竞赛提供了一个独特的实验场,让数据科学家们在匿名化市场数据上验证模型的…...

Swift学习笔记25-函数式编程

Array的常见操作//Array的常见操作 //注意:Map和FlatMap都是映射高级函数var arr [1, 2, 3, 4] //这是这块的基础 var arr2 arr.map { $0 * 2 } //每一个元素分别乘2 print(arr2)//[2, 4, 6, 8] //map:对数组的每个元素应用指定的函数,返回一个新数组。…...

从PWM到模拟信号:低通滤波器设计的工程实践与参数权衡

1. PWM DAC基础与低通滤波器的必要性 第一次接触PWM DAC这个概念时,我完全被它的巧妙设计震惊了。在嵌入式开发中,DAC(数模转换器)资源往往非常有限,而PWM(脉宽调制)却几乎每个MCU都自带多个通道…...

告别picamera!用Picamera2在树莓派上玩转计算机视觉:从拍照到实时视频分析

树莓派视觉革命:Picamera2从入门到实战全指南 去年夏天,我在为一个智能农业监控项目调试树莓派摄像头时,突然发现传统的picamera库在新款树莓派5上完全失效——这个意外让我踏上了Picamera2的探索之旅。作为树莓派基金会官方推荐的下一代摄像…...

操作系统6(系统调用)(TODO)

1 简介 这一篇主要是涉及到了不同的权限级切换,以及系统调用的原理。 内容还是来自:https://github.com/s-matyukevich/raspberry-pi-os/tree/master/docs/lesson05 之前写裸机的时候,其实接触到了一些层级切换,主要是异常处理&…...

不是SaaS,是你可以完全掌控的CRM系统:开源+可定制+多端支持(小程序/H5),附获取方式

温馨提示:文末有资源获取方式在SaaS产品大行其道的今天,很多企业逐渐发现一个尴尬的现实:数据不在自己手里,功能无法按需调整,每月的订阅费还像无底洞。有没有一种方案,既能拥有完整的系统能力,…...

AD20封装库疑难杂症:从“Footprint Not Found”到ECO一键修复

1. 当AD20大喊"Footprint Not Found"时,到底发生了什么? 每次看到AD20弹出"Footprint Not Found"的红色警告框,我都忍不住想吐槽:明明封装库就在那里,为什么软件就是找不到?这个问题困…...

表格解析问题第八届:高并发内存动态脱敏性能竞速一、课题背景 在数据动态脱敏业务场景中,数据在内存中的脱敏处理时间直接影响最终数据脱敏的效率,从而影响用户通过动态脱敏应用查询数据库的感

# K 知识库分类结果分析报告知识库id10088 杭州分行知识库 317387244825804800> 生成时间: 2026-04-17 17:39:22> 总记录数: 269> LLM 调用次数: 5## 0. 执行摘要**质量评分**: 4.0/5.0| 指标 | 数值 ||------|------|| 总文档数 | 269 || 有效知识 | 252 (93.7%) ||…...

012、张量与数据布局:内存模型与对齐策略

012、张量与数据布局:内存模型与对齐策略 上周调一个卷积性能问题,在某个边缘设备上跑得比预期慢了三倍。用perf抓热点发现大量时间花在非对齐内存访问上——明明数据尺寸都是4的倍数,为什么还会不对齐?最后定位到问题:张量在内存中的布局和编译器假设的不一致,导致生成…...

011、算子中间表示概述:计算图与算子抽象

011、算子中间表示概述:计算图与算子抽象 最近在优化一个推理引擎时遇到个头疼的问题:模型在GPU上跑得好好的,移植到边缘设备上就出精度问题。用传统调试手段跟了三天,最后发现是某个卷积算子在特定输入形状下触发了厂商驱动里的未公开量化行为。这件事让我重新审视算子中…...

别再让Copilot绕过你的Security Gate!:实时拦截高危生成代码的eBPF+LLM Guard联合审查方案(已通过ISO 27001渗透验证)

第一章:智能代码生成与代码审查流程整合 2026奇点智能技术大会(https://ml-summit.org) 现代软件工程实践中,智能代码生成已不再孤立运行于开发环境边缘,而是深度嵌入持续集成与代码审查(CI/CR)主干流程。当开发者提交…...

Python脚本驱动:AutoCAD Plant 3D中槽式垂直三通参数化建模实战

1. 为什么需要参数化建模槽式垂直三通? 在管道工程设计领域,槽式垂直三通是最常见的管件之一。传统手动建模方式需要反复绘制草图、拉伸实体、布尔运算,一个简单的三通模型可能要花费设计师半小时。当遇到非标尺寸或批量修改时,这…...

STM32调试进阶:在CLion中利用OpenOCD和SVD文件实现外设寄存器可视化调试

STM32调试进阶:在CLion中利用OpenOCD和SVD文件实现外设寄存器可视化调试 当STM32开发进入硬件调试阶段,传统的变量监视和断点调试往往难以满足深度需求。本文将揭示如何通过CLionOpenOCDSVD三位一体的方案,将调试视角从软件层面延伸到硬件寄存…...