Просмотр кода страницы TCP

{{Карточка протокола
| Аббр          = TCP
| Название      = Transmission Control Protocol
| Уровень       = Транспортный
| Семейство     = [[TCP/IP]]
| Спецификация  = RFC 793 (сентябрь 1981 года) / {{Inet-note-ref|type=std|id=7|text=STD 7}}
| Реализации    = [[UNIX]], [[Linux (ядро)|Linux]], [[BSD]], [[Windows]]
| Расширяемость = Опции
}}
'''TCP''' ({{lang-en|Transmission Control Protocol}} — протокол управления передачей) — один из основных [[Протокол передачи данных|протоколов]] [[Передача данных|передачи данных]] интернета. Пакеты в TCP называются ''сегментами'''''.'''

В стеке протоколов [[TCP/IP]] выполняет функции [[Транспортный уровень|транспортного уровня]] [[Сетевая модель OSI|модели OSI]].

Механизм TCP предоставляет [[поток данных]] с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от [[UDP]]) целостность передаваемых данных и уведомление отправителя о результатах передачи.

Реализации TCP обычно встроены в [[Ядро операционной системы|ядра]] [[Операционная система|ОС]]. Существуют реализации TCP, работающие в [[Пространство пользователя|пространстве пользователя]].

== Заголовок сегмента TCP ==
{| class="standard" text-align: center"
|+ '''Структура заголовка'''
|- align="center"
! colspan="1" width="3%"| [[Бит]]
! colspan="4" width="12%"| 0 — 3
! colspan="6" width="18%"| 4 — 6
! colspan="6" width="18%"| 7 — 15
! colspan="16" width="48%"| 16 — 31
|- align="center"
! colspan="1"|0
| colspan="16"|Порт источника, '''Source Port''' 
| colspan="16"|Порт назначения, '''Destination Port'''
|- align="center"
! colspan="1"|32
| colspan="32"|Порядковый номер, '''Sequence Number (SN)'''
|- align="center"
! colspan="1"|64
| colspan="32"|Номер подтверждения, '''Acknowledgment Number (ACK SN)'''
|- align="center"
! colspan="1"|96
| colspan="4"|Длина заголовка, ('''Data offset''')
| colspan="6"|Зарезервировано
| colspan="6"|Флаги
| colspan="16"|Размер Окна, '''Window size'''
|- align="center"
! colspan="1"|128
| colspan="16"|Контрольная сумма, '''Checksum'''
| colspan="16"|Указатель важности, '''Urgent Pointer'''
|- align="center"
! colspan="1"|160
| colspan="32" bgcolor="#FFDDDD"|Опции (необязательное, но используется практически всегда)
|- align="center"
! colspan="1"|160/192+
| colspan="32" | Данные
|}

=== Порт источника, Порт назначения ===
Эти 16-битные поля содержат номера [[Порт (TCP/UDP)|портов]] — числа, которые определяются по [[Список портов TCP и UDP|специальному списку]].

'''Порт источника''' идентифицирует приложение клиента, с которого отправлены пакеты. Ответные данные передаются клиенту на основании этого номера.

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

=== Порядковый номер ===
'''Sequence number''' (32 бита) — измеряется в байтах, и каждый переданный байт полезных данных (payload) увеличивает это значение на 1.

Если установлен флаг SYN (идёт установление сессии), то поле содержит изначальный порядковый номер — ISN (Initial Sequence Number). В целях безопасности это значение генерируется случайным образом и может быть равно от 0 до 2<sup>32</sup>−1 (4294967295). Первый байт полезных данных в устанавливающейся сессии будет иметь номер ISN+1.

В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер.

Поскольку поток TCP в общем случае может быть длиннее, чем число различных состояний этого поля, то все операции с порядковым номером должны выполняться по {{s|модулю 2<sup>32</sup>.}} Это накладывает практическое ограничение на использование TCP. Если скорость передачи коммуникационной системы такова, чтобы в течение MSL (максимального времени жизни сегмента) произошло переполнение порядкового номера, то в сети может появиться два сегмента с одинаковым номером, относящихся к разным частям потока, и приёмник получит некорректные данные.

=== Номер подтверждения ===
'''Acknowledgment Number (ACK SN)''' (32 бита) — если установлен флаг ACK, то это поле содержит порядковый номер байта, который отправитель данного сегмента желает получить. Это означает, что все предыдущие байты (с номерами {{s|от ISN+1}} {{s|до ACK-1}} включительно) были успешно получены.

Каждая сторона подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

=== Длина заголовка (смещение данных) ===
Длина заголовка (Data offset) занимает 4 бита и указывает значение длины заголовка, измеренное в 32-битовых [[Машинное слово|словах]]. Минимальный размер составляет 20 байт (пять 32-битовых [[Машинное слово|слов]]), а максимальный — 60 байт (пятнадцать 32-битовых [[Машинное слово|слов]]). Длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111<sub>2</sub> говорит о том, что заголовок занимает пятнадцать 32-битных [[Машинное слово|слова]] (15 строк*32 бита в каждой строке/8 бит = 60 байт).

=== Зарезервировано ===
Зарезервировано (3 бита) для будущего использования и должно устанавливаться в ноль.

=== Флаги (управляющие биты) ===
Это поле содержит 9 битовых флагов:

* '''NS''' (ECN-nonce) — Устойчивый механизм сигнализации насыщения с помощью ECN-nonce (RFC 3540)

* '''CWR''' (Congestion Window Reduced) — Поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтобы указать, что получен пакет с установленным флагом ECE (RFC 3168)
* '''ECE''' (ECN-Echo) — Поле «Эхо ECN» — указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети (RFC 3168)

* '''URG''' — поле ''«Указатель важности»'' задействовано ({{lang-en|Urgent pointer field is significant}}). Когда узел отправляет сегмент с URG флагом, то узел-получатель принимает его на отдельном канале.

* '''ACK''' — поле ''«Номер подтверждения»'' задействовано ({{lang-en|Acknowledgement field is significant}})
* '''PSH''' — ({{lang-en|Push function}}) инструктирует получателя протолкнуть данные, накопившиеся в приёмном буфере, в приложение пользователя. API для установки PSH флага нет. Обычно он устанавливается ядром, когда оно очищает буфер. Дело в том, что когда узел отправляет информацию, TCP сохраняет её в буфере и не передает её сразу другому узлу, ожидая, захочет ли узел-отправитель передать ещё. Такая же схема работает и у узла-получателя. Когда он получает информацию, TCP сохраняет её в буфере, чтобы не тревожить приложение из-за каждого байта полученной информации. Если узел отправляет сегмент с PSH флагом, это значит, что он отправил все, что было нужно.
* '''RST''' — оборвать соединения, сбросить буфер (очистка буфера) ({{lang-en|Reset the connection}})
* '''SYN''' — синхронизация номеров последовательности ({{lang-en|Synchronize sequence numbers}})
* '''FIN''' ({{lang-en|final}}, бит) — флаг, будучи установлен, указывает на завершение соединения ({{lang-en|FIN bit used for connection termination}}).

=== Размер окна ===
Window Size самостоятельно определяет количество байт данных ([[payload]]), после передачи которых отправитель ожидает подтверждения от получателя, что данные получены. Иначе говоря, получатель пакета располагает для приёма данных буфером длиной «размер окна» байт.

По умолчанию размер окна измеряется в байтах, поэтому ограничен 2<sup>16</sup> (65535) байтами. Однако благодаря TCP опции Window scale option этот размер может быть увеличен до 1 Гбайта. Чтобы задействовать эту опцию, обе стороны должны согласовать это в своих SYN сегментах.

=== Контрольная сумма (Checksum) ===
<!--The 16-bit [[checksum]] field is used for error-checking of the header ''and data''. The method used to compute the checksum is defined in RFC 793:

:: ''The checksum field is the 16 bit one’s complement of the one’s complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.''

: In other words, all 16-bit words are summed together using [[one's complement]] (with the checksum field set to zero). The sum is then one’s complemented. This final value is then inserted as the checksum field. Algorithmically speaking, this is the same as for [[IPv4]].

: The difference is in the data used to make the checksum. Included is a pseudo-header that mimics the IP header:
-->
Поле контрольной суммы — это 16-битное дополнение к сумме всех 16-битных [[Машинное слово|слов]] заголовка (включая псевдозаголовок) и данных. Если сегмент, по которому вычисляется контрольная сумма, имеет длину не кратную 16-битам, то длина сегмента увеличивается до кратной 16-ти за счёт добавления к нему справа нулевых битов заполнения. Биты заполнения (0) не передаются в сообщении и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.

=== Указатель важности (Urgent pointer) ===
<!-- If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte.

Options
    Additional header fields (called options) may follow the urgent pointer. If any options are present then the total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately.
-->
16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер байта, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG. Используется для [[Внеполосные данные|внеполосных данных]].

=== Опции ===
Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта [[NOP]] (в данном случае 0x01) и 10 байт, задающих [[timestamp]]s. Вычислить длину поля опции можно через значение поля смещения.

== Механизм действия протокола ==
В отличие от традиционной альтернативы — UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP-соединение можно разделить на 3 стадии:
# Установка соединения.
# Передача данных.
# Завершение соединения.

=== Состояния сеанса TCP ===
[[Файл:Tcp state diagram fixed.svg|right|thumbnail|250px|Упрощённая диаграмма состояний TCP. Более подробно в [http://www.medianet.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf  TCP EFSM diagram] (на английском языке)]]

{| class="standard" text-align: left"
!colspan="2" | Состояния сеанса TCP
|-
|width="120px"|'''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 (подтверждения на свой запрос о разъединении)
|-
|}

=== Установка соединения ===
Процесс начала сеанса TCP (также называемый «рукопожатие» ({{lang-en|handshake}})), состоит из трёх шагов.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

:* Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буфера и управляющие структуры памяти) для обслуживания нового клиента.
:* В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED.
:* В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.
:* Если клиент одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED.
:* Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
:* Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.
:* В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется «трёхэтапным рукопожатием» ({{lang-en|three way handshake}}), так как, несмотря на то, что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

Пример базового 3-этапного согласования:

 TCP A                                                    TCP B
    1.  CLOSED                                               LISTEN
    2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
    3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
    4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>      --> ESTABLISHED
    5.  ESTABLISHED <-- <SEQ=301><ACK=101><CTL=ACK><DATA>      <-- 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 (ACK=101) совпадает с номером последовательности в строке 4 (SEQ=101), поскольку ACK не занимает пространства номеров последовательности (если это сделать, придётся подтверждать подтверждения — ACK для ACK).

Существуют экспериментальные расширения протокола TCP, сокращающие количество пакетов при установлении соединения, например {{iw|TCP Fast Open|TCP Fast Open|en|TCP Fast Open}}. Ранее также существовало расширение [[T/TCP]]. Для прозрачного шифрования данных предлагается использовать расширение [[tcpcrypt]].

=== Передача данных ===
{{also|Алгоритм Нейгла|Медленный старт}}
При обмене данными приёмник использует номер последовательности, содержащийся в получаемых сегментах, для восстановления их исходного порядка. Приёмник уведомляет передающую сторону о номере последовательности, до которой он успешно получил данные, включая его в поле «номер подтверждения».
Все получаемые данные, относящиеся к промежутку подтверждённых последовательностей, игнорируются. Если полученный сегмент содержит номер последовательности больший, чем ожидаемый, то данные из сегмента буферизируются, но номер подтверждённой последовательности не изменяется. Если впоследствии будет принят сегмент, относящийся к ожидаемому номеру последовательности, то порядок данных будет автоматически восстановлен исходя из номеров последовательностей в сегментах.

Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приёмник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приёмника передающей стороне, в поле «окно» указывается текущий размер приёмного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приёмник. Если приёмник указал нулевой размер окна, то передачи данных в направлении этого узла не происходит, пока приёмник не сообщит о большем размере окна.

В некоторых случаях передающее приложение может явно затребовать передать данные до некоторой последовательности принимающему приложению, не буферизируя их. Для этого используется флаг PSH. Если в полученном сегменте обнаруживается флаг PSH, то реализация TCP отдаёт все буферизированные на текущий момент данные принимающему приложению. «Проталкивание» используется, например, в интерактивных приложениях. В сетевых терминалах нет смысла ожидать ввода пользователя после того, как он закончил набирать команду. Поэтому последний сегмент, содержащий команду, обязан содержать флаг PSH, чтобы приложение на принимающей стороне смогло начать её выполнение.

=== Завершение соединения ===
Завершение соединения можно рассмотреть в три этапа:
# Посылка серверу от клиента флага FIN на завершение соединения.
# Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
# После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

== Известные проблемы ==

=== Максимальный размер сегмента ===
TCP требует явного указания максимального размера сегмента ([[MSS]]) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока ([[Maximum transmission unit|MTU]]) менее, чем стандартный MTU Ethernet (1500 байт).

В протоколах туннелирования, таких как [[GRE (протокол)|GRE]], [[IPIP]], а также [[PPPoE]] MTU туннель меньше, чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Это приводит к фрагментации и уменьшению скорости передачи полезных данных.
Если на каком-либо узле фрагментация запрещена, то со стороны пользователя это выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера. Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.

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

=== Обнаружение ошибок при передаче данных ===
Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым [http://portal.acm.org/citation.cfm?doid=347059.347561].

В общем случае распределенным сетевым приложениям рекомендуется использовать дополнительные программные средства для гарантирования целостности передаваемой информации[http://evanjones.ca/tcp-checksums.html].

=== Атаки на протокол ===
{{also|TCP hijacking|Атака TCP Reset}}
Недостатки протокола проявляются в успешных теоретических и практических атаках, при которых злоумышленник может получить доступ к передаваемым данным, выдать себя за другую сторону или привести систему в нерабочее состояние.

== Реализация ==

=== Псевдозаголовок ===
TCP-заголовок не содержит информации об адресе отправителя и получателя, поэтому даже при совпадении порта получателя нельзя с точностью сказать, что сообщение пришло в нужное место. Поскольку назначением протокола TCP является надёжная доставка сообщений, то этот момент имеет принципиальное значение. Эту задачу можно было решить разными способами. Самый очевидный — добавить информацию об адресе назначения в заголовок TCP, однако это, во-первых, приводит к дублированию информации, что снижает долю полезной информации, переносимой TCP-сегментом, а во-вторых, нарушает принцип инкапсуляции модели OSI. Поэтому разработчики протокола пошли другим путём и использовали дополнительный псевдозаголовок:

''TCP-псевдозаголовок IPv4''
{| class="standard"
 !Биты 
 !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
 |- align="center"
 !0-31
 |colspan=32 |IP-адрес отправителя (Source address)
 |- align="center"
 !32-63
 |colspan=32 |IP-адрес получателя (Destination address)
 |- align="center"
 !64-95
 |0||0||0||0||0||0||0||0
 |colspan=8 |Протокол (Protocol)
 |colspan=16 |Длина TCP-сегмента (TCP length)
 |}

''TCP-псевдозаголовок IPv6''
{| class="standard"
 !Биты 
 !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
 |- align="center"
 !0-127
 |colspan=32 |IP-адрес отправителя (Source address)
 |- align="center"
 !128-223
 |colspan=32 |IP-адрес получателя (Destination address)
 |- align="center"
 !224-255
 |colspan=32 |Длина TCP-сегмента (TCP length)
 |- align="center"
 !256-287
 |0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0||0
 |colspan=8 |Протокол верхнего уровня (Next header)
 |- align="center"
 |}

* Протокол (Protocol)/Протокол верхнего уровня (Next header) — содержит в себе значение 6 (00000110 в двоичном виде, 0x6 — в шестнадцатеричном) — идентификатор TCP-протокола.
* Длина TCP-сегмента (TCP length) — содержит в себе длину TCP-сегмента в байтах (TCP-заголовок + данные; длина псевдозаголовка не учитывается).

Псевдозаголовок не включается в TCP-сегмент. Он используется для расчёта контрольной суммы перед отправлением сообщения и при его получении (получатель составляет свой псевдозаголовок, используя адрес хоста, с которого пришло сообщение, и собственный адрес, а затем считает контрольную сумму).

=== Освобождение от расчёта контрольной суммы ===
Многие реализации стека TCP/IP предоставляют возможности использования аппаратной поддержки для автоматического расчёта контрольной суммы в сетевом адаптере до передачи в сеть или после приёма из сети для верификации. Это может освобождать операционную систему от использования ценных тактов процессора при вычислении контрольной суммы.

Эта функция может приводить к тому, что [[анализатор трафика|анализаторы трафика]], перехватывающие исходящие пакеты до их передачи в сетевой адаптер и не знающие о делегировании расчёта контрольной суммы сетевому адаптеру, могут сообщать об ошибке контрольной суммы в исходящих пакетах.

== См. также ==
* [[SCTP]]
* [[TCP hijacking]]
* [[BIC TCP]]
* [[Порт (компьютерные сети)|Порт (TCP/IP)]]
* [[IP]]
* [[UDP]]

== Литература ==
* {{книга
|автор = Терри Оглтри.
|заглавие = Модернизация и ремонт сетей
|оригинал = Upgrading and Repairing Networks
|ссылка = 
|издание = 4-е изд
|место =  М.
|издательство = «[[Вильямс (издательство)|Вильямс]]»
|год = 2005
|страницы = 1328
|isbn = 0-7897-2817-6
}}
* {{книга
|автор = Дуглас Камер.
|заглавие = Сети TCP/IP, том 1. Принципы, протоколы и структура
|оригинал = Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture
|ссылка = 
|место =  М.
|издательство = «[[Вильямс (издательство)|Вильямс]]»
|год = 2003
|страницы = 880
|isbn = 0-13-018380-6
}}
* {{книга
|автор = Андрей Робачевский, Сергей Немнюгин, Ольга Стесик. 
|заглавие = Операционная система UNIX
|ссылка = 
|издание = 2-е изд
|издательство = «[[БХВ-Петербург (издательство)|БХВ-Петербург]]»
|год = 2007
|страницы = 656
|isbn = 5-94157-538-6
}}

== Ссылки ==
* RFC 793{{ref|en}} — Transmission Control Protocol
* [https://rfc.com.ru/rfc793.htm RFC 793 на русском]
* [http://www.citforum.ru/internet/tifamily/tcpspec.shtml Спецификация протокола TCP]
* [https://wireshark.wiki/wiki/Правила_чтения_таблиц,_описывающих_структуру_заголовков_сетевых_протоколов Правила чтения таблиц, описывающих структуру заголовков сетевых протоколов]

{{Библиоинформация}}
{{IPstack|nocat=1}}

[[Категория:Протоколы транспортного уровня]]
[[Категория:TCP/IP]]