В то же время (вопрос уже устарел), большинство людей в любом случае используют TLS для каждого соединения, поэтому вопросы о производительности стали немного излишними.Но все же стоит взглянуть на это:
1) у клиента быстрый интернет -> уместен gzip
2) у клиента медленный интернет -> gzip предотвращает частичный анализ
Дело обстоит иначе. Чем медленнее интернет-соединение клиента (или маршрут к серверу), тем больше преимуществ вы получаете от сжатия gzip (или сжатия в целом).
Сжатие полезно, если время, необходимое для сжатия / распаковки, плюс время, необходимое для передачи сжатых данных, меньше, чем время, необходимое для прямой передачи несжатых данных.
Gzip обычно сокращает вашиданные где-то между 1/3 и 1/2 от своего первоначального размера (в зависимости от того, что это такое), а сжатие выполняется со скоростью около 50 МБ / с (+/- 5).Декомпрессия примерно в 3 раза быстрее.
100 Мбит Ethernet имеет пропускную способность около 12,5 МБ / с, и большинство людей еще не имеют 100 Мбит доступа в Интернет (который, поскольку он обычно устанавливается поверх ATM, медленнеечем обычный Ethernet тоже).Кроме того, большинство людей в большинстве случаев не могут полностью насытить свое высокоскоростное интернет-соединение с помощью одной загрузки.
Таким образом, реально для обычного обычного пользователя и сервера, который не находится в вашей локальной сети.дома, но «где-то еще», скажем, вы получаете 5 МБ / с (что примерно вдвое больше теоретического максимума, который у меня здесь есть, кстати).
Для передачи файла размером 50 КБ вам, таким образом, потребуется 0,01 секунды.Сжатие gzip добавляет примерно 0,001 секунды к сжатию и 0,0003 секунды к распаковке (давайте округлим и скажем всего 0,002), но вам нужно всего лишь передать 16 КБ, что занимает 0,0032 секунды.
Добавьте их вместе, передайте с помощью gzipсжатие примерно в два раза быстрее.
Теперь, конечно, со временем (когда у обычного пользователя будет примерно 200 Мбит / с Интернета, а на серверах - 100 Гбит / с с восходящей связью) эта цифра обернется.