15.1. Типи адрес стека tcp/ip

15.2. Класи IP-адрес

IP-адреса має довжину 4 байти й звичайно записується у вигляді чотирьох чисел, що представляють значення кожного байта в десятковій формі й розділених точками, наприклад, 128.10.2.30 - традиційна десяткова форма представлення адреси, а 10000000 00001010 00000010 00011110 - двійкова форма представлення цієї ж адреси.

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

На мал. 5.9 показана структура IP-адреси різних класів.

Якщо адреса починається з 0, то мережу відносять до класу А и номер мережі займає один байт, інші 3 байти інтерпретуються як номер вузла в мережі. Мережі класу А мають номери в діапазоні від 1 до 126. (Номер 0 не використовується, а номер 127 зарезервований для спеціальних цілей, про що буде сказано нижче.) Мереж класу А небагато, зате кількість вузлів у них може досягати 2²⁴, тобто 16 777 216 вузлів.

Якщо перші два біти адреси є 10, то мережа відноситься до класу В. У мережах класу В під номер мережі й під номер вузла виділяється по 16 біт, тобто по 2 байти. Таким чином, мережа класу В є мережею середніх розмірів з максимальним числом вузлів 2¹⁶, що становить 65 536 вузлів.

Якщо адреса починається з послідовності 110, то це мережа класу С. У цьому випадку під номер мережі приділяється 24 битка, а під номер вузла — 8 біт. Мережі цього класу найпоширеніші, число вузлів у них обмежено 2⁸, тобто 256 вузлами.

Якщо адреса починається з послідовності 1110, то вона є адресою класу D і позначає особливу, групову адресу — multicast. Якщо в пакеті як адреса призначення зазначена адреса класу D, то такий пакет повинні отримати всі вузли, яким привласнена дана адреса.

Якщо адреса починається з послідовності 11110, то це значить, що дана адреса відноситься до класу Е. Адреси цього класу зарезервовані для майбутніх застосувань.

У табл. 5.4 наведені діапазони номерів мереж і максимальне число вузлів, що відповідають кожному класу мереж.

Таблиця 5.4. Характеристики адрес різного класу

Великі мережі одержують адреси класу А, середні - класу В, а малі - класу С.

15.3. Особливі IP-адреси

У протоколі IP існує кілька угод про особливу інтерпретацію IP-адрес.

• Якщо вся IP-адреса складається тільки із двійкових нулів, то вона позначає адресу того вузла, що згенерував цей пакет; цей режим використовується тільки в деяких повідомленнях ICMP.

• Якщо в полі номера мережі стоять тільки нулі, то за замовчуванням вважається, що вузол призначення належить тій же самій мережі, що й вузол, що відправив пакет.

• Якщо всі двійкові розряди IP-адреси рівні 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, що перебувають у тій же мережі, що й джерело цього пакета. Таке розсилання називається обмеженим широкомовним повідомленням (limited broadcast).

• Якщо в поле номера вузла призначення стоять тільки одиниці, то пакет, що має таку адреса, розсилається всім вузлам мережі із заданим номером мережі. Наприклад, пакет з адресою 192.190.21.255 доставляється всім вузлам мережі 192.190.21. 0. Таке розсилання називається широкомовним повідомленням(broadcast).

При адресації необхідно враховувати ті обмеження, які вносяться особливим призначенням деяких IP-адрес. Так, ні номер мережі, ні номер вузла не може складатися тільки з одних двійкових одиниць або тільки з одних двійкових нулів. Звідси треба, що максимальна кількість вузлів, наведена в таблиці для мереж кожного класу, на практиці повинна бути зменшена на 2. Наприклад, у мережах класу С під номер вузла відводиться 8 біт, які дозволяють задавати 256 номерів: від 0 до 255. Однак на практиці максимальне число вузлів у мережі класу С не може перевищувати 254, тому що адреси 0 й 255 мають спеціальне призначення. Із цих же міркувань слідує, що кінцевий вузол не може мати адресу типу 98.255.255.255, оскільки номер вузла в цій адресі класу А складається з одних двійкових одиниць.

Особливий смисл має IP-адреса, перший октет якої дорівнює 127. Вона використовується для тестування програм і взаємодії процесів у межах одної машини. Коли програма посилає дані по IP-адресі 127.0.0. 1, то утвориться як би «петля». Дані не передаються по мережі, а повертаються модулям верхнього рівня як тільки що прийняті. Тому в IP-мережі забороняється привласнювати машинам IP-адреси, що починаються з 127. Ця адреса має назву loopback. Можна віднести адресу 127.0.0.0 до внутрішньої мережі модуля маршрутизації вузла, а адресу 127.0.0.1 - до адреси цього модуля на внутрішній мережі. Насправді будь-яка адреса мережі 127.0.0.0 служить для позначення свого модуля маршрутизації, а не тільки 127.0.0.1, наприклад 127.0.0.3.

У протоколі IP немає поняття широкомовності в тому розумінні, у якому воно використовується в протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам. Як обмежена широкомовна IP-адреса, так і широкомовна IP-адреса мають межі розповсюдження в інтермережі - вони обмежені або мережею, до якої належить вузол-джерело пакета, або мережею, номер якої зазначений в адресі призначення. Тому ділення мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї зі складових загальної мережі частин просто тому, що немає способу адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.

Уже згадувана форма групової IP-адреси — multicast — означає, що даний пакет повинен бути доставлений відразу декільком вузлам, які утворять групу з номером, зазначеним у полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якій із груп вони належать. Той самий вузол може входити в кілька груп. Члени якої-небудь групи multicast не обов'язково повинні належати одній мережі. У загальному випадку вони можуть розподілятися по зовсім різних мережах, що перебувають друг від друга на довільній кількості хопів. Групова адреса не ділиться на поля номера мережі й вузла й обробляється маршрутизатором особливим чином.

Основне призначення multicast-адрес - розповсюдження інформації зі схеми «один-до-багатьох». Хост, що хоче передавати ту саму інформацію багатьом абонентам, за допомогою спеціального протоколу IGMP (Internet Group Management Protocol) повідомляє про створення в мережі нової мультимовної групи з певною адресою. Машрутизатор, що підтримують мультимовність, поширюють інформацію про створення нової групи в мережах, підключених до портів цього маршрутизатора. Хости, які хочуть приєднатися до знов створеною мультимовної групи, сповіщають про це своїм локальним маршрутизаторам і ті передають цю інформацію хосту, ініціаторові створення нової групи.

Щоб маршрутизатори могли автоматично поширювати пакети з адресою multicast по складеній мережі, необхідно використовувати в кінцевих маршрутизаторах модифіковані протоколи обміну маршрутною інформацією, такі як, наприклад, MOSPF (Multicast OSPF, аналог OSPF).

Групова адресація призначена для економічного поширення в Internet або великої корпоративної мережі аудіо- або відеопрограм, призначених відразу великій аудиторії слухачів або глядачів. Якщо такі засоби знайдуть широке застосування (зараз вони представляють в основному невеликі експериментальні острівці в загальному Internet), то Internet зможе створити серйозну конкуренцію радіо й телебаченню.

15.4. Використання масок в IP-адресації

Традиційна схема ділення IP-адреси на номер мережі й номер вузла засновано на понятті класу, що визначається значеннями декількох перших біт адреси. Саме тому, що перший байт адреси 185.23.44.206 потрапляє в діапазон 128-191, ми можемо сказати, що ця адреса відноситься до класу В, а значить, номером мережі є перші два байти, доповнені двома нульовими байтами - 185.23.0.0, а номером вузла - 0.0.44.206.

А що якщо використати яку-небудь іншу ознаку, за допомогою якого можна було б більш гнучко встановлювати границю між номером мережі й номером вузла? Як такі ознаки зараз одержали широке поширення маски. Маска — це число, що використовується в парі з IP-адресою; двійковий запис маски містить одиниці в тих розрядах, які повинні в IP-адресі інтерпретуватися як номер мережі. Оскільки номер мережі є цільною частиною адреси, одиниці в масці також повинні становити безперервну послідовність. Для стандартних класів мереж маски мають наступні значення:

• клас А - 11111111. 00000000. 00000000. 00000000 (255.0.0.0);

• клас В - 11111111. 11111111. 00000000. 00000000 (255.255.0.0);

• клас С- 11111111.11111111.11111111.00000000(255.255.255.0).

Для запису масок використовуються й інші формати, наприклад, зручно інтерпретувати значення маски, записаної в шістнадцятковому коді: FF.FF.00.00 - маска для адрес класу В. Часто зустрічається й таке позначення 185.23.44.206/16 - цей запис говорить про те, що маска для цієї адреси містить 16 одиниць або що в указаній IP-адресі під номер мережі відведено 16 двійкових розрядів.

Позначаючи кожну IP-адресу маскою, можна відмовитися від понять класів адрес і зробити більш гнучкою систему адресації. Наприклад, якщо розглянуту вище адресу 185.23.44.206 асоціювати з маскою 255.255.255.0, то номером мережі буде 185.23.44.0, а не 185.23.0.0, як це визначено системою класів.

У масках кількість одиниць у послідовності, що визначає границю номера мережі, не обов'язково повинне бути кратним 8, щоб повторювати розподіл адреси на байти. Нехай, наприклад, для IP-адреси 129.64.134.5 зазначено маску 255.255.128.0, тобто у двійковому виді:

IP-адреса 129.64.134.5 - 10000001. 01000000.10000110. 00000101

Маска 255.255.128.0- 11111111.11111111.10000000.00000000

Якщо ігнорувати маску, то відповідно до системи класів адреса 129.64.134.5 відноситься до класу В, а виходить, номером мережі є перші 2 байти - 129.64.0.0, а номером вузла - 0.0.134.5.

Якщо ж використовувати для визначення границі номера мережі маску, то 17 послідовних одиниць у масці, «накладені» на IP-адресу, визначають як номер мережі у двійковому представленні число:

10000001. 01000000. 10000000. 00000000 або в десятковій формі запису - номер мережі 129.64.128.0, а номер вузла 0.0.6.5.

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

15.5. Порядок розподілу IP-адрес

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

Координуючу роль у централізованому розподілі IP-адрес до деякого часу грала організація InterNIC, однак з ростом мережі завдання розподілу адрес стало занадто складним, і InterNIC делегувала частину своїх функцій іншим організаціям і великим постачальникам послуг Internet.

Уже порівняно давно спостерігається дефіцит IP-адрес. Дуже важко одержати адресу класу В и практично неможливо стати власником адреси класу А. При цьому слід відзначити, що дефіцит обумовлений не тільки ростом мереж, але й тим, що наявна безліч IP-адрес використовується нераціонально. Дуже часто власники мережі класу С витрачають лише невелику частину з наявних у них 254 адрес. Розглянемо приклад, коли дві мережі необхідно з'єднати глобальним зв'язком. У таких випадках як канал зв'язку використовують два маршрутизатори, з'єднані за схемою «точка-точка» (мал. 5.10). Для цієї мережі, утвореної каналом, що зв'язує порти двох суміжних маршрутизаторів, доводиться виділяти окремий номер мережі, хоча в цій мережі є всього 2 вузли.

Якщо ж деяка IP-мережа створена для роботи в «автономному режимі», без зв'язку з Internet, тоді адміністратор цієї мережі вільний призначити їй довільно обраний номер. Але й у цій ситуації для того, щоб уникнути яких-небудь колізій, у стандартах Internet визначено кілька діапазонів адрес, що рекомендують для локального використання. Ці адреси не обробляються маршрутизаторами Internet ні при яких умовах. Адреси, зарезервовані для локальних потреб, обрані з різних класів: у класі А - це мережа 10.0.0.0, у класі В - це діапазон з 16 номерів мереж 172.16.0.0 -172.31.0.0, у класі С - це діапазон з 255 мереж -192.168.0.0 - 192.168.255.0.

Для зм'якшення проблеми дефіциту адрес розробники стека TCP/IP пропонують різні підходи. Принциповим розв'язанням є перехід на нову версію IPv6, у якій різко розширюється адресний простір за рахунок використання 16-байтних адрес. Однак і поточна версія IPv4 підтримує деякі технології, спрямовані на більш ощадливу витрату IP-адрес. Однією з таких технологій є технологія масок й її розвиток — технологія безкласової міждоменної маршрутизації (Classless Inter-Domain Routing, CIDR). Технологія CIDR відмовляється від традиційної концепції розподілу адрес протоколу IP на класи, що дозволяє отримувати в користування стільки адрес, скільки реально необхідно. Завдяки CIDR постачальник послуг дістає можливість «нарізати» блоки з виділеного йому адресного простору в точній відповідності з вимогами кожного клієнта, при цьому в нього залишається простір для маневру на випадок його майбутнього зростання.

Інша технологія, що може бути використана для зняття дефіциту адрес, це трансляція адрес (Network Address Translator, NAT). Вузлам внутрішньої мережі адреси призначаються довільно (природно, відповідно до загальних правил, визначеними в стандарті), так, начебто ця мережа працює автономно. Внутрішня мережа з'єднується з Internet через деякий проміжний пристрій (маршрутизатор, міжмережевий екран). Цей проміжний пристрій отримує у своє розпорядження деяку кількість зовнішніх «нормальних» IP-адрес, погоджених з постачальником послуг або іншою організацією, що розподіляє IP-адреси. Проміжний пристрій здатний перетворювати внутрішні адреси в зовнішні, використовуючи для цього якісь таблиці відповідності. Для зовнішніх користувачів всі численні вузли внутрішньої мережі виступають під декількома зовнішніми IP-адресами. При одержанні зовнішнього запиту цей пристрій аналізує його вміст і при необхідності пересилає його у внутрішню мережу, заміняючи IP-адресу на внутрішню адресу цього вузла. Процедура трансляції адрес визначена в RFC 1631.

15.6. Автоматизація процесу призначення IP-адрес

Призначення IP-адрес вузлам мережі навіть при не дуже великому розмірі мережі може представляти для адміністратора стомлюючу процедуру. Протокол Dynamic Host Configuration Protocol (DHCP) звільняє адміністратора від цих проблем, автоматизуючи процес призначення IP-адрес.

DHCP може підтримувати спосіб автоматичного динамічного розподілу адрес, а також більш прості способи ручного й автоматичного статичного призначення адрес. Протокол DHCP працює відповідно до моделі клієнт-сервер. Під час старту системи комп'ютер, що являється DHCP-клієнтом, посилає в мережу широкомовний запит на одержання IP-адреси. DHCP-cepвер відгукується й посилає повідомлення-відповідь, що містить IP-адресу. Припускається, що DHCP-клієнт й DHCP-сервер знаходяться в одній IP-мережі.

При динамічному розподілі адрес DHCP-сервер видає адресу клієнту на обмежений час, який називається часом оренди (lease duration), що дає можливість згодом повторно використати цю IP-адресу для призначення іншому комп'ютеру. Основна перевага DHCP - автоматизація рутинної роботи адміністратора по конфігуруванню стека TCP/IP на кожному комп'ютері. Іноді динамічний розподіл адрес дозволяє будувати IP-мережу, кількість вузлів у якій перевищує кількість наявних у розпорядженні адміністратора IP-адрес.

У ручній процедурі призначення статичних адрес активну участь приймає адміністратор, що надає DHCP-серверу інформацію про відповідність IP-адрес фізичним адресам або іншим ідентифікаторам клієнтів. DHCP-сервер, користуючись цією інформацією, завжди видає певному клієнту призначену адміністратором адресу.

При автоматичному статичному способі DHCP-сервер присвоює IP-адресу з пулу наявних IP-адрес без втручання оператора. Границі пулу призначуваних адрес задає адміністратор при конфігуруванні DHCP-сервера. Адреса дається клієнту з пула в постійне користування, тобто з необмеженим строком оренди. Між ідентифікатором клієнта і його IP-адресою як і раніше при ручному призначенні, існує постійна відповідність. Вона встановлюється в момент першого призначення DHCP-сервером IP-адреси клієнту. При всіх наступних запитах сервер повертає ту ж саму IP-адресу.

DHCP забезпечує надійний і простий спосіб конфігурації мережі TCP/IP, гарантуючи відсутність дублювання адрес за рахунок централізованого управління їхнім розподілом. Адміністратор управляє процесом призначення адрес за допомогою параметра «тривалість оренди», що визначає, як довго комп'ютер може використовувати призначену IP-адресу, перед тим як знову запросити її від DHCP-сервера в оренду.

Прикладом роботи протоколу DHCP може служити ситуація, коли комп'ютер, що є DHCP-клієнтом, видаляється з підмережі. При цьому призначена йому IP-адреса автоматично звільняється. Коли комп'ютер підключається до іншої підмережі, то йому автоматично призначається нова адреса. Ні користувач, ні мережевий адміністратор не втручаються в цей процес. Ця властивість дуже важлива для мобільних користувачів.

DHCP-сервер може призначити клієнту не тільки IP-адресу клієнта, але й інші параметри стека TCP/IP, необхідні для його ефективної роботи, наприклад, маску, IP-адресу маршрутизатора за замовчуванням, IP-адресу сервера DNS, доменне ім'я комп'ютера й т.п.

15.7. Відображення IP-адрес на локальні адреси

Однією з головних задач, яка ставилася при створенні протоколу IP, було забезпечення спільної погодженої роботи в мережі, що складається з підмережей, у загальному випадку мережеві технології, що використовують різні. Безпосередньо з розв'язанням цієї задачі зв'язаний рівень міжмережевих інтерфейсів стека TCP/IP. На цьому рівні визначаються вже розглянуті вище специфікації упаковки (інкапсуляції) IP-пакетів у кадри локальних технологій. Крім цього, рівень міжмережевих інтерфейсів повинен займатися також украй важливою задачею відображення IP-адрес у локальні адреси.

Для визначення локальної адреси по IP-адресі використовується протокол дозволу адреси (Address Resolution Protocol, ARP). Протокол ARP працює різним образом залежно від того, який протокол канального рівня працює в даній мережі - протокол локальної мережі (Ethernet, Token Ring, FDDI) з можливістю широкомовного доступу одночасно до всіх вузлів мережі або ж протокол глобальної мережі (Х.25, frame relay), як правило не підтримуючий широкомовний доступ. Існує також протокол, що вирішує зворотню задачу - знаходження IP-адреси по відомій локальній адресі. Він називається реверсивним ARP (Reverse Address Resolution Protocol, RARP) і використовується при старті бездискових станцій, що не знають у початковий момент своєї IP-адреси, але знають адресу свого мережевого адаптера.

Необхідність у звертанні до протоколу ARP виникає щораз, коли модуль IP передає пакет на рівень мережевих інтерфейсів, наприклад драйверу Ethernet. IP-адреса вузла призначення відома модулю IP. Потрібно на його основі знайти Мас-адресу вузла призначення.

Робота протоколу ARP починається з перегляду так називаної ARP-таблиці (табл. 5.5). Кожен рядок таблиці встановлює відповідність між IP-адресою й Мас-адресою. Для кожної мережі, підключеної до мережевого адаптера комп'ютера або до порту маршрутизатора, будується окрема ARP-таблиця.

Поле «Тип запису» може містити одне із двох значень - «динамічний» або «статичний». Статичні записи створюються вручну за допомогою утиліти arp і не мають терміну старіння, точніше, вони існують доти, поки комп'ютер або маршрутизатор не будуть виключені. Динамічні ж записи створюються модулем протоколу ARP, що використовує широкомовні можливості локальних мережевих технологій. Динамічні записи повинні періодично обновлятися. Якщо запис не обновлявся протягом певного часу (порядку декількох хвилин), то він виключається з таблиці. Таким чином, в ARP-таблиці містяться записи не про всі вузли мережі, а тільки про ті, які беруть активну участь у мережевих операціях. Оскільки такий спосіб зберігання інформації називають кешуванням, ARP-таблиці іноді називають ARP-кеш.

У глобальних мережах адміністратору мережі найчастіше доводиться вручну формувати ARP-таблиці, у яких він задає, наприклад, відповідність IP-адреси адресі вузла мережі Х.25, що має для протоколу IP смисл локальної адреси. Останнім часом намітилася тенденція автоматизації роботи протоколу ARP й у глобальних мережах. Для цієї мети серед всіх маршрутизаторів, підключених до якої-небудь глобальної мережі, виділяється спеціальний маршрутизатор, що веде ARP-таблицю для всіх інших вузлів і маршрутизаторів цієї мережі. При такому централізованому підході для всіх вузлів і маршрутизаторів вручну потрібно задати тільки IP-адресу й локальну адресу виділеного маршрутизатора. Потім кожен вузол і маршрутизатор реєструє свої адреси у виділеному маршрутизаторі, а при необхідності встановлення відповідності між IP-адресою й локальною адресою вузол звертається до виділеного маршрутизатора із запитом й автоматично отримує відповідь без участі адміністратора. Працюючий у такий спосіб маршрутизатор називають ARP-сервером.

Отже, після того як модуль IP звернувся до модуля ARP із запитом на дозвіл адреси, відбувається пошук в ARP-таблиці зазначеної в запиті IP-адреси. Якщо така адреса в ARP-таблиці відсутня, то вихідний IP-пакет, для якого потрібно було визначити локальну адресу, ставиться в чергу. Далі протокол ARP формує свій запит (ARP-запит), вкладає його в кадр протоколу канального рівня й розсилає запит широкомовно.

Всі вузли локальної мережі отримують ARP-запит і порівнюють зазначену там IP-адресу із власною. У випадку їхнього збігу вузол формує ARP-відповідь, у якій вказує свою IP-адресу й свою локальну адресу, а потім відправляє його вже направленно, тому що в ARP-запиті відправник указує свою локальну адресу. ARP-запити й відповіді використовують той самий формат пакета. У табл. 5.6 наведені значення полів прикладу ARP-запиту для передачі по мережі Ethernet.

У полі «тип мережі» для мереж Ethernet указується значення 1.

Поле «тип протоколу» дозволяє використовувати протокол ARP не тільки для протоколу IP, але й для інших мережевих протоколів. Для IP значення цього поля дорівнює 0S00₁₆.

Довжина локальної адреси для протоколу Ethernet дорівнює 6 байт, а довжина IP-адреси - 4 байт. У полі операції для ARP-запитів указується значення 1, якщо це запит, і 2, якщо це відповідь.

Із цього запиту видно, що в мережі Ethernet вузол з IP-адресою 194.85.135.75 намагається визначити, яку Мас-адресу має інший вузол тієї ж мережі, мережева адреса якого 194.85.135.65. Поле шуканої локальної адреси заповнено нулями.

Відповідь надсилає вузол, що пізнав свою IP-адресу. Якщо в мережі немає машини із шуканою IP-адресою, то ARP-відповіді не буде. Протокол IP знищує IP-пакети, що направляються по цій адресі. (Помітимо, що протоколи верхнього рівня не можуть відрізнити випадок ушкодження мережі Ethernet від випадку відсутності машини із шуканою IP-адресою.) У табл. 5.7 поміщені значення полів ARP-відповіді, що міг би надійти на наведений вище приклад ARP-запиту.

Цю відповідь отримує машина, що зробила ARP-запит. Модуль ARP аналізує ARP-відповідь і додає запис у свою ARP-таблицю (табл. 5.8). У результаті обміну цими двома ARP-повідомленнями модуль IP-вузла 194.85.135.75 визначив, що IP-адресі 194.85.135.65 відповідає Мас-адреса 00E0F77F1920. Новий запис в ARP-таблиці з'являється автоматично, через декілька мілісекунд після того, як вона була потрібна.

15.8. Відображення доменних імен на IP-адреси

Організація доменів і доменних імен

Для ідентифікації комп'ютерів апаратне й програмне забезпечення в мережах TCP/IP покладається на IP-адреси, тому для доступу до мережевого ресурсу в параметрах програми цілком достатньо вказати IP-адресу, щоб програма правильно зрозуміла, до якого хосту їй потрібно звернутися. Наприклад, команда ftp://192.45.66.17 буде встановлювати сеанс зв'язку з потрібним ftp-сервером, а команда http://203.23.106.33 відкриє початкову сторінку на корпоративному Web-сервері. Однак користувачі звичайно воліють працювати із символьними іменами комп'ютерів, і операційні системи локальних мереж привчили їх до цього зручного способу. Отже, у мережах TCP/IP повинні існувати символьні імена хостів і механізм для встановлення відповідності між символьними іменами й IP-адресами.

В операційних системах, які спочатку розроблялися для роботи в локальних мережах, таких як Novell NetWare, Microsoft Windows або IBM OS/2, користувачі завжди працювали із символьними іменами комп'ютерів. Тому що локальні мережі складалися з невеликого числа комп'ютерів, то використовувалися так звані плоскі імена, що складаються з послідовності символів, не розділених на частини. Прикладами таких імен є: NW1_1, mail2, Kiev_SALES_2. Для встановлення відповідності між символьними іменами й Мас-адресами в цих операційних системах застосовувався механізм широкомовних запитів, подібний до механізму запитів протоколу ARP. Так, широкомовний спосіб дозволу імен реалізований у протоколі NetBIOS, на якому були побудовані багато локальних ОС. Так звані NetBIOS-імена стали на довгі роки одним з основних типів плоских імен у локальних мережах.

Для стека TCP/IP, розрахованого в загальному випадку на роботу в великих територіально розподілених мережах, подібний підхід виявляється неефективним з кількох причин.

Плоскі імена не дають можливості розробити єдиний алгоритм забезпечення унікальності імен у межах великої мережі. У невеликих мережах унікальність імен комп'ютерів забезпечує адміністратор мережі, записуючи кілька десятків імен у журналі або файл. При рості мережі задачу вирішують уже декілька адміністраторів, погоджуючи імена між собою неформальним способом. Однак якщо мережа розташована в різних містах або країнах, то адміністраторам кожної частини мережі потрібно вигадати спосіб іменування, що дозволив би їм давати імена новим комп'ютерам незалежно від інших адміністраторів, забезпечуючи в той же час унікальність імен для всієї мережі. Самий надійний спосіб розв'язання цієї задачі - відмова від плоских імен у принципі.

Широкомовний спосіб встановлення відповідності між символьними іменами й локальними адресами добре працює тільки в невеликій локальній мережі, не розділеній на підмережі. У великих мережах, де загальна широкомовність не підтримується, потрібен інший спосіб дозволу символьних імен. Звичайно гарною альтернативою широкомовність є застосування централізованої служби, що підтримує відповідність між різними типами адрес всіх комп'ютерів мережі. Компанія Microsoft для своєї корпоративної операційної системи Windows NT розробила централізовану службу WINS, що підтримує базу даних NetBIOS-імен і відповідних їм IP-адрес.

Для ефективної організації іменування комп'ютерів у великих мережах природним є застосування ієрархічних складених імен.

У стеці TCP/IP застосовується доменна система імен, що має ієрархічну деревовидну структуру, що допускає використання в імені довільної кількості складових частин (мал. 5.11).

Ієрархія доменних імен аналогічна ієрархії імен файлів, прийнятої в багатьох популярних файлових системах. Дерево імен починається з кореня, позначеного тут точкою (.). Потім слідує старша символьна частина імені, друга по старшинству символьна частина імені й т.д. Молодша частина імені відповідає кінцевому вузлу мережі. На відміну від імен файлів, при записі яких спочатку вказується сама старша складова, потім складова більш низького рівня й т.д., запис доменного імені починається із самої молодшої складової, а закінчується самою старшою. Складові частини доменного імені відокремлюється друг від друга точкою. Наприклад, в імені partnering.microsoft.com складова partnering є ім'ям одного з комп'ютерів у домені microsoft.com.

Поділ імені на частині дозволяє розділити адміністративну відповідальність за призначення унікальних імен між різними людьми або організаціями в межах свого рівня ієрархії. Так, для приклада, наведеного на мал. 5.11, одна людина може відповідати за те, щоб всі імена, які мають закінчення «uа», мали унікальну наступну вниз по ієрархії частину. Якщо ця людина справляється зі своїми обов'язками, то всі імена типу www.uа, mailmmt.uf або m2.zil.mmt.ua будуть відрізнятися другою по старшинству частиною.

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

Сукупність імен, у яких кілька старших складових частин збігаються, утворюють домен імен (domain). Наприклад, імена wwwl.zil.mmt.uа, ftp.zil.mmt.uа, meta.ua й sl.iir.uf входять у домен ua, тому що всі ці імена мають одну загальну старшу частину - ім'я uа. Іншим прикладом є домен mgu.ru. Із представлених на мал. 5.11 імен у нього входять імена sl.mgu.ru, s2.mgu.ru й rn.mgu.ru. Цей домен утворять імена, у яких дві старші частини завжди рівні mgu.ru. Ім'я www.mmt.ru у домен mgu.ru не входить, тому що має складову, що відрізняється, mmt.

Якщо один домен входить в інший домен як його складова частина, то такий домен можуть називати піддоменом (subdomain),хоча назва домен за ним також залишається. Звичайно піддомен називають по імені тієї його старшої складової, що відрізняє його від інших піддоменів. Наприклад, піддомен mmt.ru звичайно називають піддоменом (або доменом) mmt. Ім'я піддомену призначає адміністратор вищестоящого домена. Гарною аналогією домена є каталог файлової системи.

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

За аналогією з файловою системою, у доменній системі імен розрізняють короткі імена, відносні імена й повні доменні імена. Коротке ім'я — це ім'я кінцевого вузла мережі: хоста або порту маршрутизатора. Коротке ім'я — це лист дерева імен. Відносне ім'я — це складене ім'я, що починається з деякого рівня ієрархії, але не самого верхнього. Наприклад, wwwl.zil — це відносне ім'я. Повне доменне ім'я (fully qualified domain name, FQDN) включає складові всіх рівнів ієрархії, починаючи від короткого імені й кінчаючи кореневою точкою: wwwl.zu.mmt.ru.

Необхідно підкреслити, що комп'ютери що входять у домен у відповідності зі своїми складеними іменами, при цьому вони можуть мати зовсім різні IP-адреси, що належать до різних мереж і підмереж. Наприклад, у домен mgu.ru можуть входити хости з адресами 132.13.34.15, 201.22.100.33,14.0.0.6. Доменна система імен реалізована в мережі Internet, але вона може працювати і як автономна система імен у великій корпоративній мережі, що використовує стек TCP/IP, але не пов'язаної з Internet.

В Internet кореневий домен управляється центром InterNIC. Домени верхнього рівня призначаються для кожної країни, а також на організаційній основі. Імена цих доменів повинні додержуватися міжнародного стандарту ISO 3166. Для позначення країн використовуються трибуквені й двобуквені абревіатури, а для різних типів організацій - наступні позначення:

• com - комерційні організації (наприклад, microsoft.com);

• edu - освітні (наприклад, mit.edu);

• gov - урядові організації (наприклад, nsf.gov);

• org - некомерційні організації (наприклад, fidonet.org);

• net - організації, що підтримують мережі (наприклад, nsf.net).

Кожен домен адмініструєтся окремою організацією, що звичайно розбиває свій домен на піддомени й передає функції адміністрування цих піддоменів іншим організаціям. Щоб отримати доменне ім'я, необхідно зареєструватися в якій-небудь організації, який InterNIC делегували свої повноваження по розподілу імен доменів.

15.9 Система доменних імен DNS

Відповідність між доменними іменами й IP-адресами може встановлюватися як засобами локального хоста, так і засобами централізованої служби. На ранньому етапі розвитку Internet на кожному хосту вручну створювався текстовий файл із відомим іменем hosts. Цей файл складався з деякої кількості рядків, кожен з яких містив одну пару «IP-адреса - доменне ім'я», наприклад 102.54.94.97 - rhino.acme.com.

По мірі зростання Internet файли hosts також зростали, і створення масштабованого рішення для дозволу імен стало необхідністю.

Таким рішенням стала спеціальна служба — система доменних імен (Domain Name System, DNS).DNS - це централізована служба, заснована на розподіленій базі відображень «доменне ім'я - IP-адреса». Служба DNS використовує у своїй роботі протокол типу «клієнт-сервер». У ньому визначені DNS-сервери й DNS-клієнти. DNS-сервери підтримують розподілену базу відображень, а DNS-клієнти звертаються до серверів із запитами про дозвіл доменного імені в IP-адресу.

Служба DNS використовує текстові файли майже такого формату, як і файл hosts, і ці файли адміністратор також підготовляє вручну. Однак служба DNS спирається на ієрархію доменів, і кожен сервер служби DNS зберігає тільки частину імен мережі, а не всі імена, як це відбувається при використанні файлів hosts. При збільшенні кількості вузлів у мережі проблема масштабування вирішується створенням нових доменів і піддоменів імен і додаванням у службу DNS нових серверів.

Для кожного домена імен створюється свій DNS-сервер. Цей сервер може зберігати відображення «доменне ім'я - IP-адреса» для всього домена, включаючи всі його піддомени. Однак при цьому рішення виявляється погано масштабованим, тому що при додаванні нових піддоменів навантаження на цей сервер може перевищити його можливості. Частіше сервер домена зберігає тільки імена, які закінчуються на наступному нижче рівні ієрархії в порівнянні з ім'ям домена. (Аналогічно каталогу файлової системи, що містить записи про файли й підкаталоги, безпосередньо в нього «вхідні».) Саме при такій організації служби DNS навантаження з дозволу імен розподіляється більш-менш рівномірно між всіма DNS-серверами мережі. Наприклад, у першому випадку DNS-сервер домена mmt.ru буде зберігати відображення для всіх імен, що закінчуються на mmt.ru: wwwl.zil.mmt.ru, ftp.zil.mmt.ru, mau.mmt.ru і т.д. У другому випадку цей сервер зберігає відображення тільки імен типу mail.mmt.ru, www.mmt.ru, а всі інші відображення повинні зберігатися на DNS-сервері піддомена zil.

Кожен DNS-сервер крім таблиці відображень імен містить посилання на DNS-сервери своїх піддоменів. Ці посилання зв'язують окремі DNS-сервери в єдину службу DNS. Посилання являють собою IP-адреси відповідних серверів. Для обслуговування кореневого домена виділено декілька дублюючих один одного DNS-серверів, IP-адреси яких є широко відомими (їх можна довідатися, наприклад, в InterNIC).

Процедура дозволу DNS-імені багато в чому аналогічна процедурі пошуку файловою системою адреси файлу по його символьному імені. Дійсно, в обох випадках складене ім'я відображає ієрархічну структуру організації відповідних довідників - каталогів файлів або таблиць DNS. Тут домен і доменний DNS-сервер є аналогом каталогу файлової системи. Для доменних імен, так само як і для символьних імен файлів, характерна незалежність іменування від фізичного місця розташування.

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

Існують дві основні схеми дозволу DNS-імен. У першому варіанті роботу з пошуку IP-адреси координує DNS-клієнт:

• DNS-клієнт звертається до кореневого DNS-сервера із зазначенням повного доменного імені;

• DNS-сервер відповідає, указуючи адресу наступного DNS-сервера, що обслуговує домен верхнього рівня, заданий в старшій частині запитаного імені;

• DNS-клієнт робить запит наступного DNS-сервера, що відсилає його до DNS-сервера потрібного піддомена, і т.д., поки не буде знайдений DNS-сервер, у якому зберігається відповідність запитаного імені IP-адресі. Цей сервер дає остаточну відповідь клієнту.

Така схема взаємодії називається нерекурсивною або ітеративною, коли клієнт сам ітеративно виконує послідовність запитів до різних серверів імен. Тому що ця схема завантажує клієнта досить складною роботою, то вона застосовується рідко.

У другому варіанті реалізується рекурсивна процедура:

• DNS-клієнт запитує локальний DNS-сервер, тобто той сервер, що обслуговує піддомен, до якого належить ім'я клієнта;

• якщо локальний DNS-сервер знає відповідь, то він відразу ж повертає його клієнту; це може відповідати випадку, коли запитане ім'я входить у той же піддомен, що й ім'я клієнта, а також може відповідати випадку, коли сервер уже дізнавався дану відповідність для іншого клієнта й зберіг його у своєму кеші;

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

У цій схемі клієнт передоручає роботу своєму серверу, тому схема називається непрямою або рекурсивною. Практично всі DNS-клієнти використовують рекурсивну процедуру.

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