Транспортні протоколи Інтернету

На транспортному рівні в Інтернеті застосовуються два основних протоколи: TCP (Transmission Control Protocol — протокол керування передачею) та UDP (User Datagram Protocol — протокол дейтаграм користувача).

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

Рис. 10.7. Заголовок UDP-сегменту

Два порти виконують ту ж функцію, що і у TCP: ідентифікують кінцеві точки у комп’ютерах відправника і одержувача. Поле Довжина UDP включає 8-байтний бітовий заголовок і дані; Конт­рольна сума UDP обчислюється таким же чином, як і у протоколі TCP, і включає такий же псевдозаголовок, як показано на рис. 10.8. Обчислення контрольної суми є необов’язковим, і якщо контрольна сума не обчислюється, то це поле містить нулі.

Рис. 10.8. Псевдозаголовок, що включений в контрольну суму TCP

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

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

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

Рис. 10.9. Чотири 512-байтових сегментів, відправлених як окремі
IP-дейтаграми (а); 2048 байт даних, доставлені додатку за допомогою
окремого виклику процедури READ (б)

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

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

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

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

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

При фрагментації кожен новий сегмент одержує свій IP-заголовок (20 байт), що збільшує накладні витрати.

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

Рис. 10.10. TCP-заголовок

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

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

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

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

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

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

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

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

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

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

Поле Контрольна сума покликане підвищити надійність. Воно містить контрольну суму заголовка, даних і псевдозаголовка, показаного на рис. 10.8.

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

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

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

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

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

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

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

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

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