GZIP-Komprimierung Tomcat und Prozessdiagramm zur Verbesserung der Web-Leistung

1. Einleitung

Ich habe vor Kurzem an einem Projekt gearbeitet und bin auf ein Problem gestoßen: Die Menge der vom Server an den Client zurückgegebenen JSON-Daten war zu groß (ca. 65 MB) und das Laden und Rendern auf dem Client dauerte mehr als eine Minute (diese Ladezeit hängt natürlich auch von der lokalen Downstream-Bandbreite ab), was zeitaufwändig war, viel Verkehr verbrauchte und die Benutzererfahrung äußerst schlecht machte. Später suchte ich online nach einer Optimierungsmethode und es stellte sich heraus, dass es sich um HTTP-Komprimierung handelte.

HTTP-Komprimierung kann die Geschwindigkeit beim Surfen auf Websites erheblich verbessern. Das Prinzip besteht darin, dass, nachdem der Client die entsprechenden Ressourcen vom Server angefordert hat, die Ressourcendatei vom Server komprimiert und dann an den Client ausgegeben wird. Der Browser des Clients ist für das Dekomprimieren und Surfen verantwortlich. Das heißt: Reduzieren Sie die Antwortzeit, indem Sie die Größe der HTTP-Antwort reduzieren. Im Vergleich zum normalen Browsing-Prozess mit HTML, CSS, Javascript und Text können etwa 40 % des Datenverkehrs eingespart werden. Noch wichtiger ist, dass es dynamisch generierte Webseiten komprimieren kann, einschließlich der von CGI, PHP, JSP, ASP, Servlet, SHTML usw. ausgegebenen Seiten, und dass die Komprimierungseffizienz ebenfalls sehr hoch ist. GZIP selbst ist ein weit verbreiteter Algorithmus zur Komprimierung von Netzwerkdatenströmen. In diesem Artikel geht es um die Konfiguration der GZIP-Komprimierung für Apache Tomcat 8.0.47. Als Browser kommt Mozilla Firefox 35.0.1 zum Einsatz, zum Debuggen wird das integrierte Firebug verwendet. Die folgenden netzwerkbezogenen Screenshots stammen aus der Firebug-Konsole.

2. Einführung in die Gzip-Komprimierung

1. Das HTTP-Protokoll unterstützt den GZIP-Komprimierungsmechanismus, auch als Protokollkomprimierung bekannt. Bei der HTTP-GZIP-Komprimierung handelt es sich um ein Protokoll, das sowohl vom Webserver als auch vom Browser befolgt wird. Dies bedeutet, dass sowohl der Webserver als auch der Browser es einhalten müssen. Derzeit unterstützen gängige Server und Browser die GZIP-Komprimierungstechnologie. Einschließlich Chrome, IE, FireFox, Opera usw.; Server umfassen Tomcat, Apache und IIS usw.

2. GZIP wird hauptsächlich zum Komprimieren statischer Textdateien wie HTML, CSS, JavaScript usw. verwendet. Es unterstützt auch die Komprimierung dynamisch generierter Webseiten, einschließlich der von CGI, PHP, JSP, ASP, Servlet, SHTML usw. ausgegebenen Seiten.

3. Die GZIP-Komprimierungsrate liegt normalerweise zwischen dem 3- und 10-fachen, wodurch die Netzwerkbandbreite des Servers erheblich gespart und die Browsing-Geschwindigkeit des Browsers erheblich verbessert werden kann.

4. GZIP ist ein Datenkomprimierungsformat. Standardmäßig wird nur der Deflate-Algorithmus verwendet, um den Datenteil zu komprimieren. Deflate ist ein Komprimierungsalgorithmus, der eine Erweiterung des Huffman-Codes darstellt.

5. Die Protokollkomprimierung basiert auf dem HTTP-Protokoll. Programmierer müssen keine Komprimierung, Dekomprimierung und Kodierung durchführen. Stattdessen wird der Komprimierungsprozess an den Webserver und der Dekomprimierungsprozess an den Client übergeben. Wenn der Client ein Browser ist, der GZIP-Komprimierung unterstützt, ist am Dekomprimierungsprozess kein Programmierereingriff erforderlich und der Browser dekomprimiert automatisch gemäß bestimmten Regeln. Wenn der Client ein HttpClient ist, muss die GZIP-Dekodierung manuell durchgeführt werden.

6. Komprimierungsprozess: Der Client sendet eine HTTP-Anforderung. Wenn der Anforderungsheader Accept-Encoding:gzip,deflate enthält (aktuelle Browser verwenden dies im Allgemeinen als Standard), bedeutet der Browser, dass der Server eine GZIP-Komprimierung durchführen und dann prüfen muss, ob der Antwortinhaltstyp dem vom Server konfigurierten Komprimierungstyp entspricht. Wenn dies der Fall ist, komprimiert der WEB-Server den Antwortinhalt vor der Übertragung und fügt dem Antwortheader Content-Encoding gzip hinzu. Wenn nicht, wird er nicht komprimiert und direkt zurückgegeben.

7. Dekomprimierungsprozess: (Browser) Der Client empfängt die Antwort. Wenn der Antwortheader Content-Encoding GZIP enthält, dekomprimiert der Browser den Antwortinhalt automatisch mit GZIP und stellt ihn dann auf der Seite dar. Wenn es nicht enthalten ist, wird es direkt auf der Seite gerendert.

8. Nachteile von GZIP. Im Vergleich zu Projekten ohne GZIP erhöht die Verwendung von GZIP den Druck der Serverkomprimierung (CPU-Verbrauch) und der Clientdekomprimierung, sodass die Konfigurationsanforderungen des Servers höher sind. Darüber hinaus nimmt die Komprimierung auch Zeit in Anspruch. Wenn Sie weniger Platz beanspruchen und eine hohe Komprimierungsrate erzielen möchten, müssen Sie mehr Zeit opfern. Im Gegenteil, wenn Zeit kostbarer ist und Geschwindigkeit erforderlich ist, muss die Komprimierungsrate kleiner sein und natürlich wird mehr Platz beansprucht (Komprimierungsrate = Größe des ursprünglichen Inhalts/komprimierte Größe, je größer die Komprimierungsrate, desto kleiner ist das komprimierte Paket nach der Komprimierung). Dies ist der Widerspruch zwischen physischem Raum und Zeit.

3. Konfigurationsmethode in Tomcat

Versionsanforderung: Tomcat 5.0 oder höher. Ändern Sie %TOMCAT_HOME%/conf/server.xml und überarbeiten Sie die Knoten wie folgt:

<Anschlussport="8080"
Protokoll="HTTP/1.1"
VerbindungsTimeout="20000"
UmleitungsPort="8443"
Komprimierung="ein"
KomprimierungMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/javascript,
Anwendung/Javascript, Text/CSS, Text/Plain, Text/JSON"/>

Parameterbeschreibung:

1. compression="on" schaltet die Komprimierung ein. Optionale Werte: „on“ zum Aktivieren, „off“ zum Deaktivieren, „force“ zum Aktivieren in allen Fällen.

2. compressionMinSize="2048" Nur Dateien, die größer als 2 KB sind, werden komprimiert. Wird verwendet, um die minimale komprimierte Datengröße in B anzugeben, mit einem Standardwert von 2048 B. Achten Sie auf die Größe dieses Wertes. Wenn er nicht richtig konfiguriert ist, führt dies dazu, dass kleine Dateien nach der Komprimierung größer werden, was nicht den erwarteten Effekt erzielt.

3. noCompressionUserAgents="gozilla, traviata", für diese beiden Browser wird keine Komprimierung durchgeführt (ich weiß nicht, um welche beiden Browser es sich handelt, und kann sie auf Baidu nicht finden). Sein Wert ist ein regulärer Ausdruck, und die passende UA wird nicht komprimiert. Der Standardwert ist leer.

4. compressibleMimeType="text/html,text/xml,application/javascript,text/css,text/plain,text/json" ist eine Liste von MIME-Typen, die komprimiert werden. Mehrere Typen werden durch Kommas getrennt, was bedeutet, dass die Komprimierung von Dateiformaten wie HTML, XML, JS, CSS und JSON unterstützt wird (plain bedeutet kein Format, aber ich bin mir nicht sicher, was es ist). compressableMimeType ist sehr wichtig. Es wird verwendet, um Tomcat mitzuteilen, welche Datei komprimiert werden soll. Wenn der Typ falsch angegeben ist, wird er definitiv nicht komprimiert. Woher wissen Sie also, welche Dateitypen komprimiert werden sollen? Dies kann mit der folgenden Methode herausgefunden werden.

4. Prüfen Sie, ob die Konfiguration erfolgreich ist

Starten Sie Tomcat nach der Änderung neu und rufen Sie schließlich die Testwebsite auf: http://seo.chinaz.com/?host=iitshare.com, um den Effekt zu überprüfen.

5. Häufige Fehler (keine Auswirkung nach der Konfiguration)

Sie können das Problem beheben, indem Sie die folgenden Schritte ausführen:

1. Die Konfigurationsparameter in Tomcat sind an der falschen Stelle geschrieben. Beachten Sie, dass die Konfigurationsparameter in der folgenden Abbildung in Bereich A und nicht in Bereich B geschrieben werden sollten, also in den Connector mit Protokoll="HTTP/1.1".

2. Die Antwortdaten sind nicht vom Typ, der durch den Parameter compressibleMimeType konfiguriert wurde. Ich bin auf diese Falle gestoßen. Unser Projekt verwendete JSON für die Front-End- und Back-End-Übertragung. Ich dachte zunächst, es sei „text/json“, aber dann öffnete ich die Firebug-Konsole und stellte fest, dass der Wert von Content-Type „application/json“ war. Siehe Abbildung 3.

3. Die Größe der Antwortdaten ist kleiner als der Konfigurationswert von compressionMinSize.

Anhang: Optimierungsergebnisse

Es ist ersichtlich, dass das Kompressionsverhältnis = 65,6 / 8,4 = 7,810, das Zeitverhältnis = 96 / 16,2 = 5,926 beträgt, was bereits ideal ist.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.