Тестовая страница: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
.