我遇到了一个非常奇怪的问题，某些数据包无法到达目标主机。当我们传输比 MTU 稍大的 POST 时，就会发生这种情况。我们可以用这个脚本重现它：
#!/usr/bin/python
import urllib2
magic_length = 2297
logurl = 'http://www.example.nl/'
data = (magic_length - len(logurl)) * 'X'
headers = {'content-type': 'application/x-www-form-urlencoded', 'User-Agent': 'Fake'}
request = urllib2.Request(logurl, data, headers)
handler = urllib2.build_opener(urllib2.HTTPHandler())
answer = handler.open(request, timeout=5)
发送方得不到 ACK 并进行重传。接收方永远看不到它。
这取决于您在哪里运行脚本以及您发布到哪里。我家里的连接失败了（顺便说一句，几个月以来我一直遇到 AJAX POST 无法通过的问题；因为我换了一个新的调制解调器）。
如果我将发送机器的 MTU 减少 100，它又可以正常工作。但是，如果我magic_length也减少 100，它又会失败。第一种理论是，我的 ADSL 的一层（如 PPPoA）添加了标头并导致数据包被错误拆分，但当时似乎不是这样。
也许 MTU 发现出了问题。也许有些跳线会阻止所有 ICMP？这是我从家里到谷歌的跟踪路由的第一部分：
traceroute to google.com (74.125.133.102), 30 hops max, 60 byte packets
1 dsldevice.lan (192.168.2.254) 0.453 ms 0.547 ms 0.636 ms
2 195.190.243.7 (195.190.243.7) 29.836 ms 29.947 ms 29.986 ms
3 nl-zl-dc2-git-cr02.kpn.net (213.75.64.237) 37.004 ms 37.153 ms 37.204 ms
4 nl-rt-dc2-ice-ir02.kpn.net (213.75.64.236) 37.261 ms 37.300 ms 37.339 ms
5 72.14.198.161 (72.14.198.161) 38.351 ms 38.395 ms 38.405 ms
6 209.85.254.92 (209.85.254.92) 37.976 ms 38.103 ms 37.972 ms
7 209.85.253.247 (209.85.253.247) 38.612 ms 72.14.238.153 (72.14.238.153) 33.709 ms 209.85.253.249 (209.85.253.249) 36.890 ms
8 209.85.240.158 (209.85.240.158) 41.052 ms 41.104 ms 209.85.244.102 (209.85.244.102) 41.164 ms
9 209.85.249.12 (209.85.249.12) 38.392 ms 209.85.249.14 (209.85.249.14) 38.247 ms 38.851 ms^C
如果我 ping 213.75.64.237，我会得到（我实际上从未在 STDOUT 上看到过‘数据包过滤’作为响应...）：
PING 213.75.64.237 (213.75.64.237) 56(84) bytes of data.
From 213.75.64.237 icmp_seq=1 Packet filtered
其余部分我都可以 ping 通。
这个答案看起来类似。但是，我的脚本没有设置 DF（不分段）标志（编辑：更正，tcpdmp 确实显示 POST 请求上设置了该标志），当我在以下主机上运行脚本时，我也看不到 ICMP 请求返回给我做工作正常。另外，数据包已经被发送方拆分，因此发送第二个数据包会失败。
我该怎么做？ISP 的网络运营中心 (NOC) 本身就很难联系到，所以我需要有证据来证明发生了什么。他们不会帮我弄清楚的……
编辑：为了确认或否认 ICMP 类型 4（需要碎片化）假设，我这样做了：
$ ping -c 1 -M do -s 1472 host
PING host (1.2.3.4) 1472(1500) bytes of data.
1480 bytes from host (1.2.3.4): icmp_req=1 ttl=50 time=33.8 ms
这有效，但我有点困惑。“(1500)”是指总片段大小吗？我认为是这样，因为 1480 字节 + 20 字节 IP 标头是 1500 字节。
如果我将 ping 的大小增加一：
$ ping -c 1 -M do -s 1473 host
PING host (1.2.3.4) 1473(1501) bytes of data.
From pannekoek.lan (192.168.2.5) icmp_seq=1 Frag needed and DF set (mtu = 1500)
因此，这意味着两台主机之间的路径允许 1500 字节的数据包，并且不会发生碎片问题。看来我又回到原点了。
再次编辑：我发现了一些重要的东西。问题很简单，就是某些大小的数据包没有到达。它发生在我的调制解调器和 ISP 的第一个网关之间：
$ for i in `seq 1025 1030`; do ping -c 1 -M do -s $i 195.190.243.7; done
PING 195.190.243.7 (195.190.243.7) 1025(1053) bytes of data.
1033 bytes from 195.190.243.7: icmp_req=1 ttl=254 time=31.2 ms <- works
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 31.273/31.273/31.273/0.000 ms
==========================
PING 195.190.243.7 (195.190.243.7) 1026(1054) bytes of data.
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1027(1055) bytes of data.
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1028(1056) bytes of data.
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1029(1057) bytes of data.
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms <- packet loss
==========================
PING 195.190.243.7 (195.190.243.7) 1030(1058) bytes of data.
1038 bytes from 195.190.243.7: icmp_req=1 ttl=254 time=31.1 ms <- works
--- 195.190.243.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 31.177/31.177/31.177/0.000 ms
我想我必须让他们相信这是他们的问题。
答案1
从点 A 到点 B 的线路上，路由器配置了较低的 MTU，这就是问题所在。您是否尝试过进行跟踪以查看 ICMP 数据包究竟在哪里丢失？