Эта статья была составлена из статьи Дэвида Нейлора и других, Стоимость буквы «S» в HTTPS, CONEXT 2014.
мотивация
С появлением таких сервисов, как Let’s Encrypt, стоимость использования HTTPS стала очень низкой. Все больше и больше веб-сайтов также используют HTTPS. На YouTube более 50% всего трафика использует HTTPS. S в HTTPS означает безопасность, и мы знаем, что безопасность всегда сопровождается ростом затрат, и HTTPS не является исключением. Каковы эти увеличения стоимости, связанные с дополнительной безопасностью по HTTP? С этой целью в этом документе рассматриваются изменения в сетевом трафике HTTPS за последние три года (т. е. 2011–2014 гг.) и влияние TLS (безопасность транспортного уровня) на сеть по проводным, Wi-Fi и 3G-соединениям соответственно. , Эффекты задержки, потребление данных, потребление батареи. Сначала мы представим выводы этой статьи, а затем представим тенденцию использования HTTPS, влияние на время загрузки страницы, влияние на трафик данных, влияние на время автономной работы и влияние на дополнительные услуги.
в заключении
На основе трех наборов данных, перехваченных из домашней сети и беспроводной сети обычных людей, а также их собственных экспериментов, можно сделать следующие три вывода:
1. Несмотря на потенциальные затраты на развертывание, использование HTTPS быстро растет.
2. HTTPS имеет некоторые очевидные эффекты потребления задержки.
3. Накладные расходы на данные HTTPS ограничены
4. Для некоторых больших файлов HTTPS приводит к значительному расходу заряда батареи.
Тенденции использования HTTPS
(Обратите внимание, что, поскольку это статья 2014 года, стоимость использования, упомянутая автором, может не применяться. В последние годы благодаря бесплатным издателям, таким как Let's Encrypt, стоимость подключения HTTPS значительно снизилась, что расширило его использование.)
Вообще говоря, использование HTTPS повысит стоимость инфраструктуры (например, затраты на вычисления, память, накладные расходы на данные и т. д.) и, что более важно, стоимость сертификата (в некоторых случаях до 1999 долларов США в год), поэтому люди будут только хотите только при необходимости при использовании HTTPS. Чтобы проверить тенденции использования HTTPS, мы отслеживали сети домов 25 000 жителей у крупного европейского интернет-провайдера, используя программу TStat, которая реализует классификацию HTTP и HTTPS на сайтах мониторинга. Для соединений TLS TStat анализирует следующее:
1. SNI (Server Name Indication), имя хоста, к которому необходимо подключиться.
2. SCN (Subject), прикрепленный к сертификату сервера.
Распространенное имя)
На графике выше показано изменение HTTPS-трафика с апреля 2012 г. по сентябрь 2014 г. Рост HTTPS-трафика ошеломляет: за два года он увеличился более чем в два раза. К сентябрю 2014 года 44,3% всех подключений к Интернету уже использовали HTTPS.
Воздействие на время загрузки страницы
Все мы знаем, что данные будут шифроваться и расшифровываться в процессе общения по протоколу HTTPS, поэтому нетрудно предположить, что время загрузки страниц с одинаковым контентом будет разным при использовании HTTP и HTTPS соответственно.Проверочный эксперимент.
Автор проводит два эксперимента, позволяя тестируемым клиентам находиться в среде беспроводной сети, подключенной к маршрутизатору 3G, и в проводной сети, соединенной оптическими волокнами. В каждом эксперименте тестовая машина использует протокол HTTP в браузере PhantomJS для загрузки 500 наиболее посещаемых веб-сайтов на веб-сайте Alexa 20 раз, а затем использует протокол HTTPS для выполнения той же операции. Результаты эксперимента следующие:
Из приведенного выше рисунка ясно видно, что в среде 3G 90% веб-сайтов имеют дополнительную задержку HTTPS более 500 мс, в проводной сети задержка меньше, но все же 40% веб-сайтов, использующих HTTPS, нуждаются дополнительная нагрузка более 500мс.
В ходе сравнительного эксперимента по загрузке одной и той же веб-страницы с использованием протоколов HTTP и HTTPS соответственно было обнаружено, что время загрузки веб-сайта с использованием HTTPS значительно больше, чем с использованием протокола HTTP.
Так что же заставляет HTTPS загружаться дольше? Собрав информацию HTTP-запроса/ответа (HAR) каждой страницы, автор обнаружил следующую цифру, хотя по сравнению с HTTP 40% веб-сайтов загружают HTTPS и устанавливают меньше TCP-соединений; однако почти половина веб-сайтов устанавливает TCP-соединения. Однако каждое рукопожатие занимает больше времени, и эта часть времени в основном вызвана накладными расходами на согласование, вызванными TLS. В результате HTTPS загружается дольше.
Таким образом, нетрудно обнаружить, что накладные расходы HTTPS тесно связаны с накладными расходами, вызванными задержкой рукопожатия TLS, но в настоящее время нельзя исключать, что время загрузки веб-страниц, использующих протокол HTTPS, связанные с качеством сети. Чтобы лучше понять, почему, авторы модифицировали Tstat и позволили Tstat извлечь (i) продолжительность из одночасовых данных трассировки pcap, собранных RES-ISP 3 апреля 2014 г., около 1 миллиона трафика TLS и (ii) количество байтов на TLS. рукопожатие. Для экспериментов автор выбрал несколько репрезентативных веб-сайтов в США. Обычно мы думаем, что продолжительность сетевой задержки связана с расстоянием между клиентом и сервером, поэтому автор вводит внешний RTT для представления вышеуказанного расстояния.Когда RTT больше 100 мс, это означает, что сервер уже за пределами Европы. Однако в ходе эксперимента было установлено, что даже если расстояние между клиентом и сервером очень близко, продолжительность рукопожатия TLS все равно очень велика (левая часть рисунка ниже). задержка согласования в качестве примера (средний рисунок ниже), около 90% продолжительности рукопожатия TLS находится в пределах 300 мс, а 10% превышают 300 мс. Из этого видно, что время полного запроса рукопожатия TLS как минимум в два раза больше, чем RTT, поэтому нетрудно найти огромные дополнительные накладные расходы, которые запрос рукопожатия TLS приносит серверу. Как правило, 5% запросов проходят рукопожатие в 10 раз дольше, чем RTT, возможно, из-за накладных расходов клиента или сервера, перегрузки сети или медленной аутентификации OCSP.
Присмотревшись, можно увидеть, что 4% клиентов имеют соединение с самой короткой продолжительностью рукопожатия TLS более 300 мс (в середине на рисунке ниже). Для этого соединения 50% (75%) имеют внутреннее RTT (т. е. RTT между точкой обзора и устройством конечного пользователя) 51 мс (97 мс), как и менее консервативный порог (например, 1 секунда). Это показывает, что даже клиенты с хорошим сетевым подключением по-прежнему страдают от накладных расходов на рукопожатие TLS. Быстрое согласование TLS помогает уменьшить задержку рукопожатия, но мы обнаружили, что использовалось только 30% подключений. Мы предполагаем, что это нижняя граница, но, к сожалению, на основании имеющихся данных мы не можем оценить достижимую верхнюю границу, полученную в результате более широкого внедрения быстрого согласования TLS.
Влияние на использование трафика данных
Использование HTTPS также может оказывать некоторое влияние на трафик данных из-за:
- Данные рукопожатия TLS
- Нам часто не удается оптимизировать кеширование и сжатие прокси в этом процессе.
Таким образом, мы можем разделить его на две части, чтобы обсудить и изучить отдельно.
Накладные расходы на рукопожатие TLS
Влияние накладных расходов на рукопожатие TLS в значительной степени зависит от общего количества пакетов: очевидно, что чем больше общее количество пакетов, тем ниже доля накладных расходов на согласование.
На рисунке выше показано количество пакетов рукопожатия TLS, занимаемых основными веб-сайтами. Мы обнаружили, что большинство подключений TLS не использовались интенсивно, фактически половина этих подключений были рукопожатиями TLS, на которые приходилось более 42% от общего размера пакета. Конечно, есть также некоторые сервисы, которые очень эффективны, они активно используют соединения TLS, такие как Amazon S3, что относительно снижает потребление на этапе согласования. Есть также некоторые службы, которые предпочитают использовать «предварительно открытое» соединение при фактической отправке данных, что маскирует некоторое влияние задержки. Потому что в этом случае, если соединение фактически не используется, накладные расходы TLS будут составлять 100% от общих накладных расходов.
Однако в целом накладные расходы TLS составляют около 5% от общего объема.
прокси в сети
HTTPS предотвратит некоторые меры по оптимизации контента в сети, такие как некоторые прокси-серверы сжатия и кэширования. Чтобы измерить влияние невозможности использования прокси-серверов, авторы проанализировали прокси-серверы HTTP в двух мобильных средах производственного уровня.Transp-ProxyиOptIn-Proxy, Transp-Proxy — это прозрачный прокси, который обслуживает 20 миллионов европейских пользователей и широко используется крупными европейскими операторами. OptIn-Proxy — это явный прокси, который обслуживает более 2000 пользователей в день и также широко используется в европейских странах.
Авторы обсуждают влияние HTTPS как на кэширование, так и на сжатие соответственно.
Что касается кешей, то Transp-Proxy за последние два года показывает около 14,9% попаданий. Для одного экземпляра Transp-Proxy, обслуживающего 3 миллиона подписчиков, это означает экономию до 2 ТБ в день. На самом деле, этот процент попаданий уже является результатом снижения. В 2012 г. его попадание могло достигать 16,8%, а в 2014 г. – всего 13,2%. Результаты OptIn-Proxy аналогичны результатам Transp-Proxy.
Тем не менее, автор также упомянул, что это падение показателя посещаемости вызвано целым рядом факторов, например, быстрой генерацией персонализированного контента, что снижает количество попаданий, или широким использованием HTTPS, снижающим количество попаданий. Но в любом случае, трафик, сэкономленный прокси, все равно очень немалый, а если все перейдут на HTTPS, то нет возможности использовать прокси для экономии трафика. (Я не знаю, есть ли сегодня способ проксировать HTTPS-трафик спустя 3 года?)
Второй аспект — это сжатие, когда сетевые прокси-серверы часто выполняют сжатие без потерь (например, с помощью gzip) и даже повторно кодируют или изменяют размер изображения перед возвратом содержимого пользователю. Эта функция очень полезна, когда общий сетевой трафик ограничен (подумайте о текущем режиме ограничения браузера, очень ли он полезен, когда трафик составляет всего 30 МБ). Журналы Transp-Proxy показывают степень сжатия до 28,5%. Для некоторых активных пользователей такое сжатие может иметь решающее значение, экономя сотни мегабайт трафика каждый месяц.
В целом рядовые пользователи могут не обращать внимания на рост трафика, вызванный исчезновением кэширования и сжатия в HTTPS, но для операторов это относительно очевидная тенденция.
Влияние на срок службы батареи
Использование HTTPS может отрицательно сказаться на сроке службы батареи из-за:
- Операции шифрования и дешифрования требуют дополнительного процессорного времени.
- Накладные расходы на антенну из-за более длительного времени загрузки
Авторы разделили эксперименты на две части: синтетическое содержание и реальное содержание.
синтетический контент
Автор использовал Galaxy S II с измерителем мощности, убавил яркость до минимума и измерял энергопотребление каждые 200 микросекунд. Используйте этот телефон для загрузки композитного контента размером от 1 КБ до 1 МБ через 3G и Wi-Fi. Каждый контент загружается 100 раз с использованием HTTP и HTTPS соответственно. Стоит отметить, что автор собрал curl на Android, чтобы избежать посторонних эффектов.
На приведенном выше графике показано среднее время и потребление батареи для завершения загрузки в различных условиях. Очевидно, что уровень заряда батареи и время загрузки взаимосвязаны. Кроме того, для некоторых больших файлов накладные расходы в случае Wi-Fi значительны (по сравнению с случаем 3G), но причина этого неясна. В целом, помимо разницы во времени загрузки, шифрование в HTTPS практически не влияет на заряд батареи.
реальный контент
Авторы сначала отразили домашнюю страницу CNN на своем собственном сервере и использовали Chrome на Android для загрузки 50 раз с использованием HTTP и HTTPS соответственно. Результат выглядит следующим образом:
Видно, что хоть и есть некоторый оверхед, но он не очень значительный.
Во втором эксперименте авторы воспроизводили 5-12 минут роликов на YouTube. Однако, поскольку клиент и веб-сайт на мобильном телефоне не могут воспроизводить видео, отличные от HTTPS, автор заставляет настольную версию веб-сайта YouTube использовать HTTP. После авторского теста, в случае с Wi-Fi разницы между HTTP и HTTPS почти нет, а вот в случае с 3G прокси в сети сильно влияет на результаты HTTP, есть два видео с использованием питания батареи HTTP потребление по сравнению с HTTPS Результат почти на 25% меньше, а два других видео тоже на 10-20% меньше.
Этот результат вызван двумя видами поведения агента:
1. С одной стороны, прокси ограничивает скорость скачивания для снижения перегрузки сети (это аналогично выбору «Приоритета интернета» при скачивании), а если пользователь отменит и перестанет смотреть видео, это также может снизить влияние на Потребление данных (подумайте, сколько раз мы нажимали на видео, а затем выключали его). Без прокси все видео загружалось бы быстро при входе, после чего сетевое устройство переходило бы в спящий режим. С прокси скорость загрузки медленная и стабильная, и она будет воспроизводиться сразу во время всего процесса воспроизведения видео, поэтому у сетевого устройства нет шансов на отдых, что приведет к большему энергопотреблению.
2. С другой стороны, прокси-сервер вставляет на страницу JavaScript, который переписывает URL-адрес, отправленный на сервер YouTube, для более удобного для мобильных устройств кодирования и качества видео. Для второго и четвертого видео изначально полученыwebmформат видео, ни один из которых не поддерживает жесткое декодирование на нашем мобильном устройстве, поэтому прокси изменил его наmp4формат видео. Преимущества жесткого декодирования компенсируют энергопотребление некоторых сетевых устройств.
В реальных экспериментах довольно сложно контролировать переменные. Поэтому авторы также упомянули, что к этим цифрам следует относиться с недоверием. Если мы пытаемся строго контролировать переменные, мы должны сами создать HTTPS- и HTTP-видеосайт, а источник видео использует разные форматы одного и того же видео для проведения этого эксперимента.
В целом, этот эксперимент все еще говорит нам:
- Зашифрованные операции в HTTPS не оказывают существенного влияния на расход заряда батареи, но прокси-серверы могут существенно сократить срок службы батареи.
- Операторам следует тщательно продумать дизайн своего промежуточного программного обеспечения, а сообществу пора подумать, стоит ли вообще переходить на HTTPS.
Резюме и мнения
Нельзя есть и рыбу, и медвежью лапу
Безопасность и эффективность часто являются двумя сторонами, которые трудно сбалансировать одновременно. Хотя обновления оборудования и технологий в последние годы значительно снизили стоимость использования HTTPS, потребление производительности HTTPS по-прежнему является проблемой, заслуживающей нашего внимания. В то же время в поле зрения постепенно входит HTTP 2.0. Помимо соображений безопасности, его производительность также является темой, заслуживающей нашего внимания.
Но следует сказать, что в домашней сетевой среде, даже при наличии угона некоторых операторов, веб-сайтам по-прежнему необходимо использовать HTTPS для защиты безопасности процесса использования пользователем. Мы также надеемся, что доверенные прокси-серверы могут стать очень важной частью Интернета.