TCP 的数据包看吐了！ Bug 真·卡了一个1024的

一、背景

最近在预颁布环境上遇到一个特意诡异的疑问，事件大略是这样的：

设施在消费时须要走一个注册的环节，外面触及到和服务端启动 TCP 通讯失掉性能文件、发送密钥等操作，然而消费进展会卡在70%。

流程如下图所示。

大家不用细看外面的原理，只用看 D4 阶段和 D5 阶段即可。

数据通讯方式：TCP。

性能文件长这样，key=value 方式存储。

name=rabbitB2=asdf21...

当性能文件中的 name 字段为 rabbit 时，设施反常消费，当性能文件中的 name 字段为 rabbit-TD 时，设施就无法消费成功，消费进展会卡在 70%。

从现象来看，不确定是设施端没有口头 D5 阶段，还是服务端没有处置成功处置 D5 阶段。

二、排查环节

2.1、审核代码

审核下设施端和服务端的代码，有没有对 name 这个字段的长度做一些限度。

论断：设施端和服务端并没有对性能文件的字段长度做限度。

2.2、检查服务端日志

排查下服务端的日志，发现只要 D4 阶段的业务日志打印，D5 阶段的日志没有。

初步论断：设施端没有发送 D5 阶段的数据包。

2.3、服务端抓包

思绪：抓个包看下服务端有没有收到 D5 阶段的数据包。

在服务端经过 microsoft network monitor 抓包工具抓包，而后将抓包文件放到 wireshark 中排查。

下图是设施端和服务端的 TCP 通讯数据。

可以看到设施向服务端发送了性能文件（D4阶段），服务端发送了一个 ACK 照应。

在TCP（传输控制协定）通讯中，当客户端发送一条TCP信息给服务端时，服务端通常会发送一个ACK（确认）照应来标明它曾经成功接纳到了这条信息。这是基于TCP的牢靠传输机制，确保数据能够正确无误地从发送方传输到接纳方。

TCP经常使用序列号和确认号来成功牢靠传输。发送方会为每个发送的字节调配一个序列号，接纳方在收到数据后会发送一个ACK确认，确认号示意接纳方希冀接纳的下一个字节的序列号。假设发送方在必定期间内没有收到ACK确认，它会从新发送数据。（来自 AI）

初步论断：服务端发送了 D4 阶段的 ACK 照应。设施端没有发送 D5 阶段的数据包

留意：这个论断在前面的排查环节中被颠覆。

2.4、设施端抓包

思绪：抓个包看下服务端有没有发送 D5 阶段的数据包。经过如下命令在设施端抓个包：

#tcpdump -i fetho host 192.168.1.253

抓到的数据包如下所示：

经过上图的抓包结果可以看到最后一个阶段是 D4 和 D5，它俩其实是将数据包兼并在一同发送的（这个是我后来才发现的，也是 1024 卡 Bug 发生的源头）

也就是说 D4 和 D5 其实是一个阶段，并没有分开发。

而后设施端不时在期待服务端前往性能文件（P6 阶段）。

初步论断：设施端口头了 D5 阶段，服务端没有口头 P6 阶段，服务端有疑问。

2.5、再查服务端的数据包

这就难堪了，设施端明明口头了 D5 阶段，然而服务端看起来没有收到 D5 的数据包。

从新再看下最后一条数据包，报文内容如下图所示：

关上 D4 阶段的数据报文，可以看到数据外面是蕴含有 D4 阶段的性能文件内容以及D5阶段的文件内容，过后我看到这个报文是懵的：

我看之前的接口文档上写的是 D4 和 D5 阶段分开发送数据？怎样又合在一同发了？

要素：设施端将 D4和D5 的数据包延续写到 socket 中的。

初步论断：服务端没有正确处置 D4 和 D5 合体的数据包。

那怎样办？只能在服务端多加点日志打印看看 D5 的数据包为什么没有正确处置呢。

2.6、剖析数据包

3.6.1 name=rabbit 时的报文（可反常消费）

每个阶段发送一次性报文都是依照这样的格局启动发送：0x1234abcd, length, type,>

说明：

3.6.2 name=rabbit-TD时的报文（不能反常消费）

当性能文件中的 name 字段为 rabbit-TD 时，报文 D4 和 D5 合体后的报文内容如下：

说明：

日志的内容如下：

日志内容如下：

2.7、水落石出

因读取的数据报文到达1024 字节时，将业务数据的长度这四个字节做了切割，前面1024字节蕴含长度字段的第一个字节，长度字段的前面3个字节和恳求类型的 1个字节组成了长度字段的 4 个字节，也就是错位多读取了前面一个字节的内容，最后算出来长度的值为 65538，不等于前面的业务数据的 256 字节，造成服务端的程序报错，所续代码就没有口头了。

三、处置打算

3.1、打算一

要素就是前面读取的 length 的 1 个字节没有和后续读取的 length 的三个字节分解长度字段 length 的值，那么只需保障第二次读取长度字段length的时刻把之前的 1 个字节拿到即可。

3.2、打算二

还有一个卡 Bug 的打算：将 D4 阶段的性能文件参与一点内容，保障性能文件的内容 = 1014 + 1 =1 即可，或大于等于 1014+5 = 1019，目标就是把长度字段完整的四个字节卡到 1024 前面，或许把起始数据的四个字节也卡在 1024 前面。

验证了两种状况：name 为 Rabbit-TDDDDDDD 和 Rabbit-TDD 是反常消费的。上方是 Rabbit-TDD 的状况，正好将 D4 的数据 + D5 的起始数据卡满了 1024 字节。

如下图所示：

再来给大家算一遍如何卡 Bug 的，系统能反常运转。

1024 字节 = 1（性能文件报文内容） + 4（性能文件报文长度） + 1（恳求类型） + 4（D5报文起始数据）。

或

1024 字节 = 1019（性能文件报文内容） + 4（性能文件报文长度） + 1（恳求类型）= 1024 字节。

还有两个不懂：

- D4 阶段的起始数据为啥没有算到 1024 字节中，这里我也没弄懂 Socket的数据是怎样分开、兼并发送的。

- 服务端为什么是读取 1024 字节就会分红下次读取？技术栈是 mina 框架，出疑问的是 windows server 2003，而win10上没重现这个疑问。