it-swarm.com.ru

Можете ли вы использовать gzip поверх SSL? And Connection: Keep-Alive заголовки

Я оцениваю производительность интерфейса защищенного (SSL) веб-приложения здесь, на работе, и мне интересно, возможно ли сжимать текстовые файлы (html/css/javascript) по SSL. Я немного погуглил, но не нашел ничего, связанного с SSL. Если это возможно, стоит ли даже дополнительных циклов ЦП, поскольку ответы также шифруются? Повлияет ли сжатие ответов на производительность?

Кроме того, я хочу убедиться, что мы поддерживаем соединение SSL, чтобы мы не делали рукопожатия SSL снова и снова. Я не вижу Соединение: Keep-Alive в ответ заголовки. Я вижу Keep-Alive: 115 в заголовках request , но это только поддерживает соединение в течение 115 миллисекунд (кажется, что сервер приложений закрывает соединение после обработки одного запроса?) Разве вы не хотите сервер будет устанавливать этот response header до тех пор, пока тайм-аут неактивности сеанса?

Я понимаю, что браузеры не кэшируют SSL-контент на диск, поэтому при последующих посещениях мы обслуживаем одни и те же файлы снова и снова, хотя ничего не изменилось. Основные рекомендации по оптимизации - сокращение количества http-запросов, минимизация, перемещение сценариев в низ, оптимизация изображений, возможное разделение домена (хотя необходимо взвесить стоимость другого рукопожатия SSL), вещи такого рода.

31
magenta

Да, сжатие можно использовать поверх SSL; это происходит до того, как данные зашифрованы, что может помочь при медленном соединении. Следует отметить, что это плохая идея: это также открывает уязвимость.

После первоначального рукопожатия SSL - это меньше затрат, чем думают многие * - даже если клиент переподключается, существует механизм для продолжения существующих сеансов без повторного согласования ключей, что приводит к меньшему использованию ЦП и меньшему количеству обратных вызовов.

Однако балансировщики нагрузки могут работать с механизмом продолжения: если запросы чередуются между серверами, то требуется более полное рукопожатие, что может оказать заметное влияние (~ несколько сотен мс на запрос). Настройте балансировщик нагрузки для пересылки всех запросов с одного IP-адреса на один и тот же сервер приложений.

Какой сервер приложений вы используете? Если его нельзя настроить на использование keep-alive, сжатие файлов и т.д., Тогда рассмотрите возможность размещения его за обратным прокси-сервером can (и пока вы это делаете, ослабьте заголовки кэша, отправленные со статическим content - в связанной статье HttpWatchSupport есть несколько полезных советов по этому вопросу).

(* Производители оборудования SSL будут говорить что-то вроде «до 5 раз больше ЦП», но некоторые главы Google сообщают, что когда Gmail переходил на SSL по умолчанию, на него приходилось только ~ 1% загрузки ЦП)

28
SimonJ
  1. Вы, вероятно, никогда не должны использовать сжатие TLS. Некоторые пользовательские агенты (по крайней мере, Chrome) все равно отключат его. 

  2. Вы можете выборочно использовать HTTP-сжатие

  3. Вы всегда можете минимизировать

  4. Давайте поговорим о кешировании тоже

Я предполагаю, что вы используете веб-сайт в стиле HTTPS Everywhere.

Сценарий:

  1. Статический контент, такой как CSS или JS:

    • Использовать HTTP-сжатие
    • Используйте минификацию
    • Длинный период кэширования (например, год)
    • этаг полезен лишь незначительно (из-за длинного кэша)
    • Включите какой-нибудь номер версии в URL в вашем HTML-коде, указывающий на этот ресурс, чтобы вы могли кешировать
  2. HTML-контент с информацией, чувствительной к нулю (например, страница «О нас»):

    • Использовать HTTP-сжатие
    • Использовать минимизацию HTML
    • Используйте короткий период кэширования
    • Используйте etag
  3. HTML-контент с ЛЮБОЙ конфиденциальной информацией (например, токен CSRF или номер банковского счета):

    • НЕТ HTTP-сжатия
    • Использовать минимизацию HTML
    • Cache-Control: no-store, must-revalidate
    • этаг здесь не имеет смысла (из-за переаттестации)
    • некоторая логика для перенаправления страницы после тайм-аута сеанса (с учетом нескольких вкладок). Если кто-то нажимает кнопку «Назад» браузера, конфиденциальная информация не отображается из-за заголовка кэша. 

Вы можете использовать HTTP-сжатие с конфиденциальными данными, если:

  1. Вы никогда не возвращаете пользовательский ввод в ответ (есть окно поиска? Не использовать HTTP-сжатие)
  2. Или вы возвращаете пользовательский ввод в ответ, но случайным образом дополняете ответ
17
Neil McGuigan

Использование сжатия с SSL открывает вам уязвимости, такие как BREACH, CRIME или другие выбранные атаки с открытым текстом.

Вы должны отключить сжатие, так как SSL/TLS не имеют возможности в настоящее время смягчать против этой длины атаки Oracle.

11
Rodney

К первому вопросу: SSL работает не на уровне сжатия, а на другом уровне. В некотором смысле эти два свойства веб-сервера могут работать вместе и не перекрываться. Да, включив сжатие, вы будете использовать больше ресурсов процессора на вашем сервере, но у вас будет меньше исходящего трафика. Так что это скорее компромисс.

На ваш второй вопрос: поведение Keep-Alive действительно зависит от версии HTTP. Вы можете переместить свой статический контент на сервер не-ssl (может включать изображения, фильмы, аудио и т.д.)

0
Zepplock

Да, сжатие gzip и Keep-Alive можно использовать с HTTPS/SSL. Также браузеры могут кэшировать контент SSL.

Эта запись блога содержит больше информации о настройке веб-сайта для HTTPS/SSL:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

0
HttpWatchSupport