TCP

Transmission Control Protocol (TCP) (протокол управління передачею) - один з основних мережевих протоколів Інтернету, призначений для управління передачею даних в мережах і підмережах TCP / IP.

Виконує функції протоколу транспортного рівня моделі OSI.

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

Реалізація TCP, як правило, вбудована в ядро ОС, хоча є і реалізації TCP в контексті додатка.

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


1. Заголовок сегмента TCP

Заголовок сегмента TCP
Біт 0 - 3 4 - 9 10 - 15 16 - 31
0 Порт джерела Порт призначення
32 Номер послідовності
64 Номер підтвердження
96 Зсув даних Зарезервовано Прапори Розмір Вікна
128 Контрольна сума Покажчик важливості
160 Опції (необов'язкове, але використовується практично завжди)
160/192 +
Дані

1.1. Порт джерела

Порт джерела ідентифікує додаток клієнта, з якого відправлено пакети. Після повернення дані передаються клієнту на підставі номери порту джерела.

1.2. Порт призначення

Порт призначення ідентифікує порт, на який відправлений пакет.

1.3. TCP-порти

Існує набір служб (що використовують для передачі даних TCP), за якими закріплені певні порти:

См. Список портів TCP і UDP


1.4. Номер послідовності

Номер послідовності виконує два завдання:

  1. Якщо встановлений прапор SYN, то це початкове значення номера послідовності - ISN (Initial Sequence Number), і перший байт даних, які будуть передані в наступному пакеті, буде мати номер послідовності, рівний ISN + 1.
  2. В іншому випадку, якщо SYN не встановлений, перший байт даних, який передається в даному пакеті, має цей номер послідовності.

Оскільки потік TCP в загальному випадку може бути довшим, ніж число різних станів цього поля, то всі операції з номером послідовності повинні виконуватися по модулю 2 ^ 32. Це накладає практичне обмеження на використання TCP. Якщо швидкість передачі комунікаційної системи така, щоб протягом MSL (максимального часу життя сегмента) сталося переповнення номера послідовності, то в мережі може з'явитися два сегменти з однаковим номером, що відносяться до різних частин потоку, і приймач отримає некоректні дані.


1.5. Номер підтвердження

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

1.6. Зсув даних

Це поле визначає розмір заголовка пакета TCP в 4-байтних (4-октетное) словах. Мінімальний розмір складає 5 слів, а максимальний - 15, що становить 20 і 60 байт відповідно. Зсув вважається від початку заголовка TCP.

1.7. Зарезервовано

Зарезервовано (6 біт) для майбутнього використання і повинно встановлюватися в нуль. З них два (5-й і 6-й) вже визначені:

  • CWR (Congestion Window Reduced) - Поле "Вікно перевантаження зменшено" - прапор встановлено відправником, щоб вказати, що отриманий пакет зі встановленим прапором ECE (RFC 3168)
  • ECE (ECN-Echo) - Поле "Ехо ECN" - вказує, що даний вузол здатний на ECN (явне повідомлення перевантаження) і для вказівки відправнику про перевантаження в мережі (RFC 3168)

1.8. Прапори (керуючі біти)

Це поле містить 6 бітових прапорів:

  • URG - Поле "Покажчик важливості" задіяно ( англ. Urgent pointer field is significant )
  • ACK - Поле "Номер підтвердження" задіяно ( англ. Acknowledgement field is significant )
  • PSH - ( англ. Push function ) Інструктує одержувача проштовхнути дані, накопичені в приймальному буфері, в додаток користувача
  • RST - Обірвати з'єднання, скинути буфер (очищення буфера) ( англ. Reset the connection )
  • SYN - Синхронізація номерів послідовності ( англ. Synchronize sequence numbers )
  • FIN ( англ. final , Біт) - прапор, будучи встановлений, вказує на завершення з'єднання ( англ. FIN bit used for connection termination ).

1.9. Вікно

У цьому полі міститься число, що визначає в байтах розмір даних, які відправник готовий прийняти.

1.10. Псевдозаголовок

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

TCP-псевдозаголовок IPv4

Біти 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0-31 IP-адреса відправника (Source address)
32-63 IP-адреса одержувача (Destination address)
64-95 0 0 0 0 0 0 0 0 Протокол (Protocol) Довжина TCP-сегмента (TCP length)

TCP-псевдозаголовок IPv6

Біти 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0-96 IP-адреса відправника (Source address)
128-224 IP-адреса одержувача (Destination address)
256 Довжина TCP-сегмента (TCP length)
288 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Протокол верхнього рівня (Next header)
  • Протокол (Protocol) / Протокол верхнього рівня (Next header) - містить в собі значення 6 (000000110 в двійковому вигляді, 0x6 - в шістнадцятковому) - ідентифікатор TCP-протоколу.
  • Довжина TCP-сегмента (TCP length) - містить в собі довжину TCP-сегмента в байтах (TCP-заголовок + дані; довжина псевдозаголовка не враховується).

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


1.11. Контрольна сума

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


1.12. Покажчик важливості

16-бітове значення позитивного зсуву від порядкового номера в даному сегменті. Це поле вказує порядковий номер октету, яким закінчуються важливі (urgent) дані. Поле приймається до уваги тільки для пакетів з встановленим прапором URG.

1.13. Опції

Можуть застосовуватися в деяких випадках для розширення протоколу. Іноді використовуються для тестування. На даний момент в опції практично завжди включають 2 байти NOP (в даному випадку 0x01) і 10 байт, що задають timestamps. Обчислити довжину поля опції можна через значення поля зсуву.

2. Механізм дії протоколу

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

  • Установка з'єднання
  • Передача даних
  • Завершення з'єднання

2.1. Стану сеансу TCP

Спрощена діаграма станів TCP. Більш докладно в TCP EFSM diagram (англійською мовою)
Стану сеансу TCP
CLOSED Початковий стан вузла. Фактично фіктивне
LISTEN Сервер очікує запитів встановлення з'єднання від клієнта
SYN-SENT Клієнт відправив запит серверу на встановлення з'єднання і чекає відповіді
SYN-RECEIVED Сервер отримав запит на з'єднання, відправив відповідний запит і очікує підтвердження
ESTABLISHED З'єднання встановлено, йде передача даних
FIN-WAIT-1 Одна зі сторін (назвемо її вузол-1) завершує з'єднання, відправивши сегмент з прапором FIN
CLOSE-WAIT Інша сторона (вузол-2) переходить в цей стан, відправивши, в свою чергу сегмент ACK і продовжує односторонню передачу
FIN-WAIT-2 Вузол-1 отримує ACK, продовжує читання і чекає отримання сегмента з прапором FIN
LAST-ACK Вузол-2 закінчує передачу і відправляє сегмент з прапором FIN
TIME-WAIT Вузол-1 отримав сегмент з прапором FIN, відправив сегмент з прапором ACK і чекає 2 * MSL секунд, перед остаточним закриттям з'єднання
CLOSING Обидві сторони ініціювали закриття з'єднання одночасно: після відправки сегменту з прапором FIN вузол-1 також отримує сегмент FIN, відправляє ACK і знаходиться в очікуванні сегмента ACK (підтвердження на свій запит про роз'єднання)

2.2. Установка з'єднання

Процес початку сеансу TCP - позначене як "рукостискання" (handshake), складається з 3 кроків.

1. Клієнт, який має намір встановити з'єднання, посилає серверу сегмент з номером послідовності і прапором SYN.

  • Сервер отримує сегмент, запам'ятовує номер послідовності і намагається створити сокет (буфери і керуючі структури пам'яті) для обслуговування нового клієнта.
    • У разі успіху сервер посилає клієнтові сегмент з номером послідовності і прапорами SYN і ACK, і переходить в стан SYN-RECEIVED.
    • У разі невдачі сервер посилає клієнтові сегмент з прапором RST.

2. Якщо клієнт отримує сегмент з прапором SYN, то він запам'ятовує номер послідовності і посилає сегмент з прапором ACK.

  • Якщо він одночасно отримує і прапор ACK (що зазвичай і відбувається), то він переходить в стан ESTABLISHED.
  • Якщо клієнт отримує сегмент з прапором RST, то він припиняє спроби з'єднатися.
  • Якщо клієнт не отримує відповіді протягом 10 секунд, то він повторює процес з'єднання заново.

3. Якщо сервер в стані SYN-RECEIVED отримує сегмент з прапором ACK, то він переходить в стан ESTABLISHED.

  • В іншому випадку після тайм-ауту він закриває сокет і переходить в стан CLOSED.

Процес називається "трьохетапним узгодженням" ("three way handshake"), так як незважаючи на те що можливий процес встановлення з'єднання з використанням 4 сегментів (SYN в сторону сервера, ACK в сторону клієнта, SYN в сторону клієнта, ACK в сторону сервера), на практиці для економії часу використовується 3 сегмента.

Приклад базового 3-етапного узгодження:

 TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT ->   -> SYN-RECEIVED 3. ESTABLISHED <-    <- SYN-RECEIVED 4. ESTABLISHED ->    -> ESTABLISHED 5. ESTABLISHED <-     <- ESTABLISHED 

У рядку 2 TCP A починає передачу сегмента SYN, що говорить про використання номерів послідовності, починаючи з 100. У рядку 3 TCP B передає SYN і підтвердження для прийнятого SYN на адресу TCP A. Треба відзначити, що поле підтвердження показує очікування TCP B прийому номера послідовності 101, підтверджуючого SYN з номером 100.

У рядку 4 TCP A відповідає порожнім сегментом з підтвердженням ACK для сегмента SYN від TCP B; у рядку 5 TCP B передає деякі дані. Відзначимо, що номер послідовності сегмента в рядку 5 співпадає з номером у рядку 4, оскільки ACK не займає простору номерів послідовності (якщо це зробити, доведеться підтверджувати підтвердження - ACK для ACK!).

Існують експериментальні розширення протоколу TCP, що скорочують кількість пакетів при встановленні з'єднання, наприклад TCP Fast Open [Ru] . Раніше також існувало розширення T / TCP.


2.3. Передача даних

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

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

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


2.4. Завершення з'єднання

Завершення з'єднання можна розглянути в три етапи:

  1. Посилка сервера від клієнта прапорів FIN і ACK на завершення з'єднання.
  2. Сервер посилає клієнтові прапори відповіді ACK, FIN, що з'єднання закрито.
  3. Після отримання цих прапорів клієнт закриває з'єднання і на підтвердження відправляє серверу ACK, що з'єднання закрито.

2.5. Відомі проблеми

2.5.1. Максимальний розмір сегмента

TCP вимагає явної вказівки максимального розміру сегмента ( MSS) в разі, якщо віртуальне з'єднання здійснюється через сегмент мережі, де максимальний розмір блоку ( MTU) менше, ніж стандартний MTU Ethernet (1500 байт).

У протоколах тунелювання, таких як GRE, IPIP, а також PPPoE MTU тунелю менше ніж стандартний, тому сегмент TCP максимального розміру має довжину пакета більше, ніж MTU. Оскільки фрагментація в переважній більшості випадків заборонена, то такі пакети відкидаються.

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

Для вирішення цієї проблеми на маршрутизаторах застосовуються правила Firewall-а, добавляющие параметр MSS у всі пакети, які ініціюють з'єднання, щоб відправник використав сегменти допустимого розміру.

MSS може також управлятися параметрами операційної системи.


2.5.2. Виявлення помилок при передачі даних

Хоча протокол здійснює перевірку контрольної суми по кожному сегменту, використовуваний алгоритм вважається слабким [1]. Так в 2008 році не виявлена ​​мережевими засобами помилка при передачі одного біта, призвела до зупинки серверів системи Amazon Web Services [2].

У загальному випадку розподіленим мережевим додаткам рекомендується використовувати додаткові програмні засоби для гарантування цілісності переданої інформації [3].


2.5.3. Атаки на протокол

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

3. Реалізація

3.1. Звільнення від розрахунку контрольної суми

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

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