• Главная
  • Карта сайта
Не найдено

Як правильно розмістити DNS-сервер - Blog Imena.UA

  1. Як правильно розмістити DNS-сервер Вимога дотримання заданого часу відгуку і забезпечення передбаченої...
  2. Не думай про секунди з висока ...
  3. Спроба - не катування ...
  4. Що таке добре і що таке погано…
  5. Сухий Залишок
  6. література
  7. Як правильно розмістити DNS-сервер
  8. Моя адреса не дім і не вулиця ...
  9. Не думай про секунди з висока ...
  10. Спроба - не катування ...
  11. Що таке добре і що таке погано…
  12. Сухий залишок
  13. література
  14. Як правильно розмістити DNS-сервер
  15. Моя адреса не дім і не вулиця ...
  16. Не думай про секунди з висока ...
  17. Спроба - не катування ...
  18. Що таке добре і що таке погано…
  19. Сухий залишок
  20. література

Як правильно розмістити DNS-сервер

Вимога дотримання заданого часу відгуку і забезпечення передбаченої в угоді про рівень обслуговування надійності, робить вельми актуальним питання про розміщення серверів доменних імен в Мережі.

Серед ІТ-фахівців все більш популярним сьогодні стає питання розробки систем розповсюдження контенту (content distribution system), на успіх роботи яких дуже впливає розміщення інформаційних серверів. Йдеться про таке розміщення серверів, при якому час доступу було б якщо не мінімальним, то хоча б прийнятним (що відповідає SLA). Фактично, потрібно в одиницю часу обслужити максимальне число користувачів при заданому часу обслуговування одного. Наприклад, для Web-сторінок таким обмежуючим фактором буде прийнятний час завантаження сторінки браузером, яке складається не тільки з часу передачі даних по мережі і часу їх інтерпретації, але також і часу, витраченого на пошук IP-адреси сервера в тому числі і з часу звернення до сервісу Системи Доменних Імен (DNS).

Моя адреса не дім і не вулиця ...

Система доменних імен Internet - ключовий сервіс, на який в мережі замикаються адреси інформаційних ресурсів, а точніше їх ідентифікатори (Uniform Resource Identifier, URI, RFC-2396 [1]). Як зазначено в RFC-3467 [2], присвяченому ролі системи доменних імен, архітектура DNS залишалася незмінною з моменту свого створення, в той час як її функції істотно змінилися - комерціалізація Мережі привела до істотного «уплощению» ієрархії доменних імен. Власники сервісів воліють використовувати домени 2-ої рівня в рамках національних доменів або доменів загального призначення, наприклад microsoft.com, а не закопуватися вглиб ієрархії імен. Крім того, починаючи з 90-х років, систему DNS стали використовувати як інструмент балансування навантаження серверів інформаційних ресурсів, експлуатуючи для цього алгоритм Round Robin, який застосовується серверами доменних імен при відповіді на запити клієнтів. Ні перше, ні друге при проектуванні системи доменних імен не передбачалося. У всякому разі, в основоположних документах RFC-1034 [3] і RFC-1035 [4] цього не вказано.

Згадаймо типову схему пошуку IP-адреси по доменному імені (рис.1)

1)

Рис.1. Схема отримання IP-адреси за відомим доменному імені в системі DNS

Браузер через механізм resolver звертається до локального кешуючого доменних імен з рекурсивним запитом. Цьому серверу передається доменне ім'я, для якого потрібно знайти IP-адресу. Сам браузер IP-адреса не шукає, а передоручає це локальному кешуючого доменних імен (в цьому може переконатися кожен, хто сам налаштовував підключення свого комп'ютера до Мережі). При підключенні через провайдера, наприклад, по комутованого з'єднання, цього робити не потрібно: мережа налаштовується в більшості випадків автоматично (в момент автоматичної настройки провайдер по протоколу PPP надсилає IP-адреси серверів доменних імен, які будуть виконувати рекурсивні запити користувача).

На схемі (Рис. 1) вказані два типи запитів: рекурсивний і нерекурсивний. Перший - це запит, при якому клієнт передоручає пошук IP-адреси сервера, другий - запит при якому клієнт сам виробляє опитування серверів. Локальний кешуючий сервер самостійно опитує всі сервери доменних імен, тому він обмінюється з ними нерекурсивними запитами.

В системі доменних імен існує жорстка ієрархія імен. Починається вона з кореня, який часто позначають як «.», Хоча це і не зовсім правильно. За нею йдуть домени верхнього рівня (Top Level Domains, TLD), наприклад, com., Org., Net., Ru. і т.п. Далі йдуть домени другого рівня, наприклад, nic.ru, vesti.ru і т.п. Кожен домен підтримується авторитарним сервером домена і, як правило, не одним. При цьому сервер, який підтримує старші імена, має можливість передоручити управління молодшими іменами іншого сервера. Таке передоручення відбивається в описі домену, керованому сервером, і називається делегуванням. Та частина дерева ієрархи імен, якою управляє сервер, називається зоною. Якщо серверу доручено керувати коренем дерева імен, і він передоручив всі TLD інших серверів, то в його підпорядкуванні залишається тільки управління відповідниками між іменами доменів та іменами серверів, яким він ці домени передоручив.

Кому доручено управління молодшими іменами, знає тільки той сервер, який здійснює делегування, тому, коли ми шукаємо щось в домені RU, ми спочатку повинні дізнатися, хто підтримує домен RU, а потім, хто підтримує ту частину домена RU, яка, власне , нас і цікавить. На перше питання відповідає кореневий сервер, який обслуговує «корінь» імен DNS - кореневу зону. Таких серверів 13 - 10 в США, 2 в Європі і один в Японії. Досі таке розміщення було виправдано (згідно з даними CIADA (Cooperative Association for Internet Data Analysis) [5] близько 60% клієнтів кореневих серверів розміщені в США). На друге питання дадуть відповідь сервери, що підтримують національний домен RU. Їх шість: три розміщені в Росії і три в Європі. До речі, якщо вірити статистиці Фонду «Громадська думка» [6], то 19% користувачів Рунету знаходяться в Москві, там же, де розташовані і три російських сервера зони RU. З точки зору використання DNS, правильніше орієнтуватися на дані SpyLog, які отримані на основі агрегування статистики його лічильників, розміщених на Web-сайтах - на квітень 2003 року в Москві було 43% всіх міських користувачів Рунету [7].

Після отримання відповіді з сервера, що підтримує національний домен, ми можемо звернутися до авторитативні (authorative) сервера домена, якому належить цікавить нас ім'я. Авторитативним цей сервер називають по тій причині, що саме йому делеговано право відповідати на запити до імен з цього домену. За правилами делегування доменів другого рівня в RU для кожного домена таких серверів має бути не менше двох. Взагалі кажучи, їх може бути і більше - RFC-2 182 [8] рекомендує мати три. Порушенням регламенту реєстрації доменів, здатним спричинити тимчасове припинення делегування, є ситуація коли, сумарний час відсутності зв'язку з сервером перевищує двох години за добу [9]. Їли домен забезпечений трьома серверами, то ймовірність відмови відразу на двох серверах менше, ніж на одному, що істотно знижує ризик тимчасової втрати делегування. Насправді, локальний кешуючий сервер доменних імен звертається до кореневих серверів і авторитативним серверів домена RU тільки тоді, коли не може знайти необхідний йому адресу в своєму кеші.

Час зберігання відповідностей в кеші сервера визначається часом TTL (Time To Live), яке встановлює адміністратор відповідного домена. Наприклад, TTL імен авторитативні серверів домена RU одно 86400 секунд або 1 добу, тобто після першого звернення за адресою в домені RU локальний кешуючий сервер доменних імен звернутися до кореневого сервера за отриманням списку авторитативні серверів домена RU тільки через добу. Аналогічна схема працює і для всіх інших доменів. Якщо один користувач звернувся, наприклад, до www.yandex.ru через локальний кешуючий сервер dialup провайдера, то цей сервер буде обслуговувати всіх інших користувачів цього провайдера протягом доби, не звертаючись ні до кореневих серверів доменних імен, ні до авторитативним серверів домена RU. Але, якщо в якості прикладу вибрати www.rambler.ru, то таке кешування (за даними на червень 2003 роки) буде здійснюватися тільки 1 годину. А для mail.ru цей час дорівнюватиме другої години. Таким чином, для конкретного користувача системи DNS час відгуку буде варіюватися від часу повного опитування всіх серверів, які обслуговують шуканий адресу, починаючи від кореневого сервера і закінчуючи авторитативним сервером поддомена, до часу опитування тільки свого локального кешуючого.

Повернемося до питання про час відгуку на запит, а точніше до RTT (Round Trip Time), яке зазвичай і використовують в якості основи різних метрик в розрахунках ефективності розміщення сервісів [5].

Не думай про секунди з висока ...

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

Як показують дослідження [10, 11], все залежить від того, яке завдання вирішує користувач. При цьому зазвичай досліджують або час затримки, яке починає викликати роздратування, або вплив часу затримки на ефективність роботи в цілому. Зазвичай час затримки (завантаження Web-сторінки) понад 1 с., Викликає дискомфорт, однак, якщо користувач знає, що він отримає, то роздратування не викликають і затримки до 5 секунд. Але після 30 с. мова вже не може йти про інтерактивну роботі. В цілому для роботи з відомим інтерфейсом підходить наступна шкала: до 5 секунд - «добре»; до 10 секунд - «задовільно»; більше 10 секунд - «погано». Однак, якщо показувати елементи сторінки в міру їх отримання, то шкала для часу повного завантаження сторінки зміниться: до 39 с. - "добре"; до 56 с. - «задовільно»; більше 56 секунд - «погано». Цікаво й інше - непереборне бажання «прискорити» процес виникає в середньому після 8,6 секунд очікування хоч якогось результату.

З приемлемостью часу завантаження до 5 секунд згодні і «художники» банерів, рекомендуючи стандартний розмір банера в 10-15 Кбайт [12] - саме стільки вдається передати при dialup-з'єднанні зі швидкістю 28800 біт / c за 3 - 5 с. Насправді не варто сподіватися, що зайшов перший раз на ваш сайт користувач буде чекати 5 секунд, а вже банери більшість користувачів однозначно не люблять, тому при розробці сторінок варто все-таки прагнути до односекундного затримці до появи першого символу на екрані.

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

Спроба - не катування ...

Фактично, алгоритм пошуку IP-адреси по імені - це багатоступінчастий процес, що складається з серій спроб, які виконує "вирішувач" resolver і локальний кешуючий сервер (рис.1). У кожного з них приблизно однаковий механізм опитування серверів доменних імен за винятком того, що кешуючий сервер застосовує ранжування авторитативні серверів зон по RTT. Розглянь цей алгоритм більш уважно.

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

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

Тепер перейдемо до другого ланці пошуку адреси - локальному кешуючого. Він так само опитує сервера, тільки їх список він отримує не з файлу на диску, а з відповідей інших серверів. У нашому випадку, коли ми не заглиблюємося в ієрархію доменних імен далі доменів другого рівня, список авторитативні серверів зони домену 2-ої рівня він отримує від авторитативні сервера зони RU. Список авторитативні серверів зони RU він, в свою чергу, отримує від кореневого сервера, а список кореневих серверів зі свого файлу настройки. Час кешування списку авторитативні серверів зони RU - одна доба, тому основний внесок під час пошуку буде вносити час доступу до авторитативним серверів шуканої зони домену другого рівня.

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

Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси? По-перше, першим в налаштуваннях resolver повинен бути вказаний сервер, який швидше за все відгукується на запити клієнта, тобто локальний кешуючий сервер повинен бути розташований якомога ближче до користувача. По-друге, всі сервери зони повинні бути однаково добре розташовані щодо користувача, точніше його кешуючого, тому що не факт, що клієнт Windows, наприклад, запросить той сервер, який найкраще розташований щодо нього. По-третє, з точки зору «людського фактора» час затримки в 5 секунд досить велика для того, щоб браузер користувача багато разів звертався до серверів.

Що таке добре і що таке погано…

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

За останні два роки було проведено ряд досліджень в цій області. Фахівці CIADA [5] вивчали час відгуку кореневих серверів на запити клієнтів зі всієї земної кулі. Час відгуку визнавалося великим, якщо перевищувало 90% точку розподілу часу відгуку. Типовим великим часом відгуку в цьому дослідженні був час більше 0,5 с. Слід зауважити, що для Росії з 437 точок тільки 14 мали великий час відгуку (3% від загального числа російських учасників), що можна порівняти з даними по Бразилії. Важливо також, що за півроку поки проводилися ці дослідження частка точок в Росії з великим відгуком не змінилася (наприклад, на Україні вона збільшилася в два рази) і була відзначена загальна тенденція до скорочення часу відгуку.

Більш точні вимірювання проведені роботи [16]. Якщо в CIADA вимірювалося RTT від серверів до опитуваних їх хостам, то тут використовувалася програма, яка, будучи встановленої в різних точках Мережі і вимірювала безпосередньо відгук кореневих серверів і серверів національних доменів. Згідно з даними [16] для США і Європи характерним часом відгуку є час менше 0,2 с. Тут слід зробити застереження. В силу різних причин, основний обсяг DNS трафіку припадає на кореневої A-сервер, тому саме час відгуку від цього сервера і є визначальним, а воно при прямому підключенні (досліджувався також і dialup) в окремих випадках перевищує 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.

2

Рис.2. Розподіл часу відгуку серверів доменів другого рівня в зоні RU

Згідно зі статистикою компанії 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 (2 порядки величини) виглядають на цьому тлі, м'яко кажучи, дивно.

Слід враховувати той факт, що сервери, що підтримують домени другого рівня в зоні 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 с до появи першого символу на екрані користувача.

Таблиця 1 Десять самих повільних серверів


N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 ns1.masterhost.ru. 5249 2 ns2.masterhost.ru. 271 3 ns.masterhost.ru. 263 4 aserver.oo.ru. 184 5 ns1.highway.ru. 160 6 ns2.valuehost.ru. 155 7 ns3.incru.net. 153 8 ns2.highway.ru. 151 9 ns4.incru.net. 149 10 ns2.agava.net.ru. 139

Таблиця 2. Десять найшвидших з 50-и найбільш популярних

N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 xns2.rbc.ru. 16 2 ns1.demos.net. 17 3 ns3.nic.ru. 17 4 dns1.100mb.net. 17 5 ns1.mtw.ru. 18 6 ns2.gldn.net. 18 7 dns1.mtu.ru. 18 8 ns.caravan.ru. 19 9 ns.demos.su. 19 10 ns4.nic.ru. 19

В якості мети при розміщенні DNS серверів слід визнати такий час пошуку в системі DNS, яке не перевищувало б 0,15 с. Відповідно до вимірів часу відгуку серверів доменних імен другого рівня в зоні RU, більше половини серверів задовольняють цим умовам.

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

«Добре» розміщувати потрібно не тільки primary (master) сервер зони, але і все авторитативні сервери - несправність будь-якого з них загрожує припиненням делегування, а крім того, зовсім не обов'язково, що resolver-сервер користувача вибере при пошуку primary сервер.

література

  1. Uniform Resource Identifiers (URI) : Generic Syntax. RFC-2396, 1998. ()
  2. Role of the Domain Name System (DNS) . RFC-3467.2003
  3. P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES . RFC-1034, 1987.
  4. P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION . RFC-1035. 1987.
  5. Marina Fomenkov, kc claffy, Bradley Huffaker, David Moore. Macroscopic Internet Topology and Performance Measurements From the DNS Root Name Servers. 2001 LISA XV - December 2-7, 2001. -San Diego, CA.
  6. Галицький Є.Б. Опитування "Інтернет в Росії" . Випуск 3. Весна 2003. ФОН.
  7. Аудиторія Рунета за методикою SpyLOG-монітор. Квітень 2003.
  8. Selection and Operation of Secondary DNS Servers . RFC-2182. 1997. ()
  9. Регламент реєстрації доменів в домені RU . 19.08.2002.
  10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001..
  11. Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000..
  12. Тимофій Бокарьов. Енциклопедія Інтернет-реклами
  13. Unix Manual Page for resolv.conf. The dig Manual Page.
  14. Ryuji SOMEGAWA, KenjiroCHO, Yuji SEKIYA, Suguru YAMAGUCHI. The Effects of Server Placement and Server Selection for Internet Services. IEICE TRANS. COMMUN. VOL.E86-B, NO.2 FENRUARY 2003.
  15. Yuji Sekiya, Kenjiro Cho, Ryuji Somagawa, Tatsuya Jinmei, Jun Murai. Root and ccTLD DNS server observation from worldwide locations. PAM2003. La Jolla, CA, April 6-8 2003.
  16. Статистика реєстрації та делегування доменів в зоні RU на 2003-06-16
  17. Krishna P. Gummadi, Stefan Saroiu, Steven D.Gribble. King: Estimating Latency between Arbitrary Internet End Hosts. IMW 2002. November 6-8, 2002. ( http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf )

Павло Храмцов
Журнал «Відкриті Системи», # 9/2003

Як правильно розмістити DNS-сервер

Вимога дотримання заданого часу відгуку і забезпечення передбаченої в угоді про рівень обслуговування надійності, робить вельми актуальним питання про розміщення серверів доменних імен в Мережі.

Серед ІТ-фахівців все більш популярним сьогодні стає питання розробки систем розповсюдження контенту (content distribution system), на успіх роботи яких дуже впливає розміщення інформаційних серверів. Йдеться про таке розміщення серверів, при якому час доступу було б якщо не мінімальним, то хоча б прийнятним (що відповідає SLA). Фактично, потрібно в одиницю часу обслужити максимальне число користувачів при заданому часу обслуговування одного. Наприклад, для Web-сторінок таким обмежуючим фактором буде прийнятний час завантаження сторінки браузером, яке складається не тільки з часу передачі даних по мережі і часу їх інтерпретації, але також і часу, витраченого на пошук IP-адреси сервера в тому числі і з часу звернення до сервісу Системи Доменних Імен (DNS).

Моя адреса не дім і не вулиця ...

Система доменних імен Internet - ключовий сервіс, на який в мережі замикаються адреси інформаційних ресурсів, а точніше їх ідентифікатори (Uniform Resource Identifier, URI, RFC-2396 [1]). Як зазначено в RFC-3467 [2], присвяченому ролі системи доменних імен, архітектура DNS залишалася незмінною з моменту свого створення, в той час як її функції істотно змінилися - комерціалізація Мережі привела до істотного «уплощению» ієрархії доменних імен. Власники сервісів воліють використовувати домени 2-ої рівня в рамках національних доменів або доменів загального призначення, наприклад microsoft.com, а не закопуватися вглиб ієрархії імен. Крім того, починаючи з 90-х років, систему DNS стали використовувати як інструмент балансування навантаження серверів інформаційних ресурсів, експлуатуючи для цього алгоритм Round Robin, який застосовується серверами доменних імен при відповіді на запити клієнтів. Ні перше, ні друге при проектуванні системи доменних імен не передбачалося. У всякому разі, в основоположних документах RFC-1034 [3] і RFC-1035 [4] цього не вказано.

Згадаймо типову схему пошуку IP-адреси по доменному імені (рис.1)

1)

Рис.1. Схема отримання IP-адреси за відомим доменному імені в системі DNS

Браузер через механізм resolver звертається до локального кешуючого доменних імен з рекурсивним запитом. Цьому серверу передається доменне ім'я, для якого потрібно знайти IP-адресу. Сам браузер IP-адреса не шукає, а передоручає це локальному кешуючого доменних імен (в цьому може переконатися кожен, хто сам налаштовував підключення свого комп'ютера до Мережі). При підключенні через провайдера, наприклад, по комутованого з'єднання, цього робити не потрібно: мережа налаштовується в більшості випадків автоматично (в момент автоматичної настройки провайдер по протоколу PPP надсилає IP-адреси серверів доменних імен, які будуть виконувати рекурсивні запити користувача).

На схемі (Рис. 1) вказані два типи запитів: рекурсивний і нерекурсивний. Перший - це запит, при якому клієнт передоручає пошук IP-адреси сервера, другий - запит при якому клієнт сам виробляє опитування серверів. Локальний кешуючий сервер самостійно опитує всі сервери доменних імен, тому він обмінюється з ними нерекурсивними запитами.

В системі доменних імен існує жорстка ієрархія імен. Починається вона з кореня, який часто позначають як «.», Хоча це і не зовсім правильно. За нею йдуть домени верхнього рівня (Top Level Domains, TLD), наприклад, com., Org., Net., Ru. і т.п. Далі йдуть домени другого рівня, наприклад, nic.ru, vesti.ru і т.п. Кожен домен підтримується авторитарним сервером домена і, як правило, не одним. При цьому сервер, який підтримує старші імена, має можливість передоручити управління молодшими іменами іншого сервера. Таке передоручення відбивається в описі домену, керованому сервером, і називається делегуванням. Та частина дерева ієрархи імен, якою управляє сервер, називається зоною. Якщо серверу доручено керувати коренем дерева імен, і він передоручив всі TLD інших серверів, то в його підпорядкуванні залишається тільки управління відповідниками між іменами доменів та іменами серверів, яким він ці домени передоручив.

Кому доручено управління молодшими іменами, знає тільки той сервер, який здійснює делегування, тому, коли ми шукаємо щось в домені RU, ми спочатку повинні дізнатися, хто підтримує домен RU, а потім, хто підтримує ту частину домена RU, яка, власне , нас і цікавить. На перше питання відповідає кореневий сервер, який обслуговує «корінь» імен DNS - кореневу зону. Таких серверів 13 - 10 в США, 2 в Європі і один в Японії. Досі таке розміщення було виправдано (згідно з даними CIADA (Cooperative Association for Internet Data Analysis) [5] близько 60% клієнтів кореневих серверів розміщені в США). На друге питання дадуть відповідь сервери, що підтримують національний домен RU. Їх шість: три розміщені в Росії і три в Європі. До речі, якщо вірити статистиці Фонду «Громадська думка» [6], то 19% користувачів Рунету знаходяться в Москві, там же, де розташовані і три російських сервера зони RU. З точки зору використання DNS, правильніше орієнтуватися на дані SpyLog, які отримані на основі агрегування статистики його лічильників, розміщених на Web-сайтах - на квітень 2003 року в Москві було 43% всіх міських користувачів Рунету [7].

Після отримання відповіді з сервера, що підтримує національний домен, ми можемо звернутися до авторитативні (authorative) сервера домена, якому належить цікавить нас ім'я. Авторитативним цей сервер називають по тій причині, що саме йому делеговано право відповідати на запити до імен з цього домену. За правилами делегування доменів другого рівня в RU для кожного домена таких серверів має бути не менше двох. Взагалі кажучи, їх може бути і більше - RFC-2182 [8] рекомендує мати три. Порушенням регламенту реєстрації доменів, здатним спричинити тимчасове припинення делегування, є ситуація коли, сумарний час відсутності зв'язку з сервером перевищує двох години за добу [9]. Їли домен забезпечений трьома серверами, то ймовірність відмови відразу на двох серверах менше, ніж на одному, що істотно знижує ризик тимчасової втрати делегування. Насправді, локальний кешуючий сервер доменних імен звертається до кореневих серверів і авторитативним серверів домена RU тільки тоді, коли не може знайти необхідний йому адресу в своєму кеші.

Час зберігання відповідностей в кеші сервера визначається часом TTL (Time To Live), яке встановлює адміністратор відповідного домена. Наприклад, TTL імен авторитативні серверів домена RU одно 86400 секунд або 1 добу, тобто після першого звернення за адресою в домені RU локальний кешуючий сервер доменних імен звернутися до кореневого сервера за отриманням списку авторитативні серверів домена RU тільки через добу. Аналогічна схема працює і для всіх інших доменів. Якщо один користувач звернувся, наприклад, до www.yandex.ru через локальний кешуючий сервер dialup провайдера, то цей сервер буде обслуговувати всіх інших користувачів цього провайдера протягом доби, не звертаючись ні до кореневих серверів доменних імен, ні до авторитативним серверів домена RU. Але, якщо в якості прикладу вибрати www.rambler.ru, то таке кешування (за даними на червень 2003 роки) буде здійснюватися тільки 1 годину. А для mail.ru цей час дорівнюватиме другої години. Таким чином, для конкретного користувача системи DNS час відгуку буде варіюватися від часу повного опитування всіх серверів, які обслуговують шуканий адресу, починаючи від кореневого сервера і закінчуючи авторитативним сервером поддомена, до часу опитування тільки свого локального кешуючого.

Повернемося до питання про час відгуку на запит, а точніше до RTT (Round Trip Time), яке зазвичай і використовують в якості основи різних метрик в розрахунках ефективності розміщення сервісів [5].

Не думай про секунди з висока ...

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

Як показують дослідження [10, 11], все залежить від того, яке завдання вирішує користувач. При цьому зазвичай досліджують або час затримки, яке починає викликати роздратування, або вплив часу затримки на ефективність роботи в цілому. Зазвичай час затримки (завантаження Web-сторінки) понад 1 с., Викликає дискомфорт, однак, якщо користувач знає, що він отримає, то роздратування не викликають і затримки до 5 секунд. Але після 30 с. мова вже не може йти про інтерактивну роботі. В цілому для роботи з відомим інтерфейсом підходить наступна шкала: до 5 секунд - «добре»; до 10 секунд - «задовільно»; більше 10 секунд - «погано». Однак, якщо показувати елементи сторінки в міру їх отримання, то шкала для часу повного завантаження сторінки зміниться: до 39 с. - "добре"; до 56 с. - «задовільно»; більше 56 секунд - «погано». Цікаво й інше - непереборне бажання «прискорити» процес виникає в середньому після 8,6 секунд очікування хоч якогось результату.

З приемлемостью часу завантаження до 5 секунд згодні і «художники» банерів, рекомендуючи стандартний розмір банера в 10-15 Кбайт [12] - саме стільки вдається передати при dialup-з'єднанні зі швидкістю 28800 біт / c за 3 - 5 с. Насправді не варто сподіватися, що зайшов перший раз на ваш сайт користувач буде чекати 5 секунд, а вже банери більшість користувачів однозначно не люблять, тому при розробці сторінок варто все-таки прагнути до односекундного затримці до появи першого символу на екрані.

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

Спроба - не катування ...

Фактично, алгоритм пошуку IP-адреси по імені - це багатоступінчастий процес, що складається з серій спроб, які виконує "вирішувач" resolver і локальний кешуючий сервер (рис.1). У кожного з них приблизно однаковий механізм опитування серверів доменних імен за винятком того, що кешуючий сервер застосовує ранжування авторитативні серверів зон по RTT. Розглянь цей алгоритм більш уважно.

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

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

Тепер перейдемо до другого ланці пошуку адреси - локальному кешуючого. Він так само опитує сервера, тільки їх список він отримує не з файлу на диску, а з відповідей інших серверів. У нашому випадку, коли ми не заглиблюємося в ієрархію доменних імен далі доменів другого рівня, список авторитативні серверів зони домену 2-ої рівня він отримує від авторитативні сервера зони RU. Список авторитативні серверів зони RU він, в свою чергу, отримує від кореневого сервера, а список кореневих серверів зі свого файлу настройки. Час кешування списку авторитативні серверів зони RU - одна доба, тому основний внесок під час пошуку буде вносити час доступу до авторитативним серверів шуканої зони домену другого рівня.

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

Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси? По-перше, першим в налаштуваннях resolver повинен бути вказаний сервер, який швидше за все відгукується на запити клієнта, тобто локальний кешуючий сервер повинен бути розташований якомога ближче до користувача. По-друге, всі сервери зони повинні бути однаково добре розташовані щодо користувача, точніше його кешуючого, тому що не факт, що клієнт Windows, наприклад, запросить той сервер, який найкраще розташований щодо нього. По-третє, з точки зору «людського фактора» час затримки в 5 секунд досить велика для того, щоб браузер користувача багато разів звертався до серверів.

Що таке добре і що таке погано…

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

За останні два роки було проведено ряд досліджень в цій області. Фахівці CIADA [5] вивчали час відгуку кореневих серверів на запити клієнтів зі всієї земної кулі. Час відгуку визнавалося великим, якщо перевищувало 90% точку розподілу часу відгуку. Типовим великим часом відгуку в цьому дослідженні був час більше 0,5 с. Слід зауважити, що для Росії з 437 точок тільки 14 мали великий час відгуку (3% від загального числа російських учасників), що можна порівняти з даними по Бразилії. Важливо також, що за півроку поки проводилися ці дослідження частка точок в Росії з великим відгуком не змінилася (наприклад, на Україні вона збільшилася в два рази) і була відзначена загальна тенденція до скорочення часу відгуку.

Більш точні вимірювання проведені роботи [16]. Якщо в CIADA вимірювалося RTT від серверів до опитуваних їх хостам, то тут використовувалася програма, яка, будучи встановленої в різних точках Мережі і вимірювала безпосередньо відгук кореневих серверів і серверів національних доменів. Згідно з даними [16] для США і Європи характерним часом відгуку є час менше 0,2 с. Тут слід зробити застереження. В силу різних причин, основний обсяг DNS трафіку припадає на кореневої A-сервер, тому саме час відгуку від цього сервера і є визначальним, а воно при прямому підключенні (досліджувався також і dialup) в окремих випадках перевищує 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.

2

Рис.2. Розподіл часу відгуку серверів доменів другого рівня в зоні RU

Згідно зі статистикою компанії 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 (2 порядки величини) виглядають на цьому тлі, м'яко кажучи, дивно.

Слід враховувати той факт, що сервери, що підтримують домени другого рівня в зоні 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 с до появи першого символу на екрані користувача.

Таблиця 1 Десять самих повільних серверів


N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 ns1.masterhost.ru. 5249 2 ns2.masterhost.ru. 271 3 ns.masterhost.ru. 263 4 aserver.oo.ru. 184 5 ns1.highway.ru. 160 6 ns2.valuehost.ru. 155 7 ns3.incru.net. 153 8 ns2.highway.ru. 151 9 ns4.incru.net. 149 10 ns2.agava.net.ru. 139

Таблиця 2. Десять найшвидших з 50-и найбільш популярних

N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 xns2.rbc.ru. 16 2 ns1.demos.net. 17 3 ns3.nic.ru. 17 4 dns1.100mb.net. 17 5 ns1.mtw.ru. 18 6 ns2.gldn.net. 18 7 dns1.mtu.ru. 18 8 ns.caravan.ru. 19 9 ns.demos.su. 19 10 ns4.nic.ru. 19

В якості мети при розміщенні DNS серверів слід визнати такий час пошуку в системі DNS, яке не перевищувало б 0,15 с. Відповідно до вимірів часу відгуку серверів доменних імен другого рівня в зоні RU, більше половини серверів задовольняють цим умовам.

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

«Добре» розміщувати потрібно не тільки primary (master) сервер зони, але і все авторитативні сервери - несправність будь-якого з них загрожує припиненням делегування, а крім того, зовсім не обов'язково, що resolver-сервер користувача вибере при пошуку primary сервер.

література

  1. Uniform Resource Identifiers (URI) : Generic Syntax. RFC-2396, 1998. ()
  2. Role of the Domain Name System (DNS) . RFC-3467.2003
  3. P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES . RFC-1034, 1987.
  4. P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION . RFC-1035. 1987.
  5. Marina Fomenkov, kc claffy, Bradley Huffaker, David Moore. Macroscopic Internet Topology and Performance Measurements From the DNS Root Name Servers. 2001 LISA XV - December 2-7, 2001. -San Diego, CA.
  6. Галицький Є.Б. Опитування "Інтернет в Росії" . Випуск 3. Весна 2003. ФОН.
  7. Аудиторія Рунета за методикою SpyLOG-монітор. Квітень 2003.
  8. Selection and Operation of Secondary DNS Servers . RFC-2182. 1997. ()
  9. Регламент реєстрації доменів в домені RU . 19.08.2002.
  10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001..
  11. Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000..
  12. Тимофій Бокарьов. Енциклопедія Інтернет-реклами
  13. Unix Manual Page for resolv.conf. The dig Manual Page.
  14. Ryuji SOMEGAWA, KenjiroCHO, Yuji SEKIYA, Suguru YAMAGUCHI. The Effects of Server Placement and Server Selection for Internet Services. IEICE TRANS. COMMUN. VOL.E86-B, NO.2 FENRUARY 2003.
  15. Yuji Sekiya, Kenjiro Cho, Ryuji Somagawa, Tatsuya Jinmei, Jun Murai. Root and ccTLD DNS server observation from worldwide locations. PAM2003. La Jolla, CA, April 6-8 2003.
  16. Статистика реєстрації та делегування доменів в зоні RU на 2003-06-16
  17. Krishna P. Gummadi, Stefan Saroiu, Steven D.Gribble. King: Estimating Latency between Arbitrary Internet End Hosts. IMW 2002. November 6-8, 2002. ( http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf )

Павло Храмцов
Журнал «Відкриті Системи», # 9/2003

Як правильно розмістити DNS-сервер

Вимога дотримання заданого часу відгуку і забезпечення передбаченої в угоді про рівень обслуговування надійності, робить вельми актуальним питання про розміщення серверів доменних імен в Мережі.

Серед ІТ-фахівців все більш популярним сьогодні стає питання розробки систем розповсюдження контенту (content distribution system), на успіх роботи яких дуже впливає розміщення інформаційних серверів. Йдеться про таке розміщення серверів, при якому час доступу було б якщо не мінімальним, то хоча б прийнятним (що відповідає SLA). Фактично, потрібно в одиницю часу обслужити максимальне число користувачів при заданому часу обслуговування одного. Наприклад, для Web-сторінок таким обмежуючим фактором буде прийнятний час завантаження сторінки браузером, яке складається не тільки з часу передачі даних по мережі і часу їх інтерпретації, але також і часу, витраченого на пошук IP-адреси сервера в тому числі і з часу звернення до сервісу Системи Доменних Імен (DNS).

Моя адреса не дім і не вулиця ...

Система доменних імен Internet - ключовий сервіс, на який в мережі замикаються адреси інформаційних ресурсів, а точніше їх ідентифікатори (Uniform Resource Identifier, URI, RFC-2396 [1]). Як зазначено в RFC-3467 [2], присвяченому ролі системи доменних імен, архітектура DNS залишалася незмінною з моменту свого створення, в той час як її функції істотно змінилися - комерціалізація Мережі привела до істотного «уплощению» ієрархії доменних імен. Власники сервісів воліють використовувати домени 2-ої рівня в рамках національних доменів або доменів загального призначення, наприклад microsoft.com, а не закопуватися вглиб ієрархії імен. Крім того, починаючи з 90-х років, систему DNS стали використовувати як інструмент балансування навантаження серверів інформаційних ресурсів, експлуатуючи для цього алгоритм Round Robin, який застосовується серверами доменних імен при відповіді на запити клієнтів. Ні перше, ні друге при проектуванні системи доменних імен не передбачалося. У всякому разі, в основоположних документах RFC-1034 [3] і RFC-1035 [4] цього не вказано.

Згадаймо типову схему пошуку IP-адреси по доменному імені (рис.1)

1)

Рис.1. Схема отримання IP-адреси за відомим доменному імені в системі DNS

Браузер через механізм resolver звертається до локального кешуючого доменних імен з рекурсивним запитом. Цьому серверу передається доменне ім'я, для якого потрібно знайти IP-адресу. Сам браузер IP-адреса не шукає, а передоручає це локальному кешуючого доменних імен (в цьому може переконатися кожен, хто сам налаштовував підключення свого комп'ютера до Мережі). При підключенні через провайдера, наприклад, по комутованого з'єднання, цього робити не потрібно: мережа налаштовується в більшості випадків автоматично (в момент автоматичної настройки провайдер по протоколу PPP надсилає IP-адреси серверів доменних імен, які будуть виконувати рекурсивні запити користувача).

На схемі (Рис. 1) вказані два типи запитів: рекурсивний і нерекурсивний. Перший - це запит, при якому клієнт передоручає пошук IP-адреси сервера, другий - запит при якому клієнт сам виробляє опитування серверів. Локальний кешуючий сервер самостійно опитує всі сервери доменних імен, тому він обмінюється з ними нерекурсивними запитами.

В системі доменних імен існує жорстка ієрархія імен. Починається вона з кореня, який часто позначають як «.», Хоча це і не зовсім правильно. За нею йдуть домени верхнього рівня (Top Level Domains, TLD), наприклад, com., Org., Net., Ru. і т.п. Далі йдуть домени другого рівня, наприклад, nic.ru, vesti.ru і т.п. Кожен домен підтримується авторитарним сервером домена і, як правило, не одним. При цьому сервер, який підтримує старші імена, має можливість передоручити управління молодшими іменами іншого сервера. Таке передоручення відбивається в описі домену, керованому сервером, і називається делегуванням. Та частина дерева ієрархи імен, якою управляє сервер, називається зоною. Якщо серверу доручено керувати коренем дерева імен, і він передоручив всі TLD інших серверів, то в його підпорядкуванні залишається тільки управління відповідниками між іменами доменів та іменами серверів, яким він ці домени передоручив.

Кому доручено управління молодшими іменами, знає тільки той сервер, який здійснює делегування, тому, коли ми шукаємо щось в домені RU, ми спочатку повинні дізнатися, хто підтримує домен RU, а потім, хто підтримує ту частину домена RU, яка, власне , нас і цікавить. На перше питання відповідає кореневий сервер, який обслуговує «корінь» імен DNS - кореневу зону. Таких серверів 13 - 10 в США, 2 в Європі і один в Японії. Досі таке розміщення було виправдано (згідно з даними CIADA (Cooperative Association for Internet Data Analysis) [5] близько 60% клієнтів кореневих серверів розміщені в США). На друге питання дадуть відповідь сервери, що підтримують національний домен RU. Їх шість: три розміщені в Росії і три в Європі. До речі, якщо вірити статистиці Фонду «Громадська думка» [6], то 19% користувачів Рунету знаходяться в Москві, там же, де розташовані і три російських сервера зони RU. З точки зору використання DNS, правильніше орієнтуватися на дані SpyLog, які отримані на основі агрегування статистики його лічильників, розміщених на Web-сайтах - на квітень 2003 року в Москві було 43% всіх міських користувачів Рунету [7].

Після отримання відповіді з сервера, що підтримує національний домен, ми можемо звернутися до авторитативні (authorative) сервера домена, якому належить цікавить нас ім'я. Авторитативним цей сервер називають по тій причині, що саме йому делеговано право відповідати на запити до імен з цього домену. За правилами делегування доменів другого рівня в RU для кожного домена таких серверів має бути не менше двох. Взагалі кажучи, їх може бути і більше - RFC-2182 [8] рекомендує мати три. Порушенням регламенту реєстрації доменів, здатним спричинити тимчасове припинення делегування, є ситуація коли, сумарний час відсутності зв'язку з сервером перевищує двох години за добу [9]. Їли домен забезпечений трьома серверами, то ймовірність відмови відразу на двох серверах менше, ніж на одному, що істотно знижує ризик тимчасової втрати делегування. Насправді, локальний кешуючий сервер доменних імен звертається до кореневих серверів і авторитативним серверів домена RU тільки тоді, коли не може знайти необхідний йому адресу в своєму кеші.

Час зберігання відповідностей в кеші сервера визначається часом TTL (Time To Live), яке встановлює адміністратор відповідного домена. Наприклад, TTL імен авторитативні серверів домена RU одно 86400 секунд або 1 добу, тобто після першого звернення за адресою в домені RU локальний кешуючий сервер доменних імен звернутися до кореневого сервера за отриманням списку авторитативні серверів домена RU тільки через добу. Аналогічна схема працює і для всіх інших доменів. Якщо один користувач звернувся, наприклад, до www.yandex.ru через локальний кешуючий сервер dialup провайдера, то цей сервер буде обслуговувати всіх інших користувачів цього провайдера протягом доби, не звертаючись ні до кореневих серверів доменних імен, ні до авторитативним серверів домена RU. Але, якщо в якості прикладу вибрати www.rambler.ru, то таке кешування (за даними на червень 2003 роки) буде здійснюватися тільки 1 годину. А для mail.ru цей час дорівнюватиме другої години. Таким чином, для конкретного користувача системи DNS час відгуку буде варіюватися від часу повного опитування всіх серверів, які обслуговують шуканий адресу, починаючи від кореневого сервера і закінчуючи авторитативним сервером поддомена, до часу опитування тільки свого локального кешуючого.

Повернемося до питання про час відгуку на запит, а точніше до RTT (Round Trip Time), яке зазвичай і використовують в якості основи різних метрик в розрахунках ефективності розміщення сервісів [5].

Не думай про секунди з висока ...

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

Як показують дослідження [10, 11], все залежить від того, яке завдання вирішує користувач. При цьому зазвичай досліджують або час затримки, яке починає викликати роздратування, або вплив часу затримки на ефективність роботи в цілому. Зазвичай час затримки (завантаження Web-сторінки) понад 1 с., Викликає дискомфорт, однак, якщо користувач знає, що він отримає, то роздратування не викликають і затримки до 5 секунд. Але після 30 с. мова вже не може йти про інтерактивну роботі. В цілому для роботи з відомим інтерфейсом підходить наступна шкала: до 5 секунд - «добре»; до 10 секунд - «задовільно»; більше 10 секунд - «погано». Однак, якщо показувати елементи сторінки в міру їх отримання, то шкала для часу повного завантаження сторінки зміниться: до 39 с. - "добре"; до 56 с. - «задовільно»; більше 56 секунд - «погано». Цікаво й інше - непереборне бажання «прискорити» процес виникає в середньому після 8,6 секунд очікування хоч якогось результату.

З приемлемостью часу завантаження до 5 секунд згодні і «художники» банерів, рекомендуючи стандартний розмір банера в 10-15 Кбайт [12] - саме стільки вдається передати при dialup-з'єднанні зі швидкістю 28800 біт / c за 3 - 5 с. Насправді не варто сподіватися, що зайшов перший раз на ваш сайт користувач буде чекати 5 секунд, а вже банери більшість користувачів однозначно не люблять, тому при розробці сторінок варто все-таки прагнути до односекундного затримці до появи першого символу на екрані.

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

Спроба - не катування ...

Фактично, алгоритм пошуку IP-адреси по імені - це багатоступінчастий процес, що складається з серій спроб, які виконує "вирішувач" resolver і локальний кешуючий сервер (рис.1). У кожного з них приблизно однаковий механізм опитування серверів доменних імен за винятком того, що кешуючий сервер застосовує ранжування авторитативні серверів зон по RTT. Розглянь цей алгоритм більш уважно.

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

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

Тепер перейдемо до другого ланці пошуку адреси - локальному кешуючого. Він так само опитує сервера, тільки їх список він отримує не з файлу на диску, а з відповідей інших серверів. У нашому випадку, коли ми не заглиблюємося в ієрархію доменних імен далі доменів другого рівня, список авторитативні серверів зони домену 2-ої рівня він отримує від авторитативні сервера зони RU. Список авторитативні серверів зони RU він, в свою чергу, отримує від кореневого сервера, а список кореневих серверів зі свого файлу настройки. Час кешування списку авторитативні серверів зони RU - одна доба, тому основний внесок під час пошуку буде вносити час доступу до авторитативним серверів шуканої зони домену другого рівня.

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

Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси? По-перше, першим в налаштуваннях resolver повинен бути вказаний сервер, який швидше за все відгукується на запити клієнта, тобто локальний кешуючий сервер повинен бути розташований якомога ближче до користувача. По-друге, всі сервери зони повинні бути однаково добре розташовані щодо користувача, точніше його кешуючого, тому що не факт, що клієнт Windows, наприклад, запросить той сервер, який найкраще розташований щодо нього. По-третє, з точки зору «людського фактора» час затримки в 5 секунд досить велика для того, щоб браузер користувача багато разів звертався до серверів.

Що таке добре і що таке погано…

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

За останні два роки було проведено ряд досліджень в цій області. Фахівці CIADA [5] вивчали час відгуку кореневих серверів на запити клієнтів зі всієї земної кулі. Час відгуку визнавалося великим, якщо перевищувало 90% точку розподілу часу відгуку. Типовим великим часом відгуку в цьому дослідженні був час більше 0,5 с. Слід зауважити, що для Росії з 437 точок тільки 14 мали великий час відгуку (3% від загального числа російських учасників), що можна порівняти з даними по Бразилії. Важливо також, що за півроку поки проводилися ці дослідження частка точок в Росії з великим відгуком не змінилася (наприклад, на Україні вона збільшилася в два рази) і була відзначена загальна тенденція до скорочення часу відгуку.

Більш точні вимірювання проведені роботи [16]. Якщо в CIADA вимірювалося RTT від серверів до опитуваних їх хостам, то тут використовувалася програма, яка, будучи встановленої в різних точках Мережі і вимірювала безпосередньо відгук кореневих серверів і серверів національних доменів. Згідно з даними [16] для США і Європи характерним часом відгуку є час менше 0,2 с. Тут слід зробити застереження. В силу різних причин, основний обсяг DNS трафіку припадає на кореневої A-сервер, тому саме час відгуку від цього сервера і є визначальним, а воно при прямому підключенні (досліджувався також і dialup) в окремих випадках перевищує 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.

2

Рис.2. Розподіл часу відгуку серверів доменів другого рівня в зоні RU

Згідно зі статистикою компанії 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 (2 порядки величини) виглядають на цьому тлі, м'яко кажучи, дивно.

Слід враховувати той факт, що сервери, що підтримують домени другого рівня в зоні 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 с до появи першого символу на екрані користувача.

Таблиця 1 Десять самих повільних серверів


N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 ns1.masterhost.ru. 5249 2 ns2.masterhost.ru. 271 3 ns.masterhost.ru. 263 4 aserver.oo.ru. 184 5 ns1.highway.ru. 160 6 ns2.valuehost.ru. 155 7 ns3.incru.net. 153 8 ns2.highway.ru. 151 9 ns4.incru.net. 149 10 ns2.agava.net.ru. 139

Таблиця 2. Десять найшвидших з 50-и найбільш популярних

N
ім'я сервера
Час відгуку (RTT, І 10-3 секунди)

1 xns2.rbc.ru. 16 2 ns1.demos.net. 17 3 ns3.nic.ru. 17 4 dns1.100mb.net. 17 5 ns1.mtw.ru. 18 6 ns2.gldn.net. 18 7 dns1.mtu.ru. 18 8 ns.caravan.ru. 19 9 ns.demos.su. 19 10 ns4.nic.ru. 19

В якості мети при розміщенні DNS серверів слід визнати такий час пошуку в системі DNS, яке не перевищувало б 0,15 с. Відповідно до вимірів часу відгуку серверів доменних імен другого рівня в зоні RU, більше половини серверів задовольняють цим умовам.

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

«Добре» розміщувати потрібно не тільки primary (master) сервер зони, але і все авторитативні сервери - несправність будь-якого з них загрожує припиненням делегування, а крім того, зовсім не обов'язково, що resolver-сервер користувача вибере при пошуку primary сервер.

література

  1. Uniform Resource Identifiers (URI) : Generic Syntax. RFC-2396, 1998. ()
  2. Role of the Domain Name System (DNS) . RFC-3467.2003
  3. P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES . RFC-1034, 1987.
  4. P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION . RFC-1035. 1987.
  5. Marina Fomenkov, kc claffy, Bradley Huffaker, David Moore. Macroscopic Internet Topology and Performance Measurements From the DNS Root Name Servers. 2001 LISA XV - December 2-7, 2001. -San Diego, CA.
  6. Галицький Є.Б. Опитування "Інтернет в Росії" . Випуск 3. Весна 2003. ФОН.
  7. Аудиторія Рунета за методикою SpyLOG-монітор. Квітень 2003.
  8. Selection and Operation of Secondary DNS Servers . RFC-2182. 1997. ()
  9. Регламент реєстрації доменів в домені RU . 19.08.2002.
  10. Bob Bailey. Acceptable Computer Response Times. UI Design Update Newsletter - April, 2001..
  11. Bob Bailey. Improving User Performance. UI Design Update Newsletter - June, 2000..
  12. Тимофій Бокарьов. Енциклопедія Інтернет-реклами
  13. Unix Manual Page for resolv.conf. The dig Manual Page.
  14. Ryuji SOMEGAWA, KenjiroCHO, Yuji SEKIYA, Suguru YAMAGUCHI. The Effects of Server Placement and Server Selection for Internet Services. IEICE TRANS. COMMUN. VOL.E86-B, NO.2 FENRUARY 2003.
  15. Yuji Sekiya, Kenjiro Cho, Ryuji Somagawa, Tatsuya Jinmei, Jun Murai. Root and ccTLD DNS server observation from worldwide locations. PAM2003. La Jolla, CA, April 6-8 2003.
  16. Статистика реєстрації та делегування доменів в зоні RU на 2003-06-16
  17. Krishna P. Gummadi, Stefan Saroiu, Steven D.Gribble. King: Estimating Latency between Arbitrary Internet End Hosts. IMW 2002. November 6-8, 2002. ( http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf )

Павло Храмцов
Журнал «Відкриті Системи», # 9/2003

Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси?
У зв'язку з цим цікаво подивитися, а який час відгуку мають сервери, що підтримують домени в зоні RU?
Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси?
У зв'язку з цим цікаво подивитися, а який час відгуку мають сервери, що підтримують домени в зоні RU?
Що ж дає аналіз роботи resolver в плані розуміння компонентів часу відгуку при пошуку адреси?
У зв'язку з цим цікаво подивитися, а який час відгуку мають сервери, що підтримують домени в зоні RU?
Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью