9 СТЕК ПРОТОКОЛІВ TCP/IP

Всі протоколи стека TCP/IP, мережеві служби і принципи їх реалізації описуються в документах RFC (Request For Comment – пропозиція для обговорення); надалі наведемо номери RFC, що описують той або інший протокол.

9.1 Система адресації в TCP/IP

Мережі TCP/IP використовують три різновиди адрес: локальні (MAC-адреси – у разі локальної мережі, мережеві (IP-адреси) і символьними імена (доменні імена, DNS-імена).

Локальні адреси використовуються для доправляння пакетів в межах підмережі, мережеві адреси – для маршрутизації пакетів між підмережами, а символьні імена – для простішого запам'ятовування імен вузлів.

Мережевий рівень стека TCP/IP передає пакети між мережами, спираючись на IP-адреси (RFC 990 і RFC 997). IP-адреса (четвертої версії) складається з 32 біт (4 байт). Як правило, IP-адресу записують як чотири десяткові числа (значення окремих байтів), розділені крапками, наприклад: 123.45.67.89. Адреса складається з двох частин: номера підмережі і номера вузла, причому номер вузла не залежить від його MAC-адреси (або іншої локальної адреси).

Розподіл номерів підмереж для Internet здійснюється централізовано ( ICANN), а для внутрішніх підмереж, не пов'язаних безпосередньо з Internet, може призначатися адміністратором мережі.

Всі IP-адреси розділені на 5 класів (від A до E), які задають різні співвідношення між кількістю підмереж і кількістю вузлів у них (рисунок 9.1).

Деякі IP-адреси інтерпретуються спеціальним чином:

-         адреса, всі біти якої рівні нулю, визначає адресу того вузла, який видав цей пакет;

-         адреса, в полі номера мережі якої  тільки нулі, вважається такою, що відноситься до тієї ж мережі, що і вузол, що видав цей пакет;

-         адреса, всі біти якої рівні одиниці, означає, що даний пакет повинні отримати всі вузли підмережі, до якої відноситься вузол, що видав цей пакет (обмежене широкомовне повідомлення – limited broadcast);

-         адреса, в якій всі біти поля номера вузла рівні одиниці, а поле номера мережі задає певну мережу (не всі нулі і не всі одиниці), то такий пакет повинен розсилатися всім вузлам вказаної підмережі (широкомовне повідомлення – broadcast).

Рисунок 9.1 – Класи IP-адрес

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

N вузлів = 2ⁿ -2, де n – кількість біт у полі номера вузла, а кількість підмереж – співвідношенням: N підмереж = 2^m -2, де m – кількість біт у полі номера підмережі.

Наприклад, кожна з 16382 (2¹⁴-2) підмереж класу B (14 біт - номер підмережі, 16 біт - номер вузла) максимально може включати 65534 (2¹⁶-2) вузли з номерами від x.x.0.1 до x.x.255.254.

Крім того, виділена група адрес, перший байт яких дорівнює 127. Ці адреси використовують для передачі даних між процесами на одному комп'ютері або для тестування. Дані, відправлені за такою адресою, розглядаються, як тільки що прийняті з мережі, внаслідок чого утворюється як би “петля” (loopback). Зазвичай використовується адреса 127.0.0.1, але для цих цілей можна використовувати будь-яку адресу вигляду 127.x.x.x.

Безкласова адресація CIDR. Схема адресації, пропонована IP-протоколом, приводить до неефективного використання адресного простору, який в сучасному розумінні не такий вже і великий, і браку адрес класу В. У документі RFC 1519 визначена безкласова міждоменна маршрутизація (Classless InterDomain Routing, CIDR). Вона працює таким чином: мережам, які спочатку мали намір використовувати адреси класу В (але не використали б всі ці адреси), адреси призначаються у вигляді блоків адрес класу С. В CIDR більше не робиться відмінностей між адресами класів А, В і С – звідси і назва – безкласова. CIDR дозволяє не обмежувати більше адресний сегмент типами /8/16 або /24.

Маршрутизатори поводяться з цими адресами майже так само, як при маршрутизації підмереж – з кожним набором безкласових адрес вони пов'язують так звану адресну маску (address mask), за допомогою якої кожну вхідну пакетну адресу отримує базова адреса (base address) і, таким чином, визначає маршрутизатор, пов'язаний з відповідною мережею, причому ця маска тепер має змінний розмір.

З безкласовою маршрутизацією зв'язують додаткову концепцію, що полягає в тому, що конкретні адресні діапазони зв'язуються з географічними областями; наприклад, адреси діапазону 194.0.0.0– 195.255.255.255 виділяються для Європи, а адреси діапазону 198.0.0.0–199.255.255.255  для Північної Америки. Це полегшує маршрутизацію між мережами. Використовується так звана "агрегація маршрутів", за допомогою якої для опису або представлення множинних мереж можна використовувати окремий мережевий префікс.

Розглянемо випадок, коли організації був призначений діапазон IP-адрес від  130.159.80.00 до 130.159.95.255, який вона відповідним чином розподілятиме між декількома відділами. Це адреси : 130.159.88.0/21, 130.159.80.0/22, 130.159.84.0/23 та 130.159.86.0/23.

Мережі відомо, що маршрутизатор може приймати будь-який пакет, в якому перші 20 біт адреси є 10000010100111110101, це еквівалентно  ІР-адресі 130.159.80.0/20. У наведеному прикладі для чотирьох відділів організації потрібно відповідно 510, 510, 1022 і 254 хост-вузла, тому для них можна призначити адресний простір 130.159.80.0/20.

Якби одна з організацій повинна була змінити свого Internet-провайдера (ISP),  то CIDR-маршрутизація дозволила б зберегти призначений нею діапазон адрес. Новий ISP використовуватиме як свій діапазон IP-адрес, так і старий діапазон адрес свого нового клієнта. Розглянемо, наприклад, користувача з діапазоном адрес 130.84.0/23. Первинний провайдер використовував свій діапазон адрес 130.159.80.0/20, тоді як новий ISP використовуватиме діапазон  130.159.84.0/23. Проміжні маршрутизатори використовуватимуть щонайдовший префікс, який зможе розпізнавати, що пакети діапазону 130.159.84.0/23 слід відправляти новому ISP, а не старому (з діапазоном 130.159.80.0/20), оскільки діапазон /23 має пріоритет над діапазоном /20.

9.2 Протокол IP

IP (Internet Protocol, протокол міжмережної взаємодії) - RFC 791. Основна функція – передача пакетів між вузлами, що належать до різних підмереж, через проміжні підмережі. Кожен пакет (дейтаграма – datagram, в термінології TCP/IP) опрацьовується незалежно від інших. Доставка дейтаграм не гарантується. Можливі втрати дейтаграм, доставка з помилками, дублювання і порушення порядку проходження. Друга функція протоколу IP – виконання фрагментації пакетів при передачі їх між мережами з різним максимально допустимим розміром поля даних кадру (MTU). 

Істотна властивість протоколу IP полягає в нетрадиційному порядку передачі бітів: байт передається, починаючи із старшого біта. Крім того, нумерація бітів в байті також починається із старшого: самий старший біт має номер 0, самий молодший – номер 7.

Дейтаграма (IP-пакет) складається із заголовку та поля даних.

Формат заголовка приведений на рисунку  9.2, при чому 1 блок дорівнює 4 байтам.

Номер версії (Version) [4 біта] – вказує використаний формат заголовка. У наш час основна версія має номер 4.

Довжина заголовка (Internet Header Length) [4 біта] – довжина заголовка в 32-бітних словах, мінімальне допустиме значення – 5 (відповідає довжині заголовка в 20 байт). Максимальна довжина заголовка – 60 байт.

Тип сервісу (Type of Service) [8 біт] – вказує на бажані параметри якості обслуговування. Формат байта Типу сервісу приведений на рисунку 9.3.

Рисунок 9.2 – Формат заголовку IP-пакета

Загальна  довжина (Total Length) [16 біт] – довжина дейтаграми (заголовка і даних) в байтах. Хоча розмір поля дозволяє створювати дейтаграми завдовжки до 65535 байт, стандарт вимагає, щоб будь-який вузол міг приймати, щонайменше, 576-байтні дейтаграми, а відправляти дейтаграми більшої довжини тільки, будучи упевненим, що одержувач може їх прийняти.

Ідентифікатор “великого пакету” (Identification) [16 біт] – значення, однакове для всіх дейтаграм, що містять фрагменти одного пакету (“великого пакету”).

Прапорці (Flags) [3 біта] – прапори, що керують фрагментацією:

-         Нульовий біт – зарезервований, завжди дорівнює 0;

-         Перший біт (DF, Don’t Fragment) –“0” = можна фрагментувати, “1” = не можна фрагментувати;

-         Другий біт (MF, More Fragments) – “0” = останній фрагмент,  “1” =  ще будуть фрагменти.

Зміщення фрагмента (Fragment Offset) [13 біт] – указує на місце в “великому пакеті”, з якого починаються дані поточної дейтаграми. Вимірюється в 64-бітових (8-байтних) словах. Наприклад, зміщення фрагмента рівне 2, означає, що дані поточної дейтаграми повинні знаходитися в “великому пакеті”, починаючи з 16-го байта. Перший фрагмент має нульове зміщення.

Час життя (Time to Live, TTL) [8 біт] – максимальний час, який дейтаграма може знаходитися в мережі. Кожен маршрутизатор повинен зменшувати це значення на одиницю, і відкидати дейтаграми із значенням TTL = 0  (повідомивши про це відправника). Наявність цього поля забезпечує знищення дейтаграм, що “зациклилися” або “заблукали”. Поле TTL також дозволяє обмежити дальність розповсюдження дейтаграми (це зручно, наприклад, при одночасній передачі безлічі абонентів) і є основою для роботи утіліти traceroute.

Протокол (Protocol) [8 біт] – указує, дані якого протоколу верхнього рівня передаються в дейтаграмі. Можливі значення цього поля стандартизовано (RFC “Assigned Numbers”), наведемо деякі з них: 1 – ICMP, 4 – IP, 6 – TCP, 17 – UDP, 89 – OSPF.

Контрольна сума заголовка (Header Checksum) [16 біт] – контрольна сума всіх полів заголовка, що обчислюється як доповнення суми всіх 16-бітових слів заголовка (з нульовими бітами в полі контрольної суми). Оскільки деякі поля заголовка (наприклад, час життя) змінюються при передачі дейтаграми через мережу, контрольна сума перераховується кожним маршрутизатором. Якщо отримана дейтаграма з невірною контрольною сумою, така дейтаграма відкидається.

Адреси відправника (Source Address) [32 біта] – IP-адреса відправника дейтаграми.

Адреси отримувача (Destination Address) [32 біта] – IP-адреса одержувача дейтаграми.

Опції (Options) [змінна довжина] – необов'язкове поле, може містити дані про безпеку, маршрут дейтаграм (при маршрутизації від джерела) і т.д. Опції в даний час практично не використовуються.

Рисунок 9.3 – Структура поля “ Тип сервісу ” заголовка IP-пакета

Поле Пріоритету (Precedence) для звичайних пакетів дорівнює 0, решту значень (від 1 до 7) використовують для службових цілей – чим більше значення, тим вище пріоритет.

Поля D (Delay – затримка), T (Throughput – пропускна здатність) і R (Reliability – надійність) використовуються для вказівки найбільш важливого для передавального вузла параметра якості. Вибір відбувається між малою затримкою, великою пропускною спроможністю і високою надійністю. Відповідний біт (біти) встановлюється в 1, останні – в 0. Як правило, поліпшення одного з параметрів пов'язано з погіршенням решти.

Фрагментація IP-пакетів. На шляху пакету від відправника до одержувача можуть зустрічатися локальні і глобальні мережі різних типів з різними допустимими розмірами полів даних кадрів канального рівня (Maximum Transfer Unit – MTU). Так, мережі Ethernet можуть передавати кадри, що несуть до 1500 байт даних, для мереж X.25 характерний розмір поля даних кадру в 128 байт, мережі FDDI можуть передавати кадри розміром в 4500 байт, в інших мережах діють свої обмеження. Протокол IP вміє передавати дейтаграми, довжина яких більше MTU проміжної мережі, за рахунок фрагментації – розбиття “великого пакету” на деяку кількість частин (фрагментів), розмір кожною з яких задовольняє проміжну мережу. Після того, як всі фрагменти будуть передані через проміжну мережу, вони будуть зібрані на вузлі-одержувачі модулем протоколу IP назад в “великий пакет”. Відзначимо, що збирання пакету з фрагментів здійснює тільки одержувач, а не який-небудь з проміжних маршрутизаторів. Маршрутизатори можуть тільки фрагментувати пакети, але не збирати їх. Це пов'язано з тим, що різні фрагменти одного пакету не обов'язково проходитимуть через одні і ті ж маршрутизатори.

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

При діленні даних пакету, розмір всіх фрагментів, окрім останнього, повинен бути кратним 8 байтам. Це дозволяє відвести менше місця в заголовку під поле Зміщення фрагмента. Якщо пакет відправляється без фрагментації, поле Зміщення фрагмента – заповнюється нульовими бітами.

Якщо перший біт поля Прапори (Don’t fragment) дорівнює одиниці, то фрагментація пакету заборонена. Якщо цей пакет повинен бути переданий через мережу з недостатнім MTU, то маршрутизатор вимушений буде його відкинути (і повідомити про це відправникові за допомогою протоколу ICMP). Цей прапор використовується у випадках, коли відправникові відомо, що у одержувача немає достатньо ресурсів по відновленню пакетів з фрагментів.

9.3 Протокол ARP

ARP (Address Resolution Protocol, протокол дозволу адрес) - RFC 826. При передачі пакетів усередині локальних мереж протоколи канального рівня користуються локальними адресами вузлів, відправник же може знати тільки IP-адресу одержувача. Для того, щоб визначити, яка локальна адреса (наприклад, MAC-адрес в мережі Ethernet) відповідає даній IP-адресі, застосовується протокол ARP. Цей протокол розроблено спеціально для Ethernet-мереж, але він може працювати в будь-яких мережах, які підтримують широкомовну передачу.

Всі вузли, що підтримують протокол ARP, ведуть ARP-таблицю, що складається із записів <IP-адреса; MAC-адреса>.

Коли вузлу потрібно визначити локальну адресу іншого вузла, його ARP-модуль спочатку шукає його в ARP-таблиці, і, якщо потрібна адреса не знайдена, то передає широкомовне повідомлення: “Чи знає хто-небудь локальну адресу для IP 123.45.67.89? Я 123.45.67.90, моя MAC-адреса 10:20:30:40:50:60.”. Вузол, якого розшукують, відповідає (не широкомовно, а прямою передачею): “Так, 123.45.67.89 – це я. Моя MAC-адреса 10:20:30:40:50:61”. При цьому він зберігає пару <IP-адреса; MAC-адреса> вузла, що шукав його, в своїй ARP-таблиці. Нарешті, перший вузол, отримавши відповідь, заносить його в свою ARP-таблицю.

Як правило, записи в ARP-таблиці мають обмежений час життя (стандарт описує можливі схеми обмеження часу життя і тайм-аутів). Формат повідомлення ARP дозволяє використовувати цей протокол в мережах з різним розміром адрес (до 256 біт).

Повідомлення ARP не містять IP-заголовка і безпосередньо розміщуються в полі даних кадру канального рівня.

9.4 Протокол ICMP

ICMP (Internet Control Message Protocol, протокол керуючих повідомлень Інтернету) - RFC 792, RFC 1256, виконує перенесення ІСМР-пакета за допомогою IP-пакета. Він використовується для повідомлень про помилки або позаштатні ситуації, що передаються вузлу-відправнику дейтаграми вузлом-отримувачем або проміжним маршрутизатором. Повідомлення ICMP інкапсулюються у поле даних IP-дейтаграми.

Головні функції ІСМР:

-         передавання відповіді на пакет або луна-відповіді;

-         контроль часу наявності дейтаграм у системі;

-         переадресування пакету;

-         надавання повідомлень про недосяжність адресата або некоректність параметрів;

-         формування та пересилання часових позначок

Структура ІСМР-пакета показана на рисунку 9.4.

Рисунок  9.4 – Структура ІСМР-пакету

Повідомлення ICMP завжди починаються з трьох полів:

Тип (Type) [8 біт] – тип повідомлення;

Код (Code) [8 біт] – причина проблем з доставкою дейтаграми. Для решти типів в полі Код записується нульове значення. Приклади різних значень цих полів наведені в таблиці 9.1.

Таблиця 9.1 – Повідомлення ІСМР (основні)

Контрольна сума (Checksum) [16 біт] – контрольна сума ICMP-повідомлення (починаючи з поля Тип), що обчислюється, як  і в протоколі IP.

Поля Ідентифікатор та Порядковій номер потрібні для зіставлення запитів та відгуків.

Розглянемо деякі приклади використання ІСМР-пакета.

1. Під час виконання процедури Ping луну-запит з часовою позначкою надсилають адресатові. Якщо адресат активний, він приймає IP-пакет, змінює адреси відправника та одержувача місцями та надсилає пакет назад.
2. Якщо маршрутизатор не може доставити дейтаграму за місцем призначення, він надсилає відправнику ІСМР-повідомлення Адресат недосяжний.
3. Якщо приймач не в стані прийняти потік вхідних повідомлень, він надсилає відправнику спеціальний запит (quench-запит) з вимогою зменшити інформаційний потік.
4. Якщо маршрутизатор виявляє, що комп'ютер використовує неоптимальний маршрут, він надсилає ІСМР-повідомлення з його корекцією. Крім того, маршрутизатори мережі періодично (через 500-600 с) циркулярно повідомляють про свої маршрути, що дає змогу іншим маршрутизаторам скоректувати таблиці.
5. Для системних завдань синхронізації таймерів використовують ІСМР-повідомлення Запит часової позначки.

9.5  Утиліти для тестування мереж TCP/IP

Утиліта Ping дозволяє перевірити існування вказаного вузла й зміряти час передачі до нього одного пакету (можна задавати різні розміри пакету для дослідження проміжних мереж). Ця утиліта виконує передачу ICMP-повідомлення типу 8 (Echo request), на яке одержувач повинен відповісти ICMP- повідомленням типу 0 (Echo reply).

Утиліта Traceroute показує послідовність вузлів, через які проходить пакет на шляху до одержувача. Реалізовано це таким чином: послідовно відправляються пакети із зростаючим значенням в полі TTL: 1, 2, 3 і так далі. Той маршрутизатор, який зменшить TTL до нуля, зобов'язаний буде відправити ICMP-повідомлення типу 11 (Time exceeded). В результаті будуть отримані такі ICMP-повідомлення  по черзі від всіх маршрутизаторів на шляху пакету до одержувача.

Утиліта netstate в системах Unix, Linux Windows допомагає отримати статистику по протоколах ТСР/ІР, які працюють на комп’ютері. Команда route дозволяє переглянути або змінювати таблицю маршрутизації, встановлену на комп’ютері.

Утиліта tcpdump (WinDump) перехоплює інформацію заголовків пакетів під час передавання мережею і дає оцінку ІР-пакетам для діагностики різних мережевих проблем. Залежно від встановлених в мережі служб ТСР/ІР можна швидко ознайомитися з типом очікуваного трафіка, і переглянути надзвичайні ситуації за умов виникнення проблем.

9.6 Порти

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

Порти нумеруються позитивними цілими 16-бітовими числами. Наприклад,  80 – це порт www-сервера, а 53 – порт системи доменних імен. Різні протоколи транспортного рівня нумерують свої порти незалежно, тобто, наприклад, порт 20 протоколу TCP і порт 20 протоколу UDP абсолютно не зв'язані один з одним.

Деякі номери портів задані стандартами. Ці номери виділяються організацією IANA (Internet Assigned Numbers Authority). В даний час під стандартні (призначені, добре відомі) порти відведений діапазон від 0 до 1023 (RFC 1700, RFC 3232). Решта портів може вільно використовуватися прикладними процесами. Порти в діапазоні від 1024 до 5000 називаються тимчасовими (ephemeral). Призначення цих портів не стандартизовано, але IANA підтримує інформацію про їх використання.

9.7  Протоколи транспортного рівня

9.7.1 Протокол UDP

UDP (User Datagram Protocol, протокол призначених для користувача дейтаграм) , RFC 768, надає прикладним процесам прості послуги транспортного рівня.

Дві основні функції UDP:  розподіл дейтаграм між процесами (на підставі номерів портів) і контроль передачі призначених для користувача даних (не тільки заголовка, як в протоколі IP). Як і IP, UDP не гарантує доставку і не підтримує встановлення  з'єднань.

Повідомлення протоколу UDP називається призначеною для користувача дейтаграмою (User datagram) і складається із заголовка і призначених для користувача даних. Заголовок (рисунок 9.5) складається з чотирьох 16-бітових полів.

Відразу за заголовком йдуть призначені для користувача дані. Нульове значення в полі “Контрольна сума” означає, що контрольна сума не обчислювалася. Для розрахунку контрольної суми на початок дейтаграми приписується псевдозаголовок, що складається з п'яти полів: IP-адреса відправника, IP-адреса одержувача, Нулі (8 біт), Протокол (8 біт), Довжина дейтаграми (16 біт).

Рисунок 9.5 – Структура UDP-пакета

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

9.7.2 Протокол TCP

Протокол TCP (Transmission Control Protocol, протокол управління передачею), RFC 793. Він забезпечує передавання сегментів (пакетів, що передаються протоколом TCP) у вигляді байтних потоків з налагодженням сполучення. TCP використовують там, де потрібне гарантоване передавання повідомлення. Надійність передачі забезпечена використанням сервісу передавання дейтаграм протоколу IP за допомогою нумерації байтів потоку та підтверджень приймання. Усі байти вихідного потоку даних нумерують (цей номер зветься номером у послідовності (sequence number)), та з кожним сегментом передається номер у послідовності його першого байта.  Для перевірки цілісності пакетів використовують контрольні суми, для відстежування процесу передавання - механізм вікон. Протокол TCP TCP використовують сервіси ftp, telnet та ін.

У системах, орієнтованих на з'єднання, пара комбінацій IP-адрес та номерів портів однозначно задає канал зв'язку між двома комп'ютерами, та називається сокетом (Socket).

Взаємодія TCP з протоколом вищого рівня відбувається байт за байтом (потокова). На рівні TCP байти формуються у сегменти та передаються на рівень IP. TCP оптимізує розмір сегмента, що є змінним. Для контролю за часом, протягом якого повинно надійти підтвердження про одержання пакета, призначено таймер. Якщо за визначений час підтвердження не надійшло, то передавання повторюється. Сегмент має максимальну тривалість існування (Maximum Segment Lifetime (MSL). З перевищенням цього часу його буде знищено.

Сегмент складається з заголовку та поля даних. Формат заголовку сегмента TCP наведено на рисунку 9.6.

Рисунок  9.6 – Формат сегменту TCP

Поля сегмента:

Порт відправника (Source port) та порт одержувача (Destination port) [по 16 біт].  

Код позиції в повідомленні (Sequence Number) [32 біта] визначає порядковий номер першого байта даних користувача. Якщо встановлений керуючий біт SYN, тоді в цьому полі вміщується початковий номер в послідовності (Initial Sequence Number, ISN), та перший байт даних сегмента має номер в потоці ISN+1.

Номер наступного байта (Acknowledgement number) [32 біта] – номер байта в потоці, на який чекає відправник даного сегменту. Втім має бути встановлений керуючий біт ACK.

Нlеп (довжина) - зміщення даних (Data offset) [4 біта] – кількість 32-бітових слів у заголовку TCP-сегмента. Мінімальне значення поля – 5 (20-ти байтний заголовок).

Резерв (Reserved) [6 біт] – мають бути заповнені нулями

Значення  бітів з поля Ознаки: URG - ознака важливої інформації; ACK – звертати увагу на поле "Номер підтвердження", PSH - якнайшвидше передати дані програмі застосування; RST  – перервати зв’язок, SYN- ознака синхронізації номерів сегментів (використовують для налагодження сполучення); FIN- відправник закінчив надсилання пакетів.

Розмір вікна (Window) [16 біт] - кількість байтів, яку готовий прийняти приймач,  починаючи з вказаного в полі "Номер підтвердження";

Контрольна сума (Checksum) [16 біт] – контрольна сума усього сегменту (заголовку та даних), обчислена за алгоритмом протоколу IP. Як і в UDP, перед обчисленням контрольної суми до сегменту дописують псевдозаголовок (тої самої структури, що і в UDP).

Вказівник важливої інформації  (Urgent Pointer) [16 біт] – містить номер першого байта повідомлення, що потребує негайного реагування. Це поле має сенс тоді, коли ознака URG = 1. 

Поле опцій (Options)  - це список полів змінної довжини. Кожна опція записується у форматі " вид – довжина - зміст". Деякі опції – масштаб вікна, часова позначка.

Заповнювач (Padding) – поле для доведення розміру заголовка до цілого числа 32-бітних слів.

Поле даних необов'язкове.

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

Кожного разу при встановленні з’єднання модуль TCP створює структуру даних – Блок управління передаванням (Transmission Control Block, TCB), який зберігає постійну інформацію про з’єднання (IP-адреси, номера портів, вказівники на вхідний та вихідний буфери, черга повторного відправлення і т. ін.) та поточні значення змінних, які описують поточний стан з’єднання.

9.8 IP-протокол версії 6 (IPv6)

IPv6 - наступне покоління IP-протоколів. Причиною його розробки став відчутний (із зростанням числа хост-вузлів і мереж) брак адресного простору в протоколі IPv4. Динамічний розподіл адрес Internet-провайдерами і безкласова адресація фактично продовжили життя адресного простору IPv4. Нові розробки в технології мобільної телефонії і ASDL, які завжди взаємозв'язані, вимагають додаткових IP-адрес. Хоча існує обхідний шлях, що дозволяє розділяти (спільно використовувати) IP-адреси мережі і перетворювати їх за допомогою шлюзів в менший динамічний діапазон IP-адрес і портів, видимих із зовнішньої мережі, адресний простір IPv4 скоро закінчиться.

У IPv6 адресний розмір збільшений з 32 до 128 розрядів. При таких розмірах можна призначити IP-адресу не тільки кожному користувачеві, терміналу або навіть електровимикачу. З'являється також можливість призначати декілька адрес одному пристрою, виділяючи додаткові адреси різним його компонентам або службам.

Як і у ІР v4, у версії 6 визначено індивідуальні (unicast), групові (multicast) та широкомовні (broadcast) адреси, а також з'явилася нечітка адреса (anycast). Пакет з нечіткою адресою пе