TCP可靠性的边界：何种场景下TCP不可靠

TCP（Transmission Control Protocol）通常被视为"可靠的传输协议"，但这种可靠性仅限于端到端的数据传输层面。在实际应用中，TCP 并不能保证应用程序层面的完全可靠。本文将系统分析 TCP 可靠性的边界，以及在何种场景下 TCP 表现为"不可靠"。

TCP 可靠性的局限

TCP 的可靠性体现在传输层：保证数据按序、无丢失地到达对端。然而，从应用程序视角来看，存在以下不可靠场景：

发送端无法确认对端应用是否已处理数据：send() 返回成功仅表示数据已拷贝到内核发送缓冲区，不表示对端应用已读取；
已 ACK 的数据可能丢失：接收端 ACK 后，数据仍在接收缓冲区中，若应用程序崩溃，这部分数据将无法被处理；
异常感知能力有限：TCP 协议设计初衷为无人值守、自我恢复，不主动暴露过多异常细节。

TCP 连接建立后，感知链路异常的方式仅有两种：以 read() 为核心的读操作和以 write() 为核心的写操作。

故障场景分类

图表渲染中…

场景一：网络中断（对端无 FIN 包）

网络中断时，TCP 程序无法及时感知异常。除非网络设备（如路由器）发出 ICMP 报文说明目的网络或主机不可达，此时 read() 或 write() 调用会返回 Unreachable 错误。

在无 ICMP 报文的情况下：

阻塞在 read() 上：程序无法从异常中恢复，需通过设置超时来解决；
先 write() 后 read()：Linux TCP 协议栈会持续重传发送缓冲区数据，约重传 12 次、合计约 9 分钟后，协议栈标识连接异常，阻塞的 read() 返回 TIMEOUT 错误。此后若继续写入数据，write() 返回 SIGPIPE 信号。

内核版本注记：Linux 7.0 中，TCP 重传参数可通过 /proc/sys/net/ipv4/tcp_retries1 和 tcp_retries2 配置。tcp_retries2 默认值为 15，控制主动关闭前的重传次数。tcp_retries1（默认 3）控制首次 RST 发送前的重传次数。

场景二：系统崩溃（对端无 FIN 包）

系统突然崩溃（如断电）时，无任何 FIN 包被发送。此场景与网络中断类似：

无 ICMP 报文时，只能通过 read()/write() 超时感知异常；
若系统崩溃后重启，重传的 TCP 分组到达重启后的系统时，因无对应连接数据，系统返回 RST 重置分节。

RST 的处理

阻塞的 read() 调用：立即返回错误，错误信息为 "Connection Reset"；
write() 操作：立即失败，应用程序收到 SIGPIPE 信号。

场景三：对端有 FIN 包发出

对端发送 FIN 包的可能原因：

对端调用 close() 或 shutdown() 显式关闭连接；
对端应用程序崩溃，操作系统内核代为清理并发出 FIN 包。

从应用程序角度，无法区分这两种情形。

read 直接感知 FIN 包

阻塞的 read() 操作在完成正常数据读取后，FIN 包通过返回 EOF（返回值为 0）来通知。需注意：收到 FIN 包后 read() 不会立即返回，FIN 相当于在接收缓冲区末尾放置了一个 EOF 符号，之前已缓冲的有效数据不受影响。

服务器端程序：

code

int main(int argc, char **argv) {
    int connfd;
    char buf[1024];

    connfd = tcp_server(SERV_PORT);

    for (;;) {
        int n = read(connfd, buf, 1024);
        if (n < 0) {
            error(1, errno, "error read");
        } else if (n == 0) {
            error(1, 0, "client closed \n");
        }

        sleep(5);

        int write_nc = send(connfd, buf, n, 0);
        printf("send bytes: %zu \n", write_nc);
        if (write_nc < 0) {
            error(1, errno, "error write");
        }
    }

    exit(0);
}

客户端程序：

code

int main(int argc, char **argv) {
    if (argc != 2) {
        error(1, 0, "usage: reliable_client01 <IPaddress>");
    }

    int socket_fd = tcp_client(argv[1], SERV_PORT);
    char buf[128];
    int len;
    int rc;

    while (fgets(buf, sizeof(buf), stdin) != NULL) {
        len = strlen(buf);
        rc = send(socket_fd, buf, len, 0);
        if (rc < 0)
            error(1, errno, "write failed");
        rc = read(socket_fd, buf, sizeof(buf));
        if (rc < 0)
            error(1, errno, "read failed");
        else if (rc == 0)
            error(1, 0, "peer connection closed\n");
        else
            fputs(buf, stdout);
    }
    exit(0);
}

运行测试：启动服务器端和客户端，在客户端输入 "good" 后迅速杀死服务器端进程：

code

$ ./reliable_client01 127.0.0.1
$ good
$ peer connection closed

客户端通过 read() 感知到 FIN 包，正常退出。

通过 write 产生 RST，read 感知 RST

若客户端在收到服务器回应后再杀死服务器，然后继续发送数据：

code

$ ./reliable_client01 127.0.0.1
$ bad
$ bad
$ bad2
$ peer connection closed

图表渲染中…

内核版本注记：在 Linux 4.4 内核上测试，内核可能将 EOF 信息通知给应用程序而非 RST 错误信息。在 macOS 10.13.6 上测试，read() 可返回 RST 异常信息。Linux 7.0 的行为与 4.4 系列一致，倾向于通过 EOF 通知。不同内核版本的行为差异需在开发中予以关注。

向已关闭连接连续写导致 SIGPIPE

服务器端程序（每次读取 1K 数据后休眠 1 秒）：

code

int main(int argc, char **argv) {
    int connfd;
    char buf[1024];
    int time = 0;

    connfd = tcp_server(SERV_PORT);

    while (1) {
        int n = read(connfd, buf, 1024);
        if (n < 0) {
            error(1, errno, "error read");
        } else if (n == 0) {
            error(1, 0, "client closed \n");
        }

        time++;
        fprintf(stdout, "1K read for %d \n", time);
        usleep(1000);
    }

    exit(0);
}

客户端程序：

code

int main(int argc, char **argv) {
    if (argc != 2) {
        error(1, 0, "usage: reliable_client02 <IPaddress>");
    }

    int socket_fd = tcp_client(argv[1], SERV_PORT);

    signal(SIGPIPE, SIG_IGN);

    char *msg = "network programming";
    ssize_t n_written;

    int count = 10000000;
    while (count > 0) {
        n_written = send(socket_fd, msg, strlen(msg), 0);
        fprintf(stdout, "send into buffer %ld \n", n_written);
        if (n_written <= 0) {
            error(1, errno, "send error");
            return -1;
        }
        count--;
    }
    return 0;
}

杀死服务器进程后，客户端输出：

code

$ ./reliable_client02 127.0.0.1
$ send into buffer 5917291
$ send into buffer -1
$ send: Connection reset by peer

图表渲染中…

关键机制：收到 FIN 包仅表示对端不再发送数据，不表示对端不再接收数据。TCP 连接是双向的，收到 FIN 后仍可继续写入。但当数据到达对端已关闭的套接字时，对端会返回 RST，此时再执行 write() 将返回 EPIPE 错误或 SIGPIPE 信号。

内核版本注记：Linux 4.4+ 的实现中，send() 在收到 RST 后返回 ECONNRESET 错误而非触发 SIGPIPE（前提是已设置 signal(SIGPIPE, SIG_IGN)）。macOS 的行为则是在第二次 write() 时触发 SIGPIPE。Linux 7.0 延续了 4.4+ 的行为。建议始终为 SIGPIPE 注册处理函数，确保跨平台兼容性。

故障场景与感知方式汇总

图表渲染中…

故障场景	FIN 包	感知方式	错误信息
网络中断	无	read 阻塞 / write 超时	ETIMEDOUT
系统崩溃（断电）	无	read 阻塞 / write 超时	ETIMEDOUT
系统崩溃后重启	无	read/write 返回错误	ECONNRESET
对端 close/shutdown	有	read 返回 0	EOF
对端崩溃（内核发 FIN）	有	read 返回 0	EOF
收到 FIN 后继续 write	-	write 返回错误	EPIPE / SIGPIPE

总结

TCP 的可靠性仅限于传输层，应用程序层面仍需处理多种不可靠场景：

对端无 FIN 包：需通过超时机制或心跳检测来发现异常；
对端有 FIN 包：需通过增强 read()/write() 的异常处理来感知；
SIGPIPE 处理：始终为 SIGPIPE 注册处理函数，避免程序异常退出；
跨平台差异：不同操作系统和内核版本对 RST/SIGPIPE 的处理行为存在差异，需在开发中予以关注。

思考题

在你的 Linux 系统上重现本文的实验，观察运行结果是否与文中描述一致，并记录内核版本。
若服务器主机正常关闭（如执行 shutdown 命令），已连接的客户端程序会发生什么？

版本信息

更新日期：2026-06-09
目标内核：Linux 7.0