TCP

Матеріал з Вікіпедії — вільної енциклопедії.
(Перенаправлено з SYN)
Перейти до навігації Перейти до пошуку
Модель TCP/IP (RFC 1122)
Прикладний рівень
Транспортний рівень
Мережевий рівень
Канальний рівень
Цей шаблон:

Transmission Control Protocol, TCP (укр. Протокол управління передачею) — разом із протоколом IP є стрижневим протоколом Інтернету, який дав назву моделі TCP/IP. Протокол призначений для керування передаванням даних у комп'ютерних мережах, працює на транспортному рівні моделі OSI.[1]

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

Інкапсуляція TCP в мережевій моделі OSI

TCP отримує потоки даних від протоколів верхніх рівнів OSI-моделі, початковим джерелом яких є протоколи прикладного рівня, такі як HTTP, FTP та інші. Кожний протокол верхнього рівня має свій визначений TCP-порт.

TCP розбиває конкретний потік даних на порції, та додає до кожної з них заголовок з номером послідовності. Отримані таким чином порції даних традиційно називаються TCP-сегментами.[3] Далі кожний сегмент інкапсулюється в IP-пакет і передається через IP-протокол до хоста-отримувача.

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

У свою чергу TCP-сегменти деінкапсулюються з IP-пакетів, розміщуються в правильному порядку та з них вилучаються TCP-заголовки. Отриманий таким чином потік даних передається до того протоколу верхнього рівня, з якого первісно надійшли дані на стороні хоста-відправника.

Історія створення[ред. | ред. код]

Піонером у розробці сучасних комп'ютерних мереж вважається Агентство передових оборонних дослідницьких проектів США, (DARPA, Defense Advanced Research Projects Agency) зі своєю розробкою - мережею ARPANET запущеною у 1969 році.[4]

Появою протоколу вважають 1974 рік, коли інститут інженерів з електротехніки та електроніки опублікував роботу «Протокол для пакетної мережевої комунікації (A Protocol for Packet Network Intercommunication)», авторами якої були Вінтон Серф та Роберт Елліот Кан.[5] У цій праці TCP було абревіатурою від Transmission Control Program (програма керування передаванням).

TCP-сегмент[ред. | ред. код]

Блок даних (PDU[en], Protocol data unit) TCP називається сегментом,[6] хоча часто також використовують слово пакет, але таке вживання може вносити плутанину з IP-пакетом.

TCP-сегмент складається із TCP-заголовка і поля Дані (Data), яке називають сегментом даних або пейлодом[7] або SDU[en][8].

Стандартний розмір TCP-заголовка — 20 байт, але з використанням опцій розмір може зростати до 60 байт. Як правило, опціями хости обмінюються на етапі встановлення з'єднання.

Розмір сегменту даних (поля даних) визначається опцією MSS (Максимальний розмір сегменту, Maximum segment size) на етапі встановлення з'єднання. Якщо обміну опціями не відбулося, то розмір сегменту даних встановлюється за замовчуванням 536 байт.[9] Розмір сегменту даних тісно пов'язаний з MTU (Максимальний розмір блоку пересилання). Фактично MSS дорівнює MTU з відніманням розміру IP- і TCP-заголовків. Наприклад у сучасній мережі Ethernet MTU дорівнює 1500 байт; тоді оптимальний розмір MSS буде 1460 байтів (1500 мінус 20 байт заголовка IP і 20 байт заголовка TCP).

Формат TCP сегменту
Октет (Байт) 0 1 2 3
Біт  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 0 Порт джерела (Source port) Порт призначення (Destination port)
4 32 Номер послідовності (Sequence number)
8 64 Номер підтвердження (Acknowledgment number)
12 96 Зміщення даних (Data offset) Зарезервовано (Reserved)
0 0 0		 N
S		 C
W
R		 E
C
E		 U
R
G		 A
C
K		 P
S
H		 R
S
T		 S
Y
N		 F
I
N		 Розмір вікна (Window Size)
16 128 Контрольна сума (Checksum) Показник важливості (Urgent pointer)
20
…
56 		160
...
448 		Опції (Options) необов'язкове, розмір залежно від значення поля «Зміщення даних»
20+
… 		160+
… 		Дані (Data)

Поля заголовка[ред. | ред. код]

Порт джерела[ред. | ред. код]

  • 0 — 15 біти. Порт джерела (Source port) ідентифікує номер TCP-порту, з якого відправляється сегмент.

Порт призначення[ред. | ред. код]

  • 16 — 31 біти. Порт призначення (Destination port) ідентифікує номер TCP-порту, на який відправляється сегмент.

Див. також список номерів TCP- та UDP-портів.

Номер послідовності[ред. | ред. код]

  • 32 — 63 біти. Номер послідовності (Sequence number) є числом, що відображає номер першого байту в сегменті надісланих даних від хоста-відправника до хоста-отримувача. Це число є акумулювальним, тобто поточний номер послідовності є сумою номера послідовності попереднього сегменту і кількості даних (в байтах) відправлених у ньому. Використовується для відстежування кількості та правильної послідовності отриманих сегментів даних.[10]

Номер підтвердження[ред. | ред. код]

  • 64 — 95 біти. Номер підтвердження (Acknowledgment number) фактично є запитом від хоста отримувача на надіслання нового сегменту даних починаючи зі вказаного номера. З іншого боку, коли хост відправник отримує це повідомлення, він переконується, що всі сегменти даних з номерами послідовності меншими за номер підтвердження були успішно прийняті отримувачем.

Зміщення даних[ред. | ред. код]

  • 96 — 99 біти. Зміщення даних[2] (Data offset) 4-бітний номер, який визначає розмір TCP-заголовка в 32-бітових словах. Мінімальний розмір становить 5 (0101) слів, а максимальний — 15 (1111), що є відповідно 20 і 60 байт. Фактично визначає розмір поля Опції (Options) від 0 до 40 байт.

Зарезервовано[ред. | ред. код]

  • 100—102 біти, зарезервовані для майбутнього використання і повинні містити нулі (000).

Прапорці (керуючі біти)[ред. | ред. код]

Це поле містить бітові прапорці, з яких шість основних описані в RFC 793[11] з 106 по 111 біт, два прапорці додані до заголовка в RFC 3168, розміщуються в 104 і 105 бітах заголовка, в 103 біті знаходиться експериментальний прапорець згідно з RFC 3540. Прапорці вважається встановленими, якщо їх бітове значення є 1.

  • 103 NS — Одноразова сума (Nonce Sum), використовується з метою покращення роботи механізму явного повідомлення про перевантаження (Explicit Congestion Notification, ECN).
  • 104 CWR — Вікно перевантаження зменшено (Congestion Window Reduced), прапорець встановлюється, щоб показати що TCP-сегмент був отриманий зі встановленим полем ECE, іншими словами це є підтвердженням отримання сегменту даних з прапорцем ECE від хоста партнера.
  • 105 ECE — ECN-Ехо (ECN-Echo), поле показує, що відправник підтримує ECN.

Основні:

  • 106 URG — Важливість (Urgent), вказує, що TCP-сегмент містить важливі дані. Коли до хоста-отримувача надходить сегмент зі встановленим прапорцем URG, TCP відправляє важливі дані з цього сегменту, які знаходяться завдяки полю покажчик важливості до відповідного протоколу верхнього рівня минаючи чергу і без перевірки успішності надходження попередніх сегментів.[12]
  • 107 ACK — Підтвердження (Acknowledge) успішності отримання TCP-сегменту
  • 108 PSH — Просування (Push), також як і прапорець URG, вказує, на пріоритетність TCP-сегменту. Хост-відправник позачергово надсилає цей сегмент даних через IP-мережу. За аналогією з прапорцем URG, PSH інструктує хост-отримувач, що сегмент даних має бути негайно переданий до прикладного рівня (кінцевого споживача даних).
  • 109 RST — Обривання (Reset) вказує, хосту-отримувачу негайно скинути з'єднання без подальшої взаємодії. Така ситуація наступає у разі, якщо сервер (хост-відправник) не надає послуги визначеного сервісу. Наприклад клієнт (хост-отримувач) запросив у вебсерверa послуги у форматі протоколу HTTPS (TCP-порт 443), але вебсервер надає послуги лише у форматі HTTP (TCP-порт 80). Ця властивість TCP часто використовується хакерами для сканування портів мережі жертви.
  • 110 SYN — Синхронізація (Synchronize) використовується для встановлення з'єднання між хостами при так званому триходовому рукостисканні[en]
  • 111 FIN — Фініш (Finish) вказує на завершення з'єднання.

Розмір вікна[ред. | ред. код]

  • 112—127 біти. Розмір вікна (англ. Window Size) визначає кількість байтів даних, які відправник може надіслати до того, як отримає підтвердження (запит на новий сегмент) від хоста-отримувача[13] На практиці це означає, що хост-відправник може надсилати певну кількість сегментів даних без отримання підтвердження від хоста-отримувача. Розмір вікна TCP вираховує на основі максимальної пропускної здатності (англ. bandwidth) лінії зв'язку між хостами (фактично це є пропускна здатність відрізка шляху з її найгіршим значенням) та загальній затримці[en] (англ. latency) (часу потрібному на доставку сегмента) на всьому шляху.

Контрольна сума[ред. | ред. код]

Показник важливості[ред. | ред. код]

  • 144—159 біти. Покажчик важливості[2] (Urgent pointer). Поле береться до уваги тільки в разі встановленого прапорця URG, та містить значення зміщення відносно номера послідовності сегменту. Фактично це число вказує на позицію в TCP-сегменті де закінчуються важливі дані.[14] Тобто важливі дані знаходяться одразу після TCP-заголовка і закінчуються перед місцем на яке вказує покажчик важливості.

Опції[ред. | ред. код]

  • 160—479 біти. Опції (Options) необов'язкове поле, розмір якого визначається в залежності від значення поля зміщення даних та є кратним 8 (одному байту). Кожна опція в свою чергу складається з 3-х полів: Номер (kind)[15] — 1 байт, Довжина (length, вказує на загальний розмір опції в байтах) — 1 байт, Дані (data) в залежності від поля довжина. Опції використовується для обміну додаткових параметрів між хостами з метою покращення функціонування протоколу TCP. Частіше за все це поле включає наступні опції[16]:
  • MSS (Максимальний розмір сегменту, Maximum segment size), RFC 793, номер — 2, довжина — 4.[17] Опція максимальний розмір сегменту визначає максимальний розмір поля Дані в TCP-сегменті тобто кількість даних які можуть бути поміщені в один сегмент при їх передаванні між хостами.
  • Масштабування вікна (Window scale), RFC 7323, номер — 3, довжина — 3,[18] слугує для збільшення значення TCP-вікна, максимальне значення цієї опції є 14. Новий розмір TCP-вікна вираховується по формулі: розмір вікна * 2n, де n є значення опції масштабування вікна. Стандартний максимальний розмір вікна відображається 16-ти бітовим числом, тобто може мати максимальне значення — 65535 (64 Кб), використовуючи опцію масштабування вікна з максимально допустимим значенням 14, отримуємо 65535 * 214 = 65535 * 16384 = 1073725440 (1 Гб). Великі значення TCP-вікна використовуються коли на шляху пакетів із TCP-сегментами зустрічаються WAN-лінки зі значними максимальними пропускними здатностями (bandwidth) та великими затримками[en] (latency).
  • Вибіркові підтвердження (Selective Acknowledgments, SACK), RFC 2018, номер — 2, довжина — від 4 байт — верхня межа варіюється,[19] як правило містить у собі два 2-х байтних поля даних. Мета її введення є покращення ефективності роботи TCP, як відомо TCP для передавання сегментів даних використовує протокол IP, який є протоколом без встановлення з'єднання[en], тобто доправлення пакетів з TCP-сегментами не є гарантованим, допускається, що частина IP-пакетів може бути втрачена. В свою чергу TCP забезпечує надійне доправляння даних, що базується на механізмі надсилання номерів підтвердження (acknowledgment number). Якщо якийсь сегмент від відправника до отримувача не надійшов у встановлений час то ініціюється повторне передавання починаючи зі втраченого сегменту, навіть якщо TCP-сегменти з номерами послідовності більшими за номер втраченого сегменту були успішно отримані. Механізм вибіркового підтвердження дозволяє ретранслювати лише втрачені сегменти даних, чим суттєво покращує ефективність роботи TCP.
  • Мітки часу (Timestamps), RFC 7323, номер — 8, довжина — 10,[20] містить у собі два 4-х байтних поля Значення мітки часу (Timestamp Value) та Ехо-відповідь мітки часу (Timestamp Echo Reply).[21] Як правило хости обмінюються значеннями міток часу на етапі встановлення з'єднання. За допомогою міток часу TCP визначає скільки потрібно часу на доправлення сегментів між хостами. На основі цих значень встановлюються TCP-таймери відповідальні на стороні хоста-відправника за повторне передавання даних, якщо підтвердження отримання не надійшло у встановлений час, а у разі використання опції вибіркового підтвердження хост-отримувач самостійно ініціює запит на повторне пересилання конкретного сегменту даних.

Якщо деякий простір поля Опції лишається незаповненим то він заповнюється спеціальною опцією NOP (No-Operation, нічого не робити), RFC 793, номер — 1, довжина — відсутня.[22]

TCP-порти[ред. | ред. код]

Див. також: Список портів TCP і UDP

Поняття порт (port) є ключовим у протоколі TCP. Порт з точки зору операційних систем називається сокетом (socket) процесу. Іншими словами це програмний інтерфейс для забезпечення обміну даними між процесами.

Для розуміння поняття порту з точки зору комп'ютерних мереж легко провести аналогію з роботою звичайної пошти. Коли ви відправляєте листа, то заповнюєте поля Куди: адреса будинку і Кому: людина, яка проживає у цьому будинку. У мережі Інтернет на питання Куди: відповідає IP-протокол, тобто це є IP-адреса хоста, а на питання Кому: відповідає TCP-протокол (або інший протокол транспортного рівня), тобто це номер протоколу прикладного рівня (процес, що відповідає за цей протокол з точки зору операційної системи), який «мешкає» за вказаною IP-адресою хоста. За аналогією зі звичайною поштою ви можете направити 2-а листа 2-м різним людям, які живуть в одному будинку, в Інтернеті ви можете направити TCP-сегменти 2-м різним протоколам прикладного рівня за однією і тією ж самою IP-адресою. Звичайно треба заповнити і зворотню адресу.

В Інтернеті широко вживається форма запису : ip-адреса: порт.

Команда netstat -n може показати наступне: 

192.168.1.31:54132     198.35.26.96:443
192.168.1.31:54138     198.35.26.96:22

Тобто якийсь хост з локальної мережі (використовує приватну IP-адресу) має одночасно з'єднання з сервером в глобальній мережі Інтернет з ip-адресою 198.35.26.96 [Архівовано 18 вересня 2016 у Wayback Machine.] по портам 443 (протокол HTTPS) та 22 (протокол SSH).

За надання і використання портів відповідальна IANA[23], хоча на практиці на відміну від використання IP-адрес це правило не завжди дотримується. Наприклад нічого не заважає адміністраторам 2-х хостів домовитися передавати, якийсь тип IP-трафіку по порту 80, який є закріплений за протоколом http і є відкритим на більшості файрволів.

TCP-заголовок має 16-бітові поля порт джерела та порт призначення, які можуть приймати значення від 0 до 65535.

Порти поділяються на категорії:

  • Загальновідомі (well-known), діапазон номерів 0 — 1023.[24] Як правило це порти, які використовують протоколи прикладного рівня TCP/IP стеку затверджені IETF, згідно з принципами відкритого стандарту. Наприклад: HTTP порт −80, HTTPS — 443, SMTP — 25, Telnet — 23, SSH — 22.
  • Зареєстровані (registered), діапазон номерів 1024 — 49151. За задумом, ці порти призначаються для протоколів різних виробників програмного забезпечення, які мають їх зареєструвати в IANA. Наприклад ігровий сервіс Xbox Live використовує зареєстрований порт 3074.[25] На практиці багато портів у цьому діапазоні використовуються без офіційної реєстрації.
  • Динамічні (приватні, ефемерні, dynamic, private, ephemeral), діапазон номерів 49152-65535. IANA не реєструє ці порти. Використовуються, як правило хостами-клієнтами, для встановлення TCP-з'єднань з хостами-серверами. Як у прикладі вище, коли клієнт з IP-адресою 192.168.1.31 встановив 2 з'єднання зі сервером 198.35.26.96, на стороні клієнта використовуються динамічні порти 54132 та 54138, а на стороні сервера загальновідомі порти 443 (протокол HTTPS) та 22 (протокол SSH).

TCP-сесія[ред. | ред. код]

Діаграма станів TCP-сесії

Завданням протоколу, як випливає з його назви («протокол керування пересиланням»), є контроль надійного передавання даних між хостами, для забезпечення цього між хостами встановлюється логічне з'єднання[en], яке зветься TCP-сесією.[26] Протокол TCP працює у форматі архітектури клієнт-сервер. Хост який надсилає запит на отримання сервісу є клієнтом, той хто відповідає на запит зветься сервером. Хости зв'язуються один з одним за TCP-портами, на стороні клієнта це, як правило, динамічний порт, а на стороні сервера це загальновідомий або зареєстрований порт, номер якого відповідає протоколу прикладного рівня. Номери портів та значення інших параметрів заносяться до заголовка TCP-сегменту.

Тут під терміном сервер (server) розуміють комп'ютер під управлінням операційної системи, який має доступ до IP-мережі та надає послуги одного чи декількох сервісів прикладного рівня. В свою чергу на сервері-комп'ютері встановлені спеціальні сервер-програми, які забезпечують роботу протоколів прикладного рівня. Таким чином, якщо це вебсервер, то на ньому мусить бути встановлена одна із таких програм, як наприклад: Apache HTTP Server. На практиці сервер-комп'ютер надає послуги відзразу декількох сервісів, тобто на ньому може бути встановлено більше однієї сервер-програми, що забезпечують роботу декількох протоколів прикладного рівня. Наприклад сервер-комп'ютер може бути одночасно вебсервером і FTP-сервером та забезпечувати роботу протоколів HTTP, HTTPS та FTP.

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

Кожна окрема сесія роботи протоколу ТСР може бути поділена на три фази:

  1. Встановлення з'єднання
  2. Передавання даних
  3. Закінчення з'єднання

Встановлення з'єднання[ред. | ред. код]

Триходове рукостискання

Необхідною умовою для встановлення ТСР-сесії є відкритий доступ до програмного сокету процесу на сервері, що відповідає за роботу протоколу прикладного рівня, який мовою ТСР зветься портом. За такої умови стан ТСР-сесії на стороні сервера є LISTEN (слухати).[27] Тобто сервер слухає, якийсь конкретний TCP-порт і очікує отримати запит від клієнта на надання послуг, що відповідають номеру цього порту. Початковий стан ТСР-сесії на стороні клієнта є CLOSED.

Для встановлення з'єднання протокол TCP використовує триходове (рукостискання[en]), назване так за кількістю повідомлень між хостами:

  1. Клієнт формує TCP-заголовок: у поле порт джерела заносить свій номер TCP-порта, як правило динамічний, у поле порт призначення номер порту протоколу прикладного рівня, послуги якого хоче отримати, в поле номер послідовності сегменту довільне значення та встановлює прапорець SYN. Сформований таким чином TCP-сегмент відправляється серверу. ТСР-сесія на стороні клієнта переходить у стан SYN-SENT.
  2. Сервер отримує ТСР-сегмент від клієнта зі встановленим прапорцем SYN та у відповідь формує TCP-заголовок: у поле порт джерела заносить свій номер TCP-порта, у поле порт призначення номер порту клієнта. Додає до отриманого від клієнта номера послідовності сегменту 1 і поміщає отримане число до номеру підтвердження, вносить свій власний початковий номер послідовності сегменту та відправляє сегмент до клієнта з прапорцями SYN та ACK. ТСР-сесія на стороні сервера переходить у стан SYN-RECEIVED.
  3. Після отримання ТСР-сегмента зі встановленими прапорцями ACK та SYN клієнт переходить у стан ESTABLISHED та відповідає на запит сервера про синхронізацію шляхом додавання 1 до номера отриманої послідовності сегменту та поміщає це число до номера підтвердження. Далі клієнт надсилає таким чином сформований сегмент до сервера з прапорцем ACK

Після отримання сервером ТСР-сегмента з прапорцем ACK стан ТСР-сесії на його стороні стає також ESTABLISHED, разом з чим розпочинається передавання даних.

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

Закінчення з'єднання[ред. | ред. код]

Закінчення TCP сесії

Ініціатором закінчення з'єднання може бути, як клієнт так і сервер.[28] Для закінчення TCP-сесії використовується так зване чотириходове рукостискання (four-way handshake).

  1. Ініціатор розірвання з'єднання направляє своєму партнеру TCP-сегмент зі встановленим прапорцем FIN. TCP-сесія ініціатора переходить зі стану ESTABLISHED у стан FIN-WAIT-1
  2. Хост-отримувач приймає FIN від ініціатора та посилає у відповідь TCP-сегмент зі встановленим прапорцем АСК. TCP-сесія отримувача переходить зі стану ESTABLISHED у стан CLOSE-WAIT. З набуттям хостом цього стану TCP припиняє отримувати нові запити, на передавання даних, від відповідного протоколу верхнього рівня та встановлює таймер на завершення попередніх запитів. Ініціатор отримує АСК та переходить у стан FIN-WAIT-2.
  3. Після закінчення оброблення всіх запитів протоколів верхнього рівня хост-отримувач переходить у стан LAST-ACK та відправляє ініціатору TCP-сегмент зі встановленим прапорцем FIN.
  4. Ініціатор приймає FIN від отримувача та посилає у відповідь TCP-сегмент зі встановленим прапорцем АСК. Отримувач приймає АСК та переходить у стан CLOSED.

Ініціатор розірвання з'єднання чекає протягом подвійного часу від MSL[en] (максимального життя сегмента, maximum segment lifetime), щоб переконатися, що посланий ACK був отриманий та також переходить у стан CLOSED.

Посилання[ред. | ред. код]

Література[ред. | ред. код]

  • Douglas E. Comer. Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture
  • Дуглас Камер. Сети TCP/IP, том 1. Принципы, протоколы и структура. М. «Вильямс» 2003, ISBN 0-13-018380-6,

Примітки[ред. | ред. код]

  1. ↑ TCP/IP Overview — Cisco. Архів оригіналу за 23 жовтня 2015. Процитовано 30 жовтня 2015.
  2. ↑ а б в Лекція № 10. Протокол транспортного рівня. Архів оригіналу за 11 вересня 2016. Процитовано 30 жовтня 2015.
  3. ↑ IP Application Services Configuration Guide, Cisco IOS XE Release 3S — Configuring TCP [Cisco IOS XE 3S] — Cisco. Архів оригіналу за 29 жовтня 2015. Процитовано 23 жовтня 2015.
  4. ↑ What is ARPANET? The First Internet. Архів оригіналу за 27 жовтня 2018. Процитовано 26 лютого 2016.
  5. ↑ apf — Vinton G. Cerf, Robert E. Kahn, (May 1974). «A Protocol for Packet Network Intercommunication» (PDF). IEEE Transactions on Communications 22 (5): 637—648. doi:10.1109/tcom.1974.1092259 (PDF). Архів оригіналу (PDF) за 23 липня 2015. Процитовано 23 липня 2015.
  6. ↑ CCENT: Cisco Certified Entry Networking Technician Study Guide: ICND1 (Exam … — Todd Lammle — Google Books. Архів оригіналу за 23 листопада 2015. Процитовано 22 листопада 2015.
  7. ↑ Checking your TCP Packets are pulling their weight (TCP Max Segment Size or MSS) — On The Wire — Site Home — TechNet Blogs. Архів оригіналу за 22 грудня 2015. Процитовано 18 грудня 2015.
  8. ↑ F2R001A TCP. Архів оригіналу за 22 грудня 2015. Процитовано 18 грудня 2015.
  9. ↑ The TCP/IP Guide — TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size. Архів оригіналу за 20 жовтня 2020. Процитовано 17 грудня 2015.
  10. ↑ Understanding TCP Sequence and Acknowledgment Numbers — PacketLife.net. Архів оригіналу за 26 жовтня 2015. Процитовано 19 жовтня 2015.
  11. ↑ Security Configuration Guide: Access Control Lists, Cisco IOS Release 15E — Creating an IP Access List to Filter TCP Flags [Cisco IOS 15.2E] — Cisco. Архів оригіналу за 16 жовтня 2015. Процитовано 21 жовтня 2015.
  12. ↑ TCP Flag Options — Section 4. Архів оригіналу за 8 листопада 2015. Процитовано 7 листопада 2015.
  13. ↑ TCP, Transmission Control Protocol. Архів оригіналу за 14 листопада 2015. Процитовано 5 листопада 2015.
  14. ↑ TCP Window Size, Checksum & Urgent Pointer — Section 5. Архів оригіналу за 10 листопада 2015. Процитовано 7 листопада 2015.
  15. ↑ Transmission Control Protocol (TCP) Parameters. Архів оригіналу за 9 листопада 2015. Процитовано 17 листопада 2015.
  16. ↑ Analysing TCP Header Options — Section 6. Архів оригіналу за 17 листопада 2015. Процитовано 12 листопада 2015.
  17. ↑ TCP option 2, Maximum Segment Size. Архів оригіналу за 24 березня 2016. Процитовано 17 листопада 2015.
  18. ↑ TCP option 3, Window Scale. Архів оригіналу за 27 листопада 2015. Процитовано 17 листопада 2015.
  19. ↑ TCP option 5, Selective Acknowledgment. Архів оригіналу за 4 березня 2016. Процитовано 17 листопада 2015.
  20. ↑ TCP option 8, Timestamp. Архів оригіналу за 9 листопада 2015. Процитовано 16 листопада 2015.
  21. ↑ TCP option 8, Timestamp. Архів оригіналу за 9 листопада 2015. Процитовано 16 листопада 2015.
  22. ↑ TCP option 1, No operation. Архів оригіналу за 4 березня 2016. Процитовано 18 листопада 2015.
  23. ↑ Service Name and Transport Protocol Port Number Registry. The Internet Assigned Numbers Authority (IANA). Архів оригіналу за 28 грудня 2017. Процитовано 9 листопада 2015.
  24. ↑ RFC 6335 — Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry. Архів оригіналу за 7 квітня 2019. Процитовано 10 листопада 2015.
  25. ↑ Xbox 360 Network Ports and Router Configurations for Xbox Live. Архів оригіналу за 12 листопада 2015. Процитовано 10 листопада 2015.
  26. ↑ IP Application Services Configuration Guide, Cisco IOS XE Release 3S — Configuring TCP [Cisco IOS XE 3S] — Cisco. Архів оригіналу за 29 жовтня 2015. Процитовано 23 жовтня 2015.
  27. ↑ The TCP/IP Guide — TCP Connection Establishment Process: The «Three-Way Handshake». Архів оригіналу за 20 листопада 2015. Процитовано 19 листопада 2015.
  28. ↑ The TCP/IP Guide — TCP Connection Termination. Архів оригіналу за 6 грудня 2015. Процитовано 22 грудня 2015.


Отримано з https://uk.wikipedia.org/w/index.php?title=TCP&oldid=39960142#Прапорці_(керуючі_біти)