Saan Makatitipid ng Bandwidth ang Isang Compressing Proxy
Ilagay ang pagbabawas ng nilalaman bago ang limitadong koneksyon ng kliyente at isaalang-alang ang kalidad ng larawan, umiiral na compression at visibility ng HTTPS.
Ilagay ang pagbabawas ng nilalaman bago ang limitadong koneksyon sa daan ng tugon:
website → proxy transforms response → slow or metered link → browserKung ang buong katawan ay nakatawid na sa koneksyong iyon, ang pagpapaliit nito pagkatapos ay hindi na makakabawi ng mga byte na iyon. Ang isang malayong tagapagpalit na may mas mabilis na upstream ay maaaring maglingkod sa ibang layunin kaysa lokal na proxy sa tabi ng browser.
Inilalarawan ng Ziproxy ang pamamaraang ito: inilalarawan ng proyekto nito ang isang HTTP proxy na walang cache na naggzip ng nilalamang tulad ng teksto at makakagawa ng mas maliit at mas mababang kalidad na mga larawan.
| Daan ng tugon | Posibleng pagbawas |
|---|---|
| Gzip encoding | Walang pagkawala; dine-decode ng browser ang orihinal na datos |
| Muling compression ng larawan | Maaaring itapon ang detalye at hindi angkop kapag mahalaga ang eksaktong larawan |
| Nilalamang mahusay nang naka-compress | Mas kaunting puwang para sa karagdagang pagbawas |
| Karaniwang HTTPS CONNECT | Hinahadlangan ng malabong TLS ang pagbabago ng HTML o larawan nang walang ibang pinagkakatiwalaang kaayusan para sa pag-access sa plaintext |
Ang pagpoproseso at ang karagdagang pagtalon ay tumatagal din ng oras, kaya ang mas kaunting byte ay hindi garantiya ng mas mabilis na pagtatapos. Ginagamit muli ng cache ang karapat-dapat na naka-store na tugon; ang compression ay makakabago ng bagong nakuhang tugon nang hindi ito iniimbak.
Kung saan nakikita ang nilalamang HTTP, igalang ang Cache-Control: no-transform. Ang patakaran ng tugon na no-transform ay namamahala sa pagsunod na paghawak ng nilalaman; hiwalay ito sa encryption ng transport. Tantiya ang mga pakinabang mula sa aktwal na nilalaman at daan ng encryption, hindi mula sa lumang demonstrasyon ng mga larawan sa plaintext.