С приемлемостью времени загрузки до 5 секунд согласны и «художники» баннеров, рекомендуя стандартный размер баннера в 10-15 Кбайт : именно столько удается передать при коммутируемом соединении со скоростью 28,8 кбит/c за 3-5 секунд. (На самом деле не стоит надеяться, что пользователь, зашедший на ваш сайт впервые, будет ждать 5 секунд, а уж баннеры большинство однозначно не любит; поэтому при разработке страниц стоит все-таки стремиться к односекундной задержке до появления первого символа на экране.)

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

Попытка — не пытка...

Алгоритм поиска IP-адреса по имени — многоступенчатый процесс, состоящий из серий попыток, которые выполняет «решатель» (resolver) и локальный кэширующий сервер. У каждого из них примерно одинаковый механизм опроса серверов доменных имен за исключением того, что кэширующий сервер применяет ранжирование авторитативных серверов зон по RTT. Рассмотрим этот алгоритм более внимательно.

В настройках resolver обычно указывают один-два сервера доменных имен, к которым он обращается с рекурсивными запросами. Процесс опроса начинается с первого сервера в списке и идет последовательно. Может быть совершено до четырех попыток. В первой попытке resolver ждет отклика от сервера 5 секунд, после чего переходит к следующему серверу. Если ответ не получен, то период ожидания увеличивается вдвое, и опрос серверов возобновляется с первого сервера в списке. Если resolver использует только один сервер, то тогда максимальное время ожидания отклика равно 75 секунд (5+10+20+40). Если серверов несколько, то возможны два варианта. В первом приведенный алгоритм справедлив для каждого сервера [13], а во втором время ожидания при каждой попытке на каждом сервере получается как результат деления установленного для данной попытки времени ожидания на число серверов. Например, для первой попытки и случая двух серверов оно будет равно 5/2 [14].

Следует пояснить, почему время суммируется. При рекурсивном запросе resolver перепоручает нахождение адреса локальному кэширующему серверу. Даже когда resolver начинает опрос второго сервера, первый сервер все равно пытается выполнить запрос (получить ответ и кэшировать его), поэтому при повторном обращении к нему он может иметь уже в своем распоряжении нужный ответ.

Перейдем ко второму звену поиска адреса — локальному кэширующему серверу. Он точно также опрашивает серверы, только их список он получает не из файла на диске, а из ответов других серверов. В нашем случае, когда мы не углубляемся в иерархию доменных имен дальше доменов второго уровня, список авторитативных серверов зоны домена второго уровня он получает от авторитативного сервера зоны RU. Список авторитативных серверов зоны RU он, в свою очередь, получает от корневого сервера, а список корневых серверов из своего файла настройки. Время кэширования списка авторитативных серверов зоны RU — одни сутки, поэтому основной вклад во время поиска будет вносить время доступа к авторитативным серверам искомой зоны домена второго уровня.

На самом деле разные серверы применяют разные алгоритмы выбора первого сервера для опроса [15] — BIND ранжирует серверы по RTT, а Windows выбирает просто случайным образом из полученного списка.

Что же дает анализ работы resolver в плане понимания компонентов времени отклика при поиске адреса? Во-первых, первым в настройках resolver должен быть указан сервер, который быстрее всего откликается на запросы клиента, поскольку локальный кэширующий сервер должен быть расположен как можно ближе к пользователю. Во-вторых, все серверы зоны должны быть одинаково хорошо расположены относительно пользователя (точнее, его кэширующего сервера), так как не факт, что клиент Windows, например, запросит тот сервер, который лучше всего расположен относительно него. В-третьих, с точки зрения «человеческого фактора» время задержки в 5 секунд достаточно велико для того, чтобы браузер пользователя многократно обращался к серверам.

Что такое хорошо, и что такое плохо...

Какое время отклика DNS-сервера принято считать «хорошим», а какое «плохим»? Посмотрим на наиболее загруженные и критичные с точки зрения всей системы серверы — корневые и те, что обслуживают «национальные» домены.

За последние два года был проведен ряд исследований в этой области. В CIADA [5] изучали время отклика корневых серверов на запросы клиентов со всего земного шара. Время отклика признавалось большим, если превышало 90% точку распределения времени отклика. Типичным большим временем отклика в этом исследовании было время, превышающее полсекунды. Для России из 437 точек только 14 имели большое время отклика (3% от общего числа российских участников), что сравнимо с данными по Бразилии. Важно также, что за полгода, в течение которого проводились эти исследования, доля точек в России с большим откликом не изменилась (к примеру, в Украине она увеличилась вдвое); была отмечена общая тенденция к сокращению времени отклика.

Более точные измерения проведены в работе [16]. Если в CIADA измерялось RTT от серверов к опрашивающим их хостам, то здесь использовалась программа, которая, будучи установленной в различных точках Сети и измеряла непосредственно отклик корневых серверов и серверов национальных доменов. Согласно данным [16], для США и Европы характерным временем отклика является время, меньшее 0,2 с. Здесь следует сделать оговорку. Основной объем трафика DNS приходится на корневой A–сервер; поэтому именно время отклика этого сервера и является определяющим, а оно при прямом подключении в редких случаях превышает 0,2 с. Как правило, время отклика ccTLD-серверов несколько хуже, чем корневых — несколько десятых долей секунды. Например, для Парижа среднее время отклика A-сервера равно 0,18 с, а сервера национального домена FR — 0,25 с.

А какое время отклика имеют серверы, поддерживающие домены в зоне RU? Для этого было решено замерять время обращения за записью зоны SOA (Start Of Authority), для которой сервер является авторитативным, проверять авторитативность отклика и запоминать параметр RTT. Измерения проводились из точки, для которой значение RTT до ns.ripn.net было равно 0,0013 с (запрос SOA для зоны RU), т.е. фактически от авторитативного сервера зоны RU (см. рис. 2).

Согласно статистике Ru-center, на момент проведения измерений в зоне RU было 28106 серверов [17], которые поддерживали домены второго уровня. Это означает, что 48% серверов имели время отклика менее 0,1 секунды. Еще 12% попадали в интервал 0,1-0,2 с. Приемлемое время отклика до 1 секунды имело 79% серверов; во время до 5 секунд укладывался 81% серверов.

Интересно посмотреть на 10 самых медленных (таблица 1) и самых быстрых (таблица 2) серверов из 50 наиболее популярных (по числу поддерживаемых ими уникальных доменов в зоне RU).

Разница между самыми быстрыми и самыми медленными наиболее популярными серверами составляет в среднем порядок. Пять с слишком секунд для ns1.masterhost.ru (два порядка величины) выглядят на этом фоне, мягко говоря, странно.

Следует учитывать тот факт, что серверы, поддерживающие домены второго уровня в зоне RU, как и во всем мире [18], в большинстве случаев (70%) одновременно являются и серверами, которые выполняют рекурсивные запросы. Чем ближе данный сервер расположен к корневому серверу, тем больше времени из интервала «приемлемого времени» останется на передачу полезной информации, а не на накладные расходы, к которым относится и служба DNS.

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

Есть еще один момент. Например, rambler.ru, как уже было указано, кэшируется только час, а время доступа до него от ns.ripn.net — 0,004 с. Для mail.ru время доступа от ns.ripn.ru также равняется 0,004 с. Время определяется не только физическим расстоянием, но и качеством, и пропускной способностью канала. Например, для сервера ns.nsk.ru время отклика составляет 0,18 с, а для ns.spb.su — 0,019 с. В таких условиях времена отклика серверов доменных имен провайдеров услуг хостинга, которые превышают 0,15 с, выглядят плохо. Понятно, что это, скорее всего дублирующие серверы (secondary), но алгоритмы выбора серверов resolver предполагают «одинаковость» авторитативных серверов доменов.

Сухой остаток

Следует признать «приемлемым» время загрузки от 1 до 5 секунд, а в качестве цели, которую желательно достичь при разработке страниц сайтов, — 1 секунда до появления первого символа на экране пользователя. В качестве цели при размещении DNS-серверов следует признать такое время поиска в системе DNS, которое не превышало бы 0,15 с. Согласно измерениям времени отклика серверов доменных имен второго уровня в зоне RU, более половины серверов удовлетворяют этим условиям.

Для надежного обеспечения поиска своих ресурсов в сети следует не ограничиваться двумя авторитативными серверами, а увеличить их число до трех, чтобы не оказаться в ситуации приостановки делегирования.

«Хорошо» размещать нужно не только первичный (master) сервер зоны, но и все авторитативные серверы — неисправность любого из них грозит приостановкой делегирования, а кроме того, совершенно не обязательно, что resolver-сервер пользователя выберет при поиске первичный сервер.

У ИТ-общественности еще нет четкого понимания того, чем конкретно (убытки, потерянные пользователи, четко измеренные недопустимые задержки и т.п.) может грозить неправильное размещение DNS-сервера. Для Рунета никто не рассчитывал времена отклика на запрос ресурсов, не изучал составляющие времени отклика, и влияние всего этого на бизнес. Между тем, к примеру, при изменении маршрутизации в конце прошлого года тремя ведущими российскими провайдерами и увеличении RTT некоторые бизнесмены от Internet потеряли пользователей и, соответственно, понесли убытки, но их измерений и корреляций никто не делал. На Западе работы, посвященные измерению RTT тем же методом, что и рассмотренные в данной статье, были проведены в конце прошлого года [18]. Предполагается, что это поможет судить о влиянии RTT на эффективность работы Сети, однако пока эти работы еще не завершены. В общем случае, это достаточно серьезная проблема, затрагивающая оценку всего объема трафика, предоставляемого отечественными провайдерами.