Rust 会话类型：用类型状态机编织协议安全之网

在网络编程和多代理系统中，协议违规是最隐蔽也最危险的 bug 之一。Rust 的类型系统提供了一种优雅的方案——会话类型（Session Types），它在编译期就能证明协议被正确遵循，从根本上消除了状态机违规。

一、问题本质：协议即状态机

任何网络协议本质上都是一个有限状态机。以 SMTP 为例：HELO → MAIL FROM → RCPT TO → DATA → QUIT。如果在 DATA 状态发送 QUIT，或在 HELO 前发送 MAIL FROM，就是协议违规。

这类 bug 的生产表现为：序列化错误、对端断连、静默数据损坏。传统检测方式是单元测试 + 集成测试 + fuzzing，但再多的覆盖率也无法穷举所有交错路径。

二、会话类型的核心思想

会话类型将协议建模为类型级别的有限状态机。每一种协议状态对应一个类型，状态转换对应函数调用——这保证了：

1. 状态正确性：你不能在 "等待登录响应" 类型上调用 "发送文件" 方法
2. 终止性保证：协议的最终状态必须被到达（通常是关闭）
3. 通信安全性：发送方和接收方的通道类型是对偶的（dual）

用 Rust 的术语讲，就是利用 typestate pattern 和 phantom types 在编译期编码协议状态。

三、核心原语实现

3.1 双工通道基础

use std::marker::PhantomData;
use std::net::TcpStream;
use serde::{Serialize, de::DeserializeOwned};

/// 基础通道：携带读端和写端，类型参数 'proto 表示当前协议状态
pub struct Channel<State> {
    reader: std::io::Read,
    writer: std::io::Write,
    _marker: PhantomData<State>,
}

impl<State> Channel<State> {
    /// 发送消息，返回新状态类型的 Channel
    pub fn send<M: Serialize>(mut self, msg: M) -> Channel<Next>
    where
        State: CanSend<M, Next>,
    {
        bincode::serialize_into(&mut self.writer, &msg)
            .expect("send failed");
        Channel {
            reader: self.reader,
            writer: self.writer,
            _marker: PhantomData,
        }
    }

    /// 接收消息，返回 (消息, 新状态的 Channel)
    pub fn recv<M: DeserializeOwned>(mut self) -> (M, Channel<Next>)
    where
        State: CanRecv<M, Next>,
    {
        let msg = bincode::deserialize_from(&mut self.reader)
            .expect("recv failed");
        (msg, Channel {
            reader: self.reader,
            writer: self.writer,
            _marker: PhantomData,
        })
    }

    /// 关闭通道：仅当协议允许关闭时才能调用
    pub fn close(self)
    where
        State: CanClose,
    {
        drop(self);
    }
}

这里的神来之笔是 CanSend 和 CanRecv trait——它们构成了状态转移表（transition table），只有在特定状态允许发送/接收特定消息，才能完成调用。

3.2 状态转移表

/// 状态转移 trait：State A 发送 Message M 后转移到 State B
pub trait CanSend<M, Next> {}
/// 状态转移 trait：State A 接收 Message M 后转移到 State B
pub trait CanRecv<M, Next> {}
/// 终止状态允许关闭
pub trait CanClose {}

// 协议状态标记类型
pub struct Initialized;
pub struct SentGreeting;
pub struct WaitingAuth;
pub struct Authenticated;
pub struct SessionActive;

// 消息类型
pub struct Greeting { pub version: u32 }
pub struct AuthRequest { pub token: String }
pub struct AuthResponse { pub success: bool }
pub struct Command { pub payload: Vec<u8> }
pub struct Response { pub data: Vec<u8> }
pub struct Quit;

// 完整转移表
impl CanSend<Greeting, SentGreeting> for Initialized {}
impl CanRecv<Greeting, SentGreeting> for Initialized {}

impl CanSend<AuthRequest, WaitingAuth> for SentGreeting {}
impl CanRecv<AuthRequest, WaitingAuth> for SentGreeting {}

impl CanRecv<AuthResponse, Authenticated> for WaitingAuth {}
impl CanSend<AuthResponse, Authenticated> for WaitingAuth {}

impl CanSend<Command, SessionActive> for Authenticated {}
impl CanRecv<Command, Command> for Authenticated {}

impl CanSend<Response, Authenticated> for SessionActive {}
impl CanRecv<Response, Authenticated> for SessionActive {}

impl CanSend<Quit, Initialized> for Authenticated {}
impl CanRecv<Quit, Initialized> for Authenticated {}

impl CanClose for Initialized {}

四、编译期保障：错误即非代码

当你试图写出以下代码时，编译器会直接报错：

// 编译错误！SentGreeting 状态不允许直接发送 Command
fn bad_client(ch: Channel<SentGreeting>) {
    ch.send(Command { payload: vec![] });  // COMPILE ERROR
}

// 编译错误！没有为 WaitingAuth 实现 CanClose
fn premature_close(ch: Channel<WaitingAuth>) {
    ch.close();  // COMPILE ERROR
}

// 正确！遵循完整协议
fn correct_client(ch: Channel<Initialized>) {
    let ch = ch.send(Greeting { version: 1 });
    let ch = ch.send(AuthRequest { token: "secret".into() });
    let (_resp, ch): (AuthResponse, _) = ch.recv();
    let ch = ch.send(Command { payload: b"ls".to_vec() });
    let (_data, ch): (Response, _) = ch.recv();
    let ch = ch.send(Quit);
    ch.close();
}

这意味着什么？这意味着 只要代码能编译通过，协议就永远不会被违反——不依赖运行时检查，不依赖测试覆盖，不依赖代码审查。

五、高阶组合：选择（Branching）与递归协议

5.1 Offer/Choice 模式

/// 分支选择：接收方选择协议分支
pub enum Offer<A, B> {
    Left(Channel<A>),
    Right(Channel<B>),
}

impl<State> Channel<State> {
    /// 接收一个分支点
    pub fn offer<A, B>(self) -> Offer<A, B>
    where
        State: CanOffer<A, B>,
    {
        let mut buf = [0u8; 1];
        self.reader.read_exact(&mut buf).unwrap();
        match buf[0] {
            0 => Offer::Left(Channel { /* ... */ }),
            1 => Offer::Right(Channel { /* ... */ }),
            _ => panic!("invalid branch"),
        }
    }

    /// 发送选择（进入左分支或右分支）
    pub fn choose_left<Left, Right>(self) -> Channel<Left>
    where
        State: CanChoose<Left, Right>,
    {
        self.writer.write_all(&[0]).unwrap();
        Channel { /* ... */ }
    }
}

5.2 递归协议

/// μX. send T ; X  （无限循环发送）
pub struct Rec<T, Inner>(PhantomData<(T, Inner)>);

/// 'fold' 进入递归体，'unfold' 展开递归
pub trait RecFold<RecPoint> {}
pub trait RecUnfold<RecPoint> {}

// 例如：TELNET 风格的持续交互协议
// RecPoint -> Send Command; Recv Response; (RecPoint | Quit)

六、生产实践中选择 session-types crate

上述是教学级实现。生产环境可直接使用 'session-types' crate：

use session_types::*;

type Client = Send<u64, Recv<u64, Eps>>;  // 发送 u64，接收 u64，关闭
type Server = <Client as HasDual>::Dual;    // Recv<u64, Send<u64, Eps>>

fn client(c: Chan<Client>) {
    let c = c.send(42);
    let (n, c) = c.recv();
    println!("Got: {}", n);
    c.close();
}

也可以选择更轻量的方式——依赖 Rust 的 typestate pattern 即可：

// 编译期状态转移（零运行时开销）
pub struct Connection<S> { inner: TcpStream, _s: PhantomData<S> }
pub struct Disconnected;
pub struct Handshaked;
pub struct Ready;

impl Connection<Disconnected> {
    fn connect(addr: &str) -> io::Result<Connection<Handshaked>> { /* ... */ }
}
impl Connection<Handshaked> {
    fn handshake(self, creds: &str) -> io::Result<Connection<Ready>> { /* ... */ }
}
impl Connection<Ready> {
    fn send(&mut self, data: &[u8]) -> io::Result<usize> { /* ... */ }
}
// 无法在 Disconnected 上调用 send，编译器会拦截

七、何时使用会话类型

适合场景： - 实现自定义二进制协议（游戏、存储、IoT） - 强合规的金融系统（FIX 协议、SWIFT 消息） - 多跳网络中的中间节点（必须严格透传） - 智能合约中的状态通道协议

不适合场景： - 已使用 gRPC/Protobuf 等强类型 RPC 框架的场景 - 协议频繁变更的早期探索阶段 - 团队成员不熟悉类型驱动开发的场景（学习曲线陡峭）

八、总结

会话类型将协议验证从运行时测试提升到编译期证明。它不是一颗银珠——随着状态空间指数增长，类型签名会变得冗长。但对于核心共识节点、安全关键的网络协议而言，这把"编译期安全"的标尺值得投入。

Rust 的类型系统在此展现了独特优势：它能证明"这段代码永远不会在错误的协议状态下发送消息"——这种保证是动态类型语言永远无法提供的。