一位客户尝试向我们的 Exchange 服务器之一发送带有（较小和较大）附件的电子邮件，但在超时后重置了连接。在我看来，发送服务器似乎没有收到 ACK，因此重新发送，导致我们这边出现 DUP ACK。我们正在使用 Cisco ASA，但我们没有对任何相关接口使用任何 smtp/esmtp 策略（又名修复 smtp）（它用于完全不同的 vlan，其中没有 Exchange）。
1.1.1.1 接收 smtp 服务器
2.2.2.2 发送 smtp 服务器
直到“S: 354 开始邮件输入；以 . 结尾”，它都运行正常。问题真正出现在发送数据时。
Wireshark 转储
无时间源目标协议长度信息 20 504.923698 1.1.1.1 2.2.2.2 SMTP 78 S: 250 2.1.5 收件人 OK 无时间源目标协议长度信息 21 505.304394 2.2.2.2 1.1.1.1 SMTP 60 C：数据 无时间源目标协议长度信息 22 505.304713 1.1.1.1 2.2.2.2 SMTP 100 S: 354 开始邮件输入；以 结束。 无时间源目标协议长度信息 23 505.599857 2.2.2.2 1.1.1.1 SMTP 1434 C：数据片段，1380 字节 无时间源目标协议长度信息 24 505.620808 2.2.2.2 1.1.1.1 SMTP 1434 C：数据片段，1380 字节 无时间源目标协议长度信息 25 505.620823 1.1.1.1 2.2.2.2 TCP 54 smtp > 55346 [ACK] 序列号=450 确认=2904 赢=64860 长度=0 无时间源目标协议长度信息 26 505.919899 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 前一个段丢失] C：数据段，1380 字节 无时间源目标协议长度信息 27 505.919912 1.1.1.1 2.2.2.2 TCP 54 [TCP 重复 ACK 25#1] smtp > 55346 [ACK] Seq=450 Ack=2904 Win=64860 Len=0 无时间源目标协议长度信息 28 505.940785 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 前一个段丢失] C：数据片段，1380 字节 编号 时间 源 目标 协议 长度 信息 29 505.940797 1.1.1.1 2.2.2.2 TCP 54 [TCP 重复 ACK 25＃2] smtp > 55346 [ACK] Seq=450 Ack=2904 Win=64860 Len=0 编号 时间 源 目标 协议 长度 信息 30 505.961793 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 重传] C：数据片段，1380 字节 编号 时间 源 目标 协议 长度 信息 31 505.982494 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 重传] C：数据片段，1380 字节 编号 时间 源 目标 协议 长度 信息 32 505.982508 1.1.1.1 2.2.2.2 TCP 54 smtp > 55346 [ACK] 序列号=450 确认=4284 赢=64860 长度=0 编号 时间 源 目标 协议 长度 信息 33 506.302829 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 前一个段丢失] C：数据片段，1380 字节 编号 时间 源 目标 协议 长度 信息 34 506.302846 1.1.1.1 2.2.2.2 TCP 54 [TCP 重复 ACK 32#1] smtp > 55346 [ACK] Seq=450 Ack=4284 Win=64860 Len=0 编号 时间 源 目标 协议 长度 信息 35 506.323446 2.2.2.2 1.1.1.1 SMTP 1434 [TCP 重传] C：数据片段，1380 字节
等等，直到超时。
我们运行其他 Exchange 服务器，发件人可以向其发送相同的电子邮件。我们所有的 Exchange 服务器都位于相同的防火墙、路由器和交换机后面。可能只有接线不同。
哦，从 gmail 向服务器发送 15MB 的附件是可行的
正常连续 ping：
2.2.2.2 的 Ping 统计信息：
数据包：已发送 = 249，已接收 = 249，丢失 = 0（0% 丢失），
近似往返时间（以毫秒为单位）：
最小值 = 82 毫秒，最大值 = 546 毫秒，平均值 = 138 毫秒
^C
# 992 字节的未碎片数据包可以正常工作
C:\Users\someadmin>ping -f -l 992 2.2.2.2
对 2.2.2.2 执行 ping 操作，数据为 992 字节：
来自 2.2.2.2 的回复：字节=992 时间=100ms TTL=48
来自 2.2.2.2 的回复：字节=992 时间=101ms TTL=48
来自 2.2.2.2 的回复：字节=992 时间=101ms TTL=48
来自 2.2.2.2 的回复：字节=992 时间=100ms TTL=48
2.2.2.2 的 Ping 统计信息：
数据包：已发送 = 4，已接收 = 4，丢失 = 0（0% 丢失），
近似往返时间（以毫秒为单位）：
最小值 = 100 毫秒，最大值 = 101 毫秒，平均值 = 100 毫秒
# 未碎片化的 993 字节数据包失败
C:\Users\someadmin>ping -f -l 993 2.2.2.2
对 2.2.2.2 执行 ping 操作，数据为 993 字节：
请求超时。
请求超时。
请求超时。
请求超时。
2.2.2.2 的 Ping 统计信息：
数据包：已发送 = 4，已接收 = 0，丢失 = 4（100％丢失），
但是我可以使用大数据包 ping googles dns：
ping -f -l 1472 8.8.8.8 正在 ping 8.8.8.8，数据为 1472 字节： 来自 8.8.8.8 的回复：字节=64（已发送 1472）时间=31ms TTL=51 ping -f -l 1472 8.8.4.4 正在 ping 8.8.4.4，数据为 1472 字节： 来自 8.8.4.4 的回复：字节=64（已发送 1472）时间=30ms TTL=51
思科 ASA 策略
类映射检查默认 匹配默认检查流量 ！ ！ 策略映射类型检查 DNS preset_dns_map 参数 消息长度最大客户端自动 消息长度最大为 3096 没有 DNS 保护 不执行协议 无 nat-rewrite 策略图 global_policy 检查类_默认 检查 DNS preset_dns_map 检查 ftp 检查 h323 h225 检查 h323 ras 检查 rsh 检查 rtsp 检查 sqlnet 检查瘦 检查 sunrpc 检查 xdmcp 检查 SIP 检查 netbios 检查 tftp 检查 ip 选项 检查 icmp 策略图 shape_policy 类类默认 警方输入 10000000 5000 警察输出 10000000 5000 ！
我应该从哪里开始查找？我应该先要求发送方执行相同的 wireshark/tcpdump 跟踪吗？
答案1
很难确定，但我认为，这里存在 MTU 路径问题。执行路径 MTU 发现并相应地减少网关（或服务器 NIC）的 MTU。如果它解决了您的问题，那么您就有证据表明路径中的某个节点没有正确处理 MTU（要么丢弃 ICMP 代码 4 数据包，要么根本不发回）。