为什么应用程序可以在 CLOSE_WAIT 状态（Linux）下接受和读/写 TCP 连接？

Question

我的假设是当 TCP 连接处于 ESTABLISHED 状态时，服务器可以从/向套接字读/写。 但是我看到当 TCP 连接处于 CLOSE_WAIT 状态时，服务器实际上可以读取和写入套接字。 当客户端关闭了它的连接，但服务器还没有检测/处理流结束的情况时，就会发生这种情况。

例如。 同步的、阻塞的单线程服务器：

#include <unistd.h>
#include <netdb.h>
#include <signal.h>

int main (void)
{
    signal(SIGPIPE, SIG_IGN); // ignore SIGPIPE from last send()
    int listen_sock = socket(PF_INET, SOCK_STREAM, 0);
    setsockopt(listen_sock, SOL_SOCKET, SO_REUSEADDR, &(int){1}, sizeof(int));
    struct sockaddr_in addr = {.sin_family = AF_INET, .sin_port = htons(8000), .sin_addr.s_addr = htonl(INADDR_ANY)};
    bind(listen_sock, (struct sockaddr *) &addr, sizeof(addr));
    listen(listen_sock, 10);
    while (1) {
        int sock = accept(listen_sock, 0, 0);
        char buffer[1024];
        recv(sock, buffer, sizeof(buffer), 0);
        sleep(1);
        send(sock, buffer, 10, 0);
        send(sock, buffer, 10, 0);
        sleep(1);
        send(sock, buffer, 10, 0);
        close(sock);
    }
}

编译并运行：

gcc server_short.c -o server_short && strace ./server_short

观看同一主机上的连接：

watch -n0.1 'sudo ss -lnt | grep 8000; sudo netstat -tpvn | grep 8000'

在另一台主机上运行短期客户端：

seq 20 | xargs -P100 -n1 bash -c 'echo -n "0123456789ABCDEF" | telnet $SERVER_IP 8000'

然后我看到连接处于 CLOSE_WAIT 和 SYN_RECV 状态，SYN_RECV 将变成 CLOSE_WAIT，因为排队的连接将由服务器处理：

LISTEN    11        10                 0.0.0.0:8000             0.0.0.0:*       
tcp       17      0 server_IP:8000       client_IP:33016        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33030        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33020        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33028        CLOSE_WAIT  -                   
tcp        0      0 server_IP:8000       client_IP:33012        CLOSE_WAIT  21282/./server 
tcp        0      0 server_IP:8000       client_IP:33046        SYN_RECV    -                   
tcp        0      0 server_IP:8000       client_IP:33040        SYN_RECV    -                   
tcp        0      0 server_IP:8000       client_IP:33044        SYN_RECV    -                   
tcp        0      0 server_IP:8000       client_IP:33036        SYN_RECV    -                   
tcp       17      0 server_IP:8000       client_IP:33018        CLOSE_WAIT  -                   
tcp        0      0 server_IP:8000       client_IP:33048        SYN_RECV    -                   
tcp       17      0 server_IP:8000       client_IP:33034        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33022        CLOSE_WAIT  -                   
tcp        0      0 server_IP:8000       client_IP:33042        SYN_RECV    -                   
tcp        0      0 server_IP:8000       client_IP:33038        SYN_RECV    -                   
tcp       17      0 server_IP:8000       client_IP:33032        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33026        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33014        CLOSE_WAIT  -                   
tcp       17      0 server_IP:8000       client_IP:33024        CLOSE_WAIT  -

然后服务器一一处理这些 CLOSE_WAIT 连接：

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 10)                           = 0
accept(3, NULL, NULL)                   = 4
recvfrom(4, "0123456789ABCDEF", 1024, 0, NULL, NULL) = 16
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffdb9a2d0e0) = 0
sendto(4, "0123456789", 10, 0, NULL, 0) = 10
sendto(4, "0123456789", 10, 0, NULL, 0) = 10
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffdb9a2d0e0) = 0
sendto(4, "0123456789", 10, 0, NULL, 0) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=22658, si_uid=1001} ---
close(4)                                = 0
accept(3, NULL, NULL)                   = 4
recvfrom(4, "0123456789ABCDEF", 1024, 0, NULL, NULL) = 16
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffdb9a2d0e0) = 0
sendto(4, "0123456789", 10, 0, NULL, 0) = 10
sendto(4, "0123456789", 10, 0, NULL, 0) = 10
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffdb9a2d0e0) = 0
sendto(4, "0123456789", 10, 0, NULL, 0) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=22658, si_uid=1001} ---
close(4)                                = 0
... AND SO ON

因此，服务器可以通过调用 read 或通过调用 write 检测管道损坏，在检测流结束之前成功接受、读取请求、处理它并发送响应。

我知道这个服务器代码并不理想，但即使你让它异步（使用 select、epoll、boost::asio 等）你也将接受 CLOSE_WAIT 连接，在检测到连接之前读取传入请求和启动请求处理没活着。 虽然服务器端知道连接已被客户端关闭，然后才被服务器接受。

所以问题：

1. 这种行为是否遵循 TCP 规范？ 接受和读取 CLOSE_WAIT 连接是否合法？
2. 为什么内核允许接受 CLOSE_WAIT 连接？ 或者为什么在这种情况下 recv 不返回错误？ 谁能对从关闭的连接中读取数据感兴趣？ 这种行为的目的是什么？ 似乎我没有看到如何使用这种情况。
3. 当 100% 确定没有人会收到响应时，如何检测这种情况而不开始处理请求？

Answer 1

TCP 堆栈独立于您的用户空间应用程序。 当您将套接字设置为LISTEN ，TCP 堆栈已经接受传入的连接（传入的SYN用SYN|ACK响应）并且还将传入的数据包存储到接收缓冲区中。

当您程序调用accept()它要么阻塞并等待某人连接到套接字，要么返回从 TCP 堆栈（或 TCP 状态机）的角度来看已经存在的已建立的套接字。

有完全合法的用例，客户端打开连接，传递一些数据并立即关闭连接。 然后，服务器可以花时间从网络缓冲区中检索该数据并处理请求（例如，如果该请求不需要对客户端的回答）。

CLOSE_WAIT本质上是“TCP 堆栈也在等待本地应用程序关闭套接字”的状态，因此您假设只有在状态为ESTABLISHED时才能read()是错误的。