Все это началось, когда я пытался загрузить подкаст на моем Mac. Это происходит как в Snow Leopard, так и в Lion, когда интерфейс Ethernet настроен на использование Jumbo Frames.
prompt> curl -v -o x.mpg http://audio.wnyc.org/freakonomics_specials/freakonomics_specials041112.mp3
* About to connect() to audio.wnyc.org port 80 (#0)
* Trying 204.93.180.53... Local Interface en0 is ip 172.16.1.2 using address family 2
* Local port: 0
* connected
* Connected to audio.wnyc.org (204.93.180.53) port 80 (#0)
> GET /freakonomics_specials/freakonomics_specials041112.mp3 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: audio.wnyc.org
> Accept: */*
>
OK
< Server: nginx/0.7.65
< Date: Mon, 16 Apr 2012 23:39:03 GMT
< Content-Type: audio/mpeg
< Content-Length: 42075070
< Last-Modified: Tue, 10 Apr 2012 21:15:08 GMT
< Connection: close
< Content-Disposition: attachment
< Accept-Ranges: bytes
<
0 40.1M 0 0 0 0 0 0 --:--:-- 0:00:24 --:--:-- 0^C
Заголовки проходят нормально, но загрузка никуда не денется. Это единственный веб-сервер, с которым у меня возникают подобные проблемы, но он по-прежнему раздражает, и я хотел бы посмотреть, есть ли какое-либо исправление, кроме пропуска больших кадров везде.
Я решил, что могу загрузить частичный файл, если размер загружаемого фрагмента составляет 1448 байт или меньше. Я могу использовать диапазон 0-1447 или 10000-11447, так что это не позиция в файле, а размер фрагмента. Значение WAN MTU на моем маршрутизаторе было установлено равным 1500, поэтому я попытался постепенно уменьшить его до 1400, и это все равно не имело никакого значения.
Я думал, что это была проблема с обнаружением Path MTU Black Hole, потому что проблема исчезает, когда я прекращаю использовать гигантские кадры в интерфейсе Ethernet. Но у меня все настроено для обнаружения черной дыры (насколько я могу судить), и ping не видит никаких проблем:
ping -g1435 -G1445 204.93.180.53PING 204.93.180.53 (204.93.180.53):
(1435 ... 1445) data bytes
1443 bytes from 204.93.180.53: icmp_seq=0 ttl=51 time=69.223 ms
1444 bytes from 204.93.180.53: icmp_seq=1 ttl=51 time=75.542 ms
1445 bytes from 204.93.180.53: icmp_seq=2 ttl=51 time=72.136 ms
1446 bytes from 204.93.180.53: icmp_seq=3 ttl=51 time=73.732 ms
1447 bytes from 204.93.180.53: icmp_seq=4 ttl=51 time=72.057 ms
1448 bytes from 204.93.180.53: icmp_seq=5 ttl=51 time=73.377 ms
1449 bytes from 204.93.180.53: icmp_seq=6 ttl=51 time=71.717 ms
1450 bytes from 204.93.180.53: icmp_seq=7 ttl=51 time=73.293 ms
1451 bytes from 204.93.180.53: icmp_seq=8 ttl=51 time=71.874 ms
1452 bytes from 204.93.180.53: icmp_seq=9 ttl=51 time=73.206 ms
1453 bytes from 204.93.180.53: icmp_seq=10 ttl=51 time=71.289 ms
Фактически, ping работает до 1494 байт, хотя я считаю, что Mac считает байты иначе, чем другие * nixes. (Я думаю, что в качестве данных он учитывает 8 байтов заголовка ICMP, но не 20 байтов заголовка IP, в отличие от большинства, которые тоже не учитываются, и некоторых, которые учитывают оба.)
Я не хочу отказываться от преимуществ, связанных с производительностью огромных кадров в моей локальной сети, только для этого сломанного веб-сайта, но, конечно, мне нужен мой подкаст. Поэтому я ищу предложения для вещей, чтобы попробовать.
Мой Mac имеет 2 встроенных порта Ethernet, поэтому я попытался подключить второй к MTU 1500 и заставить curl использовать этот порт. Керл сказал, что он использует этот порт, но MTU этого порта не влияет на загрузку или нет. Это был MTU первого активного порта Ethernet, который имел значение. Я тоже не знаю, что это значит.
Предложения, кто-нибудь?