Протокол
надійної доставки повідомлень TCP
У стеку протоколів TCP/IP протокол TCP (Transmission Control Protocol)
працює так само, як і протокол UDP, на транспортному рівні. Він забезпечує надійне транспортування даних між прикладними процесами шляхом встановлення
логічного з'єднання. p>
Сегменти TCP
Одиницею даних протоколу TCP є сегмент. Інформація, що надходить до протоколу TCP в рамках логічного з'єднання від протоколів більш високого
рівня, розглядається протоколом TCP як неструктурований потік байт. Вступники дані буферизує засобами TCP. Для передачі на мережевий рівень
з буфера "вирізається" деяка безперервна частина даних, яка називається сегментом. p>
У протоколі TCP передбачений випадок, коли програма звертається із запитом про термінову передачу даних (біт PSH в запиті встановлений в 1). У цьому випадку
протокол TCP, не чекаючи заповнення буфера до рівня розміру сегменту, негайно передає вказані дані в мережу. Про таких даних говорять, що вони
передаються поза потоком - out of band. p>
Не всі сегменти, надіслані через з'єднання, будуть одного і того ж розміру, однак обидва учасники з'єднання повинні домовитися про максимального розміру
сегмента, який вони будуть використовувати. Цей розмір вибирається таким чином, щоб при пакуванні сегмента в IP-пакет він містився туди цілком, то є
максимальний розмір сегмента не повинен перевищувати максимального розміру поля даних IP-пакета. В іншому разі довелося б виконувати фрагментацію, то
є ділити сегмент на декілька частин, для того, щоб він вмістився у IP-пакет. p>
Аналогічні проблеми вирішуються і на мережевому рівні. Для того, щоб уникнути фрагментації, потрібно обрати відповідний максимальний розмір IP-пакета.
Однак при цьому повинні бути прийняті до уваги максимальні розміри поля даних кадрів (MTU) всіх протоколів канального рівня, що використовуються в мережі.
Максимальний розмір сегмента не повинен перевищувати мінімальне значення на множині всіх MTU складовою мережі. p>
Порти та встановлення TCP-з'єднань
У протоколі TCP також, як і в UDP, для зв'язку з прикладними процесами використовуються порти. Номери портів присвоюються аналогічним чином: є
стандартні, зарезервовані номери (наприклад, номер 21 закріплений за сервісом FTP, 23 - за telnet), а менш відомі програми користуються довільно
вибраними локальними номерами. p>
Однак у протоколі TCP порти використовуються трохи іншим способом. Для організації надійної передачі даних передбачається встановлення логічного
з'єднання між двома прикладними процесами. У рамках з'єднання здійснюється обов'язкове підтвердження правильності прийому для всіх
надіслані повідомлення, і при необхідності виконується повторна передача. З'єднання в TCP дозволяє вести передачу даних одночасно в обидва боки, то
є повнодуплексному передачу. p>
З'єднання в протоколі TCP ідентифікується парою повних адрес обох взаємодіючих процесів (кінцевих точок). Адреса кожній з кінцевих точок
включає IP-адресу (номер мережі і номер комп'ютера) і номер порту. Одна крайова точка може брати участь в декількох з'єднаннях. p>
Встановлення з'єднання виконується в наступній послідовності: p>
При встановленні з'єднання одна зі сторін є ініціатором.
Вона надсилає запит до протоколу TCP на відкриття порту для передачі (active
open).
Після відкриття порту протокол TCP на стороні процесу-ініціатора
надсилає запит процесу, з яким потрібно встановити з'єднання.
Протокол TCP на приймальній стороні відкриває порт для отримання даних
(passive open) і повертає квитанцію, що підтверджує прийом запиту.
Для того щоб передача могла вестися в обидві сторони, протокол на
приймальній стороні також відкриває порт для передачі (active port) і також
передає запит до протилежної сторони.
Сторона-ініціатор відкриває порт для прийому і повертає
квитанцію. З'єднання вважається встановленим. Далі відбувається обмін
даними в рамках даного з'єднання.
Концепція квітірованія
У рамках з'єднання правильність передачі кожного сегмента повинна підтверджуватися квитанцією одержувача. Квітірованіе - це один з
традиційних методів забезпечення надійного зв'язку. Ідея квітірованія полягає в наступному. p>
Для того, щоб можна було організувати повторну передачу перекручених даних відправник нумерує відправляються одиниці переданих даних (далі для
простоти звані кадрами). Для кожного кадру відправник чекає від приймача так звану позитивну квитанцію - службове повідомлення,
яке повідомляє про те, що вихідний кадр був отриманий і дані в ньому опинилися коректними. Час цього очікування обмежена - при відправці кожного кадру
передавач запускає таймер, і якщо по його закінченню позитивна квитанція на отримана, то кадр вважається загубленим. У деяких протоколах приймач, у разі
отримання кадру з викривленими даними повинен відправити негативну квитанцію - явне зазначення того, що даний кадр потрібно передати повторно. p>
Існують два підходи до організації процесу обміну позитивними і негативними квитанціями: з простоями і з організацією "вікна". p>
Метод з простоями вимагає, щоб джерело, що послав кадр, очікував отримання квитанції (позитивної або негативної) від приймача і тільки після цього
посилав наступний кадр (або повторював спотворений). З малюнка 6.1 видно, що в цьому випадку продуктивність обміну даними істотно знижується - хоча
передавач і міг би послати наступний кадр відразу ж після відправлення попереднього, він зобов'язаний чекати приходу квитанції. Зниження продуктивності для цього методу
корекції особливо помітно на низькошвидкісних каналах зв'язку, тобто в територіальних мережах. p>
p>
Рис. 6.1. Метод підтвердження коректності передачі кадрів з простоєм джерела h2>
У другому методі для підвищення коефіцієнта використання лінії джерела дозволяється передати деяку кількість кадрів в безперервному режимі, тобто
в максимально можливому для джерела темпі, без отримання на ці кадри відповідних квитанцій. Кількість кадрів, які дозволяється передавати таким
чином, називається розміром вікна. Малюнок 6.2 ілюструє даний метод для розміру вікна в W кадрів. Зазвичай кадри при обміні нумеруються циклічно, від 1 до
W. При відправці кадру з номером 1 джерела дозволяється передати ще W-1 кадрів до отримання квитанції на кадр 1. Якщо ж за цей час квитанція на кадр 1 так
і не прийшла, то процес передачі припиняється, і по закінченню деякого тайм-ауту кадр 1 вважається втраченим (або квитанція на нього втрачено) і він
передається знову. p>
p>
Рис. 6.2. Метод "вікна" - безперервна відправка пакетів h2>
Якщо ж потік квитанцій надходить більш-менш регулярно, в межах допуску в W кадрів, то швидкість обміну досягає максимально можливої величини для
даного каналу і прийнятого протоколу. p>
Цей алгоритм називають алгоритмом ковзного вікна. Дійсно, при кожному отриманні квитанції вікно переміщується (ковзає), захоплюючи нові
дані, які дозволяється передавати без підтвердження. p>
Реалізація ковзного вікна в протоколі TCP
У протоколі TCP реалізована різновид алгоритму квітірованія з використанням вікна. Особливість цього алгоритму полягає в тому, що, хоча
одиницею переданих даних є сегмент, вікно визначено на множині нумерованих байт неструктурованого потоку даних, що надходять з верхнього
рівня і буферізуемих протоколом TCP. p>
Квитанція надсилається тільки у разі правильного прийому даних, негативні квитанції не надсилаються. Таким чином, відсутність квитанції
означає або прийом спотвореного сегмента, яку втрату сегмента, яку втрату квитанції. p>
Як квитанції одержувач сегмента відсилає повідомлення у відповідь (сегмент), в яке поміщає число, на одиницю перевищує максимальний номер
байти в отриманому сегменті. Якщо розмір вікна дорівнює W, а остання квитанція містила значення N, то відправник може посилати нові сегменти до тих пір,
поки в черговий сегмент не потрапить байт з номером N + W. Цей сегмент виходить за рамки вікна, і передачу в такому випадку необхідно призупинити до приходу
наступній квитанції. p>
Вибір тайм-ауту
Вибір часу очікування (тайм-ауту) черговий квитанції є важливим завданням, результат рішення якої впливає на продуктивність протоколу TCP. p>
Тайм-аут не повинен бути занадто коротким, щоб по можливості виключити надлишкові повторні передачі, які знижують корисну пропускну здатність
системи. Але він не повинен бути і занадто великим, щоб уникнути тривалих простоїв, пов'язаних з очікуванням неіснуючої або "заблудилися"
квитанції. p>
При виборі величини тайм-ауту повинні враховуватися швидкість і надійність фізичних ліній зв'язку, їх довжина і багато інших подібних факторів. У
протоколі TCP тайм-аут визначається за допомогою досить складного адаптивного алгоритму, ідея якого полягає в наступному. При кожній передачі засікається
час від моменту відправлення сегмента до приходу квитанції про його прийомі (час обороту). Отримані значення часів обороту усереднюються з ваговими
коефіцієнтами, зростаючими від попереднього заміру до наступному. Це робиться з тим, щоб посилити вплив останніх вимірів. Як тайм-ауту
вибирається середній час обороту, помножена на деякий коефіцієнт. Практика показує, що значення цього коефіцієнта повинно перевищувати 2. У мережах з
про малі часу обороту при виборі тайм-ауту враховується і дисперсія цієї величини. p>
Реакція на перевантаження мережі
Варіюючи величину вікна, можна вплинути на завантаження мережі. Чим більше вікно, тим більшу порцію непідтверджених даних можна надіслати в мережу. Якщо мережа не
справляється з навантаженням, то виникають черги в проміжних вузлах-маршрутизаторах і в кінцевих вузлах-комп'ютерах. p>
При переповнення прийомного буфера кінцевого вузла "перевантажений" протокол TCP, надсилаючи квитанцію, вміщує в неї новий, зменшений розмір
вікна. Якщо він зовсім відмовляється від прийому, то в квитанції вказується вікно нульового розміру. Однак навіть після цього програма може надіслати повідомлення на
що відмовився від прийому порт. Для цього, повідомлення повинно супроводжуватися позначкою "терміново" (біт URG в запиті встановлений в 1). У такій
ситуації порт зобов'язаний прийняти сегмент, навіть якщо для цього доведеться витіснити з буфера вже знаходяться там дані. p>
Після прийому квитанції з нульовим значенням вікна протокол-відправник час від часу робить контрольні спроби продовжити обмін даними. Якщо
протокол-приймач вже готовий приймати інформацію, то у відповідь на контрольний запит він посилає квитанцію із зазначенням ненульового розміру вікна. p>
Іншим проявом перевантаження мережі є переповнення буферів до маршрутизаторах. У таких випадках вони можуть централізовано змінити розмір вікна,
посилаючи керуючі повідомлення деяким кінцевим вузлам, що дає їм можливість диференційовано управляти інтенсивністю потоку даних у різних частинах мережі. p>
Формат повідомлень TCP
Повідомлення протоколу TCP називаються сегментами і складаються із заголовка і блоку даних. Заголовок сегмента має такі поля: p>
Порт джерела (SOURS PORT) займає 2 байти, ідентифікує
процес-відправник;
Порт призначення (DESTINATION PORT) займає 2 байти,
ідентифікує процес-отримувач;
Послідовний номер (SEQUENCE NUMBER) займає 4 байти,
вказує номер байта, який визначає зміщення сегмента щодо
потоку даних, що відправляються;
Підтверджений номер (ACKNOWLEDGEMENT NUMBER) займає 4 байти,
містить максимальний номер байта в отриманому сегменті, збільшений на
одиницю; саме це значення використовується в якості квитанції;
Довжина заголовка (HLEN) займає 4 біта, вказує довжину заголовка
сегмента TCP, обмірювану в 32-бітових словах. Довжина заголовка не
фіксована та може змінюватися в залежності від значень, що встановлюються
у полі Опції;
Резерв (RESERVED) займає 6 бітів, поле зарезервовано для
подальшого використання;
Кодові біти (CODE BITS) займають 6 бітів, містять службову
інформацію про тип даного сегмента, що задається установкою в одиницю
відповідних біт цього поля:
URG - термінове повідомлення;
ACK - квитанція на прийнятий сегмент;
PSH - запит на відправку повідомлення без очікування заповнення буфера;
RST - запит на відновлення з'єднання;
SYN - повідомлення що використовується для синхронізації лічильників
переданих даних при встановленні з'єднання;
FIN - ознака досягнення передавальної стороною останнього байта в
потоці даних для передачі.
Вікно (WINDOW) займає 2 байти, містить повідомляються значення
розміру вікна в байтах;
Контрольна сума (CHECKSUM) займає 2 байти, розраховується за
сегменту;
Покажчик терміновості (URGENT POINTER) займає 2 байти,
використовується спільно з кодовим бітом URG, вказує на кінець даних,
які необхідно терміново прийняти, не дивлячись на переповнення буферу;
Параметри (OPTIONS) - це поле має змінну довжину і може взагалі
відсутнім, максимальна величина поля 3 байти; використовується для
вирішення допоміжних завдань, наприклад, при виборі максимального розміру
сегмента;
Заповнювач (PADDING) може мати змінну довжину, представляє
собою фіктивне поле, що використовується для доведення розміру заголовка до
цілого числа 32-бітових слів.