Преимущества производительности

Введение: причины и способы устранения задержки DNS

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

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

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

Мы считаем, что фактор промаха кэша является наиболее распространенной причиной задержки 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, которые запрашиваются очень редко или которые приводят к некэшируемым ответам (0 TTL и ошибки), суммирующие машины на самом деле не влияют на частоту промахов в кэше.)

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

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

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

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

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