Інкапсуляція, фрагментація та реасемлювання данограми. 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Інкапсуляція, фрагментація та реасемлювання данограми.



Інкапсуляція данограми.

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

 
 

Рис. 3.29. Інкапсуляція данограми.

Фрагментація данограми.

В ідеальному випадку IP-данограма розміщається всередині однієї фізичної рамки. Мережеве обладнання звичайно накладає обмеження на довжину даних: Ethernet обмежує дані до 1500 байт, FDDI - приблизно до 4470 байт. Це обмеження називають максимальним блоком для пересилання (Maximum Transfer Unit ~ MTU). Кожен мережевий інтерфейс має відповідне значення MTU. Коли IP-рівень потребує передати данограму, розмір якої більший від MTU, то відбувається процес IP-фрагментації, тобто розбиття даних на частини (фрагменти).

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

 

Нагадаємо які поля IP-заголовку використовуються при фрагментації:

identification Унікальний номер кожної IP данограми, він копіюється у кожний фрагмент при фрагментації для ідентифікації фрагментів при збиранні данограми в пункті призначення.
flags Два молодші біти з трьох контролюють фрагментацію. Один з бітів (more fragments - MF) вказує на те, що це не останній фрагмент, тобто очікується прийняття як мінімум ще одного фрагменту. Другий з бітів (don’t fragment - DF) використовується для того, щоб позначити IP-данограму, яку не можна піддавати фрагментації. Коли при пересиланні такої данограми фрагментація все ж необхідна, то у відповідь до її джерела генерується ICMP-повідомлення про помилку.
fragment offset Використовується при фрагментації данограми і означає відступ в оригінальній данограмі для даних, які передаються у фрагменті, від початку даних нефрагментованої IP-данограми; визначається числом, кратним 8 байтам (байти заголовку оригінальної данограми не враховуються). Для першого фрагенту або для нефрагментованої данограми це значення завжди дорівнює 0. Щоб здійснити реасемблювання, адресат повинен отримати всі фрагменти, починаючи від фрагменту з відступом 0 до фрагменту з найбільшим відступом. Фрагменти, які не прибувають в потрібному порядку, а також ті, які не належать до комунікації між маршрутизатором, що фрагментує данограму, і адресатом, утруднюють реасемблювання.
total length Вказує на довжину фрагменту, тобто це поле коректується під час фрагментації.

Фрагментацію звичайно здійснює раутер, який з’єднує мережу з більшим MTU з мережею, в якій MTU менший, ніж довжина данограми. Довжина фрагменту повинна бути кратною 8 байтам (див. FRAGMENT OFFSET), останній останній фрагмент звичайно коротший. Щоб можна було відновити копію оригінальної данограми перед її подальшим опрацюванням у місці призначення, фрагменти повинні бути реасембльовані (reassembled).

Протокол IP вимагає, щоб кожне сполучення мало MTU, не менший від 68 байтів, так що коли будь-яка мережа передбачає менше значення від вказаного (наприклад, мережа ATM має довжину комірки 53 байти, з яких 48 відведені для поміщення даних), то фрагментація і реасемблювання мусять бути вбудовані в мережевий інтерфейс у спосіб, прозорий для IP. 68 байтів – це сума максимальної довжини IP-заголовка (60 байтів) і мінімально можливої довжини даних у фрагменті, крім останнього (8 байтів). Маршрутизатор завжди повинен сприймати данограми з довжиною, яка не перевищує MTU мережі, до якої він під'єднаний, і завжди повинен опрацьовувати нефрагментовані данограми довжиною до 576 байтів. Хоч протокол IP не вимагає обслуговування нефрагментованих IP-данограм, довших від 576 байтів, однак конкретні впровадження IP-протоколу можуть працювати із довжинами 8192 байти і більше, і рідко працюють із меншими від 1500 байтів. Станції також повинні сприймати і при потребі реасемблювати данограми довжиною щонайменше 576 байтів.

Фрагменти данограм мають той самий формат, як данограми, за вийнятком поля FLAG, яке вказує, що це фрагменти.

Приклад: Оригінальна данограма з довжиною даних 1400 байтів (рис. 3.30 а) і три фрагменти (рис. 3.30 б) для мережі з MTU = 620 байт. Значення відступів на рис. 5.5 вказують кількість байтів в десятковій системі; їх слід поділити на 8, щоб отримати значення, яке зберігається в заголовках фрагментів: відступ визначається кількістю 8-байтових блоків. Довжина IP-заголовків становить 20 байтів.


 
 

(а) оригінальна данограма;

 
 

(б) фрагменти.

Рис. 3.30. Приклад фрагментації данограми.

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

q Біт прапорця фрагментування DF перевіряється для вияснення, чи фрагментація можлива. Якщо цей біт встановлено в “1”, то данограма повинна бути відкинена, а повідомлення про помилку через протокол ICMP доручається до джерела.

q Базуючись на значенні MTU, поле даних ділиться на дві або більше частин. Всі новостворені порції даних (фрагменти), за винятком останньої, повинні мати довжину, кратну 8 байтам.

q Всі фрагменти даних поміщаються в IP-данограми. Заголовки цих данограм копіюються із оригінального заголовка із такими модифікаціями:

q біт прапорця MF (more fragments)встановлюється в “1”, за винятком останнього фрагменту;

q поле відступ фрагменту (Fragment Offset) отримує значення, яке вказує на розташування фрагменту даних в оригінальній (нефрагментованій) данограмі;

q якщо опції включені в оригінальну данограму, то біт найвищого порядку в байті тип опції (Option Type) визначає, чи опції будуть скопійовані у всі данограми фрагментів, чи тільки у перший фрагмент; наприклад, опція маршрутувати від джерела (Source Route) копіюється у всі фрагменти, а тому цей біт встановлюється в “1”;

q встановлюється значення поля довжина заголовка (Header Length) для нової данограми;

q встановлюється значення поля повна довжина (Total Length) для нової данограми;

q переобчислюється поле контрольна сума заголовку данограми фрагменту (Header Checksum).

q Кожна із форагментованих данограм пересилається як звичайна данограма. Протокол незалежно обслуговує кожен фрагмент, тобто фрагменти можуть пересилатися до призначення різними маршрутами і можуть бути суб’єктами нових фрагментацій, якщо вони перетинають мережі з меншими MTU.

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

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

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

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

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



Поделиться:


Последнее изменение этой страницы: 2016-08-01; просмотров: 179; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 34.201.19.151 (0.007 с.)