Протоколи TCPIP

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.


Нажми чтобы узнать.
скачати

Введення

Стек протоколів TCP / IP тісно пов'язаний з мережею Internet, її історією та сучасністю. Створений він був у 1969 році, коли для мережі ARPANET знадобився ряд стандартів для об'єднання в єдину мережу комп'ютерів з різними архітектурами та операційними системами. На базі цих стандартів і був розроблений набір протоколів, що отримали назву TCP / IP. Разом зі зростанням Internet протокол TCP / IP завойовував позиції і в інших мережах. На сьогоднішній день цей мережевий протокол використовується як для зв'язку комп'ютерів всесвітньої мережі, так і в переважній більшості корпоративних мереж. У наші дні використовується версія протоколу IP, відома як IPv4. У статті ми розглянемо стандартну схему адресації і більше нові методи раціонального використання адресного простору, введені в результаті виявлених недоліків у реалізації протоколу IP.

1. Адресація протоколу IP

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

Спочатку всі адресний простір розділили на п'ять класів: A, B, C, D і Е. Така схема отримала назву "класової". Кожен клас однозначно ідентифікувався першими бітами лівого байта адреси. Самі ж класи відрізнялися розмірами мережевої та вузловий частин. Знаючи клас адреси, ви могли визначити межу між його мережевий і вузловий частинами. Крім того, така схема дозволяла при маршрутизації не передавати разом з пакетом інформацію про довжину мережної частини IP-адреси.

Таблиця 1-Іеархіческая схема протоколів IP

Клас А
Номер біта 0 8 16 24 31
Адреса 0 ....... ........ ........ ........
Мережева частина
Клас В
Номер біта 0 8 16 24 31
Адреса 10 ...... ........ ........ ........
Мережева частина
Клас С
Номер біта 0 8 16 24 31
Адреса 110 ..... ........ ........ ........
Мережева частина
Клас D
Номер біта 0 8 16 24 31
Адреса 1110 .... ........ ........ ........
Клас E
Номер біта 0 8 16 24 31
Адреса 1111 .... ........ ........ ........

Клас А орієнтований на дуже великі мережі. Всі адреси, що належать цьому класу, мають 8-бітний мережний префікс, на що вказує перший біт лівого байта адреси встановлений в нуль. Відповідно, на ідентифікацію вузла відведено 24 біта і кожна мережа "вісімка" може містити до 224-2 вузлів. Два адреси необхідно відняти, оскільки адреси, що містять у правому октеті всі нулі (ідентифікує вказану мережу) і всі одиниці (широкомовний адреса) використовуються в службових цілях і не можуть бути присвоєні вузлів. Самих же мереж "вісімок" може бути 27-2. Знову ми віднімаємо двійку, але це вже дві службових мережі: 127 / 8 і 0 / 8 (по-старому: 127.0.0.0 і 0.0.0.0). Нарешті, можна помітити, що клас А містить всього 27 * 224 = 231 адрес, або половину всіх можливих IP-адрес. Клас В призначений для мереж великого і середнього розмірів. Адреси цього класу ідентифікуються двома старшими бітами, рівними відповідно 1 і 0. Мережевий префікс класу складається з шістнадцяти біт або перших двох октетів адреси. Оскільки два перших біта мережевого префікса зайняті визначальним клас ключем, то можна задати лише 214 різних мереж. Вузлів ж у кожної мережі можна визначити до 216-2. У деяких джерелах, для визначення кількості можливих мереж використовується формула 2х-2 для всіх класів, а не тільки для А. Це пов'язано з певними причинами, які більш детально будуть викладені нижче. На сьогоднішній день немає ніякої необхідності зменшувати кількість можливих мереж на дві. Провівши обчислення, аналогічні наведеним для класу А, ми побачимо, що клас У займає чверть адресного простору протоколу IPНаконец, самий вживається клас мереж - клас С-має 24 бітний мережний префікс, визначається старшими бітами, встановленими в 110, і може ідентифікувати до 221 мереж . Відповідно, клас дозволяє адресувати до 28-2 вузлів. Займає восьму частину адресного простору протоколу TCP / IP. Останні два класи займають залишилася восьму частину в адресному просторі і призначені для службового (клас D) та експериментального (клас Е) використання. Для класу D старші чотири біта адреси встановлені в 1110, для класу Е - 1111. Сьогодні клас D використовується для групової передачі інформації. Оскільки довгі послідовності з одиниць і нулів важко запам'ятати, IP адреси звичайно записують у десятковій формі. Для цього кожен октет адреси представляється у вигляді десяткового числа. Між собою октети відокремлюються крапкою. Іноді октети позначаються як wxyz і називаються "z-октет", "y-октет", "x-октет" і "w-октет". Представлення IP-адреси у вигляді чотирьох десяткових чисел розділених точками і називається "точково-десяткова нотація".

Октет W X Y Z
Номер біта 0 8 16 24 31
Адреса 11011100 11010111 00001110 00010110
220 215 14 22
Точково-десятковий формат 220.215.14.22

Малюнок 1 - IP в точково-десяткового нотації

На рис. 1 показано, як IP-адреса представляється у точково-десяткового нотації.

Підсумуємо інформацію про класи мереж в таблиці:

Таблиця 2 - Класова мережу

Клас Кількість мереж Кількість вузлів Десятковий діапазон
A 27 - 2 (126) 224 - 2 (2 147 483 648) 1.ххх.ххх.ххх 126.ххх.ххх.ххх
B 214 (16 384) 216 - 2 (65 534) 128.0.ххх.ххх 191.255.ххх.ххх
C 221 (2 097 152) 28 - 2 (254) 192.0.0.ххх 223.255.255.ххх
D - - 224.0.0.ххх 239.255.255.ххх
E - - 240.0.0.ххх 254.255.255.ххх

1.1 Угода про спеціальні:: broadcast, multicast, loopback

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

якщо IР-адреса складається тільки з двійкових нулів,

0 0 0 0 ................................... 0 0 0 0

то він позначає адресу того вузла, який згенерував цей пакет;

якщо в поле номера мережі коштують 0,

0 0 0 0 ....... 0 Номер вузла

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

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

1 1 1 1 ......................................... 1 січня

Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast);

якщо в поле адреси призначення коштують суцільні 1,

Номер мережі 1111 ................ 11

то пакет, що має таку адресу розсилається всім вузлам мережі із заданим номером. Така розсилка називається широкомовним повідомленням (broadcast); адреса 127.0.0.1 зарезервований для організації зворотного зв'язку при тестуванні роботи програмного забезпечення вузла без реального відправлення пакета по мережі. Ця адреса має назва loopback.

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

1.2 Відображення фізичних адрес на IP-адреси: протоколи ARP і RARP

У протоколі IP-адресу сайту, тобто адреса комп'ютера або порту маршрутизатора, призначається довільно адміністратором мережі й прямо не пов'язаний з його локальною адресою, як це зроблено, наприклад, у протоколі IPX. Підхід, використовуваний в IP, зручно використовувати у великих мережах і через його незалежності від формату локальної адреси, і через стабільності, тому що в противному випадку, при зміні на комп'ютері мережного адаптера ця зміна повинні б були враховувати всі адресати всесвітньої мережі Internet ( в тому випадку, звичайно, якщо мережа підключена до Internet'у). Локальний адреса використовується в протоколі IP тільки в межах локальної мережі при обміні даними між маршрутизатором і вузлом цієї мережі. Маршрутизатор, одержавши пакет для вузла однієї з мереж, безпосередньо підключених до його портів, повинен для передачі пакета сформувати кадр відповідно до вимог прийнятої в цій мережі технології і вказати в ньому локальна адреса вузла, наприклад його МАС-адресу. У прийшов пакеті ця адреса не вказано, тому перед маршрутизатором встає задача пошуку його по відомому IP-адресою, яка зазначена в пакеті як адреси призначення. З аналогічною задачею зіштовхується й кінцевий вузол, коли він хоче відправити пакет у вилучену мережу через маршрутизатор, підключений до тієї ж локальної мережі, що і цей вузол. Для визначення локальної адреси по IP-адресою використовується протокол дозволу адреси Address Resolution Protocol, ARP. Протокол ARP працює різним образом залежно від того, який протокол канального рівня працює в даній мережі - протокол локальної мережі (Ethernet, Token Ring, FDDI) з можливістю широкомовного доступу одночасно до всіх вузлів мережі, або ж протокол глобальної мережі (X.25, frame relay), як правило не підтримуючий широкомовний доступ. Існує також протокол, що вирішує зворотну задачу - знаходження IP-адреси за відомим локального адресою. Він називається реверсивний ARP - RARP (Reverse Address Resolution Protocol) і використовується при старті бездискових станцій, що не знають у початковий момент свого IP-адреси, але знаючих адресу свого мережного адаптера. У локальних мережах протокол ARP використовує широкомовні кадри протоколу канального рівня для пошуку в мережі вузла із заданим IP-адресою. Вузол, якому потрібно виконати відображення IP-адреси на локальну адресу, формує ARP запит, вкладає його в кадр протоколу канального рівня, указуючи в ньому відомий IP-адресу, і розсилає запит широкомовно. Всі вузли локальної мережі одержують ARP запит і порівнюють зазначений там IP-адресу із власним. У разі їх збігу вузол формує ARP-відповідь, в якій вказує свій IP-адресу і свій локальний адресу і відправляє його вже направлено, тому що в ARP запиті відправник зазначає свою локальну адресу. ARP-запити і відповіді використовують один і той же формат пакета. Так як локальні адреси можуть у різних типах мереж мати різну довжину, то формат пакета протоколу ARP залежить від типу мережі. На малюнку 2 показаний формат пакета протоколу ARP для передачі по мережі Ethernet.

Тип мережі Тип протоколу
Довжина локальної адреси Довжина мережевого адреси Операція
Локальний адресу відправника (байти 0 - 3)
Локальний адресу відправника (байти 4 - 5) IP-адреса відправника (байти 0-1)
IP-адреса відправника (байти 2-3) Бажаємий локальну адресу (байти 0 - 1)
Бажаємий локальну адресу (байти 2-5)
Бажаємий IP-адреса (байти 0 - 3)

Рисунок 2 - Формат пакета протоколу ARP

У полі типу мережі для мереж Ethernet вказується значення 1. Поле типу протоколу дозволяє використовувати пакети ARP не тільки для протоколу IP, але і для інших мережевих протоколів. Для IP значення цього поля дорівнює 080016. Довжина локальної адреси для протоколу Ethernet дорівнює 6 байтам, а довжина IP-адреси - 4 байтам. У полі операції для ARP запитів вказується значення 1 для протоколу ARP і 2 для протоколу RARP. Вузол, що відправляє ARP-запит, заповнює в пакеті всі поля, крім поля шуканого локальної адреси (для RARP-запиту не вказується шуканий IP-адресу). Значення цього поля заповнюється вузлом, упізнав свою IP-адресу. У глобальних мережах адміністратора мережі найчастіше доводиться вручну формувати ARP-таблиці, в яких він задає, наприклад, відповідність IP-адреси адресою вузла мережі X.25, який має сенс локальної адреси. Останнім часом намітилася тенденція автоматизації роботи протоколу ARP і в глобальних мережах. Для цієї мети серед всіх маршрутизаторів, підключених до якої-небудь глобальної мережі, виділяється спеціальний маршрутизатор, який веде ARP-таблицю для всіх інших вузлів і маршрутизаторів цієї мережі. При такому підході централізованому для всіх вузлів і маршрутизаторів вручну потрібно встановити тільки IP-адресу і локальний адресу виділеного маршрутизатора. Потім кожен вузол і маршрутизатор реєструє свої адреси в виділеному маршрутизаторі, а при необхідності встановлення відповідності між IP-адресою і локальною адресою вузол звертається до виділеного маршрутизатора з запитом і автоматично отримує відповідь без участі адміністратора.

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

Для ідентифікації комп'ютерів апаратне та програмне забезпечення в мережах 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, MOSCOW_ SALES_2. Для встановлення відповідності між символьними іменами й Мас-адресами в цих операційних системах застосовувався механізм широкомовних запитів, подібний механізму запитів протоколу ARP. Так, широкомовний спосіб дозволу Імен реалізований в протоколі NetBIOS, на якому були побудовані багато локальних ОС. Так звані NetBIOS-імена стали на довгі роки одним з основних типів плоских імен у локальних мережах. Для стека TCP / IP, розрахованого в загальному випадку на роботу у великих територіально розподілених мережах, подібний підхід виявляється неефективним з кількох причин. Плоскі імена не дають можливості розробити єдиний алгоритм забезпечення унікальності імен у межах великої мережі. У невеликих мережах унікальність імен комп'ютерів забезпечує адміністратор мережі, записуючи кілька десятків імен у журналі або файлі. При зростанні мережі задачу вирішують уже кілька адміністраторів, погоджуючи імена між собою неформальним способом. Однак якщо мережа розташована в різних містах або країнах, то адміністраторам кожної частини мережі потрібно придумати спосіб іменування, який дозволив би їм давати імена новим комп'ютерам незалежно від інших адміністраторів, забезпечуючи в той же час унікальність імен для всієї мережі. Найнадійніший спосіб вирішення цього завдання - відмова від плоских імен у принципі. Широкомовна спосіб встановлення відповідності між символьними іменами й локальними адресами добре працює тільки в невеликій локальній мережі, не розділеній на підмережі. У великих мережах, де загальна широкомовного не підтримується, потрібен інший спосіб дозволу символьних імен. Зазвичай хорошою альтернативою широкомовного є застосування централізованої служби, що підтримує відповідність між різними типами адрес всіх комп'ютерів мережі. Компанія Microsoft для своєї корпоративної операційної системи Windows NT розробила централізовану службу WINS, яка підтримує базу даних NetBIOS-імен і відповідних їм IP-адрес. Для ефективної організації іменування комп'ютерів у великих мережах природним є застосування ієрархічних складових імен. У стеці TCP / IP застосовується доменна система імен, яка має ієрархічну деревоподібну структуру, яка допускає використання в імені довільної кількості складових частин (рис. 3).

Протоколи TCP / IP

Рисунок 3 - Простір доменних імен

Ієрархія доменних імен аналогічна ієрархії імен файлів, прийнятої в багатьох популярних файлових системах. Дерево імен починається з кореня, що позначається тут точкою (.). Потім слід старша символьна частина імені, друга за старшинством символьна частина імені і т. д. Молодша частина імені відповідає кінцевому вузлу мережі. На відміну від імен файлів, при записі яких спочатку вказується сама старша складова, потім складова більш низького рівня і т. д., запис доменного імені починається з самої молодшої складової, а закінчується самою старшою. Складові частини доменного імені відокремлюється один від одного крапкою. Наприклад, в імені partnering.microsoft.com складова partnering є ім'ям одного з комп'ютерів у домені microsoft.com.Разделеніе імені на частини дозволяє розділити адміністративну відповідальність за призначення унікальних імен між різними людьми або організаціями в межах свого рівня ієрархії. Так, для прикладу, наведеного на рис.1.3, одна людина може нести відповідальність за те, щоб всі імена, які мають закінчення «ru», мали унікальну наступну вниз по ієрархії частину. Якщо ця людина справляється зі своїми обов'язками, то всі імена типу www.ru, mail.mmt.ru або m2.zil.mmt.ru будуть відрізнятися другий за старшинством частиною.

Поділ адміністративної відповідальності дозволяє вирішити проблему утворення унікальних імен без взаємних консультацій між організаціями, відповідальними за імена одного рівня ієрархії. Очевидно, що повинна існувати одна організація, що відповідає за призначення імен верхнього рівня ієрархії. Сукупність імен, у яких кілька старших складових частин збігаються, утворюють домен {domain) імен. Наприклад, імена www1.zil.mmt.ru, ftp.zil.mmt.ru, yauidex.ru і s1. Mgu.ru входять в домен ru, тому що всі ці імена мають одну загальну старшу частину - ім'я ru. Іншим прикладом є домен mgu.ru. З представлених на рис. 3 імен в нього входять імена s1.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. Zil.mmt.ru.Корневой домен управляється центральними органами Інтернету: IANA і InterNIC. Домени верхнього рівня призначаються для кожної країни, а також на організаційній основі. Імена цих доменів повинні випливати міжнародному стандарту ISO 3166. Для позначення країн використовуються трибуквені і дволітерні абревіатури, наприклад, ru (Росія), uk (Велика Британія), fin (Фінляндія), us (Сполучені Штати), а для різних типів організацій - наступні позначення:

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

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

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

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

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

Кожен домен адмініструється окремою організацією, яка зазвичай розбиває свій домен на піддомени і передає функції адміністрування цих піддоменів іншим організаціям. Щоб отримати доменне ім'я, необхідно зареєструватися в якій-небудь організації, якій організація InterNIC делегувала свої повноваження з розподілу імен доменів. У Росії такою організацією є РОСНІЇРОС, яка відповідає за делегування імен піддоменів в домені ru. Необхідно підкреслити, що комп'ютери входять в домен у відповідності зі своїми складовими іменами, при цьому вони можуть мати абсолютно незалежні один від одного IP-адреси, що належать до різних мереж і подсетям. Наприклад, в домен mgu.ru можуть входити хости з адресами 132.13.34.15, 201.22.100.33 і 14.0.0.6.

Доменна система імен реалізована в Інтернеті, але вона може працювати і як автономна система імен у будь-якої великої корпоративної мережі, яка також використовує стек TCP / IP, але ніяк не пов'язана з Інтернетом.

1.4 Автоматизація процесу порядку призначення IP-адрес вузлами мережі протокол DHCP

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

У великих мережах, подібних Інтернету, унікальність мережевих адрес гарантується централізованою, ієрархічно організованою системою їх розподілу. Головним органом реєстрації глобальних адрес в Інтернеті з 1998 року є ICANN (Internet Corporation for Assigned Names and Numbers) - неурядова некомерційна організація, керована радою директорів. Ця організація координує роботу регіональних відділів, діяльність яких охоплює великі географічні площі: ARIN (Америка), RIPE (Європа), APNIC (Азія і Тихоокеанський регіон). Регіональні відділи виділяють блоки адрес мереж великим постачальникам послуг, ті, у свою чергу привласнюють їх своїм клієнтам, серед яких можуть бути ц більш дрібні постачальники послуг.

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

Протоколи TCP / IP

Малюнок 4 - Нераціональне використання простору IP-адрес

Якщо ж деяка IP-мережа створена для роботи в «автономному режимі», без зв'язку з Інтернетом, тоді адміністратор цієї мережі вільний призначити їй довільно вибраний номер. Але і в цій ситуації для того, щоб уникнути будь-яких колізій, в стандартах Інтернету визначено декілька адрес, рекомендованих для автономного використання: у класі А - це мережа 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 постачальник послуг одержує можливість «нарізати» блоки з виділеного йому адресного простору в точній відповідності до вимог кожного клієнта. Як вже було сказано, IP-адреси можуть призначатися адміністратором мережі вручну. Це становить для адміністратора тяжку процедуру. Ситуація ускладнюється ще тим, що багато користувачів не володіють достатніми знаннями для того, щоб конфігурувати свої комп'ютери для роботи в інтермережі і тому повинні покладатися на адміністраторів. Протокол Dynamic Host Configuration Protocol (DHCP) був розроблений для того, щоб звільнити адміністратора від цих проблем. Основним призначенням DHCP є динамічне призначення IP-адрес. Однак, крім динамічного, DHCP може підтримувати і більш прості способи ручного й автоматичного статичного призначення адрес. У ручній процедуру призначення адрес активну участь приймає адміністратор, який надає DHCP-серверу інформацію про відповідність IP-адрес фізичним адресами або іншим ідентифікаторів клієнтів. Ці адреси повідомляються клієнтам у відповідь на їхні запити до DHCP-сервера. При автоматичному статичному способі DHCP-сервер привласнює IP-адреса (і, можливо, інші параметри конфігурації клієнта) з пулу готівкових IP-адрес без втручання оператора. Межі пулу призначаються адрес задає адміністратор при конфігуруванні DHCP-сервера. Між ідентифікатором клієнта і його IP-адресою, як і раніше, як і при ручному призначення, існує постійна відповідність. Воно встановлюється в момент первинного призначення сервером DHCP IP-адреси клієнта. При всіх наступних запитах сервер повертає той же самий IP-адресу. При динамічному розподілі адрес DHCP-сервер видає адреса клієнту на обмежений час, що дає можливість згодом повторно використовувати IP-адреси іншими комп'ютерами. Динамічне розділення адрес дозволяє будувати IP-мережу, кількість вузлів у якої набагато перевищує кількість наявних у розпорядженні адміністратора IP-адрес. DHCP забезпечує надійний і простий спосіб конфігурації мережі TCP / IP, гарантуючи відсутність конфліктів адрес за рахунок централізованого управління їх розподілом. Адміністратор управляє процесом призначення адрес за допомогою параметра "тривалості оренди" (lease duration), яка визначає, як довго комп'ютер може використовувати призначений IP-адреса, перед тим як знову запросити його від сервера DHCP в оренду. Прикладом роботи протоколу DHCP може служити ситуація, коли комп'ютер, що є клієнтом DHCP, видаляється з підмережі. При цьому призначений йому IP-адресу автоматично звільняється. Коли комп'ютер підключається до іншої підмережі, то йому автоматично призначається новий адресу. Ні користувач, ні адміністратор не втручаються в цей процес. Ця властивість дуже важливо для мобільних користувачів. Протокол DHCP використовує модель клієнт-сервер. Під час старту системи комп'ютер-клієнт DHCP, що знаходиться в стані "ініціалізація", надсилає повідомлення discover (досліджувати), яке широкомовно поширюється по локальній мережі і передається всім DHCP-серверів приватної інтермережі. Кожен DHCP-сервер, що отримав це повідомлення, відповідає на нього повідомленням offer (пропозицію), яке містить IP-адресу та конфігураційну інформацію. Комп'ютер-клієнт DHCP переходить в стан "вибір" і збирає конфігураційні пропозиції від DHCP-серверів. Потім він вибирає один з цих пропозицій, переходить в стан "запит" і відправляє повідомлення request (запит) тому DHCP-сервера, чиє пропозицію було обрано. Обраний DHCP-сервер посилає повідомлення DHCP-acknowledgment (підтвердження), що містить той же IP-адресу, який вже був посланий раніше на стадії дослідження, а також параметр оренди для цієї адреси. Крім того, DHCP-сервер посилає параметри мережевої конфігурації. Після того, як клієнт отримає це підтвердження, він переходить у стан "зв'язок", перебуваючи в якому він може приймати участь в роботі мережі TCP / IP. Комп'ютери-клієнти, які мають локальні диски, зберігають отриманий адресу для використання при наступних стартах системи. При наближенні моменту закінчення терміну оренди адреси комп'ютер намагається оновити установки оренди у DHCP-сервера, а якщо цей IP-адреса не може бути виділений знову, то йому повертається інший IP-адресу. У протоколі DHCP описується кілька типів, які використовуються для виявлення і вибору DHCP-серверів, для запитів інформації про конфігурацію, для продовження та дострокового припинення ліцензії на IP-адресу. Всі ці операції спрямовані на те, щоб звільнити адміністратора мережі від утомливих рутинних операцій по конфігурації мережі. Проте використання DHCP несе в собі й деякі проблеми. По-перше, це проблема узгодження інформаційної адресної бази в службах DHCP і DNS. Як відомо, DNS служить для перетворення символьних імен в IP-адреси. Якщо IP-адреси будуть динамічно зміняться сервером DHCP, то ці зміни необхідно також динамічно вносити в базу даних DNS-сервера. Хоча протокол динамічної взаємодії між службами DNS і DHCP вже реалізований деякими фірмами (так звана служба Dynamic DNS), стандарт на нього поки не прийнятий. По-друге, нестабільність IP-адрес ускладнює процес управління мережею. Системи управління, засновані на протоколі SNMP, розроблені з розрахунком на статичність IP-адрес. Аналогічні проблеми виникають і при конфігуруванні фільтрів маршрутизаторів, які оперують з IP-адресами. Нарешті, централізація процедури призначення адрес знижує надійність системи: при відмові DHCP-сервера всі його клієнти виявляються не в змозі отримати IP-адресу та іншу інформацію про конфігурації. Наслідки такої відмови можуть бути зменшені шляхом використання в мережі декількох серверів DHCP, кожен з яких має свій пул IP-адрес. Як вже зазначалося, в адресній схемі протоколу виділяють особливі IP-адреси. Якщо біти всіх октетів адреси рівні нулю, то він позначає адресу того вузла, який згенерував цей пакет. Це використовується в обмежених випадках, наприклад у деяких повідомленнях протоколу IP. Якщо біти мережевого префікса дорівнюють нулю, вважається, що вузол призначення належить тій же мережі, що й джерело пакета. Коли біти всіх октетів адреси призначення рівні двійкової одиниці, пакет доставляється всім вузлам, що належить тій самій мережі, що відправника пакету. Така розсилка називається обмеженим широкомовлення. Нарешті, якщо в бітах адреси, відповідних вузлу призначення, стоять одиниці, то такий пакет розсилається всім вузлам зазначеної мережі. Це називається широкомовлення. Спеціальне значення має, так само, адреси мережі 127 / 8. Вони використовуються для тестування програм і взаємодії процесів у межах однієї машини. Пакети, відправлені на цей інтерфейс, обробляються локально, як вхідні. Тому адреси з цієї мережі не можна присвоювати фізичним мережевим інтерфейсам.

2. Організація підмереж

Дуже рідко в локальну обчислювальну мережу входить більше 100-200 вузлів: навіть якщо взяти мережу з великою кількістю вузлів, багато мережевих середовища накладають обмеження, наприклад, в 1024 вузла. Виходячи з цього, доцільність використання мереж класу А і В вельми сумнівна. Та й використання класу С для мереж, що складаються з 20-30 вузлів, теж є марнотратством. Для вирішення цих проблем у дворівневу ієрархію IP-адрес (мережа - вузол) була введена нова складова - підмережа. Ідея полягає в "запозичення" кількох бітів з вузлової частини адреси для визначення підмережі. Повний префікс мережі, що складається з мережевого префікса і номера підмережі, отримав назву розширеного мережного префікса. Двійкове число, і його десятковий еквівалент, що містить одиниці у розрядах, які відносяться до розширеного мережного префікса, а в інших розрядах - нулі, назвали маскою підмережі. Але маску в десятковому поданні зручно використовувати лише тоді, коли розширений мережевий префікс закінчується на кордоні октетів, в інших випадках її розшифрувати складніше. Припустимо, що ми хотіли б для підмережі використовувати не 8 біт, а десять. Тоді в останньому (z-ом) октеті ми мали б не нулі, а число 11000000. У десятковому поданні отримуємо 255.255.255.192. Очевидно, що таке подання не дуже зручно. У наш час найчастіше використовують позначення виду "/ xx", де хх - кількість біт у розширеному мережевому префіксі. Таким чином, замість вказівки: "144.144.19.22 з маскою 255.255.255.192", ми можемо записати: 144.144.19.22/26. Як видно, таке подання більш компактно і зрозуміло.

2.1 Маска під мережі змінної довжини (Variable Length Subnet Mask)  

Однак незабаром стало ясно, що підмережі, незважаючи на всі їхні переваги, володіють і недоліками. Так, визначивши одного разу маску підмережі, доводиться використовувати підмережі фіксованих розмірів. Скажімо, у нас є мережа 144.144.0.0/16 з розширеним префіксом / 23.

Таблиця 3 - З розширений префікс

Мережевий префікс Підмережа Вузол
144.144.0.0/23 10010000 10010000 0000000 0 00000000
Розширений мережевої префікс

Така схема дозволяє створити 27 підмереж розміром в 29 вузлів кожна. Це підходить до випадку, коли є багато підмереж з великою кількістю вузлів. Але якщо серед цих мереж є такі, кількість вузлів у яких знаходиться в межах ста, то в кожній з них буде пропадати близько 400 адрес. Рішення полягає в тому, що б для однієї мережі вказувати більше одного розширеного мережного префікса. Про таку мережі кажуть, що це мережа з маскою підмережі змінної довжини (VLSM). Дійсно, якщо для мережі 144.144.0.0/16 використовувати розширений мережевий префікс / 25, то це більше б підходила мереж розмірами близько ста вузлів. Якщо допустити використання обох масок, то це б значно збільшило гнучкість застосування підмереж. Загальна схема розбиття мережі на підмережі з масками змінної довжини така: мережа ділиться на підмережі максимально необхідного розміру. Потім деякі підмережі діляться на більш дрібні, і рекурсивно далі, до тих пір, поки це необхідно. Крім того, технологія VLSM, шляхом приховування частини підмереж, дозволяє зменшити обсяг даних, переданих маршрутизаторами. Так, якщо мережа 12 / 8 конфігурується з розширеним мережевим префіксом / 16, після чого мережі 12.1/16 і 12.2/16 розбиваються на підмережі / 20, то маршрутизатора в мережі 12.1 нема чого знати про підмережах 12.2 з префіксом / 20, йому достатньо знати маршрут на мережу 12.1/16.

2.2 Протокол міжмережевої взаємодії IP. Формат IP дейтограмм

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

Таблиця 4 - Формат IP дейтаграми.

версія довжина тип сервісу загальна довжина пакета в байтах

Ідентифікація

(Для всіх фрагментів однакове)

прапори (3біта) Зсув фрагмента
час життя протокол FCS заголовка
IP-адреса відправника
IP-адреса одержувача
Опції IP (якщо є) заповнення (до 32 біт)
Дані

Версія (IPv4), довжина заголовка в 32 біт. словах, тип сервісу (для інтелектуальних маршрутизаторів, PPPDTRхх, P - пріоритет (для майбутнього), D, T, R - запитуються хв. затримки, макс. пропускна здатність, макс.надежность). Прапори Do not Fragment - DF, More Fragments - MF - ще фрагменти.Time to live - у секундах скільки жити пакету (перевантаження і кільця, зняття 1 при будь-якому переході). Опції IP (якщо є) - для тестування або налагодження мережі (напр. запис маршруту або обов'язкове проходження по маршруту).

Протоколи TCP / IP

Малюнок 5 - Дейтаграми UDP

Протокол доставки користувацьких дейтаграм UDP. Формат повідомлень UDP. Протокол надійної доставки повідомлень TCP (Transmission Control Protocol). Порти і встановлення TCP-соедіненій.Протокол доставки користувацьких дейтаграм UDP. Без гарантій доставки, тому його пакети можуть бути втрачені, продубльовані або прийти не в тому порядку, головне - швидкість. Мультиплексування і демультиплексирование прикладних протоколів за допомогою протоколу UDP.

Формат повідомлень UDP.

UDP source port - номер порту процесу-відправника,

UDP destination port - номер порту процесу-одержувача,

UDP message length - довжина UDP-пакета в байтах,

UDP checksum - контрольна сума UDP-пакета.

(!) Можна не заповнювати поля 1 і 4.

Протокол надійної доставки повідомлень TCP (Transmission Control Protocol).

Зверху - неструктурований потік байт, вниз - сегменти (осн. одиниця TCP). Договір про макс. довжині сегмента (не повинен перевищувати поле даних IP дейтаграми).

Порти і встановлення TCP-з'єднань.

Встановлення логічного з'єднання. Адреса кожної кінцевої точки включає IP адреса і номер порту TCP. Одна крайова точка може брати участь у кількох з'єднаннях.

2.3 Проблеми класичної схеми

У середині 80-х років Internet вперше зіткнувся з проблемою переповнення таблиць магістральних маршрутизаторів. Рішення, проте, було швидко знайдено - підмережі усунули проблему на кілька років. Але вже на початку 90-х до проблеми великої кількості маршрутів додалася брак адресного простору. Обмеження у 4 мільярди адрес, закладене до протоколу і здавалося недосяжною, стало вельми відчутним. В якості вирішення проблеми були одночасно запропоновані два підходи - один на найближче майбутнє, інший комплексний і довгостроковий. Перше рішення - це впровадження протоколу безкласової маршрутизації (CIDR), до якого пізніше приєдналася система NAT. Довгострокове рішення - це протокол IP наступної версії. Він позначається, як IPv6, або IPng (Internet Protocol next generation). У цій реалізації протоколу довжина адреси збільшена до 16-ти байтів (128 біт!), Виключені деякі елементи чинного протоколу, які виявилися невикористовуваними. Нова версія забезпечить, як люблять вказувати, щільність у 3 911 873 538 269 506 102 IP адрес на квадратний метр поверхні Землі. Однак те, що і в 2000-му році протокол все ще проходив стандартизацію, і те, що протокол CIDR разом з системою NAT виявилися ефективним рішенням, змушує думати, що перехід з IPv4 на IPng зажадає дуже багато часу. Поява цієї технології було викликано різким збільшенням об'єму трафіку в Internet і, як наслідок, збільшенням кількості маршрутів на магістральних маршрутизаторах. Так, якщо в 1994 році, до розгортання CIDR, таблиці маршрутизаторів містили до 70 000 маршрутів, то після впровадження їх кількість скоротилася до 30 000. На вересень 2002, кількість маршрутів перевалило за позначку 110 000! Можете собі уявити, скільки маршрутів потрібно було б тримати в таблицях сьогодні, якщо б не було CIDR! Що ж являє собою ця технологія? Вона дозволяє піти від класової схеми адресації, ефективніше використовувати адресний простір протоколу IP. Крім того, CIDR дозволяє агрегувати маршрутні запису. Однією записом в таблиці маршрутизатора описуються шляхи до багатьох мереж. Суть технології CIDR полягає в тому, що кожному постачальнику послуг Internet (або, для корпоративних мереж, якому-небудь структурно-територіальним підрозділу) повинен бути призначений нерозривний діапазон IP-адрес. При цьому вводиться поняття узагальненого мережевого префікса, що визначає загальну частину всіх призначених адрес. Відповідно, маршрутизація на магістральних каналах може реалізовуватися на основі узагальненого мережевого префікса. Результатом є агрегування маршрутних записів, зменшення розміру таблиць маршрутних записів і збільшення швидкості обробки пакетів. Припустимо, центральний офіс компанії виділяє одному своєму регіональному підрозділу мережі 172.16.0.0/16 і 172.17.0.0/16, а іншому - 172.18.0.0/16 і 172.19.0.0/16. У кожного регіонального підрозділу є свої обласні філії і з отриманого адресного блоку їм виділяються підмережі різних розмірів. Використання технології безкласової маршрутизації дозволяє за допомогою всього одного запису на маршрутизаторі другого підрозділу адресувати всі мережі і підмережі першого підрозділу. Для цього вказується маршрут до мережі 172.16.0.0 з узагальненим мережевим префіксом 15. Він повинен вказувати на маршрутизатор першого регіонального підрозділу. За своєю суттю технологія CIDR споріднена VLSM. Тільки якщо у випадку з VLSM є можливість рекурсивного поділу на підмережі, невидимі ззовні, то CIDR дозволяє рекурсивно адресувати цілі адресні блоки. Використання CIDR дозволило розділити Internet на адресні домени, усередині яких передається інформація виключно про внутрішні мережах. Поза домену використовується лише загальний префікс мереж. У результаті багатьом мереж відповідає одна маршрутна запис.

2.4 Приклади організації адресації в IP мережах

У кінці статті хотілося б привести практичні приклади з порушених у статті тем. Проектування адресної схеми вимагає від фахівця ретельного опрацювання багатьох факторів, урахування можливого зростання та розвитку мережі. Почнемо з прикладу розбиття мережі на підмережі. При будь-якому плануванні потрібно знати, скільки підмереж необхідно сьогодні і може знадобитися завтра, скільки вузлів знаходиться в найбільшій підмережі сьогодні і скільки може бути в майбутньому. Крім того, слід розробити хоча б схематичну топологію мережі з зазначенням всіх маршрутизаторів і шлюзів. Доброю практикою є резервування ресурсів на майбутнє. Так, якщо в найбільшій підмережі знаходиться 60 вузлів, не слід виділяти підмережа розмірністю в 26 - 2 (= 62) вузла! Не скупіться, вартість рішення можливої ​​проблеми буде більше, ніж вартість виділення в два рази більшої блоку адрес. Проте не потрібно впадати й в іншу крайність.

Приклад 1

Організації виділено блок адрес 220.215.14.0/24. Розбити блок на 4 підмережі, найбільша з яких налічує 50 вузлів. Врахувати можливе зростання в 10%. На першому етапі необхідне число підмереж ми округляємо в більшу сторону до найближчої ступеня числа 2. Оскільки в даному прикладі число необхідних підмереж дорівнює 4, округляти не потрібно. Визначимо кількість біт, потрібних для організації 4 підмереж. Для цього представимо 4 у вигляді ступеня двійки: 4 = 22. Ступінь - це і є кількість біт відводяться для номера підмережі. Так як мережевий префікс блоку дорівнює 24, то розширений мережевий префікс дорівнює 24 + 2 = 26.

Мережевий префікс Підмережа Вузол
0 8 16 24 25 31
220.215.14.0/26 10010000 10010000 00001110 0 0 000000
Розширений мережевої префікс

Решта 32 - 26 = 6 біт будуть використовуватися для номера вузла. Перевіримо, скільки вузлів можна адресувати 6-ю бітами: 26 - 2 = 62 вузла. Чи достатньо це для 10% зростання? 10% від 50 вузлів - це 5 вузлів, а 55 вузлів менше можливих 62-х. Отже, два біти для номера підмережі нас влаштовують. Наступним етапом буде знаходження підмереж. Для цього двійкове подання номера підмережі, починаючи з нуля, підставляється в біти, відведені для номера підмережі.

Основну мережу 11011100 11010111 00001110 00 000000 220.215.14.0/24
Підмережа 0 (00) 11011100 11010111 00001110 00 000000 220.215.14.0/26
Підмережа 1 (01) 11011100 11010111 00001110 01 000000 220.215.14.64/26
Підмережа 2 (10) 11011100 11010111 00001110 10 000000 220.215.14.128/26
Підмережа 3 (11) 11011100 11010111 00001110 11 000000 220.215.14.192/26
Розширений мережевої префікс

Для перевірки правильності наших обчислень, слід пам'ятати просте правило: десяткові номери підмереж повинні бути кратними номером першим підмережі. З цього правила можна вивести і інше, що спрощує розрахунок підмереж: достатньо обчислити адресу першої підмережі, а адреси наступних визначаються твором адреси першою на відповідний номер підмережі. У нашому прикладі ми легко могли встановити адресу третім підмережі, просто помноживши 64 * 3 = 192. Як вже згадувалося, окрім адреси підмережі, в якому всі біти вузловий частини дорівнюють нулю, є ще один службовий адресу - широкомовний. Особливість широкомовного адреси полягає в тому, що всі біти вузловий частини дорівнюють одиниці. Розрахуємо широкомовні адреси наших підмереж:

підмережа |

ШВА підмережі 0 (00) | 11011100.11011100.00001110.00 111111 | 220.215.14.63/26

ШВА підмережі 0 (01) | 11011100.11011100.00001110.01 111111 | 220.215.14.127/26

ШВА підмережі 0 (10) | 11011100.11011100.00001110.10 111111 | 220.215.14.191/26

ШВА підмережі 0 (11) | 11011100.11011100.00001110.11 111111 | 220.215.14.255/26

Розширений мережевої префікс. Вузлова частина = всі 1

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

№ підмережі Найменший адресу підмережі Найбільший адресу підмережі
0 220.215.14.1 - 220.215.14.62
1 220.215.14.65 - 220.215.14.126
2 220.215.14.129 - 220.215.14.190
3 220.215.14.193 - 220.215.14.254

Це і є розбивка, що задовольняє умові.

Приклад 2

У першому прикладі всі підмережі були однакового розміру - по 6 розрядів. Часто зручніше мати підмережі різного розміру. Припустимо, одна підмережа потрібна для завдання адрес двох маршрутизаторів, пов'язаних за схемою "точка-точка". У цьому випадку використовується всього лише дві адреси. Розглянемо тепер випадок, коли компанії виділено блок адрес 144.144.0.0/16. Потрібно розбити адресний простір на три частини, виділити адреси для двох пар маршрутизаторів і залишити деякий резерв. Розділимо мережа 144.144.0.0/16 на чотири рівні частини, виділивши два біти для номера підмережі:

Октет W X Y Z
Підмережа 0 (00) 10010000 10010000 0 000000 00000000 144.144.0.0/18
Підмережа 1 (01) 10010000 10010000 1 000000 00000000 144.144.64.0/18
Підмережа 2 (10) 10010000 10010000 0 000000 00000000 144.144.128.0/18
Підмережа 3 (11) 10010000 10010000 1 000000 00000000 144.144.192.0/18

Усередині третьої підмережі виділимо дві підмережі розміром у чотири адреси:

Підмережа № 3 № вузла
Підмережа 0 (0) 10010000 10010000 1 00000 00000 0 144.144.192.0/30
Підмережа 1 (1) 10010000 10010000 1 000000 00001 0 144.144.192.4/30
Номер підмережі

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

Висновок

Встановлення відповідності між IP-адресою і апаратним адресою здійснюється протоколом дозволу адрес.

Існує два принципово відмінних підходи до розв'язання адрес: у мережах, що підтримують широкомовлення, і в мережах, його не підтримують.

Протокол АКР, що працює в мережах Ethernet, Token Ring, FDDI, для трансляції IP-адреси в МАС-адресу виконує широкомовний ARP-запит. Для прискорення процедури перетворення адрес протокол ARP кешує отримані відповіді в ARP-таблицях.

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

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

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

Список літератури

1 Кульгин. М Технології корпоративних мереж / Енциклопедія - СПБ Видавництво «Пітер», 2000.-614с.: Іл.

2 Адресна схема протоколу IP. Крейг Хант, "Персональні комп'ютери в IP мережах", "BHV-Kиїв Алмати", з 384. 1997

3 Оліфер В.Г. Комп'ютерні мережі. Адресація в IP: Учеб. посібник для вузів / В.Г. Оліфер, Н.А. Оліфер. - 2-е вид. - СПб: Видавництво «Пітер», 2003. - 495 с.: Іл.

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
110.6кб. | скачати


Схожі роботи:
Протоколи обміну маршрутною інформацією стека TCPIP
TCPIP
Стек протоколів TCPIP
Безпека мереж на базі TCPIP
Розвиток стека TCPIP протокол IPv6
Автоматизована настройка TCPIP BOOTP Динамічна налаштування DHCP
Використання TCPIP протоколу для обміну інформацією в мережі
Захищені протоколи
Інтернет протоколи
© Усі права захищені
написати до нас
Рейтинг@Mail.ru