Martin Brinkmann 03.02.2022 Firefox | 0
Am 13. Januar 2022 begannen Firefox-Benutzer aus der ganzen Welt, Verbindungsprobleme zu melden. Der Browser konnte keine Verbindung zu einer Website herstellen und Benutzer meldeten Hänger und Abstürze.
< /p>
Mozilla veröffentlichte am 2. Februar 2022 eine detaillierte technische Erklärung des Vorfalls auf der Mozilla Hacks-Website des Unternehmens.
Die Organisation erhielt am 13. Januar 2022 Berichte über das Hängenbleiben von Firefox bei Verbindungsversuchen. Damals sah es dieses Crash-Repo rts stiegen an, hatten aber nicht viele Informationen darüber, was das Problem verursachte.
ANZEIGE
Mozilla-Ingenieure entdeckten, dass eine Netzwerkanfrage die Hänger für Firefox-Benutzer verursachte. Ingenieure haben sich die letzten Änderungen oder Aktualisierungen angesehen, aber keine gefunden, die das Problem verursachen könnten, das Benutzer erlebt haben.
Mozilla vermutete, dass das Problem durch eine kürzlich erfolgte “unsichtbare” Konfigurationsänderung durch einen der Cloud-Anbieter, die es für den Lastenausgleich verwendet. Die Organisation nutzt die Infrastruktur mehrerer Anbieter für Dienste wie Crash-Reporting, Telemetrie, Aktualisierung oder Zertifikatsverwaltung.
Die Einstellungen wurden bei der Inspektion nicht geändert, aber die Ingenieure stellten fest, dass der Telemetriedienst HTTP/3-Verbindungen bediente, was zuvor nicht der Fall war. HTTP/3 wurde von Mozilla deaktiviert und Benutzer konnten Firefox endlich wieder verwenden, um sich mit Diensten zu verbinden. Die HTTP/3-Einstellung beim Cloud-Anbieter wurde mit dem automatischen Wert konfiguriert.
Mozilla untersuchte das Problem genauer, nachdem das dringendste Problem behoben worden war. Alle HTTP/3-Verbindungen laufen über den Netzwerk-Stack Necko, aber Rust-Komponenten verwenden eine Bibliothek namens viaduct, um Necko aufzurufen.
WERBUNG
Necko prüft, ob ein Header vorhanden ist, und falls nicht, fügt er ihn hinzu. HTTP/3 verlässt sich auf den Header, um die Anforderungsgröße zu bestimmen. Bei Necko-Checks wird zwischen Groß- und Kleinschreibung unterschieden. Nun kam es vor, dass die Anfragen, die den Viadukt passierten, von der Bibliothek automatisch in Kleinbuchstaben gesetzt wurden; das bedeutete, dass jede Anfrage über Viaduct, die einen Header mit Inhaltslänge hinzufügte, Necko passierte, aber Probleme mit dem HTTP/3-Code hatte.
Die einzige Rust-Komponente, die den Netzwerkstack verwendet und einen Content-Length-Header hinzufügt, ist die Telemetry-Komponente des Firefox-Webbrowsers. Mozilla stellt fest, dass dies der Grund war, warum das Deaktivieren der Telemetrie in Firefox das Problem auf der Benutzerseite gelöst hat. Das Deaktivieren von HTTP/3 hat es ebenfalls behoben.
Das Problem verursachte eine Endlosschleife, die die gesamte weitere Netzwerkkommunikation blockierte, da laut Mozilla “alle Netzwerkanfragen durch einen Socket-Thread gehen”.
WERBUNG
Mozilla gibt an, aus dem Problem mehrere Lehren gezogen zu haben. Es untersucht alle Load Balancer und überprüft ihre Konfigurationen, damit solche Probleme in Zukunft vermieden werden können. Der Einsatz von HTTP/3 bei Google, dem fraglichen Cloud-Anbieter, war unangekündigt. Schließlich plant Mozilla, in Zukunft weitere Systemtests mit „verschiedenen HTTP-Versionen“ durchzuführen.
Schlusswort
Mozilla hat schnell auf die Notsituation reagiert und diese behoben. Möglicherweise hat es dem Ruf geschadet, und einige Benutzer sind dabei möglicherweise zu einem anderen Browser gewechselt. Mozilla sollte sich fragen, ob es eine gute Idee ist, auf eine Cloud-Infrastruktur zu setzen, die von seinem größten Konkurrenten im Browserbereich betrieben wird. Einige Firefox-Benutzer schlagen möglicherweise auch vor, dass die Organisation die Verarbeitung von Anfragen durch den Browser überprüft, um sicherzustellen, dass unnötige Anfragen, z. B. das Melden von Telemetrie- oder Absturzmeldungen, wird niemals Verbindungen blockieren, die der Benutzer in Zukunft herzustellen versucht.
Jetzt Sie: Wie beurteilen Sie den Vorfall?
ANZEIGE