У стеці протоколів TCP / IP протокол TCP (Transmission Control Protocol) працює так само, як і протокол UDP, на транспортному рівні. Він забезпечує надійне транспортування даних між прикладними процесами шляхом встановлення логічного з'єднання.
Сегменти TCPОдиницею даних протоколу TCP є сегмент. Інформація, що надходить до протоколу TCP в рамках логічного з'єднання від протоколів більш високого рівня, розглядається протоколом TCP як неструктурований потік байт. Дані, що надходять буферизуются засобами TCP. Для передачі на мережевий рівень з буфера "вирізається" деяка безперервна частина даних, звана сегментом.
У протоколі TCP передбачений випадок, коли програма звертається із запитом про термінову передачу даних (біт PSH у запиті встановлений в 1). У цьому випадку протокол TCP, не чекаючи заповнення буфера до рівня розміру сегменту, негайно передає зазначені дані в мережу. Про такі дані говорять, що вони передаються поза потоку - out of band.
Не всі сегменти, послані через з'єднання, будуть одного і того ж розміру, однак обидва учасники з'єднання повинні домовитися про максимальний розмір сегмента, що вони будуть використовувати. Цей розмір вибирається таким чином, щоб при упаковці сегмента в IP-пакет він містився туди цілком, тобто максимальний розмір сегмента не повинен перевершувати максимальної величини поля даних IP-пакета. В іншому разі довелося б виконувати фрагментацію, тобто ділити сегмент на кілька частин, для того, щоб він вмістився в IP-пакет.
Аналогічні проблеми вирішуються і на мережевому рівні. Для того, щоб уникнути фрагментації, може бути обраний відповідний максимальний розмір IP-пакета. Однак при цьому повинні бути прийняті до уваги максимальні розміри поля даних кадрів (MTU) всіх протоколів канального рівня, які використовуються в мережі. Максимальний розмір сегменту не повинен перевищувати мінімальне значення на множині всіх MTU складовою мережі.
Порти і встановлення TCP-з'єднаньУ протоколі TCP також, як і в UDP, для зв'язку з прикладними процесами використовуються порти. Номери портів присвоюються аналогічним чином: є стандартні, зарезервовані номери (наприклад, номер 21 закріплений за сервісом FTP, 23 - за telnet), а менш відомі програми користуються довільно вибраними локальними номерами.
Однак у протоколі TCP порти використовуються трохи іншим способом. Для організації надійної передачі даних передбачається встановлення логічного з'єднання між двома прикладними процесами. У рамках з'єднання здійснюється обов'язкове підтвердження правильності прийому для всіх переданих повідомлень, і при необхідності виконується повторна передача. З'єднання в TCP дозволяє вести передачу даних одночасно в обидві сторони, тобто повнодуплексну передачу.
З'єднання в протоколі TCP ідентифікується парою повних адрес обох взаємодіючих процесів (кінцевих точок). Адреса кожної з крайових точок включає IP-адресу (номер мережі і номер комп'ютера) і номер порту. Одна крайова точка може брати участь у кількох з'єднаннях.
Встановлення з'єднання виконується в такій послідовності:
При встановленні з'єднання одна з сторін є ініціатором. Вона посилає запит до протоколу TCP на відкриття порту для передачі (active open). Після відкриття порту протокол TCP за процесса-ініціатора надсилає запит процесу, з яким потрібно встановити з'єднання. Протокол TCP на приймальній стороні відкриває порт для прийому даних (passive open) і повертає квитанцію, що підтверджує прийом запиту. Для того щоб передача могла вестися в обидві сторони, протокол на приймальній стороні також відкриває порт для передачі (active port) і також передає запит до протилежної сторони. Сторона-ініціатор відкриває порт для прийому і повертає квитанцію. З'єднання вважається встановленим. Далі відбувається обмін даними в рамках даного з'єднання. Концепція квитированияУ рамках з'єднання правильність передачі кожного сегмента повинна підтверджуватися квитанцією одержувача. Квитирование - це один з традиційних методів забезпечення надійного зв'язку. Ідея квитирования полягає в наступному.
Для того, щоб можна було організувати повторну передачу перекручених даних відправник нумерує відправляються одиниці даних (далі для простоти звані кадрами). Для кожного кадру відправник очікує від приймача так звану позитивну квитанцію - службове повідомлення, що сповіщає про те, що вихідний кадр був отриманий і дані в ньому виявилися коректними. Час цього очікування обмежена - при відправленні кожного кадру передавач запускає таймер, і якщо по його закінченню позитивна квитанція на отримана, то кадр вважається загубленим. У деяких протоколах приймач, у разі отримання кадру з перекрученими даними повинен відправити негативну квитанцію - явне зазначення того, що даний кадр потрібно передати повторно.
Існують два підходи до організації процесу обміну позитивними і негативними квитанціями: з простоями і з організацією "вікна".
Метод із простоями вимагає, щоб джерело, що послав кадр, очікував отримання квитанції (позитивної або негативної) від приймача і тільки після цього посилав наступний кадр (або повторював спотворений). З малюнка 6.1 видно, що в цьому випадку продуктивність обміну даними істотно знижується - хоча передавач і міг би послати наступний кадр відразу ж після відправлення попереднього, він зобов'язаний чекати приходу квитанції. Зниження продуктивності для цього методу корекції особливо помітно на низькошвидкісних каналах зв'язку, тобто в територіальних мережах.
Рис. 6.1. Метод підтвердження коректності передачі кадрів з простоєм джерела
У другому методі для підвищення коефіцієнта використання лінії джерела дозволяється передати деяку кількість кадрів в безперервному режимі, тобто в максимально можливому для джерела темпі, без отримання на ці кадри відповідних квитанцій. Кількість кадрів, які дозволяється передавати таким чином, називається розміром вікна. Малюнок 6.2 ілюструє даний метод для розміру вікна в W кадрів. Зазвичай кадри при обміні нумеруються циклічно, від 1 до W. При відправці кадру з номером 1 джерела дозволяється передати ще W-1 кадрів до отримання квитанції на кадр 1. Якщо ж за цей час квитанція на кадр 1 так і не прийшла, то процес передачі припиняється, і по закінченню деякого тайм-ауту кадр 1 вважається загубленим (або квитанція на нього втрачено) і він передається знову.
Рис. 6.2. Метод "вікна" - безперервна відправка пакетів
Якщо ж потік квитанцій надходить більш-менш регулярно, в межах допуску в W кадрів, то швидкість обміну досягає максимально можливої величини для даного каналу і прийнятого протоколу.
Цей алгоритм називають алгоритмом ковзного вікна. Дійсно, при кожному отриманні квитанції вікно переміщається (ковзає), захоплюючи нові дані, які дозволяється передавати без підтвердження.
Реалізація ковзаючого вікна в протоколі TCPУ протоколі TCP реалізована різновид алгоритму квитирования з використанням вікна. Особливість цього алгоритму полягає в тому, що, хоча одиницею переданих даних є сегмент, вікно визначено на множині нумерованих байт неструктурованого потоку даних, що надходять з верхнього рівня і буферізуемих протоколом TCP.
Квитанція надсилається тільки у випадку правильного прийому даних, негативні квитанції не посилаються. Таким чином, відсутність квитанції означає або прийом спотвореного сегмента, або втрату сегмента, або втрату квитанції.
В якості квитанції одержувач сегмента відсилає у відповідь повідомлення (сегмент), в яке поміщає число, на одиницю перевищує максимальний номер байта в отриманому сегменті. Якщо розмір вікна дорівнює W, а остання квитанція містила значення N, то відправник може посилати нові сегменти до тих пір, поки в черговий сегмент не потрапить байт з номером N + W. Цей сегмент виходить за рамки вікна, та передачу в такому випадку необхідно призупинити до приходу наступної квитанції.
Вибір тайм-аутуВибір часу очікування (тайм-ауту) черговий квитанції є важливим завданням, результат рішення якої впливає на продуктивність протоколу TCP.
Тайм-аут не повинен бути занадто коротким, щоб по можливості виключити надлишкові повторні передачі, які знижують корисну пропускну здатність системи. Але він не повинен бути і занадто великим, щоб уникнути тривалих простоїв, пов'язаних з очікуванням неіснуючої або "заблукав" квитанції.
При виборі величини тайм-ауту повинні враховуватися швидкість і надійність фізичних ліній зв'язку, їх протяжність і багато інших подібних факторів. У протоколі TCP тайм-аут визначається за допомогою досить складного адаптивного алгоритму, ідея якого полягає в наступному. При кожній передачі засікається час від моменту відправки сегменту до приходу квитанції про його прийомі (час обороту). Одержувані значення часів обороту усереднюються з ваговими коефіцієнтами, зростаючими від попереднього заміру до наступному. Це робиться з тим, щоб посилити вплив останніх вимірів. В якості тайм-ауту вибирається середній час обороту, помножене на певний коефіцієнт. Практика показує, що значення цього коефіцієнта повинно перевищувати 2. У мережах з великим розкидом часу обороту при виборі тайм-ауту враховується і дисперсія цієї величини.
Реакція на перевантаження мережіВаріюючи величину вікна, можна вплинути на завантаження мережі. Чим більше вікно, тим більшу порцію непідтверджених даних можна надіслати в мережу. Якщо мережа не справляється з навантаженням, то виникають черги в проміжних вузлах-маршрутизаторах і в кінцевих вузлах-комп'ютерах.
При переповненні приймального буфера кінцевого вузла "перевантажений" протокол TCP, відправляючи квитанцію, поміщає в неї новий, зменшений розмір вікна. Якщо він зовсім відмовляється від прийому, то в квитанції вказується вікно нульового розміру. Однак навіть після цього програма може послати повідомлення на відмовився від прийому порт. Для цього, повідомлення повинно супроводжуватися позначкою "терміново" (біт URG у запиті встановлений в 1). У такій ситуації порт зобов'язаний прийняти сегмент, навіть якщо для цього доведеться витіснити з буфера вже знаходяться там дані.
Після прийому квитанції з нульовим значенням вікна протокол-відправник час від часу робить контрольні спроби продовжити обмін даними. Якщо протокол-приймач вже готовий приймати інформацію, то у відповідь на контрольний запит він посилає квитанцію із зазначенням ненульового розміру вікна.
Іншим проявом перевантаження мережі є переповнення буферів у маршрутизаторах. У таких випадках вони можуть централізовано змінити розмір вікна, посилаючи керуючі повідомлення деяким кінцевим вузлам, що дозволяє їм диференційовано керувати інтенсивністю потоку даних у різних частинах мережі.
Формат повідомлень TCPПовідомлення протоколу TCP називаються сегментами і складаються із заголовка і блоку даних. Тема сегмента має наступні поля:
Порт джерела (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-бітових слів.