发送大量数据后的RST，ACK

Question

我有一个IMAP服务器（Dovecot），我正在尝试创建1,200个邮箱（用于性能测试）。服务器成功创建邮箱。

在此操作之后，我想列出所有创建的文件夹。服务器发送一些数据，但是，在一段时间（接近1秒）后，CLIENT将RST，ACK发送到服务器，以响应服务器使用IMAP协议的命令响应创建的文件夹列表。

这是我的Wireshark转储代码段：

IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 29186, Ack: 20533, Len: 24
IMAP: Src Port: 56794 (56794), Dst Port: imap (143), Seq: 20533, Ack: 29210, Len: 15
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 29210, Ack: 20548, Len: 16384
TCP: 56794 > imap [ACK] Seq=20548 Ack=45594 Win=49408 Len=0 TSV=3940902 TSER=3940902
IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 45594, Ack: 20548, Len: 16384
TCP: 56794 > imap [RST, ACK] Seq=20548 Ack=61978 Win=49408 Len=0 TSV=3940902 TSER=3940902

编辑：好吧，我想我找出了客户端发送 RST 标志的原因。原因是我的环回接口的服务器超过 MTU 值。我已经检查了样本Mina服务器的类似行为 - 并且一切正常，即TCP / IP协议激活了大量数据包。所以 Dovecot 无法明智地管理数据包。但我有自己的IMAP服务器（基于MINA），问题仍然存在！

那么为什么TCP / IP协议管理已发送的数据包（根据MTU值进行拆分）只是对某些应用程序而不是对所有应用程序而言？

Answer 1

您对发送TCP重置的原因的假设不正确。如果您已超过MTU，则不受TCP管理。它在IP层进行管理，并且需要进行ICMP＆＃34;碎片化。消息将被发送到客户端。这样的消息应该然后导致客户端在IP层分段数据包。根据您共享的信息，这种情况不会发生。

关于环回接口，此流量不会靠近环回接口，是不是两个独立的设备？

可悲的是，您的跟踪文件仍无法提供有关此数据包原因的任何信息 -

IMAP: Src Port: imap (143), Dst Port: 56794 (56794), Seq: 45594, Ack: 20548, Len: 16384

导致TCP重置。我可以从这些信息中推断出更多的东西。

TCP有一个名为Maximum Segment size的选项，它类似但也不同:) TCP / IP堆栈独立于应用程序，并且不对每个应用程序应用不同的设置，它是系统范围的。

编辑：看着你的数据包捕获，没有任何迹象表明MTU问题。在任何地方都没有ICMP流量，因此我怀疑它不是问题。如果存在MTU问题，则应该在之前的响应中发生，因为来自IMAP服务器的LIST响应具有相同的大小并且窗口大小没有问题。

我唯一可以看到的是与最终响应的第一个元素（在RST之前）相关，其中部分答复看起来格格不入（参见附件）。 IMAP应用程序出现了问题，而且它回复的数据格式不正确。 - 查看与pcap中所有其他LIST响应一致的底部两个响应的差异