Tcp 客户端放弃请求时出现ldap性能问题。可能的网络问题

我们正试图调查LDAP服务器的性能问题。 我们正在从linux上的openldap转移到windows 2008上的Ownery（DirX）

LDAP是weblogic应用程序的用户存储，并在其中配置为 身份验证提供程序

一些应用程序现在遇到性能问题

硬件资源正常，可以使用其他LDAP客户端查询（新的）LDAP服务器 而且via脚本无法重现性能问题

然后我们看了一下网络。我们发现，对于受影响的应用程序，大量ldap“放弃请求”操作来自客户端。我们带着怀疑的目光观察了这一行为 最初的openldap服务器发现了一些，但很少有“放弃请求”操作。 我们还不知道客户在什么情况下决定发送放弃请求

下面的场景有点典型。在客户端发送放弃请求之后 首先在客户端，然后在服务器上显示一对ACK。而ldap发送的数据需要0.1-0.4秒。 而ACK的延迟似乎要付出代价

由于不太熟悉TCP协议，我希望有人帮助澄清/确认我的解释：

分组664是从服务器到分组662的ACK（放弃请求长度10）。 数据包663是从客户端到数据包661的确认（searchResDone）

如果我的解释正确，我现在将调查： -为什么放弃请求的确认需要如此长的时间（即0.20而不是0.04） （或者为什么服务器需要这么长时间才能确认放弃？） -为什么客户首先要发送放弃

还有其他想法吗

提前感谢,

迈克尔

。。。
657 9.2943 ldapserver ldapclient LDAP 170 searchResDone（57）
658 9.2948 ldapclient ldapserver TCP 66 18367>389[ACK]Seq=10007 ACK=19799 Len=0
659 9.2954 ldapclient ldapserver LDAP 1009搜索请求（134）
660 9.2972 ldapserver ldapclient LDAP 630 searchResEntry（134）
661 9.2973 ldapserver ldapclient LDAP 172 searchResDone（134）
序列号：45106，len=106
662 9.2978 ldapclient ldapserver LDAP 76放弃请求（134）
序列号：46818，len=10
663 9.3378 ldapclient ldapserver TCP 66 18368>389[ACK]Seq=46828 ACK=45212 Len=0
（确认该段的RTT为：0.040492000秒）
664 9.5062 ldapserver ldapclient TCP 66 389>18368[ACK]Seq=45212 ACK=46828 Len=0
（确认该段的RTT为：0.208397000秒）
665 9.5068 ldapclient ldapserver LDAP 183搜索请求（136）
666 9.5229 ldapserver ldapclient LDAP 163 searchResEntry（136）
667 9.5229 ldapserver ldapclient LDAP 170 searchResDone（136）
..