Причины и уменьшение задержки DNS.

Поскольку веб-страницы становятся более сложными, ссылаясь на ресурсы из множества доменов, поиск DNS может стать существенным узким местом в процессе просмотра веб страниц. Всякий раз, когда клиенту необходимо запросить распознаватель DNS по сети, задержка может быть значительной, в зависимости от близости и количества серверов имён, которые должен запрашивать распознаватель (редко более 2, но это может произойти). В качестве примера на следующем снимке экрана показаны временные интервалы, сообщаемые веб-инструментом измерения производительности Page Speed.

Каждая строка представляет ресурс, на который ссылается страница; черные сегменты указывают на поиск DNS. На этой странице за первые 11 секунд загрузки страницы выполнено 13 поисков. Хотя несколько поисков выполняются параллельно, на снимке экрана показано, что требуется 5 последовательных поисков, что составляет несколько секунд от общего времени загрузки страницы в 11 секунд.

Задержка DNS состоит из двух компонентов:

• Задержка между клиентом (пользователем) и сервером разрешения DNS. В большинстве случаев это происходит в основном из-за ограничений обычного времени прохождения сигнала в обоих направлениях в сетевых системах: географическое расстояние между клиентскими и серверными компьютерами; перегрузка сети; потеря пакета и длительные задержки повторной передачи (в среднем одна секунда); перегруженные серверы, атаки типа «отказ в обслуживании» и т. д.
• Задержка между разрешающими серверами и другими серверами имён. Этот источник задержки обусловлен, прежде всего, следующими факторами:
• Пропуск кеша. Если ответ не может быть обработан из кэша распознавателя, но требует рекурсивного запроса других серверов имен, дополнительная задержка в сети является значительной, особенно если авторитетные серверы географически удалены.
• Если преобразователи DNS перегружены, они должны ставить в очередь запросы и ответы на разрешение DNS и могут начинать отбрасывать и повторно передавать пакеты.
• Вредоносный трафик. Даже если служба DNS чрезмерно обеспечена, трафик DoS может привести к чрезмерной нагрузке на серверы. Точно так же атаки типа Kaminsky могут включать в себя наполнение распознавателей запросами, которые гарантированно обходят кеш и требуют исходящих запросов на разрешение.

Мы полагаем, что фактор пропуска кэша является основной причиной задержки DNS, и обсудим это подробнее ниже.

Пропуск кеша

Даже если распознаватель имеет мощные локальные ресурсы, трудно избежать фундаментальных задержек, связанных с общением с удаленными серверами имен. Другими словами, при условии, что распознаватель обеспечен достаточно хорошо, так что попадание в кэш занимает нулевое время на стороне сервера, потери в кеше остаются очень большими с точки зрения задержки. Чтобы справиться с пропуском, распознаватель должен общаться хотя бы с одним, но часто с двумя или более внешними серверами имен. Используя веб-сканер Googlebot, мы наблюдали среднее время разрешения 130 мс для отвечающих серверов имен. Но порядка 4-6% запросов просто теряют время ожидания из-за потери пакетов UDP и недоступности серверов. Если принять во внимание сбои, такие как потеря пакетов, недействительные серверы имен, ошибки конфигурации DNS и т. д., Фактическое среднее время сквозного разрешения составляет 300-400 мс. Тем не менее, есть высокая дисперсия и длинный хвост.

Несмотря на то, что частота пропусков кеша может отличаться на разных DNS-серверах, пропуски кеша принципиально трудно избежать по следующим причинам:

• Размер и рост интернета. Проще говоря, по мере роста Интернета, как за счет добавления новых пользователей, так и новых сайтов, большая часть контента представляет незначительный интерес. Хотя несколько сайтов (и, следовательно, DNS-имена) очень популярны, большинство из них представляют интерес лишь для нескольких пользователей и к ним редко обращаются; поэтому большинство запросов приводят к отсутствию кэша.
• Низкие значения времени жизни (TTL). Тенденция к снижению значений DNS TTL означает, что разрешения требуют более частого выполнения поиска.
• Изоляция кеша. DNS-серверы обычно развёртываются за балансировщиками нагрузки, которые произвольно назначают запросы различным машинам. Это приводит к тому, что каждый отдельный сервер поддерживает отдельный кэш, и не может повторно использовать кэшированные разрешения из общего пула.

Смягчение

В Google Public DNS реализованы несколько подходов для ускорения времени поиска DNS. Некоторые из этих подходов достаточно стандартны; другие являются экспериментальными:

• Подготовка серверов адекватная для обработки нагрузки от клиентского трафика, включая вредоносный трафик.
• Предотвращение DoS и усиленных атак. Хотя это в основном проблема безопасности и затрагивает закрытые средства распознавания в меньшей степени, чем открытые, предотвращение DoS-атак также повышает производительность, устраняя дополнительную нагрузку на трафик на DNS-серверах.
• Балансировка нагрузки для общего кэширования, чтобы повысить частоту обращений к агрегированному кешу в обслуживающем кластере.
• Обеспечение глобального охвата для близости ко всем пользователям.

Предоставление обслуживающих кластеров

Кэширование DNS-распознавателей должно выполнять более дорогие операции, чем авторитетные серверы имен, поскольку многие ответы не могут обслуживаться из памяти; вместо этого они требуют связи с другими серверами имен и, следовательно, требуют большого количества сетевого ввода-вывода. Кроме того, открытые средства распознавания очень уязвимы для попыток открытия кэша, которые увеличивают частоту промахов работы с кэшем (такие атаки, в частности, отправляют запросы на поддельные имена, которые не могут быть разрешены из кэша), и для атак DoS, которые увеличивают нагрузку на трафик. Если резолверы не обеспечены должным образом и не справляются с нагрузкой, это может очень негативно повлиять на производительность. Пакеты отбрасываются и должны быть переданы повторно, запросы сервера имен должны быть поставлены в очередь, и так далее. Все эти факторы увеличивают задержки.

Поэтому важно, чтобы преобразователи DNS были подготовлены для ввода/вывода большого объёма данных. Это включает в себя обработку возможных DDoS-атак, для которых единственным эффективным решением является избыточное обеспечение многих компьютеров. Но в то же время важно не снижать частоту обращений к кешу при добавлении компьютеров; это требует реализации эффективной политики балансировки нагрузки, о которой мы поговорим ниже.

Балансировка нагрузки для общего кэширования

Масштабирование инфраструктуры резольвера путём добавления машин может фактически привести к обратному эффекту и снизить частоту обращений к кэшу, если балансировка нагрузки не будет выполнена должным образом. В типичном развертывании несколько машин работают с балансировщиком нагрузки, который равномерно распределяет трафик на каждую машину, используя простой алгоритм, такой как циклический перебор. Результатом этого является то, что каждая машина поддерживает свой независимый кэш, так что кэшированный контент изолирован между компьютерами. Если каждый входящий запрос распределяется на случайную машину, в зависимости от характера трафика, эффективная частота пропуска кэша может быть пропорционально увеличена. Например, для имен с длинными TTL, которые запрашиваются неоднократно, частота пропуск кэша может быть увеличен на количество компьютеров в кластере. (Для имён с очень короткими TTL, которые запрашиваются очень редко или которые приводят к не кэшируемым ответам (TTL и ошибки), на количество пропусков кэша реально не влияют добавленные машины.)

Чтобы повысить частоту обращений к кешируемым именам, важно сбалансировать нагрузку на серверы, чтобы кеш не фрагментировался. В Google Public DNS есть два уровня кэширования. В одном пуле машины, очень близкие к пользователю, и небольшой кэш для каждой машины содержит наиболее популярные имена. Если запрос не может быть выполнен из этого кэша, он отправляется в другой пул машин, которые разбивают кэш по именам. Для этого кэша второго уровня все запросы на одно и то же имя отправляются на одну и ту же машину, где имя либо кэшируется, либо нет.

Распределение обслуживающих кластеров для широкого географического охвата

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

Общедоступный DNS Google размещён в центрах обработки данных по всему миру и использует маршрутизацию anycast для отправки пользователей в географически ближайший центр обработки данных.

Кроме того, Google Public DNS поддерживает клиентскую подсеть (ECS) EDNS, и расширение протокола DNS для распознавателей для пересылки местоположения клиента на серверы имен, которые могут возвращать чувствительные к местоположению ответы, оптимизированные для фактического IP-адреса клиента, а не IP-адреса распознавателя.