3. Реасемблювання данограми.

Механізм фрагментації та збирання або реасемблювання (reassembling) данограм розроблено так, що для вищих рівнів (TCP, UDP) він виглядає зовсім прозоро, хоча впливає на їх кількісні характеристики пеерсилання даних. У TCP/IP фрагменти данограми передаються від пункту фрагментації до адреси станції-призначення і лише там реасемблюються. Поле ідентифікація (Identification) данограми містить унікальний номер, встановлений станцією-джерелом у межах, визначених 16-бітовим числом. Оскільки це поле не змінюється при фрагментації, то фрагмент, яких досягає приймальну станцію, може бути ідентифікований на підставі значень поля ідентифікація та IP-адрес джерела і призначення. При цьому також перевіряється значення поля протокол (Protocol).

Для реасемблювання фрагментів приймальна станція виділяє буфер, як тільки поступає перший фрагмент данограми. Водночас стартує програма таймера реасемблювання. Якщо таймер вичерпується, а не всі фрагменти данограми прийняті, то данограма знищується. Початкове значення цього таймера називають часом існування (time to live – TTL) данограми. Значення TTL залежить від впровадження протоколу IP; окремі впровадження дозволяють конфігурувати його.

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

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

8. Протокол повідомлень управління icmp

Протокол ICMP (Internet Control Message Protocol - міжмережевий протокол повідомлень управління) є стандартним обов’язковим протоколом, описаним у RFC 792 із модифікаціями, наведеними в RFC 950. Він є частиною STD 5, який також включає IP. Деякі аспекти застосувань ICMP викладені в RFC 1191 та RFC 1256.

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

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

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

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

• Для фрагментованих IP-данограм ICMP-повідомлення висилаються тільки щодо помилок у фрагменті 0, тобто ICMP-повідомлення ніколи не відносяться до IP-данограм з неннульовим полем відступу фрагменту.

• ICMP-повідомлення ніколи не висилаються у відповідь на данограми із широкомовними або багатоадресними адресами призначення.

• ICMP-повідомлення ніколи не висилаються у відповідь на данограми, які мають IP-адреси джерела, що не є адресами одної станції. Інакше, адреса джерела не може бути нулем, адресою зворотнього зв’язку або багатоадресною.

• ICMP-повідомлення ніколи не висилаються у відповідь на ICMP-повідомлення про помилки. Вони можуть висилатися у відповідь на ICMP-запити (ICMP-типи 0, 8, 9, 10, 13..18).

• RFC 792 встановлює, що ICMP-повідомлення “можуть”, але не “мусять” бути генеровані для повідомлення про помилки при обробці IP-данограм. На практиці раутери можуть майже завжди генерувати ICMP-повідомлення про помилки, однак для станцій-призначень кількість генерованих ICMP-повідомлень залежить від реалізації.