АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

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

Читайте также:
  1. Апаратні і програмні засоби Internet. Протоколи TCP/IP. Доступ користувачів до мережі Internet, система адресації у мережі Internet.
  2. Види транспортних засобів
  3. Види транспортних подорожей
  4. Грошовий ринок та механізми його функціонування
  5. Досвід функціонування вільних економічних зон (ВЕЗ) в Україні
  6. Екологічні аспекти функціонування національного парку.
  7. ЗБІР ЗА ПЕРШУ РЕЄСТРАЦІЮ ТРАНСПОРТНИХ ЗАСОБІВ
  8. Зовнішнє та внутрішнє середовище функціонування підприємства
  9. Как TCP/IP соединяет разнородые устройства (Unit 12)
  10. Коментар до статті 277. Пошкодження шляхів сполучення і транспортних засобів
  11. Коментар до статті 279. Блокування транспортних комунікацій, а також захоплення транспортного підприємства
  12. Коментар до статті 287. Випуск в експлуатацію технічно несправних транспортних засобів або інше порушення їх експлуатації

 

Однак, детальне дослідження виявить цікавий факт, що один з протоколів, що сьогодні належать до стандартного стеку 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

  UDP   TCP   DCCP   SCTP  
Розмір заголовку пакета   8 байт   20 байт   Різний   8 байт + додаткові байти  
Одиниця транспортного рівня   Дейтаграма   Сегмент   Дейтаграма   Дейтаграма  
Нумерація портів   Так   Так Так Так
Корекція помилок   Можливо   Так Так Так
Надійність: виправлення помилок автоматичним повтором передачі Ні   Так Ні   Так
Віртуальні канали: послідовність та впорядкування   Ні   Так Так Можливо  
Контроль передачі   Ні   Так Так Так
Уникнення скупчень: вікна передачі, повільний старт, таймаути   Ні   Так Так Так
Багатопоточний   Ні   Ні   Ні   Так

 

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

 


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 |

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



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)