So zwingst du den Server zu komprimierten Antworten: Schritt-für-Schritt-Anleitung zum Traffic-Sparen

Ein einziger Header in einer HTTP-Anfrage kann die heruntergeladene Datenmenge um ein Vielfaches reduzieren. Die Rede ist von der Aushandlung der Komprimierung zwischen Client und Server. Wenn du mit einem Proxy arbeitest und für jedes Gigabyte Traffic zahlst, wirkt sich dieses Thema direkt auf deine Rechnung aus. In diesem Leitfaden schauen wir uns an, wie du den Server dazu bringst, komprimierte Antworten zu liefern, wie du die echte Ersparnis bei deiner Aufgabe misst und welche Stolperfallen auf dich warten.

Einleitung: Ein einziger Header kann den Traffic um ein Vielfaches reduzieren

HTTP-Komprimierung funktioniert erstaunlich einfach. Der Client teilt dem Server mit, welche Komprimierungsalgorithmen er versteht. Der Server wählt einen passenden aus, komprimiert den Antwortkörper und sendet ihn. Der Client entpackt die Daten auf seiner Seite. Das Ergebnis: Über das Netzwerk wird nicht das ursprüngliche HTML oder JSON übertragen, sondern eine komprimierte Version, die oft drei bis fünf Mal weniger wiegt.

Was du am Ende bekommst. Nach dem Lesen dieses Leitfadens wirst du in der Lage sein, Komprimierung auf Client-Seite zu aktivieren, zu überprüfen, ob der Server wirklich komprimierte Antworten liefert, die Traffic-Ersparnis in Bytes vorher und nachher zu messen und Situationen zu diagnostizieren, in denen die Komprimierung aus irgendeinem Grund nicht funktioniert. Das ist alles entscheidend, wenn du Traffic über den Proxeon-Proxy schickst und für Gigabytes zahlst.

Für wen ist dieser Leitfaden. Das Material richtet sich an Entwickler, Web-Scraper-Spezialisten, Automatisierungsingenieure und alle, die HTTP-Clients über Proxys schreiben. Mittleres Niveau. Wir werden nicht besprechen, woraus sich der gesamte Traffic-Verbrauch zusammensetzt. Dafür gibt es einen separaten Artikel. Hier konzentrieren wir uns streng auf die Komprimierung.

Was du vorher wissen solltest. Grundverständnis davon, was eine HTTP-Anfrage und -Antwort sind, was Header sind und wie man eine Befehlszeile im Terminal ausführt. Wenn du schon einmal eine Anfrage mit curl gemacht oder ein Skript in Python oder Node.js geschrieben hast, wirst du es ohne Probleme schaffen.

Wie viel Zeit du benötigst. Das Lesen und Wiederholen aller Beispiele dauert etwa sechzig Minuten. Erste praktische Ergebnisse siehst du bereits nach zehn Minuten, wenn du die Größe komprimierter und unkomprimierter Antworten mit eigenen Augen vergleichst.

Vorbereitung

Bevor du loslegst, stelle sicher, dass du alles Notwendige hast. Das spart Zeit und vermeidet Fehler auf halbem Weg.

Notwendige Werkzeuge

• curl Version 7.72 oder neuer. In den Builds von 2026 werden brotli und zstd auf den meisten Systemen von Haus aus unterstützt.
• Python Version 3.10 oder neuer mit installierter requests-Bibliothek und für brotli zusätzlich das Paket brotli oder brotlicffi.
• Node.js Version 18 oder neuer. Das Modul zlib ist integriert und kann gzip, deflate, brotli.
• Zugriff auf den Proxeon-Proxy, wenn du die Ersparnis genau unter den Bedingungen messen möchtest, unter denen du täglich arbeitest.
• Einen beliebigen Texteditor zum Schreiben von Skripten.

Systemanforderungen

Geeignet ist jedes moderne System: Windows, macOS oder Linux. Alle Beispiele sind plattformübergreifend. Zwei Gigabyte Arbeitsspeicher reichen aus. Es gibt keine besonderen Anforderungen an den Prozessor, obwohl das Komprimieren großer Datenmengen mit brotli auf maximaler Stufe einen Kern deutlich belasten kann.

Was installieren und prüfen

1. Öffne ein Terminal und führe den Befehl zur Versionsprüfung von curl aus:

   curl --version

2. Schau dir die erste Zeile der Ausgabe an. Dort steht die Version. Stelle sicher, dass in der Liste der Funktionen brotli und wenn möglich zstd enthalten sind.
3. Überprüfe Python mit dem Befehl

   python --version

   und installiere die Abhängigkeiten:

   pip install requests brotli

4. Überprüfe Node.js mit dem Befehl

   node --version

Tipp: Wenn curl in deinem System ohne brotli gebaut wurde, installiere es über den offiziellen Paketmanager deines Betriebssystems. In Unternehmens-Builds von 2026 ist brotli fast immer standardmäßig enthalten.

Sicherungskopien. In diesem Leitfaden ändern wir keine Konfiguration von Produktionsservern und fassen keine produktiven Daten an. Wir senden nur Anfragen und messen Antworten. Daher sind keine Sicherungskopien erforderlich. Wenn du später jedoch die Komprimierung auf deinem eigenen Webserver aktivierst, speichere unbedingt die ursprüngliche Konfigurationsdatei, bevor du Änderungen vornimmst.

✅ Überprüfung: Alle drei Werkzeuge antworten auf den Versionsprüfungsbefehl und zeigen eine Nummer an. Die Vorbereitung ist abgeschlossen, wir können weitermachen.

Grundbegriffe einfach erklärt

Bevor wir auf die Knöpfe drücken, klären wir die Begriffe. Das dauert fünf Minuten, erspart aber spätere Verwirrung.

Wie die Aushandlung der Komprimierung funktioniert

HTTP-Komprimierung basiert auf drei Headern. Das Verständnis ihrer Rolle löst die meisten Probleme.

Accept-Encoding beim Client. Das ist der Header, den dein Client zusammen mit der Anfrage sendet. Darin sind die Komprimierungsalgorithmen aufgelistet, die der Client entpacken kann. Zum Beispiel sagt die Zeichenkette

Accept-Encoding: gzip, br, zstd

Content-Encoding in der Antwort. Das ist der Header, den der Server seiner Antwort hinzufügt. Er gibt an, mit welchem Algorithmus der Körper komprimiert ist. Wenn du

Content-Encoding: br

Vary auf der Server-Seite. Der Header Vary teilt Caches und Proxys mit, dass die Antwort von bestimmten Headern der Anfrage abhängt. Für die Komprimierung ist der Wert

Vary: Accept-Encoding

Kernidee der Aushandlung

Merke dir die Abfolge. Der Client fragt via Accept-Encoding an. Der Server entscheidet und antwortet via Content-Encoding. Zwischenstationen orientieren sich an Vary. Wenn nur ein Glied dieser Kette unterbrochen ist, erhältst du eine unkomprimierte Antwort und zahlst mehr für den Traffic.

Tipp: Selbst wenn deine HTTP-Bibliothek Accept-Encoding automatisch hinzufügt, überprüfe immer den tatsächlichen Antwort-Header. Automatik schweigt manchmal, und der Traffic fließt trotzdem.

gzip, deflate, brotli, zstd: Vergleich der Algorithmen

Es gibt vier gängige Komprimierungsalgorithmen für HTTP. Sie unterscheiden sich im Komprimierungsgrad und in der Prozessorlast. Wir schauen uns jeden an und fassen die Zahlen in einer Tabelle zusammen.

gzip

Der älteste und universellste. Wird absolut überall unterstützt: jeder Server, jeder Client, jeder Proxy. Bietet eine gute Komprimierung bei Textdaten mit moderater Last. Wenn du unsicher bist, was du wählen sollst, beginne mit gzip.

deflate

Naher Verwandter von gzip, verwendet intern denselben Algorithmus, aber mit anderer Verpackung. In der Praxis seltener anzutreffen und manchmal fehlerhaft auf Servern implementiert. Der Komprimierungsgrad ist ungefähr wie bei gzip. Es gibt keinen besonderen Grund, deflate anstelle von gzip zu wählen.

brotli

Modern, speziell für das Web entwickelt. Bei Textdaten komprimiert deutlich stärker als gzip, insbesondere bei HTML, CSS und JSON. Der Preis dafür ist eine höhere Prozessorlast beim Komprimieren auf maximalen Stufen. Das Entpacken ist schnell. In Headern wird es als br bezeichnet.

zstd

Schneller moderner Algorithmus mit flexibler Einstellung der Stufen. Bietet einen Komprimierungsgrad auf dem Niveau von brotli, arbeitet aber schneller beim Komprimieren. Die Unterstützung im Web wächst; bis 2026 verstehen ihn die meisten aktuellen Server und Clients. In Headern wird er als zstd bezeichnet.

Vergleichstabelle bei einer typischen Textantwort

Nehmen wir eine beispielhafte JSON-Antwort mit einer Größe von 1000 Kilobyte unkomprimiert. Die Zahlen sind Richtwerte, sie hängen vom Inhalt ab, aber die Größenordnung stimmt.

• Ohne Komprimierung: 1000 KB, Ersparnis 0 Prozent, Prozessorlast minimal.
• gzip Stufe 6: ca. 190 KB, Ersparnis ca. 81 Prozent, geringe Last.
• deflate Stufe 6: ca. 195 KB, Ersparnis ca. 80 Prozent, geringe Last.
• brotli Stufe 5: ca. 165 KB, Ersparnis ca. 83 Prozent, mittlere Last.
• brotli Stufe 11: ca. 140 KB, Ersparnis ca. 86 Prozent, hohe Last.
• zstd Stufe 3: ca. 175 KB, Ersparnis ca. 82 Prozent, geringe Last.
• zstd Stufe 19: ca. 150 KB, Ersparnis ca. 85 Prozent, mittlere Last.

Die Schlussfolgerung ist einfach: Bei Textdaten reduziert jede Komprimierung den Traffic um etwa das Fünffache. Der Unterschied zwischen den Algorithmen liegt im Bereich weniger Prozent. Für die Traffic-Ersparnis über einen Proxy ist also nicht der Algorithmus entscheidend, sondern die Tatsache, dass die Komprimierung überhaupt aktiviert ist.

Tipp: Wenn du Daten nur herunterlädst und nicht bereitstellst, fällt auf deinem Prozessor nur das Entpacken an, und das ist bei allen Algorithmen schnell. Du kannst also getrost die Variante mit dem besten Komprimierungsgrad anfordern.

✅ Überprüfung: Du verstehst, dass brotli und zstd bei Text meist etwas effizienter sind als gzip, aber gzip am kompatibelsten ist. Das reicht für die Praxis.

Schritt 1: Anfrage senden und prüfen, ob die Antwort komprimiert wird

Ziel dieser Phase. Lernen, die Header Content-Encoding und die tatsächliche Größe des Körpers zu sehen. Ohne das ist es unmöglich, die Ersparnis zu messen.

Prüfung mit curl

1. Öffne ein Terminal.
2. Frage zuerst die Ressource ohne Komprimierung ab, um die ursprüngliche Größe zu erfahren:

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. Notiere die Zahl. Das ist die Größe der unkomprimierten Antwort in Bytes.
4. Jetzt fordere die Komprimierung an. Das Flag --compressed fügt automatisch Accept-Encoding hinzu und entpackt die Antwort:

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. Vergleiche die beiden Zahlen. Die zweite sollte bei gleichem Inhalt deutlich kleiner sein.

Wichtig: Der Wert size_download in curl mit --compressed gibt die Größe der bereits entpackten Daten wieder, nicht die Menge, die über das Netzwerk gegangen ist. Um das tatsächliche Netzwerkvolumen zu sehen, verwende den Antwort-Header und Zwischenmessungen, die wir im Messschritt besprechen.

Antwort-Header ansehen

1. Führe eine Anfrage mit dem Flag für die Header-Ausgabe durch:

   curl -s -I --compressed https://example.com/api/data

2. Suche in der Ausgabe nach der Zeile Content-Encoding. Wenn dort gzip, br oder zstd steht, hat der Server eine komprimierte Antwort geliefert.
3. Suche nach der Zeile Vary. Wenn dort Accept-Encoding steht, ist das Caching korrekt konfiguriert.

Tipp: Um einen bestimmten Algorithmus explizit anzufordern, füge den Header manuell hinzu:

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

Arbeiten mit dem Proxeon-Proxy

Um die Ersparnis unter realen Bedingungen zu messen, sende die Anfrage über den Proxy. In curl geschieht das mit dem Flag -x:

curl -s --compressed -x http://Benutzername:Passwort@Proxeon-Adresse:Port -o /dev/null -w "%{size_download}" https://example.com/api/data

So siehst du, ob die Komprimierung über den Proxy ankommt und ob unterwegs Header entfernt werden.

Erwartetes Ergebnis. Du siehst zwei Zahlen: Größe ohne Komprimierung und Größe mit Komprimierung. Außerdem siehst du den Header Content-Encoding in der Antwort. Das bedeutet, der Mechanismus funktioniert.

Mögliches Problem: Wenn beide Zahlen identisch sind und Content-Encoding fehlt, hat der Server keine Komprimierung geliefert. Die Ursachen besprechen wir in einem eigenen Abschnitt.

✅ Überprüfung: In der Antwort mit dem Flag --compressed ist die Zeile Content-Encoding mit einem der Algorithmen vorhanden. Der Schritt ist abgeschlossen.

Schritt 2: Echte Ersparnis in Python messen

Ziel dieser Phase. Genaue Zahlen zum Netzwerkverkehr vor und nach der Komprimierung mit einem funktionierenden Skript erhalten, das du auf deine Aufgabe anwenden kannst.

Einfache Messung mit requests

Die Bibliothek requests fügt standardmäßig selbst Accept-Encoding hinzu und entpackt die Antwort. Um die tatsächliche Netzwerkgröße zu messen, betrachten wir die Länge des rohen Inhalts vor dem Entpacken.

1. Erstelle eine Datei measure.py.
2. Füge den folgenden Code ein:

import requests
url = "https://example.com/api/data"
# Anfrage ohne Komprimierung
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# Anfrage mit Komprimierung
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "keiner")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("Ohne Komprimierung, Bytes:", size_plain)
print("Komprimierungsalgorithmus:", encoding)
print("Übertragen (ca.), Bytes:", size_wire)
print("Nach dem Entpacken, Bytes:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("Traffic-Ersparnis, Prozent:", saved)

Achtung: Der Wert Content-Length ist nicht immer vorhanden, insbesondere bei Chunked-Übertragung. Wenn er fehlt, verwende die genauere Methode unten.

Genaue Messung des Netzwerkvolumens

Um genau zu messen, was über das Netzwerk geht, deaktiviere die automatische Entpackung und zähle die Bytes des rohen Streams.

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# Automatische Entpackung deaktivieren, um die Rohgröße zu sehen
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("Algorithmus:", r.headers.get("Content-Encoding", "keiner"))
print("Rohe Bytes über das Netzwerk:", raw_bytes)

Vergleiche raw_bytes mit der Größe der unkomprimierten Anfrage. Die Differenz ist deine tatsächliche Ersparnis.

Messung über den Proxeon-Proxy

Füge den Parameter proxies hinzu, um Zahlen unter realen Bedingungen zu erhalten:

proxies = {
"http": "http://Benutzername:Passwort@Proxeon-Adresse:Port",
"https": "http://Benutzername:Passwort@Proxeon-Adresse:Port",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

Tipp: Führe die Messung mehrmals durch und nimm den Durchschnitt. Dynamische Antworten ändern ihre Größe, daher kann eine einzelne Messung in die Irre führen.

Erwartetes Ergebnis. Das Skript gibt den Komprimierungsalgorithmus und die Anzahl roher Bytes aus, die kleiner ist als die Größe der unkomprimierten Antwort. Wenn die Ersparnis bei einer Textressource siebzig Prozent oder mehr beträgt, funktioniert alles wie erwartet.

✅ Überprüfung: In der Ausgabe ist der Algorithmus nicht „keiner“, und die rohen Bytes sind kleiner als ohne Komprimierung. Sehr gut.

Schritt 3: Dieselbe Messung auf Node.js

Ziel dieser Phase. Ein funktionierendes Messwerkzeug in JavaScript für alle, die Clients auf Node schreiben.

Messung des rohen Streams

1. Erstelle eine Datei measure.js.
2. Füge den Code ein, der die Bytes vor dem Entpacken zählt:

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'keiner', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('Ohne Komprimierung, Bytes:', plain.bytes);
 console.log('Algorithmus:', comp.enc);
 console.log('Komprimiert über das Netzwerk, Bytes:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('Ersparnis, Prozent:', saved);
})();

Wichtig: In diesem Beispiel lesen wir den rohen Stream aus res und verbinden zlib nicht. Der Zähler bytes zeigt also das tatsächliche Netzwerkvolumen. Genau das ist es, wofür du den Proxy-Anbieter bezahlst.

Manuelles Entpacken auf Node

Wenn du den Inhalt auch lesen musst, entpacke den Stream über das integrierte Modul zlib:

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

Tipp: Für zstd gibt es in neueren Node.js-Versionen zlib.createZstdDecompress. Wenn deine Version das nicht enthält, aktualisiere Node oder verwende ein separates npm-Paket.

Erwartetes Ergebnis. Node gibt eine Ersparnis in Prozent aus, die mit den Werten von Python und curl vergleichbar ist.

✅ Überprüfung: Drei Werkzeuge liefern ähnliche Ersparniswerte. Deine Messungen sind zuverlässig.

Schritt 4: Warum die Antwort unkomprimiert ankommt

Ziel dieser Phase. Lernen, zu diagnostizieren, warum die Komprimierung nicht funktioniert hat, und die Ursache zu beheben. Das ist das häufigste Problem in der Praxis.

Fall eins: Der Client hat nicht danach gefragt

Die häufigste Ursache. Dein HTTP-Client hat den Header Accept-Encoding nicht gesendet, und der Server liefert korrekt eine unkomprimierte Antwort. Das passiert, wenn du Header manuell erstellst und das Komprimieren vergisst oder einen Low-Level-Socket verwendest.

1. Überprüfe, was genau zum Server geht. Füge in curl das Flag -v hinzu und suche nach der Zeile mit Accept-Encoding in den ausgehenden Headern.
2. Wenn die Zeile fehlt, füge sie explizit über -H oder das Flag --compressed hinzu.
3. In Python stelle sicher, dass du den Header nicht mit einem leeren Wert überschrieben hast.

Achtung: Einige Bibliotheken fügen ihre Standard-Header nicht mehr hinzu, wenn du einen Header manuell setzt. Wenn du den User-Agent von Hand setzt, prüfe, ob Accept-Encoding nicht auch verschwunden ist.

Fall zwei: Der Server kann es nicht

Der Server unterstützt möglicherweise überhaupt keine Komprimierung oder nicht den angefragten Algorithmus. In diesem Fall liefert er eine unkomprimierte Antwort, was laut Standard zulässig ist.

1. Frage nacheinander verschiedene Algorithmen ab: zuerst gzip, dann br, dann zstd.
2. Prüfe, bei welchem Algorithmus Content-Encoding in der Antwort erscheint.
3. Wenn bei keinem, liefert der Server keine Komprimierung. Das kannst du bei einem fremden Server nicht ändern, aber du kannst einen anderen Endpunkt oder eine andere API wählen, falls vorhanden.

Tipp: Viele APIs liefern nur Antworten ab einer bestimmten Größe komprimiert. Kleine Antworten lässt der Server bewusst unkomprimiert, weil der Mehraufwand größer als der Nutzen wäre.

Fall drei: Ein Zwischenglied hat den Header entfernt

Zwischen dir und dem Server kann ein Cache-Knoten, ein Gateway oder ein Proxy stehen, der die Komprimierungs-Header löscht oder ändert. Manchmal entpackt ein Zwischenglied die Antwort für eigene Zwecke und liefert dir bereits entpackte Variante.

1. Mach eine Anfrage direkt und eine über den Proxy und vergleiche die Content-Encoding-Header.
2. Wenn direkt Komprimierung vorhanden ist, aber über das Zwischenglied nicht, greift das Zwischenglied ein.
3. Beim Arbeiten über den Proxeon-Proxy wird die Komprimierung transparent übertragen. Wenn du also einen Unterschied siehst, suche das Problem auf der Seite des Zielservers oder dessen CDN.

Erwartetes Ergebnis. Du weißt genau, an welchem der drei Glieder die Komprimierung verloren geht, und verstehst, was du dagegen tun kannst.

✅ Überprüfung: Du kannst in einem Satz erklären, warum eine bestimmte Antwort unkomprimiert ankam. Die Diagnose ist gemeistert.

Schritt 5: Stolperfallen bei der Arbeit mit Komprimierung

Ziel dieser Phase. Feine Fehler vermeiden, die Daten beschädigen oder Messungen verfälschen.

Doppelte Komprimierung

Manchmal ist der Inhalt bereits auf Anwendungsebene komprimiert, und der Server komprimiert ihn erneut. Oder umgekehrt: Du komprimierst den Anfragekörper, und der Proxy oder die Bibliothek macht es erneut. Doppelte Komprimierung bringt fast keinen Gewinn, manchmal sogar eine Vergrößerung, und verschwendet definitiv Prozessorzeit.

1. Prüfe, ob in der Antwort zwei Werte in Content-Encoding stehen, z.B. gzip in br.
2. Komprimiere nicht manuell, was die Bibliothek bereits automatisch macht.
3. Wenn du eine Kette von Kodierungen siehst, entpacke sie in umgekehrter Reihenfolge.

Beschädigter Stream

Ein Verbindungsabbruch oder ein Fehler eines Zwischenglieds kann dazu führen, dass der komprimierte Stream unvollständig ankommt. Beim Entpacken erhältst du einen Fehler oder abgeschnittene Daten.

1. Wickle das Entpacken immer in eine Fehlerbehandlung ein.
2. Bei einem Entpackfehler wiederhole die Anfrage, anstatt beschädigte Daten zu lesen.
3. Vergleiche die tatsächliche Größe mit Content-Length, falls angegeben.

Achtung: Speichere niemals teilweise entpackte Daten als Ergebnis. Beschädigtes JSON sieht plausibel aus, führt aber später zu versteckten Fehlern im Datenfluss.

Manuelles Entpacken, wenn die Bibliothek es nicht macht

Wenn du das automatische Entpacken für eine genaue Messung deaktiviert hast oder einen Low-Level-Client verwendest, musst du manuell entpacken. Beispiel in Python:

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

Tipp: Wenn das Entpacken von deflate fehlschlägt, versuche zlib.decompress mit dem Parameter wbits gleich minus fünfzehn. Einige Server liefern reines deflate ohne Zlib-Umschlag.

Erwartetes Ergebnis. Du kannst jedes der unterstützten Formate manuell entpacken und behandelst Stromfehler korrekt.

✅ Überprüfung: Dein Skript stürzt bei einer beschädigten Antwort nicht ab, sondern wiederholt die Anfrage. Stabilität erreicht.

Schritt 6: Was zu komprimieren sinnlos ist

Ziel dieser Phase. Keine Prozessorzeit und Zeit für das Komprimieren von bereits Komprimiertem verschwenden. Das spart Ressourcen ohne Verlust an Traffic-Vorteil.

Bereits komprimierte Formate

Einige Daten sind in Formaten gespeichert, die intern bereits Komprimierung verwenden. Diese erneut zu komprimieren ist sinnlos: Der Gewinn beträgt Bruchteile eines Prozents, und der Prozessor wird unnötig belastet.

• Bilder: JPEG, PNG, WebP, AVIF sind intern bereits komprimiert.
• Video: MP4, WebM, MKV enthalten hochkomprimierte Videoströme.
• Audio: MP3, AAC, OGG sind von Natur aus komprimiert.
• Archive: ZIP, RAR, 7z, gz sind bereits komprimierte Container.

Bei solchen Ressourcen bringt Accept-Encoding keine Einsparung beim Körper. Außerdem komprimiert der Server sie meist selbst nicht erneut, da er nach einer Liste von MIME-Typen konfiguriert ist.

Was zu komprimieren sinnvoll ist

• HTML, CSS, JavaScript.
• JSON- und XML-Antworten von APIs.
• Einfacher Text, CSV, Logs.
• SVG, weil das im Grunde Text ist.

Tipp: Wenn du hauptsächlich Mediendateien lädst, wird die Ersparnis durch Komprimierung nahe null sein. Hier bringt anderes etwas: Nur die benötigten Größen und Formate anfordern, nicht die Tatsache der Komprimierung. Das ist aber ein Thema des Traffic-Managements, nicht der Komprimierung selbst.

Erwartetes Ergebnis. Du verschwendest keine Ressourcen für das Komprimieren binärer Formate und wendest Komprimierung nur dort an, wo sie wirklich hilft.

✅ Überprüfung: Du kannst in einer Sekunde sagen, ob es sinnvoll ist, einen bestimmten Antworttyp zu komprimieren. Verständnis geschaffen.

Ergebnisprüfung

Nun ist es Zeit, sicherzustellen, dass alles korrekt eingerichtet ist. Gehe die Checkliste durch.

Checkliste für die Funktion

1. Dein Client sendet den Header Accept-Encoding mit den gewünschten Algorithmen.
2. In der Antwort ist Content-Encoding mit einem dieser Algorithmen auf Textressourcen vorhanden.
3. Das Messskript zeigt ein Netzwerkvolumen, das mindestens siebzig Prozent kleiner ist als unkomprimiert (bei Text).
4. Über den Proxeon-Proxy bleibt die Komprimierung erhalten, die Zahlen stimmen mit der direkten Anfrage überein.
5. Das Entpacken erzeugt keine Fehler, und die Daten sind korrekt lesbar.
6. Du versuchst nicht, binäre Formate zu komprimieren.

So testest du

1. Nimm drei verschiedene Endpunkte: einen mit JSON, einen mit HTML, einen mit einem Bild.
2. Lass jeden durch dein Messskript laufen.
3. Stelle sicher, dass die Ersparnis bei den ersten beiden hoch und beim dritten nahe null ist.

Erfolgskriterien. Bei einer Text-API siehst du konsistent eine Ersparnis zwischen siebzig und neunzig Prozent. Bei Medien ist die Ersparnis minimal, das ist normal. Durch den Proxy verschlechtern sich die Zahlen nicht.

✅ Überprüfung: Alle sechs Punkte der Checkliste sind erfüllt. Die Komprimierung ist korrekt eingerichtet und gemessen.

Typische Fehler und Lösungen

Hier findest du häufige Probleme im Format Problem, Ursache, Lösung.

Die Antwort wird nicht komprimiert, obwohl Accept-Encoding gesendet wurde

Ursache: Der Server unterstützt keine Komprimierung für diesen Inhaltstyp oder für Antworten dieser Größe. Lösung: Probiere einen anderen Algorithmus und stelle sicher, dass die Ressource textbasiert und groß genug ist.

Die Ersparnis bei curl ist nicht sichtbar, size_download ändert sich nicht

Ursache: Das Flag --compressed zeigt die Größe nach dem Entpacken. Lösung: Miss das Netzwerkvolumen mit einem separaten Skript ohne automatisches Entpacken, wie in den Schritten zu Python und Node.

Die Bibliothek gibt Müll statt Text aus

Ursache: Du hast das automatische Entpacken deaktiviert, aber den Stream nicht manuell entpackt. Lösung: Bestimme Content-Encoding und wende die passende Entpackfunktion an.

Fehler beim Entpacken von deflate

Ursache: Der Server liefert reines deflate ohne Umschlag. Lösung: Rufe das Entpacken mit dem Parameter wbits minus fünfzehn auf.

Über den Proxy verschwindet die Komprimierung

Ursache: Auf dem Weg steht ein Knoten, der Header ändert, meist das CDN der Zielseite. Lösung: Vergleiche direkte und proxierte Anfrage und bestimme das Zwischenglied. Der Proxeon-Proxy leitet Header transparent weiter, also liegt das Problem meistens auf Server-Seite.

Unterschiedliche Antwortgröße bei wiederholten Messungen

Ursache: Der Inhalt ist dynamisch und ändert sich von Anfrage zu Anfrage. Lösung: Nimm den Durchschnitt mehrerer Messungen und vergleiche nur bei gleichen Anfrageparametern.

Content-Length fehlt

Ursache: Bei Chunked-Übertragung wird die Länge nicht vorab angegeben. Lösung: Zähle die Bytes manuell beim Lesen des Streams, wie in den Skriptbeispielen.

Doppelte Komprimierung belastet den Prozessor

Ursache: Der Inhalt wird auf verschiedenen Ebenen doppelt komprimiert. Lösung: Entferne manuelle Komprimierung, wo Bibliothek oder Server sie bereits übernehmen.

Weitere Möglichkeiten

Wenn das Grundszenario gemeistert ist, gibt es Raum für Entwicklung.

Priorität der Algorithmen wählen

Im Header Accept-Encoding kannst du Gewichte über q-Werte angeben, um dem Server deine Präferenz mitzuteilen. Zum Beispiel

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

Entpackte Daten cachen

Wenn du auf dieselbe Ressource mehrfach zugreifst, cache das entpackte Ergebnis auf deiner Seite. Das spart sowohl Traffic als auch Prozessorzeit für wiederholtes Entpacken.

Massenmessung über eine URL-Liste

Wickle das Messskript in eine Schleife über eine Liste von Endpunkten und sammle eine Tabelle der Ersparnis. So findest du die schwersten unkomprimierten Antworten in deinem Projekt und kümmerst dich zuerst um sie.

Tipp: Führe ein Protokoll der Ersparnis in Bytes pro Tag. Multipliziert mit dem Preis pro Gigabyte erhältst du den greifbaren Geldvorteil der aktivierten Komprimierung bei der Arbeit über einen Proxy.

✅ Überprüfung: Du kannst eine übersichtliche Tabelle der Ersparnis über mehrere Ressourcen mit einem einzigen Skriptlauf erstellen.

FAQ

Sollte ich immer brotli statt gzip anfordern?

Wenn du nur herunterlädst, ist das Entpacken bei allen Algorithmen schnell, also kannst du den effizientesten anfordern. In der Praxis gib in Accept-Encoding alle drei an: gzip, br, zstd. Der Server wählt den besten verfügbaren.

Wie viel Traffic spart Komprimierung bei einer Text-API?

Normalerweise zwischen siebzig und neunzig Prozent. Das heißt, eine Antwort, die ein Gigabyte wog, geht als etwa hundertfünfzig bis zweihundert Megabyte über das Netzwerk. Bei Bezahlung pro Gigabyte ist die Ersparnis direkt und spürbar.

Beeinflusst Komprimierung die Antwortgeschwindigkeit?

Weniger Daten werden schneller übertragen, besonders auf langsamen Kanälen. Die kleine Verzögerung durch das Komprimieren beim Server wird in der Regel durch die kürzere Übertragungszeit mehr als ausgeglichen.

Warum zeigt curl bei Komprimierungsflag und ohne dieselbe Größe?

Weil --compressed die Größe des bereits entpackten Körpers ausgibt. Das tatsächliche Netzwerkvolumen ist kleiner. Miss den rohen Stream mit einem separaten Skript.

Kann ich den POST-Anfragekörper komprimieren?

Ja, dazu setzt der Client Content-Encoding in der Anfrage, aber der Server muss es entpacken können. Nicht alle Server unterstützen das, also prüfe die API-Dokumentation.

Funktioniert Komprimierung über den Proxeon-Proxy?

Ja. Der Proxy leitet die Header Accept-Encoding und Content-Encoding transparent weiter, also bleibt die gesamte Ersparnis erhalten. Genau deshalb lohnt es sich, gleich über den Proxy zu messen, unter realen Bedingungen.

Was tun, wenn der Server keine Komprimierung liefert?

Stelle sicher, dass du Komprimierung anforderst und die Ressource textbasiert ist. Wenn der Server trotzdem schweigt, kannst du den fremden Server nicht ändern, aber du kannst einen anderen Endpunkt wählen oder die Daten auf deiner Cache-Schicht komprimieren.

Sollte ich Bilder über Accept-Encoding komprimieren?

Nein. Formate wie JPEG und WebP sind bereits komprimiert. Zusätzliche Komprimierung bringt keinen Gewinn und belastet nur den Prozessor.

Wie wähle ich zwischen zstd und brotli?

Zum Herunterladen liegt der Unterschied beim Traffic bei wenigen Prozent. Gib beide in Accept-Encoding an und lass den Server entscheiden. Wenn der Server nur einen unterstützt, bekommst du genau den.

Brauche ich Vary bei der Client-Arbeit?

Als Client setzt du Vary nicht, das macht der Server. Aber es zu verstehen hilft: Es erklärt, warum ein Cache manchmal komprimierte und manchmal unkomprimierte Varianten ausliefert.

Fazit

Du hast den Weg von der Theorie bis zu funktionierenden Messungen geschafft. Jetzt verstehst du, wie Komprimierung über Accept-Encoding, Content-Encoding und Vary ausgehandelt wird. Du kannst Komprimierung in curl, Python und Node.js anfordern und das tatsächliche Netzwerkvolumen vorher und nachher messen. Du weißt, warum eine Antwort manchmal unkomprimiert ankommt und wie du das anhand der drei typischen Ursachen diagnostizierst. Du hast dich mit Stolperfallen auseinandergesetzt: doppelter Komprimierung, beschädigtem Stream und manuellem Entpacken. Und du verschwendest keine Ressourcen mehr für das Komprimieren von Bildern, Videos und Archiven.

Was du als Nächstes tun solltest. Lass das Messskript über alle wichtigen Endpunkte deines Projekts laufen. Finde die Antworten, bei denen keine Komprimierung aktiviert ist, und fordere sie explizit an. Führe ein Protokoll der gesparten Bytes, um den Geldvorteil bei der Arbeit über den Proxeon-Proxy zu sehen. Wenn du das Grundszenario gemeistert hast, gehe zur Massenmessung über eine URL-Liste und zu Algorithmus-Prioritäten über q-Werte über.

Komprimierung ist eine der günstigsten Möglichkeiten, die Rechnung für Traffic zu senken. Ein richtig gesendeter Header kann die Datenmenge um ein Vielfaches reduzieren. Jetzt liegt dieses Werkzeug in deinen Händen, und du kannst es bewusst und mit präzisen Zahlen anwenden.