重新组装的 PDU 长度为 1 的 TCP 段答案

【问题标题】：TCP segment of a reassembled PDU length 1重新组装的 PDU 长度为 1 的 TCP 段
【发布时间】：2014-08-17 05:27:11
【问题描述】：

我在 Oracle 数据库中遇到超时错误，当我使用 Wireshark 嗅探它时，我得到一个包含以下信息的数据包：重新组装的 PDU 的 TCP 段。

它有这个 TCP 信息：

传输控制协议，Src 端口：ncube-lm (1521)，Dst 端口：57861 (57861)，Seq：1，Ack：1，Len：1

我还有 10 个数据包，其来源和目的地与上述相同。

在第一个带有“重组 PDU 的 TCP 段”信息的数据包之后，有 9 个相同的数据包：

2728 596.537143000 10.XX.XX.XX 10.YY.YY.YY TCP 55 [TCP Keep-Alive] ncube-lm > 57861 [ACK] Seq=1 Ack=1 Win=258 Len=1 .

那么我有最后一个数据包：

2746 605.585011000 10.XX.XX.XX 10.YY.YY.YY TCP 54 ncube-lm > 57861 [RST, ACK] Seq=2 Ack=1 Win=0 Len=0

最后一个数据包出现在数据库中发生超时的确切时间。

如何重新组装长度为 1 的数据包？为什么它来自我们自己的本地机器时被重新组装？

此数据包的来源是我们的 Oracle 数据库（端口 1521）。为什么它发送一个包含一个字节数据的数据包（值为'00'）？

谢谢！

【问题讨论】：

【解决方案1】：

默认情况下，keep-alive(tcp_keepalive_probes) 探测计数为 9。机器已发送 9 次 keep-alive 探测，但未从另一端得到任何响应，因此已重置连接。

【讨论】：

【解决方案2】：

通常，len 为 1 的 TCP 数据包是控制数据包（ACK、SYN、FIN、RST）。我猜你遇到的就是这种情况。此外，Wireshark 数据包额外信息（在您的情况下 - '重新组装的 PDU 的 TCP 段'）有时会错误地标记数据包，因此您不应完全依赖它。

我不认为这些数据包是超时问题的原因。你能提供更多关于会话的其余部分和数据包时间的信息吗？

【讨论】：

感谢您对 Evyatar 的回答。我只有 11 个与上面提到的具有相同来源和目的地的数据包。在第一个包含信息“重组 PDU 的 TCP 段”的数据包之后，出现 9 个相同的数据包：2728 596.537143000 10.XX.XX.XX 10.YY.YY.YY TCP 55 [TCP Keep-Alive] ncube-lm > 57861 [ ACK] Seq=1 Ack=1 Win=258 Len=1。然后我有最后一个数据包： 2746 605.585011000 10.XX.XX.XX 10.YY.YY.YY TCP 54 ncube-lm > 57861 [RST, ACK] Seq=2 Ack=1 Win=0 Len=0 准确数据库中发生超时的时间。
这些是时间戳：15：55：52.008147000 15：53.006458000 15：55：55：55.018789000 15：57.031243000 15：55：57.03124300015：55：57.03124300015：5 55:59.043493000 15:56:00.041838000 15:56:01.055949000 15:56:02.054326000
看起来 dvasanth 是正确的。我会继续检查另一端。