22.5. Протокол керування передачею (tcp) і протокол дейтаграм користувача (udp)

TransmissionControlProtocol - це протокол, тісно пов'язаний із IP, що використовується з аналогічною метою, але на більш висо­кому, транспортному рівні еталонної моделі ISOOSI. Часто ці про­токоли, через їх тісний зв'язок, іменують разом, як TCP/IP. Термін "TCP/IP" звичайно означає усе, що пов'язано з протоколами TCP і IP. Він охоплює ціле сімейство протоколів, прикладні програми і навіть саму Мережу. До складу сімейства входять протоколиTCP, UDP, telnet, FTP і багато інших.

Самий протоколTCP займається проблемою пересилки великих обсягів інформації, базуючись на можливостях протоколу 1Р.

Як це робиться? Цілком розумно можна розглянути таку ситуа­цію. Як можна переслати книгу поштою, якщо та приймає тільки листи і нічого більш? Дуже просто: розірвати її на сторінки і відправити сторінки окремими конвертами. Одержувач, керуючись номе­рами сторінок, легко зможе книгу відновити. Цим простим і природ­ним методом користуєтьсяTCP.

TCP поділяє інформацію, яку треба переслати, на декілька час­тин. Нумерує кожну частину, щоб пізніше відновити порядок. Щоб пересилати цю нумерацію разом із даними, він обкладає кожний шматочок інформації своєю обкладинкою - конвертом, що містить відповідну інформацію. Це і є ТСР-конверт. TCP-пакет, що утворив­ся, поміщається в окремий IP-конверт, і утворюється IP-пакет, із котрим мережа вже вміє поводитися.

Одержувач (TCP-модуль) після одержання розпаковує ІР-конверти і бачить TCP-конверти, розпаковує їх і розміщує дані у пра­вильній послідовності. Якщо чогось бракує, він потребує переслати цей пакет знову. Зрештою інформація збирається в потрібному по­рядку і цілком відновлюється. У реальності пакети не тільки губ­ляться, але й можуть спотворюватися при передачі через наявність перешкод на лініях зв'язку. TCP вирішує і цю проблему. Для цього він користується системою кодів, що виправляють похибки. Існує ціла наука про такі кодування. Найпростішим прикладом служить код із додаванням до кожного пакета контрольної суми (і до коле­ного байта біту перевірки на парність). При поміщенні в ТСР-кон­верт обчислюється контрольна сума, що записується в ТСР- заголовок. Якщо при прийомі заново обчислена сума не збігається з тією, що показана на конверті, значить десь на шляху мали місце спотворення, отже, треба переслати цей пакет знову, що й відбувається.

Для ясності і повноти картини необхідно зробити важливе зауваження: модульTCP розбиває потік байтів на пакети, не збері­гаючи при цьому меж між записами. Тобто, якщо один прикладний процес робить 5 записів в порт, то зовсім не обов'язково, що інший прикладний процес на іншому кінці віртуального каналу одержить зі свого порту саме 5, записів, причому саме таких (по розбивці), що були передані з іншого кінця. Уся інформація буде отримана корект­но і зі зберіганням порядку передачі, але вона може вже бути роз­бита по іншому і на іншу кількість частин. Не існує залежності між кількістю і розміром повідомлень, що записуються, з однієї сторони і кількістю і розміром повідомлень, що зчитуються, з іншої сторони.

Таким чином, протоколTCP забезпечує гарантовану доставку зі встановленням логічного з'єднання у вигляді байтових потоків. Він звільняє прикладні процеси від необхідності використовувати очікування і повторні передачі для забезпечення надійності. Най­більш типовими прикладними процесами, що використовуютьTCP, єFTP іTELNET.

Коли прикладний процес починає використовуватиTCP, то по­чинають спілкуватися модульTCP на машині користувача і модуль на машині серверу. Ці два кінцевих модуліTCP підтримують інфор­мацію про стан з'єднання - віртуального каналу. Підтримка віртуаль­ного каналу споживає ресурси обох кінцевих модулівTCP. Цей ка­нал є дуплексним. Один прикладний процес записує дані в ТСР-порт, звідки вони модулями відповідних рівнів по ланцюжку пере­даються по мережі і видаються в TCP-порт на іншому кінці каналу, а інший прикладний процес зчитує їх звідти, емулює (створює види­мість) виділену лінію зв'язку двох користувачів. Хоча в дійсності ніяка пряма лінія відправнику й одержувачу в безроздільне володін­ня не виділяється (інші користувачі можуть використовувати ті ж вузли і канали зв'язку в мережі в проміжках між пакетами цих), але зовні це, практично, саме так і виглядає.

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

Існує інший стандартний протокол транспортного рівня, що не обтяжений такими накладними витратами. Цей протокол нази­вається UDP — {UserDatagramProtocol) - протокол дейтаграм корис­тувача. Він використовується замістьTCP. Тут дані помішуються не вTCP, а вUDP-конверт, що також помішується вIP-конверт. Цей протокол реалізує дейтаграмний спосіб передачі даних. Дейтаграми самі по собі не містять засобів виявлення і виправлення похибок пе­редачі, тому при передачі даних за їх допомогою варто вживати за­ходів по забезпеченню надійності пересилки інформації. Для цього звичайно використовується метод підтвердження прийому посилкою відгуку при одержанні кожного пакета з дейтаграмою.

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

На відміну від TCP, дані, що відправляються прикладним про­цесом через модуль UDP, досягають місця призначення як єдине ціле. Наприклад, якщо процес-відправник робить 5 записів вUDP-порт, то процес-одержувач повинен буде зробити 5 зчитувань. Роз­мір кожного записаного повідомлення буде збігатися з розміром від­повідного зчитаного. ПротоколUDP зберігає межі повідомлень, обу­мовлені прикладним процесом. Він ніколи не об'єднує декілька пові­домлень в одне ціле і не поділяє одне повідомлення на частини.

Альтернатива TCP-UDP дозволяє програмісту гнучко і раціо­нально використовувати надані ресурси, виходячи зі своїх можли­востей і потреб. Якщо потрібна надійна доставка, то кращим може бути-TCP. Якщо потрібна доставка дейтаграм, то -UDP. Якщо потрібна ефективна доставка по довгому і ненадійному каналу пере­дачі даних, то краще використовуватиTCP. Якщо потрібна ефектив­ність на швидких мережах із короткими з'єднаннями, найкраще буде UDP. Якщо потреби не потрапляють у жодну з цих категорій, то вибір транспортного протоколу не ясний. Прикладні програми, зви­чайно, можуть усувати деякі недоліки обраного протоколу. Наприк­лад, якщо ви обрали UDP, а вам необхідна надійність, то прикладна програма повинна забезпечити надійність сама, як описано вище: вимагати підтвердження, пересилки загублених або пошкоджених пакетів і т.д. Якщо ви обрали TCP, а вам потрібно передавати за­писи, то прикладна програма повинна вставляти мітки в потік байтів так, щоб можна було розрізнити межі записів.