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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

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

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

Кэш промахивается

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

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

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

Смягчения

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

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

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

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

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

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

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

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

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

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

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