Das Fehlerprotokoll im Server sieht in etwa so aus:
124.65.133.242 – – [27.10.2014:14:30:51 +0800] „-“ 400 0 „-“ „-“
124.65 . 133.242 – – [27.10.2014:14:31:45 +0800] „-“ 400 0 „-“ „-“
124.65.133.242 – – [27.10.2014:14:31:45 +0800 ] „-“ 400 0 „-“ „-“
124.65.133.242 – – [27/okt/2014:14:31:45 +0800] „-“ 400 0 „-“ „-“
Aussteigen
Nach der Analyse der Nginx-Protokolldatei wurde festgestellt, dass nach einem normalen Besuch mehrere 400 Fehler generiert wurden. Es gab jedes Mal etwa 1-6 aufeinanderfolgende Fehler und 400 Fehler wurden nicht bei jedem Besuch generiert.
Es ist normal, den vorherigen Zugriff zu beobachten, der den 400-Fehler erzeugt hat. Der 200-Statuscode, die normale Datei, die normale Quelle, der normale Benutzeragent ... alles ist harmonisch, also woher kommt der 400-Fehler?
Durch sorgfältige Beobachtung haben wir festgestellt, dass alle User-Agents des vorherigen Besuchs, die 400 Fehler generiert haben, vom Google Chrome-Browser hinterlassen wurden, was bedeutet, dass die 400 Fehler vom Chrome-Browser generiert wurden. Nach der lokalen Paketerfassung wurde jedoch festgestellt, dass Chrome keine ungewöhnlichen Anfragen oder Datenpakete an den Server gesendet hatte.
Bei der Paketerfassungsanalyse wurde festgestellt, dass Chrome beim Zugriff auf den Server mehr als eine Verbindung initiiert hat, normalerweise zwischen 5 und 6. Wenn die angeforderte Ressource nicht so viele Verbindungen benötigt, schließt Chrome die ungenutzten Verbindungen wird als Vorverbindung bezeichnet.
Wenn wir eine Website besuchen, erhalten wir normalerweise als Erstes eine Haupt-HTML-Datei, die auf andere Medienressourcendateien wie CSS, JS, Bilder usw. verweist. Im Allgemeinen sind dies die Ressourcendateien und die Die Haupt-HTML-Datei befindet sich in einer Domäne. Vor dem Herstellen einer Verbindung müssen viele TCP-Verbindungen hergestellt werden, bevor die HTML-Datei abgerufen wird, anstatt auf den Abruf der HTML-Datei zu warten, bevor eine Verbindung zum Server hergestellt wird, um andere Dateien abzurufen Gleichzeitig kann diese Technologie die Darstellung von Webseiten erheblich beschleunigen.
Wenn die Ressource des HTML-Links der Webseite relativ klein ist oder der Client über einen Cache verfügt und zum Herunterladen keine Verbindung herstellen muss, ist wahrscheinlich nur eine der 5-6 vom Chrome-Browser ausgegebenen Verbindungen erforderlich , und die anderen müssen geschlossen sein, daher entsteht ein Problem: Der Server ist verbunden, ohne irgendwelche Anfragen zu senden. In diesem Fall behandelt nginx den Fehler als 400-Fehler, aber da die Verbindung geschlossen wurde, wird die Fehlermeldung nicht an den Client gesendet. Dies führt dazu, dass der Fehler in der Protokolldatei aufgezeichnet wird, in der jedoch nichts zu sehen ist Phänomen der Paketerfassung.
Testen
Es ist sehr einfach, die obigen Analyseergebnisse zu überprüfen. Öffnen Sie die Befehlszeile cmd.exe, geben Sie telnet serverip 80 ein, warten Sie, bis die Verbindung erfolgreich ist, und schließen Sie dann cmd Protokolldatei. Ein 400-Fehler-Datensatz.
Ein Kommentar
Die Vorteile der Vorverbindung sind bereits sehr klar, aber sie hat auch Nachteile. Wenn der Webmaster sie optimiert, eine Cookie-freie Technologie verwendet oder unterschiedliche Server für Webseiten und statische Ressourcen verwendet hat, dann ist das der Fall Webseite Die erforderlichen CSS- und JS-Ressourcen befinden sich nicht in derselben Domäne wie der Haupt-HTML-Server und möglicherweise nicht auf derselben IP-Adresse. Daher ist die Vorverbindung nicht nur nutzlos, sondern belastet auch den Haupt-HTML-Server unnötig.
Andere Gründe
Viele Leute im Internet haben verwandte Artikel geschrieben, weil die Größe des Headers die Größe überschreitet, was zu einer Antwort von 400 führt und darauf hindeutet, dass es sich um eine schlechte Anfrage handelt Tatsächlich gibt es noch eine andere Möglichkeit, nämlich den Port. Das Testtool prüft lediglich, ob der Port aktiv ist. Auch Dinge wie lvs können solche Probleme verursachen, und dann erscheinen viele 400-Fehler in den Protokollen.
Für das oben genannte Problem können Sie sowohl client_header_buffer_size als auch large_client_header_buffers in nginx.conf erhöhen, um dieses Problem zu lindern.
Das obige ist der detaillierte Inhalt vonSo beheben Sie eine große Anzahl von http 400-Fehlern im Nginx-Zugriffsprotokoll des Linux-Servers. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
