Можете ли вы использовать gzip через SSL? И соединение: Keep-Alive headers

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

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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 2

  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. Или вы возвращаете пользовательский ввод в ответ, но случайным образом дополняете ответ

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

В этом сообщении блога есть дополнительная информация о настройке веб-сайта для HTTPS/SSL:

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