![\"Vier](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/http-kompression-de.png\")
Zwei Header regeln es<\/h2>\n
Der Browser macht den Anfang mit einer Liste. Seine Anfrage tr\u00e4gt eine Zeile namens Der Server sucht sich eines davon aus, packt die Antwort und nennt seine Wahl in einer Zeile namens Eine weitere Zeile z\u00e4hlt \u00fcberall dort, wo ein Zwischenspeicher im Weg sitzt. Nichts an diesem Austausch ist eine feste Einstellung auf einer der beiden Seiten. Er wird f\u00fcr jede Datei neu gef\u00fchrt, jedes Mal.<\/p>\n Zwanzig gro\u00dfe Seiten wurden am 2. September 2026 je einmal gefragt, jede Anfrage mit allen vier Verfahren im Angebot. Alle zwanzig antworteten mit Status 200.<\/p>\n Dreizehn antworteten mit Sechs antworteten mit Eine antwortete mit gar nichts.<\/p>\n Und Die gemessenen Verh\u00e4ltnisse reichen von 2,88 bis 12,63.<\/p>\n Am dichtesten packte cloudflare.com: 1.315.964 Bytes Auszeichnung reisten als 104.114. Am lockersten nginx.org mit 2,88, und das ist kein Versagen – die Seite ist kurz und schlicht, und eine kleine Datei tr\u00e4gt schlicht weniger Wiederholung, aus der sich sch\u00f6pfen lie\u00dfe.<\/p>\n Gr\u00f6\u00dfe hilft also. Gro\u00dfe, von einem Baukasten zusammengesetzte Seiten lassen sich weit besser packen als kleine handgeschriebene, denn Kompression lebt von Wiederholung, und eine erzeugte Seite ist voll davon.<\/p>\n Brotli gewinnt auch nicht von allein. tagesschau.de erreichte damit 11,99, w\u00e4hrend zeit.de mit demselben Verfahren auf 3,38 kam. Was gepackt wird, z\u00e4hlt mehr als womit.<\/p>\n microsoft.com lieferte die einzige Antwort ohne Die Antwort nennt ihre Herkunft deutlich genug – Das geh\u00f6rt genau gesagt, denn eine Messung ist eine Messung: Was hier, zu dieser Stunde, \u00fcber diesen Weg ankam, war unkomprimiert. Ein anderer Knoten oder ein anderer Weg antwortet vielleicht anders. Die Antwort war trotzdem echt, und 201 KB sind \u00fcber die Leitung gegangen.<\/p>\n Der naheliegende Weg zu einem Verh\u00e4ltnis ist, zweimal anzufragen: einmal mit Diese Methode lieferte hier ein scheinbar eindeutiges, aber falsches Ergebnis. python.org lieferte beide Male 11.672 Bytes, also ein Verh\u00e4ltnis von genau 1,00. Das erweckt den Eindruck, die Seite komprimiere \u00fcberhaupt nicht.<\/p>\n Der Eindruck t\u00e4uscht. Der Server \u00fcberging die Bitte um keine Kompression und schickte trotzdem gzip, also war beide Male die gepackte Gr\u00f6\u00dfe gemeint. Richtig gemessen packt python.org 52.820 Bytes auf 11.672 herunter – ein Verh\u00e4ltnis von 4,52.<\/p>\n Der Weg, der sich nicht t\u00e4uschen l\u00e4sst, braucht nur eine Anfrage: die Bytes z\u00e4hlen, die auf der Leitung ankommen, und sie mit der Datei nach dem Entpacken vergleichen. Beide Zahlen stammen aus derselben Antwort, also bekommt kein Server die Gelegenheit, eine zweite Frage anders zu beantworten.<\/p>\n Kaum. JPEG, PNG, WebP und WOFF2 sind bereits in sich komprimiert, und gzip oder Brotli finden darin kaum noch Wiederholung, aus der sich sch\u00f6pfen lie\u00dfe; manchmal wird die Datei sogar ein wenig gr\u00f6\u00dfer. Server beschr\u00e4nken die Kompression deshalb \u00fcblicherweise auf Textformate wie HTML, CSS, JavaScript, JSON und SVG.<\/p>\n Das h\u00e4ngt an der Stufe. Brotli kennt Qualit\u00e4tsstufen von 0 bis 11, und die obersten packen deutlich langsamer als gzip. F\u00fcr Antworten, die bei jeder Anfrage frisch entstehen, etwa HTML aus WordPress, sind deshalb mittlere Stufen \u00fcblich, bei denen der Zeitbedarf in der Gr\u00f6\u00dfenordnung von gzip liegt und das Ergebnis trotzdem dichter ausf\u00e4llt.<\/p>\n Bei statischen Dateien f\u00e4llt die Rechnung anders aus. CSS und JavaScript lassen sich einmal beim Ausrollen mit der h\u00f6chsten Stufe vorpacken und als fertige Datei neben das Original legen; der Server reicht dann nur noch die passende Fassung aus. Die langsame Stufe kostet so einmal Zeit statt bei jedem Abruf. Genau auf den umgekehrten Fall, das Packen bei jeder Anfrage, zielt das Tempo-Argument von zstd.<\/p>\n In einem eng umrissenen Fall. Der Angriff BREACH nutzt, dass eine komprimierte Antwort k\u00fcrzer wird, wenn ein vom Angreifer eingeschleuster Text mit einem Geheimnis in derselben Antwort \u00fcbereinstimmt. N\u00f6tig sind drei Dinge zugleich: ein Geheimnis im Antworttext, etwa ein CSRF-Token, eine Eingabe des Angreifers, die in derselben Antwort wieder erscheint, und die M\u00f6glichkeit, sehr viele Anfragen auszul\u00f6sen und die L\u00e4nge der verschl\u00fcsselten Antworten zu beobachten.<\/p>\n Die \u00fcbliche Abwehr l\u00e4sst die Kompression eingeschaltet und nimmt stattdessen eine der Bedingungen weg: Tokens, die bei jeder Auslieferung anders maskiert werden, oder keine ungefilterte Wiedergabe von Eingaben auf Seiten mit Geheimnissen. Die Kompression auf TLS-Ebene, gegen die sich der \u00e4ltere Angriff CRIME richtete, gibt es in TLS 1.3 nicht mehr; sie hat mit Content-Encoding nichts zu tun.<\/p>\n Am einfachsten mit curl ohne automatisches Entpacken: Die Anfrage bietet nur gzip an, und die Antwort landet genau so in einer Datei, wie sie \u00fcber die Leitung kam.<\/p>\n Die ausgegebenen Header zeigen, ob der Server tats\u00e4chlich Content-Encoding: gzip gesetzt hat. Danach liefert Fehlt die Zeile Content-Encoding, ist die Datei gar nicht gepackt, und gzip bricht mit einer Fehlermeldung ab. Auch das ist ein Befund, der Fall von microsoft.com. F\u00fcr Brotli gilt dasselbe mit br im Angebot und dem Programm brotli zum Entpacken, sofern es installiert ist.<\/p>\n<\/div>\n Jede Anfrage dieser Messung bot vier Wege an, die Antwort zu komprimieren. Zwanzig Startseiten haben geantwortet und dabei zwei der vier genutzt – w\u00e4hrend das neueste Verfahren kein einziges Mal gew\u00e4hlt wurde.<\/p>\n","protected":false},"author":1,"featured_media":16131,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[156],"tags":[92340,92235,92292],"class_list":["post-13562","post","type-post","status-publish","format-standard","hentry","category-tutorials-de-web-entwicklung","tag-server-administration-de","tag-tutorial-de","tag-web-performance-de"],"yoast_head":"\nAccept-Encoding<\/code>, und darin steht alles, was der Browser entpacken kann – heute meist gzip, deflate, br, zstd<\/code>.<\/p>\nContent-Encoding<\/code>. W\u00e4hlt er nichts, fehlt diese Zeile schlicht, und der Inhalt reist genau so, wie er auf der Platte liegt.<\/p>\nVary: Accept-Encoding<\/code> sagt diesem Speicher, dass die Antwort von der Frage abh\u00e4ngt – damit eine gepackte Kopie nie an ein Programm weitergereicht wird, das sie nicht entpacken kann.<\/p>\nDie drei Verfahren<\/h2>\n
gzip<\/code> ist das \u00e4lteste und das sicherste. Es steckt seit Jahrzehnten in jedem Browser und jedem Kommandozeilenwerkzeug, und nirgends verweigert es jemand.<\/p>\nbr<\/code>, kurz f\u00fcr Brotli, ist j\u00fcnger und packt Text im Allgemeinen dichter als gzip, bei vergleichbarer Lesegeschwindigkeit. Browser bieten es nur \u00fcber HTTPS an.<\/p>\nzstd<\/code> ist noch j\u00fcnger. Sein Argument ist Tempo statt Dichte: Es packt und entpackt schneller bei \u00e4hnlichem Verh\u00e4ltnis, was vor allem dort z\u00e4hlt, wo f\u00fcr jede einzelne Anfrage frisch gepackt wird.<\/p>\ndeflate<\/code> steht meist aus Gewohnheit mit in der Liste. Es ist derselbe Algorithmus wie gzip in einer anderen Verpackung und wird weit h\u00e4ufiger angeboten als je genutzt.<\/p>\nWas zwanzig Startseiten tats\u00e4chlich senden<\/h2>\n
gzip<\/code>: Wikipedia, GitHub, die BBC, die New York Times, Apple, Spiegel, Heise, python.org, debian.org, kernel.org, gnu.org, nginx.org und postgresql.org.<\/p>\nbr<\/code>: cloudflare.com, mozilla.org, w3.org, zeit.de, tagesschau.de und php.net.<\/p>\nzstd<\/code>, in allen zwanzig Anfragen angeboten, wurde von keiner gew\u00e4hlt. Warum, ist von au\u00dfen nicht zu sehen. Zu sehen ist, dass gzip nach drei Jahrzehnten weiterhin die gew\u00f6hnliche Antwort bleibt.<\/p>\n![\"Ein](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/illustrationen\/illu-http-kompression.webp\")
\n<\/figure>\nWie viel es wirklich spart<\/h2>\n
Die eine, die nichts sendet<\/h2>\n
Content-Encoding<\/code>-Zeile: 201.253 Bytes HTML, genau wie gespeichert.<\/p>\nserver: AkamaiNetStorage<\/code>, ein nacktes content-length<\/code>, kein vary<\/code>. Kompression h\u00e4tte davon rund neun Zehntel entfernt.<\/p>\nDer Messfehler, der ein Ergebnis erfindet<\/h2>\n
Accept-Encoding: identity<\/code> und einmal mit allen Verfahren im Angebot. Dann teilt man die Gr\u00f6\u00dfe der ersten Antwort durch die der zweiten.<\/p>\nFragen und Antworten<\/h2>\n
Lohnt sich Kompression auch f\u00fcr Bilder und Schriftdateien?<\/h3>\n
Kostet Brotli auf dem Server mehr Rechenzeit als gzip?<\/h3>\n
Ist Kompression \u00fcber HTTPS ein Sicherheitsrisiko?<\/h3>\n
Wie sieht die Messung mit nur einer Anfrage auf der Kommandozeile aus?<\/h3>\n
curl -s -D - -H \"Accept-Encoding: gzip\" -o seite.gz https:\/\/example.com\/<\/code><\/p>\nwc -c < seite.gz<\/code> die Gr\u00f6\u00dfe des gepackten Inhalts, wie er \u00fcbertragen wurde, und gzip -dc seite.gz | wc -c<\/code> die Gr\u00f6\u00dfe nach dem Entpacken; das Verh\u00e4ltnis beider Zahlen ist der gesuchte Wert. Beide stammen aus derselben Antwort, und genau darauf kommt es an.<\/p>\nQuellen<\/h2>\n
\n