8. Модернізація мережі на основі багатоапаратних систем доступу

Сімейство протоколів TCP/IP працює в мережових середовищах та, в окремому випадку, в Ethernet. Мережа Ethernet була розроблена Дослідним центром корпорації Xerox в Поло Альто в 1970-му році і заповнила нішу між глобальними мережами, низькошвидкісними мережами і спеціалізованими мережами комп’ютерних цертрів, які працювали з високими швидкостями, але на дуже обмежені відстані. Сьогодні Ethernet являється найбільш розповсюдженим протоколом локальних обчислювальних мереж.

Інші можливі мережеві середовища для роботи TCP/IP – це локальні мережі Token Ring, глобальні мережі WAN, такі як мережі передачі даних загального використання типу х.25. Порівнянно невелика кількість комп’ютерів може підключатися до каналів зв’язку з безпосереднім з’єднанням “крапка-крапка”, тобто до послідовних каналів зв’язку, наприклад, телефонним лініям. Для роботи по всіх цих лініях передбачені стандарти інкапсуляції IP-протоколу. Одним з таких стандартів роботи по каналам послідовного доступу – Serial Line – є протокол SLIP (Serial Line Internet Protocol).

Протокол послідовного міжмережевого зв’язку (SLIP) звичайно використовується при зв’язку по телефонній лінії через модем. Він являється протоколом, котрий підтримує TCP/IP через лінії послідовного зв’язку, демаршрутизатори та міжмережеві інтерфейси не використовуються. SLIP не забезпечує ні адресації, ні ідентифікації, ні пакета, ні механізмів перевірки помилок. Дякуючи своїй простоті він став швидко розповсюджуватися.

Протокол SLIP пакетує інформацію протокола IP чи інформацію, поступаючу з рівнів вище IP, і передає її по лінії послідовного зв’язку, для чого використовуються два спеціальних символа: END =192 і ESC =219.Відправку пакета SLIP починають з передачі двох END. Після цього починається передача потоку даних. Якщо байт даних співпадає з END, замість нього відправляють два ESC і 220. Якщо в потоку даних зустрічається байт ESC, замість нього передаються два ESC і 221. Після передачі останнього байту потоку передається END.

Протокол “ крапка-крапка” PPP (Point-to-Point Protocol) є новою версією протоколу SLIP, забезпечуючою більш швидкодіючий і ефективний зв’язок. Протокол PPP використовує формат кадру HDLC з інформаційним полем, яке містить заголовок протоколу IP. При цьому PPP використовує інший протокол управління лінією зв’язку LCP для установлення з’єднання.

Протоколи Internet.

Протоколи TCP/IP і модель OSI.

Протоколи TCP/IP (Transmission Control Protocol/Internet Protocol) були розроблені по замовленню Управління перспективних досліджень і розробок Міністерства оборони США (ARPA) і впровадженні в державній мережі Defense Data Network (DDN), включаючій в себе мережі ARPANET і MILNET. Першочергова мета була зв’язана з побудовою відмовостійкої коммутаційної мережі, котра могла б функціонувати навіть при виході з строю її більшої частини, наприклад, через ядерні бомбардування. Широке розповсюдження TCP/IP отримали в 1982 році, коли засоби їх підтримки були включені в ядро операційної системи UNIX 4.2BSD. Це об’єднання TCP/IP з ОС UNIX зробило протоколи TCP/IP доступними для всіх UNIX- мереж. В цьому ж році в цей комплект було включено протокол розрішення адреси ARP (Address Resolution Protocol), який ставить Ethernet- адреси в відповідність міжмережевим TCP/IP- адресам.

Реалізовані в OSI принципи, орієнтовані на максимальну спільність і функціональність вносять деяку надмірність. Наприклад, протокол x.25 дублює ряд функцій на кожному рівні, щоб забезпечити максимальну незалежність рівнів один від одного. Підраховуються контрольні суми і встановлюється таймер на очікування подій і на рівні ланки даних, і на мережевому рівні, що підвищує надійність, але підвищує вартість і знижує ефективність протоколу в цілому.

Подібна надмірність проявляється також в введенні двох наступних рівнів семирівневої моделі OSI: сеансового і рівня подання даних. Наявність сеансового рівня можна вважати доцільним для телекомунікаційних протоколів, в яких необхідні процедури установлення сеанса (LOGIN) і його завершення. Ці процедури повинні виконуватися багаторазово, наприклад, при організації доступа користувачів до загальномережевих ресурсів. Не виглядає абсолютно необхідним і виділення в окремий рівень телекомунікаційного функцій підставлення даних. Зжимання, конвертування, кодування, форматування і розпізнавання структур даних виконується не тільки на цьому рівні, а також на рівні ланки даних і прикладному.

Але модель протоколів TCP/IP має також ряд недоліків:

-різне функціональне заповнення однойменних рівнів в протоколах TCP/IP і в моделі OSI.

-система пересилки файлів FTP набагато більше проста, чим протокол FTAM;

-електронна пошта TCP/IP дещо обмежена на фоні поштового сервісу протоколу х.400 моделі OSI.

Особливості обох структур обумовлюють актуальність проблеми їх спільного функціонування при забезпеченні електронного обміну даними і реалізації складних функцій управління телекомунікаційними мережами. Одним з рішень проблеми узгодження TCP/IP і OSI є метод шлюзів. Не надто висока швидкодія цього методу робить його редостатньо ефективним для мережевих додатків, працюючих в реальному часі, але для електронної пошти чи для пересилання невеликих файлів його можливостей цілком достатньо. Підтвердженням цього служить наявність на ринку шлюзів прикладного рівня FTAM-FTR і X.400-SMTP.Відомий також простий спосіб двохпротокольного стека і метод, передбачаючий використання моста транспортного сервісу (transport-service bridge). Такий міст, працюючи як маршрутизатор, дозволяє виконувати прикладні програми OSI в TCP/IP-мережах. Він здійснює маршрутизацію блоків данних протоколів OSI, запаковуючи їх так, щоб вони емулювали TCP/IP.

Протокол керування передачею TCP.

Протокол керування передачею (TCP-Transmission Control Protokol) приблизно відповідає транспортному рівню моделі OSI, але містить і деякі функції сеансового рівня. З його допомогою реалізується організація сеансу зв’язку між двома користувачами в мережі. Крім цього в його функції включається виправлення помилок і перетворення інформації до вигляду діаграм, передача діаграм і відстеження їх проходження по мережі. TCP служить також для організації повторної передачі загублених діаграм і забезпечення їх надійності. В комп’ютері-адресаті TCP видобуває повідомлення з дейтаграми і направляє його прикладній програмі-адресату. Протокол TCP, як і протокол дейтаграми користувача UDP, вважаються протоколами поставника послуг, причому TCP являється протоколом, орієнтованим на з’єднання, в той час як UDP-не орієнтований на з’єднання протокол. Обидва вони опираються на послуги протокола IP, але не можуть транспортуватися мережові рівні x.25, ISDN чи Frame Relay.

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

Порт джерела(16 біт)								Порт призначення(16 біт)
Порядковий номер(32 біта)
Номер підтвердження(32 біта)
Зміщення Даних (4 біта)	Резерв (6 біт)	U R G	ACK	PSH	RST	SYN	F I N	Розмір вікна (16 байт)
Контрольна сума (16 біт)								Показник терміновості (16 біт)
Опції (переміщені)								Накопичення
Данні (переміщені)

Рис.2. Заголовок TCP.

Поля порту джерела (sourse port) і порту призначення (destination port) містять номери портів взаємодіючих програм. Це зв’язано з тим, що адресація на рівні TCP швидше призначена для передачі дейтаграм між логічними об’єктами всередині комп’ютера, ніж для фактичного з’єднання користувача з мережею. Тому номери портів призначення і джерела представляють собою числа довжиною 16 біт, ідентифікуючі прикладки, котрі використовують послуги TCP (наприклад, FTP, TELNET, протоколи електронної пошти SMTP, і т.д.). Номера від 0 до 225 визначені раніше і не можуть задаватись операторами, а номера після 225 можуть довільно визначатись для кожної конкретної мережі.

Порядковий номер блока даних (sequence number) довжиною 32 біта використовується для перевірки того, що всі блоки даних отримані. Якщо отриманий порядковий не відповідає послідовності і спрацьовує таймер ТСР, всі непідтверджені блоки даних повинні бути передані повторно. Передбачується лише позитивне підтвердження, негативних не існує. Номер підтвердження (acknowledgment number) іде слідом за порядковим номером і ідентифікує наступний сподіваний порядковий номер.

Поле зміщення даних (4 біта) визначає, де починаються дані заголовка ТСР, тобто скільки 32-бітових слів знаходиться в заголовку, що знаходиться перед полем даних користувача.

Декілька однобітових полів, наступних за полем зміщення даних, використовуються для обробки блока даних ТСР. Біт негайності URG позначає, що покажчик негайності повідомлення містить значущу інформацію. Покажчик негайності представляє собою поле 16 біт, ідентифікуюче зміщення в полі даних користувача, котре містить негайні дані. Біт підтвердження АСК вказує на присутність підтвердження в полі номера підтвердження і повідомляє приймальний пристрій про те, що цей номер підтверджує раніше отримані послідовності. Біт позачергової обробки PSH є аналогічним біту негайності. Він повідомляє приймаючий головний комп’ютер про те, що отриманий блок даних опрацьовуватись негайно. Біт відновлення RST викликає відновлення сеансу. Звичайно це означає, що всі черги, пов’язані з сеансом, відключаються і всі приєднані лічильники і таймери встановлюються в нуль. Біт синхронізації SYN використовується, коли встановлюється логічне з’єднання, і вказує на те, що порядкові номера повинні бути синхронізовані. Біт завершення FIN вказує на те, що даних для посилки більше нема і сеанс має бути закритим. Потім сеанс повинен бути закінчений, а ресурси звільнені для другого сеансу.

Поле вікна (16 біт) використовується на протязі встановлення сеансу. Сторони повинні узгоджувати, яке число блоків даних може бути послано до підтвердження. Це число називається розміром вікна і вираховується розміром черги і об’ємом обробки даних, уже отриманих від інших сеансів. Розмір вікна не може бути змінений після того, як сеанс установлено.

Поле контрольної суми (cheksum), довжиною 16 біт використовується для контролю помилок в заголовку, а також в користувальницьких даних. (в ІР контрольна сума не контролює користувальницькі дані ІР, а перевіряє лише заголовок).

Поле опцій може містити саму різну інформацію, наприклад максимальний розмір ТСР-дейтаграми. В кінці заголовок доповнюється нулями до розміру, кратного 32-бітному слову.

З’єднання встановлюється з допомогою команди OPEN з аргументами в вигляді ІР-адреси і номера порта віддаленого процесу. Команда OPEN використовується в обох випадках: коли процес має намір передавати інформацію і коли він очікує надходження інформації. Процедура установлення використовує спеціальний прапорець синхронізації SYN і складається з трьох тактів квитируючих співвідношення, дозволяючих синхронізувати потоки даних. Завершення з’єднання виконується обміном пакетами, які містять команду FIN.

Для перевірки того, що всі дані, передані на рівень ТСР, відправлені, існує функція “пропихання пакету”- PUSH-функція. Призначення цієї функції і PUSH-прапорця сладається лише в “пропиханні” даних до користувача, минаючи механізм кешування і не виконуючи ніяких додаткових групувань чи інших дій над даними.

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

Протоколи UDP і ICMP

Протокол дейтаграми користувача UDP (user datagram protocol) відноситься до протоколів без встановлення логічних з’єднань і призначений для обміну дейтаграмами між процесами комп’ютерів, які входять в єдину мережу з комутацією пакетів.

На відміну від протоколу ТСР, в протоколі UDP відсутнє підтвердження прийому блоків даних, що робить UDP набагато простіше, ніж ТСР, але відносно менш надійним. Це не страшно, коли протоколи вищого рівня можуть компенсувати недоліки UDP. Перевага протоколу UDP в тому, що він вимагає мінімум установок і параметрів для з’єднання двох процесів між собою і, якщо не потребується великого об’єму обробки, блоки даних можуть бути послані і отримані з дуже малим часом затримки.

Порт джерела (16 біт)	Порт призначення (16 біт)
Довжина повідомлення UDP (16 біт)	Контрольна сума UDP (16 біт)
Дані

Рис.3. Заголовок UDP.

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

Існують номери порта-відправника (source port) і порта призначення (destination port), поля довжини (length) і контрольної суми (checksum). Поле порта-відправника може, якщо потрібно, містити номер порту, з котрого було відправлено пакет (наприклад, якщо відправник чекає відповіді). Якщо це поле не використовується, воно заповнюється нулями. Поле довжини містить відомості про довжину дейтаграми (в байтах), включаючи заголовок і данні. Мінімальна довжина дорівнює 8. Поле контрольної суми UDP-пакета побітове доповнення 16-бітової суми 16-бітових слів (аналогічно ТСР).

Можуть виникати ситуації, коли при передачі дейтаграми виникають помилки, про які необхідно повідомити відправника чи інший хост-комп’ютер. Для передачі цих повідомлень чи і інформації службового характеру призначений протокол передачі управляючих повідомлень ІСМР (Internet Control Message Protocol).

Як і протоколи TCP і UDP, протокол ІСМР використовує ІР якості протоколу нижнього рівня, однак по своїй структурі і призначенню ІСМР являється частиною ІР.

Тип (8 біт)	Код (8 біт)	Контрольна cума UDP (16 біт)
Дані

Рис.4. Заголовок ІСМР.

Даному заголовку ІСМР передує звичайний ІР-заголовок без поля опцій (Options) і вирівнювання (Padding).

Різні типи повідомлень ІСМР визначаються полем “типу”, котре показує, чому генерувалось повідомленя ІСМР, наприклад, “destination unreachable” (пункт призначення недосяжний). Для протоколу визначено 13 типів повідомлень. Поле “код заголовку” носить службовий характер і забезпечує додаткову інформацію про помилку, розширюючи ієрархію повідомлень даного типу.

Звичацно шлюзи генерубть повідомлення ІСМР з вихідним хост-комп’ютером у якості отримувача (адресата). Це означає, що програмне забезпечення ІСМР, яке знаходиться в шлюзах, являється більш складним, ніж те, що знаходиться в комп’ютерах.

ІСМР не забезпечує виявлення помилок для ІР, а являється просто засобом, використовуваним ІР для передачі повідомлень про помилки хост-комп’ютерам.