为何TcpListener与生成的TcpStream的文件描述符不同？

问题背景 #

我是Rust编程和Unix系统的新手，正在研究文件描述符与TCP连接的交互逻辑。最终目标是通过匹配文件描述符将程序的标准IO绑定到TCP收发，目前先想理解文件描述符的分配规则及差异原因。我编写了一段实验代码：

use std::{
    net::TcpListener,
    os::fd::AsFd
};

fn main() {
    let listener = TcpListener::bind("0.0.0.0:1024").unwrap();
    println!("Listener fd: {:?}", listener.as_fd());
    for stream in listener.incoming() {
        let stream = stream.unwrap();
        println!("Stream fd: {:?}", stream.as_fd());
    }
}

运行初始输出：

Listener fd: BorrowedFd { fd: 3 }

有客户端连接时输出：

Stream fd: BorrowedFd { fd: 4 }

疑问点：

1. 为何两者的文件描述符不同？
2. 每个文件描述符分别对应什么功能？比如fd3是否对应连接的入站数据，fd4对应回写数据？

解答 #

1. 文件描述符不同的原因 #

在Unix系统中，所有打开的资源（包括套接字、文件、管道等）都会被分配唯一的文件描述符。TcpListener和TcpStream是两种完全独立的套接字对象：

• TcpListener是监听套接字，作用是监听指定端口的连接请求，它本身是一个独立的打开资源，因此占用一个文件描述符（此处为3）。
• 当有客户端发起连接时，系统会创建全新的TcpStream对象，它代表服务器与该客户端的专属双向连接，属于另一个独立资源，所以会分配新的文件描述符（此处为4）。

另外，程序启动时默认会打开三个文件描述符：0（标准输入）、1（标准输出）、2（标准错误），因此新创建的资源会从3开始按顺序分配。

2. 各文件描述符的功能 #

• fd3（对应TcpListener）：仅负责监听指定端口的TCP连接请求，不处理任何数据收发。它的核心作用是接收新的连接请求，生成对应的TcpStream对象，本身无法直接用来读/写数据。
• fd4（对应TcpStream）：代表与单个客户端的双向TCP连接，既可以读取客户端发送的数据，也可以向客户端发送响应数据。它是真正承担数据交互的对象，而fd3只是连接请求的"入口"。

内容的提问来源于stack exchange，提问作者whatf0xx