Где сжимающий прокси может сэкономить пропускную способность
Разместите сокращение содержимого перед ограниченным клиентским каналом и учитывайте качество изображений, существующее сжатие и видимость HTTPS.
Разместите сокращение содержимого перед ограниченным каналом на пути ответа:
website → proxy transforms response → slow or metered link → browserЕсли полное тело уже прошло этот канал, последующее уменьшение не вернёт эти байты. Удалённый преобразователь с более быстрым восходящим каналом может служить другой цели, чем локальный прокси рядом с браузером.
Ziproxy иллюстрирует подход: его проект описывает HTTP-прокси без кеширования, который сжимает текстовое содержимое по gzip и может создавать изображения меньшего размера и более низкого качества.
| Путь ответа | Возможное сокращение |
|---|---|
| Кодирование gzip | Без потерь; браузер декодирует исходные данные |
| Повторное сжатие изображений | Может отбросить детали и быть непригодным, когда важны точные изображения |
| Уже эффективно сжатое содержимое | Меньше места для дальнейшего сокращения |
| Обычный HTTPS CONNECT | Непрозрачный TLS препятствует преобразованию HTML или изображений без другой доверенной схемы доступа к открытому тексту |
Обработка и дополнительный переход тоже требуют времени, поэтому меньше байтов не гарантирует более быстрого завершения. Кеш повторно использует подходящий сохранённый ответ; сжатие может преобразовать только что полученный ответ, не сохраняя его.
Там, где содержимое HTTP видно, соблюдайте Cache-Control: no-transform. Политика ответа no-transform регулирует соответствующую обработку содержимого; она отделена от шифрования транспорта. Оценивайте выгоду по фактическому содержимому и пути шифрования, а не по старой демонстрации изображений открытым текстом.