Що таке протокол udp. Протоколи TCP і UDP. Діаграма встановлення і завершення з'єднання

UDP є простим протоколом і має певну область застосування. В першу чергу, це клієнт-серверні взаємодії і мультимедіа. Проте, більшості інтернет-додатків потрібна надійна, послідовна передача. UDP не задовольняє цим вимогам, тому потрібно інший протокол. Такий протокол називається TCP, і він є робочою конячкою Інтернету.

основи TCP

Протокол TCP (Transmission Control Protocol - протокол управління передачею) був спеціально розроблений для забезпечення надійного наскрізного байтового потоку по ненадійною інтермережі. Об'єднана мережа відрізняється від окремої мережі тим, що її різні ділянки можуть мати сильно розрізняється топологією, пропускною спроможністю, значеннями часу затримки, розмірами пакетів і іншими параметрами. При розробці TCP основна увага приділялася здатності протоколу адаптуватися до властивостей об'єднаної мережі та відмовостійкості при виникненні різних проблем.

Протокол TCP описаний в RFC 793. Згодом були виявлені різні помилки і неточності, і за деякими пунктами вимоги були змінені. Докладний описцих уточнень і виправлень дається в RFC 1122. Розширення протоколу наведені в RFC тисячі триста двадцять три.

Кожна машина, що підтримує протокол TCP, володіє транспортної сутністю TCP, що є або бібліотечної процедурою, або призначеним для користувача процесом, або частиною ядра системи. У будь-якому випадку, транспортна сутність управляє TCP-потоками і інтерфейсом з IP-рівнем. TCP-сутність приймає від локальних процесів призначені для користувача потоки даних, розбиває їх на шматки, не перевищують 64 Кбайт (на практиці це число зазвичай одно 460 байтам даних, що дозволяє помістити їх в один кадр Ethernet з заголовками IP і TCP), і посилає їх в вигляді окремих IP-дейтаграм. Коли IP-дейтаграми з TCP-даними прибувають на машину, вони передаються TCP-суті, яка відновлює вихідний байтовий потік. Для простоти ми іноді будемо вживати «TCP» для позначення транспортної суті TCP (частини програмного забезпечення) або протоколу TCP (набору правил). З контексту буде зрозуміло, що мається на увазі. Наприклад, у виразі «Користувач передає дані TCP» мається на увазі, природно, транспортна сутність TCP.

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

Модель служби TCP

В основі служби TCP лежать так звані сокети (гнізда або кінцеві точки), створювані як відправником, так і одержувачем. Вони обговорювалися в розділі «Сокети Берклі». У кожного сокета є номер (адреса), що складається з IP-адреси хоста і 16-бітного номера, локального по відношенню до хосту, званого портом. Портом в TCP називають TSAP-адреса. Для звернення до служби TCP між сокетом машини відправника і сокетом машини одержувача має бути явно встановлено з'єднання.

Один сокет може використовуватися одночасно для декількох з'єднань. Іншими словами, два і більше сполук можуть закінчуватися одним сокетом. З'єднання розрізняються по ідентифікаторів сокетов на обох кінцях - (socket1, socket2). Номери віртуальних каналів або інші ідентифікатори не використовуються.

Номери портів зі значеннями нижче 1024, звані популярними портами, зарезервовані стандартними сервісами. Наприклад, будь-який процес, який бажає встановити з'єднання з хостом для передачі файлу за допомогою протоколу FTP, Може зв'язатися з портом 21 хоста-адресата і звернутися, таким чином, до його FTP-демона. Список популярних портів наведено на сайті www.iana.org.

Можна було б, звичайно, зв'язати FTP-демона з портом 21 ще під час завантаження, тоді ж зв'язати демона telnet з портом 23, і т. Д. Однак якби ми так зробили, ми б тільки даремно зайняли пам'ять інформацією про демонів, які , насправді, більшу частину часу простоюють. Замість цього зазвичай користуються послугами одного демона, званого в UNIX inetd, який зв'язується з декількома портами і очікує перший вхідні повідомлення. Коли воно відбувається, inetd створює новий процес, для якого викликається відповідний демон, що обробляє запит. Таким чином, постійно активний тільки inetd, інші викликаються тільки тоді, коли для них є робота. Inetd має спеціальний конфігураційний файл, з якого він може дізнатися про призначення портів. Це означає, що системний адміністратор може налаштувати систему таким чином, щоб з найбільш завантаженими портами (наприклад, 80) були пов'язані постійні демони, а з іншими - inetd.

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

TCP-з'єднання являє собою байтовий потік, а не потік повідомлень. Межі між повідомленнями не зберігаються. Наприклад, якщо відправляє процес записує в TCP-потік чотири 512-байтових порції даних, ці дані можуть бути доставлені отримує процесі у вигляді чотирьох 512-байтових порцій, двох 1024-байтових порцій, однією 2048-байтовой порції або як-небудь ще. Немає способу, яким одержувач зміг би визначити, яким чином записувалися дані.

Файли в системі UNIX також володіють цією властивістю. Програма, що читає Райлі, не може визначити, як був записаний цей файл: по блоках, побайтно або відразу цілком. Як і у випадку з файлами системи UNIX, TCP-програми не мають уявлення про призначення байтів і не цікавляться цим. Байт для них - просто байт.

Отримавши дані від програми, протокол TCP може послати їх відразу або помістити в буфер, щоб послати відразу велику порцію даних, на свій розсуд. Однак іноді з додатком буває необхідно, щоб дані були послані негайно. Припустимо, наприклад, що користувач реєструється на віддаленій машині. Після того як він ввів команду і натиснув клавішу Enter, важливо, щоб введена ним рядок була доставлена ​​на віддалену машину відразу ж, а не поміщалася в буфер, поки не буде введена наступний рядок. Щоб змусити передачу даних без зволікання, додаток може встановити прапор PUSH (проштовхнути).

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

Останньою особливістю служби TCP, про яку слід згадати, є термінові дані. Коли користувач, який взаємодіє з програмою в інтерактивному режимі, натискає кнопку Delete або Ctrl-C, щоб перервати розпочатий віддалений процес, що посилає додаток поміщає в вихідний потік даних керуючу інформацію і передає її TCP-службі разом з прапором URGENT (терміново). Цей прапор змушує TCP-сутність припинити накопеніе даних і без зволікання передати в мережу все, що у неї є для цього з'єднання.

Коли термінові дані прибувають за призначенням, яка отримує додаток переривається (тобто «отримує сигнал», в термінології UNIX), після чого воно може вважати дані з вхідного потоку і знайти серед них термінові. Кінець термінових даних маркується, так що додаток може розпізнати, де вони закінчуються. Початок термінових даних не маркується. Додаток має саме здогадатися. Така схема являє собою грубий сигнальний механізм, залишаючи все інше з додатком.

протокол TCP

В даному розділі буде розглянуто протокол TCP в загальних рисах. У наступному розділі ми обговоримо заголовок протоколу, поле за полем.

Ключовою властивістю TCP, що визначає всю структуру протоколу, є те, що в TCP-з'єднанні у кожного байта є свій 32-розрядний порядковий номер. У перші роки існування Інтернету базова швидкість передачі даних між маршрутизаторами по виділеним лініям становила 56 Кбіт / с. Хосту, постійно видає дані з максимальною швидкістю, треба було б більше тижня на те, щоб порядкові номери здійснили повне коло. При нинішніх швидкостях порядкові номери можуть скінчитися дуже швидко, про це ще буде сказано пізніше. Окремі 32-розрядні порядкові номери використовуються для підтверджень і для механізму ковзного вікна, про що також буде сказано пізніше.

Відправляє і приймає TCP-суті обмінюються даними у вигляді сегментів. Сегмент складається з фіксованого 20-байтового заголовка (плюс необов'язкова частина), за якою можуть слідувати байти даних. Розмір сегментів визначається програмним забезпеченням TCP. Воно може об'єднувати в один сегмент дані, отримані в результаті декількох операцій записи, або, навпаки, розподіляти результат запису між декількома сегментами. Розмір сегментів обмежений двома межами. По-перше, кожен сегмент, включаючи TCP-заголовок, повинен поміщатися в 65 515-байтное поле корисного навантаження IP-пакета. По-друге, в кожній мережі є максимальна одиниця передачі (MTU, Maximum Transfer Unit), і кожен сегмент повинен поміщатися в MTU. На практиці розмір максимальної одиниці передачі становить зазвичай 1500 байт (що відповідає розміру поля корисного навантаження Ethernet), і таким чином визначається верхня межа розміру сегмента.

Основним протоколом, використовуваним TCP-сутностями, є протокол ковзаючого вікна. При передачі сегмента відправник включає таймер. Коли сегмент прибуває в пункт призначення, що приймає TCP-сутність посилає назад сегмент (з даними, якщо є що посилати, або без даних) з номером

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

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

Протокол TCP повинен вміти справлятися з цими проблемами і вирішувати їх ефективно. На оптимізацію продуктивності TCP-потоків було витрачено багато сил. У наступному розділі ми обговоримо кілька алгоритмів, використовуваних в різних реалізаціях протоколу TCP.

Тема ТСР-сегмента

Кожен сегмент починається з 20-байтного заголовка фіксованого формату. За ним можуть слідувати додаткові поля. Після додаткових полів може розташовуватися до 65 535 - 20 - 20 = 65 495 байт даних, де перші 20 байт - це IP-заголовок, а другі - TCP-заголовок. Сегменти можуть і не містити даних. Такі сегменти часто застосовуються для передачі підтверджень і керуючих повідомлень.

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

Поля Порядковий номер і Номер підтвердження виконують свою звичайну функцію. Зверніть увагу: поле Номер підтвердження відноситься до наступного очікуваного байту, а не до останнього отриманого. Обидва вони 32-розрядні, так як в TCP-потоці нумерується кожен байт даних.

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

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

За нею йдуть шість 1-бітових прапорів. Біт URG встановлюється в 1 у разі використання поля Покажчик на термінові дані, що містить зсув в байтах від поточного порядкового номера байта до місця розташування термінових даних. Таким чином в протоколі TCP реалізуються переривають повідомлення. Як уже згадувалося, протокол TCP лише забезпечує доставку сигналу користувача до одержувача, не цікавлячись причиною переривання.

Якщо біт АСК встановлено в 1, значить, поле Номер підтвердження містить осмислені дані. В іншому випадку даний сегмент не містить підтвердження, і поле Номер підтвердження просто ігнорується.

Біт PSH є, ​​по суті, PUSH-прапором, за допомогою якого відправник просить одержувача доставити дані з додатком відразу після отримання пакету, а не зберігати їх в буфері, поки той не наповниться. (Одержувач може займатися буферизацией для досягнення більшої ефективності.)

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

Біт SYN застосовується для установки з'єднання. У запиту з'єднання біт SYN = 1, а біт АСК = 0, що означає, що поле підтвердження не використовується. У відповіді на цей запит міститься підтвердження, тому значення цих бітів в ньому рівні: SYN = 1, ACK- 1. Таким чином, біт SYN використовується для позначення сегментів CONNECTION REQUEST і CONNECTION ACCEPTED, а біт АСК - щоб відрізняти їх один від одного.

Біт FIN використовується для розриву з'єднання. Він вказує на те, що у відправника більше немає даних для передачі. Однак, навіть закривши з'єднання, процес може продовжувати отримувати дані протягом невизначеного часу. У сегментів з битами FIN і SYN є порядкові номери, що гарантує правильний порядок їх виконання.

Управління потоком в протоколі TCP здійснюється за допомогою ковзного вікна змінного розміру. Поле Розмір вікна повідомляє, скільки байт може бути послано після байта, який отримав підтвердження. Значення поля Розмір вікна може дорівнювати нулю, що означає, що всі байти аж до Номер підтвердження-1 отримані, але у одержувача в даний момент якісь проблеми, і інші байти він поки прийняти не може. Дозвіл на подальшу передачу може бути отримано шляхом відправки сегмента з таким самим значенням поля Номер підтвердження і ненульовим значенням поля Розмір вікна.

У деяких протоколах, підтвердження прийому кадрів пов'язані з дозволами на продовження передачі. Цей зв'язок наслідок жорстко закріпленого розміру ковзного вікна в цих протоколах. В TCP підтвердження відділені від дозволів на передачу даних. По суті, приймач може сказати: «Я отримав байти аж до k-ro, але я зараз не хочу продовжувати прийом даних». Такий поділ (що виражається в ковзному вікні змінного розміру) надає протоколу додаткову гнучкість. Далі ми обговоримо цей аспект більш детально.

Поле Контрольна сума служить для підвищення надійності. Воно містить контрольну суму заголовка, даних і псевдозаголовка. При виконанні обчислень поле Контрольна сума встановлюється рівним нулю, а поле даних доповнюється нульовим байтом, якщо його довжина є непарне число. Алгоритм обчислення контрольної суми просто складає всі 16-розрядні слова в додатковому коді, а потім обчислює додаток для всієї суми. В результаті, коли одержувач вважає контрольну суму всього сегмента, включаючи поле Контрольна сума, результат повинен дорівнювати 0.

Псевдозаголовок містить 32-розрядні IP-адреси відправника і одержувача, номер протоколу для TCP (6) і лічильник байтів для TCP-сегмента (включаючи заголовок). Включення псевдозаголовка в контрольну суму TCP допомагає виявити невірно доставлені пакети, хоча це порушує ієрархію протоколів, так як IP-адреси в ньому належать IP-рівню, а не TCP-рівня. У UDP для контрольної суми використовується такий же псевдозаголовок.

Поле факультативні поля надає додаткові можливості, що не покриваються стандартним заголовком. За допомогою одного з таких полів кожен хост може вказати максимальний розмірполя корисного навантаження, який він може прийняти. Чим більше розмір використовуваних сегментів, тим вище ефективність, так як при цьому знижується питома вага накладних витрат у вигляді 20-байтних заголовків, проте не всі хости здатні приймати дуже великі сегменти. Хости можуть повідомити один одному максимальний розмір поля корисного навантаження під час установки з'єднання. За замовчуванням цей розмір дорівнює 536 байтам. Всі хости зобов'язані приймати TCP-сегменти розміром 536 + 20 = 556 байт. Для кожного з напрямків може бути встановлений свій максимальний розмір поля корисного навантаження.

Для ліній з великою швидкістю передачі і / або великою затримкою вікно розміром в 64 Кбайт виявляється занадто маленьким. Так, для лінії ТЗ (44,736 Мбіт / с) повне вікно може бути передано в лінію всього за 12 мс. Якщо значення часу поширення сигналу в обидва кінці становить 50 мс (що типово для трансконтинентального оптичного кабелю), 3/4 часу відправник буде займатися очікуванням підтвердження. При зв'язку через супутник ситуація буде ще гірше. більший розмірвікна міг би поліпшити ефективність, але 16-бітове поле Розмір вікна не дозволяє цього зробити. В RFC 1 323 був запропонований новий параметр Масштаб вікна, про значення якого два хоста могли домовитися під час активного з'єднання. Це число дозволяє зрушувати поле Розмір вікна до 14 розрядів вліво, забезпечуючи розширення розміру вікна до 230 байт (1 Гбайт). В даний час більшість реалізацій протоколу TCP підтримують цю можливість.

Ще одна можливість, запропонована в RFC 1106 і широко застосовується зараз, полягає в використанні протоколу вибіркового повтору замість повернення на п. Якщо адресат отримує один поганий сегмент і слідом за ним велика кількість хороших, у нормального TCP-протоколу в кінці кінців закінчиться час очікування і він передасть повторно все непідтверджені сегменти, включаючи ті, що були отримані правильно. У документі RFC 1106 було запропоновано використовувати негативні підтвердження (NAK), що дозволяють одержувачу запитувати окремий сегмент або кілька сегментів. Отримавши його, приймаюча сторона може підтвердити все що зберігаються в буфері дані, зменшуючи таким чином кількість повторно переданих даних.

Набору мережевих протоколів для Інтернету. З UDP комп'ютерні програми можуть надсилати повідомлення (в даному випадку звані датаграму) іншим хостам по IP-мережі без необхідності попереднього повідомлення для установки спеціальних каналів передачі або шляхів даних. Протокол був розроблений Девідом П. Рідом в 1980 році і офіційно визначений в RFC 768.

UDP використовує просту модель передачі, без неявних «рукостискань» для забезпечення надійності, упорядкування або цілісності даних. Таким чином, UDP надає ненадійний сервіс, і датаграми можуть прийти не один за одним, дублюватися або зовсім зникнути без сліду. UDP має на увазі, що перевірка помилок і виправлення або не потрібні, або повинні виконуватися в додатку. Чутливі до часу додатки часто використовують UDP, так як краще скинути пакети, ніж чекати затрималися пакети, що може виявитися неможливим в системах реального часу. При необхідності виправлення помилок на мережевому рівні інтерфейсу додаток може задіяти TCP або SCTP, розроблені для цієї мети.

Природа UDP як протоколу без збереження стану також корисна для серверів, що відповідають на невеликі запити від величезного числа клієнтів, наприклад DNS і потокові мультимедійні додатки на зразок IPTV, Voice over IP, протоколи тунелювання IP і багато онлайн-ігри.

енциклопедичний YouTube

1 / 5

✪ Порти і перенаправлення \ відкриття портів. Інструкція і пояснення на пальцях!

• субтитри

службові порти

UDP не надає жодних гарантій доставки повідомлення для вищого протоколу і не зберігає стану відправлених повідомлень. З цієї причини UDP іноді називають Unreliable Datagram Protocol (англ. - ненадійний протокол датаграм).

Контрольна сума

Поле контрольної суми використовується для перевірки заголовка і даних на помилки. Якщо сума не згенерована передавачем, то поле заповнюється нулями. Поле не є обов'язковим для IPv4.

Розрахунок контрольної суми

Метод для обчислення контрольної суми визначений в RFC тисяча сімдесят одна.

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

Для розрахунку контрольної суми псевдозаголовок і UDP-повідомлення розбивається на двухбайтное слова. Потім розраховується сума всіх слів в арифметиці зворотного коду (тобто коду, в якому негативне число виходить з позитивного інверсією всіх розрядів числа і існує два нуля: 0х0000 (позначається +0) і 0xffff (позначається -0)). Результат записується у відповідне поле в UDP-заголовку.

Значення контрольної суми, що дорівнює 0х0000 (+0 в зворотному коді), зарезервовано і означає, що для посилки контрольна сума не обчислювалася. У разі, якщо контрольна сума обчислювалася і вийшла рівною 0х0000, то в поле контрольної суми заносять значення 0xffff (-0 в зворотному коді).

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

Приклад розрахунку контрольної суми

Для прикладу розрахуємо контрольну суму декількох 16-бітних слів: 0x398a, 0xf802, 0x14b2, 0xc281.

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

0x398a + 0xf802 = 0x1318c → 0x318d (перенесення в старший розряд) 0x318d + 0x14b2 = 0x0463f → 0x463f (число позитивне) 0x463f + 0xc281 = 0x108c0 → 0x08c1

В кінці виконується інверсія всіх бітів отриманого числа

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e або, інакше - 0xffff - 0x08c1 = 0xf73e. Це і є шукана контрольна сума.

При обчисленні контрольної суми знову використовується псевдозаголовок, що імітує реальний IPv6-заголовок:

Адреса джерела такої ж, як і в IPv6-заголовку. Адреса одержувача - фінальний одержувач; якщо в IPv6-пакеті не міститься заголовка маршрутизації (Routing), то це буде адреса одержувача з IPv6-заголовка, в іншому випадку, на початковому вузлі, це буде адреса останнього елемента заголовка маршрутизації, а на вузлі-одержувачі - адреса одержувача з IPv6- заголовка. Значення «Наступний заголовок» дорівнює значенню протоколу - 17 для UDP. Довжина UDP - довжина UDP-заголовка і даних.

Надійність і вирішення проблеми перевантажень

Через нестачу надійності додатки UDP повинні бути готові до деяких втрат, помилок і дублювання. Деякі з них (наприклад, TFTP) можуть при необхідності додати елементарні механізми забезпечення надійності на прикладному рівні.

Але частіше такі механізми не використовуються UDP-додатками і навіть заважають їм. Потокові медіа, розраховані на багато користувачів ігри в реальному часі і VoIP - приклади додатків, часто використовують протокол UDP. У цих конкретних додатках втрата пакетів зазвичай не є великою проблемою. Якщо з додатком необхідний високий рівеньнадійності, то можна використати інший протокол (TCP) або скористатися методами завадостійкого кодування (Erasure code ru en).

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

Мережеві механізми були призначені для того, щоб звести до мінімуму можливі ефекти від перевантажень при неконтрольованих, високошвидкісних навантаженнях. Такі мережеві елементи, як маршрутизатори, що використовують пакетні черги і техніки скидання, часто є єдиним доступним інструментом для уповільнення надмірної UDP-трафіку. DCCP (англ. Datagram Congestion Control Protocol - протокол контролю за перевантаженням датаграмм) розроблений як часткове вирішення цієї потенційної проблеми за допомогою додавання кінцевого хосту механізмів для відстеження перевантажень для високошвидкісних UDP-потоків на кшталт потокових медіа.

додатки

Численні ключові Інтернет-додатки використовують UDP, в їх числі - DNS (де запити повинні бути швидкими і складатися тільки з одного запиту, за яким слід один пакет відповіді), Простий Протокол Управління Мережами (SNMP), Протокол Маршрутної Інформації (RIP), Протокол динамічної Зміни Вузла (DHCP).

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

Порівняння UDP і TCP

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

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

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

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

• потоковость- дані читаються як потік байтів, не передається ніяких особливих позначень для кордонів повідомлення або сегментів.

UDP - простіший, заснований на повідомленнях протокол без встановлення з'єднання. Протоколи такого типу не встановлюють виділеного з'єднання між двома хостами. Зв'язок досягається шляхом передачі інформації в одному напрямку від джерела до одержувача без перевірки готовності або стану одержувача. У додатках для голосового зв'язку через інтернет-протокол (Voice over IP, TCP / IP) UDP має перевагу над TCP, в якому будь-який «рукостискання» завадило б хорошою голосового зв'язку. У VoIP вважається, що кінцеві користувачі в реальному часі нададуть будь-яку необхідну підтвердження про отримання повідомлення.

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

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

• легковажність- ніякого упорядкування повідомлень, ніякого відстеження з'єднань і т. Д. Це невеликий транспортний рівень, розроблений на IP.

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

• Немає контролю перевантажень- UDP сам по собі не уникає перевантажень. Для додатків з великою пропускною здатністю можливо викликати колапс перевантажень, якщо тільки вони не реалізують заходи контролю на прикладному рівні.

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

Що означають TCP і UDP

TCP- транспортний протокол передачі даних в мережах TCP / IP, попередньо встановлює з'єднання з мережею.

UDP- транспортний протокол, який передає повідомлення-датаграми без необхідності установки з'єднання в IP-мережі.

Нагадую, що обидва протоколи працюють на транспортному рівні моделі OSI або TCP / IP, і розуміння того чим вони відрізняються дуже важливо.

Різниця між протоколами TCP і UDP

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

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

Давайте розглянемо основні відмінності tcp від udp.

1. TCP гарантує доставку пакетів даних в незмінних вигляді, послідовності і без втрат, UDP нічого не гарантує.
2. TCP нумерує пакети при передачі, а UDP немає
3. TCP працює в дуплексному режимі, в одному пакеті можна відправляти інформацію і підтверджувати отримання попереднього пакету.
4. TCP вимагає заздалегідь встановленого з'єднання, UDP з'єднання не вимагає, у нього це просто потік даних.
5. UDP забезпечує більш високу швидкість передачі даних.
6. TCP надійніше і здійснює контроль над процесом обміну даними.
7. UDP краще для програм, що відтворюють потокове відео, відеофонії і телефонії, мережевих ігор.
8. UPD не містить функцій відновлення даних

Прикладами UDP додатків, наприклад можна привести, передачу DNS зон, в Active Directory, там не потрібно надійність. Дуже часто такі питання люблять питати на співбесідах, так, що дуже важливо знати tcp і udp відмінності.

Заголовки TCP і UDP

Давайте розглянемо як виглядають заголовки двох транспортних протоколів, так як і тут відмінності кардинальні.

заголовок UDP

• 16 бітний порт джерела> Вказівка ​​порту джерела для UDP необов'язково. Якщо це поле використовується, одержувач може відправити відповідь цьому порту.
• 16 бітний порт призначення> Номер порту призначення
• 16 бітна довжина UDP> Довжина повідомлення, включаючи заголовок і дані.
• 16 бітна контрольна сума> Контрольна сума заголовка і даних для перевірки

Тема TCP

• 16 бітний порт джерела> Номер порту джерела
• 16 бітний порт призначення> Номер порту призначення
• 32 бітний послідовний номер> Послідовний номер генерується джерелом і використовується призначенням, щоб змінити порядок пакети для створення вихідного повідомлення і відправити підтвердження джерела.
• 32 бітний номер підтвердження> Якщо встановлено біт АСК поля "Управління", в даному полі містить наступний очікуваний послідовний номер.
• 4 біта довжина заголовка> Інформація про початок пакета даних.
• резерв> Резервуються для майбутнього використання.
• 16 бітна контрольна сума> Контрольна сума заголовка і даних; по ній визначається, чи був спотворений пакет.
• 16 бітний покажчик терміновості> У цьому полі цільове пристрій отримує інформацію про терміновість даних.
• Параметри> Необов'язкові значення, які вказуються при необхідності.

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

При розмірі вікна 3, відправник відправляє вже по 3 кадри, і чекає від 4, який має на увазі, що всі три кадри у нього є, +1.

Сподіваюся у вас тепер є уявлення про відмінності tcp udp протоколів.

Говорячи про безпеку інформації, ми маємо на увазі конфіденційність, цілісність і доступність інформації в кожен момент часу. І якщо з конфіденційністю і доступністю все зрозуміло, то як забезпечити цілісність інформації при її передачі по мережі? Для вирішення цього завдання нам стане в нагоді знання мережевих протоколів. У даній статті ми розглянемо протоколи TCP і UDP. Вони входять в стек протоколів TCP / IP, відносяться до транспортному рівню моделі OSI і використовуються для передачі інформації від вузла до вузла.

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

UDP

UDP protocol - протокол, що забезпечує передачу даних (датаграмм) без попереднього створення з'єднання між хостами. При відправці датаграмм немає впевненості в існуванні одержувача і його готовність до обміну. Мережевий протокол UDP не забезпечує також упорядкування датаграмм при отриманні. Він використовується додатками для яких суттєве значення має час доставки, коли немає можливості чекати затрималися або запитувати втрачені пакети, наприклад, в системах реального часу. Датаграми можуть доставлятися не в заданому порядку, дублюватися або зовсім не доставлятися. Тому протокол UDP називають «ненадійним протоколом датаграм».

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

TCP

Протокол передачі даних TCP - протокол забезпечує надійну доставку пакетів даних, він забезпечує установку з'єднання між двома хостами методом «рукостискання», після якого може здійснюватися обмін даними.

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

Кожен пакет при обміні має свій порядковий номер. TCP автоматично впорядковує пакети, використовуючи порядковий номер, і передає після склейки на рівень додатків. Після відправки кількох пакетів, очікується підтвердження і порядковий номер наступного пакета. Якщо підтвердження не отримане, відправка повторюється, якщо спроби не увінчалися успіхом, сесія розривається. Кількість пакетів даних, на які буде запитуватися підтвердження, залежить від надійності мережі. Якщо дані губляться, то підтвердження автоматично запитується частіше. Це називається механізмом ковзаючого вікна (sliding window), завдяки якому TCP може працювати з мережами, незалежно від рівня їх надійності.

Застосування TCP доцільно там, де неприпустима втрата даних, наприклад, при авторизації, а також при передачі шифрованого інформації.

TCP і UDP відмінності

Чи означає це, що протокол UDP не варто використовувати? Зовсім ні. За рахунок відсутності «гарантії доставки» протокол UDP забезпечує більш високу швидкість передачі даних, ніж TCP. З цієї причини UDP оптимальний для мережевих і онлайн ігор, перегляду потокового відео, організації відео-зв'язку і IP телефонії.

Діліться корисною інформацією з близькими.

протокол UDP

User Datagram Protocol (UDP)- це простий, орієнтований на дейтаграми протокол без організації з'єднання, що надає швидке, але необов'язково надійне транспортне обслуговування. Він підтримує взаємодії "один з багатьма" і тому часто застосовується для широкомовної і групової передачі дейтаграм.

Internet Protocol (IP) є ​​основним протоколом Інтернету. Transmission Control Protocol (TCP) і UDP - це протоколи транспортного рівня, побудовані поверх лежить в основі протоколу.

TCP / IP - це набір протоколів, званий також "пакетом протоколів Інтернету" (Internet Protocol Suite), що складається з чотирьох рівнів. Запам'ятайте, що TCP / IP не просто один протокол, а сімейство або набір протоколів, який складається з інших низькорівневих протоколів, таких, як IP, TCP і UDP. UDP розташовується на транспортному рівні поверх IP (протоколу мережевого рівня). Транспортний рівень забезпечує взаємодію між мережами через шлюзи. У ньому використовуються IP-адреси для відправки пакетів даних через Інтернет або іншу мережу за допомогою різноманітних драйверів пристроїв.

Перш ніж приступати до вивчення роботи UDP, звернемося до основної термінології, яку потрібно добре знати. Нижче коротко визначимо основні терміни, пов'язані з UDP:

У передачі даних пакетом називається послідовність двійкових цифр, які представляють дані і керуючі сигнали, які передаються і комутуються через хост. Усередині пакета ця інформація розташована відповідно до спеціального форматом.

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

MTU характеризує канальний рівень і відповідає максимальному числу байтів, яке можна передати в одному пакеті. Іншими словами MTU - це найбільший пакет, який може переносити дана мережеве середовище. Наприклад, Ethernet має фіксований MTU, рівний 1500 байт. У UDP, якщо розмір дейтаграми більше MTU, протокол IP виконує фрагментацію, розбиваючи дейтаграмму на більш дрібні частини (фрагменти) так, щоб кожен фрагмент був менше MTU.

Щоб поставити у відповідність входять даними конкретний процес, що виконується в комп'ютері, UDP використовує порти. UDP направляє пакет у відповідне місце, використовуючи номер порту, вказаний в UDP-заголовку дейтаграми. Порти представлені 16-бітними номерами і, отже, приймає значення в діапазоні від 0 до 65 535. Порти, які також називають кінцевими точками логічних з'єднань, розділені на три категорії:

Добре відомі порти - від 0 до 1023

Реєстровані порти - від 1024 до 49151

Динамічні / приватні порти - від 49152 до 65535

Зауважимо, що порти UDP можуть отримувати більше одного повідомлення в кожен проміжок часу. У деяких випадках сервіси TCP і UDP можуть використовувати одні і ті ж номери портів, наприклад 7 (Echo) або 23 (Telnet).

UDP використовує такі відомі порти:

Перелік портів UDP і TCP підтримується агентством IANA (Internet Assigned Numbers Authority).

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

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

Значення часу життя, або TTL (time-to-live), дозволяє встановити верхню межу числа маршрутизаторів, через які може пройти дейтаграма. Значення TTL не дає пакетам потрапити в нескінченні цикли. Воно инициализируется відправником і зменшується на одиницю кожним маршрутизатором, що обробляє дейтаграму. Коли значення TTL стає нульовим, дейтаграма відкидається.

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

Принцип роботи UDP

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

На попередньому малюнку вказано, що загальна довжина заголовка UDP становить вісім байтів. Теоретично максимальний розмір дейтаграми IP дорівнює 65 535 байтам. З урахуванням 20 байтів заголовка IP і 8 байтів заголовка UDP довжина даних користувача може досягати 65 507 байтів. Однак більшість програм працюють з даними меншого розміру. Так, для більшості додатків за умовчанням встановлена ​​довжина приблизно 8192 байт, оскільки саме такий обсяг даних зчитується і записується мережевої файлової системою (NFS). Можна встановлювати розміри вхідного і вихідного буферів.

Контрольна сума потрібна, щоб перевірити чи були дані доставлені в пункт призначення правильно чи були спотворені. Вона охоплює як заголовок UDP, так і дані. Байт-заповнювач використовується, якщо загальне число октетів дейтаграми непарній. Якщо отримана контрольна сума дорівнює нулю, одержувач фіксує помилку контрольної суми і відкидає дейтаграмму. Хоча контрольна сума є необов'язковим засобом, її завжди рекомендується включати.

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

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

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

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

недоліки UDP

У порівнянні з TCP UDP має такі недоліки:

Відсутність сигналів квитування. Перед відправкою пакету UDP, сторона, яка відряджає не обмінюється з одержує стороною квитирующего сигналами. Отже, у відправника немає способу дізнатися, чи досягла дейтаграмма кінцевої системи. В результаті UDP не може гарантувати, що дані будуть дійсно доставлені адресату (наприклад, якщо не працює кінцева система або мережа).

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

Використання сесій. Орієнтованість TCP на з'єднання підтримується сеансами між хостами. TCP використовує ідентифікатор сеансу, що дозволяє відстежувати з'єднання між двома хостами. UDP не має підтримки сеансів через свою природи, що не орієнтованої на з'єднання.

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

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

управління потоком. У UDP управління потоком відсутня, в результаті погано спроектоване UDP-додаток може захопити значну частину пропускної здатності мережі.

переваги UDP

У порівнянні з TCP UDP має такі переваги:

Ні установки з'єднання. UDP є протоколом без організації з'єднань, тому він звільняє від накладних витрат, пов'язаних з установкою з'єднань. Оскільки UDP не користується сигналами квитирования, то затримок, викликаних установкою з'єднань, також вдається уникнути. Саме тому DNS віддає перевагу UDP перед TCP - DNS працювала б набагато повільніше, якби вона виконувалася через TCP.

швидкість. UDP працює швидше TCP. З цієї причини багато додатків вважають за краще не TCP, a UDP. Ті ж кошти, які роблять TCP більш стійким (наприклад сигнали квитування), уповільнюють його роботу.

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

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

Розмір заголовка. Для кожного пакету заголовок UDP має довжину всього лише вісім байтів, в той час як TCP має 20-байтові заголовки, і тому UDP споживає менше пропускної здатності мережі.