Testseite:https://www.beobank.be/nl/Home.aspx
Dies ist das Ergebnis bei Verwendung von wget (oder einem echten Browser):
# 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
Und dies ist das Ergebnis mit curl:
# time curl https://www.beobank.be/nl/Home.aspx &>/dev/null
real 1m0.741s
user 0m0.012s
sys 0m0.012s
OS X scheint dieses Problem nicht zu haben (cURL ist schnell). Soweit ich es testen kann, passiert das nur unter Linux. Alle Rechner (ich habe mehrere ausprobiert) basieren alle auf Debian (mit der neuesten Software) und haben IPv6 aktiviert, aber diese Website hat keine IPv6-Einträge. Alle Tests dauern etwas über 1 Minute – es scheint, als ob etwas eine Zeitüberschreitung hat?
Die Anfrage an Google ist schnell:
# time curl https://www.google.com/ &>/dev/null
real 0m0.550s
user 0m0.020s
sys 0m0.012s
Das Hinzufügen des Parameters „-4“ zu cURL, um IPv4 zu erzwingen, scheint nichts zu ändern.
Was könnte die Ursache sein?
Antwort1
Nutzen Sie tcpdumpauf Port 53 UDP, um zu prüfen, wie die Verbindung funktioniert, wenn Sie im zweiten Tab eine Site per CURL und per wget abrufen.
Der übliche Grund ist ein IPv4/IPv6-Konflikt, der behoben werden kann, indem IPv6 in sysctl deaktiviert oder die Option „Single-Request-Reopen“ hinzugefügt wird /etc/resolv.conf.