Wo ein komprimierender Proxy Bandbreite sparen kann
Setzen Sie die Inhaltsreduktion vor die begrenzte Client-Strecke und berücksichtigen Sie Bildqualität, vorhandene Kompression und HTTPS-Sichtbarkeit.
Setzen Sie die Inhaltsreduktion vor die begrenzte Strecke auf dem Antwortpfad:
website → proxy transforms response → slow or metered link → browserHat der vollständige Body diese Strecke bereits passiert, kann eine spätere Verkleinerung diese Bytes nicht zurückholen. Ein entfernter Transformator mit schnellerem Upstream kann einem anderen Zweck dienen als ein lokaler Proxy neben dem Browser.
Ziproxy veranschaulicht den Ansatz: Das Projekt beschreibt einen nicht cachenden HTTP-Proxy, der textähnliche Inhalte mit gzip komprimiert und kleinere Bilder mit geringerer Qualität erzeugen kann.
| Antwortpfad | Mögliche Reduktion |
|---|---|
| Gzip-Kodierung | Verlustfrei; der Browser dekodiert die Originaldaten |
| Erneute Bildkompression | Kann Details verwerfen und ungeeignet sein, wenn exakte Bilder wichtig sind |
| Bereits effizient komprimierter Inhalt | Weniger Spielraum für weitere Reduktion |
| Gewöhnliches HTTPS CONNECT | Undurchsichtiges TLS verhindert die Umformung von HTML oder Bildern ohne eine andere vertrauenswürdige Regelung für Klartextzugriff |
Auch Verarbeitung und der zusätzliche Sprung kosten Zeit, daher garantieren weniger Bytes keinen schnelleren Abschluss. Caching nutzt eine geeignete gespeicherte Antwort erneut; Kompression kann eine neu abgerufene Antwort umformen, ohne sie zu speichern.
Wo HTTP-Inhalte sichtbar sind, beachten Sie Cache-Control: no-transform. Die no-transform-Antwortrichtlinie regelt den regelkonformen Umgang mit Inhalten; sie ist von der Transportverschlüsselung getrennt. Schätzen Sie den Nutzen anhand des tatsächlichen Inhalts und Verschlüsselungspfads, nicht anhand einer alten Demonstration mit Klartextbildern.