AdGuard 7.7 для Windows: CoreLibs, DNS-over-QUIC и расширенные DNS-настройки
Последний релиз AdGuard для Windows — это такая генеральная работа над ошибками. Наша команда тестировщиков честно пыталась сломать приложение, но всё отлично работает! Впрочем, вы тоже можете попытаться 🙂
В этом случае, пожалуйста, сообщите нам, что именно случилось и как у вас это вышло.
Что изменилось? Появились любопытные расширенные DNS-настройки, добавилась локализация на финский язык и обновились переводы на других языках. Да, в этой версии вы не найдёте новые уникальные функции, так как в ней мы направили энергию на кое-что не менее важное: обновили CoreLibs и DNSLibs, много всего починили и поколдовали над журналом фильтрации, чтобы сделать его удобнее и понятнее для пользователей.
CoreLibs
CoreLibs — это наш основной движок фильтрации, он обновился до новой версии и получил множество изменений и исправлений. В результате наши фильтры стали ещё более гибкими и мощными и могут блокировать гораздо больше.
DNS-over-QUIC
В этой версии мы внесли много исправлений на уровне DNS. В частности, теперь AdGuard поддерживает последнюю версию QUIC. Не припоминаете, что это? Тогда крайне рекомендуем прочитать о протоколе QUIC и узнать, почему DNS-over-QUIC гораздо круче своих предшественников DNS-over-HTTPS и DNS-over-TLS.
Новые расширенные DNS-настройки
В расширенных настройках появился раздел «Действие, применяемое к заблокированным DNS-запросам». В нём можно выбрать тип ответа, если вы запросили DNS-домен, запрещённый правилом DNS-фильтрации. Всего типов три: ответ ошибкой «Refused», ответ ошибкой «NxDomain» или редирект на выбранный домен. Если выбрана последняя опция, все заблокированные DNS-запросы будут перенаправлены на указанный пользователем IPv4- или IPv6-адрес.
Пример: если вы хотите оградить ребёнка от посещения сайта для взрослых, то просто выберите «Редирект на выбранный домен», а в поле «Редирект на выбранный IPv4-адрес» (и «Редирект на выбранный IPv6-адрес») подставьте любой безобидный сайт. Как насчёт нового сезона «Смешариков»?
Но да ладно, вернёмся к нашим б̶а̶р̶а̶ш̶а̶м̶. Ещё поменялись настройки с резервными серверами. В предыдущей версии AdGuard для Windows 7.6.1 была простая опция «Включить DNS Fallback». Теперь пользователи могут не просто включить её, но и выбрать, каким резервным DNS-сервером пользоваться — системным или своим. Кстати, их можно добавить сразу несколько. И наконец, появились DNS-исключения — домены в этом списке будут резолвиться через системный DNS. «Зачем мне это нужно?» — могли подумать вы про себя. Иногда домен обязательно нужно резолвить через DNS по умолчанию (то есть системный). Например, если это домен панели управления роутером. Специально для таких случаев была создана эта настройка.
Напомним, запасной DNS-сервер нужен, чтобы можно было на него переключиться, когда основной сервер или провайдер не отвечает после установленного периода ожидания (оно также настраивается).
Вот и всё. Как всегда, полный список изменений можно посмотреть на GitHub. И будем рады обратной связи: обновляйте приложение и делитесь с нами впечатлениями.
А ещё раз вы дочитали до конца, поделимся с вами секретом — мы собираемся разработать совершенно новый AdGuard для Windows. В планах масштабный редизайн всего приложения! Следите за новостями, и очень скоро вы узнаете про версию 8.0!
AdGuard представляет первый в мире резолвер DNS-over-QUIC
AdGuard DNS — первый публичный резолвер, который использует новый протокол DNS-over-QUIC. Мы невероятно гордимся и рады, что добились такого и можем предоставить нашим пользователям возможность первыми опробовать его в деле. Сейчас мы расскажем вам, что это такое, какие у него есть плюсы и минусы, а главное, как его использовать.
Если вам нужно освежить свои знания о DNS и том, как его использовать для защиты персональных данных в интернете, прочитайте эту статью.
Что такое QUIC?
Чтобы разобраться в тонкостях DNS-over-QUIC, логично сначала понять, что такое QUIC. Так что давайте сделаем один шажок назад, чтобы затем сделать два шага вперёд.
QUIC — это относительно новый транспортный протокол. Проще говоря, он передаёт пакеты информации между серверами или между сервером и клиентом. Есть разные способы сделать это (другие протоколы), вы наверняка слышали о старом добром TCP, который в основном использовался в сети в последние десятилетия.
По сравнению с TCP, у QUIC выше скорость, надёжность и лучше шифрование. Помимо этого, он решает несколько важных проблем, масштабы которых не были очевидны во времена, когда разрабатывался старый стек протоколов.
Head-of-line blocking
Как упоминалось раньше, долгое время мы жили, используя TCP и другие протоколы, работающие поверх него — TLS, SSL, HTTP. Должно быть, эти аббревиатуры по меньшей мере кажутся вам знакомыми, и неудивительно: они существуют уже давно и прекрасно справляются со своей работой. Но есть одна загвоздка: они хорошо работают в практически идеальных условиях, то есть в сетях с высоким качеством связи. Стоит выйти из дома во внешний мир с его LTE и мобильными сетями в целом, как вы неизбежно наткнётесь на слабый сигнал, медленное соединение и что-либо ещё. И даже внедрение современных стандартов вроде 5G не спасёт от неприятностей — в городе вы запросто найдёте место с плохой связью, взять хотя бы лифты.
Годы с этой проблемой, и вот мы уже в стадии принятия, рассматриваем проблемы со связью как нечто естественное — сеть плохая, поэтому страницы загружаются медленно или не загружаются вообще. Но почему? Мы подходим к теме так называемой Head-of-line blocking. По протоколу TCP пакеты данных передаются порциями. Представьте, что ваш браузер отправляет несколько запросов, а сервер возвращает несколько ответов, скомпонованных вместе в определённом порядке. Стоит одному из них потеряться в пути из-за слабого соединения, и карточный домик рассыпается. Остальные пакеты не могут быть обработаны и остаются в очереди, ожидая, пока потерянный пакет будет отправлен вновь.
По протоколу TCP, если один пакет данных потерялся, остальные не могут быть обработаны
Благодаря особенностям реализации, в случае QUIC данные не остаются в очереди, а обрабатываются сразу по их получении. Если первый пакет данных потерялся из-за слабого сигнала, остальные, тем не менее, будут обработаны без задержки.
По протоколу QUIC другие пакеты данных могут быть обработаны, даже если первый потерялся по пути
Миграция соединения
Мы привыкли к тому, что каждое устройство в интернете однозначно определяется его IP-адресом, и это в каком-то смысле верно. Но представьте себе день обычного человека. Давайте даже возьмём меня в качестве примера. Каждое утро я покидаю комфортную зону дома (и его стабильный Wi-Fi) и еду на работу. Я спускаюсь на лифте, и мой телефон переключается с домашнего Wi-Fi на 4G. Его IP-адрес меняется, а все активные подключения разрываются. Я снова открываю браузер, и он вынужден заново устанавливать соединения с сайтом и моим DOH-сервером, работающем на AdGuard Home. Это занимает время, и я быстро теряю терпение. Затем я добираюсь до офиса, подключаюсь к Wi-Fi, и всё заново.
QUIC разработан с учётом всего этого. Когда он используется, ваш телефон беспрепятственно будет переключаться с одного IP-адреса на другой — это называется connection migration («миграция соединения»). Всё устроено более сложно, и на самом деле QUIC позволяет соединениям пережить изменения конечных адресов, а не только IP-адресов (порт тоже меняется).
DNS-over-QUIC
DNS-over-QUIC — это DNS-протокол, который пользуется преимуществами транспортного протокола QUIC и использует его, чтобы передавать DNS-запросы. Сейчас DoQ находится в стадии черновика стандарта, но это не мешает нам экспериментировать с ним и пробовать его использовать.
Почему не DNS-over-HTTPS
Тут сложнее: в будущем DNS-over-HTTPS также получит поддержку QUIC за счёт использования протокола HTTP/3, построенного как раз на нём. Так что вопрос имеет смысл, и правда, зачем?
Есть сразу несколько причин, но все они сводятся к одному факту: HTTP — не транспортный протокол. Он предназначен для разных целей, но в теории может использоваться и как транспортный протокол. С точки зрения приватности, HTTP-протокол только привносит дополнительные риски для передачи DNS-запросов:
Каждая из этих проблем может и должна быть учтена на уровне DNS-over-HTTPS клиента, но не забывайте, что клиентов теперь — великое множество. Это и браузеры, и операционные системы, и сторонний софт. Практически невозможно найти клиентское решение для каждого.
AdGuard DNS-over-QUIC
Мы рады первыми из публичных DNS-резолверов реализовать текущую спецификацию DNS-over-QUIC в наших DNS-серверах. Предлагаем вам первыми её протестировать! Самый простой способ это сделать — использовать одно из наших приложений, где DoQ уже поддерживается: AdGuard для Android или AdGuard для iOS.
Как включить DoQ в AdGuard для Android
Как включить DoQ в AdGuard для iOS
Хотите большего?
Пожалуйста! Вот подборка ссылок, которые пригодятся, если вы хотите по полной использовать все возможности DoQ, а также обладаете определёнными техническими навыками:
dnslookup — простая утилита для выполнения DNS-запросов. Поддерживает все популярные протоколы: DoH, DoT, DoQ, DNSCrypt.
AdGuard Home — хотите свой собственный DoQ-сервер? Не проблема! AdGuard Home получил поддержку DoQ в последнем релизе. Если ваш AdGuard Home работает как публичный сервер, вы можете настроить в нём шифрование.
dnsproxy — AdGuard Home для вас слишком тяжёлый и вам нужен простой forwarder? Используйте dnsproxy — простой DNS-прокси с поддержкой DoH, DoT, DoQ и DNSCrypt.
DnsLibs — хотите встроить DoQ в ваше приложение? Возьмите на заметку эту библиотеку на C++, которую мы используем в продуктах AdGuard.
DNS-фильтрация
Чтобы лучше понимать DNS-фильтрацию, надо сначала ответить на вопрос «Что такое DNS»?
Что такое DNS?
DNS расшифровывается как «Domain name system», или «Система доменных имён». Её цель — переводить имена доменов, понятные человеку, в нечто, что понятно браузерам, т.е. в IP-адреса. Таким образом, каждый раз, когда вы переходите на сайт, ваш браузер посылает запрос на специальный сервер (DNS-сервер). Этот сервер смотрит на имя запрашиваемого домена и отвечает соответствующим IP-адресом. Очень схематично это выглядит так:
Всё то же самое применимо, разумеется, и к приложениям и программам, которые посылают какие-либо веб-запросы, а не только к браузерам.
Как работает DNS-фильтрация?
Когда вы используете одно из приложений AdGuard, поддерживающее DNS-фильтрацию, оно работает как буфер между вашим устройством и DNS-сервером. Все DNS-запросы, которые ваши браузеры и приложения собираются отправить, сначала обрабатываются AdGuard. Если вы используете DNS-сервер, предоставленный по умолчанию вашим интернет-провайдером, ваш DNS-трафик, скорее всего, не зашифрован и уязвим для подслушивания и перехвата. AdGuard зашифрует все ваши DNS-запросы до того, как они будут отправлены, так что никакие злоумышленники не смогут получить доступ к их содержимому. Кроме того, AdGuard может идентифицировать запросы по рекламным, трекинговым и взрослым сайтам и перенаправить их «в никуда» вместо того, чтобы переслать на DNS-сервер. Подробнее об этом позднее.
DNS-фильтрация — это мощный инструмент, который поддерживается всеми основными приложениями AdGuard: AdGuard для Windows, AdGuard для Mac, AdGuard для Android и AdGuard для iOS.
DNS-фильтрация может быть условно разделена на две основные функции: шифрование DNS-трафика и его перенаправление на DNS-сервер, а также блокировка определённых доменов с помощью локальных DNS-фильтров.
DNS-серверы
В мире существуют тысячи DNS-серверов, и все они уникальны по своим свойствам и целям. Большинство просто возвращает IP-адрес запрошенного домена, но некоторые имеют дополнительные функции: они блокируют рекламные, трекинговые, взрослые домены и т.д. Сегодня все крупные DNS-провайдеры поддерживают различные протоколы для шифрования DNS-трафика: DNS-over-HTTPS, DNS-over TLS. AdGuard также предоставляет свой DNS-сервис, и он стал самым первым DNS-провайдером в мире, который добавил поддержку нового и многообещающего протокола шифрования DNS-over-QUIC. AdGuard имеет несколько разных серверов для разных целей. Эта диаграмма иллюстрирует работу блокирующих серверов AdGuard DNS:
Другие DNS-провайдеры могут работать иначе, так что узнайте все подробности перед тем, как делать выбор в пользу того или иного сервера. Вы можете найти список некоторых популярных DNS-провайдеров в этой статье. Все приложения AdGuard, которые поддерживают DNS-функционал, также предоставляют на выбор список проверенных DNS-серверов и даже дают возможность вручную указать любой предпочитаемый вами DNS-сервер.
Локальные DNS-фильтры
Но если полагаться только на DNS-серверы в вопросе фильтрации DNS-трафика, то неизбежны потери в гибкости. Если выбранный сервер блокирует какой-либо домен, вы не сможете на него перейти, пока не переключитесь на другой сервер. С AdGuard же вам даже не обязательно настраивать какой-то конкретный DNS-сервер, чтобы фильтровать DNS-трафик. Все продукты AdGuard позволяют добавлять локальные DNS-фильтры, будь то простые файлы hosts или фильтры, использующие более сложный DNS-синтаксис. Они работают сходным образом с обычными рекламными фильтрами: когда DNS-запрос подходит под одно из правил в активном фильтре, он блокируется. Чтобы быть более точным, перенаправляется «в никуда».
Чтобы получить доступ к DNS-фильтрации в AdGuard для iOS, вам сначала потребуется включить «Расширенный режим» в настройках.
Вы можете добавлять столько собственных DNS-фильтров, сколько захотите. Например, вы можете задействовать DNS-фильтр AdGuard. Он буквально блокирует всё то же самое, что и сервер AdGuard DNS, но в данном случае вы вольны использовать любой другой DNS-сервер. Плюс, при использовании данного метода вы можете добавить больше фильтров или же создать собственные правила-исключения. Всё это было бы невозможно в случае с использованием только DNS-сервера.
Существуют сотни различных DNS-фильтров, вы можете выбрать нужные вам здесь.
Сравнение DNS-фильтрации с сетевой фильтрацией
Мы называем сетевой фильтрацией «обычный» способ, которым самостоятельные приложения AdGuard (кроме браузерных расширений) фильтруют весь сетевой трафик, отсюда и название. Освежить знания о сетевой фильтрации можно, прочитав эту статью.
Во-первых, мы сразу хотим оговориться, что с AdGuard вам не нужно выбирать между ними. Вы всегда можете использовать обычную сетевую фильтрацию и DNS-фильтрацию одновременно. Однако важно понимать разницу между этими двумя подходами. DNS-фильтрация обладает как своими уникальными преимуществами, так и недостатками.
Плюсы DNS-фильтрации:
Недостатки DNS-фильтрации:
Пример разницы между DNS-фильтрацией и сетевой фильтрацией
AdGuard 3.6 для Android: поддержка DNS-over-QUIC и YouTube без рекламы
Встречайте AdGuard 3.6 для Android! С прошлого релиза прошло меньше трёх месяцев, за которые мы успели добавить в наш блокировщик две новые функции: просмотр YouTube без рекламы (наконец-то!) и поддержку DNS-over-QUIC (DoQ).
Мы все страдали от рекламных видеороликов, которые никак нельзя пропустить, перед интересующим нас контентом в приложении YouTube. К счастью, мы нашли решение — теперь буквально два шага отделяют вас от просмотра видео без рекламы. Что касается второй важной функции, DoQ — это новый протокол, который предлагает готовое шифрование и улучшенную производительность.
Просмотр YouTube без рекламы
Из-за технических ограничений операционной системы Android ни один блокировщик не способен убрать рекламу внутри самого приложения YouTube. До этого момента лучшее, что мы могли предложить, было фильтрацией YouTube, когда вы смотрите его в браузере. Безусловно, это не так удобно и прекрасно, даже можно не сравнивать. Но теперь мы нашли альтернативу, которая приближает нас к опыту просмотра в приложени и позволяет обходить накладываемые Android ограничения.
Свершилось, теперь за пару кликов вы можете смотреть видео в приложении YouTube без назойливых рекламных роликов. Вот что для этого нужно сделать:
Следуйте этой инструкции, чтобы смотреть YouTube без рекламы
Вот и всё. Откроетcя новое окошко с видео, и вы сможете посмотреть его без рекламы.
Поддержка DNS-over-QUIC
Много букв! Если вы не представляете, что они значат, ничего страшного. Первое, что стоит знать о DoQ — это новый протокол шифрования. Сама концепция не нова, но практическое её воплощение только появилось. AdGuard представил самые первые публичные DNS-серверы, которые поддерживают DoQ!
Возможно, вы уже слышали о протоколах шифрования DNS, наиболее распространённые из них — DNS-over-HTTPS и DNS-over-TLS (DoH и DoT соответственно). Что же делает DoQ особенным? На самом деле, причин много: готовое решение шифрования, сокращение времени подключения и улучшенная производительность при потере пакетов данных. Если вы хотите узнать больше про новый протокол, почитайте нашу статью, целиком посвящённую DNS-over-QUIC.
Чтобы настроить DoQ в AdGuard для Android, выполните следующие шаги:
Теперь AdGuard для Android поддерживает DNS-over-QUIC
Как видите, функция пока ещё экспериментальная, AdGuard для Android – это одна из её первых реализаций с открытым исходным кодом (недавно мы также добавили эту функцию в AdGuard Home). Тем не менее, она исправно работает, и мы призываем вас её опробовать!
На этом всё. Полный список изменений вы можете посмотреть на GitHub, и как обычно, ждём ваших комментариев о новой версии AdGuard — в блоге, соцсетях или где вам удобно.
QUIC, TLS 1.3, DNS-over-HTTPS, далее везде
Хабр, привет! Это транскрипция доклада Артема ximaera Гавриченкова, прочитанного им на BackendConf 2018 в рамках прошедшего фестиваля РИТ++.
В названии доклада приведён длинный список протоколов, мы по нему пройдемся постепенно, но давайте начнем с того, чего в названии нет.
Это (под катом) заголовок одного из блогов, в интернете вы могли таких заголовков видеть очень много. В том посте написано, что HTTP/2 — это не какое-то отдаленное будущее, это наше настоящее; это современный протокол, разработанный Google и сотнями профессионалов из многих продвинутых компаний, выпущенный IETF в качестве RFC в далеком 2015 году, то есть уже 3 года назад.
Стандарты IETF воспринимаются индустрией, как такие железобетонные документы, как могильная плита, фактически.
Планируется, что они определяют развитие интернета и учитывают все возможные сценарии использования. То есть, если у нас была старая версия протокола, а потом появилась новая, то она точно сохраняет совместимость со всеми предыдущими юзкейсами и дополнительно решает кучу проблем, оптимизирует работу и так далее.
HTTP/2 должен был быть адаптирован для продвинутого веба, готов к использованию в современных сервисах и приложениях, фактически быть drop-in replacement для старых версий протокола HTTP. Он должен был повышать производительность сайта, параллельно снижая нагрузку на бэкенд.
Даже SEO-шники говорили, что им нужен HTTP/2.
И его, вроде как, было очень просто поддержать. В частности, Нил Крейг из BBC писал в своем блоге, что достаточно «просто включить» его на сервере. Еще можно найти множество презентаций, где написано, что HTTP/2 включается следующим образом: если у вас Nginx, то можно в одном месте поправить конфигурацию; если нет HTTPS, нужно ещё дополнительно поставить сертификат; но, в принципе, это вопрос одного токена в конфигурационном файле.
И, естественно, после того, как вы пропишете этот токен, вы сразу начинаете получать бонусы от повышения производительности, новых доступных фич, возможностей – в общем, всё становится замечательно.
Ссылки со слайда:
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2. www.cloudflare.com/website-optimization/http2
Дальнейшая история основана на реальных событиях. Компания имеет некоторый онлайн-сервис, обрабатывающий порядка 500-1000 HTTP-запросов в секунду. Сервис этот находится под DDoS-защитой Cloudflare.
Существует множество бенчмарков, которые подтверждают, что переход на HTTP/2 снижает нагрузку на сервер вследствие того, что при переходе на HTTP/2 браузер устанавливает уже не 7 соединений, а по плану вообще одно. Ожидалось, что при переходе на HTTP/2 и памяти используемой станет меньше, и процессор будет менее нагружен.
Плюс к этому в блоге Cloudflare и на сайте Cloudflare предлагается включить HTTP/2 просто одним кликом. Вопрос: почему бы так не сделать?
1 февраля 2018 года компания включает HTTP/2 этой самой кнопочкой в Cloudflare, и на локальном Nginx тоже его включает. Месяц собираются данные. 1-го марта происходит замер потребляемых ресурсов, и потом sysops’ы смотрят число запросов в логах, которые приходят по HTTP/2 на стоящий за Cloudflare сервер. На следующем слайде будет процент запросов, пришедших на сервер по HTTP/2. Поднимите руки, кто знает, какой будет этот процент?
— Ноль. По какой причине?
Cloudflare, а так же другие сервисы по защите от атак, MSSP и облачные сервисы, работают в режиме reverse proxy. Если в нормальной ситуации браузер напрямую соединяется с вашим Nginx, то есть соединение идет напрямую от браузера до вашего HTTP-сервера, то вы можете использовать тот протокол, который браузер поддерживает.
В случае, если между браузером и вашим сервером стоит облако, пришедшее TCP-соединение терминируется в облаке, TLS тоже там терминируется, и HTTP-запрос сначала попадает на облако, далее облако фактически обрабатывает этот запрос.
У облака есть собственный HTTP-сервер, в большинстве случаев тот же самый Nginx, в редких случаях это «самописный» сервер. Этот сервер парсит запрос, как-то его обрабатывает, консультируется с кэшами и, в конечном итоге, формирует новый запрос и отправляет его уже на ваш сервер по тому протоколу, который он поддерживает.
Все существующие облака, заявляющие о поддержке HTTP/2, поддерживают HTTP/2 на стороне, смотрящей в браузер. Но не поддерживают его на стороне, смотрящей к вам.
Простой и не совсем правильный ответ: «Потому что в большинстве случаев у них развёрнут Nginx, а Nginx не умеет ходить по HTTP/2 к апстриму». Окей, хорошо, это ответ правильный, но не полный.
Полный ответ нам дают инженеры Cloudflare. Дело в том, что в фокусе спецификации HTTP/2, написанной и выпущенной в 2015 году, было повышение производительности браузера на специфичных, например, для Google сценариях использования.
Google использует собственные технологии, не использует reverse proxy перед своими production-серверами, поэтому о reverse proxy никто не подумал, и именно поэтому HTTP/2 от облака до апстрима не используется. Там, на самом деле, и профита мало, потому что в режиме reverse proxy, из того, что описано в протоколе HTTP/2, например, Server Push не поддерживается, потому что непонятно, как он должен работать, если у нас pipelining.
То, что HTTP/2 экономит соединения – это круто, но reverse proxy сам по себе их экономит, потому что он не открывает по одному соединению на каждого пользователя. Смысла поддерживать здесь HTTP/2 мало, а накладные расходы и проблемы связанные с этим – большие.
Что важно: reverse proxy – это технология, которая начала активно использоваться порядка 13 лет назад. То есть это технология середины 2000 годов: я еще в школу ходил, а она уже использовалась. В стандарте, выпущенном в 2015 году, она не упоминается, не поддерживается и работа по ее поддержке, на данный момент, в рабочей группе httpbis в IETF не ведется.
Это один пример тех вопросов, которые возникают, когда люди начинают внедрять HTTP/2. На самом деле, когда разговариваешь с людьми, которые развернули и имеют уже какой-то опыт работы с ним, постоянно слышишь примерно одни и те же слова.
Лучше всего их сформулировал Максим Матюхин из Badoo в посте на Хабре, где он рассказывал о том, как работает HTTP/2 Server Push. Он написал, что его сильно удивило, насколько отличается взаимодействие конкретно этой функциональности с браузерами, ведь он думал, что это полностью отработанная фича, готовая к использованию в продакшене. Эту фразу в отношении HTTP/2 я слышал уже очень много раз: думали, что это протокол, который «drop-in replacement» – то есть включаешь его, и все нормально – почему же на практике всё так сложно, откуда возникают все эти проблемы и недоработки?
Исторически, в стародавние времена, архитектура интернета выглядела примерно следующим образом. Зеленого прямоугольника в какой-то момент не было, но потом он появился.
Протоколы использовались следующие: так как мы говорим про Интернет, а не про локальную сеть, то на нижнем уровне начинаем с протокола IPv4. Выше него использовался протокол TCP – или UDP, но для 90% случаев (так как 80-90% трафика в интернете – это Web) дальше был TCP, – затем SSL (который потом заменили на TLS), а выше уже был гипертекстовый протокол HTTP. Постепенно сложилась ситуация, что, по плану, к 2020 году архитектура интернета должна была в корне поменяться.
Протокол IPv6 с нами уже очень давно. TLS недавно обновили, мы еще обсудим, как это происходило. И протокол HTTP/2 тоже обновился.
У замечательного отечественного фантаста Вадима Панова в цикле «Анклавы» была такая прекрасная фраза: «Вы ждали будущего. Вы хотели будущего? Оно наступило. Вы его не хотели? Оно все равно наступило». Единственное, что осталось практически нетронутым — по состоянию на пару лет назад – это протокол TCP.
Люди, которые занимаются дизайном интернета, не могли пройти мимо такой вопиющей несправедливости и решили протокол TCP выкинуть тоже.
Ладно, это, конечно же, шутка. Проблема не просто в том, что протокол слишком старый. В протоколе TCP есть недостатки. Особенно многих беспокоило, что протокол HTTP/2 уже написан, стандарт 2015 года уже внедряется, но вот конкретно с TCP он работает не всегда хорошо, и неплохо бы под него подложить какой-нибудь другой транспорт, более подходящий для того, что когда-то называлось SPDY, когда пошли те разговоры, а потом и для HTTP/2.
Протокол решили назвать QUIC. QUIC – это ныне разрабатываемый протокол для транспорта. Он основан на UDP, то есть это датаграммный протокол. Первый черновик стандарта был выпущен в июле 2016 года, и текущая версия черновика…
[Докладчик проверяет почту на телефоне]
На данный момент QUIC еще не является стандартом — его активно пишут. Если я не ошибаюсь – я не стал писать на слайде, потому что боялся ошибиться – но на IETF 101 в Лондоне говорилось, что где-то к ноябрю 2018 года планируется выпустить его уже как окончательный документ. Именно сам стандарт QUIC, потому что в рабочей группе документов ещё восемь штук.
То есть стандарта еще нет, но уже идет активный хайп. Я перечислил только те конференции, где я был за последние полгода, где про QUIC была хотя бы одна презентация. О том, «какой он крутой», «как нам нужно на него переходить», «что делать операторам», «перестаньте фильтровать UDP — через него сейчас QUIC будет работать». Весь этот хайп длится уже достаточно давно — я уже видел много статей, которые призывали игровую индустрию переходить на QUIC вместо обычного UDP.
Ссылки со слайда:
1. conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop
В ноябре 2017 года в рассылке рабочей группы QUIC появляется вот такая ссылка: верхняя на whitepaper, а нижняя для тех, кому тяжело читать whitepaper — это ссылка на блог APNIC с кратким содержанием.
Исследователи решили сравнить производительность TCP и QUIC в текущем его виде. Для сравнения, чтобы не разбираться с тем, кто в чем виноват и где может быть вина Windows, со стороны клиента взяли Chrome под Ubuntu, а также взяли 2 мобильных устройства: какой-то Nexus и какой-то Samsung (прим. ред.: Nexus 6 и MotoG) с Android 4 и 6 версий, и в них тоже запустили Chrome.
Со стороны сервера они поставили Apache для того, чтобы видеть, как работает TCP-сервер, а для того, чтобы отслеживать QUIC, они выдрали кусок опенсорсного кода, который имеется в проекте Chromium. Результаты benchmark’ов показали, что, хотя во всех тепличных условиях QUIC действительно выигрывает у TCP, есть некоторые краеугольные кейсы, по которым он проигрывает.
Например, реализация QUIC от Google работает существенно хуже TCP, если в сети происходит packet reordering, то есть пакеты прилетают не в том порядке, в котором были отправлены сервером. В 2017-2018 годах, в век мобильных и беспроводных сетей, вообще нет никакой гарантии, что пакет в принципе долетит, не говоря уже о том, в каком порядке. QUIC отлично работает на проводной сети, но кто сейчас пользуется проводной сетью?
Вообще, разработчики этого кода в Google, видимо, очень не любят мобилки.
QUIC – это протокол, который реализован поверх UDP в user space. И на мобильных устройствах так же в user space. По результатам измерений, в нормальной ситуации, то есть при работе через беспроводную сеть, реализация протокола QUIC 58% времени проводит в Android в состоянии «Application Limited». Что это за состояние? Это состояние, когда мы какие-то данные отправили и ждем подтверждения. Для сравнения, на десктопах была цифра около 7%.
Всего 2 кейса использования: первый – беспроводная сеть, второй – мобильное устройство; и QUIC работает либо как TCP, либо существенно хуже. Естественно, это оказалось в рабочей группе IETF, посвященной QUIC и, естественно, на это отреагировал Google. Реакция Google была следующая:
mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE
Ну, мы посмеялись, но на самом деле это абсолютно логично.
Почему? Потому что дизайн QUIC – хотя мы говорим уже о внедрении в production, но – на самом деле дичайший эксперимент.
Вот, скажем, семиуровневая модель ISO/OSI. Кто ее помнит здесь? Помните уровни: физический, канальный, сетевой, транспортный, какая-то чушь, какой-то бред и прикладной, да?
Да, оно было разработано очень давно, и как-то мы жили с этой уровневой моделью. QUIC – это эксперимент по устранению самой по себе уровневой системы сети. Он объединяет в себе шифрование, транcпорт, надежную доставку данных. Все это не в уровневой структуре, а в комбайне, где каждый компонент имеет доступ к API других компонентов.
Цитируя одного из дизайнеров протокола QUIC Кристиана Гюитема: «Одно из главных преимуществ QUIC с архитектурной точки зрения – это отсутствие уровневой структуры». У нас есть и acknowledgement, и flow control, и шифрование, и вся криптография, – все это полностью в одном транспорте, и наши транспортные инновации подразумевают доступ всего этого напрямую к сетевому API, поэтому уровневую архитектуру в QUIC’е мы не хотим.
Разговор в рабочей группе об этом пошел из-за того, что в начале марта другой дизайнер протокола QUIC, а именно Эрик Рескорла, решил предложить на обсуждение вариант, в котором из QUIC убирается все шифрование, вообще. Остается только транспортная функция, которая работает поверх DTLS. DTLS, в свою очередь, – это TLS поверх UDP, в сумме получается: QUIC поверх TLS поверх UDP.
Откуда возникло такое предложение? Кстати, Рескорла написал большой документ, но вовсе не для того, чтобы это стало стандартом — это был предмет для обсуждения потому, что в процессе дизайна архитектуры QUIC, в процессе тестирования интероперабельности и реализации, возникло очень много проблем. В основном, связанных с «потоком 0».
Что такое «поток 0» в QUIC? Это такая же идея, как и в HTTP/2: у нас есть одно соединение, внутри него у нас есть несколько мультиплексируемых потоков. По дизайну QUIC, напоминаю, шифрование обеспечивается тем же протоколом. Сделано это было следующим образом: открывается «магический» поток номер 0, который отвечает за установку соединения, рукопожатие и шифрование, после чего этот поток 0 шифруется и все остальные шифруются тоже. С этим возникло достаточно много проблем, они перечислены в списке рассылки, там 10 пунктов, я не буду на каждом останавливаться. Выделю только один, который мне очень нравится.
www.ietf.org/mail-archive/web/quic/current/msg03498.html
Проблема, связанная с потоком 0, – одна из – состоит в том, что в случае, если у нас идет потеря пакетов, нам нужно их перепосылать. А при этом, например, на стороне сервера соединение уже может быть отмечено, как шифрованное, а потерянный пакет относится ещё ко времени, когда оно было незашифровано. В этом случае при перепосылке реализация может случайно шифровать пакеты.
Случайно шифровать пакеты.
Это довольно сложно прокомментировать, кроме того, чтобы рассказать, как это все на самом деле дизайнится. В разработке QUIC фактически используется эрзац-agile-подход. То есть не то, чтобы кто-то написал железобетонный стандарт, который через пару итераций можно официально выпустить. Нет.
Работа происходит следующим образом:
1. Запускается черновик стандарта, например, номер 5;
2. В списках рассылки, а также на IETF-встречах – три штуки в год — проходит обсуждение, потом на хакатонах проходит реализация, interop testing, собирается обратная связь;
3. Google внедряет какие-то из изменений в Chrome, в собственной инфраструктуре, анализирует последствия и далее счетчик инкрементируется и появляется стандарт 6.
Сейчас, напоминаю, 12 версия.
Прим. ред.: по состоянию на 10 июля 2018 г. уже 13-я.
Во-первых, минусы мы только что увидели, но есть и плюсы. В этом процессе, на самом деле, можно участвовать. Feedback собирается со всех вовлеченных сторон: если вы занимаетесь gaming’ом, если вы думаете, что вы в игровой индустрии можете просто взять и поменять UDP, поставить вместо него QUIC, и все будет работать – нет, не будет. Но на данный момент вы можете на это повлиять, с этим можно как-то работать.
И это, на самом деле, общая история. Feedback от вас ожидается, все хотят его видеть.
Google разрабатывает протокол, в него какие-то идеи вкладывает – для своих целей. Компании, которые занимаются другими вещами (если это не совсем типичные Web, gaming или мобильные приложения, SEO то же самое), они не могут по умолчанию рассчитывать, что протокол будет учитывать их интересы: не только потому, что это никого не интересует, а потому, что никто просто не знает про эти интересы.
Это, кстати, явка с повинной. Конечно же, вопрос ко мне, почему мы, как Qrator Labs, в частности, не участвовали в разработке протокола HTTP/2 и не сказали никому про reverse proxy. Но те же Cloudflare и Nginx тоже там не участвовали.
Пока в этом не участвует индустрия, разработкой занимаются Google, Facebook, какие-то еще компании и академики. Чтобы вы знали, в около-IETF’ной тусовке слово «академик» – оно, скажем так, не похвальное. Оно звучит наподобие эпитетов «шизофреник» и «ипохондрик». Люди часто приходят без каких-либо практических целей, без понимания реальных задач, но вписываются туда, потому что так проще на докторскую диссертацию наработать.
В этом всём, конечно, нужно участвовать и вариантов других нет.
Возвращаясь к QUIC: итак, протокол реализован в user space, на мобильных устройствах существует… Бла-бла. «Реализован в user space». Давайте поговорим об этом.
Как у нас вообще был устроен транспорт до того, как начали придумывать QUIC? Как он устроен сейчас в продакшене? Есть протокол TCP, если мы говорим про Web.
В протоколе TCP есть такая штука, как тройное рукопожатие: SYN, SYN/ACK, ACK. Оно нужно для целого ряда вещей: чтобы не позволять использовать сервер для атак на других, чтобы успешнее фильтровать определенные атаки на протокол TCP, такие, как SYN-флуд. Только после того, как 3 сегмента тройного рукопожатия прошли, у нас начинается отправка данных.
При этом тут 4 действия, 3 из которых происходят в ядре, происходят они достаточно эффективно, а в user space попадают уже данные, когда соединение установлено.
В ситуации с QUIC всё это счастье – в юзерспейсе. Тут звездочка стоит, потому что там терминология не совсем «SYN, SYN/ACK», но, по сути, это тот же самый хендшейк, только переехавший полностью в user space. Если летит 20 Гбит/с флуда и раньше в TCP их можно было обработать в ядре SYN-куками, то теперь их нужно обрабатывать в user space, так как они пролетают все ядро и через вcе context switch’и. И там их нужно как-то поддерживать.
Почему сделано так? Почему QUIC – это протокол user space’овый? Хотя транспортный, казалось бы, самое место ему где-то на системном уровне.
Потому что, опять же, в этом интерес Google и других участников рабочей группы. Они хотят видеть новый протокол внедренным, они не хотят ждать, пока все операционные системы в округе обновятся. Если он реализован в user space, его можно использовать (в частности, в браузере, но не только) уже сейчас.
То, что нужно будет потратить очень много ресурсов на стороне сервера, для Google – не проблема. Где-то было хорошее высказывание о том, что для решения большинства проблем с производительностью на бэкенде современного интернета нужно у Google просто половину серверов конфисковать (а лучше три четверти). Что не лишено какого-то здравого смысла, потому что Google, действительно, на такие мелочи не разменивается.
www.ietf.org/mail-archive/web/quic/current/msg03736.html
На экране буквальная цитата из рассылки QUIC, где проходило обсуждение как раз о том, что протокол планируется к реализации в user space. Это буквальная цитата: «Мы хотим деплоить QUIC на любую машину без поддержки операционной системы. Если у кого будут проблемы с производительностью, то они унесут это все в ядро». QUIC уже настолько развесистый, что уносить это в ядро с шифрованием и со всем остальным уже страшновато, но рабочая группа на эту тему тоже особо не запаривается.
Причем почему этот подход используется на стороне клиента – я могу понять. Но тот же подход используется на стороне сервера. Теоретически, в этом случае QUIC действительно стоило бы уносить в ядро, но, опять же, работа над этим не ведется, а когда она будет закончена, мы уже в лучшем случае все седыми будем, и я не планирую жить вечно. И когда это произойдет – не очень понятно.
Говоря про ядро Linux, нельзя не упомянуть, что одним из главных смыслов существования QUIC было то, что он реализован поверх легковесного протокола UDP, и благодаря этому работает более эффективно, более быстро… и вообще зачем тогда нам TCP, такой большой и громоздкий.
vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf
Тут представлена другая ссылка на бенчмарк. Выясняется, что отправка UDP-датаграмм в Linux дороже, чем отправка TCP-потока, причем существенно дороже, заметно дороже. Там есть 2 главных момента (то есть много моментов, но только два главных):
1. Поиск по таблице маршрутизации занимает больше времени в случае UDP-датаграммы;
2. Штука под названием «large segment offload». В TCP мы большой поток данных можем просто сгрузить в передачу, не обязаны его разбивать по сегментам на CPU, в то время как в UDP нам нужно подготовить каждую датаграмму, у нас нет потока. В данный момент разработчики ядра думают, что с этим делать, но, по большому счету, на данный момент, TCP работает на посылке больших данных, не влезающих в один пакет, эффективнее, чем UDP, на котором основан QUIC.
www.ietf.org/mail-archive/web/quic/current/msg03720.html
Вот это опять же цитата сотрудника Google, я, в частности, тоже задавал ему этот вопрос. Ведь мы можем просто попытаться обвинить Linux, сказать, что под Windows, может быть, не так все плохо, но нет. Утверждается, что на любой платформе, на которой Google деплоил QUIC, есть проблема с повышенной стоимостью (с точки зрения центрального процессора) отправки UDP-пакета против TCP-потока. То есть это не просто Linux такой, а это общий подход.
Что приводит нас к одной простой мысли.
Хватит говорить про QUIC. Достаточно. Простая идея, которую нужно отсюда вынести – это то, что перед внедрением любого нового протокола вместо старого: HTTP/2 против HTTP/1.1, QUIC вместо TCP, шифрование DNS, IPv6 вместо IPv4… первое, что нужно сделать, перед принятием решения и выкладкой на production – это, естественно, benchmarking.
Не верьте никому, кто говорит, что протокол «можно просто поменять/включить/нажать кнопку» – нет! Никогда такого не будет – и не было никогда, и не будет в будущем, и никто такое не гарантирует.
Поэтому только бенчмарк, и, естественно, что если вы этого не сделаете, а просто развернете что-нибудь, то, конечно, гарантию качественной работы вам никто не предоставит.
Кстати, про IPv6. Дело в том, что во времена IPv6, когда он разрабатывался, протоколы разрабатывались как-то более прямолинейно, то бишь без agile-технологий. Но их адаптация в интернете всё равно заняла очень большое существенное время. И, на данный момент, все еще продолжается, и все еще висит на уровне 10-20% в случае IPv6. Причем в зависимости от страны, потому что в России еще ниже.
На пути внедрения IPv6 было решено очень много проблем. Кто знает, что такое «Happy Eyeballs»? В общем, было очень много проблем, связанных с IPv6, причём таких, когда жаловались живые пользователи. Скажем, ты закрываешь ноутбук, выходишь из дома, где у тебя есть IPv6, приходишь в кафе, где IPv6 нет, открываешь лэптоп – ничего не работает, потому что кэши браузера и операционной системы – все это продолжает смотреть в IPv6, а локальной связности нет.
Был придуман подход под названием «Happy Eyeballs» (тоже являющийся стандартом, выпущенным IETF): если в течении 0,3 с мы не нашли IPv6-связности, не смогли соединиться, мы откатываемся на IPv4.
Костыль, но работает, вроде бы, почти всегда, но! Постоянно возникают мистические проблемы с реализацией. В частности, одна из самых популярных проблем почему-то была почему-то с iPad, которые из IPv6 в IPv4 и обратно переключались существенно медленнее, чем за 0,3 секунды: около 1 секунды – а то и 1 минуты.
Даже в какой-то момент возникло безумное предложение на IETF 99 в Праге: «а давайте Happy Eyeballs будет в каждой сети по syslog’у на централизованный сервер, если проблемы, – что-нибудь отправлять». Собирать syslog со всех подключенных устройств – никто, конечно, на это не согласился. Но это показатель того, что проблем достаточно много.
Другие проблемы – это борьба со всякими злонамеренными активностями, потому что локальная сеть в IPv6 – это /64 и очень много адресов, которые атакующий может начать перебирать, защите нужно их вовремя агрегировать, и все такое. Этим нужно как-то заниматься, это все должно быть реализовано.
В результате мы все равно получили проблемы с внедрением, которые не только выражаются в том, что кто-то IPv6 медленно внедряет. Нет, его начали отключать обратно. Обратно переходить в IPv4. Потому что и без проблем тяжело было обосновать менеджменту преимущества перехода, но если после включения ещё и пользователи начали жаловаться — сразу всё. Это такой пример, когда даже протокол, который разработан был с видом на внедрение, всё равно вызывает дичайшие проблемы с внедрением, которые выражаются в головомойке техническому департаменту.
Представьте, что произойдет при внедрении протоколов, которые не были рассчитаны на широкомасштабное внедрение в соответствующих сценариях использования.
blog.apnic.net/2018/02/26/peak-dnssec
Другой пример на эту тему – DNSSEC. Я не буду просить вас поднять руки, чтобы узнать, у кого оно есть, потому что знаю, что ни у кого нет.
Развёртывание IPv6, с одной стороны, развивается, с другой стороны, с ним есть проблемы, но оно хотя бы идет. Начиная с конца прошлого года, внедрение DNSSEC в мире замедлилось и пошло в обратном направлении.
На этом графике мы видим ежедневное количество интернет-пользователей (по замерам APNIC Labs), использующих резолверы, которые валидируют DNSSEC. Здесь очень четко виден медвежий тренд: вот он, стартует после последнего пика, и этот пик – октябрь 2016 г.
У DNSSEC есть цель, есть правильные задачи, но его развертывание фактически остановилось и пошел какой-то обратный процесс, и еще предстоит расследовать, откуда этот процесс взялся.
datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01
Вообще с DNS очень много проблем. В рабочей группе IETF dnsop сейчас 3 председателя, 15 черновиков, что называется, «в полете»: готовятся к выходу как RFC.
DNS, в частности, научились передавать поверх всего. Поверх TCP он работал давно (но еще нужно людям показать, как это правильно делать). Теперь его начали пускать поверх TLS, поверх HTTPS, поверх QUIC.
Все это выглядело совершенно замечательно, пока люди не начали это реализовывать, и у них не начало болеть в пятой точке. В марте 2017 г. разработчики OpenDNS привезли на IETF презентацию под названием «DNS Camel», или «верблюд DNS». Презентация сводится к следующей мысли: насколько еще мы можем нагрузить этого верблюда (aka протокол DNS), прежде чем очередная хворостинка сломает ему хребет?
Это общий подход к тому, как мы видим сейчас дизайн. Фичи добавляются, фич очень много, они друг с другом интерферируют по-разному. И не всегда предсказуемым образом, и не всегда авторы реализации понимают все возможные точки интерференции. Внедрение каждой такой новой фичи, реализация, внедрение в production – добавляют набор потенциальных точек отказа в каждом месте, где происходит такая интерференция. Без бенчмарка, без мониторинга – никуда.
Почему важно участвовать во всем этом процессе? Потому что стандарт IETF – «RFC» – это все-таки стандарт. Есть вот такая хорошая статистика: сроки разработки различных версий протоколов шифрования SSL и TLS.
Обратите внимание, что версионирование SSL начинается с номера 2, потому что версии 0.9 и 1.0 никогда не были выпущены в production, они были более дырявыми, чем Netscape мог позволить себе выпустить. Поэтому история началась с протокола SSL 2.0, который разрабатывался год. Потом SSL 3.0 разрабатывался ещё один год.
Затем TLS 1.0 разрабатывался 3 года; версия 1.1 – 7 лет; 1.2 разрабатывался только 2 года, потому что там не такие большие изменения были; но последняя версия, которая была выпущена в марте этого года – 27-й черновик, кстати – разрабатывалась 10 лет.
В соответствующей рабочей группе в определенный момент на эту тему была большая паника, потому что выяснилось, что TLS 1.3 ломает очень много use case’ов, в частности, в финансовых организациях, с их мониторингом и файрволлами. Но изменить это, придя к осознанию уже на стадии восемнадцатого черновика, не смогли даже такие крупные компании, как U.S. Bank. Они ничего не успели с этим сделать, потому что, когда ты приходишь на вечеринку в момент, когда всем уже раздают счет, ты не можешь ожидать, что к твоему предложению продолжить веселье отнесутся с пониманием.
Поэтому, если в каком-то протоколе – это опять вопрос к обратной связи – есть/будут/появляются фичи, которые вам не подходят, единственным вариантом является вовремя это отследить и вовремя в это вмешаться, потому что в противном случае оно так и будет выпущено, и придется строить костыли вокруг этого.
Здесь на слайде, собственно, три главных вывода из всего этого процесса.
Первый: как я говорил, внедрение нового протокола – это не просто в конфигурации «что-то подкрутить». Это расписанный план внедрения, оценка целесообразности с обязательными бенчмарками, как в реальности это все себя поведет.
Пункт номер два: протоколы не инопланетянами разрабатываются, они не даны нам свыше, в этом процессе можно и нужно участвовать, потому что за вас никто ваши юзкейсы продвигать не будет.
И третье, действительно: фидбэк нужен. Самое главное, что тот же Google, он не злой, он просто преследует свои собственные цели, у него нет задачи разрабатывать протокол для вас и за вас, это можете сделать только вы.
Поэтому, в общем случае, внедрение чего-то нового взамен чего-то старого, несмотря на количество хвалебных статей в блогах, начинается с того, что необходимо вложиться не просто в деплоймент, а в процесс дизайна протокола, Посмотреть там, как оно работает, и только после этого принимать взвешенное решение.
