上周有位读者面美团时被问到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 延迟确认机制导致的。完