Протоколи TCP та UDP

TCP- Transmission Control Protocol

Обмін даними, орієнтований на з'єднання, може використовувати надійний зв'язок, для забезпечення якого протокол рівня 4 надсилає підтвердження про отримання даних і запитує повторну передачу, якщо дані не отримані або спотворені. Протокол TCP використовує саме такий надійний зв'язок. TCP використовується у таких прикладних протоколах, як HTTP, FTP, SMTP та Telnet.

Протокол TCP вимагає, щоб перед надсиланням повідомлення було відкрито з'єднання. Серверний додаток має виконати так зване пасивне відкриття (passive open), щоб створити з'єднання з відомим номером порту, і замість того, щоб відправляти дзвінок до мережі, сервер переходить в очікування надходження вхідних запитів. Клієнтський додаток має виконати активне відкриття (active open), відправивши серверному додатку синхронізуючий порядковий номер(SYN), що ідентифікує з'єднання. Клієнтська програма може використовувати динамічний номер порту як локальний порт.

Сервер повинен надіслати клієнту підтвердження (ACK) разом із порядковим номером (SYN) сервера. У свою чергу, клієнт відповідає АСК, і з'єднання встановлюється.

Після цього може розпочатися процес надсилання та отримання повідомлень. При отриманні повідомлення у відповідь завжди надсилається повідомлення АСК. Якщо до отримання АСК відправником закінчується тайм-аут, повідомлення розміщується у чергу на повторну передачу.

Поля заголовка TCP перелічені у таблиці:

Заголовок TCP

Поле	Довжина	Опис
Порт джерела	2 байти	Номер порту джерела
Порт призначення	2 байти	Номер порту призначення
Послідовний номер	4 байти	Послідовний номер генерується джерелом та використовується призначенням, щоб переупорядкувати пакети для створення вихідного повідомлення та надіслати підтвердження джерелу.
Номер підтвердження	4 байти	Якщо встановлено біт АСК поля "Керування", у цьому полі міститься наступний очікуваний послідовний номер.
Зміщення даних	4 біта	Інформація про початок пакета даних.
Резерв	6 бітів	Резервуються на майбутнє використання.
Управління	6 бітів	Біти керування містять прапори, які вказують, чи правильні поля підтвердження (АСК), покажчика терміновості (URG), чи слід скидати з'єднання (RST), чи надіслано синхронізуючий послідовний номер (SYN) і т.д.
Розмір вікна	2 байти	У цьому полі вказується розмір приймального буфера. Використовуючи повідомлення, що підтверджують, одержувач може інформувати відправника про максимальний розмір даних, які той може надіслати.
Контрольна сума	2 байти	Контрольна сума заголовка та даних; по ній визначається, чи був спотворений пакет.
Вказівник терміновості	2 байти	У цьому полі цільовий пристрій отримує інформацію про терміновість даних.
Опції	змінна	Необов'язкові значення, що вказуються за потреби.
Доповнення	змінна	У полі доповнення додається стільки нулів, щоб заголовок закінчувався на 32-бітному кордоні.

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

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

UDP - User Datagram Protocol

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

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

Тож у чому переваги UDP, навіщо може знадобитися такий ненадійний протокол? Щоб зрозуміти причину використання UDP, потрібно розрізняти однонаправлену передачу, широкомовну передачу та групове розсилання.

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

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

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

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

• Мережеві протоколи - що це за страшні назви та з чим їх їдять
• UDP, TCP, ICMP, - Що, навіщо і в чому різниця
• IP-Адреса, - у всіх є, але не всі знають нафіга ця штука:-)
• Маска адреси (підмережа)
• Шлюз (gateway)
• Декілька слів про таблиці маршрутизації
• Порти - що це насправді
• MAC-адреса

Приблизно так.

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

Мережеві протоколи TCP/IP, NWLink IPX/SPX, NetBEUI

Почнемо з того, що взагалі таке мережевий протокол і з чим його їдять.
Мережевий протокол– це набір програмно реалізованих правил спілкування між комп'ютерами. Така мова, якою комп'ютери розмовляють один з одним і передають інформацію. Раніше комп'ютери були, так би мовити, багатомовними і у старих версіях Windowsвикористовувався цілий набір протоколів, - TCP/IP, NWLink IPX/SPX, NetBEUI. Нині ж дійшли загальної домовленості, і стандартом стало використання виключно протоколу TCP/IPа тому мова далі піде саме про нього.

Коли говорять про TCP/IP, то зазвичай мають на увазі під цим ім'ям безліч різних. правил або, скажімо, стандартів, які прописані з використанням (або під використання) цього протоколу. Так, наприклад, є правила, за якими здійснюється обмін повідомленнями між поштовими серверами і є правила, за якими кінцевий користувач одержує до своєї скриньки листи. Є правила для проведення відеоконференцій та правила для організації "телефонних" переговорів по Інтернету. Фактично, це навіть не те щоб правила. Швидше така собі граматика, чи що. Ну знаєте, в англійській одна структура побудови діалогів, у французькій інша. TCP/IPщось подібне, тобто. деяка зв'язка різних граматичних правил є якраз цілісним протоколом TCP/IPабо, точніше кажучи, стек протоколів TCP/IP.

Мережеві протоколи UDP, TCP, ICMP

У рамках протоколу TCP/IPдля передачі даних використовуються протоколи - TCPі UDP. Багато хто напевно чув, що є порти як TCP, так і UDP, але не всі знають у чому різниця і що це взагалі. І так.

Передача даних за протоколом TCP(Transmission Control Protocol - Протокол Управління Передачею) передбачає наявність підтверджень отримання інформації. "-Ну, мовляв, - отримав? -Отримав!" Якщо ж сторона, що передає, не отримає у встановлені терміни необхідного підтвердження, то дані будуть передані повторно. Тому протокол TCPвідносять до протоколів, що передбачають з'єднання, а UDP(User Datagram Protocol - Протокол користувача Датаграм) - ні. UDPзастосовується в тих випадках, коли не потрібно підтвердження прийому (наприклад, DNS-запити або IP-телефонія (яскравий представник якої - Skype)). Тобто різниця полягає у наявності підтвердження прийому. Здавалося б "Усього те!", але на практиці це відіграє важливу роль.

Є ще такий же протокол ICMP(Internet Control Message Protocol - міжмережевий протокол керуючих повідомлень), який використовується передачі даних про параметри мережі. Він включає службові типи пакетів, таки як ping, distintion unreachable, TTLта ін.

Що таке IP-адреса

У всіх він є, але не всі мають уявлення, що за адреса така і чому взагалі без неї не можна. Розповідаю.

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

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

Для побудови локальних мереж виділені спец.діапазони адрес. Це адреси 10.x.x.x,192.168.x.x, 10.x.x.x, c 172.16.x.xпо 172.31.x.x, 169.254.x.x, де під x- мається на увазі будь-яке число це від 0 до 254 . Пакети, що передаються з зазначених адрес, не маршрутизується, інакше кажучи, просто не пересилаються через Інтернет, а тому в різних локальних мережах комп'ютери можуть мати відповідні адреси із зазначених діапазонів. Тобто, у компанії ТОВ " Роги і копита" та ТОВ " Вася та компаніяможуть бути два комп'ютери з адресами 192.168.0.244 але не можуть, скажімо, з адресами 85.144.213.122 , отриманими від інтернет-провайдера, т.к. в інтернеті не може бути два однакових IP-Адреси. Для пересилання інформації з таких комп'ютерів в Інтернет і назад використовуються спеціальні програми та пристрої, які замінюють локальні адреси реальними при роботі з інтернетом. Іншими словами, дані до мережі пересилаються з реального IP-Адреси, а не з локального. Цей процес відбувається не помітно для користувача та називається трансляцією адрес. Хочеться так само згадати, що в рамках однієї мережі, скажімо, компанії, ТОВ Роги і копита", не може бути два комп'ютери з однією локальною IP-адресою, тобто, у вказаному вище прикладі малося на увазі, що один комп'ютер з адресою 192.168.0.244 в одній компанії, другий з такою ж адресою - в іншій. В одній компанії два комп'ютери з адресою 192.168.0.244 просто не уживуться.

Хочете знати та вміти, більше й самі?

Ми пропонуємо Вам навчання за напрямами: комп'ютери, програми, адміністрування, сервери, мережі, сайтобудування, SEO та інше. Дізнайтесь подробиці зараз!

Ви, напевно, чули такі терміни як зовнішній IPта внутрішній IP, постійний (статичний IP) та змінний (динамічний) IP. У двох словах про них:

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

Тип Вашого IP(статичний або динамічний) залежить від установок провайдера.

Що таке маска адреси (підмережа)

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

Маска - це параметр, який повідомляє програмне забезпечення у тому, скільки комп'ютерів об'єднано у цю групу (підмережа). Маска адреси має таку ж структуру як і сама IP-адреса: це набір із чотирьох груп чисел, кожна з яких може бути в діапазоні від 0 до 255 . При цьому чим менше значення маски, тим більше комп'ютерів об'єднано в цю підмережу. Для мереж невеликих компаній маска зазвичай має вигляд 255.255.255.x(наприклад, 255.255.255.224). Маска мережі надається комп'ютеру одночасно з IP-адресою. Так, наприклад, мережа 192.168.0.0 з маскою 255.255.255.0 може містити в собі комп'ютери з адресами 192.168.0.1 до 192.168.254 192.168.0.0 з маскою 255.255.255.128 допускає адреси від 192.168.0.1 до 192.168.0.127 . Думаю, сенс зрозумілий. Як правило, мережі з невеликим можливим числом комп'ютерів використовуються провайдерами з метою економії IP-адрес. Наприклад, клієнту, може бути призначена адреса з маскою 255.255.255.252 . Така підмережа містить лише два комп'ютери.

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

Що таке Шлюз (Gateway)

Шлюз – це пристрій (комп'ютер або маршрутизатор), який забезпечує пересилання інформації між різними IP-підмережами. Якщо програма визначає (IP і маску), що адреса призначення не входить до складу локальної підмережі, то вона відправляє ці дані на пристрій, що виконує функції шлюзу. У налаштуваннях протоколу вказують IP-адресу такого пристрою.

Для роботи лише в локальній мережі шлюз може не вказуватись.

Для індивідуальних користувачів, що підключаються до Інтернету, або для невеликих підприємств, що мають єдиний канал підключення, в системі повинна бути лише одна адреса шлюзу, - це адреса пристрою, який має підключення до Інтернету. За наявності кількох маршрутів існуватиме кілька шлюзів. У цьому випадку визначення шляху передачі даних використовується таблиця маршрутизації.

Що таке таблиці маршрутизації

І ось ми плавно дісталися до них. І так. Що ж за таблиці такі.

Організація або користувач може мати кілька точок підключення до Інтернету (наприклад, резервні канали на випадок, якщо у першого провайдера щось вийде з ладу, а інтернет таки дуже потрібен) або утримувати у своїй структурі кілька IP-Мереж. У цьому випадку, щоб система знала яким шляхом (через який шлюз) надсилати ту чи іншу інформацію, використовуються таблиці маршрутизації. У таблицях маршрутизації кожного шлюзу вказуються ті підмережі Інтернету, котрим через них має передаватися інформація. При цьому для декількох шлюзів можна задати однакові діапазони, але з різною вартістю передачі даних: наприклад, інформація, буде пересилатися по каналу, що має найнижчу вартість, а у разі виходу його з ладу з тих чи інших причин, автоматично буде використовуватися наступне доступне найбільше дешеве з'єднання.

Що таке мережеві порти

При передачі даних крім IP-адрес відправника та одержувача пакет інформації містить у собі номери портів. Приклад: 192.168.1.1: 80 , - у даному випадку 80 - Це номер порту. Порт - це деяке число, яке використовується при прийомі та передачі даних для ідентифікації процесу (програми), який має обробити дані. Так, якщо пакет надіслано на 80 -й порт, це свідчить, що інформація призначена серверу HTTP.

Номери портів з 1 -го до 1023 -й закріплені за конкретними програмами (так звані well-known-порти). Порти з номерами 1024 -65 535 можуть бути використані у програмах власної розробки. При цьому можливі конфлікти мають вирішувати самі програми шляхом вибору вільного порту. Іншими словами, порти розподілятимуться динамічно: можливо, що при наступному старті програма вибере інше значення порту, якщо, звичайно, Ви вручну через налаштування не задавали їй порт.

Що є MAC-адреса

Справа в тому, що пакети, що пересилаються в мережі, адресуються комп'ютерам не за їх іменами і не на IP-Адреса. Пакет призначається пристрою з конкретною адресою, яка і називається MAC-Адресою.

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

Як правило MAC-адреса буває потрібна для ідентифікації, скажімо, у провайдера (якщо провайдер використовує прив'язку по мак-адресі замість логіна-паролю) або при налаштуванні маршрутизатора.

Де переглянути всі мережеві налаштування

Ледве не забув сказати пару слів про те де можна подивитися і змінити все це.

Говорячи про безпеку інформації, ми маємо на увазі конфіденційність, цілісність та доступність інформації у кожний момент часу. І якщо з конфіденційністю та доступністю все зрозуміло, то як забезпечити цілісність інформації при її передачі через мережу? Для вирішення цього завдання нам знадобиться знання мережевих протоколів. У цій статті ми розглянемо протоколи 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 телефонії.

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

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

Привіт, мене звуть Гленн Фідлер і я вітаю вас у першій статті з моєї онлайн-книги "Мережеве програмування для розробників ігор".

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

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

Вибір типу сокетів залежить від жанру гри, яку розробляєте. У даному циклі статей я вважатиму, що ви пишете гру в стилі action - на зразок Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress і т.п.

Тепер ми детальніше розглянемо властивості кожного типу сокетів (враховуючи той факт, що ми розробляємо гру в стилі action), і трохи заглибимося в деталі роботи мережі інтернет. Після детального огляду правильний варіант стане очевидним!

TCP розшифровується як “transmission control protocol” (протокол контролю передачі), а IP - як “internet protocol”. Разом вони лежать в основі практично всього, що ви робите в мережі, починаючи від перегляду веб-сторінок і закінчуючи спілкуванням в IRC та електронною поштою – все це працює на основі TCP/IP.

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

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

Ще раз - все просто, як звичайний запис або читання з файлу. Елементарно, Ватсон!

Але така простота у зверненні зовсім відрізняється від того, що насправді відбувається «під капотом», на нижчому рівні – на рівні протоколу IP.

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

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

А що якщо ми захочемо пересилати інформацію між комп'ютерами не в стилі читання/запису до файлу, а безпосередньо надсилаючи та отримуючи окремі пакети?

Що ж, ми можемо це зробити, використовуючи UDP. UDP розшифровується як "user datagram protocol" (протокол користувальницьких датаграм), і він працює поверх IP (як і TCP), але замість додавання купи функціональності він є лише невеликою надбудовою над IP.

Використовуючи UDP, ми можемо надіслати пакет за певною IP-адресою (наприклад, 112.140.20.10) і портом (наприклад, 52423), і він буде передаватися від комп'ютера до комп'ютера, поки не досягне мети (або не загубиться по дорозі).

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

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

Також UDP не гарантує порядок доставки пакетів. Ви можете відправити п'ять пакетів по порядку - 1, 2, 3, 4, 5 - а прийти вони можуть зовсім в іншому порядку - наприклад, 3, 1, 2, 5, 4. Знову ж таки, на практиці, вони швидше за все прийдуть у правильному порядку у більшості випадків, але покладатися на це не можна!

Зрештою, хоч UDP і нічого особливо не додає до IP, одну річ він таки гарантує. Якщо ви пересилаєте пакет, то він або повністю дійде, або не дійде взагалі. Так, якщо ви пересилаєте пакет у 256 байт іншому комп'ютеру, то він не може отримати лише перші 100 байт від пакета – він обов'язково має отримати всі 256 байт. Це реально єдина річ, яку гарантує протокол UDP – все інше лягає на ваші плечі.

Отже, нам потрібно вирішити – використовувати TCP чи UDP сокети? Погляньмо на їх властивості:

• Використовує принцип з'єднань
• Гарантує доставку та черговість
• Автоматично розбиває інформацію на пакети
• Слідкує за тим, щоб не пересилати дані занадто інтенсивно (контроль потоку даних)
• Легко використовувати - як запис/читання з файлу

UDP:

• Не використовує принципу з'єднань - доведеться реалізовувати це вручну
• Не гарантує доставку та порядок доставки пакетів - вони можуть дійти у неправильному порядку, з дублікатами, або взагалі не дійти!
• Потрібно вручну розбивати дані на пакети та надсилати їх
• Потрібно стежити за тим, щоб не пересилати дані надто інтенсивно
• Якщо пакет загубиться, потрібно якось це відстежити, і у разі потреби переслати його заново

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

А ось і ні.

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

Як працює TCP

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

Отже, як він це робить?

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

Така поведінка може стати проблемою для нашої розрахованої на багато користувачів гри, якщо потрібно передавати дуже маленькі пакети. Може статися так, що TCP вирішить не передавати наші дані, поки їх не накопичиться достатньо, щоб сформувати пакет певного розміру (скажімо більше ста байт). І це велика проблема, тому що необхідно передавати дані з клієнта (натискання клавіш гравця) на сервер якнайшвидше, і якщо при цьому виникатимуть затримки через буферизацію даних протоколом, то для гравця на клієнтській стороні гра відбуватиметься далеко не самим приємним чином. При цьому оновлення об'єктів гри відбуватиметься із затримкою та рідко – тоді як нам потрібно робити оновлення об'єктів вчасно та часто.

TCP має опцію, покликану виправити це - “TCP_NODELAY”. Вона каже протоколу, щоб він не чекав на накопичення даних у черзі на відправку, а відсилав їх відразу.

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

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

Як TCP забезпечує надійність з'єднання

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

Але що буде, якщо один із пакетів не дійде? Чи, якщо пакети прийдуть не по порядку, чи з дублікатами?

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

Проблема у тому, що коли TCP в такий спосіб “синхронізує” потік даних, у разі втрати пакета передача зупиняється до того часу, поки втрачений пакет буде відправлено заново (і отримано адресатом). Якщо під час очікування прийдуть нові дані, вони будуть поставлені в чергу, і ви не зможете прочитати їх, поки не дійде цей втрачений пакет. Скільки часу займає надсилання пакета заново? Вона займає як мінімум час, що дорівнює часу проходження пакета туди і назад (коли TCP визначає, який пакет треба відправити заново), плюс час на повторну доставку втраченого пакета. Так що, якщо пінг між комп'ютерами складає 125 мс, повторна передача пакета займе приблизно одну п'яту секунди, а в гіршому випадку - до півсекунди (уявіть, якщо раптом знову відправлений пакет теж загубиться). Веселуха!

Чому ніколи не варто використовувати TCP для розрахованих на багато ігор

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

Розглянемо простий приклад розрахованої на багато користувачів гри, наприклад, 3d-шутер. Мережева частина в грі побудована дуже просто: кожну ітерацію циклу гри клієнт посилає на сервер опис усіх дій гравця (натиснені клавіші, положення миші тощо), і кожну ітерацію сервер обробляє ці дані, оновлює модель ігрового світу та посилає назад клієнту поточні позиції об'єктів світу, щоби той відмалював гравцеві новий кадр.

Отже, в нашій грі, якщо пакет буде втрачено під час передачі по мережі, гра зупиняється і чекає, поки пакет не буде доставлено заново. На стороні клієнта ігрові об'єкти завмирають, і на сервері гравці також не можуть рухатися або стріляти, оскільки сервер не може приймати нові пакети. Коли втрачений пакет нарешті доходить, він містить вже застаріла інформація, яка вже є неактуальною. До того ж після цього приходять і всі пакети, які накопичилися в черзі за час очікування, і їх усіх потрібно обробити за одну ітерацію циклу. Повна плутанина!

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

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

Але зачекайте! Чому я не можу використовувати UDP і TCP разом?

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

Звичайно, велика спокуса використовувати UDP для передачі даних введення користувача і стану світу, а TCP - для тих даних, які повинні бути гарантовано доставлені. Можливо, ви навіть думаєте, що можна зробити кілька "потоків" команд, наприклад, один для завантаження рівнів, інший - для команд AI. Ви думаєте: "Мені не потрібно, щоб команди AI чекали в черзі, якщо загубиться пакет з даними для завантаження рівня, адже вони зовсім не пов'язані!". В даному випадку ви маєте рацію, і ви можете вирішити створити по TCP сокету на кожен потік команд.

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

8 відповідей

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

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

У певних ситуаціях використовується UDP, оскільки дозволяє передавати пакетну передачу. Це іноді є фундаментальним у таких випадках, як протокол DHCP , оскільки клієнтська машина ще не отримала IP-адресу (це протокол протоколу t26 >), і не буде ніякого способу встановити TCP потік без адреси IP .

UDP (User Datagram Protocol) - це звичайний протокол, що широко використовується в Інтернеті. Однак UDP ніколи не використовується для надсилання важливих даних, таких як веб-сторінки, відомості про базу даних тощо; UDP зазвичай використовується для потокової передачі аудіо та відео. Потокові медіа, такі як аудіофайли Windows Media (.WMA), Real Player (.RM) та інші, використовують UDP, тому що він пропонує швидкість! Причина, через яку UDP працює швидше, ніж TCP, полягає в тому, що немає контролю потоку або виправлення помилок. На дані, надіслані через Інтернет, впливають зіткнення, і помилки будуть присутні. Пам'ятайте, що UDP стосується лише швидкості. Це основна причина, через яку потокові медіа не є якісними.

1) TCP є орієнтованим на з'єднання та надійним, коли UDP є з'єднанням меншим і ненадійним.

2) TCP вимагає додаткової обробки лише на рівні мережного інтерфейсу, де, як й у UDP, немає.

3) TCP використовує тристороннє рукостискання, керування перевантаженням, керування потоком та інший механізм, щоб забезпечити надійну передачу.

4) UDP в основному використовується у випадках, коли затримка пакета серйозніша, ніж втрата пакетів.

Подумайте про TCP як про запланований розклад UPS/FedEx за розкладом UPS/FedEx пакетів між двома розташуваннями, тоді як UDP еквівалентний надсиланню листівки до поштової скриньки.

UPS/FedEx зробить все можливе, щоб переконатися, що пакет, на який ви надсилаєте пошту, потрапляє туди та отримує його вчасно. З поштовою карткою вам пощастило, якщо вона взагалі прийде, і вона може вийти з ладу чи пізно (кілька разів ви отримали листівку від когось ПІСЛЯ того, як вони повернулися додому з відпустки?)

TCP якомога ближче до гарантованого протоколу доставки, тому що ви можете отримати UDP - це просто "краще зусилля".

Причини UDP використовуються для DNS та DHCP:

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

DHCP – DHCP є розширенням BOOTP. BOOTP - це протокол, який клієнтські комп'ютери використовують для отримання інформації про конфігурацію із сервера, в той час як клієнт завантажується. Щоб знайти сервер, широкомовна передача надсилається із запитом на сервери BOOTP (або DHCP). Трансляція може бути надіслана лише через протокол без встановлення з'єднання, такої як UDP. Тому BOOTP вимагав хоча б одного UDP-пакету для широкомовної передачі на сервері. Крім того, оскільки BOOTP працює поки клієнт... завантажується, і це період часу, коли клієнт може не завантажувати і запускати весь свій стек TCP/IP, UDP може бути єдиним протоколом, який клієнт готовий обробляти при цьому час. Нарешті, деякі клієнти DHCP/BOOTP мають лише UDP на борту. Наприклад, деякі IP-термостати реалізують лише UDP. Причина в тому, що вони побудовані з такими крихітними процесорами та невеликим об'ємом пам'яті, які не можуть виконувати TCP, але їм все одно потрібно отримати IP-адресу при завантаженні.

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

Однією з відмінностей є скорочення

UDP. Надсилайте повідомлення і не дивіться назад, якщо він досяг мети, протокол без встановлення з'єднання
TCP: надіслати повідомлення та гарантувати, що ви досягнете адресата, протокол, орієнтований на з'єднання