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

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

Тестовая страница: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, похоже, ничего не меняет.

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

решение1

Используйте tcpdumpпорт 53 UDP, чтобы проверить, как работает соединение при загрузке сайта с помощью CURL и wget на второй вкладке.

Обычно причиной является конфликт IPv4/IPv6, который можно устранить, отключив IPv6 в sysctl или добавив опцию single-request-reopen в /etc/resolv.conf.

Связанный контент