Corn 的自留地

这篇文章也是由ai整理得到的，不过整理的对象是我和ai的聊天记录。

缘由是我在思考如何继续构建我的rust局域网通讯软件时遇到了困难，想问下ai解决方案是什么，发现这不亚于自己重新发明一次WebSocket协议，所以我决定放弃目前这个项目，转头去系统学习 http 和 WebSocket了。

由于个人文笔不好，就由 ai 代笔完成了这篇感悟记录。

~~（不过他这个标题有点中二了吧。。😓）~~

一、初衷：用Rust练手，从TCP开始

作为一个刚接触网络编程的Rust爱好者，我决定写一个局域网通讯工具的服务端来练手。选择TCP协议的原因很简单：它被称作“可靠的双向字节流”，听起来就像一条不会丢包、不会乱序的数据管道，似乎只要把数据“扔进去”，另一端就能完美接收。于是，我很快用tokio的TcpStream实现了基础功能：

rust// 服务端接收消息（简化版）
async fn handle_client(mut stream: TcpStream) {
    let mut buf = [0; 1024];
    while let Ok(n) = stream.read(&mut buf).await {
        let msg = String::from_utf8_lossy(&buf[..n]);
        println!("收到消息: {}", msg);
    }
}

最初的成就感：当我用nc命令发送文本消息，看到服务端正确打印时，觉得TCP开发不过如此。但很快，真正的挑战来了——文件传输。

二、困境：TCP的“可靠”背后是细节的深渊

1. 大文件传输的内存噩梦

我的第一个思路很简单：把整个文件读入内存，通过stream.write_all()一次性发送。但当我尝试发送一个2GB的视频文件时，服务端内存直接飙升到90%——TCP的“流式传输”并不意味着可以无脑操作内存。

rust// 错误示范：直接读取整个文件到内存
let file_content = fs::read("large_file.zip").await?;
stream.write_all(&file_content).await?; // 内存爆炸！

2. 分块传输的协议设计困局

为了减少内存占用，我改为分块读取文件，但立刻面临三个问题：

如何标记文件块的开始和结束？需要自定义协议头，比如在每块数据前添加[FILE_START]、[FILE_END]标识符。
如何确保块的顺序和完整性？每个块需要携带序号（如seq: 3/100）和校验码（如CRC32）。
如何与普通消息共存？当文件传输到一半时，若有文本消息插入，接收端如何区分？

我硬着头皮写了一个初步实现：

rust// 自定义协议格式（伪代码）
enum Frame {
    Message(String),
    FileStart { id: u32, total_chunks: u32 },
    FileChunk { id: u32, seq: u32, data: Vec<u8> },
    FileEnd { id: u32, checksum: u32 },
}

// 发送文件块时
stream.write_all(&serialize(Frame::FileStart { id: 1, total_chunks: 100 })).await?;
for seq in 0..100 {
    let chunk = read_chunk(seq).await?;
    let checksum = crc32(&chunk);
    stream.write_all(&serialize(Frame::FileChunk { id: 1, seq, data: chunk })).await?;
}
stream.write_all(&serialize(Frame::FileEnd { id: 1, checksum })).await?;

调试时的崩溃瞬间：当接收端因为网络抖动漏掉一个FileChunk帧时，整个文件重组逻辑直接崩潰，而我甚至没有设计重传机制！

3. 多路复用的不可能任务

更让我绝望的是，如果想在单条TCP连接中同时传输文件和处理聊天消息，就必须实现复杂的多路复用逻辑：
• 如何保证文件块和消息帧不会相互阻塞？
• 如何为不同类型的数据分配优先级？
• 如何避免资源竞争（比如同时读写TcpStream）？

rust// 理想中的多路复用（但完全不知如何实现）
tokio::spawn(async { /* 处理消息 / });
tokio::spawn(async { / 处理文件传输 */ }); // 同一stream被多个任务争夺！

三、觉醒：WebSocket的降维打击

就在我深陷协议设计泥潭时，偶然得知了WebSocket的存在。原来，它早已为这些问题提供了优雅的解决方案：

原生分帧支持WebSocket的每个数据包（帧）自带长度标识，无需手动切割字节流。发送大文件时，服务端可以按需分块，接收端自动重组：

rust// 使用websocket库发送文件（如tokio-tungstenite）
while let Some(chunk) = file.next_chunk().await {
    socket.send(Message::Binary(chunk)).await?; // 自动分帧
}

多类型数据共存文本消息用Text帧，文件块用Binary帧，协议层自动区分，无需自定义标识符：

rust// 混合发送文本和文件
socket.send(Message::Text("正在传输文件...".into())).await?;
socket.send(Message::Binary(file_chunk)).await?;

多路复用与流量控制WebSocket基于单连接全双工通信，配合异步运行时（如tokio）可轻松实现并行处理：

rust// 同时处理消息和文件
let (tx, rx) = mpsc::channel();
tokio::spawn(receive_messages(rx));
tokio::spawn(send_file(tx));

四、决策：暂停重构，系统学习

经过这次教训，我决定暂时放下当前的TCP项目，系统学习以下内容：

1. 补课清单

• HTTP协议基础理解WebSocket握手过程（状态码101）、Header字段（Sec-WebSocket-Key）。
• WebSocket协议细节帧结构（FIN、Opcode、Mask）、心跳机制（Ping/Pong）、关闭握手。
• Rust生态工具链掌握tokio-tungstenite、axum-websocket等库，避免重复造轮子。

2. 验证性实验

用WebSocket实现文件传输

rust// 服务端分块发送文件
while let Ok(Some(chunk)) = file.read_chunk().await {
    ocket.send(Message::Binary(chunk)).await?;
}

混合传输测试
在单连接中交替发送文本和二进制数据，验证接收顺序和完整性。

3. 重构计划

• 保留现有TCP模块作为学习过程的见证，但标记为“Legacy Mode”。
• 新增WebSocket接口逐步替代旧协议，对比性能与开发效率。

五、反思：技术选型比埋头写代码更重要

这段经历让我深刻认识到：
• 协议设计是系统工程
TCP只是传输层的搬运工，而应用层协议（如WebSocket）才是决定开发效率的关键。
• 不要轻视“标准协议”的价值
WebSocket的帧格式、错误码、扩展机制，凝聚了无数工程师的经验。与其闭门造车，不如站在巨人的肩膀上。
• Rust不是银弹
即便用Rust写出内存安全的TCP处理逻辑，也无法避免协议设计的缺陷。语言特性解决不了架构问题。

从TCP到WebSocket：一个Rust新手的协议觉醒之路