Ich habe einen Webserver mit Centos7, der Curl-Anfragen an andere Ressourcen stellt. Bei einer Rate von 5-10 Anfragen pro Sekunde funktioniert alles einwandfrei, außer dass ich alle 2-10 Minuten verschiedene Curl-Fehler bekomme. Ich glaube, das passierte mit der Zeit, als die Anzahl der Anfragen zunahm, was mich glauben lässt, dass es etwas mit dem Netzwerk zu tun hat, aber ich bin ein absoluter Neuling auf diesem Gebiet. Wie finde ich heraus, was diese Fehler verursacht, und was kann ich dagegen tun?
Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read
Antwort1
Die Ursachen dieser Fehler lassen sich höchstwahrscheinlich allgemein als „SNAFU“ einstufen. Normale Situation, alles im Eimer.
Das Internet ist ein riesiges Netzwerk aus miteinander verbundenen Computern und Netzwerkgeräten. Diese anderen Maschinen, über die Sie keine Kontrolle haben, tun nicht immer das, was sie sollten. Sie haben Stromausfälle. Sie haben Hardwarefehler. Sie werden von kosmischer Strahlung getroffen. Es passiert so etwas.
Die Netzwerktechnologien, die dem Internet zugrunde liegen, sind mit diesem Gedanken konzipiert. Der Grund, warum das Internet überhaupt funktioniert, ist ein enormes Maß an Redundanz. Wenn ein Versuch, über eine Route eine Verbindung zu einem Ziel herzustellen, fehlschlägt, merkt sich der letzte „Hop“ in dieser Kette, der funktioniert hat, den Fehler und versucht für die zukünftige Kommunikation einen anderen „nächsten Hop“. Tatsächlich ist es viel komplizierter als das … aber Sie verstehen, worum es geht.
Die meisten Webanwendungen wiederholen fehlgeschlagene Verbindungen, um diese Redundanz zu nutzen. Allerdings nicht alle. Je einfacher die Anwendung, desto wahrscheinlicher ist es, dass sie einfach fehlschlägt. Dies gilt insbesondere für Terminalanwendungen, die *nix-Prinzipien kleiner, auf einen Job spezialisierter Tools anwenden. Das Wiederholen ist die Aufgabe eines anderen Tools. curl
ist eine solche Anwendung. Lautdie curl
Manpage:
--wiederholen
Wenn beim Versuch von curl, eine Übertragung durchzuführen, ein vorübergehender Fehler zurückgegeben wird, führt es diese Anzahl von Wiederholungsversuchen durch, bevor es aufgibt.Wenn Sie die Zahl auf 0 setzen, führt curl keine Wiederholungsversuche durch (Das ist die Standardeinstellung). Vorübergehender Fehler bedeutet entweder: eine Zeitüberschreitung, einen FTP 4xx-Antwortcode oder einen HTTP 408- oder 5xx-Antwortcode.
Ich bin mir nicht sicher, was Ihr Anwendungsfall für das curl
Abrufen von Ressourcen ist, aber wenn Sie curl verwenden, um Ressourcen auf automatisierte Weise bereitzustellen, müssen Sie es unbedingt mit dem --retry
Flag mit einem Wert von 3-5 konfigurieren. Denn Fehler wie die von Ihnen gezeigten sind völlig normal ... und müssen berücksichtigt werden.
2. Warum ist die Zuverlässigkeit Ihres Produktionsservers schlechter als die Ihres lokalen Computers?
In einer perfekten WeltEin Produktionsserver hat immer eine zuverlässigere Verbindung zu internetbasierten Ressourcen als jede Internetverbindung zu Hause oder im Büro. Da dies hier nicht der Fall ist, ist es richtig, dass Sie sich für die Ursache interessieren. Das bedeutet jedoch nicht unbedingt, dass Sie sich Sorgen machen sollten, denn auch dieses Problem muss nicht unbedingt von Ihrem Server verursacht werden.
Bedenken Sie, dass Ihr lokaler Computer und Ihr Server mit ziemlicher Sicherheit nicht dieselbe Route zu den betreffenden Ressourcen verwenden. Wenn ich beispielsweise traceroute
von meinem lokalen Heimserver aus eine Verbindung zu ... ausführe, superuser.com
erhalte ich Folgendes:
user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 rtr.scrapyard.local (10.5.0.1)
2 96.120.58.37 (96.120.58.37)
3 po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
4 162.151.221.209 (162.151.221.209)
5 be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
6 * * *
7 50.242.151.138 (50.242.151.138)
8 151.101.1.69 (151.101.1.69)
Aber wenn ich denselben Befehl von einem meiner Produktionsserver aus ausführe, erhalte ich Folgendes:
user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 * * *
2 ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
3 ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
4 kanc-b1-link.telia.net (80.239.196.109)
5 dls-b22-link.telia.net (62.115.125.159)
6 fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
7 151.101.1.69 (151.101.1.69)
Der einzige Hop, den diese beiden Routen gemeinsam haben, ist das Ziel. Jede andere Maschine, die sie durchlaufen, ist anders. Wenn dls-b22-link.telia.net
sich also beispielsweise ein Computer schlecht verhält, würde dies die Versuche meines Servers beeinträchtigen, mit superuser.com zu kommunizieren ... aber nicht die Versuche meines Heimcomputers, dasselbe zu tun.
Leider, wenn esWarein Problem, mit dls-b22-link.telia.net
dem ich nicht viel tun könnte. Und angesichts der zeitweiligen Natur des Problems wäre es nicht besonders einfach, herauszufinden, wovon dls-b22-link.telia.net
das Problem ursprünglich herrührte.
Also...
2b. Ist das wirklich ein Problem?
Als Erstes sollten Sie bestätigen, dass dies ein tatsächliches Problem verursacht, das sich nicht durch einfaches Wiederholen der fehlgeschlagenen Verbindungen beheben lässt. Das bedeutet, dass Ihr Produktionsserver in irgendeiner Weise bei der Ausführung seiner Aufgabe beeinträchtigt wird. Ich gehe davon aus, dass Sie bei der Einrichtung ein bestimmtes Ziel vor Augen hatten.Wird dieses Ziel immer noch so erreicht, dass Sie nichts unternehmen müssen?Das ist die entscheidende Frage.
Um auf das zurückzukommen, was ich zuvor gesagt habe: Solche zeitweiligen Probleme sind einfach Teil des Internets. In einer perfekten Welt würden sie nicht auftreten, aber wir leben nicht in einer perfekten Welt … deshalb ist Redundanz ein Grundprinzip aller Technologien, auf denen das Internet basiert. Deshalb ist ein erneuter Versuch nach solchen Verbindungsfehlern das Standardverfahren. Und deshalb sollten Sie sich über solche Fehler nicht allzu viele Sorgen machen, es sei denn, sie beeinträchtigen Ihren Server aktiv.
2c. Haben Sie es unter Kontrolle?
Sie müssen die mögliche Ursache des Problems eingrenzen. Führen Sie dazu einfach dieselben Tests durch, die Sie bereits durchgeführt haben (zählen Sie die Anzahl der Fehler in einem bestimmten Zeitraum), aber lassen Sie den Server dieses Mal Ressourcen von einer völlig anderen Stelle anfordern. Ich würde vorschlagen, auf Ihrem Heimcomputer einen einfachen Webserver mit ein paar Dateien einzurichten, die denen ähneln, mit denen Sie gearbeitet haben, und curl
diese auf Ihrem Server zu verwenden.
Wenn der Server dabei keine Fehler aufweist, liegt das Problem höchstwahrscheinlich nicht an Ihrem Server oder dem Hosting-Anbieter Ihres Servers. Und Ihre vorhandenen Tests haben Ihr lokales Netzwerk und Ihren ISP sowie den Ort, an dem die Ressourcen selbst gehostet werden, bereits als mögliche Problemquellen ausgeschlossen. Damit bleiben die Knoten zwischen Ihrem Hosting-Anbieter und dem Hosting-Anbieter der Ressourcen übrig und fallen eindeutig unter „Dinge, über die Sie keine Kontrolle haben“.
Wenn der ServertutWenn Sie während des obigen Tests Probleme haben, können Sie fast sicher sein, dass das Problem entweder bei Ihrem Server oder dem Hosting-Anbieter des Servers liegt, da Sie Ihr lokales Netzwerk/Ihren ISP bereits als Problem ausgeschlossen haben. Das bedeutet, dass Sie die Behebung selbst in der Hand haben. Es bedeutet auch, dass Sie weitere Fehlerbehebungsmaßnahmen durchführen müssen.
2d. Was kommt als Nächstes?
Wenn das Problem nicht bei Ihrem Server, dem Hosting-Anbieter Ihres Servers oder den von Ihnen abgefragten Ressourcen liegt, dann liegt die Ursache selbst nicht in Ihrer Hand. In diesem Fall ist es am besten, den Server zu verlegen (kontaktieren Sie Ihren Hosting-Anbieter und fragen Sie, welche Optionen er Ihnen anbieten kann). DieHoffnungist, dass Sie dadurch die Route mit dem fehlerhaften Knoten nicht mehr verwenden müssen. Das ist allerdings eine ziemliche Tortur und es gibt keine Garantie, dass es funktioniert. Es könnte sogar zu neuen Problemen führen. Deshalb muss dies definitiv ein ernstes Problem sein, bevor Sie einen solchen Schritt unternehmen.
Wenn Sie das Problem jedoch auf Ihren Server oder den Hosting-Anbieter Ihres Servers eingegrenzt haben, können Sie es wahrscheinlich beheben lassen. Wenn Sie einen Managed-Hosting-Vertrag haben, rufen Sie Ihren Hosting-Anbieter an und lassen Sie das Problem beheben. Wenn Sie keinen Managed-Hosting-Vertrag haben, müssen Sie die Konfiguration Ihres Servers als möglichen Übeltäter ausschließen. Und hier steige ich leider aus. Wir stoßen an die Grenzen meiner Expertise.
Wenn es sich um ein zeitweiliges Problem handelt, das von Ihrem Server verursacht wird, hat es im Allgemeinen wahrscheinlich etwas mit der Netzwerkpufferung zu tun oder ist das Ergebnis einer Art Automatisierung. Einige fundierte Vermutungen:
- Haben Sie Schritte unternommen, um Ihren Server gegen böswillige Versuche und Angriffe zu schützen?
- Haben Sie an Ihrem
/etc/sysctl.conf
oder den Dateien in herumgespielt/etc/sysctl.d/
? - Haben Sie eine Art Stateful Packet Inspection- oder Intrusion Detection-Software (auf Iptables/Netfilter basierende Firewalls, Snort usw.) eingerichtet?
Unabhängig davon, ob Sie an dem Punkt sind, an dem Sie den Server selbst beheben, würde ich Ihnen raten, die gesammelten Informationen zu verwenden und eine neue Frage zu stellenServerFault. Die Leute dort haben viel mehr Erfahrung mit Serverproblemen als die Leute hier auf SuperUser und wissen eher, was als Nächstes zu versuchen ist.
3. Zur offensichtlichen Konsistenz der Fehler
Warum erhalten Sie nun immer und immer wieder denselben Fehler? Das ist schwer zu sagen. Angenommen, es passiert wirklich alle 5 Minuten wie am Schnürchen … könnte trotzdem alles Mögliche sein. Diese Geräte haben Uhren und Timer für die verschiedensten Zwecke. Es könnte sein, dass etwas, das eines davon so eingestellt ist, dass es alle fünf Minuten passiert, diesen kleinen Schluckauf verursacht.
Möglicherweise liegt ein Problem mit Ihrem Server vor. Oder es liegt an Ihrem Hosting-Anbieter. Oder es liegt an dem ISP Ihres Hosting-Anbieters. Oder es liegt an Ihrem ISP zu Hause/im Büro. Oder irgendwo dazwischen. Wenn es nicht Ihr Server ist (und das ist wahrscheinlich nicht der Fall, basierend auf dem, was Sie mir gesagt haben), können Sie im Endeffekt nicht viel dagegen tun ... außer sicherzustellen, dass Sie so eingerichtet sind, dass Sie fehlgeschlagene Verbindungsversuche wiederholen können. Alle modernen Webbrowser beispielsweise versuchen es mehrere Male, bevor sie den Abruf einer Ressource von einem Webserver aufgeben.
BEARBEITUNGEN
- Zweiter und dritter Abschnitt als Antwort auf einen Kommentar mit der Bitte um weitere Klarstellung hinzugefügt
- Der zweite Abschnitt wurde umgeschrieben, um Korrekturen zu berücksichtigen.