Aus Linux-Magazin 11/2017

Brotli komprimiert Webseiten besser

© seen0001, 123RF

Mit Brotli hat Google eine Software entwickelt, die eine echte Alternative zu Gzip darstellt, indem sie Webseiten stärker komprimiert und dem Serverbetreiber auf diese Weise Bandbreite spart.

Seit fast 20 Jahren setzen Webserver auf die Gzip-Kompression und verdichten damit die von ihnen angebotenen HTML-, CSS- und sonstige Textdateien, die Browser dann empfangen und wieder entpacken. Da die Netzwerkverbindung ein Nadelöhr ist, beschleunigen diese Methoden die Datenübertragung.

Handelt es sich hingegen um dynamische Inhalte, erfolgt die Gzip-Kompression auf dem Server on the Fly. Der Webserver liest in diesem Fall die Datei aus dem Dateisystem, pipt sie durch Gzip und liefert das Ergebnis anschließend an den Browser. Oft ruft er vor dem Gzip-Schritt noch ein PHP-Modul auf.

Bei statischen Files (zum Beispiel CSS-Dateien) erledigt der Server die Kompression mitunter auch einmalig im Vorfeld und legt sie dann als ».gz«-Dateien im Dateisystem ab. Das spart CPU-Leistung auf dem Server. Zudem kann in diesem Fall auch Googles Komprimierungssoftware Zopfli [1] zum Einsatz kommen. Die arbeitet zwar sehr viel langsamer und zugleich CPU-intensiver als Gzip, liefert aber bessere und dennoch mit Gzip kompatible Ergebnisse.

Im Laufe der letzten 20 Jahre tauchten natürlich immer mal wieder bessere Komprimierungsmethoden als Gzip auf. Die haben allerdings niemals den Einzug in die Webbrowser geschafft, da sie alle schlicht zu viel Zeit für die On-the-Fly-Komprimierung benötigten. Denn wenn diese länger dauert als das Übertragen der Originaldateien, ist am Ende niemandem geholfen.

Stark geknetet

Erst 2015 lieferte Google mit der Open-Source-Software Brotli [2] eine Lösung für dieses Dilemma. Sie komprimiert Dateien im gleichen Zeitraum wie Gzip, aber stärker – wie es auch das folgende Beispiel an einem HTML-Dokument demonstriert (Listing 1).

Listing 1

hello-world.html

01   <html>
02       <head>
03           <title>Brotli Test</title>
04       </head>
05       <body>
06           <p>Hello World!</p>
07       </body>
08   </html>

Die Datei belegt auf der Festplatte 124 Bytes. Mit Gzip komprimiert sind es 113 Bytes, was eine Platzersparnis von 9 Prozent bedeutet. Mit Brotli komprimiert ist die Datei nur noch 77 Bytes groß, also 38 Prozent kleiner:

-rw-r--r--  1 sw  sw  124  8 Sep 16:52  hello-world.html
-rw-r--r--  1 sw  sw   77  8 Sep 16:53  hello-world.html.br
-rw-r--r--  1 sw  sw  113  8 Sep 16:53  hello-world.html.gz

Der Hauptgrund für das gute Abschneiden von Brotli bei HTML-Dateien liegt vor allem darin, dass im Programm ein 120 KByte großes Wörterbuch fest hinterlegt ist. Es kennt die auf Webseiten am häufigsten benutzten Zeichenketten, beispielsweise HTML-Tags. Brotli verweist dann direkt auf diesen Eintrag und spart so sehr viel Speicherplatz. Im Schnitt erzeugt Brotli 20 Prozent kleinere Dateien als Gzip. Das dürfte allein schon jeden Serverbetreiber freuen, der für Netzwerktraffic zahlen müssen.

Der Schlüssel zum Erfolg liegt aber in der Browserunterstützung. Hier hat Google dank des hauseigenen Browsers Chrome einen Heimvorteil. Nachdem die Entwickler Chrome mit Brotli-Support ausgerüstet haben, zogen andere Browserhersteller nach. Heute unterstützen alle großen Browser Brotli [3].

Brotli Server-seitig

Bei den Servern sieht es weniger rosig aus. Von den mit den großen Linux-Distributionen ausgelieferten Webservern in den Stable-Zweigen unterstützt kein einziger Brotli. Wer die Komprimierungssoftware unter Linux anbieten will, der muss zurzeit patchen und neu kompilieren. Das aber führt zu einem Betriebssystem, das sich nur schwer aktualisieren lässt. Spätestens die nächste Major-Release bietet Brotli voraussichtlich offiziell mit an. Der Admin will dann vermutlich auf das offizielle Paket umsteigen.

Der Artikel zeigt, wie der Admin auf einem Debian Stable 9.1 (Stretch, [4]) den dort verfügbaren stabilen Nginx-Webserver [5] mit Brotli kombiniert. Dabei geht er von einem frisch installierten Server aus, auf dem der Admin mit Rootrechten agiert. Als Stand-alone-Komprimierungssoftware bietet Debian 9.1 Brotli bereits an. Das Paket installiert der Admin als Erstes, zusammen mit Git:

apt-get install brotli git

Für das Nginx-Modul benötigt er dann aber noch die Entwicklungs-Bibliotheken. Die stecken aktuell leider nur im Testing-Zweig, bringen aber zum Glück nicht viele Abhängigkeiten mit. Deshalb muss er die folgende Zeile in der Datei »/etc/apt/sources.list« ergänzen

deb http://deb.debian.org/debian experimental main

und kann das benötigte Paket im Anschluss installieren, wobei er über den Schalter »-t« Apt-Pinning [6] verwendet:

apt-get update
apt-get install libbrotli-dev/experimental

Für das Nginx-Modul gibt es hingegen kein fertiges Debian-Paket. Das zieht der Admin daher aus Googles Repository und speichern es unter »/opt/ngx_brotli« (Listing 2).

Listing 2

Nginx-Modul von Brotli installieren

01 cd /opt
02 git clone https://github.com/google/ngx_brotli
03 cd /opt/ngx_brotli
04 git submodule update --init

Listing 3

Nginx-Paket für Debian

01 cd /usr/src
02 mkdir nginx
03 cd nginx
04 apt-get source nginx
05 cd nginx-1.10.3

Dann besorgt er die Quellen für das offizielle Debian-Paket von Nginx (Listing 3). In den Quellen steckt die Datei »debian/rules«, welche Debian-spezifische Einstellungen definiert. In ihr sucht der Paketbauer nach dem Eintrag für »extras« (das ist die Nginx-Variante mit den meisten Modulen) und ergänzt dann die folgende Zeile:

--add-module=/opt/ngx_brotli

Sind alle nötigen Dateien am Platz und konfiguriert, baut er die neuen Debian-Pakete:

dpkg-buildpackage -b

Die landen dann im Verzeichnis »/usr/src/nginx« und lassen sich per Dpkg installieren:

dpkg -i nginx-common_*.deb libnginx-mod*_.deb nginx-extras*_.deb

Damit das System die gerade installierten Pakete nicht unbeabsichtigt aktualisiert, kann der Admin sie mit Hilfe von Apt auf »hold« setzen:

apt-mark hold $(dpkg --get-selections |  grep nginx | sed "s/\t.*//" | xargs)

Fertig ist das stabile Nginx mit zusätzlichem Brotli-Modul.

Ohne HTTPS geht nix

Vor dem Abruf einer Seite erklärt der Webbrowser dem Webserver per HTTP-»GET«-Request, welche Komprimierung er verarbeiten kann (»Accept-Encoding«). Um sicherzugehen, dass sich alte HTTP-Proxys auf dem Weg vom Server zum Browser nicht an der Brotli-Kompression verschlucken, fragen Browser nur beim Einsatz von TLS-Verbindungen (SSL) nach der Brotli-Kompression.

Der kostenlose Zertifizierungsdienst Let’s Encrypt [7] macht das Konfigurieren von SSL auf dem Webserver inzwischen glücklicherweise sehr einfach [8]. Der Admin installiert den Let’s-Encrypt-Client unter Debian mit »apt-get«:

apt-get install letsencrypt

Das Beispiel spielt das an der URL »www.linux-magazin.de« durch und erstellt dafür ein Verzeichnis:

mkdir -p /var/www/www.linux-magazin.de/.well-known

Um Let’s Encrypt zu beweisen, dass der Admin die Kontrolle über diese Domain hat, muss er erst einmal einen einfachen HTTP-Server aufsetzen. Die Nginx-Konfiguration dafür speichert er in der Datei »/etc/nginx/sites-available/www.linux-magazin.de« (Listing 4).

Listing 4

/etc/nginx/sites-available/www.linux-magazin.de

01 server {
02     listen 80;
03     server_name www.linux-magazin.de;
04
05     root /var/www/www.linux-magazin.de;
06     index index.html index.htm;
07
08     # Let's Encrypt Challenge
09     #
10     location ~ /.well-known {
11       allow all;
12     }
13
14     location / {
15       try_files $uri $uri/ =404;
16     }
17   }

Der Webseitenbetreiber aktiviert diese Konfiguration mit einem Link in das »/etc/nginx/sites-enabled/«-Verzeichnis und indem er Nginx neu startet:

ln -s /etc/nginx/sites-available/www.linux-magazin.de /etc/nginx/sites-enabled/www.linux-magazin.deservice nginx restart

Dann ruft er das Let’s-Encrypt-Programm »certbot« mit der gewünschte URL auf:

certbot certonly --webroot -w /var/www/www.linux-magazin.de/.well-known -d www.linux-magazin.de

Die Software legt die SSL-Zertifikate in der Verzeichnisstruktur unter »/etc/letsencrypt« ab. Jetzt fasst der Admin noch einmal die Nginx-Konfiguration des Webservers an (Listing 5). Hier konfiguriert er den HTTPS-Zugriff und aktiviert dabei auch gleich HTTP/2, um die optimale Webperformance zu erhalten. Zusätzlich richtet er eine automatische Umleitung von allen HTTP-Anfragen auf HTTPS ein. Danach startet er Nginx erneut:

service nginx restart

Anschließend legt der Admin im Verzeichnis »/var/www/www.linux-magazin.de« eine HTML-Datei ab und ruft sie mit Brotli-Kompression auf. Für die On-the-Fly-Kompression lässt sich der »brotli_comp_level« auf Werte von eins bis elf einstellen, was die Kompressionsleistung von Brotli verändert.

Listing 5

/etc/nginx/sites-available/www.linux-magazin.de

01 # Umleitung von HTTP-Anfragen auf HTTPS
02 #
03   server {
04   listen 80;
05   server_name www.linux-magazin.de;
06
07   root /var/www/www.linux-magazin.de;
08   index index.html index.htm;
09
10   # Let's Encrypt Challenge
11     #
12   location ~ /.well-known {
13    allow all;
14   }
15
16   location / {
17    rewrite ^/(.*)$ https://www.linux-magazin.de/$1 permanent;
18    rewrite ^/$ https://www.linux-magazin.de/ permanent;
19   }
20   }
21
22   # HTTPS-Konfiguration
23   #
24   server {
25   listen 443 ssl http2;
26   server_name www.linux-magazin.de;
27
28     # Letsencrypt-SSL-Zertifikate
29   ssl_certificate /etc/letsencrypt/live/www.linux-magazin.de/fullchain.pem;
30   ssl_certificate_key /etc/letsencrypt/live/www.linux-magazin.de/privkey.pem;
31
32   # Connection-Credentials cachen
33   ssl_session_cache shared:SSL:20m;
34   ssl_session_timeout 180m;
35
36   root /var/www/www.linux-magazin.de/current;
37   index index.html index.htm;
38
39     # Brotli-Settings
40     #
41     brotli on;
42     brotli_comp_level 5;
43     brotli_static on;
44     brotli_types text/html text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;
45
46   location / {
47    try_files $uri $uri/ =404;
48   }
49   }

Wie bei Gzip erzielen auch bei Brotli höhere Werte eine bessere Komprimierung, benötigen dafür aber mehr Zeit und CPU-Leistung. Werte zwischen vier und sechs gelten im Allgemeinen als guter Kompromiss. Wer für optimale Performance statische Dateien vorab komprimiert und mit der Datei-Endung ».br« ablegt, fährt auch mit einem Wert von elf gut.

Mal schauen

Hat der Admin schließlich alles eingerichtet, kann er die Resultate auf der Kommandozeile überprüfen, wobei ihm »curl« zur Seite steht. Damit testet er, ob der Webserver wunschgemäß auf die Anfrage »Accept-Encoding: br« mit einem »Content-Encoding: br« reagiert. Abbildung 1 zeigt einen erfolgreichen Test mit der Webseite des Autors.

Abbildung 1: Die Webseite des Autors unterst&uuml;tzt Brotli, wie eine Serveranfrage mit Curl verr&auml;t.

Abbildung 1: Die Webseite des Autors unterstützt Brotli, wie eine Serveranfrage mit Curl verrät.

Der Autor

Stefan Wintermeyer ist Consultant, Trainer und Buchautor für die Themen Ruby on Rails, Phoenix und Webperformance: https://www.wintermeyer-consulting.de.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 3 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben