Можете ли вы использовать gzip поверх SSL? And Connection: Keep-Alive заголовки - PullRequest
33 голосов
/ 04 мая 2010

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

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

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

Ответы [ 5 ]

31 голосов
/ 31 октября 2010

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

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

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

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

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

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

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

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

  4. Поговорим и о кешировании

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

Сценарий:

  1. Статическое содержимое, например, CSS или JS:

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

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

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

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

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

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

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

0 голосов
/ 06 мая 2010

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

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

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

0 голосов
/ 04 мая 2010

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

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

...