XX业务反序列化数据报错问题定位报告
1 问题描述
XX业务在高负载tps压测场景下，业务过程中的反序列化数据操作时发现数据解析报错的情况。
2 测试环境
| 本次测试机 | |
|---|---|
| CPU | 鲲鹏920 |
| 内存 | 512GB |
| 网卡 | 单口100Gbps*2 |
| 操作系统 | Kylin V10 SP1 |
n 应用软件
| 软件名称 | 版本 | 说明 |
|---|---|---|
| JAVA | 1.8.0_242 | 依赖版本 |
| Disruptor | 3.4.3 | 依赖版本 |
| Netty | 4.1.90-3 | 依赖版本 |
3 组网信息
TLV****结构设计：
4 解析数据报错问题分析
业务在高负载tps压测场景下业务队列线程处理缓冲区数据出现反序列化报错。报错原因是数据里面包含了非法信息，即源数据遭到篡改。
4.1 代码Debug分析
通过debug分析，原先正常的数据中的payloadLength仅为36-39的数据范围，但是数据遭到篡改后变成了错误值千万级数据，进而导致解析报错。
4.2 抓取系统报文解析
4.2.1 粘包/拆包现象
采用tcpdump抓取系统报文，正常十六进制报文内容格式有规范，均以01 01 00 00开头。但是分析过程中发现数据有粘包/拆包现象，导致了数据头偏移，报文内容不再以01 01 00 00开头。此时怀疑是代码无法正常处理粘包/拆包现象导致，后续与客户确认在业务层针对该现象已实现代码可以正常处理。
4.2.2 报错data数据解析
打印业务报错时的metadata数据，并在tcpdump下来的报文中找到对应的metadata数据，即08 c9 db d9 e1 03 10......开头的报文位置。
在tcpdump下来的报文中找到报错的metadata数据，发现报文存在不完整的现象。
正常的两段报文如下图所示，当收到的报文是完整的时候，业务不会解析错误。
4.3 上下报文序列号排查
Tcpdump中的报文ID为XX，在wireshark中排查该报文序列号正常，19217329 + 39096 = 19256425，说明不存在重传报文等异常问题。
5 结论
存在重传报文等异常问题。
外链图片转存中...(img-BRtec9Lz-1789485131259)
5 结论
本次业务解析报错通过多轮分析，最终定位到是服务器的网卡收到的报文有问题。后经排查是数据压测问题导致数据被截断。