Протокол управления передачей

Протокол управления передачей

Стек протоколов
Аббревиатура	TCP
Разработчик(и)	Винт Серф и Боб Кан
Введение	1974 год ( 1974 )
На основе	Программа управления коробкой передач
Уровень OSI	Транспортный уровень (4)
RFC(ы)	RFC 9293

Протокол управления передачей ( TCP ) является одним из основных протоколов набора протоколов Интернета . Он возник в первоначальной реализации сети, в которой он дополнял Интернет-протокол (IP). Поэтому весь пакет обычно называют TCP/IP . TCP обеспечивает надежную , упорядоченную и проверенную на ошибки доставку потока октетов ( байтов ) между приложениями, работающими на хостах, взаимодействующих через IP-сеть. Основные интернет-приложения, такие как Всемирная паутина , электронная почта, удаленное администрирование и передача файлов , используют протокол TCP, который является частью транспортного уровня пакета TCP/IP. SSL/TLS часто работает поверх TCP.

TCP ориентирован на соединение . Это означает, что отправителю и получателю сначала необходимо установить соединение на основе согласованных параметров; они делают это посредством процедуры трехстороннего рукопожатия. Сервер должен прослушивать (пассивно открываться) запросы на подключение от клиентов, прежде чем соединение будет установлено. Трехстороннее рукопожатие (активное открытие), повторная передача и обнаружение ошибок повышают надежность, но удлиняют задержку . Приложения, которым не требуется надежная служба потоков данных, могут вместо этого использовать протокол пользовательских дейтаграмм (UDP), который обеспечивает без установления соединения службу дейтаграмм , в которой время приоритетнее надежности. TCP использует предотвращение перегрузки сети . Однако в TCP существуют уязвимости, в том числе отказ в обслуживании , перехват соединения , вето TCP и атака сброса .

Историческое происхождение

В мае 1974 года Винт Серф и Боб Кан описали протокол межсетевого взаимодействия для совместного использования ресурсов с использованием коммутации пакетов между сетевыми узлами. Авторы работали с Жераром Ле Ланном над включением концепций французского проекта CYCLADES в новую сеть. Спецификация . полученного протокола, RFC 675 ( Спецификация программы управления передачей через Интернет ), была написана Винтом Серфом, Йогеном Далалом и Карлом Саншайном и опубликована в декабре 1974 года Он содержит первое засвидетельствованное использование термина Интернет как сокращения от межсетевого взаимодействия .

Программа управления передачей включала как каналы связи, так и службы дейтаграмм между хостами. В версии 4 монолитная Программа управления передачей была разделена на модульную архитектуру, состоящую из Протокола управления передачей и Интернет-протокола . В результате появилась сетевая модель, которая неофициально стала известна как TCP/IP , хотя формально ее называли по-разному: моделью интернет-архитектуры Министерства обороны США ( моделью Министерства обороны США сокращенно ) или моделью DARPA . Позже он стал частью и синонимом Internet Protocol Suite .

Следующие документы Internet Experiment Note (IEN) описывают эволюцию TCP до современной версии:

• IEN 5 Спецификация программы управления передачей через Интернет TCP, версия 2 ( март 1977 г.).
• IEN 21 Спецификация программы управления межсетевой передачей TCP, версия 3 ( январь 1978 г.).
• ОДИН 27
• ОДИН 40
• ОДИН 44
• ОДИН 55
• ОДИН 81
• ОДИН 112
• ОДИН 124

TCP был стандартизирован в январе 1980 года как РФК   761 .

В 2004 году Винт Серф и Боб Кан получили Премию Тьюринга за фундаментальную работу над TCP/IP.

Сетевая функция

Протокол управления передачей обеспечивает службу связи на промежуточном уровне между прикладной программой и Интернет-протоколом. Он обеспечивает соединение между хостами на транспортном уровне модели Интернета . Приложению не нужно знать конкретные механизмы отправки данных по каналу на другой хост, например, необходимую IP-фрагментацию для размещения максимальной единицы передачи в среде передачи. На транспортном уровне TCP обрабатывает все детали установления связи и передачи и представляет приложению абстракцию сетевого подключения, обычно через интерфейс сетевого сокета .

На нижних уровнях стека протоколов из-за перегрузки сети трафика , балансировки нагрузки или непредсказуемого поведения сети IP-пакеты могут теряться , дублироваться или доставляться не по порядку . TCP обнаруживает эти проблемы, запрашивает повторную передачу потерянных данных, упорядочивает неупорядоченные данные и даже помогает минимизировать перегрузку сети, чтобы уменьшить возникновение других проблем. Если данные по-прежнему не доставлены, источник уведомляется об этой ошибке. Как только получатель TCP заново собрал последовательность первоначально переданных октетов, он передает их принимающему приложению. Таким образом, TCP абстрагирует взаимодействие приложения от основных сетевых деталей.

TCP широко используется многими интернет-приложениями, в том числе Всемирной паутиной (WWW), электронной почтой, протоколом передачи файлов , Secure Shell , одноранговым обменом файлами и потоковым мультимедиа .

TCP оптимизирован для точной доставки, а не для своевременной доставки, и может вызывать относительно длительные задержки (порядка секунд) при ожидании сообщений, находящихся вне очереди, или повторной передачи потерянных сообщений. Поэтому он не особенно подходит для приложений реального времени, таких как передача голоса по IP . Для таких приложений протоколы, как транспортный протокол реального времени (RTP), работающий поверх протокола пользовательских дейтаграмм (UDP). обычно рекомендуются такие

TCP — это надежная служба доставки потока байтов , которая гарантирует, что все полученные байты будут идентичны и в том же порядке, что и отправленные. Поскольку передача пакетов во многих сетях ненадежна, TCP достигает этого с помощью метода, известного как положительное подтверждение с повторной передачей . Для этого получатель должен ответить подтверждающим сообщением при получении данных. Отправитель ведет учет каждого отправляемого пакета и поддерживает таймер с момента отправки пакета. Отправитель повторно передает пакет, если таймер истекает до получения подтверждения. Таймер необходим на случай потери или повреждения пакета.

В то время как IP занимается фактической доставкой данных, TCP отслеживает сегменты — отдельные единицы передачи данных, на которые делится сообщение для эффективной маршрутизации по сети. Например, когда файл HTML отправляется с веб-сервера, уровень программного обеспечения TCP этого сервера делит файл на сегменты и пересылает их индивидуально на интернет-уровень сетевого стека . Программное обеспечение интернет-уровня инкапсулирует каждый сегмент TCP в IP-пакет, добавляя заголовок, который включает (помимо других данных) IP-адрес назначения . Когда клиентская программа на целевом компьютере получает их, программное обеспечение TCP на транспортном уровне повторно собирает сегменты и обеспечивает их правильный порядок и отсутствие ошибок при потоковой передаче содержимого файла принимающему приложению.

Структура TCP-сегмента

Протокол управления передачей принимает данные из потока данных, делит их на фрагменты и добавляет заголовок TCP, создавая сегмент TCP. Затем сегмент TCP инкапсулируется в дейтаграмму Интернет-протокола (IP) и обменивается данными с одноранговыми узлами.

Термин TCP-пакет встречается как в неформальном, так и в формальном использовании, тогда как в более точной терминологии сегмент относится к блоку данных протокола TCP (PDU), дейтаграмме. в IP PDU и кадр в PDU канального уровня :

Процессы передают данные, вызывая TCP и передавая буферы данных в качестве аргументов. TCP упаковывает данные из этих буферов в сегменты и вызывает интернет-модуль [например, IP] для передачи каждого сегмента в TCP-адрес назначения.

Сегмент TCP состоит из заголовка сегмента и раздела данных . Заголовок сегмента содержит 10 обязательных полей и необязательное поле расширения ( Параметры , розовый фон в таблице). Раздел данных следует за заголовком и представляет собой полезные данные, переносимые для приложения. Длина раздела данных не указана в заголовке сегмента; ее можно рассчитать путем вычитания общей длины заголовка сегмента и заголовка IP из общей длины датаграммы IP, указанной в заголовке IP.

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

Смещения		0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
0	0	Исходный порт																Порт назначения
4	32	Порядковый номер
8	64	Номер подтверждения (если установлен ACK)
12	96	Смещение данных				Сдержанный 0 0 0 0				КВР	ЕЭК	УРГ	ПОДТВЕРЖДЕНИЕ	ПШ	РСТ	СИН	КОНЕЦ	Размер окна
16	128	Контрольная сумма																Указатель срочности (если установлен URG)
20	160	Опции (если смещение данных > 5. При необходимости дополняется в конце битами «0»).
⋮	⋮
56	448

Исходный порт (16 бит)

Определяет порт отправки.

Порт назначения (16 бит)

Идентифицирует принимающий порт.

Порядковый номер (32 бита)

Имеет двойную роль:

• Если флаг SYN установлен (1), то это начальный порядковый номер. Порядковый номер фактического первого байта данных и подтвержденный номер в соответствующем ACK равны этому порядковому номеру плюс 1.
• Если флаг SYN не установлен (0), то это накопленный порядковый номер первого байта данных этого сегмента для текущего сеанса.

Номер подтверждения (32 бита)

Если флаг ACK установлен, то значением этого поля является следующий порядковый номер, который ожидает отправитель ACK. Это подтверждает получение всех предыдущих байтов (если таковые имеются). Первый ACK, отправленный каждым концом, подтверждает исходный порядковый номер другого конца, но не данные.

Смещение данных (4 бита)

Указывает размер заголовка TCP в 32-битных словах . Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что дает минимальный размер 20 байт и максимум 60 байт, что позволяет использовать до 40 байтов параметров в заголовке. Это поле получило свое название из-за того, что оно также является смещением от начала сегмента TCP до фактических данных.

Зарезервировано (4 бита)

Для будущего использования и должен быть установлен на ноль; отправители не должны устанавливать их, а получатели должны игнорировать их, если они установлены, при отсутствии дальнейшей спецификации и реализации.

С 2003 по 2017 год последний бит (бит 103 заголовка) определялся как флаг NS (Nonce Sum) экспериментальным RFC 3540 , ECN-nonce. ECN-nonce так и не получил широкого распространения, и RFC был переведен в исторический статус.

Флаги (8 бит)

Содержит 8 1-битных флагов (битов управления) следующим образом:

• CWR (1 бит): Флаг уменьшения окна перегрузки (CWR) устанавливается отправляющим хостом, чтобы указать, что он получил сегмент TCP с установленным флагом ECE и ответил в механизме управления перегрузкой.
• ECE (1 бит): ECN-Echo имеет двойную роль, в зависимости от значения флага SYN. Это указывает:

• Если установлен флаг SYN (1), одноранговый узел TCP поддерживает ECN .
• Если флаг SYN не установлен (0), пакет с установленным флагом Congestion Experienced (ECN=11) в его IP-заголовке был получен во время нормальной передачи. Это служит индикатором перегрузки сети (или предстоящей перегрузки) для отправителя TCP.

• URG (1 бит): указывает, что поле указателя срочности имеет значение.
• ACK (1 бит): указывает, что поле подтверждения значимо. Этот флаг должен быть установлен для всех пакетов после исходного пакета SYN, отправленного клиентом.
• PSH (1 бит): функция push. Просит передать буферизованные данные принимающему приложению.
• RST (1 бит): сброс соединения.
• SYN (1 бит): синхронизировать порядковые номера. Этот флаг должен быть установлен только для первого пакета, отправленного с каждого конца. Некоторые другие флаги и поля меняют значение в зависимости от этого флага, некоторые действительны только тогда, когда он установлен, а другие — когда он снят.
• FIN (1 бит): последний пакет от отправителя.

Размер окна (16 бит)

Размер окна приема , который определяет количество единиц размера окна. который отправитель этого сегмента в данный момент готов получить. (См. § Управление потоком и § Масштабирование окна .)

Контрольная сумма (16 бит)

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

Указатель срочности (16 бит)

Если флаг URG установлен, то это 16-битное поле представляет собой смещение от порядкового номера, указывающее последний байт срочных данных.

Опции (переменная 0–320 бит, с шагом 32 бита)

Длина этого поля определяется полем смещения данных . Опции имеют до трех полей: Option-Kind (1 байт), Option-Length (1 байт), Option-Data (переменная). Поле Option-Kind указывает тип параметра и является единственным полем, которое не является необязательным. В зависимости от значения Option-Kind могут быть установлены следующие два поля. Option-Length указывает общую длину опции, а Option-Data содержит данные, связанные с опцией, если это применимо. Например, байт Option-Kind, равный 1, указывает, что это опция без операции, используемая только для заполнения, и за ней не следуют поля Option-Length или Option-Data. Байт Option-Kind, равный 0, отмечает конец опций и также составляет всего один байт. Байт Option-Kind, равный 2, используется для указания параметра максимального размера сегмента, за ним следует байт Option-Length, определяющий длину поля MSS. Option-Length — это общая длина данного поля параметров, включая поля Option-Kind и Option-Length. Таким образом, хотя значение MSS обычно выражается в двух байтах, Option-Length будет равняться 4. Например, поле параметра MSS со значением 0x05B4 кодируется как (0x02 0x04 0x05B4) в разделе параметров TCP.

Некоторые параметры могут быть отправлены только тогда, когда установлен SYN; они обозначены ниже как ^[SYN]. Option-Kind и стандартная длина, заданная как (Option-Kind, Option-Length).

Вариант-Вид	Опция-Длина	Опция-Данные	Цель	Примечания
0	—	—	Конец списка опций
1	—	—	Нет операции	Это можно использовать для выравнивания полей параметров по 32-битным границам для повышения производительности.
2	4	SS	Максимальный размер сегмента	см . в § Максимальный размер сегмента . Подробности [SYN]
3	3	С	Масштаб окна	см . в § Масштабирование окна . Подробности [SYN]
4	2	—	Разрешено выборочное подтверждение	см . в § Выборочные подтверждения . Подробности [SYN]
5	Н (10, 18, 26 или 34)	ББББ, ЭЭЭЭ,...	Выборочное подтверждение (SACK)	За этими первыми двумя байтами следует список из 1–4 выборочно подтверждаемых блоков, определяемых как 32-битные указатели начала/конца.
8	10	ГГГ, ЭЭЭЭ	Временная метка и эхо предыдущей временной метки	см . в разделе Временные метки TCP . Подробности
28	4	—	Пользовательский параметр тайм-аута	Видеть РФК 5482 .
29	Н	—	Опция TCP-аутентификации (TCP-AO)	Для аутентификации сообщений замена аутентификации MD5 (опция 19), изначально предназначенной для защиты сеансов BGP . Видеть РФК 5925 .
30	Н	—	Многопутевой TCP (MPTCP)	смотрите в разделе Multipath TCP Подробности .

Остальные значения Option-Kind являются историческими, устаревшими, экспериментальными, еще не стандартизированными или не назначенными. Присвоение номеров опций поддерживается Управлением по присвоению номеров в Интернете (IANA).

Заполнение

Заполнение заголовка TCP используется для обеспечения того, чтобы заголовок TCP заканчивался и данные начинались на 32-битной границе. Заполнение состоит из нулей.

Протокол работы

Упрощенная диаграмма состояний TCP.

Операции протокола TCP можно разделить на три фазы. Установление соединения — это многоэтапный процесс установления связи, который устанавливает соединение перед переходом к этапу передачи данных . После завершения передачи данных завершение соединения закрывает соединение и освобождает все выделенные ресурсы.

TCP-соединение управляется операционной системой через ресурс, который представляет собой локальную конечную точку связи — интернет-сокет . За время существования TCP-соединения локальная конечная точка претерпевает ряд изменений состояния :

Состояния TCP-сокета

Состояние	Конечная точка	Описание
СЛУШАТЬ	Сервер	Ожидание запроса на соединение от любой удаленной конечной точки TCP.
СИН-ОТПРАВЛЕНО	Клиент	Ожидание соответствующего запроса на соединение после отправки запроса на соединение.
SYN-ПОЛУЧЕНО	Сервер	Ожидание подтверждающего подтверждения запроса на соединение после получения и отправки запроса на соединение.
УЧРЕДИЛ	Сервер и клиент	Открытое соединение, полученные данные могут быть доставлены пользователю. Нормальное состояние для фазы передачи данных соединения.
ФИН-ОЖИДАНИЕ-1	Сервер и клиент	Ожидание запроса на завершение соединения от удаленного TCP или подтверждения ранее отправленного запроса на завершение соединения.
ФИН-ОЖИДАНИЕ-2	Сервер и клиент	Ожидание запроса на завершение соединения от удаленного TCP.
ЗАКРЫТЬ-ЖДАТЬ	Сервер и клиент	Ожидание запроса на прекращение соединения от локального пользователя.
ЗАКРЫТИЕ	Сервер и клиент	Ожидание подтверждения запроса на завершение соединения от удаленного TCP.
ПОСЛЕДНИЙ ПОДТВЕРЖДЕНИЕ	Сервер и клиент	Ожидание подтверждения запроса на завершение соединения, ранее отправленного на удаленный TCP (что включает в себя подтверждение его запроса на завершение соединения).
ВРЕМЯ-ОЖИДАНИЕ	Сервер или клиент	Ожидание достаточного времени, чтобы убедиться, что срок действия всех оставшихся пакетов в соединении истек.
ЗАКРЫТО	Сервер и клиент	Нет состояния соединения вообще.

Установление соединения

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

1. SYN : активное открытие выполняется клиентом, отправляющим SYN на сервер. Клиент устанавливает порядковый номер сегмента как случайное значение A.
2. SYN-ACK : В ответ сервер отправляет SYN-ACK. Номер подтверждения устанавливается на единицу больше, чем полученный порядковый номер, т. е. A+1, а порядковый номер, который сервер выбирает для пакета, представляет собой другое случайное число, B.
3. ACK : Наконец, клиент отправляет ACK обратно на сервер. Порядковый номер устанавливается равным полученному значению подтверждения, т.е. A+1, а номер подтверждения устанавливается равным на единицу большему, чем принятый порядковый номер, т.е. B+1.

Шаги 1 и 2 устанавливают и подтверждают порядковый номер для одного направления (от клиента к серверу). Шаги 2 и 3 устанавливают и подтверждают порядковый номер для другого направления (от сервера к клиенту). После завершения этих шагов и клиент, и сервер получили подтверждения и установилась полнодуплексная связь.

Прекращение соединения

Прекращение соединения

Подробная диаграмма последовательности TCP close()

На этапе завершения соединения используется четырехстороннее рукопожатие, при этом каждая сторона соединения завершается независимо. Когда конечная точка желает прекратить свою половину соединения, она передает пакет FIN, который другой конец подтверждает подтверждением ACK. Таким образом, для типичного отключения требуется пара сегментов FIN и ACK от каждой конечной точки TCP. После того, как сторона, отправившая первый FIN, ответила окончательным подтверждением ACK, она ждет тайм-аут, прежде чем окончательно закрыть соединение, в течение которого локальный порт недоступен для новых соединений; это состояние позволяет TCP-клиенту повторно отправить окончательное подтверждение на сервер в случае потери ACK при передаче. Продолжительность времени зависит от реализации, но некоторые общие значения составляют 30 секунд, 1 минуту и ​​2 минуты. По истечении таймаута клиент переходит в состояние ЗАКРЫТО и локальный порт становится доступен для новых подключений.

Также возможно разорвать соединение с помощью трехстороннего рукопожатия, когда хост A отправляет FIN, хост B отвечает FIN и ACK (объединяя два шага в один), а хост A отвечает ACK.

Некоторые операционные системы, такие как Linux и HP-UX , реализовать полудуплексную последовательность закрытия. Если хост активно закрывает соединение, хотя все еще имеет доступные непрочитанные входящие данные, хост отправляет сигнал RST (теряя все полученные данные) вместо FIN. Это гарантирует, что приложение TCP знает о потере данных.

Соединение может находиться в полуоткрытом состоянии, и в этом случае одна сторона разорвала соединение, а другая — нет. Сторона, которая завершила соединение, больше не может отправлять какие-либо данные в соединение, а другая сторона может. Завершающая сторона должна продолжать чтение данных до тех пор, пока другая сторона также не завершится.

Использование ресурсов

В большинстве реализаций в таблице выделяется запись, которая сопоставляет сеанс с запущенным процессом операционной системы. Поскольку пакеты TCP не содержат идентификатор сеанса, обе конечные точки идентифицируют сеанс, используя адрес и порт клиента. Всякий раз при получении пакета реализация TCP должна выполнить поиск в этой таблице, чтобы найти процесс назначения. Каждая запись в таблице известна как блок управления передачей или TCB. Он содержит информацию о конечных точках (IP и порт), состоянии соединения, текущих данных о пакетах, которыми обмениваются, и буферах для отправки и получения данных.

Количество сеансов на стороне сервера ограничено только объемом памяти и может увеличиваться по мере поступления новых подключений, но клиент должен выделить временный порт перед отправкой первого SYN на сервер. Этот порт остается выделенным на протяжении всего разговора и эффективно ограничивает количество исходящих подключений с каждого IP-адреса клиента. Если приложению не удается должным образом закрыть ненужные соединения, у клиента могут исчерпаться ресурсы и он не сможет устанавливать новые TCP-соединения даже из других приложений.

Обе конечные точки также должны выделить пространство для неподтвержденных пакетов и полученных (но непрочитанных) данных.

Передача данных

Протокол управления передачей отличается от протокола пользовательских дейтаграмм несколькими ключевыми особенностями :

• Упорядоченная передача данных: хост назначения переупорядочивает сегменты в соответствии с порядковым номером.
• Повторная передача потерянных пакетов: любой неподтвержденный совокупный поток передается повторно.
• Передача данных без ошибок: поврежденные пакеты считаются потерянными и передаются повторно.
• Управление потоком: ограничивает скорость передачи данных отправителем, чтобы гарантировать надежную доставку. Получатель постоянно намекает отправителю, какой объем данных можно получить. Когда буфер принимающего хоста заполняется, следующее подтверждение приостанавливает передачу и позволяет обработать данные в буфере.
• Контроль перегрузки: потеря пакетов (предположительно из-за перегрузки) приводит к снижению скорости доставки данных.

Надежная передача

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

Подтверждения (ACK) отправляются получателем данных с порядковым номером, чтобы сообщить отправителю, что данные были получены в указанном байте. ACK не означают, что данные были доставлены приложению, они просто означают, что теперь ответственность за доставку данных лежит на получателе.

Надежность достигается за счет того, что отправитель обнаруживает потерянные данные и повторно передает их. TCP использует два основных метода для выявления потерь. Тайм-аут повторной передачи (RTO) и повторяющиеся совокупные подтверждения (DupAcks).

При повторной передаче сегмента TCP он сохраняет тот же порядковый номер, что и исходная попытка доставки. Такое объединение доставки и логического порядка данных означает, что, когда подтверждение получено после повторной передачи, отправитель не может определить, подтверждается ли исходная передача или повторная передача, так называемая неоднозначность повторной передачи . TCP усложняется из-за неоднозначности повторной передачи.

Ретрансляция на основе Dupack

Если один сегмент (скажем, номер сегмента 100) в потоке потерян, то получатель не может подтвердить пакеты, превышающие этот номер сегмента (100), поскольку он использует накопительные подтверждения. Следовательно, получатель снова подтверждает пакет 99 при получении другого пакета данных. Это дублированное подтверждение используется как сигнал потери пакета. То есть, если отправитель получает три повторяющихся подтверждения, он повторно передает последний неподтвержденный пакет. Используется пороговое значение, равное трем, поскольку сеть может изменить порядок сегментов, что приведет к дублированию подтверждений. Было продемонстрировано, что этот порог позволяет избежать ложных повторных передач из-за изменения порядка. Некоторые реализации TCP используют выборочные подтверждения (SACK) для предоставления явной обратной связи о полученных сегментах. Это значительно улучшает способность TCP повторно передавать нужные сегменты.

Неоднозначность повторной передачи может привести к ложным быстрым повторным передачам и предотвращению перегрузки, если переупорядочение выходит за пределы порога дублированного подтверждения. За последние два десятилетия в Интернете наблюдалось все больше переупорядочивания пакетов. что привело к тому, что реализации TCP, такие как реализация в ядре Linux, приняли эвристические методы для масштабирования порога дублированного подтверждения. В последнее время были предприняты попытки полностью отказаться от быстрых повторных передач на основе dupack и заменить их на системы, основанные на таймере. (Не путать с классическим RTO, обсуждаемым ниже). Алгоритм обнаружения потерь по времени, называемый недавним подтверждением (RACK). был принят в качестве алгоритма по умолчанию в Linux и Windows.

Повторная передача по тайм-ауту

Когда отправитель передает сегмент, он инициализирует таймер с консервативной оценкой времени прибытия подтверждения. Сегмент передается повторно, если время таймера истекает, с новым пороговым значением тайм-аута, в два раза превышающим предыдущее значение, что приводит к экспоненциальной отсрочке передачи . Обычно начальное значение таймера равно ${\text{smoothed RTT}}+\max(G,4\times {\text{RTT variation}})$, где $G$ это степень детализации часов. Это защищает от чрезмерного трафика передачи из-за неисправных или злоумышленников, таких как злоумышленники, осуществляющие отказ в обслуживании .

Точные оценки RTT важны для восстановления потерь, поскольку они позволяют отправителю предположить, что неподтвержденный пакет будет потерян по истечении достаточного времени (т. е. определения времени RTO). Неоднозначность повторной передачи может привести к тому, что оценка RTT отправителем будет неточной. В среде с переменными значениями RTT могут возникать ложные тайм-ауты: если значение RTT занижено, то RTO срабатывает и запускает ненужную повторную передачу и медленный старт. После ложной повторной передачи, когда приходят подтверждения исходной передачи, отправитель может полагать, что он подтверждает повторную передачу, и ошибочно заключить, что сегменты, отправленные между исходной передачей и повторной передачей, были потеряны, что приводит к дальнейшим ненужным повторным передачам до такой степени, что канал действительно становится перегруженным; выборочное подтверждение может уменьшить этот эффект. RFC 6298 указывает, что реализации не должны использовать повторно передаваемые сегменты при оценке RTT. Алгоритм Карна гарантирует, что в конечном итоге будет получена хорошая оценка RTT, ожидая однозначного подтверждения перед корректировкой RTO. Однако после ложных повторных передач может пройти значительное время, прежде чем придет такое однозначное подтверждение, что тем самым снижает производительность. Временные метки TCP также решают проблему неоднозначности повторной передачи при настройке RTO. хотя они не обязательно улучшают оценку RTT.

Обнаружение ошибок

Порядковые номера позволяют получателям отбрасывать повторяющиеся пакеты и правильно упорядочивать пакеты, нарушающие порядок. Подтверждения позволяют отправителям определить, когда следует повторно передать потерянные пакеты.

Для обеспечения правильности включено поле контрольной суммы; см . в § Вычисление контрольной суммы подробности . Контрольная сумма TCP является слабой проверкой по современным стандартам и обычно сочетается с CRC проверкой целостности на уровне 2 , ниже TCP и IP, например, который используется в PPP или кадре Ethernet . Однако появление ошибок в пакетах между узлами, защищенными CRC, является обычным явлением, и 16-битная контрольная сумма TCP улавливает большинство из них.

Управление потоком

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

TCP использует протокол управления потоком скользящего окна . В каждом сегменте TCP получатель указывает в поле окна приема объем дополнительно полученных данных (в байтах), которые он готов буферизовать для соединения. Отправляющий узел может отправлять только этот объем данных, прежде чем ему придется дождаться подтверждения и получить обновление окна от принимающего узла.

Порядковые номера TCP и окна приема ведут себя очень похоже на часы. Окно приема смещается каждый раз, когда получатель получает и подтверждает новый сегмент данных. Как только порядковые номера исчерпаются, порядковый номер возвращается к 0.

Когда получатель объявляет размер окна равный 0, отправитель прекращает отправку данных и запускает таймер сохранения . Таймер сохранения используется для защиты TCP от ситуации взаимоблокировки , которая может возникнуть, если последующее обновление размера окна от получателя потеряно, и отправитель не сможет отправить больше данных до тех пор, пока не получит новое обновление размера окна от получателя. По истечении времени таймера сохранения отправитель TCP пытается восстановиться, отправляя небольшой пакет, а получатель в ответ отправляет еще одно подтверждение, содержащее новый размер окна.

Если получатель обрабатывает входящие данные небольшими порциями, он может неоднократно объявлять небольшое окно приема. Это называется синдромом глупого окна , поскольку неэффективно отправлять только несколько байтов данных в сегменте TCP, учитывая относительно большие накладные расходы заголовка TCP.

Контроль перегрузок

Основная статья: Контроль перегрузки TCP

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

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

Современные реализации TCP содержат четыре переплетенных алгоритма: медленный старт , предотвращение перегрузки , быстрая повторная передача и быстрое восстановление .

Кроме того, отправители используют тайм-аут повторной передачи (RTO), который основан на расчетном времени прохождения туда и обратно (RTT) между отправителем и получателем, а также на разнице этого времени прохождения туда и обратно. Есть тонкости в оценке RTT. Например, отправители должны быть осторожны при вычислении выборок RTT для повторно передаваемых пакетов; обычно они используют алгоритм Карна или временные метки TCP. Эти отдельные выборки RTT затем усредняются по времени для создания сглаженного времени прохождения туда и обратно (SRTT) с использованием алгоритма Джейкобсона . Это значение SRTT используется в качестве оценки времени прохождения туда и обратно.

Улучшение TCP для надежной обработки потерь, минимизации ошибок, управления перегрузками и быстрой работы в очень высокоскоростных средах — это постоянные области исследований и разработки стандартов. В результате существует ряд вариантов алгоритма предотвращения перегрузки TCP .

Максимальный размер сегмента

Максимальный размер сегмента (MSS) — это наибольший объем данных, указанный в байтах, который TCP готов получить в одном сегменте. Для достижения наилучшей производительности MSS должен быть установлен достаточно маленьким, чтобы избежать фрагментации IP , которая может привести к потере пакетов и чрезмерным повторным передачам. Для этого каждая сторона обычно объявляет MSS с использованием опции MSS при установке TCP-соединения. Значение параметра выводится из максимального размера единицы передачи (MTU) уровня канала передачи данных сетей, к которым напрямую подключены отправитель и получатель. Отправители TCP могут использовать обнаружение MTU пути , чтобы определить минимальный MTU на сетевом пути между отправителем и получателем и использовать его для динамической настройки MSS, чтобы избежать фрагментации IP внутри сети.

Объявление MSS также можно назвать согласованием MSS, но, строго говоря, MSS не согласовывается . Для двух направлений потока данных в TCP-соединении разрешены два полностью независимых значения MSS. поэтому нет необходимости согласовывать общую конфигурацию MSS для двунаправленного соединения.

Выборочные благодарности

См. Также: SACK Panic

Если полагаться исключительно на схему кумулятивного подтверждения, используемую исходным TCP, это может привести к неэффективности при потере пакетов. Например, предположим, что байты с порядковыми номерами от 1000 до 10999 отправляются в 10 различных сегментах TCP одинакового размера, а второй сегмент (порядковые номера от 2000 до 2999) теряется во время передачи. В протоколе чистого кумулятивного подтверждения получатель может отправить только совокупное значение ACK, равное 2000 (порядковый номер, следующий сразу за последним порядковым номером полученных данных), и не может сказать, что он успешно получил байты с 3000 по 10999. Таким образом, отправителю, возможно, придется повторно отправить все данные, начиная с порядкового номера 2000.

Чтобы решить эту проблему, TCP использует опцию выборочного подтверждения (SACK) , определенную в 1996 году в RFC 2018 , которая позволяет получателю подтверждать прерывистые блоки пакетов, которые были получены правильно, в дополнение к порядковому номеру, следующему сразу за последним порядковым номером пакета. последний непрерывный байт получен последовательно, как и в базовом подтверждении TCP. Подтверждение может включать в себя несколько блоков SACK , где каждый блок SACK передается по левому краю блока (первый порядковый номер блока) и правом краю блока (порядковый номер, следующий сразу за последним порядковым номером блока). ), где Блок представляет собой непрерывный диапазон, который получатель правильно принял. В приведенном выше примере получатель отправит сегмент ACK с совокупным значением ACK 2000 и заголовком опции SACK с порядковыми номерами 3000 и 11000. Соответственно, отправитель будет повторно передавать только второй сегмент с порядковыми номерами от 2000 до 2999.

Отправитель TCP может интерпретировать доставку сегмента с нарушением порядка как потерянный сегмент. Если это произойдет, отправитель TCP повторно передаст сегмент, предшествующий пакету с нарушением порядка, и замедлит скорость доставки данных для этого соединения. Опция дублирования SACK, расширение опции SACK, определенной в мае 2000 года в RFC 2883 , решает эту проблему. Получатель TCP отправляет D-ACK, чтобы указать, что ни один сегмент не был потерян, и отправитель TCP может затем восстановить более высокую скорость передачи.

Опция SACK не является обязательной и вступает в силу только в том случае, если обе стороны ее поддерживают. Это согласовывается при установке соединения. SACK использует опцию заголовка TCP ( см. § Структура сегмента TCP подробнее ). Использование SACK получило широкое распространение — его поддерживают все популярные стеки TCP. Выборочное подтверждение также используется в протоколе передачи управления потоком (SCTP).

Выборочные подтверждения могут быть «отменены», когда получатель в одностороннем порядке отбрасывает выборочно подтвержденные данные. RFC 2018 не одобрял такое поведение, но не запрещал давать получателям возможность отказаться, если у них, например, закончилось буферное пространство. Возможность отказа приводит к сложности реализации как для отправителей, так и для получателей, а также требует от отправителя затрат памяти.

Масштабирование окна

Основная статья: Опция масштабирования окна TCP

Для более эффективного использования сетей с высокой пропускной способностью можно использовать больший размер окна TCP. 16-битное поле размера окна TCP управляет потоком данных, и его значение ограничено 65 535 байтами. Поскольку поле размера не может быть расширено за пределы этого предела, используется коэффициент масштабирования. Опция масштабирования окна TCP , определенная в RFC 1323 , — это опция, используемая для увеличения максимального размера окна до 1 гигабайта. Масштабирование до этих больших размеров окна необходимо для настройки TCP .

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

Некоторые маршрутизаторы и пакетные межсетевые экраны переписывают коэффициент масштабирования окна во время передачи. Это приводит к тому, что отправляющая и принимающая стороны принимают разные размеры окна TCP. В результате получается нестабильный трафик, который может быть очень медленным. Проблема видна на некоторых сайтах за неисправным роутером.

Временные метки TCP

Временные метки TCP, определенные в RFC 1323 в 1992 году, могут помочь TCP определить, в каком порядке были отправлены пакеты. Временные метки TCP обычно не привязаны к системным часам и начинаются с некоторого случайного значения. Многие операционные системы увеличивают временную метку каждую прошедшую миллисекунду; однако в RFC указано только, что отметки должны быть пропорциональными.

Есть два поля временных меток:

• 4-байтовое значение отметки времени отправителя (моя отметка времени)
• 4-байтовое значение временной метки эхо-ответа (самая последняя полученная от вас временная метка).

Временные метки TCP используются в алгоритме, известном как защита от завернутых порядковых номеров или PAWS . PAWS используется, когда окно приема пересекает границу переноса порядкового номера. В случае, когда пакет потенциально был передан повторно, он отвечает на вопрос: «Этот порядковый номер находится в первых 4 ГБ или во вторых?» И временная метка используется для разрыва связи.

Кроме того, алгоритм обнаружения Eifel использует временные метки TCP, чтобы определить, происходят ли повторные передачи из-за того, что пакеты потеряны или просто вышли из строя.

Временные метки TCP включены по умолчанию в Linux. и отключен по умолчанию в Windows Server 2008, 2012 и 2016.

Недавняя статистика показывает, что уровень внедрения меток времени TCP остался на прежнем уровне (около 40%) из-за прекращения поддержки Windows Server с момента выпуска Windows Server 2008.

Внеполосные данные

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

Указатель срочности изменяет только обработку на удаленном хосте и не ускоряет обработку в самой сети. Эта возможность реализована по-разному или плохо в разных системах или может не поддерживаться. Там, где это возможно, разумно предположить, что будут надежно обрабатываться только отдельные байты данных OOB. Поскольку эта функция используется нечасто, она недостаточно протестирована на некоторых платформах и связана с уязвимостями , WinNuke например .

Принудительная доставка данных

Обычно TCP ожидает отправки полного пакета данных в течение 200 мс ( алгоритм Нэгла пытается сгруппировать небольшие сообщения в один пакет). Такое ожидание создает небольшие, но потенциально серьезные задержки, если оно повторяется постоянно во время передачи файла. Например, типичный блок отправки будет иметь размер 4 КБ, типичный MSS — 1460, поэтому 2 пакета отправляются по Ethernet со скоростью 10 Мбит / с, занимая ~ 1,2 мс каждый, а затем третий передает оставшиеся 1176 после паузы в 197 мс, потому что TCP ожидает полного буфера. В случае telnet каждое нажатие клавиши пользователя отражается сервером до того, как пользователь увидит его на экране. Эта задержка будет очень раздражать.

Установка сокета опции TCP_NODELAY переопределяет задержку отправки по умолчанию в 200 мс. Прикладные программы используют эту опцию сокета, чтобы принудительно отправить вывод после записи символа или строки символов.

RFC определяет PSH push-бит как «сообщение принимающему стеку TCP о необходимости немедленной отправки этих данных принимающему приложению». Невозможно указать или контролировать его в пользовательском пространстве с помощью сокетов Беркли ; он контролируется только стеком протоколов .

Уязвимости

TCP может быть атакован различными способами. Результаты тщательной оценки безопасности TCP, а также возможные способы устранения выявленных проблем были опубликованы в 2009 году. и продолжалась в IETF до 2012 года. Известные уязвимости включают отказ в обслуживании, перехват соединения, вето TCP и атаку сброса TCP .

Отказ в обслуживании

Используя поддельный IP-адрес и неоднократно отправляя специально собранные пакеты SYN, за которыми следует множество пакетов ACK, злоумышленники могут заставить сервер потреблять большое количество ресурсов для отслеживания фиктивных соединений. Это известно как SYN-флуд -атака. Предлагаемые решения этой проблемы включают файлы cookie SYN и криптографические головоломки, хотя файлы cookie SYN имеют свой собственный набор уязвимостей. Sockstress — аналогичная атака, которую можно смягчить с помощью управления системными ресурсами. Сложная DoS-атака, включающая использование таймера сохранения TCP, была проанализирована во Phrack № 66. PUSH и ACK-флуды . Другими вариантами являются

Перехват соединения

Основная статья: Атака с предсказанием последовательности TCP

Злоумышленник, который может подслушать сеанс TCP и перенаправить пакеты, может перехватить TCP-соединение. Для этого злоумышленник узнает порядковый номер из текущего обмена данными и создает ложный сегмент, который выглядит как следующий сегмент в потоке. Простой захват может привести к тому, что один пакет будет ошибочно принят на одном конце. Когда принимающий хост подтверждает ложный сегмент, синхронизация теряется. Перехват может сочетаться с подменой ARP или другими атаками на маршрутизацию, которые позволяют злоумышленнику получить постоянный контроль над TCP-соединением.

До RFC 1948 , когда исходный порядковый номер можно было легко угадать, выдать себя за другой IP-адрес не было сложно. Более ранние реализации позволяли злоумышленнику слепо отправлять последовательность пакетов, которые, по мнению получателя, пришли с другого IP-адреса, без необходимости перехвата связи через ARP или атаки маршрутизации: достаточно убедиться, что законный хост с выдающимся IP-адресом адрес не работает, или доведите его до этого состояния с помощью атак типа «отказ в обслуживании» . Вот почему начальный порядковый номер теперь выбирается случайным образом.

TCP вето

Злоумышленник, который может подслушать и предсказать размер следующего пакета, который будет отправлен, может заставить получателя принять вредоносную полезную нагрузку, не нарушая существующее соединение. Злоумышленник внедряет вредоносный пакет с порядковым номером и размером полезной нагрузки следующего ожидаемого пакета. Когда законный пакет в конечном итоге получен, обнаруживается, что он имеет тот же порядковый номер и длину, что и уже полученный пакет, и автоматически отбрасывается, как обычный дубликат пакета - злонамеренный пакет накладывает вето на законный пакет. В отличие от перехвата соединения, соединение никогда не десинхронизируется, и связь продолжается в обычном режиме после принятия вредоносной полезной нагрузки. TCP-вето дает злоумышленнику меньший контроль над связью, но делает атаку особенно устойчивой к обнаружению. Единственным доказательством для получателя того, что что-то не так, является один дублирующийся пакет, что является обычным явлением в IP-сети. Отправитель пакета, на который наложено вето, никогда не видит никаких доказательств атаки.

TCP-порты

См. также: Список номеров портов TCP и UDP.

TCP-соединение идентифицируется четырьмя кортежами: адрес источника, порт источника , адрес назначения и порт назначения. Номера портов используются для идентификации различных служб и для разрешения нескольких соединений между хостами. TCP использует 16-битные номера портов, предоставляя 65 536 возможных значений для каждого порта источника и назначения. Зависимость идентификатора соединения от адресов означает, что TCP-соединения привязаны к одному сетевому пути; TCP не может использовать другие маршруты, доступные многосетевым узлам , и соединения разрываются при изменении адреса конечной точки.

Номера портов делятся на три основные категории: общеизвестные, зарегистрированные и динамические или частные. Хорошо известные порты назначаются Управлением по присвоению номеров Интернета (IANA) и обычно используются процессами системного уровня. Эти порты обычно используются хорошо известными приложениями, работающими как серверы и пассивно прослушивающими соединения. Некоторые примеры включают: FTP (20 и 21), SSH (22), TELNET (23), SMTP (25), HTTP через SSL/TLS (443) и HTTP (80). Зарегистрированные порты обычно используются приложениями конечных пользователей в качестве временных исходных портов при обращении к серверам, но они также могут идентифицировать именованные службы, зарегистрированные третьей стороной. Динамические или частные порты также могут использоваться приложениями конечных пользователей, однако эти порты обычно не несут никакого значения за пределами конкретного TCP-соединения.

Трансляция сетевых адресов (NAT) обычно использует динамические номера портов на общедоступной стороне, чтобы устранить неоднозначность потока трафика, проходящего между общедоступной сетью и частной подсетью , тем самым позволяя использовать множество IP-адресов (и их портов) в одной сети. подсеть, которая будет обслуживаться одним общедоступным адресом.

Разработка

TCP — сложный протокол. Однако, несмотря на то, что за прошедшие годы были сделаны и предложены значительные улучшения, его основные операции существенно не изменились со времени его первой спецификации RFC 675 в 1974 году и спецификации v4 RFC 793 , опубликованной в сентябре 1981 года. RFC 1122 , опубликованной в октябре 1989 года. , уточнил ряд требований к реализации протокола TCP. Список из 8 обязательных спецификаций и более 20 настоятельно рекомендуемых улучшений доступен в RFC 7414 . В этом списке есть RFC 2581 , TCP Congestion Control, один из наиболее важных RFC, связанных с TCP, за последние годы, описывающий обновленные алгоритмы, позволяющие избежать ненужной перегрузки. В 2001 году RFC 3168 был написан для описания явного уведомления о перегрузке (ECN), механизма сигнализации предотвращения перегрузки.

Исходный алгоритм предотвращения перегрузки TCP был известен как TCP Tahoe , но с тех пор было предложено множество альтернативных алгоритмов (включая TCP Reno , TCP Vegas , FAST TCP , TCP New Reno и TCP Hybla ).

Многопутевой TCP (MPTCP) — это постоянная работа в рамках IETF, направленная на то, чтобы разрешить TCP-соединению использовать несколько путей для максимального использования ресурсов и повышения избыточности. Избыточность, обеспечиваемая Multipath TCP в контексте беспроводных сетей, позволяет одновременно использовать разные сети, что обеспечивает более высокую пропускную способность и лучшие возможности передачи обслуживания. Multipath TCP также обеспечивает повышение производительности в средах центров обработки данных. Эталонная реализация Multipath TCP был разработан в ядре Linux. Multipath TCP используется для поддержки приложения распознавания голоса Siri на iPhone, iPad и Mac.

tcpcrypt — это расширение, предложенное в июле 2010 года для обеспечения шифрования транспортного уровня непосредственно в самом TCP. Он предназначен для прозрачной работы и не требует какой-либо настройки. В отличие от TLS (SSL), tcpcrypt сам по себе не обеспечивает аутентификацию, но предоставляет для этого приложению простые примитивы. RFC tcpcrypt был опубликован IETF в мае 2019 года.

TCP Fast Open — это расширение, позволяющее ускорить открытие последовательных TCP-соединений между двумя конечными точками. Он работает, пропуская трехстороннее рукопожатие с использованием криптографического файла cookie . Оно похоже на более раннее предложение под названием T/TCP , которое не получило широкого распространения из-за проблем безопасности. TCP Fast Open был опубликован как RFC 7413 в 2014 году.

(PRR), предложенное в мае 2013 года, Пропорциональное снижение скорости представляет собой расширение TCP, разработанное инженерами Google. PRR гарантирует, что размер окна TCP после восстановления будет как медленного запуска . можно ближе к порогу Алгоритм предназначен для повышения скорости восстановления и является алгоритмом управления перегрузкой по умолчанию в ядрах Linux 3.2+.

Устаревшие предложения

TCP Cookie Transactions (TCPCT) — это расширение, предложенное в декабре 2009 г. для защиты серверов от атак типа «отказ в обслуживании». В отличие от файлов cookie SYN, TCPCT не конфликтует с другими расширениями TCP, такими как масштабирование окон . TCPCT был разработан в связи с необходимостью DNSSEC , где серверам приходится обрабатывать большое количество кратковременных TCP-соединений. В 2016 году TCPCT был отменен в пользу TCP Fast Open. Статус исходного RFC был изменен на исторический .

Аппаратные реализации

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

Проволочное изображение и окостенение

Проводные данные TCP предоставляют наблюдателям на пути значительные возможности по сбору и модификации информации, поскольку метаданные протокола передаются в открытом виде . Хотя эта прозрачность полезна для сетевых операторов и исследователи, информация, полученная из метаданных протокола, может снизить конфиденциальность конечного пользователя. Эта видимость и гибкость метаданных привели к тому, что TCP стало трудно расширять (случай окостенения протокола ), поскольку любой промежуточный узел (« промежуточный блок ») может принимать решения на основе этих метаданных или даже изменять их. нарушение сквозного принципа . Одно измерение показало, что треть путей в Интернете сталкивается как минимум с одним посредником, который изменяет метаданные TCP, а 6,5% путей сталкиваются с вредным закостенелющим воздействием со стороны посредников. Избегание угроз расширяемости со стороны посредников наложило значительные ограничения на разработку MPTCP . а трудности, вызванные посредниками, препятствовали внедрению TCP Fast Open в веб-браузерах . Другим источником закостенения является сложность модификации функций TCP на конечных точках, обычно в ядре операционной системы. или аппаратно с механизмом разгрузки TCP .

Производительность

Поскольку TCP предоставляет приложениям абстракцию надежного байтового потока , он может страдать от блокировки начала строки : если пакеты переупорядочиваются или теряются и их необходимо повторно передать (и, следовательно, переупорядочить), данные из последовательно последующих частей потока может быть получен перед последовательно более ранними частями потока; однако более поздние данные обычно не могут быть использованы до тех пор, пока не будут получены более ранние данные, что приводит к задержке в сети . Если несколько независимых сообщений более высокого уровня инкапсулируются и мультиплексируются в одном TCP-соединении, то блокировка начала строки может привести к тому, что полностью полученное сообщение, отправленное позже, будет обрабатываться в ожидании доставки сообщения, отправленного ранее. Веб-браузеры пытаются смягчить блокировку начала строки, открывая несколько параллельных соединений. Это влечет за собой постоянные затраты на установление соединения, а также увеличение ресурсов, необходимых для отслеживания этих соединений в конечных точках. Параллельные соединения также имеют контроль перегрузки, работающий независимо друг от друга, вместо того, чтобы объединять информацию и более оперативно реагировать на наблюдаемые условия сети; Агрессивные шаблоны начальной отправки TCP могут вызвать перегрузку, если открыто несколько параллельных соединений; а модель справедливости для каждого соединения приводит к монополизации ресурсов приложениями, использующими этот подход.

Установление соединения является основным фактором задержки, с которым сталкиваются веб-пользователи. Трехстороннее рукопожатие TCP вводит задержку в один RTT во время установления соединения, прежде чем данные могут быть отправлены. Для коротких потоков эти задержки очень значительны. Transport Layer Security (TLS) требует собственного подтверждения для обмена ключами при установлении соединения. Из-за многоуровневой конструкции подтверждение TCP и подтверждение TLS выполняются последовательно: подтверждение TLS не может начаться до тех пор, пока не завершится подтверждение TCP. через TCP требуются два RTT Для установления соединения с TLS 1.3 . TLS 1.3 в некоторых случаях допускает возобновление соединения без RTT, но при наложении на TCP один RTT по-прежнему требуется для подтверждения TCP, и это не может способствовать первоначальному соединению; Нулевые рукопожатия RTT также создают криптографические проблемы, поскольку эффективный, безопасный для воспроизведения и прямой безопасный неинтерактивный обмен ключами является открытой темой исследований. TCP Fast Open позволяет передавать данные в начальных (т. е. SYN и SYN-ACK) пакетах, устраняя задержку на один RTT во время установления соединения. Однако TCP Fast Open было сложно развернуть из-за окостенения протокола; в 2020 году ни один веб-браузер не использовал его по умолчанию.

На пропускную способность TCP влияет переупорядочение пакетов . Переупорядоченные пакеты могут привести к отправке дублирующих подтверждений, которые, если они превысят пороговое значение, затем вызовут ложную повторную передачу и контроль перегрузки. Поведение передачи также может стать менее плавным и более прерывистым, поскольку большие диапазоны подтверждаются сразу при получении переупорядоченного пакета в начале диапазона (аналогично тому, как блокировка начала строки влияет на приложения). Блэнтон и Оллман (2002) обнаружили, что пропускная способность обратно пропорциональна количеству переупорядочивания, вплоть до предела, при котором любое переупорядочение вызывает ложную повторную передачу. Смягчение переупорядочения зависит от способности отправителя определить, что он отправил ложную повторную передачу, и, следовательно, от разрешения неоднозначности повторной передачи. Уменьшение количества ложных повторных передач, вызванных переупорядочением, идет вразрез с быстрым восстановлением после реальных потерь.

Выборочное подтверждение может существенно повысить пропускную способность; Bruyeron, Hemon & Zhang (1998) зафиксировали прирост до 45%. Важным фактором улучшения является то, что выборочное подтверждение позволяет чаще избегать медленного старта после потери и, следовательно, может лучше использовать доступную полосу пропускания. Однако TCP может выборочно подтвердить максимум три блока порядковых номеров. Это может ограничить скорость повторной передачи и, следовательно, восстановление потерь или вызвать ненужные повторные передачи, особенно в средах с высокими потерями.

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

ряд альтернативных алгоритмов контроля перегрузки, таких как Vegas , Westwood , Veno и Santa Cruz. Для решения проблемы беспроводной связи был предложен

Ускорение

Идея TCP-ускорителя состоит в том, чтобы завершить TCP-соединения внутри сетевого процессора и затем передать данные на второе соединение к конечной системе. Пакеты данных, исходящие от отправителя, буферизуются на узле-ускорителе, который отвечает за выполнение локальной повторной передачи в случае потери пакета. Таким образом, в случае потерь контур обратной связи между отправителем и получателем сокращается до контура между узлом ускорения и получателем, что гарантирует более быструю доставку данных получателю.

Поскольку TCP является протоколом, адаптирующимся к скорости, скорость, с которой отправитель TCP вводит пакеты в сеть, прямо пропорциональна преобладающему состоянию нагрузки в сети, а также вычислительной мощности получателя. О преобладающих условиях в сети отправитель судит на основании полученных им подтверждений. Узел ускорения разделяет контур обратной связи между отправителем и получателем и, таким образом, гарантирует более короткое время прохождения туда и обратно (RTT) для каждого пакета. Более короткий RTT выгоден, поскольку обеспечивает более быстрое время реакции на любые изменения в сети и более быструю адаптацию отправителя для борьбы с этими изменениями.

К недостаткам метода можно отнести тот факт, что TCP-сессия должна проходить через ускоритель; это означает, что если маршрутизация изменится и ускорителя больше не будет на пути, соединение будет разорвано. Это также разрушает сквозное свойство механизма подтверждения TCP; когда подтверждение получено отправителем, пакет был сохранен ускорителем, а не доставлен получателю.

Отладка

Анализатор пакетов , который перехватывает TCP-трафик по сетевому каналу, может быть полезен при отладке сетей, сетевых стеков и приложений, использующих TCP, показывая пользователю, какие пакеты проходят по каналу. Некоторые сетевые стеки поддерживают опцию сокета SO_DEBUG, которую можно включить в сокете с помощью setsockopt. Эта опция сбрасывает все пакеты, состояния TCP и события в этом сокете, что полезно при отладке. Netstat — еще одна утилита, которую можно использовать для отладки.

Альтернативы

Для многих приложений TCP не подходит. Одна из проблем (по крайней мере, в обычных реализациях) заключается в том, что приложение не может получить доступ к пакетам, идущим после потерянного пакета, до тех пор, пока не будет получена повторно переданная копия потерянного пакета. Это вызывает проблемы для приложений реального времени, таких как потоковое мультимедиа, многопользовательские игры в реальном времени и передача голоса по IP (VoIP), где обычно полезнее получать большую часть данных своевременно, чем получать все данные. чтобы.

По историческим причинам и из соображений производительности большинство сетей хранения данных (SAN) используют протокол Fibre Channel (FCP) поверх соединений Fibre Channel .

Кроме того, для встроенных систем , сетевой загрузки и серверов, которые обслуживают простые запросы от огромного количества клиентов (например, DNS- серверов), сложность TCP может стать проблемой. Наконец, некоторые трюки, такие как передача данных между двумя хостами, которые оба находятся за NAT (с использованием STUN или аналогичных систем), намного проще без использования относительно сложного протокола, такого как TCP.

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

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

Транспортный протокол Вентури (VTP) — это запатентованный собственный протокол , который предназначен для прозрачной замены TCP и устранения предполагаемой неэффективности, связанной с беспроводной передачей данных.

TCP также имеет проблемы в средах с высокой пропускной способностью. Алгоритм предотвращения перегрузки TCP очень хорошо работает в специальных средах, где отправитель данных заранее неизвестен. Если среда предсказуема, протокол на основе синхронизации, такой как асинхронный режим передачи (ATM), может избежать накладных расходов на повторную передачу TCP.

Протокол передачи данных (UDT) на основе UDP имеет более высокую эффективность и справедливость, чем TCP, в сетях с высокой задержкой полосы пропускания .

Многоцелевой протокол транзакций (MTP/IP) — это запатентованное программное обеспечение, предназначенное для адаптивного достижения высокой пропускной способности и производительности транзакций в самых разных сетевых условиях, особенно в тех, где TCP считается неэффективным.

Вычисление контрольной суммы

Контрольная сумма TCP для IPv4

Когда TCP работает через IPv4 , метод, используемый для вычисления контрольной суммы, определяется следующим образом:

Поле контрольной суммы представляет собой 16-битное дополнение суммы всех 16-битных слов в заголовке и тексте. Вычисление контрольной суммы должно гарантировать 16-битное выравнивание суммируемых данных. Если сегмент содержит нечетное количество октетов заголовка и текста, выравнивания можно добиться путем дополнения последнего октета нулями справа от него, чтобы сформировать 16-битное слово для целей контрольной суммы. Контактная площадка не передается как часть сегмента. При вычислении контрольной суммы само поле контрольной суммы заменяется нулями.

Другими словами, после соответствующего заполнения все 16-битные слова добавляются с использованием арифметики дополнения до единиц . Затем сумма побитово дополняется и вставляется в качестве поля контрольной суммы. Псевдозаголовок, имитирующий заголовок пакета IPv4, используемый при вычислении контрольной суммы, показан в таблице ниже.

Псевдозаголовок TCP для вычисления контрольной суммы (IPv4)

Битовое смещение	0–3				4–7				8–15								16–31
0	Исходный адрес
32	Адрес назначения
64	Нули								Протокол								Длина TCP
96	Исходный порт																Порт назначения
128	Порядковый номер
160	Номер подтверждения
192	Смещение данных				Сдержанный			Флаги									Окно
224	Контрольная сумма																Срочный указатель
256	Опции (необязательно)
256/288+	Данные

Адреса источника и назначения соответствуют заголовкам IPv4. Значение протокола для TCP равно 6 (см. Список номеров протоколов IP ). Поле длины TCP — это длина заголовка TCP и данных (измеряется в октетах).

Контрольная сумма TCP для IPv6

Когда TCP работает через IPv6 , метод, используемый для вычисления контрольной суммы, изменяется:

Любой транспортный или другой протокол верхнего уровня, который включает адреса из заголовка IP в расчет контрольной суммы, должен быть изменен для использования через IPv6, чтобы включать 128-битные адреса IPv6 вместо 32-битных адресов IPv4.

Псевдозаголовок, имитирующий заголовок IPv6 для вычисления контрольной суммы, показан ниже.

Псевдозаголовок TCP для вычисления контрольной суммы (IPv6)

Битовое смещение	0–7								8–15								16–23								24–31
0	Исходный адрес
32
64
96
128	Адрес назначения
160
192
224
256	Длина TCP
288	Нули																								Следующий заголовок = Протокол
320	Исходный порт																Порт назначения
352	Порядковый номер
384	Номер подтверждения
416	Смещение данных				Сдержанный				Флаги								Окно
448	Контрольная сумма																Срочный указатель
480	Опции (необязательно)
480/512+	Данные

• Исходный адрес: тот, что в заголовке IPv6.
• Адрес назначения: конечный пункт назначения; Если пакет IPv6 не содержит заголовка маршрутизации, TCP использует адрес назначения в заголовке IPv6, в противном случае на исходном узле он использует адрес в последнем элементе заголовка маршрутизации, а на принимающем узле — использует адрес назначения в заголовке IPv6.
• Длина TCP: длина TCP-заголовка и данных.
• Следующий заголовок: значение протокола TCP.

Выгрузка контрольной суммы

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

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

См. также

• Отказоустойчивый обмен сообщениями
• Микровзрыв (сеть)
• Глобальная синхронизация TCP
• TCP-слияние
• TCP-скорость
• TCP-стелс
• Транспортный уровень § Сравнение протоколов транспортного уровня
• WTCP — модификация TCP для беспроводных сетей на основе прокси.

Библиография

Запросы на комментарии

• Серф, Винт ; Далал, Йоген ; Саншайн, Карл (декабрь 1974 г.). Спецификация программы управления передачей через Интернет, версия от декабря 1974 г. дои : 10.17487/RFC0675 . РФК 675 .
• Postel, Jon (September 1981). Internet Protocol . doi : 10.17487/RFC0791 . RFC 791 .
• Постел, Джон (сентябрь 1981 г.). Протокол управления передачей . дои : 10.17487/RFC0793 . РФК 793 .
• Брейден, Роберт , изд. (октябрь 1989 г.). Требования к интернет-хостам – коммуникационные уровни . дои : 10.17487/RFC1122 . РФК 1122 .
• Джейкобсон, Ван ; Брейден, Боб ; Борман, Дэйв (май 1992 г.). Расширения TCP для высокой производительности . дои : 10.17487/RFC1323 . РФК 1323 .
• Белловин, Стивен М. (май 1996 г.). Защита от атак по порядковому номеру . дои : 10.17487/RFC1948 . РФК 1948 года .
• Матис, Мэтт; Махдави, Джамшид; Флойд, Салли; Романов, Аллин (октябрь 1996 г.). Опции выборочного подтверждения TCP . дои : 10.17487/RFC2018 . РФК 2018 .
• Оллман, Марк; Паксон, Верн ; Стивенс, В. Ричард (апрель 1999 г.). Контроль перегрузки TCP . дои : 10.17487/RFC2581 . РФК 2581 .
• Флойд, Салли ; Махдави, Джамшид; Матис, Мэтт; Подольский, Мэтью (июль 2000 г.). Расширение опции выборочного подтверждения (SACK) для TCP . дои : 10.17487/RFC2883 . РФК 2883 .
• Рамакришнан, К.К.; Флойд, Салли ; Блэк, Дэвид (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) в IP . дои : 10.17487/RFC3168 . РФК 3168 .
• Людвиг, Райнер; Мейер, Майкл (апрель 2003 г.). Алгоритм обнаружения Эйфеля для TCP . дои : 10.17487/RFC3522 . РФК 3522 .
• Спринг, Нил; Уэзеролл, Дэвид; Эли, Дэвид (июнь 2003 г.). Надежная сигнализация явного уведомления о перегрузке (ECN) с одноразовыми номерами . дои : 10.17487/RFC3540 . РФК 3540 .
• Оллман, Марк; Паксон, Верн ; Блэнтон, Итан (сентябрь 2009 г.). Контроль перегрузки TCP . дои : 10.17487/RFC5681 . РФК 5681 .
• Симпсон, Уильям Аллен (январь 2011 г.). Транзакции TCP Cookie (TCPCT) . дои : 10.17487/RFC6013 . РФК 6013 .
• Форд, Алан; Райчу, Костин; Хэндли, Марк ; Барре, Себастьян; Айенгар, Джанардхан (март 2011 г.). Архитектурные рекомендации для разработки многопутевого TCP . дои : 10.17487/RFC6182 . РФК 6182 .
• Паксон, Верн ; Оллман, Марк; Чу, Гонконг Джерри; Сарджент, Мэтт (июнь 2011 г.). Вычисление таймера повторной передачи TCP . дои : 10.17487/RFC6298 . РФК 6298 .
• Форд, Алан; Райчу, Костин; Хэндли, Марк ; Бонавентура, Оливье (январь 2013 г.). Расширения TCP для многопутевой работы с несколькими адресами . дои : 10.17487/RFC6824 . RFC 6824 .
• Матис, Мэтт; Дуккипати, Нандита; Ченг, Ючунг (май 2013 г.). Пропорциональное снижение скорости для TCP . дои : 10.17487/RFC6937 . РФК 6937 .
• Борман, Дэвид; Брейден, Боб ; Джейкобсон, Ван (сентябрь 2014 г.). Шеффенеггер, Ричард (ред.). Расширения TCP для высокой производительности . дои : 10.17487/RFC7323 . RFC 7323 .
• Герцог, Мартин; Брейден, Роберт ; Эдди, Уэсли М.; Блэнтон, Итан; Циммерманн, Александр (февраль 2015 г.). Дорожная карта для документации по спецификациям протокола управления передачей (TCP) . дои : 10.17487/RFC7414 . РФК 7414 .
• Ченг, Ючунг; Чу, Джерри; Радхакришнан, Шивасанкар; Джайн, Арвинд (декабрь 2014 г.). TCP Быстрое открытие . дои : 10.17487/RFC7413 . РФК 7413 .
• Циммерманн, Александр; Эдди, Уэсли М.; Эггерт, Ларс (апрель 2016 г.). Перемещение устаревших расширений TCP и документов, связанных с TCP, в исторический или информационный статус . дои : 10.17487/RFC7805 . РФК 7805 .
• Фэрхерст, Горри; Траммелл, Брайан; Кюлевинд, Мирья, ред. (март 2017 г.). Услуги, предоставляемые транспортными протоколами IETF и механизмами контроля перегрузки . дои : 10.17487/RFC8095 . РФК 8095 .
• Ченг, Ючунг; Кардвелл, Нил; Дуккипати, Нандита; Джа, Прияранджан, ред. (февраль 2021 г.). Алгоритм обнаружения потерь RACK-TLP для TCP . дои : 10.17487/RFC8985 . РФК 8985 .
• Диринг, Стивен Э .; Хинден, Роберт М. (июль 2017 г.). Спецификация интернет-протокола версии 6 (IPv6) . дои : 10.17487/RFC8200 . РФК 8200 .
• Траммелл, Брайан; Кюлевинд, Мирья (апрель 2019 г.). Образ сетевого протокола . дои : 10.17487/RFC8546 . RFC 8546 .
• Харди, Тед, изд. (апрель 2019 г.). Сигналы пути транспортного протокола . дои : 10.17487/RFC8558 . RFC 8558 .
• Айенгар, Яна; Светт, Ян, ред. (май 2021 г.). Обнаружение потерь QUIC и контроль перегрузок . дои : 10.17487/RFC9002 . РФК 9002 .
• Фэрхерст, Горри; Перкинс, Колин (июль 2021 г.). Соображения относительно конфиденциальности транспортного заголовка, сетевых операций и эволюции транспортных протоколов Интернета . дои : 10.17487/RFC9065 . РФК 9065 .
• Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протоколов . дои : 10.17487/RFC9170 . РФК 9170 .
• Эдди, Уэсли М., изд. (август 2022 г.). Протокол управления передачей (TCP) . дои : 10.17487/RFC9293 . РФК 9293 .

Другие документы

• Оллман, Марк; Паксон, Верн (октябрь 1999 г.). «Об оценке свойств путей в сквозной сети» . Обзор компьютерных коммуникаций ACM SIGCOMM . 29 (4): 263–274. дои : 10.1145/316194.316230 . hdl : 2060/20000004338 .
• Бхат, Дивьяшри; Ризк, Амр; Цинк, Майкл (июнь 2017 г.). «Не так QUIC: исследование производительности DASH по сравнению с QUIC». NOSSDAV'17: Материалы 27-го семинара по поддержке сетевых и операционных систем цифрового аудио и видео . стр. 13–18. дои : 10.1145/3083165.3083175 . S2CID   32671949 .
• Блэнтон, Итан; Оллман, Марк (январь 2002 г.). «О повышении устойчивости TCP к переупорядочению пакетов» (PDF) . Обзор компьютерных коммуникаций ACM SIGCOMM . 32 : 20–30. дои : 10.1145/510726.510728 . S2CID   15305731 .
• Бриско, Боб; Брунстрем, Анна; Петлунд, Андреас; Хейс, Дэвид; Рос, Дэвид; Цанг, Инг-Джых; Йессинг, Штейн; Фэрхерст, Горри; Гриводз, Карстен; Вельцль, Майкл (2016). «Уменьшение задержки в Интернете: обзор методов и их преимуществ». Опросы и учебные пособия IEEE по коммуникациям . 18 (3): 2149–2196. дои : 10.1109/COMST.2014.2375213 . hdl : 2164/8018 . S2CID   206576469 .
• Брюерон, Рено; Хемон, Бруно; Чжан, Ликса (апрель 1998 г.). «Эксперименты с выборочным подтверждением TCP». Обзор компьютерных коммуникаций ACM SIGCOMM . 28 (2): 54–77. дои : 10.1145/279345.279350 . S2CID   15954837 .
• Чен, Шан; Джером, Сэмюэл; Ягельский, Мэтью; Болдырева Александра; Нита-Ротару, Кристина (2021). «Установление безопасного канала связи: TLS 1.3 (быстрое открытие через TCP) в сравнении с QUIC» . Журнал криптологии . 34 (3). дои : 10.1007/s00145-021-09389-w . S2CID   235174220 .
• Корбет, Джонатан (8 декабря 2015 г.). «Разгрузка контрольной суммы и окостенение протокола» . LWN.net .
• Корбет, Джонатан (29 января 2018 г.). «QUIC как решение проблемы закостенения протоколов» . LWN.net .
• Эделин, Кориан; Доннет, Бенуа (2019). Исследование окостенения транспортного слоя снизу вверх . Конференция по измерению и анализу сетевого трафика 2019 (TMA). дои : 10.23919/TMA.2019.8784690 .
• Гедини, Алессандро (26 июля 2018 г.). «Дорога к QUIC» . Облачная вспышка .
• Гуртов Андрей; Флойд, Салли (февраль 2004 г.). Разрешение неоднозначности подтверждения в TCP без SACK (PDF) . Телетрафик следующего поколения и расширенные проводные/беспроводные сети (NEW2AN'04).
• Гуртов Андрей; Людвиг, Райнер (2003). Реагирование на ложные тайм-ауты в TCP (PDF) . IEEE INFOCOM 2003. Двадцать вторая ежегодная совместная конференция обществ компьютеров и коммуникаций IEEE. дои : 10.1109/INFCOM.2003.1209251 .
• Хесманс, Бенджамин; Дюшен, Фабьен; Пааш, Кристоф; Деталь, Грегори; Бонавентура, Оливье (2013). Являются ли TCP-расширения защищенными от промежуточного блока? . ХотМиддлбокс '13. CiteSeerX   10.1.1.679.6364 . дои : 10.1145/2535828.2535830 .
• Рабочая группа IETF HTTP. «Часто задаваемые вопросы по HTTP/2» .
• Карн, Фил ; Партридж, Крейг (ноябрь 1991 г.). «Улучшение оценки времени прохождения туда и обратно в надежных транспортных протоколах» . Транзакции ACM в компьютерных системах . 9 (4): 364–373. дои : 10.1145/118544.118549 .
• Людвиг, Райнер; Кац, Рэнди Ховард (январь 2000 г.). «Алгоритм Эйфеля: повышение устойчивости TCP к ложным повторным передачам» . Обзор компьютерных коммуникаций ACM SIGCOMM . дои : 10.1145/505688.505692 .
• Маркс, Робин (3 декабря 2020 г.). «Блокировка заголовка в QUIC и HTTP/3: подробности» .
• Пааш, Кристоф; Бонавентура, Оливье (1 апреля 2014 г.). «Многопутевой TCP». Коммуникации АКМ . 57 (4): 51–57. дои : 10.1145/2578901 . S2CID   17581886 .
• Папастергиу, Гиоргос; Фэрхерст, Горри; Рос, Дэвид; Брунстрем, Анна; Гриннемо, Карл-Йохан; Хуртиг, Пер; Хадеми, Наим; Тюксен, Майкл; Вельцль, Майкл; Дамьянович, Драгана; Манджианте, Симона (2017). «Де-окостенение транспортного уровня Интернета: обзор и перспективы на будущее». Опросы и учебные пособия IEEE по коммуникациям . 19 : 619–639. дои : 10.1109/COMST.2016.2626780 . hdl : 2164/8317 . S2CID   1846371 .
• Рыбчинская, Марта (13 марта 2020 г.). «Быстрый взгляд на HTTP/3» . LWN.net .
• Да, Эрик; Мюллер, Тобиас; Буркерт, Кристиан; Федеррат, Ханнес; Фишер, Матиас (2020). «Повышенная производительность и конфиденциальность для TLS через TCP Fast Open» . Труды по технологиям повышения конфиденциальности . 2020 (2): 271–287. arXiv : 1905.03518 . дои : 10.2478/popets-2020-0027 .
• Чжан, Лися (5 августа 1986 г.). «Почему таймеры TCP не работают». Обзор компьютерных коммуникаций ACM SIGCOMM . 16 (3): 397–405. дои : 10.1145/1013812.18216 .

Дальнейшее чтение

• Стивенс, В. Ричард (10 января 1994 г.). TCP/IP в иллюстрациях, том 1: Протоколы . Паб Аддисон-Уэсли. компании ISBN  978-0-201-63346-7 .
• Стивенс, В. Ричард; Райт, Гэри Р. (1994). TCP/IP в иллюстрациях, том 2: Реализация . Аддисон-Уэсли. ISBN  978-0-201-63354-2 .
• Стивенс, В. Ричард (1996). TCP/IP Illustrated, Volume 3: TCP для транзакций, HTTP, NNTP и протоколы домена UNIX . Аддисон-Уэсли. ISBN  978-0-201-63495-2 . **

Внешние ссылки

• Устное историческое интервью с Робертом Э. Каном
• Назначение портов IANA
• Параметры TCP IANA
• Обзор TCP Джона Кристоффа (фундаментальные концепции TCP и то, как он используется для передачи данных между двумя конечными точками)
• Пример контрольной суммы