比特币节点握手记：连上网络的第一分钟交换了哪些信息

连接建立的物理顺序

比特币节点之间的任何数据交换，都从一次朴素的 TCP 连接开始。连上之后第一件事不是要数据，而是互相通报身份与能力：双方各自发出一条版本消息，里面写着各自的协议版本号、支持的服务位、时间戳、一个用于识别重复自连的随机数、用户代理字符串，以及一个是否想继续接收数据公告的开关。对端收下后用验证消息表示握手完成。在验证消息前后还有一个短暂窗口：支持按见证交易编号中继的节点会发送协商消息，把后续交易公告的编号方式从交易编号切换为对全部序列化数据取哈希的编号——这是隔离见证时代修补”双胞胎交易”问题的机制。

能力宣言之后各取所需

握手完成后，节点开始按能力表安排同步。区块头先行：发送者请求一批区块头，接收方沿着自己认可的最佳链连续返回；这条纯头部的链条让新节点先花几十兆字节建立”全图”，再决定往哪里下载真正的区块体。数据请求靠消息清单：谁发现新区块或新交易，就广播一个编号列表，对端根据本地缺失情况用数据消息索取原文。之后还有地址交换：节点把从对端身上观察到的可达地址告知彼此，供新连接者取用；支持新编码的节点之间会交换包含匿名网络地址的扩展格式。

这套寒暄里藏着的工程取舍

值得注意的第一点是”先声明后索取”：所有功能都以握手期声明的能力位为准，之后任何一方越界使用都算作协议违规，这条纪律避免了老版本节点被新流量打死。第二点是中继的开关哲学：不想接收交易数据的节点（比如只想同步区块的矿工节点或防火墙后设备）可以在版本消息里把转发标志关掉，此后对端只递区块不递交易——但这类连接会牺牲对交易广播网络的贡献。第三点是编号切换发生在连接粒度上：同一天里，你的节点可以一边和老节点用交易编号打招呼，一边和新节点用见证编号打招呼，各说各话但账本一致。

排查问题时的用法

当节点”连得上却不动”，回看握手的每一层能省很多盲目重启：TCP 通了但版本消息被拒，通常是协议版本过旧；验证之后收不到任何区块头，检查服务位与网络参数；块到了但交易始终不来，确认这条连接是普通连接还是被设计成只传区块的连接；频繁与”新版本”节点断开，则要看实现兼容性。把连接日志里的每一条握手消息与本章的顺序对号入座，比凭感觉调参数要快得多。

为什么把数据流拆成”先喊编号再取货”

比特币中继采用”公告加拉取”两段式：先广播编号清单，对端按需索取原文。这个看似绕弯的设计有三个实打实的收益。其一是去重经济：同一笔交易在网内每台节点只需下载一次，其余节点听到编号即知道”已见过”，避免洪泛式转发把带宽吃光；其二是隐私缓冲：编号公告不带内容，观察者无法仅凭公告判断你的钱包余额变化，交易原文与身份的关联被拉取时序稀释；其三是故障隔离：某台对端迟迟不响应索取请求，可以换一家拉取而无需重传已到账的数据。代价是传播延迟与孤儿缓存——先收到子交易、后见到父交易时，节点要暂存等待补全，这类缓存有容量上限，超限即丢弃。理解这套取舍后就能明白，为什么”我的交易广播出去了却只在几台节点上打转”通常不是丢包，而是费率与邻接关系的函数。

风险提示：本文描述的是协议层机制，各实现细节以对应项目文档为准；不构成投资建议。