Почему cURL медленнее, чем wget

Question

Тестовая страница: https://www.beobank.be/nl/Home.aspx

Это результат использования wget (или реального браузера):

# 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

И это результат использования curl:

# time curl https://www.beobank.be/nl/Home.aspx &>/dev/null

real    1m0.741s
user    0m0.012s
sys     0m0.012s

OS X, кажется, не имеет этой проблемы (cURL работает быстро). Насколько я могу проверить, это происходит только в Linux. Все машины (я пробовал несколько) основаны на Debian (работает последняя версия программного обеспечения) и имеют IPv6, но на этом сайте нет записей IPv6. Все тесты занимают чуть более 1 минуты - что, кажется, что-то истекает?

Запрос в Google быстро:

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

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

Добавление параметра -4 в cURL для принудительной установки IPv4, похоже, ничего не меняет.

Что может быть причиной?

Answer 1

Используйте tcpdump на порту 53 UDP, чтобы проверить, как работает соединение, когда вы выбираете сайт по CURL и по wget во второй вкладке. Обычная причина вызвана конфликтом ipv4/v6, который можно исправить, отключив ipv6 в sysctl или добавив параметр single-request-reopen в /etc/resolv.conf