ZeroMQ的ROUTER套接字并不像REP那样按连接自动匹配请求和响应，它属于一种更底层的路由型套接字。每次收到对端消息，ROUTER都会在最前面插入一个身份帧，这个帧就是对端连接的唯一标识。CZTop::Server在Ruby层封装了ROUTER套接字，把身份帧的处理从业务代码中剥离出来，但理解它内部的帧处理模式仍然很重要，尤其当你要做异步回复、广播或者自定义路由时。
如果开发者只使用CZTop::Server的高层接口，很可能完全感受不到身份帧的存在；一旦把Server替换成裸的ROUTER套接字，或者需要保存连接标识做延迟响应，就很容易被消息开头的二进制数据搞糊涂。因此，本文从ROUTER的帧结构讲起，再到CZTop::Server的自动处理机制，最后给出几种手动控制身份帧的模式与常见错误。
一、ROUTER套接字的身份帧从何而来
在ZeroMQ中，ROUTER套接字被设计用来处理多个对端连接，却不像DEALER那样进行负载均衡。它要求发送方在消息的第一个帧中指定目标身份，而这个身份正是接收消息时最前面那个帧的内容。对于REQ对端，ZeroMQ会自动生成一个随机身份；对于DEALER对端，可以在建立连接前通过设置socket选项显式指定身份。这个身份帧是二进制安全的，长度不固定，不能假设它是可打印的字符串。
为了直观看到身份帧的结构，可以直接使用CZTop的底层Socket::ROUTER来接收一条消息。下面的代码会打印出两个独立帧：第一帧是身份帧，第二帧才是REQ客户端发送的业务数据。如果把身份帧误当成业务内容处理，后续回复就会发错目标，甚至导致消息堆积在发送缓冲区中。
router = CZTop::Socket::ROUTER.new('tcp://*:5555')
msg = router.receive
identity = msg.pop # 第一帧：身份帧
payload = msg.pop # 第二帧：业务数据
puts "identity=#{identity.to_s.inspect}"
puts "payload=#{payload.to_s.inspect}"
在上面的代码中，msg.pop会按顺序弹出帧。如果对端发送的是多帧消息，那么payload之后可能还有更多帧。了解这一点后，就不会在处理业务逻辑时错误地改变帧的数量。ROUTER发送回复时同样要求第一帧是目标身份，后面跟着的才是要送达的负载。这个简单的规则是理解CZTop::Server内部机制的基础。
二、CZTop::Server自动剥帧与回复粘帧
CZTop::Server的一个核心设计目标就是让开发者不必关心ROUTER的底层帧操作。它在内部为每一个连接维护了一个peer对象，每个peer对象都保存着对应的身份帧。当Server收到一个请求时，它会先弹出第一帧，把身份帧存储起来，然后把剩余的帧交给用户的处理块。用户处理块中拿到的Message已经不再包含身份帧，因此可以直接读取业务数据。
当用户处理块返回一个Message对象时，Server并不会直接发送这个Message，而是先从内部存储中取出当前连接的身份帧，再把它放到返回消息的最前面。换句话说，Server自动完成了回复粘帧的工作。这种设计让请求响应模式的代码非常简洁。下面是一个使用Server处理echo请求的示例。
require 'cztop'
server = CZTop::Server.new('tcp://*:5555')
server.listen do |message|
text = message.to_s
puts "处理请求: #{text}"
reply = CZTop::Message.new("echo #{text}")
reply
end
在上面示例中，用户只能看到负载帧，完全不需要知道身份帧的存在。如果返回的reply是一个多帧消息，Server仍然会在最前面加上身份帧后发送，保持帧边界不变。这种方式大幅降低了开发门槛，但同时也意味着一些高级场景无法只靠Server的高层接口完成，比如把一个请求的响应推迟到未来的某个时间点。
另外需要留意，CZTop::Server在处理过程中会假设用户返回的Message是最终回复内容。如果用户自己手动添加了身份帧再返回，就会导致回复中出现两个身份帧，从而破坏路由。因此在切换到Server封装之前，必须彻底忘记底层ROUTER的习惯，不要尝试手工操作第一个帧。
三、手动身份帧处理的三种实用模式
当业务需要异步回复、向某个特定客户端主动推送消息、或者使用自定义连接标识时，就需要绕过CZTop::Server，直接使用CZTop::Socket::ROUTER。手动处理身份帧有三种常见模式。第一种是单身份帧加单负载帧，这是最典型的请求响应场景，代码结构与之前展示的底层接收示例类似，回复时把身份帧放在数组的第一个位置即可。
第二种模式是多帧负载。ROUTER并不会把身份帧后面的多个帧合并，而是原样发送给目标对端。因此在处理多帧业务消息时，必须严格保持负载部分的帧顺序和帧数量。例如客户端发送了三帧数据，服务端回复时也要回复三帧，身份帧则始终只出现一次，位于最前面。下面的代码演示了异步回复时如何保存身份帧，并在稍后把身份帧重新放到发送队列顶部。
router = CZTop::Socket::ROUTER.new('tcp://*:5555')
identities = {}
loop do
msg = router.receive
id = msg.pop
body = msg.pop
# 保存身份帧，稍后异步回复
identities[body.to_s] = id
if body.to_s == "later"
next
else
reply = CZTop::Message.new("ok")
router << [id, reply]
end
end
第三种模式是使用DEALER作为客户端并设置固定身份。这样服务端在收到身份帧时可以得到一个可预期的标识，比如用户ID或者服务名称。对端连接前调用options.identity=即可。这样做的好处是服务端可以提前建立身份索引，即使连接尚未建立，也可以向指定身份发送消息。下面是一个简短的客户端示例。
dealer = CZTop::Socket::DEALER.new()
dealer.options.identity = 'client-001'
dealer.connect('tcp://localhost:5555')
设置固定身份后，服务端可以通过identity字符串直接构造发送目标。不过要谨慎处理身份冲突，同一网络内两个DEALER设置相同身份会导致路由混乱。通常建议使用随机身份或由服务端分配身份，而不是在客户端写死。
四、身份帧处理中的常见陷阱
最常犯的错误是把身份帧当成了业务数据的一部分。ROUTER接收消息时，第一帧永远不属于应用层，即使它看起来是空帧或者一段短文本。有些开发者会尝试把身份帧转换为字符串并输出，却发现该字符串包含不可打印字符，于是怀疑CZTop解析出错。实际上，这只是在错误地解释二进制数据。正确做法是通过inspect或者长度信息来观察身份帧内容。
另一个陷阱发生在连接断开重连之后。如果服务端缓存了某个对端的身份帧，而对端断开后重新连接，ZeroMQ通常会为新的连接分配新的身份帧，除非客户端显式设置了固定身份。继续向旧身份帧发送消息会导致数据进入黑洞。因此，在设计异步回复时，要么采用固定身份，要么在每次收到消息时更新缓存中的身份帧，并定期清理失效条目。
此外，手动发送消息时忘记在第一个位置放身份帧会直接报出路由错误。ZeroMQ对ROUTER的发送帧有严格校验，如果第一帧不是之前从该连接获得的有效身份，消息会静默丢弃或触发异常，具体行为取决于ZMQ版本。正确做法是始终把id作为数组的第一个元素传给发送方法，任何排序错误都会破坏消息传递的可靠性。
Ruby CZTopROUTER套接字身份帧处理修改时间：2026-09-25 08:08:40