抓包看 KingbaseES 内部协议？官方给了个现成工具

调数据库问题，最难受的是什么？是程序报错、驱动报错，但你不知道客户端和服务端到底聊了什么。

以前排查这种问题，得上 tcpdump 抓包，然后对着十六进制报文猜。KingbaseES 里其实有个官方工具专门干这个，叫 kes_protocol_tool，能把数据库协议报文直接解析成能看懂的文字。今天就聊聊这工具怎么用。

它是什么原理

KingbaseES 的前端（客户端进程）和后端（服务端进程）之间跑的是 TCP 报文。kes_protocol_tool 做的事情，就是通过协议栈抓取这些 TCP 报文，只要是数据库相关的协议就尝试解释，把内容转成可读格式打印到屏幕上。

说白了就是数据库版的"抓包 + 协议解码器"。

官方文档说它从理论上不会对数据库的正常运行和协议交互造成影响，这点可以放心。

工具在哪、怎么启动

工具是单个二进制文件，跟着安装包走：

bash 复制代码

$KES_HOME/bin/kes_protocol_tool

启动格式就两个参数：物理网卡名 + 端口号。

bash 复制代码

[root@DB-NODE-1 bin]# ./kes_protocol_tool ens192 54333

这里两个关键点：

必须 root 跑。因为要直接从物理网卡抓 TCP 报文，普通用户没权限。
网卡和端口要对。端口是数据库实例实际监听的那个，网卡是实例绑定的物理网卡。搞错了就什么都抓不到。

启动之后，工具就一直抓、一直往屏幕上打，停不下来。想停就 Ctrl+C，或者另开个会话 kill 掉进程。

抓出来长什么样

启动后大概是这样：

ini 复制代码

[root@DB-NODE-1 bin]# ./kes_protocol_tool ens192 54333

Begin to monitor `intf` [ens192]

TCP [10.10.11.122]. [21298] -> [10.10.11.121]. [54333]
TCP [10.10.11.122]. [21298] -> [10.10.11.121]. [54333]
TCP [10.10.11.121]. [54333] -> [10.10.11.122]. [21298]
Backend->Frontend: AuthenticationSCMMethod
[SCRAM-SHA-256]
...
Frontend->Backend PasswordMessage
[c=biws, r=7G//fs1UayfPmS2BfasohcWkz79GiyRQNO1AKKPZs9WXNOXG, p=U8Pc4iPH9ySVhmzDAXN05mY2kuK7MRqv1fE30RwUEMg=]
...

能看到报文的流向（谁发给谁）、报文类型（AuthenticationSCMMethod、PasswordMessage 这种）、还有具体的参数内容。连接认证过程一目了然，比如这里能看到用的是 SCRAM-SHA-256 认证，密码消息的 nonce 和 proof 都在。

工具能识别的常见报文类型，后端有：AuthenticationOk、BindComplete、DataRow、EmptyQueryResponse、ErrorResponse、NoData、NoticeResponse、ParameterDescription、ParameterStatus、ParseComplete、ReadyForQuery；前端有：Bind、Close、Describe、Parse、PasswordMessage、Query、Terminate。

ErrorResponse 这种最有价值，里面带 S/V/C/M/D/H/P/W/F/L 这些字段，错误码、错误消息、详情全在里面，排查问题直接看这个比翻应用日志强多了。

什么时候用得上

官方列了几个场景，我挑实际有用的说：

调试服务器某个模块的工作状态：比如怀疑解析器、优化器某个环节有问题，看它跟客户端交互的报文就能判断走到哪一步了。
调试驱动问题：应用报错但 SQL 看起来没问题，抓一下看驱动发过来的 Parse、Bind、Execute 报文是不是符合预期，十有八九能定位是驱动版本问题还是参数问题。
调试应用用法：程序发了个 Query，服务端回了 ErrorResponse，报文里清清楚楚，不用去猜。
调试集群工作流程：集群节点之间怎么交互的，抓包看协议最直接。
排查网络引起的异常：报文都发不出来，或者半路丢了，看流向就明白了。

适合谁用？功能模块研发、测试、现场实施，都适用。

注意：加密协议抓不了

有个大坑必须提前说：SSL 会话、加密相关的协议都不支持。

也就是说，如果客户端和服务端之间走了 SSL/TLS 加密连接，这工具只能看到握手那一段，后续的报文全是密文，解析不了。

所以要抓完整内容，测试时可以把连接配成非加密的，或者抓没开 SSL 的链路。生产环境要是强制 SSL，这工具就派不上太大用场了，顶多看看连接建立阶段。

一点使用建议

抓包的时候尽量用单独的会话，别在跑业务的终端里跑，输出太多影响看。
先小流量验证：连一个客户端、执行一条简单 SQL，确认能抓到、能解析，再放大场景。
定位问题要带着"预期"去抓：先想清楚这个操作应该产生哪些报文，再看实际报文缺了哪条、多了哪条、内容对不对。
抓完记得关掉，这工具理论上不影响性能，但一直开着总归没必要。

结尾

这工具算是个"锦上添花"型的调试利器，日常用不上，但遇到协议层、驱动层的问题时，比对着十六进制报文硬啃强太多。而且它是官方自带的，不用装额外的抓包软件，对国产化环境（有些客户环境不让随便装 tcpdump）来说特别友好。

下次再遇到"应用连不上 KingbaseES"或者"驱动报奇怪的错"，先想起这个工具，可能十分钟就定位了。