Página de teste:https://www.beobank.be/nl/Home.aspx
Este é o resultado usando o wget (ou um navegador real):
# time wget https://www.beobank.be/nl/Home.aspx -O /dev/null
--2015-01-26 12:05:46-- https://www.beobank.be/nl/Home.aspx
Resolving www.beobank.be (www.beobank.be)... 62.213.211.94
Connecting to www.beobank.be (www.beobank.be)|62.213.211.94|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33444 (33K) [text/html]
Saving to: `/dev/null'
100%[======================================================================================================================================================>] 33,444 --.-K/s in 0.05s
2015-01-26 12:05:47 (670 KB/s) - `/dev/null' saved [33444/33444]
real 0m1.327s
user 0m1.072s
sys 0m0.060s
E este é o resultado usando curl:
# time curl https://www.beobank.be/nl/Home.aspx &>/dev/null
real 1m0.741s
user 0m0.012s
sys 0m0.012s
O OS X não parece ter esse problema (o cURL é rápido). Isso só acontece no Linux até onde posso testar. Todas as máquinas (tentei várias) são todas baseadas em Debian (executando o software mais recente) e possuem IPv6 habilitado, mas esse site não possui registros IPv6. Todos os testes duram pouco mais de 1 minuto - o que parece que algo está expirando?
A solicitação ao Google é rápida:
# time curl https://www.google.com/ &>/dev/null
real 0m0.550s
user 0m0.020s
sys 0m0.012s
Adicionar o parâmetro "-4" ao cURL para forçar o IPv4 não parece mudar nada.
O que poderia ser a causa?
Responder1
Use tcpdumpna porta 53 UDP, para examinar como funciona a conexão quando você está buscando um site por CURL e por wget na segunda aba.
O motivo usual é causado por conflito de IPv4/IPv6 que pode ser corrigido desativando o IPv6 no sysctl ou adicionando a opção single-request-reopen ao /etc/resolv.conf.