Протокол IP має ясну і елегантну структуру. У нормальних ситуаціях IP дуже ефективно використовує для пересилання пам'ять і ресурси. Однак що станеться в нестандартній ситуації? Що може перервати безцільне блукання датаграми до завершення її часу життя після краху маршрутизатора і несправності в мережі? Хто попередить додаток про припинення відправки датаграм в недосяжну точку призначення?
Засоби для лікування таких несправностей надає протокол керуючих повідомлень Інтернету (Internet Control Message Protocol - ICMP). Він виконує роль мережевого помічника, сприяючи маршрутизації в хостах і забезпечуючи мережевого адміністратора засобами визначення стану мережевих вузлів. Функції ICMP є важливою частиною IP. Всі хости і маршрутизатори повинні бути здатні генерувати і обробляти повідомлення ICMP. При правильному використанні ці повідомлення можуть поліпшити виконання мережевих операцій.
Повідомлення ICMP пересилаються в датаграму IP зі звичайним заголовком IP (див. Рис. 7.1), маючи в поле протоколу значення 1.
Мал. 7.1. Пакетування повідомлення ICMP
Бувають ситуації, що призводять до відкидання (видалення з мережі) датаграми IP. Наприклад, точка призначення може стати недоступною через обрив зв'язку. Або може завершитися час життя датаграми. Маршрутизатор не зможе переслати довгу датаграмму при заборону фрагментації.
Мал. 7.2. Повідомлення ICMP направляється по шляху трафіку.
ICMP швидко повідомить системі про виявлену проблему. Це дуже надійний протокол, оскільки вказівка на помилки не залежить від наявності мережевого центру управління.
Однак у використанні повідомлень ICMP є деякі недоліки. Наприклад, якщо є недосяжною точка призначення, то повідомлення буде поширюватися до джерела по всій мережі, а не на станцію мережевого управління.
Реально ICMP не має коштів надати звіт про помилки виділеному операційного центру. Для цього служить протокол SNMP (див. Розділ 20).
На рис. 7.3 показані узагальнені повідомлення, що формуються маршрутизатором і хостом призначення для звіту про проблему. У таблиці 7.1 перераховані формальні імена повідомлень про помилки ICMP.
Мал. 7.3. Типи повідомлень про помилки ICMP
Таблиця 7.1 Повідомлення про помилки ICMP
Протокол IP дуже простий: хост або маршрутизатор обробляють датаграмму і посилають її якомога швидше. Однак доставка не завжди проходить гладко. Можуть виникнути різні проблеми.
Коли один або кілька хостів відправляють трафік UDP на повільний сервер, то на останньому може виникнути перевантаження, що призведе до відкидання сервером, коли деякі трафіку.
Маршрутизатор може переповнити свої буфери і далі буде змушений відкидати деякі надходять датаграми. Повільно через регіональну мережу (наприклад, на швидкості 56 Кбіт / с) між двома швидкісними локальними мережами (наприклад, в 10 Мбіт / с) може створити затор на шляху проходження датаграмм. Через це в мережі виникнуть перевантаження, які також приведуть до відкидання датаграми і, отже, до створення ще більшого трафіку.
Повідомлення Source Quench (придушення джерела) показано на рис. 7.7. Воно дозволяє спробувати вирішити проблему перевантажень, хоча і не завжди успішно. Механізми для придушення джерела перевантаження мережі повинні створювати розробники конкретних продуктів, але залишається відкритим конкретне питання:
Коли і кому маршрутизатор або хост повинен відправляти повідомлення Source Quench? Рис. 7.7. Формат ICMP-повідомлення Source Quench
Зазвичай ICMP-повідомлення вказує хосту джерела на причину відкидання надісланій їм датаграми. Однак при перевантаженні таке повідомлення може не дійти до цього хоста, що генерує дуже напружений мережевий трафік. Крім того, дуже розпливчасті вимоги до обробки вхідних повідомлень Source Quench.
Поточний документ за вимогами до хостів (RFC 1812) обумовлює як особливого пункту, що повідомлення Source Quench зовсім не потрібно посилати. Робота повинна виконуватися більш досконалим механізмом управління навантаженням в мережі.
До локальної мережі може бути підключено більше одного маршрутизатора. Коли локальний хост посилає датаграмму нема на той маршрутизатор, останній пересилає її і відправляє хосту джерела ICMP-повідомлення Redirect (перенаправлення), як показано на рис. 7.8. Хост повинен переключити наступний трафік на більш короткий шлях.
Мал. 7.8. Корекція маршрутизації на хості за допомогою повідомлення Redirect
Повідомлення Redirect використовується і для виключення маршрутизатора системним адміністратором. Хост може бути налаштований з єдиним маршрутизатором за замовчуванням; при цьому він буде динамічно визначати можливості пересилання через інші маршрутизатори.
Мал. 7.9. Формат ICMP-повідомлення Redirect
Формат повідомлення про перенаправлення показаний на рис. 7.9. Коди цього повідомлення перераховані в таблиці 7.5. Деякі протоколи маршрутизації здатні вибирати шлях доставки на основі вмісту поля типу обслуговування (TOS) датаграми. Коди 2 і 3 пропонують деякі відомості та такого вибору.
Таблиця 7.5 Коди перенаправлення
Перенаправлення датаграми в хост на основі значення з поля типу обслуговування
Що повинен робити хост, який отримав повідомлення ICMP? Реалізації різних розробників по-різному відповідають на це питання. У деяких з них хости ігнорують всі або багато такі повідомлення. Стандарти TCP / IP залишають велику свободу вибору в рішенні цього питання. Для різних типів повідомлень ICMP пропонуються наступні рекомендації:
Доставити ICMP-повідомлення на транспортний рівень. Що Їх дії повинні залежати від того, чи є причина виведення повідомлення тимчасової або постійної (наприклад, адміністративна заборона на пересилку).
Хост зобов'язаний оновити таблицю маршрутизації.
Доставити ICMP-повідомлення на транспортний рівень або в модуль обробки ICMP.
Доставити на транспортний рівень.
Доставити ICMP-повідомлення на транспортний рівень з необов'язковим повідомленням користувача.
Іноді помилки повинні оброблятися спільно операційною системою, комунікаційним програмним забезпеченням і мережевим додатком.
При пересиланні великого обсягу даних (наприклад, при копіюванні файлів по мережі) з одного хоста на інший розмір датаграмм істотно впливає на продуктивність. Заголовки IP і TCP вимагають не менше 40 додаткових байт.
# 9632; Якщо дані пересилаються в 80-байтових датаграму, додаткове навантаження складе 50%.
# 9632; Якщо дані пересилаються в 400-байтових датаграму, додаткове навантаження складе 10%.
# 9632; Якщо дані пересилаються в 4000-байтових датаграму, додаткове навантаження складе 1%.
Для мінімізації додаткового навантаження краще відсилати датаграми найбільшого розміру. Однак цей розмір обмежується значенням максимального елемента пересилання (Maximum Transmission Unit - MTU) для кожного з носіїв. Якщо датаграмма буде занадто великий, то вона буде фрагментована, а цей процес знижує продуктивність. (З точки зору користувача, якість мережі визначається двома параметрами: інтервалом пересилання (від початку пересилання до її завершення) і часом очікування (затримкою доступу до мережі, зайнятої іншими користувачами). Збільшення розміру датаграми призводить до зниження інтервалу пересилання, але збільшення очікування для інших користувачів. Грубо кажучи, навантаження на мережу буде виглядати як пікові імпульси з дуже невеликим навантаженням між ними, що вважається найбільш невдалим варіантом завантаження мережі. Набагато краще, коли мережа навантажується одно мірно. - Прим. пер.)
Багато років хости уникали фрагментації, встановлюючи ефективне значення MTU для пересилки в 576 октетів для всіх нелокальних хостів. Це часто призводило до непотрібного зниження продуктивності.
Набагато корисніше заздалегідь знати найбільший допустимий розмір датаграми, яку можна переслати по заданому шляху. Існує дуже простий механізм дослідження MTU по шляху (Path MTU discovery), що дозволяє дізнатися це значення. Для такого дослідження:
# 9632; Прапор "Чи не фрагментувати" заголовка IP встановлюють в 1.
# 9632; Розмір MTU по шляху спочатку встановлюють в значення MTU для локального інтерфейсу.
# 9632; Якщо датаграмма буде занадто велика для одного з маршрутизаторів, то він пошле назад ICMP-повідомлення Destination Unreachable з кодом 4.
# 9632; Хост джерела зменшить розмір датаграми і повторить спробу.
Яке ж значення потрібно вибрати для наступної спроби? Специфікація IP передбачає збереження значення MTU і його доступність для протоколів транспортного рівня. Якщо маршрутизатор має сучасне програмне забезпечення, то він буде включати в пересилається далі по мережі повідомлення Destination Unreachable розмір MTU (див. Рис. 7.10). Іноді засоби захисту конфигурируются на повне виключення всіх вхідних повідомлень ICMP, що не дозволяє використовувати механізм визначення MTU по шляху проходження дейтаграми.
Мал. 7.10. Повідомлення Destination Unreachable приносить результат дослідження розміру
Оскільки шляху пересилання можуть змінюватися динамічно, прапорець «Не фрагментувати" потрібно встановлювати у всіх комунікаційних датаграму. При необхідності маршрутизатор будуть посилати відомості про оновлення.
Якщо маршрутизатор використовує застаріле програмне забезпечення, він не зможе надати значення MTU для наступного попадання. У цьому випадку значення для наступної спроби буде вибиратися зі списку стандартних розмірів MTU (див. Розділ 4) з поступовим зменшенням для кожної нової спроби до досягнення значення, потрібного для комунікації з віддаленим хостом.
Зрозуміло, зміна шляху проходження може створити передумови для використання більшого розміру MTU. В цьому випадку система, узгоджених невеликий розмір MTU, буде намагатися його збільшити, якщо таке поліпшення буде можливо.
Не всі повідомлення ICMP сигналізують про помилки. Деякі з них витягують з мережі корисні відомості. Чи працює хост X? Ви не вимкнули хост Y? Як довго рухається датаграмма до хоста Z і назад? Яка маска підмережі хоста джерела?
Відповіді на ці питання дають наступні повідомлення ICMP:
# 9632; Відлуння-запити і луна-відповіді забезпечують обмін інформацією між хостами і маршрутизаторами.
# 9632; Запити та відповіді тимчасової мітки служать для вилучення відомостей про встановлення часу на цільовій системі. Відповіді на такі запити дають інформацію, необхідну для оцінки часу обробки датаграмм на хості.
Мал. 7.11. Повідомлення запиту ICMP
Відлуння-запити (Echo Request) і луна-відповіді (Echo Reply) застосовуються для перевірки активності системи. Код типу 8 застосовується в запитах, а код 0 - у відповідях. Кількість октетів в поле даних змінно і може вибиратися відправником.
Відповідає сторона повинна послати назад ті ж самі дані, які були отримані. Поле ідентифікатора служить для порівняння відповіді з вихідним запитом. Послідовний номер луна-повідомлення може застосовуватися для тестування, на якій ділянці стався обрив мережі, і для обчислення приблизного часу на шлях туди і назад. При цьому ідентифікатор не змінюється, а послідовний номер (починаючи від 0) збільшується на одиницю для кожного повідомлення. Формат луна-повідомлення показаний на рис. 7.12.
Мал. 7.12. Формат ICMP-повідомлень Echo Request і Echo Reply
Широко відома команда ping доступна майже в усіх системах TCP / IP, а її робота заснована на ICMP-повідомленнях для луна-запитів і луна-відповідей. У наведеному нижче діалозі спочатку тестується хост ring.bell.com. Потім відсилається послідовність з 14 повідомлень, що містять по 64 октету кожне. Відзначимо, що повідомлення 0, 1 і 2 були втрачені. Справа наводяться відомості про шляхи туди і назад.
> Ping ring.bell.com
ring.bell.com is alive
> Ping -s ring.bell.com 64 14
64 bytes from ring.bell.com: icmp_seq = 3. time = 21. ms
64 bytes from ring.bell.com: icmp_seq = 4. time = 18. ms
64 bytes from ring.bell.com: icmp_seq = 5. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 6. time = 19. ms
64 bytes from ring.bell.com: icmp_seq = 7. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 8. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 9. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 10. time = 18. ms
64 bytes from ring.bell.com: icmp_seq = 11. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 12. time = 17. ms
64 bytes from ring.bell.com: icmp_seq = 13. time = 17. ms
-ring.bell.com PING Statistics-
14 packets transmitted, 11 packets received, 21% packet loss
round-trip (ms) min / avg / max = 17/17/21
Мал. 7.13. Формат ICMP-повідомлень Address Mask
Повідомлення з відповіддю на Timestamp надає відомості про час в системі. Воно призначене для оцінки буферизації і обробки датаграми на віддаленій системі. Відзначимо наступні поля:
Originate timestamp (вихідна тимчасова мітка)
Час останнього звернення до повідомлення в системі-відправника
Receive timestamp (тимчасова мітка отримання)