Por que o cURL é mais lento que o wget?

Question

Página de teste: link

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 o 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, tanto quanto eu posso testar. Todas as máquinas (eu tentei várias), são todas baseadas no Debian (executando o software mais recente) e têm o IPv6 ativado, mas esse site não tem registros IPv6. Todos os testes são um pouco mais de 1 minuto - o que parece que está acabando?

O pedido para o Google é rápido:

# time curl https://www.google.com/ &>/dev/null

real    0m0.550s
user    0m0.020s
sys     0m0.012s

Adicionar o parâmetro "-4" para cURL para forçar o IPv4 não parece mudar nada.

Qual poderia ser a causa?

    

Answer 1

Use o tcpdump na porta 53 UDP, para examinar como a conexão funciona ao buscar o site por CURL e por wget na segunda guia. O motivo usual é causado pelo conflito de ipv4 / v6, que pode ser corrigido ao desabilitar o ipv6 em sysctl ou ao adicionar a opção single-request-reopen ao /etc/resolv.conf