Функціонування транспортних протоколів TCP/IP

Однак, детальне дослідження виявить цікавий факт, що один з протоколів, що сьогодні належать до стандартного стеку TCP/IP, і який не був спроектований як транспортний, насправді може нести корисні дані в певних умовах. Це Internet Control Message Protocol (ICMP).

ICMP є одним з центральних протоколів сімейства Internet Protocol (IP).

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

Одна з функцій ICMP, яка викликає інтерес, є так званий «ехо-запит» та «ехо-відповідь». RFC792 визначає, що стандартна реалізація TCP/IP при нормальних умовах повинна відповісти на ICMP ехо-запит з певними байтами навантаження пакетом ехо-відповіді, до якого приєднані точно ті ж самі байти.

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

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

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

Але, якщо один з вузлів знаходиться позаду NAT шлюза, мають бути зроблені додаткові кроки:

Подавлення ехо-відповідей, згенерованих операційною системою, для того, щоб шлюз NAT чекав «правильного» пакета, замість згенерованого ОС;

Акуратно порівнювати послідовні номери в ICMP заголовках з тим, щоб NAT шлюз розпізнав потрібні дані як справжню ехо-віпдовідь;

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

Для кращого розуміння, чому їх так багато, потрібно знати деякі основні особливості TCP та UDP, без заглиблення в структуру пакету, а на рівні концептуальних відмінностей.

UDP оперує єдиною сутністю, що називається «дейтаграма» — фактично, масив байтів. Дейтаграма супроводжується заголовком UDP, в якому вказані вихідний та вхідний порт, довжина пакету та контрольна сума. Дейтаграма просто надсилається з мережі вихідного вузла та отримується на мережевому інтерфейсі отримувача. Сторона отримувача не може визначити ні порядок, в якому дейтаграми було надіслано, ні те, що вони всі були доставлені, та не має ніякого засобу виправлення скупчень дейтаграм, якщо полоса пропускання виявляється недостатньою.

З іншого боку, TCP гарантує, що кожна надіслана порція даних доходить до вузла призначення і в потрібному порядку по відношенню до прилеглих даних. Більше того, TCP оперує не на рівні дейтаграм, а на рівні потоку, який представляє собою неперервну послідовність байт від початку потоку до його кінця. TCP включає методи запиту на з’єднання, методи відмови або прийняття запиту на з’єднання, методи перезапиту пакету, який загублено при передачі, методи нормального або аварійного закриття каналу та методи контролю скупчень даних. Всі ці методи надають TCP функціональність, необхідну для надійної та впорядкованої передачі, що, в свою чергу, робить його менш зручним порівняно з UDP в термінах часу обробки та службового трафіку.

TCP та UDP представляють собою дві протилежні сторони дизайну транспортних протоколів — один надійний, впорядкований та поточний, інший — ні.

Таким чином, не викликають подиву спроби розробити протокол, який логічно вписується між цими двома крайнощами. Один з прикладів — це DCCP, запропонований як стандарт RFC4340 станом на березень 2006. Так як і TCP він передбачає методи усунення скупчень та контролю передачі, але не передбачає чіткого впорядкування пакетів.

Другий приклад — це SCTP, наразі затверджений стандарт RFC2960 та багато інших. Він використовує багато чого з функціональності TCP, але в ньому відсутні поняття каналів і пере-впорядкування пакетів.

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

Протокол IL був безуспішною спробою Bell Lab’s впровадити транспортний протокол з гарантованою доставкою та впорядкованістю, але зі значно меншим об’ємом службової інформації в пакетах, ніж TCP.

В таблиці 2.1 показані суттєві відмінності в проаналізованих вище протоколах.

Таблиця 2.1. Відмінності в транспортних протоколах сімейств TCP/IP

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

Поиск по сайту: