Функції ІР

Основне призначення Internet Protocol полягає в передачі дейтаграм через зв'язані між собою сімейства мереж. Це досягається передачею дейтаграм від одного модуля IP-сервісу до іншого доти, поки не буде досягнутий комп'ютер одержувача. Дейтаграми передаються через інтерфейси локальних мереж, а вибір шляхи здійснюється на основі IP-адреси одержувача пакета.

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

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

Однак не всі дейтаграми можуть бути фрагментовані. Якщо дейтаграма позначена як "не фрагментована" (тобто встановлений прапор No Fragment), то така дейтаграма ні за яких обставин не може піддаватися поділові на пакети меншої довжини. Якщо така дейтаграма не може бути доставлена в точку призначення без фрагментації, вона буде знищена. В інших випадках дейтаграму можна розбити на більш дрібні фрагменти.

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

Процедура фрагментації може розбити дейтаграму на пакети довільної довжини і потім відновити її в первісному виді. Кожен фрагмент вихідної дейтаграми має унікальний ідентифікатор (identification field), що однозначно визначає його приналежність до вихідного фрагментованого пакета. Це число унікальне для пари адрес відправник-одержувач увесь той час, поки дейтаграма знаходиться в мережі. Поля зсуву (fragment offset) і довжини, задані для кожного фрагмента вихідної дейтаграми, цілком визначають положення фрагмента у вихідній дейтаграмі. Крім того, IP-пакет містить прапор "наступного фрагмента", що вказує на те, що в даної порції є продовження або що даний фрагмент останній. Інформації цих полів досить, щоб IP-модуль, що одержує серію фрагментів, міг зібрати вихідну дейтаграму.

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

Дані довгої дейтаграми поділяються на дві порції по 64-бітній границі (друга порція не обов'язково повинна бути вирівняна по 64 бітах, але перша — обов'язково). Перша порція даних розміщається в першій дейтаграмі. У поле довжини фрагмента встановлюється довжина першої порції даних. Потім у першої дейтаграмі встановлюється прапор "наявності наступного фрагмента".

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

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

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

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

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

IP-протокол відноситься до мережевого рівня системи протоколів. Про структуру IP-адреси багато було сказано вище. Тут, напевно, досить відзначити, що IP-пакет містить дві основних адреси — відправника й одержувача. Обидві ці адреси статичні, тобто не міняються на протязі усього шляху IP-пакета і являють собою два 32-бітних числа.

Крім них IP-дейтаграма може (але, узагалі говорячи, не повинна) містити також адреси шлюзів мережі, що вона повинна пройти по шляху до одержувача. У таких IP-дейтаграмах адреси хостів "маршруту" розташовані у виді масиву з вказівником на наступний проміжний хост. При відправленні такої дейтаграми враховується не поле адреси призначення, а поле адреси першого "проміжного" хоста. Після того як дейтаграма буде оброблена маршрутизатором цього хоста, вказівник масиву пересувається на наступну адресу хоста в масиві і т.д., поки не будуть пройдені всі хости, зазначені в структурі, або не буде досягнута адреса призначення. Якщо масив проміжних шлюзів вичерпався, а дейтаграма ще не доставлена за адресою призначення, то вона направляється за адресою одержувача. Адреси, зазначені в структурі, повинні проходитися дейтаграмою одна за одною і бути розташовані в області "прямої видимості". Якщо таку передачу здійснити неможливо — дейтаграма знищується.

1.7.3.3. Формат заголовка IP-пакета

Рис. 1.7.3.2. Заголовок IP-дейтаграми

Version (4 біти). Поле версії. Значення поля установлює формат заголовка Internet-пакета. Ми розглядаємо версію 4.

IHL (4 біти). Поле довжини заголовка IP-пакета (Internet Header Length) у 32-бітних словах. Значення цього поля не може бути менше 5.

Type of service (ТОS) (8 біт). Поле типу сервісу. Це поле використовується для ідентифікації використовуваного дейтаграмою сервісу, тобто приналежність її до того або іншого з передбачених видів IP-дейтаграм, що, відповідно, визначає вид її обробки. Так, деякі мережі надають сервіс роботи з пакетами різної важливості, обробляючи і пропускаючи спочатку дейтаграми з виставленим прапором пріоритетності. Мережні модулі таких мереж використовують такі параметри поля TOS, як категорія терміновості або важливості пакета, можлива затримка передачі, рівень забезпечення достовірної доставки й ін.

Total Length (16 біт). Поле сумарної довжини. Сумарна довжина — це довжина всієї дейтаграми цілком, вважаючи байти, що входять у заголовок дейтаграми і дані. Це поле може приймати значення до 65535 (тобто довжина дейтаграми може досягати 2^16-1 байтів). Однак довгі дейтаграми не використовуються при роботі IP-протоколу. Усі хости і шлюзи мережі, як правило, працюють з довжинами до 576 байт, що не рекомендується перевищувати, працюючи в стандартному режимі. Число 576 обране з тих міркувань, що цієї довжини пакета цілком достатньо для того, щоб передати заголовок (64 байта) і блок даних (512 байт).

Identification (16 біт). Поле ідентифікатора дейтаграми. Значення цього поля установлюється відправником. Воно служить ідентифікатором дейтаграми, наприклад, у випадку її фрагментації на частини. Вибір ідентифікатора дейтаграми заснований на необхідності забезпечення унікальності фрагментів даної дейтаграми. Модулі обслуговування протоколу групують фрагменти з однаковою адресою джерела, адресою призначення, типом протоколу й ідентифікатором.

На перший погляд здається, що відправник повинен зберігати таблицю ідентифікаторів для кожного свого адресата, з яким він підтримує зв'язок протягом максимального "часу життя" IP-пакета. Однак, оскільки поле ідентифікатора дейтаграми може приймати 66536 різних значень, деякі хости можуть забезпечувати унікальність ідентифікатора незалежно від адреси призначення.

Вибір унікальності ідентифікатора може здійснюватися також за рахунок протоколів верхнього над IP рівня. Наприклад, ТСР-протокол може передати повторно точно такий же ТСР-сегмент, тоді імовірність коректної обробки дейтаграми буде набагато вище, якщо повторно відправлений пакет містить той же ідентифікатор, як і вихідний, і якщо фрагменти дейтаграми використовуються для побудови ТСР-сегмента.

Flags (3 біти). Поле керуючих прапорів.

Біт 0 — зарезервоване (повинний бути 0).

Біт 1 (DF)=0 — можна фрагментувати, біт 1 (DF)=1 — не фрагментувати.

Біт 1 (MF)=0 — останній фрагмент, біт 1 (MF)=1 — є наступний фрагмент.

Fragment Offset (13 біт). Поле зсуву фрагмента. Це поле вказує, де у вихідній дейтаграмі розташований даний фрагмент. Величина цього поля задає зсув у 64-бітних блоках. Перший фрагмент має нульовий зсув.

Time To Live (ТТL) (8 біт). Поле "часу життя" пакета. Величина цього поля визначає верхнє значення періоду часу, протягом якого дана дейтаграма може знаходитися в мережі, тобто подорожувати від шлюзу до шлюзу, від сегмента до сегмента. Цей параметр установлюється відправником дейтаграми і зменшується в кожній точці маршрутизації або обробки дейтаграми. Якщо в цьому полі виявляється нульове значення до того, як дейтаграма досягла свого адресата, вона знищується — шлюз не пропускає таку дейтаграму далі. Цей параметр служить свого роду "саморегулятором" мережевого трафіку.

Зазначений час виміряється в секундах. Максимальне значення цього поля може досягати 255 секунд, а при проходженні через кожен шлюз величина цього поля повинна зменшуватися хоча б на 1, навіть якщо процедура обробки зайняла значно менше часу. Іншими словами, це поле регулює тривалість життя дейтаграми в мережі і, в основному, призначене для того, щоб знищувалися дейтаграми, не доставлені за якимись причинами в точку призначення, і не було "засмічення" мережного простору.

Деякі протоколи будують свої механізми забезпечення високого рівня надійності з'єднання на тому, що старі дубльовані дейтаграми не доходять до вузла після закінчення визначеного часу (TTL).

Protocol (8 біт). Поле типу протоколу. Це поле містить число, що визначає тип наступного (верхнього) протоколу, що використовує дану дейтаграмму (ТСР, UDP і т.д.).

Header Checksum (16 біт). Поле контрольної суми заголовка. Це поле служить для перевірки правильності інформації тільки заголовка дейтаграми. При цьому дані дейтаграми можуть містити помилки. При виявленні невідповідності контрольної суми заголовкові дейтаграми, дейтаграма відразу ж знищується. Оскільки частина заголовка при передачі міняється (TTL і ін.), вона перераховується і перевіряється в кожній точці обробки дейтаграми. Алгоритм обчислення являє собою побітове доповнення побітової суми всіх 16-бітних слів заголовка. При обчисленні поле контрольної суми вважається рівним нулеві. Цей алгоритм досить простий, швидко виконується і цілком задовольняє вимогам контролю цілісності пакета.

Source Address (32 біта). Адреса відправника.

Destination Address (32 біта). Адреса одержувача.

Options. Поле додаткових параметрів: може бути перемінної довжини. Поле Options забезпечує контрольні функції, що можуть бути корисні або необхідні в ряді випадків (наприклад для збереження тимчасових міток, ключів таємності, параметрів нестандартної маршрутизації і т.д.).

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

Padding. Поле вирівнювання: може бути перемінної довжини. Це поле використовується для вирівнювання розміру заголовка по 32-бітній границі. Число заповнення — нуль.

38, 39

Дата добавления: 2014-01-07