ZeroMQ以其多样化的消息传输模式著称，比如请求应答、发布订阅、推拉模式等，这些模式都假设通信双方使用ZeroMQ协议。但在实际项目中，我们经常需要与不使用ZeroMQ协议的普通TCP客户端打交道，例如HTTP服务器、Telnet终端或者自定义的文本协议。CZTop库中的Stream套接字正是为解决这类问题而设计的，它把原始的TCP连接抽象成ZeroMQ风格的消息流，让开发者既能享受ZeroMQ的事件驱动IO模型，又能兼容任意协议的客户端。
Stream套接字的工作原理与消息帧结构
Stream套接字与其他ZeroMQ套接字最本质的区别在于，它工作在原始TCP层之上，没有使用ZeroMQ自有的握手协议和消息封装格式。这意味着任何一个普通的TCP客户端，比如用netcat或telnet发起的连接，都可以直接与Stream套接字通信，完全不需要安装ZeroMQ库。对于服务端来说，这提供了一种把ZeroMQ生态与非ZeroMQ世界连接起来的桥梁能力。
为了让应用层能够区分不同的TCP连接，Stream套接字在每条消息前面附加了一个路由ID，这个ID本质上是对端连接的底层文件描述符编号。当你收到数据时，第一个帧就是路由ID，第二个帧才是真正的数据载荷；当你想要向某个客户端回发数据时，也必须先发送该客户端的路由ID帧，再发送数据帧。这种两帧一组的约定是使用Stream套接字时最容易出错的地方，漏发路由ID帧会导致发送失败或者数据发到了错误的连接上。
另一个关键细节是连接的生命周期事件也会以消息形式通知给你。当一个新的TCP连接建立时，Stream套接字会投递一条数据部分为空的消息；当连接断开时，同样会收到一条空消息。通过监听这些空帧，应用可以维护在线客户端列表，实现连接管理、超时踢除等逻辑。下面的伪代码描述了这个消息结构：
# 收到的每条消息由两个帧组成 # 帧一: routing_id (整数，代表底层连接的标识) # 帧二: payload (客户端发来的原始字节，连接建立或断开时为空字符串) # 发送数据的格式 # 先发 routing_id 帧，再发 payload 帧，顺序不能颠倒
由于Stream套接字面向的是字节流，ZeroMQ并不会在应用层帮你切分消息边界。TCP本身是流式协议，一次recv可能拿到半个请求，也可能拿到多个请求粘在一起，因此基于Stream套接字构建服务时，必须自行设计协议的拆包逻辑，比如按换行符切分、按固定长度读取，或者实现一个带长度前缀的帧协议。
用CZTop实现一个Echo服务器与客户端
理解了帧结构之后，我们来看一个完整的例子。下面是一个基于CZTop::Stream的回显服务器，它监听5556端口，把客户端发来的内容原样返回。代码中使用CZTop::Poller来轮询就绪事件，这是CZTop推荐的IO多路复用方式，比手动循环read更加高效：
require 'cztop'
ctx = CZTop::Context.new
server = CZTop::Socket::STREAM.new
server.bind('tcp://127.0.0.1:5556')
poller = CZTop::Poller.new(server)
loop do
poller.wait do |socket|
msg = socket.receive
routing_id = msg[0]
payload = msg[1]
if payload.empty?
# 空帧代表连接建立或断开事件
puts "connection event, routing_id: #{routing_id}"
next
end
# 原样回写，注意必须先带上routing_id帧
socket.send(routing_id)
socket.send(payload)
end
end测试这个服务器非常简单，不需要编写客户端代码，直接在终端里用nc命令即可验证。打开两个终端，先运行服务器脚本，然后在另一个终端执行 echo hello | nc 127.0.0.1 5556，你会看到服务器把hello原样返回。如果使用Ruby编写客户端，由于普通客户端是裸TCP，用Ruby标准库的TCPSocket就够了，无需引入任何ZeroMQ依赖：
require 'socket'
# 普通TCP客户端即可与Stream服务端通信
client = TCPSocket.new('127.0.0.1', 5556)
client.puts('hello from ruby client')
puts client.gets # 读取回显结果
client.close这里需要注意收发数据的粒度问题。在回显这种场景下，收到什么就回什么，逻辑简单。但如果要实现请求应答语义，就需要在应用层缓存每个连接的接收缓冲区，按协议边界拼包后再处理。可以把每个routing_id对应一个Buffer对象，存放在Hash中，连接断开的空帧到来时清理对应条目，这样就能构建出健壮的有状态连接管理。
Stream与其他ZeroMQ模式的对比及适用场景
很多初学者会拿Stream套接字与ROUTER模式混淆，因为两者都携带路由ID、都能与多个对端通信。关键区别在于对端使用的协议：ROUTER的对端必须也是ZeroMQ套接字（通常是DEALER），通信时使用ZeroMQ的帧封装和握手协议；而Stream的对端是任意TCP程序，没有协议要求。简单来说，通信双方都是ZeroMQ就用ROUTER，一端是ZeroMQ另一端是普通TCP就选Stream。
对比REQ REP这类高级模式，Stream牺牲了内置的请求应答配对、消息排队、慢加入者处理等特性，换来了协议无关性。它不会自动重连、不会自动重发、不保证消息可靠投递到应用层处理完毕，可靠性需要应用自己保证。因此Stream更适合作为网关或适配层的角色：一端对接外部的HTTP、WebSocket升级前的TCP、自定义二进制协议客户端，另一端通过CZTop的其他套接字把消息转发进ZeroMQ内部网络。
| 特性 | Stream | Router | Req/Rep |
|---|---|---|---|
| 对端要求 | 任意TCP程序 | ZeroMQ套接字 | ZeroMQ套接字 |
| 连接管理 | 需自行维护 | 自动 | 自动 |
| 消息边界 | 需自行拆包 | 帧天然分界 | 帧天然分界 |
| 典型用途 | 协议网关 | 无状态路由 | 简单RPC |
实践中一个常见的组合是：用Stream套接字接收外部设备的裸TCP上报数据，在应用层完成协议解析后，通过PUSH或PUB套接字分发给后端的ZeroMQ工作集群。反向链路则是后端通过ROUTER把响应交给网关进程，网关再查表找到目标连接的routing_id，用Stream回写。这种架构让协议适配逻辑集中在网关一层，内部服务完全不感知底层协议差异，是Stream套接字最有价值的用法。
总结来说，CZTop::Stream并不是日常业务开发中最高频的套接字类型，但当你需要把ZeroMQ的事件驱动模型延伸到非ZeroMQ的TCP世界时，它是Ruby生态里最顺手的选择。掌握routing_id加空帧的约定、自行处理粘包与连接生命周期，是写好Stream服务的关键，希望本文的示例和分析能帮你少走弯路。