Tudo isso começou quando eu estava tentando baixar um podcast no meu Mac. Isso acontece no Snow Leopard e no Lion quando a interface Ethernet está configurada para usar 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
Os cabeçalhos funcionam bem, mas o download nunca chega a lugar nenhum. Isto é oapenasservidor web com o qual tenho esse tipo de problema, mas ainda é irritante e gostaria de ver se há uma solução além de renunciar aos jumbo frames em todos os lugares.
Determinei que posso baixar um arquivo parcial, desde que o tamanho do bloco que estou baixando seja de 1.448 bytes ou menos. Posso usar o intervalo 0-1447 ou 10000-11447, então não é a posição no arquivo, é o tamanho do pedaço. O WAN MTU no meu roteador estava configurado para 1500, então tentei reduzi-lo passo a passo até chegar a 1400 e ainda assim não fez nenhuma diferença.
Eu estava pensando que isso era um problema com a descoberta do Path MTU Black Hole porque o problema desaparece quando eu paro de usar frames jumbo na interface Ethernet. Mas tenho tudo configurado para a descoberta de buracos negros (até onde sei) e o ping não vê nenhum problema:
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
Na verdade, o ping funciona até 1494 bytes, embora eu acredite que o Mac conte os bytes de maneira diferente de outros *nixes. (Acho que conta como dados os 8 bytes do cabeçalho ICMP, mas não os 20 bytes do cabeçalho IP, ao contrário da maioria que não conta e alguns que contam ambos.)
Não quero abrir mão dos benefícios de desempenho dos jumbo frames na minha LAN apenas por causa deste site quebrado, mas é claro que quero meu podcast. Então, estou procurando sugestões de coisas para tentar.
Meu Mac tem 2 portas Ethernet integradas, então uma coisa que tentei foi conectar a segunda com MTU 1500 e forçar curl
o uso dessa porta. Curl disse que estava usando essa porta, mas o MTU dessa porta não afetou se o download funcionava ou não. O que importava era o MTU da primeira porta Ethernet ativa. Também não sei o que isso significa.
Sugestões, alguém?
Responder1
Soluções alternativas:
- Reduza o MTU da interface para 1500. Preferências do Sistema -> Rede, selecione a interface (por exemplo, Ethernet integrada), clique no botão Avançado..., guia Ethernet, menu suspenso MTU ou defina Configurar como Automaticamente. Isso resolve o problema, mas significa que você não pode usar Jumbo Frames na LAN (pelo menos neste computador).
- Se fosse no Linux: use
iptables
para fixar o TCP MSS apenas para este host.--set-mss 1460
Solução:
- Corrija a configuração do servidor para diminuir o MTU ou fazer o Path MTU Discovery funcionar.
Acontece que finalmente consegui encontrar alguém com quem conversar na empresa CDN que pudesse implementar a solução, e eles baixaram o MTU e isso resolveu o problema.