3、标准库网络模块：TcpListener、TcpStream、UdpSocket的基本用法与事件循环

Rust 标准库（std::net）提供了跨平台的 TCP 与 UDP 网络编程基础能力，是构建高性能网络服务的第一块基石。与异步运行时（如 tokio）不同，标准库中的网络类型是同步阻塞的，但这并不意味着它们只能用于玩具项目——理解这些同步原语的工作方式、阻塞语义与事件循环的配合模式，恰恰是后续理解异步网络、多线程并发模型以及操作系统网络栈行为的关键前提。本章将深入剖析 TcpListener、TcpStream 与 UdpSocket 的核心 API、典型用法、事件循环的构建方式，并通过一个完整的案例展示如何用标准库实现一个可用的 TCP 回显服务。

标准库网络模块核心模型与事件循环 TCP 服务端 TcpListener::bind() listener.accept() 阻塞等待 TcpStream 建立连接 read() / write() 数据收发 每连接一个线程处理 事件循环模式 循环 { accept() } 生成子线程处理连接 主线程继续 accept() 非阻塞 + poll 轮询 同步阻塞 vs 非阻塞轮询 UDP 通信 UdpSocket::bind() recv_from() 接收数据报 send_to() 发送数据报 无连接，无需 accept() 数据报边界保留 图：标准库网络模块三种核心对象的关系与事件循环模型

3.1 核心原理：从系统调用到 Rust 封装

Rust 标准库的 std::net 模块本质上是操作系统网络 API（如 POSIX 的 socket、bind、listen、accept、connect、send、recv）的安全封装。它遵循 RAII（Resource Acquisition Is Initialization）原则：当 TcpListener 或 UdpSocket 对象被创建时，底层文件描述符随之分配；当对象被 drop 时，描述符自动关闭，无需手动释放。这一设计极大地降低了资源泄漏的风险。

三个核心类型的定位如下：

  • TcpListener：服务端监听套接字，负责绑定地址、监听端口、接受新连接。它本身不传输数据，只产生 TcpStream。
  • TcpStream：代表一条已建立的 TCP 连接，可双向读写。它既可以由 accept() 产生（服务端），也可以由 TcpStream::connect() 主动发起（客户端）。
  • UdpSocket：无连接的数据报套接字，通过 send_to() 和 recv_from() 收发数据，每次收发都需指定对端地址。

理解这三者的关键在于把握 TCP 的“面向连接、字节流”与 UDP 的“无连接、数据报”的本质差异。TCP 保证数据有序、可靠到达，但应用层需要自行处理粘包/半包问题；UDP 不保证可靠性和顺序，但保留了消息边界，适合实时性要求高、可容忍丢包的应用（如音视频传输、游戏状态同步）。

底层视角：在 Linux 上，TcpListener::bind() 对应 socket() + bind() + listen() 三个系统调用；accept() 对应 accept4()；TcpStream::connect() 对应 connect()。Rust 的封装隐藏了错误码处理、地址结构体转换等细节，但保留了 io::Result 作为错误传播机制。

3.2 操作流程：TcpListener 与 TcpStream 的标准用法

一个典型的 TCP 服务端生命周期包含四个阶段：绑定地址 → 监听 → 接受连接 → 数据收发。下面通过代码展示最基础的用法。

use std::io::{Read, Write};
use std::net::{TcpListener, TcpStream};
use std::thread;

fn handle_client(mut stream: TcpStream) {
    let mut buf = [0u8; 1024];
    loop {
        // 阻塞读取，直到收到数据或对端关闭
        match stream.read(&mut buf) {
            Ok(0) => {
                println!("客户端关闭连接");
                break;
            }
            Ok(n) => {
                // 回显数据
                if let Err(e) = stream.write_all(&buf[..n]) {
                    eprintln!("写入失败: {}", e);
                    break;
                }
            }
            Err(e) => {
                eprintln!("读取错误: {}", e);
                break;
            }
        }
    }
}

fn main() -> std::io::Result<()> {
    // 1. 绑定地址，监听 127.0.0.1:8080
    let listener = TcpListener::bind("127.0.0.1:8080")?;
    println!("服务器启动，监听 127.0.0.1:8080");

    // 2. 事件循环：不断接受新连接
    for stream in listener.incoming() {
        match stream {
            Ok(stream) => {
                // 3. 为每个连接创建独立线程处理
                thread::spawn(move || handle_client(stream));
            }
            Err(e) => {
                eprintln!("接受连接失败: {}", e);
            }
        }
    }
    Ok(())
}

客户端连接方式同样简单：

use std::io::{Read, Write};
use std::net::TcpStream;

fn main() -> std::io::Result<()> {
    let mut stream = TcpStream::connect("127.0.0.1:8080")?;
    stream.write_all(b"Hello, Rust!")?;
    
    let mut buf = [0u8; 1024];
    let n = stream.read(&mut buf)?;
    println!("收到响应: {}", String::from_utf8_lossy(&buf[..n]));
    Ok(())
}

上述代码展示了几个关键点：incoming() 是一个迭代器，每次迭代阻塞等待新连接；thread::spawn 为每个连接分配独立线程，这是最简单的并发模型，但线程开销较大，不适合高并发场景。更高效的方式是使用线程池或非阻塞 I/O（如 set_nonblocking(true) 配合 poll）。

3.3 事件循环的两种构建模式

“事件循环”是网络服务的核心骨架。标准库提供了两种构建方式：阻塞式多线程模型和非阻塞式轮询模型。前者简单直观，后者更接近异步运行时的底层实现。

维度 阻塞式 + 多线程 非阻塞 + poll 轮询
核心 API accept()、read()、write() set_nonblocking(true)、std::poll
并发模型 每连接一线程，线程数随连接数增长 单线程或少量线程管理大量连接
资源开销 高（线程栈默认 2MB，上下文切换成本高） 低（仅需维护 fd 集合）
编程复杂度 低，符合直觉 高，需处理 EWOULDBLOCK 等错误
适用场景 连接数 < 1000，开发效率优先 连接数 > 1000，或需要精细控制

非阻塞模式的典型写法如下：

use std::io::{self, Read, Write};
use std::net::{TcpListener, TcpStream};
use std::collections::HashMap;
use std::os::unix::io::AsRawFd;

fn main() -> io::Result<()> {
    let listener = TcpListener::bind("127.0.0.1:8080")?;
    listener.set_nonblocking(true)?;
    
    let mut clients: HashMap<u32, TcpStream> = HashMap::new();
    let mut poll_fds = vec![
        libc::pollfd {
            fd: listener.as_raw_fd(),
            events: libc::POLLIN,
            revents: 0,
        }
    ];
    
    loop {
        // 调用 poll 等待事件，超时 100ms
        let ret = unsafe { libc::poll(poll_fds.as_mut_ptr(), poll_fds.len() as u64, 100) };
        if ret < 0 {
            return Err(io::Error::last_os_error());
        }
        
        // 检查监听套接字是否有新连接
        if poll_fds[0].revents & libc::POLLIN != 0 {
            loop {
                match listener.accept() {
                    Ok((stream, addr)) => {
                        stream.set_nonblocking(true)?;
                        let fd = stream.as_raw_fd() as u32;
                        poll_fds.push(libc::pollfd {
                            fd: fd as i32,
                            events: libc::POLLIN,
                            revents: 0,
                        });
                        clients.insert(fd, stream);
                        println!("新连接: {}", addr);
                    }
                    Err(e) if e.kind() == io::ErrorKind::WouldBlock => break,
                    Err(e) => return Err(e),
                }
            }
        }
        
        // 检查已有连接的可读事件
        // ...（省略具体处理逻辑）
    }
}

这段代码展示了非阻塞模式的核心思想：set_nonblocking(true) 后，accept() 在没有新连接时返回 WouldBlock 错误；通过 poll() 统一监听所有 fd 的可读事件，避免线程阻塞。这种模式是 tokio、async-std 等异步运行时的底层基础，理解它有助于后续学习异步网络编程。

3.4 UdpSocket 的基本用法与数据报语义

UDP 编程比 TCP 简单得多，因为没有连接建立和断开的过程。服务端和客户端都只需绑定一个端口，然后直接收发数据报。

use std::net::UdpSocket;

fn main() -> std::io::Result<()> {
    // 绑定 UDP 端口
    let socket = UdpSocket::bind("127.0.0.1:8080")?;
    println!("UDP 服务器启动，监听 127.0.0.1:8080");

    let mut buf = [0u8; 1024];
    loop {
        // 接收数据报，返回 (字节数, 对端地址)
        match socket.recv_from(&mut buf) {
            Ok((n, src_addr)) => {
                println!("收到 {} 字节，来自 {}", n, src_addr);
                // 原样回显
                socket.send_to(&buf[..n], src_addr)?;
            }
            Err(e) => eprintln!("接收错误: {}", e),
        }
    }
}

UDP 的关键特性：

  • 消息边界保留：每次 recv_from() 恰好返回一个完整的数据报，不会出现 TCP 的粘包问题。
  • 无连接：不需要 accept/connect，直接收发。
  • 不可靠：数据报可能丢失、重复、乱序，应用层需自行处理。
  • 支持广播/组播：通过 set_broadcast(true) 可发送广播包。

经验提示：UDP 的 send_to() 可能部分发送（返回的字节数小于输入长度），但这种情况极为罕见。若需确保完整发送，可循环调用直到全部发送完毕。另外，UDP 接收缓冲区默认较小（Linux 约 208KB），高吞吐场景下需通过 set_recv_buffer_size() 调大。

3.5 案例拆解：构建一个多线程 TCP 聊天室

为了综合运用本章知识，我们设计一个简易聊天室服务端。需求如下：

  • 支持多个客户端同时连接，任意客户端发送的消息广播给所有其他客户端。
  • 客户端发送 /quit 时断开连接。
  • 服务端记录每个客户端的昵称（首次连接时发送 NICK:xxx 注册）。

架构设计：采用“每连接一线程 + 共享客户端列表”模型。使用 Arc<Mutex<HashMap<u32, TcpStream>>> 保存所有在线客户端，每个连接线程负责读取数据并广播。

use std::io::{BufRead, BufReader, Write};
use std::net::{TcpListener, TcpStream};
use std::sync::{Arc, Mutex};
use std::thread;
use std::collections::HashMap;

type ClientMap = Arc<Mutex<HashMap<u32, TcpStream>>>;

fn broadcast(clients: &ClientMap, sender_id: u32, msg: &str) {
    let mut map = clients.lock().unwrap();
    for (id, stream) in map.iter_mut() {
        if *id != sender_id {
            let _ = writeln!(stream, "{}", msg);
        }
    }
}

fn handle_client(id: u32, mut stream: TcpStream, clients: ClientMap) {
    let mut reader = BufReader::new(stream.try_clone().unwrap());
    let mut nickname = String::from("anonymous");
    
    // 读取昵称
    let mut first_line = String::new();
    if reader.read_line(&mut first_line).is_ok() {
        if let Some(nick) = first_line.trim().strip_prefix("NICK:") {
            nickname = nick.to_string();
        }
    }
    broadcast(&clients, id, &format!("[系统] {} 加入聊天室", nickname));
    
    loop {
        let mut line = String::new();
        match reader.read_line(&mut line) {
            Ok(0) => break,
            Ok(_) => {
                let msg = line.trim();
                if msg == "/quit" {
                    break;
                }
                broadcast(&clients, id, &format!("[{}] {}", nickname, msg));
            }
            Err(_) => break,
        }
    }
    
    // 移除客户端
    clients.lock().unwrap().remove(&id);
    broadcast(&clients, id, &format!("[系统] {} 离开聊天室", nickname));
}

fn main() -> std::io::Result<()> {
    let listener = TcpListener::bind("127.0.0.1:8080")?;
    let clients: ClientMap = Arc::new(Mutex::new(HashMap::new()));
    let mut next_id = 1u32;
    
    for stream in listener.incoming() {
        match stream {
            Ok(stream) => {
                let id = next_id;
                next_id += 1;
                let clients = Arc::clone(&clients);
                clients.lock().unwrap().insert(id, stream.try_clone().unwrap());
                thread::spawn(move || handle_client(id, stream, clients));
            }
            Err(e) => eprintln!("连接失败: {}", e),
        }
    }
    Ok(())
}

运行效果与复盘：启动服务端后，用三个终端分别运行 nc 127.0.0.1 8080 模拟客户端。第一个客户端发送 NICK:Alice，第二个发送 NICK:Bob，之后 Alice 发送 “Hello”，Bob 能收到 [Alice] Hello。该案例暴露了几个值得注意的问题：

  1. 锁竞争：每次广播都持有全局锁，当客户端数量增多时，锁会成为瓶颈。优化方向是使用读写锁或分片锁。
  2. 阻塞写：如果某个客户端接收缓慢，writeln! 会阻塞当前线程，影响广播效率。可考虑为每个客户端设置发送缓冲区或使用非阻塞写。
  3. 线程资源：每连接一线程在 1000 连接时内存占用约 2GB（线程栈），实际部署需改用线程池或异步方案。

风险提示：上述代码中 try_clone() 创建了同一个 socket 的多个句柄，但 BufReader 和 TcpStream 共享同一个底层 fd。当 handle_client 结束时，stream 被 drop，但 clients 中的克隆句柄仍然存在，导致连接未真正关闭。正确做法是在移除客户端时显式调用 shutdown() 或确保所有克隆都被 drop。

3.6 常见误区与总结复盘

标准库网络编程看似简单，但实践中容易踩坑。以下是高频问题与应对策略：

误区 后果 正确做法
忽略 WouldBlock 错误 非阻塞模式下程序崩溃或忙轮询 匹配 ErrorKind::WouldBlock 并继续循环
TCP 粘包/半包处理不当 数据解析错乱 应用层定义消息边界（如长度前缀、分隔符）
UDP 发送缓冲区溢出 数据报静默丢弃 监控 send_to() 返回值，必要时增加重传机制
线程无限增长 资源耗尽，服务不可用 使用线程池或限制最大连接数
未处理 write_all 部分写入 数据不完整 循环写入直到全部完成，或使用 write_all

本章核心收获：标准库网络模块是理解 Rust 网络编程的起点。掌握 TcpListener 的 accept 循环、TcpStream 的读写语义、UdpSocket 的数据报模型，以及阻塞/非阻塞两种事件循环模式，为后续学习 tokio 等异步框架打下坚实基础。在实际项目中，若连接数较少且追求开发效率，标准库 + 多线程完全够用；若需支撑高并发，则应转向非阻塞模型或直接使用异步运行时。无论选择哪种方案，理解底层系统调用的行为都是排查问题、优化性能的关键。

← 上一章 📖 返回目录 下一章 →