Загальні відомості про протокол TCP.

Протокол TCP

Властивості сервісу надійного доручення.

Інтерфейс між прикладною програмою і сервісом дорученняTCP/IP може бути охарактеризований такими п’ятьома властивостями:

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

· З’єднання віртуальних кіл. Модулі програмного забезпечення протоколу в двох операційних системах комунікуються, щоб передати повідомлення через internet, перевіряють, чи передача є авторизована і тоді обидві сторони готові до обміну інформацією - встановлене з’єднання. Якщо з будь-яких причин з’єднання порушується, то обидві машини виявляють обставини і повідомляють відповідні прикладні програми. Це називають віртуальним колом.

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

· Неструктурований потік. Сервіс потоків TCP/IP не підтримує структурованих потоків даних. Прикладна програма, яка використовує сервіс потоків, повинна розуміти вміст потоку і погодити формат потоку, перш ніж ініціювати з’єднання.

· З’єднання з повним дуплексом. З’єднання, які здійснюються сервісом потоків TCP/IP, дозволяють узгоджену передачу даних в обидвох напрямках (повний дуплекс). З точки зору прикладного процесу повний дуплекс складається з двох незалежних потоків, які переміщаються в протилежних напрямках без видимої взаємодії. Потоковий сервіс, який дозволяє обмежити потік в одному напрямку при наявності даних для передачі в протилежному напрямку, називається півдуплекс (half-duplex). Перевага повного дуплексу полягає в тому, що програмне забезпечення протоколів нижчого рівня може висилати контрольну інформацію для одного потоку до джерела в датаграмах, які переносять інформацію в протилежному напрямку. Це зменшує трафік мережі.

Забезпечення надійності.

Операції TCP

Першою фазою сполучення TCP є встановлення сполучення. Це вимагає трьохходового підтвердження (three-way handshacke), чим досягається, що обидві сторони сполучення мають однозначне розуміння послідовності номерного простору віддаленої сторони сполучення. Операції встановлення сполучення такі:

q локальна система висилає до віддаленого кінця сполучення початковий номер послідовності для віддаленого порта, використовуючи пакет SYN;

q віддалена система відповідає підтвердженням (ACK) початкового номеру послідовності та початковим номером послідовності віддаленого кінця у пакеті SYN відповіді;

q локальний кінець відповідає підтвердженням (ACK) цього віддаленого номера послідовності - сполучення встановлене.

Операції цього алгоритму зображені на рис. 3.78.

Рис. 3.78. Трьохходове встановлення сполучення TCP.

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

Після встановлення сполучення протокол TCP керує надійним пересиланням даних між двома системами. Алгоритми, які визначають різні таймери повторного пересилання, можуть бути переозначені багато разів. TCP – це протокол з ковзним вікном і загальний принцип управління потоком базується на управлінні розміром оголошеного вікна та управлінні паузами повторного пересилання з метою оптимізації характеристик протоколу при відомих затримках і втратах пакетів у сполученні. Настроювання стеку протоколів TCP для отримання оптимальних характеристик у високошвидкісних локальних мережах з малою затримкою вимагає інших встановлень, ніж для оптимальних характеристик сполучення через комутовані телефонні лінії, і ще інших встановлень для відповідності вимогам високошвидкісних глобальних мереж. Хоч TCP пробує дослідити значення добутку затримка ´ ширина_смуги для сполучення і пробує автоматично оптимізувати швидкості потоків для оцінених параметрів мережевого шляху, однак окремі оцінки неточні і відповідні зусилля TCP оптимізувати поведінку можуть бути не цілком успішними.

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

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

Інтерактивність у TCP. Інтерактивні протоколи звичайно скеровані на забезпечення взаємодії на рівні окремих символів, при чому кожен символ пересилається окремим пакетом, наприклад, echo. Взаємодія протоколів, яка це підтримує, показана на рис. 3.79.

Рис. 3.79. Інтерактивний обмін.

Це становить 2 байти даних, згенерованих чотирма пакетами TCP/IP, або 160 байтів службового навантаження протоколу. У TCP зроблено невеликі вдосконалення цього обміну шляхом використання вкладеності (piggybacking), коли ACK переноситься у тому самому пакеті, що й дані, і затриманого підтрвердження, коли ACK затримується на час до 200 мс перед висиланням, що дає застосуванням сервера можливість згенерувати дані, в які може бути вкладене підтвердження. Результуючий обмін протоколу зображено на рис. 3.80.

Рис. 3.80. Інтерактивний обмін з використанням затриманого підтвердження.

Для локальних мереж з малою затримкою цей протокольний обмін забезпечує прийнятні характеристики. Такий обмін окремим символом даних і його ехо виникає кожних 16 мс в мережі Ethernet, що відповідає інтерактивному темпу в 60 символів за секунду. Коли мережева затримка зростає (наприклад, у WAN), ці малі пакети можуть бути джерелом перевантажень.

Рис. 3.81. Інтерактивний обмін у WAN.

Механізм TCP, адресований до цих перевантажень малими пакетами, описаний в документі RFC 896 і відомий як алгоритм Nagle. Він забороняє надавачу пересилати будь-який додатковий малий сегмент, доки сполучення TCP має вислані непідтверджені малі сегменти. Для LAN ця модифікація алгоритму має незначний вплив, однак для WAN вприв дуже суттєвий, бо кількість малих пакетів зменшується у безпосередній кореляції з рівнем перевантаженості мережевого шляху. За це збільшуються варіації тривалості сесії (jitter) протягом періоду обігу петлі (RTT). Тому застосування, чутливі до цих варіацій, не використовують цей алгоритм.

Рис. 3.82. Інтерактивний обмін з використанням алгоритму Nagle.

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

-------

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

Більшість надійних протоколів застосовує фундаментальну техніку, відому як позитивне підтвердження з ретрансмісією (positive acknowledgement with retransmission). Ця техніка передбачає, що приймач, який комунікується із джерелом, висилає назад підтвердження (acknowledgement, скорочення -ACK) - повідомлення про прийом даних. Передавач запускає таймер, коли він передає пакет, очікує підтвердження перед передачею наступного пакету, і, якщо час очікування завершився без отримання підтвердження, повторно передає (ретрансмітує) пакет.

Рис. 3.83. Функціонування протоколу передавання з підтвердженням та ретрансмісією.

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

Рис. 3.84. Функціонування протоколу при втраті пакету.

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

q Повнодуплексність. TCP є протоколом з повним дуплексом. Він дозволяє обидвом сторонам сполучення висилати і приймати дані в контексті одного сполучення TCP.

q Орієнтація на потоки. Хоч TCP використовує пакетну структуру для пересилання в мережі, однак TCP є справжнім потоковим протоколом і операції рівня застосувань мережі не є прозорими. Певні протоколи застосувань у явному вигляді інкапсулюють кожну транзакцію, для кожної операції висилання мусить бути узгоджена операція читання. Таким чином Сегментація потоку даних від застосування в логічній структурі потоку даних зберігається у всій мережі. На відміну від цього, протокол TCP не зберігає таку структуру в потоці даних. Наприклад, застосування TCP можуть послідовно вислати три блоки даних у мережеве сполучення, які можуть бути об’єднані у віддаленому приймачі однією операцією читання. Розмір блоку даних (сегменту), який використовується у TCP-сесії, повинен бути узгоджений на початку сесії. Висилач має намір використовувати найбільшу довжину сегменту для пересилання даних у рамках обмежень на розмір сегменту у приймача, максимальної довжини сегменту, сконфігурованої в надавача і максимальної довжини нефрагментованого пакету, яку підтримує шлях в мережі (Maximum Transfer Unit – MTU). Значення MTU для шляху періодично оновлюється для корекції всіх змін, які могли виникнути в мережі під час активності сполучення TCP.

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

Ідея ковзного вікна.

Як видно з повищих рисунків, час простою мережі між передачею пакету і отриманням підтвердження може бути значним. Для підвищення ефективності передачі потоків даних використовується ідея ковзного вікна. Протокол ковзного вікна використовує смугу мережі краще, бо передавач може передати багато пакетів перед очікуванням підтвердження. Протокол розміщає мале вікно фіксованого розміру над послідовністю пакетів і передає всі пакети, розміщені всередині вікна. Пакет називають непідтвердженим (unacknowledged), якщо він висланий, але підтвердження не отримане. Практично число непідтверджених пакетів обмежене розміром вікна. Властивості протоколу ковзного вікна залежать від розміру вікна і швидкості, з якою мережа приймає пакети. Ключова ідея полягає в тому, що всі пакети у вікні передаються, перш ніж буде отримане будь-яке підтвердження. На рис. 5.20 показано, що після отримання підтвердження для пакету 1 вікно “ковзає” і передається наступний пакет (9-й). Рис. 3.85 ілюструє операції протоколу з ковзним вікном, який передає три пакети.

Початкове вікно
										...
				(а)
Вікно ковзнуло ®
										...
				(б)

Рис. 3.85. Ковзне вікно.

Формат сегменту TCP.

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

Рис. 3.89. Формат TCP-сегменту.

Будь-який сегмент ділиться на дві частини: заголовок і дані. TCP-заголовок переносить інформацію, потрібну для ідентифікації та управління. Звичайно розмір TCP-заголовку становить 20 байтів (при відсутності опцій). В TCP-сегменті як опції так і дані можуть бути відсутні.

Значення полів в TCP заголовку:

Номер порта джерела (source port number)	ідентифікатор процесу, що передав пакет;
Номер порта призначення (destination port_number)	ідентифікатор процесу, для якого пакет призначений;
Номер послідовності (sequence number)	ідентифікатор першого байта в пакеті з потоку даних від передаючого TCP модуля до приймаючого TCP модуля, тобто кожен байт в потоці має свій номер. Він не обов’язково починається з 0. Оскільки TCP забезпечує дуплексний зв’язок, дані незалежно можуть передаватися в обох напрямках, кожна сторона веде свій незалежний ідентифікатор послідовності. Ідентифікатор послідовності наступного пакету збільшується на число рівне кількості байтів даних присутніх в попередньому пакеті;
Номер підтвердження (acknowledgment number)	номер наступного ідентифікатора послідовності (sequence) який очікується на приймальній стороні, тим самим підтверджує, що всі попередньо передані дані прийнято правильно;
Довжина заголовку (header length - HLEN)	довжина TCP заголовку в 32-х розрядних словах. Оскільки поле займає 4 біти, максимально можлива довжина заголовку становить 15´4=60 байт. Нормально (коли TCP опції не присутні) тут записано значення 5, тобто заголовок займає 20 байт;
Резерв (reserved)	зарезервовано для майбутнього використання;
Коди прапорців (flags)	поле, що займає 6 біт які розглядаються як 6 прапорців, один або більше з яких можуть бути встановлені в 1. · URG - в даному TCP сегменті присутні термінові дані; · ACK - поле acknowledgment використано для підтвердження прийнятих даних, тобто пакет являється підтвердженням, що не обмежує можливості даного пакету одночасно нести і дані користувача; · PSH - передати прийняті TCP модулем дані пакету якомога швидше до процесу користувача; · RST - ініціатива в розриві або відмова встановлення зв’язку; · SYN - синхронізувати ідентифікатор послідовності, проводиться при встановленні зв’язку; · FIN - джерело пакета повідомляє що воно завершило передавати свою інформацію в данїй TCP сесії, хоча не відмовляється від приймання даних від призначення; Коли в пакеті встановлений SYN, або FIN прапорець, то наступний ідентифікатор послідовності додатково збільшується на 1.
Розмір вікна (windows size)	кількість байт, яку може (погоджується) прийняти джерело TCP сегменту. Саме за допомогою windows size (збільшуючи чи зменшуючи його значення) проводиться контроль потоку інформації на обох сторонах зв’язку;
Контрольна сума (checksum)	контрольна сума сегменту, що покриває як TCP заголовок так і дані. Вона рахується так само як для UDP, використовуючи псевдо-заголовок. На відміну від UDP, в TCP використння контрольної суми завжди є обов’язковим;
Показник терміновості (urgent pointer)	це поле має зміст (аналізується) коли в пакеті встановлено URG прапорець. Число записане тут є позитивним зміщенням, яке треба додати до ідентифікатора послідовності пакету, для того щоб можна було визначити останній байт термінових даних в пакеті;
Опції (options)	додаткові поля заголовку, які розширюють можливості TCP. Вони мають змінну довжину але завжди вирівнюються на 32-х розрядне слово за допомогою поля Набивка. Одна з найчастіше використовуваних опцій це MSS (maximum segment size) - максимальний розмір TCP сегмента який TCP модуль погоджується приймати (передається на фазі встановлення зв’язку);
Дані (data)	дані користувача, кількість байт може бути некратна 32-х розрядним словам.

 

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

Поле HLEN містить ціле число, яке визначає довжину заголовка сегменту в одиницях, кратних 32 бітам. Це потрібно, окільки довжина поля ОПЦІЇ змінюється в залежності від того, які опції включаються в сегмент.

Деякі сегменти передають тільки підтвердження, тоді як інші передають дані. Інші передають запити для встановлення з’єднання або для його припинення. Програмне забезпечення TCP використовує 6-бітова поле КОД для визначення мети і змісту сегменту:

Поле ВІКНО визначає розмір буфера в байтах (октетах).

Хоч TCP є протоколом, орієнтованим на потік даних, часом необхідно терміново подати сигнал про закінчення зв’язку. Для цього дані можуть бути означені як термінові, і приймач може відзначити їх прибуття незалежно від їх позиції в потоці. TCP на приймальній стороні відзначає, яка прикладна програма є віжповідальна за з’єднання в “терміновому режимі”.Після того, як всі термінові дані використані, TCP втановлює прикладну програму до нармального функціонування. Механізм, який використовує позначку термінових даних, складається з біта URG і поля Показник терміновості. Коли біт URG встановлений в 1, показник визначає позицію в сегменті, де закінчуються термінові дані.

Не всі сегменти протягом з’єднання мають однакову довжину. Програмне забезпечення TCP використовує поле ОПЦІЇ; одна з них визначає максимальний розмір сегменту (maximum segment size - MSS).

q Опція максимальний розмір сегменту для приймання (maximum receive segment size). Ця опція використовується, коли відкривається сполучення. Вона потрібна для інформування віддаленого кінця сполучення про максимальний розмір сегменту в октетах, бажаний для приймання у сполученні TCP. Цяопця вживається тільки у посатковому пакеті SYN, який відкриває сполучення TCP. Він встановлює як максимальний розмір сегменту для приймання, так і максимальний розмір оголошеного вікна TCP, пересланого до віддаленого кінця сполучення. У деяких стійких (robust) впровадженнях TCP ця опція може бути використана разом з дослідженням значення MTU шляху для встановлення розміру сегменту, який може пересилатися через сполучення без фрагментації, що є суттєвою властивістю потоку даних з високими характеристиками.

q Опція масштабування вікна (window scale). Ця опція призначена для вирішення проблеми максимального розміру вікна для шляху, який виявляє високу затримку. Опція дозволяє зсувати вправо оголошення розміру вікна на визначену величину (у двійковій арифметиці зсув вправо на один розряд відповідає множенню на 2). Без цієї опції максимальний розмір вікна, який може бути оголошений, становить 65535 байтів (максимальне можливе значення для 16-бітового поля). Обмеження швидкості пересилання для TCP здійснюється фіксацією розміру одного вікна для пересилання між надавачем і приймачем. Для високошвидкісний мереж з великою затримкою (наприклад, при використанні сателітарного каналу) це обмеження є вагомим фактором, бо воно обмежує швидкість пересилання до 65535 байтів на інтервал часу обігу петлі незалежно від перепускної здатності мережі. Використання опції масштабування вікна дозволяє надавачу TCP ефективно пристосовуватися до широкосмугових шляхів з високою затримкою, дозволяючи помістити більше даних до отримання підтвердження. Максимальний розмір вікна з цією опцією становить 2³⁰ байтів. Опція узгоджується при старті сполучення TCP і може бути вислана у пакеті тільки з прапорцем SYN. Слід відзначити, що доки процес дослідження MTU дозволяє оптимальне встановлення опції максимальний розмір сегменту для приймання, доти відповідне дослідження затримки не дозволяє надійного автоматичного встановлення опції масштабування вікна.

q Опція дозволене селективне підтвердження і селективне підтвердження (SACK-permitted and SACK). SACK – це абревіатура від selective acknowledgment (селективне підтвердження). Ця опція змінює поведінку для підтверджень TCP. Опція дозволене селективне підтвердження пропонується для віддаленого кінця сполучення при встановленні сполучення TCP як опція для пакету SYN, який відкриває сполучення. Опція селективне підтвердження (SACK) дозволяє селективне підтвердження дозволених даних. Поведінка підтверджень TCP за замовчуванням полягає у підтвердженні найбільшого номера байту у вхідній послідовності. Ця поведінка за замовчуванням може спричинити непотрібне повторне пересилання, яке може загострити умови перевантаження і обумовити втрату оригінальних пакетів. Опція SACK дозволяє приймачу модифікувати поле підтвердження для опису непослідовних блоків прийнятих даних, так що надавач може повторно переслати тільки ті блоки, які відсутні на приймальному кінці.

Будь яке стійке впровадження TCP з високими характеристиками повинне узгоджувати ці параметри при старті сесії TCP, досягаючи при цьому того, що:

q сесія використовує максимально можливий розмір IP-пакету без фрагментування при транспортуванні;

q розміри вікна, використані при транспортуванні, адекватні затримці на шляху;

q селективне підтвердження може бути використане для швидкого коригування виникнення помилок в лінії або при короткочасному погіршенні характеристик мережі.

Встановлення TCP-з’єднання.

Оскільки TCP відноситься до протоколів із сполученням, перед передаванням даних проводиться встановлення зв’язку. Фаза встановлення зв’язку складається з 3-х TCP-сегментів, якими обмінюються ініціатор (джерело) та призначення:

1. Ініціатор генерує SYN сегмент (TCP-сегмент, де встановлено SYN-прапорець), в якому він вказує необхідні номер порта призначення (destination port), та свій початковий ідентифікатор послідовності (initial sequence number - ISN), з якого він починає нумерувати свої дані;

2. Призначення у відповідь генерує свій SYN-сегмент, встановлюючи destination port рівний source port ’у який був у пакеті ініціатора, та вибираючи свій ISN. Додатково пакет підтверджує сегмент ініціатора, піднімаючи ACK прапорець та встановлюючи acknowledgment number рівний значенню ISN ініціатора плюс 1 (нагадуємо що SYN прапорець додатково збільшує sequence number на 1);

3. Ініціатор підтверджує SYN сегмент призначення шляхом передачі пакету, в якому встановлено ACK-прапорець, та acknowledgment number дорівнює ISN призначення.

Рис. 3. 90. Встановлення TCP-з'єднання.

Сторона, яка виступає ініціатором, тобто відсилає першою свій SYN сегмент, робить так зване “активне” відкривання (active open) зв’язку, а сторона що відповідає на цей сегмент своїм SYN пакетом, відповідно “пасивне” відкривання (passive open). В англомовній літературі фазу встановлення зв’язку часто називають “three-way handshake”. В найпростішому випадку процес відбувається так, як показано на рис 3.90.

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

Тришляхове підтвердження зв'язку здійснює дві важливі функції:

· гарантує, що обидві сторони готові до передавання даних;

· що обидві сторони погодили початковий номер послідовності.

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

Щоб побачити, що комп’ютери можуть погодити номери послідовностей для двох потоків тільки після трьох підтверджень, повторимо, що будь-який сегмент містить як поле номеру послідовності, так і поле підтвердження. Комп’ютер А, який ініціює підтвердження, передає свій початковий номер послідовності x в полі послідовності першого SYN-сегменту в тришляховому підтвердженні. Другий комп’ютер, B, приймає SYN, записує номер послідовності і відповідає, висилаючи свій початковий номер послідовності в полі послідовності як підтвердження, яке визначає сподіваний від B октет x+1. В останньому повідомленні-підтвердженні А “підтверджує” прийом від В всіх октетів від початку до кінця y. У всіх випадках підтвердження дотримується угоди про використання номера наступного октету за очікуваним.

Припинення TCP-з’єднання.

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

1. Ініціатор завершення зв’язку генерує TCP сегмент в якому втановлено FIN прапорець, що говорить про те, що він вже передав усі необхідні дані, і бажає завершити передачу зі свого боку;

2. Призначення генерує ACK сегмент в якому підтверджується FIN пакет ініціатора, тим самим знаючи що більше від нього дані не поступатимуть. Але це не означає що призначення не може продовжувати передачу своїх даних;

3. Призначення завершивши передачу всіх необхідних даних генерує свій FIN пакет, тим самим повідомляючи про кінець передачі зі свого боку, а тобто і про бажання завершити TCP зв’язок;

4. Ініціатор підтверджує FIN пакет призначення своїм ACK пакетом, після чого зв’язок рахується повністю розірваним.

Рис. 3.91. Припинення TCP-з'єднання.

TCP-сегменти 1 і 2 являють собою так зване часткове завершення (half close) зв’язку з одного боку. Говорять що ініціатор, той хто першим послав FIN пакет, робить “активне завершення” (active close), а друга сторона відповідно “ пасивне завершення ” (passive close). На рисунку 3.91 зображено часову діаграму фаз встановлення та завершення зв’язку.

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

 

UDP-данограма.

В комплекті протоколів TCP/IP протокол датаграм користувача (User Datagram Protocol - UDP) здійснює первинний механізм, який використовує прикладна програма для передавання данограми до іншої прикладної програми. UDP є першим прикладом транспортного протоколу і розташований над шаром IP. UDP здійснює ненадійний безз’єднальний сервіс доручення, використовуючи данограми IP для транспорту повідомлень між машинами, однак додає здатність до розпізнавання серед різних призначень в даному вузлі. Будь-яке UDP-повідомлення називають UDP-данограмою. Кожна спроба прикладного процесу передати через мережу інформацію викликає утворення тільки однієї UDP-данограми, що інкапсулюється в одну IP-данограму (рис. 3.98).

Рис. 3.98. Інкапсуляція UDP-данограми.

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

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

Концептуально UDP-данограма складається з двох частин: UDP-заголовка і області даних.

На рисунку 3.99 наведено формат UDP-данограми.

Рис. 3.99. Формат UDP-данограми.

UDP-заголовок.

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

Поле Довжина містить кількість октетів (байтів) і UDP-датаграмі включно із UDP-заголовком (8 байтів) і даними користувача; мінімальне значення рівне 8.

Рис. 3.100. Данограма UDP, інкапсульована в данограмі IP.

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

Протокол TCP

Загальні відомості про протокол TCP.

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

Рис. 3.74. Операції на транспортному рівні.

Транспортний рівень передбачає такі особливості:

q більшість застосувань вимагають, щоб транспортний рівень був орієнтований на сполучення, тобто він мусить забезпечувати встановлення і припинення сполучення;

q необхідність або можливість наскрізного контролю помилок.

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

q є надійними, орієнтованими на сполучення, повнодуплексними;

q здійснюють пересилання потоків, без видимого пакетування;

q є наскрізними, тобто діють безпосередньо між двома процесами.

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

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

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