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

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

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

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

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

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

В мае 1974 года Vint Cerf и Bob Kahn описали интернет -протокол для обмена ресурсами с использованием переключения пакетов между сетевыми узлами. Авторы работали с Жераром Ле Ланн, чтобы включить концепции из проекта французских велосипедов в новую сеть. Спецификация ) полученного протокола, RFC 675 ( спецификация программы контроля передачи в Интернете была написана Vint Cerf, Yogen Dalal и Carl Sunshine и опубликована в декабре 1974 года. Он содержит первое подтвержденное использование термина Интернет , в качестве сокращения для интернета .

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

В следующих документах по эксперименту в Интернете (IEN) описываются эволюция TCP в современную версию:

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

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

В 2004 году Vint Cerf и Bob Kahn получили награду Тьюринга за основную работу по TCP/IP.

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

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

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

TCP широко используется многими интернет-приложениями, включая World Wide Web (www), протокол передачи электронной почты, протокол передачи файлов , безопасную оболочку , обмен файлами-одноранговым и потоковым носителем .

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

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

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

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

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

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

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

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

Формат заголовка TCP

Компенсировать	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Исходный порт																Порт назначения
4	32	Номер последовательности
8	64	Номер подтверждения (осмысленное при установке битов ACK)
12	96	Смещение данных				Сдержанный				Больной	ЭКС	Ург	Ак	Пш	Перстю	Его	КОНЕЦ	Окно
16	128	Контрольная сумма																Срочный указатель (осмысленный, когда набор битов URG)
20	160	[Параметры] Если присутствует, смещение данных будет превышать 5. Блажена с нулями до 32 бит, поскольку смещение данных считает слова из 4 октетов.
⋮	⋮
56	448
60	480	Данные
64	512
⋮	⋮

Источник -порт: 16 битов

Определяет отправляющий порт.

Порт назначения: 16 битов

Определяет приемный порт.

Номер последовательности: 32 бита

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

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

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

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

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

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

Зарезервированный (RSRVD): 4 бита

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

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

Флаги: 8 бит

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

Сир: 1 бит

Флаг по сниженному окну заторов (CWR) устанавливается отправным хостом, чтобы указать, что он получил сегмент TCP с набором флага ECE и ответил в механизме управления перегрузкой.

ECE: 1 бит

ECN-Echo играет двойную роль, в зависимости от значения флага Syn. Это указывает:

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

URG: 1 bit

Указывает, что срочное поле указателя является значительным.

ACK: 1 бит

Указывает, что поле подтверждения является значительным. Все пакеты после начального пакета SYN, отправленного клиентом, должны иметь этот набор флага.

PSH: 1 бит

Push -функция. Просит подтолкнуть буферизованные данные в приемное приложение.

RST: 1 бит

Сбросить соединение

SYN: 1 bit

Синхронизировать номера последовательностей. Только первый пакет, отправленный с каждого конца, должен иметь этот набор флага. Некоторые другие флаги и поля меняют значение на основе этого флага, а некоторые действительны только тогда, когда он установлен, а другие, когда это ясно.

Конец: 1 бит

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

Окно: 16 бит

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

Контрольная сумма : 16 битов

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

Срочный указатель: 16 битов

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

Опции (опция TCP): переменная 0–320 битов, в единицах 32 бита; размер (опции) == (Doffset - 5) * 32

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

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

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

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

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

Данные : переменная

Полезная нагрузка пакета TCP

Работа протокола

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

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

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

Соперные состояния TCP

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

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

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

1. SYN : Active Open выполняется клиентом, отправляющей 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. После того, как сторона, которая отправила первый плавник, ответил окончательным ACK, он ожидает тайм -аута, прежде чем наконец закрыть соединение, в течение которого местный порт недоступен для новых соединений; Это состояние позволяет клиенту TCP отказаться от окончательного подтверждения серверу в случае, если ACK потерян при транзите. Продолжительность времени зависит от реализации, но некоторые общие значения составляют 30 секунд, 1 минута и 2 минуты. После тайм -аута клиент входит в закрытое состояние, и локальный порт становится доступным для новых соединений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ретрансляция на основе Дюпака

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

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

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

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

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

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

Номера последовательностей позволяют приемникам отказываться от дублирующих пакетов и должным образом последовательно последовательности пакетов вне порядка. Благодарности позволяют отправителям определять, когда ретрансляция потерянных пакетов.

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

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

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

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

Номера последовательности TCP и получение Windows ведут себя очень похожи на часы. Окно приема сдвигается каждый раз, когда получатель получает и подтверждает новый сегмент данных. Как только он заканчивает числа последовательностей, номер последовательности переходит к 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 могут использовать Path MTU Discovery, чтобы вывести минимальный MTU вдоль пути сети между отправителем и приемником, и использовать его для динамической регулировки MSS, чтобы избежать фрагментации IP в сети.

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

Селективные подтверждения

Смотрите также: паника мешка

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

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

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

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

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

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

Основная статья: опция шкалы окна TCP

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

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

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

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

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

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

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

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

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

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

Недавние статистические данные показывают, что уровень принятия TCP TimeStamp заставил на уровне ~ 40%благодаря поддержке Windows Server с момента Windows Server 2008.

Данные вне полосы

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

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

Принуждение доставки данных

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

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

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

Уязвимости

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

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

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

Похищение соединения

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

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

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

TCP Veto

Злоумышленник, который может подслуживать и предсказать размер следующего пакета, который будет отправлен, может привести к тому, что получатель примет вредоносную полезную нагрузку без нарушения существующего соединения. Злоумышленник вводит вредоносный пакет с номером последовательности и размером полезной нагрузки следующего ожидаемого пакета. Когда в конечном итоге будет получен законный пакет, он имеет тот же номер последовательности и длину, что и пакет, уже полученный, и он молча отбрасывается в качестве обычного дублированного пакета - законный пакет вето направляется вредоносным пакетом. В отличие от угона, соединение никогда не дезинхронизируется, а общение продолжается как нормально после того, как злонамеренная полезная нагрузка принимается. TCP Veto дает злоумышленнику меньше контроля над связи, но делает атаку особенно устойчивой к обнаружению. Единственным доказательством получателя о том, что что -то не так, является единственным дублированным пакетом, нормальным явлением в сети 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 , Control TCP Control, один из наиболее важных RFC, связанных с TCP в последние годы, описывает обновленные алгоритмы, которые избегают чрезмерного заторов. В 2001 году RFC 3168 был написан для описания явного уведомления о перегрузке (ECN), механизма сигнализации уклонения за скопления.

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

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

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

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

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

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

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

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

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

Изображение провода и окостенение

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

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

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

Создание подключения является основным участником задержки, испытываемых пользователями веб -сайтов. Трехстороннее рукопожатие TCP представляет один RTT задержки во время установления соединения, прежде чем данные могут быть отправлены. Для коротких потоков эти задержки очень важны. Безопасность транспортного уровня (TLS) требует собственного рукопожатия для обмена ключами при установлении соединения. Из -за многоуровневого дизайна рукопожатие TCP и рукопожатие TLS проходят последовательно; Руководство TLS не может начаться, пока рукопожатие TCP не завершится. Два RTT требуются для установления соединения с TLS 1.2 над TCP. TLS 1.3 допускает нулевое возобновление подключения к RTT в некоторых обстоятельствах, но, когда для рукопожатия TCP по -прежнему требуется один RTT, это все еще требуется, и это не может помочь первоначальному соединению; Руководства RTT также представляют криптографические проблемы, как эффективные, безопасные и прямые безопасные неинтерактивные ключевые обмены, является открытой темой исследования. Fast Open TCP позволяет передавать данные в начальных пакетах (т.е., Syn и Syn-Ack), удаляя один RTT задержки во время установления соединения. Тем не менее, TCP Fast Open было трудно развернуть из -за окостенения протокола; По состоянию на 2020 год , Никакие веб -браузеры не использовали его по умолчанию.

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

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

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

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

Ускорение

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

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

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

Отладка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компенсировать	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Адрес источника
4	32	Адрес назначения
8	64	Нули								Протокол								Длина TCP
12	96	Исходный порт																Порт назначения
16	128	Номер последовательности
20	160	Номер подтверждения
24	192	Смещение данных				Сдержанный				Флаги								Окно
28	224	Контрольная сумма																Срочный указатель
32	256	[Параметры] (необязательно)
36	288	Данные
40	320
⋮	⋮

Контрольная сумма вычисляется по следующим полям:

Адрес источника: 32 бита

Адрес источника в заголовке IPv4

Адрес назначения: 32 бита

Адрес назначения в заголовке IPv4.

Нули: 8 битов; Zeroes == 0

Все нули.

Протокол: 8 бит

Значение протокола для TCP: 6.

Длина TCP: 16 битов

Длина заголовка TCP и данных (измеряется в октетах).

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

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

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

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

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

Компенсировать	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Адрес источника
4	32
8	64
12	96
16	128	Адрес назначения
20	160
24	192
28	224
32	256	Длина TCP
36	288	Нули																								Следующий заголовок (= протокол)
40	320	Исходный порт																Порт назначения
44	352	Номер последовательности
48	384	Номер подтверждения
52	416	Смещение данных				Сдержанный				Флаги								Окно
56	448	Контрольная сумма																Срочный указатель
60	480	[Параметры] (необязательно)
64	512	Данные
68	544
⋮	⋮

Контрольная сумма вычисляется по следующим полям:

Адрес источника: 128 бит

Адрес в заголовке IPv6.

Адрес назначения: 128 бит

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

Длина TCP: 32 бита

Длина заголовка TCP и данных (измеряется в октетах).

Нули: 24 бита; Zeroes == 0

Все нули.

Следующий заголовок: 8 битов

Значение протокола для TCP: 6.

Контрольная сумма разгрузки

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

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

Смотрите также

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

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

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

• Cerf, Vint ; Далал, Йоген ; Sunshine, Carl (декабрь 1974 г.). Спецификация программы управления передачей Интернета, версия декабря 1974 года . doi : 10.17487/rfc0675 . RFC 675 .
• Postel, Jon (September 1981). Internet Protocol . doi : 10.17487/RFC0791 . RFC 791 .
• Postel, Джон (сентябрь 1981). Протокол управления передачей . doi : 10.17487/rfc0793 . RFC 793 .
• Брэйден, Роберт , изд. (Октябрь 1989 г.). Требования к интернет -хостам - слои связи . doi : 10.17487/rfc1122 . RFC 1122 .
• Джейкобсон, Ван ; Брэйден, Боб ; Борман, Дэйв (май 1992). Расширения TCP для высокой производительности . doi : 10.17487/rfc1323 . RFC 1323 .
• Белловин, Стивен М. (май 1996 г.). Защита от атаки номера последовательности . doi : 10.17487/rfc1948 . RFC 1948 .
• Матис, Мэтт; Махдави, Джамшид; Флойд, Салли; Романов, Аллин (октябрь 1996 г.). TCP Селективные варианты подтверждения . doi : 10.17487/rfc2018 . RFC 2018 .
• Аллман, Марк; Паксон, Верн ; Стивенс, В. Ричард (апрель 1999 г.). Контроль заторов TCP . doi : 10.17487/rfc2581 . RFC 2581 .
• Флойд, Салли ; Махдави, Джамшид; Матис, Мэтт; Подольский, Мэтью (июль 2000 г.). Расширение на опцию выборочного подтверждения (SACK) для TCP . doi : 10.17487/rfc2883 . RFC 2883 .
• Рамакришнан, KK; Флойд, Салли ; Черный, Дэвид (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) к IP . doi : 10.17487/rfc3168 . RFC 3168 .
• Людвиг, Рейнер; Мейер, Майкл (апрель 2003 г.). Алгоритм обнаружения Эйфеля для TCP . doi : 10.17487/rfc3522 . RFC 3522 .
• Весна, Нил; Weatherall, David; Эли, Дэвид (июнь 2003 г.). Надежная явная передача уведомлений о перегрузке (ECN) с помощью NONCES . doi : 10.17487/rfc3540 . RFC 3540 .
• Аллман, Марк; Паксон, Верн ; Блантон, Итан (сентябрь 2009 г.). Контроль заторов TCP . doi : 10.17487/rfc5681 . RFC 5681 .
• Симпсон, Уильям Аллен (январь 2011 г.). TCP Cookie Transactions (TCPCT) . doi : 10.17487/rfc6013 . RFC 6013 .
• Форд, Алан; Raiciu, Costin; Хэндли, Марк ; Барре, Себастьен; Айенгар, Джанардхан (март 2011 г.). Архитектурные руководящие принципы для многолучевого развития TCP . doi : 10.17487/rfc6182 . RFC 6182 .
• Паксон, Верн ; Аллман, Марк; Чу, Х. К. Джерри; Сарджент, Мэтт (июнь 2011 г.). Вычисление таймера ретрансляции TCP . doi : 10.17487/rfc6298 . RFC 6298 .
• Форд, Алан; Raiciu, Costin; Хэндли, Марк ; Bonaventure, Olivier (январь 2013 г.). Расширения TCP для многолучевой работы с несколькими адресами . doi : 10.17487/rfc6824 . RFC 6824 .
• Матис, Мэтт; Dukkipati, Nandita; Ченг, Ючунг (май 2013). Пропорциональное снижение скорости для TCP . doi : 10.17487/rfc6937 . RFC 6937 .
• Борман, Дэвид; Брэйден, Боб ; Джейкобсон, Ван (сентябрь 2014 г.). Шеффенеггер, Ричард (ред.). Расширения TCP для высокой производительности . doi : 10.17487/rfc7323 . RFC 7323 .
• Герцог, Мартин; Брэйден, Роберт ; Эдди, Уэсли М.; Блантон, Итан; Циммерманн, Александр (февраль 2015 г.). Дорожная карта для спецификационных документов протокола управления передачей (TCP) . doi : 10.17487/rfc7414 . RFC 7414 .
• Ченг, Юбнг; Чу, Джерри; Стенд, Сиванкар; Джайн, Арвинд (вырожденный 2014). TCP Fast Fest . DUI : 10,17487/ RFC7413 RFC 7413
• Циммерманн, Александр; Эдди, Уэсли М.; Эггерт, Ларс (апрель 2016 г.). Перемещение устаревших расширений TCP и документов, связанных с TCP, к историческому или информационному статусу . doi : 10.17487/rfc7805 . RFC 7805 .
• Фэрхерст, Горри; Траммелл, Брайан; Kuehlewind, Mirja, eds. (Март 2017). Услуги, предоставляемые протоколами транспорта IETF и механизмом контроля затоков . doi : 10.17487/rfc8095 . RFC 8095 .
• Ченг, Ючунг; Кардвелл, Нил; Dukkipati, Nandita; Джа, Прияранджан, ред. (Февраль 2021 г.). Алгоритм обнаружения потерь стойки TLP для TCP Doi : 10.17487/ rfc8 8985RFC
• Диринг, Стивен Э .; Хинден, Роберт М. (июль 2017 г.). Интернет -протокол, версия 6 (IPv6) . doi : 10.17487/rfc8200 . RFC 8200 .
• Траммелл, Брайан; Kuehlewind, Mirja (апрель 2019 г.). Изображение провода сетевого протокола . doi : 10.17487/rfc8546 . RFC 8546 .
• Харди, Тед, изд. (Апрель 2019). Транспортный протокол сигналов . doi : 10.17487/rfc8558 . RFC 8558 .
• Айенгар, Яна; Светт, Ян, ред. (Май 2021 г.). Обнаружение потери QUIC и контроль заторов . doi : 10.17487/rfc9002 . RFC 9002 .
• Фэрхерст, Горри; Перкинс, Колин (июль 2021 г.). Соображения вокруг конфиденциальности транспорта, сетевых операций и эволюции интернет -транспортных протоколов . doi : 10.17487/rfc9065 . RFC 9065 .
• Томсон, Мартин; Поли, Томми (декабрь 2021 г.). Долгосрочная жизнеспособность механизмов расширения протокола . doi : 10.17487/rfc9170 . RFC 9170 .
• Эдди, Уэсли М., изд. (Август 2022). Протокол управления передачей (TCP) . doi : 10.17487/rfc9293 . RFC 9293 .

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

• Аллман, Марк; Паксон, Верн (октябрь 1999). «О оценке сквозных свойств сетевого пути» . ACM SigComm Computer Communication Review . 29 (4): 263–274. doi : 10.1145/316194.316230 . HDL : 2060/20000004338 .
• Бхат, Дивьяшри; Ризк, Амр; Зинк, Майкл (июнь 2017 г.). «Не так Quic: исследование производительности Dash Over Quic». Nossdav'17: Материалы 27 -го семинара по поддержке сетевых и операционных систем для цифрового аудио и видео . С. 13–18. doi : 10.1145/3083165.3083175 . S2CID   32671949 .
• Блантон, Итан; Аллман, Марк (январь 2002 г.). «При сделании TCP более надежным для переупорядочения пакетов» (PDF) . ACM SigComm Computer Communication Review . 32 : 20–30. doi : 10.1145/510726.510728 . S2CID   15305731 .
• Бриско, Боб; Брунстрем, Анна; Петлунд, Андреас; Хейс, Дэвид; Рос, Дэвид; Цанг, Инг-Джих; Gjessing, Stein; Фэрхерст, Горри; Гриводц, Карстен; Уэлцл, Майкл (2016). «Сокращение задержки в Интернете: обзор методов и их достоинств». IEEE Communications Surveys & Ruciots . 18 (3): 2149–2196. doi : 10.1109/comst.2014.2375213 . HDL : 2164/8018 . S2CID   206576469 .
• Bruyeron, Renaud; Хемон, Бруно; Чжан, Ликса (апрель 1998 г.). «Эксперименты с селективным подтверждением TCP». ACM SigComm Computer Communication Review . 28 (2): 54–77. doi : 10.1145/279345.279350 . S2CID   15954837 .
• Чен, пять; Джеро, Самуил; Ягельский, Мэтью; Болдирева, Александра; Нита-Ротару, Кристина (2021). "Застройка канала безопасного коммуникации: TLS 1.3 (над TCP Fast Open) по сравнению с Quic " Журнал криптологии 34 (3). Doi : 10.1007/s00145-021-09389- w  235174220S2CID
• Корбет, Джонатан (8 декабря 2015 г.). «Отделка контроля и протокол, носификация» . Lwn.net .
• Корбет, Джонатан (29 января 2018 г.). «QUIC как решение для наблюдения протокола» . Lwn.net .
• Эделин, Корейан; Доннет, Бенуа (2019). Восходное расследование транспортного соротика . Конференция по измерению и анализу сетевого трафика 2019 года (TMA). doi : 10.23919/tma.2019.8784690 .
• Гедини, Алессандро (26 июля 2018 г.). «Дорога к Quic» . Cloudflare .
• Гуртов, Андрей; Флойд, Салли (февраль 2004 г.). Разрешение неоднозначности подтверждения в не-сак-TCP (PDF) . Следующее поколение Тетраффик и проводные/беспроводные передовые сети (new2an'04).
• Гуртов, Андрей; Людвиг, Рейнер (2003). Отвечая на ложные тайм -ауты в TCP (PDF) . IEEE Infocom 2003. Двадцать второй ежегодной совместной конференции IEEE Computer и коммуникационных обществ. doi : 10.1109/infcom.2003.1209251 .
• Hesmans, Benjamin; Дюшен, Фабен; Пааш, Кристоф; ДЕТАЛ, Грегори; Bonaventure, Olivier (2013). Являются ли TCP Extensions Middlebox, защищенные? Полем Hotmiddlebox '13. Citeseerx   10.1.1.679.6364 . doi : 10.1145/2535828.2535830 .
• IETF HTTP Рабочая группа. «Http/2 часто задают вопросы» .
• Карн, Фил ; Партридж, Крейг (ноябрь 1991 г.). «Улучшение оценки времени в оба конца в надежных протоколах транспорта» . Транзакции ACM на компьютерных системах . 9 (4): 364–373. doi : 10.1145/1185444.118549 .
• Людвиг, Рейнер; Кац, Рэнди Ховард (январь 2000 г.). «Алгоритм Эйфеля: сделав TCP надежным против ложных ретрансмиссий» . ACM SigComm Computer Communication Review . doi : 10.1145/505688.505692 .
• Маркс, Робин (3 декабря 2020 г.). «Блокировка головы в Quic и http/3: детали» .
• Пааш, Кристоф; Bonaventure, Olivier (1 апреля 2014 г.). "Многолучебный TCP". Коммуникации ACM . 57 (4): 51–57. doi : 10.1145/2578901 . S2CID   17581886 .
• Papastergiou, Giorgos; Фэрхерст, Горри; Рос, Дэвид; Брунстрем, Анна; Grinnemo, Карл-Джохан; Херт, за; Khademi, Naeem; Тюксен, Майкл; Уэлцл, Майкл; Даманович, Драгана; Mangiante, Simone (2017). «Отставление интернет-транспортного уровня: опрос и будущие перспективы». IEEE Communications Surveys & Ruciots . 19 : 619–639. doi : 10.1109/comst.2016.2626780 . HDL : 2164/8317 . S2CID   1846371 .
• Rybczyńska, Марта (13 марта 2020 года). "QUIC HIST на http/3" . Lwn.net .
• Sy, erik; Мюллер, Тобиас; Беркерт, Кристиан; Федеррат, Ханнес; Фишер, Матиас (2020). «Усовершенствованная производительность и конфиденциальность для TLS по сравнению с TCP Fast Open» . Материалы по технологиям повышения конфиденциальности . 2020 (2): 271–287. Arxiv : 1905.03518 . doi : 10.2478/popets-2020-0027 .
• Чжан, Ликсия (5 августа 1986 г.). «Почему таймеры TCP не работают хорошо». ACM SigComm Computer Communication Review . 16 (3): 397–405. doi : 10.1145/1013812.18216 .

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

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

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

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