Якщо комп 'ютер контактує з іншим аналогічним пристроєм у тій самій мережі, потрібна фізична або MAC-адреса. Але оскільки додаток надав IP-адресу одержувача, йому потрібен якийсь механізм для його прив 'язки з MAC-адресою. Це робиться за протоколом дозволу адрес (ARP). IP-адреса вузла призначення є широкомовною, а вузол-одержувач повідомляє джерело його MAC-адреси.
Це означає, що в кожному випадку, коли машина A має намір передати пакети даних пристрою B, вона змушена відправити ARP-пакет для дозволу MAC-адреси B. Отже, це занадто сильно збільшує навантаження на трафік, тому для зниження вартості зв 'язку, комп' ютери, які використовують протоколи ARP, зберігають кеш нещодавно придбаних прив 'язок адрес IP_to_MAC,
Сучасний вигляд
Сьогодні використовуються декілька удосконалень протоколу ARP і його призначення. Так, коли машина A хоче відправити пакети пристрою B, можливо, що B відправить дані для A незабаром. З цієї причини, щоб уникнути ARP для машини B, A повинна виконати прив 'язку адреси IP_to_MAC при запиті MAC-адреси B в спеціальному пакеті.
Оскільки A направляє свій початковий запит для MAC-адреси B, кожен комп 'ютер в мережі повинен витягувати і зберігати в своєму кеші прив' язку адреси IP_to_MAC A. Коли в мережі з 'являється новий комп' ютер (наприклад, при перезавантаженні операційної системи), він може транслювати цю прив 'язку, щоб всі інші машини могли зберігати його в своїх кешу Це дозволить усунути безліч ARP-пакетів усіма іншими машинами, коли вони хочуть спілкуватися з доданим пристроєм.
Варіації ARP-протоколу
Розглянемо сценарій, при якому комп 'ютер робить спробу зв' язатися з якоюсь віддаленою машиною за допомогою програми PING при тому, що раніше не було обміну IP-дейтаграмами між цими пристроями, і ARP-пакет повинен бути відправлений для ідентифікації MAC-адреси віддаленого комп 'ютера.
Повідомлення запиту Address Resolution Protocol (яке виглядає як звернення AA до BA BB - IP-адрес) транслюється в локальній мережі з використанням протоколу Ethernet типу 0x806. Пакет відкидається всіма машинами, за винятком цільової, яка відповідає повідомленням відповіді APR (AAAA - hh: hh: hh: hh: hh: hh де hh: hh: hh: hh: hh: hh - адреса джерела Ethernet). Ця відповідь є одноадресною для машини з IP-адресою B.B.B.B. Оскільки повідомлення запиту APR включало апаратну адресу (а саме - джерела Ethernet) запитувача комп 'ютера, цільовому пристрою не потрібно інше повідомлення, щоб зрозуміти це.
Взаємозв "язок з іншими протоколами
Як тільки ви зрозумієте, для чого потрібен протокол ARP, слід розглянути його взаємодію з іншими елементами мережі.
RARP - це протокол, за допомогою якого фізична машина в локальній мережі може робити запит, щоб дізнатися свою IP-адресу з таблиці протоколу або кешування сервера шлюзу. Це необхідно, оскільки на пристрої не може бути постійно встановлений диск, де він може постійно зберігати свою IP-адресу. Мережевий адміністратор створює таблицю в маршрутизаторі шлюзу локальної мережі, який зіставляє адреси фізичного комп 'ютера (або керування доступом до середовища - MAC) відповідним "айпі". Коли нова машина налаштована, її клієнтська програма RARP запитує з сервера RARP на маршрутизаторі для відправки його IP-адресу. Припускаючи, що запис було налаштовано в таблиці маршрутизатора, цей сервер RARP поверне "айпі" на комп 'ютер, який може зберегти його для майбутнього використання. Таким чином, це теж своєрідний протокол визначення адреси.
Механізм у деталях
І машина, що видає запит, і сервер, що на нього відповідає, використовує фізичні мережеві адреси в процесі їх короткого зв 'язку. Зазвичай запитувач не знає його. Таким чином, запит передається всім машинам у мережі. Тепер запитувач повинен ідентифікувати себе унікально для сервера. Для цього можна використовувати або серійний номер процесора, або фізичну мережеву адресу пристрою. При цьому використання другого як унікального ідентифікатора володіє двома перевагами:
- Дані адреси завжди доступні і не обов 'язково пов' язані з кодом початкового завантаження.
- Оскільки ідентифікаційна інформація залежить від мережі, а не від ЦБ, всі машини в даній мережі будуть надавати унікальні ідентифікатори.
Як і повідомлення протоколу ARP, запит RARP відправляється з одного комп 'ютера на інший, інкапсульований в частині даних мережевого кадру. Рамка Ethernet, що містить його, має звичайну преамбулу, Ethernet-джерело та адреси призначення, а також поля типу пакету перед кадром. Кадр кодує 8035, щоб ідентифікувати його вміст як повідомлення RARP. Частина даних кадру включає в себе 28-октетне повідомлення.
Відправник надсилає запит RARP, який вказує себе як ініціатор запиту і цільову машину, і передає свою фізичну мережеву адресу в полі цільової апаратної адреси. Всі пристрої в мережі отримують запит, але тільки ті з них, хто уповноважений надавати RARP, обробляють запит і відправляють відповідь. Такі машини відомі неофіційно як сервери цього протоколу. Для успішної реалізації протоколів ARP/RARP мережа повинна містити як мінімум один такий сервер.
Вони відповідають на запит, заповнюючи поле адреси цільового протоколу, змінюючи тип повідомлення від запиту до відповіді і відправляючи відповідь прямо на машину, що надсилає запит.
Синхронізація транзакцій RARP
Оскільки RARP безпосередньо використовує фізичну мережу, ніяке інше програмне забезпечення протоколу не повинно відгукуватися на запит або повторно передавати його. ЗА RARP має виконувати ці завдання. Деякі робочі станції, що покладаються на такий протокол для завантаження, воліють повторювати спробу до нескінченності, поки не отримають відповідь. Інші реалізації оголошують про відмову після кількох спроб запобігти наповненню мережі непотрібною трансляцією.
Переваги Mulitple RARP Servers: велика надійність.
Недолік: перевантаження може виникнути, коли всі сервери дадуть відповідь.
Таким чином, щоб уникнути недоліків, можна використовувати первинний і вторинний сервери. Кожному комп 'ютеру, який запитує запит RARP, призначається первинний сервер. Зазвичай він відповідає на всі позиви, але якщо він зазнає невдачі, тоді запитник може взяти тайм-аут і виконати ретрансляцію запиту. Якщо другий сервер отримує другу копію запиту протягом короткого часу першого, він відповідає. Але все ж може виникнути проблема, при якій за замовчуванням реагують всі вторинні сервери, тим самим перевантажуючи мережу. Таким чином, проблема полягає в тому, щоб уникнути одночасної передачі відповідей з обох серверів. Кожен вторинний сервер, який приймає запит, обчислює випадкову затримку і потім надсилає відповідь.
Недоліки RARP
Оскільки він працює на низькому рівні, він вимагає прямих адрес у мережі, що ускладнює роботу програм для створення сервера. Він не повністю використовує можливості такої мережі, як ethernet, яка застосовується для відправки мінімального пакета. Оскільки відповідь з сервера містить лише одну невелику частину інформації, 32-розрядна інтернет-адреса RARP формально описана в RFC903.
Протокол ICMP
У цьому протоколі зашифровано механізм, який шлюзи і вузли використовують для обміну інформацією про управління або помилкою. Інтернет-протокол забезпечує надійну службу передачі даних без встановлення з 'єднання, датаграма переміщується від шлюзу до шлюзу, поки не досягне того, яке може доставити його безпосередньо до кінцевого пункту призначення.
Якщо шлюз не може маршрутизувати або доставляти дейтаграму, або якщо він виявляє незвичайну умову, таку як перевантаження мережі, що впливає на його здатність перенаправляти дейтаграму, йому необхідно дати вказівку вихідному джерелу вжити заходів, щоб уникнути або усунути проблему.
Сполучна ланка
Протокол управління інтернет-протоколом дозволяє шлюзам надсилати повідомлення про помилки або керувати повідомленнями на інші шлюзи або хости. ICMP надає зв 'язок між програмним забезпеченням протоколу Інтернету між комп' ютерами. Це механізм повідомлень так званого спеціального призначення, доданий розробниками до протоколів TCP/IP. Це дозволяє шлюзам в Інтернеті інформувати про помилки або надсилати інформацію про непередбачені обставини.
Сам протокол IP не містить нічого, щоб допомогти підключитися до тестування відправника або дізнатися про аварії. Звіти про помилки і їх виправлення повідомляються за допомогою ICMP тільки щодо вихідного джерела. Він повинен пов 'язувати помилки з окремими прикладними програмами і робити дії для усунення проблем. Таким чином, він надає можливість для шлюзу повідомляти про помилку. При цьому він не повністю визначає дію, яку необхідно зробити для виправлення неполадок.
ICMP обмежується у зв 'язку з вихідним джерелом, але не з проміжними ICMP-повідомленнями. Вони відправляються через Інтернет в частині даних дейтаграми IP, яка сама переміщується по мережі. Саме тому вони тісно взаємопов 'язані з ARP-протоколом. ICMP-повідомлення маршрутизуються точно так само, як датаграми, що містять інформацію для користувачів, не маючи при цьому додаткової надійності або пріоритету.
Виключення присутнє для процедур обробки помилок, коли IP-датаграма, що несе повідомлення ICMP, не генерується для помилок, які виникають з дейтаграм, що містять повідомлення про неполадки.
Формат повідомлення ICMP
Воно налічує в собі три поля:
- 8-бітне цілочисельне поле TYPE, що ідентифікує повідомлення;
- 8-бітове поле CODE, яке надає додаткову інформацію про його тип;
- 16-розрядне поле CHECKSUM (ICMP використовує одну і ту ж контрольну суму алгоритму, яка охоплює тільки повідомлення цього протоколу).
Крім того, повідомлення ICMP, що інформують про помилки, у всіх випадках включають в себе заголовок і початкові 64 біта даних дейтаграми, що викликають проблему.
Запити і відповіді
Протоколи TCP/IP надають засоби, що допомагають мережевим менеджерам або користувачам ідентифікувати мережеві проблеми. Один з найчастіше використовуваних інструментів зневадження робить виклики відлуння-запиту ICMP і повідомлення ехо-відповіді. Вузол або шлюз надсилає повідомлення до певного пункту призначення.
Будь-який комп 'ютер, який приймає ехо-запит, створює відповідь, і повертає його вихідному відправнику. Запит включає в себе необов 'язкову область надсиланих даних. Відповідь має в собі копію даних, надісланих у запиті. Ехо-запит і відгук, пов 'язаний з ним, можуть застосовуватися для перевірки доступності досяжної мети і відгуку.
Оскільки як запит, так і відповідь надсилаються в IP-датаграмах, успішне його отримання підтверджує, що система справно працює. Для цього мають бути дотримані такі умови:
- IP-програмне забезпечення джерела має маршрутизувати датаграму;
- Проміжні шлюзи пунктом призначення і джерелом повинні працювати і правильно маршрутизувати дейтаграму;
- Повинен бути запущений кінцевий комп 'ютер, і на ньому має працювати як програмне забезпечення ICMP, так і IP;
- Маршрути в шлюзах по зворотному шляху повинні бути правильними.
Як це працює?
Робота протоколів ARP і ICMP тісно пов 'язана. Кожного разу, коли помилка запобігає маршрутизації або доставці шлюзу датаграми, він надсилає повідомлення про недоступність адресата назад у вихідний код, а потім видаляє датаграму. Несправні неполадки в мережі зазвичай передбачають збої в передачі даних. Оскільки повідомлення включає в себе короткий префікс дейтаграми, що викликала проблему, джерело точно знає, який з адрес недоступний. Напрямок може бути недоступним, оскільки апаратне забезпечення тимчасово не працює, відправник повідомив неіснуючу адресу призначення або тому, що шлюз не має маршруту до цільової мережі.
Незважаючи на те, що шлюзи відправляють повідомлення, які не доходять за призначенням, якщо вони не можуть маршрутизувати або доставляти датаграми, не всі такі помилки можуть бути виявлені. Якщо дейтаграма містить параметр вихідного маршруту з неправильними даними, вона може ініціювати повідомлення про помилку маршруту джерела.