（我知道 2013 很快就会停止支持并且会被取代，但在此期间，我遇到了一个想要解决的问题。）
我将使用通过端口 25 的 telnet 作为示例，但正常流量的行为方式也相同。
当我通过端口 25 向 Exchange 群集中的特定节点发送数据包时，需要等待 11 到 14 秒才能显示带有 220 响应的横幅。由于这也会影响电子邮件，因此某些服务依赖于此通信超时。
我知道的事情：
- 大约 70% 的节点会持续遇到此问题。而另外 30% 的节点似乎从未出现过此问题。它们都是在同一时间设置的，但在我之前可能有人更改了某些节点的设置，而没有更改其他节点的设置。然而，在我看来，它们“看起来”一模一样。
- 通过跟踪数据包，我可以看到 SMTP 流量立即到达目标服务器。（没有网络\延迟、防火墙、dns 等问题。一切顺利）
- 我看到 MSExchangeFrontendTransport.exe 立即出现 TCP 接受
- 此数据包进入 Windows 后，我看到了 TCP 接受，它需要整整 11-14 秒才能显示在 Exchange 日志（SMTP 协议连接器日志）中
- 目前尚不清楚该问题何时出现，但很可能是很久以前的事情了，只是之前的延迟没有造成任何影响。
因此，似乎有什么东西在控制着流量，但是我关闭了所有我能找到的并且深入研究了每一个可以想象到的日志和进程监控结果等，我看不到任何影响它的东西。
这可能是 Exchange 内部的问题，还是 Windows 系统进程内部的问题？如果没有直接建议的解决方案，您将从哪里着手调查这个问题？我不太确定近期最好的处理方式是什么。
任何帮助将不胜感激！
答案1
您看到的行为可能是一种称为 SMTP Tarpit 的安全功能。它会故意减慢 SMTP 响应速度，以缓解某些攻击类型，例如目录收集攻击。
该设置由注册表项控制，HKLM\System\CurrentControlSet\Services\SmtpSvc\Parameters\TarpitTime
值以秒为单位（DWORD）
注意：如果 TarpitTime 注册表项不存在，Exchange 的行为将如同此注册表项的值设置为 0。当注册表项的值为 0 时，发送 SMTP 地址验证响应时不会出现延迟
答案2
以秒为单位的延迟通常是向第三方发出请求的超时。因此，类似反向 DNS 查找传入 IP 或检查失效的 RBL 之类的操作也是如此。
如果您只捕获客户端和服务器之间的数据包，则很容易错过这一点。如果数据量不是太大，请尝试在传入连接时从服务器捕获所有内容*，看看它是否发出了没有响应的请求。DNS 是我的第一个猜测，但它不是唯一的可能性。
* 排除常识、法律和贵公司的隐私政策不允许的内容。