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

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

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

Хотя TCP является сложным протоколом, его основные операции не претерпели значительных изменений с момента его первой спецификации. TCP по-прежнему преимущественно используется для Интернета, то есть для HTTP протокол, а позже HTTP / 2, хотя не используется последним стандартом HTTP / 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

Период, термин Пакет TCP появляется как в неформальном, так и в формальном использовании, тогда как в более точной терминологии сегмент относится к TCP блок данных протокола (PDU), дейтаграмма^[8] к IP PDU и Рамка к уровень канала передачи данных PDU:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для будущего использования и должен быть установлен на ноль.

Флаги (9 бит)

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

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

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

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

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

Размер окно приема, который определяет количество единиц размера окна^[c] что отправитель этого сегмента в настоящее время желает получить.^[d] (Видеть § Управление потоком и § Масштабирование окна.)

Контрольная сумма (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]. Тип опции и стандартная длина указываются как (Тип опции, Длина опции).

Вариант-вид	Вариант-Длина	Вариант-данные	Цель	Примечания
0	Нет данных	Нет данных	Конец списка опций
1	Нет данных	Нет данных	Нет операции	Это можно использовать для выравнивания полей параметров по 32-битным границам для повышения производительности.
2	4	SS	Максимальный размер сегмента	Видеть § Максимальный размер сегмента [SYN]
3	3	S	Масштаб окна	Видеть § Масштабирование окна для подробностей[10] [SYN]
4	2	Нет данных	Разрешено выборочное подтверждение	Видеть § Выборочные подтверждения для подробностей[11][SYN]
5	N (10, 18, 26 или 34)	BBBB, EEEE, ...	Выборочное подтверждение (SACK)[12]	За этими первыми двумя байтами следует список из 1–4 выборочно подтвержденных блоков, указанных как 32-битные указатели начала / конца.
8	10	TTTT, EEEE	Отметка времени и эхо предыдущей отметки времени	Видеть § Временные метки TCP для подробностей[13]

Остальные значения Option-Kind являются историческими, устаревшими, экспериментальными, еще не стандартизованными или неназначенными. Назначение номеров опций поддерживается IANA.^[14]

Прокладка

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

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

Упрощенная диаграмма состояний TCP. Видеть Схема TCP EFSM для получения более подробной диаграммы состояний, включая состояния внутри состояния ESTABLISHED.

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

Соединение TCP управляется операционной системой через ресурс, который представляет локальную конечную точку для связи, Интернет-розетка. В течение времени существования TCP-соединения локальная конечная точка подвергается серии государственный изменения:^[16]

СЛУШАТЬ

(сервер) означает ожидание запроса на соединение от любой удаленной конечной точки TCP.

СИНХРОНИЗАЦИЯ

(клиент) представляет ожидание соответствующего запроса на соединение после отправки запроса на соединение.

СИНХРОНИЗАЦИЯ

(сервер) представляет ожидание подтверждающего подтверждения запроса на соединение после получения и отправки запроса на соединение.

УЧРЕДИЛ

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

FIN-WAIT-1

(и сервер, и клиент) означает ожидание запроса на завершение соединения от удаленного TCP или подтверждения ранее отправленного запроса на завершение соединения.

FIN-WAIT-2

(и сервер, и клиент) означает ожидание запроса на завершение соединения от удаленного TCP.

ЗАКРЫТЬ-ПОДОЖДИТЕ

(и сервер, и клиент) означает ожидание запроса на разрыв соединения от локального пользователя.

ЗАКРЫТИЕ

(и сервер, и клиент) означает ожидание подтверждения запроса на завершение соединения от удаленного TCP.

ПОСЛЕДНИЙ ACK

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

ВРЕМЯ ЖДЕТ

(сервер или клиент) означает ожидание, пока пройдет достаточно времени, чтобы убедиться, что удаленный TCP получил подтверждение своего запроса на завершение соединения. [В соответствии с RFC 793 соединение может оставаться в режиме TIME-WAIT не более четырех минут, известных как две максимальный срок службы сегмента (MSL).]

ЗАКРЫТО

(и сервер, и клиент) вообще не представляют состояния подключения.

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

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

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

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

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

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

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

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

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

Некоторые операционные системы, например Linux и H-UX, реализовать полудуплексную последовательность закрытия в стеке TCP. Если хост активно закрывает соединение, но все еще имеет непрочитанные входящие данные, хост отправляет сигнал RST (потеря всех полученных данных) вместо FIN.^[18] Это гарантирует приложению TCP, что удаленный процесс прочитал все переданные данные, ожидая сигнала FIN, прежде чем он активно закроет соединение. Удаленный процесс не может различить сигнал RST для соединение прерывается и потери данных. Оба приводят к тому, что удаленный стек теряет все полученные данные.

Некоторые приложения, использующие протокол установления связи открытия / закрытия TCP, могут обнаруживать проблему RST при активном закрытии. В качестве примера:

s = соединение (удаленный); отправить (s, данные); закрыть (s);

Для потока программы, подобного описанному выше, стек TCP / IP, подобный описанному выше, не гарантирует, что все данные поступят в другое приложение, если на этот конец прибыли непрочитанные данные.

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

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

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

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

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

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

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

Надежная трансмиссия

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

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

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

Ретрансляция на основе дупака

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

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

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

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

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

Для обеспечения правильности включено поле контрольной суммы; видеть вычисление контрольной суммы раздел для получения подробной информации о контрольной сумме. Контрольная сумма TCP - это слабая проверка по современным стандартам. Уровни канала передачи данных с высоким коэффициентом ошибок по битам могут потребовать дополнительных возможностей исправления / обнаружения ошибок канала. Слабая контрольная сумма частично компенсируется общим использованием CRC или лучшая проверка целостности на слой 2, ниже TCP и IP, например, используется в PPP или Ethernet Рамка. Однако это не означает, что 16-битная контрольная сумма TCP является избыточной: примечательно, что появление ошибок в пакетах между переходами, защищенными с помощью CRC, является обычным явлением, но концы с концами 16-битная контрольная сумма TCP улавливает большинство этих простых ошибок.^[22] Это сквозной принцип на работе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объявление MSS также часто называют «согласованием MSS». Строго говоря, MSS не «согласовывается» между отправителем и получателем, потому что это будет означать, что и отправитель, и получатель будут согласовывать и согласовывать единую унифицированную MSS, которая применяется ко всем коммуникациям в обоих направлениях соединения. Фактически, два полностью независимых значения MSS разрешены для двух направлений потока данных в TCP-соединении.^[23] Такая ситуация может возникнуть, например, если одно из устройств, участвующих в соединении, имеет чрезвычайно ограниченный объем памяти, зарезервированной (возможно, даже меньше, чем общий MTU обнаруженного пути) для обработки входящих сегментов TCP.

Выборочные подтверждения

Если полагаться исключительно на схему кумулятивного подтверждения, используемую исходным протоколом 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. Соответственно, отправитель ретранслирует только второй сегмент с порядковыми номерами от 2 000 до 2 999.

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

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

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

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

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

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

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

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

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

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

4-байтовое значение метки времени отправителя (моя метка времени)

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

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

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

Последние статистические данные показывают, что уровень внедрения меток времени не изменился и составил ~ 40% из-за прекращения поддержки серверов Windows с Windows Server 2008.^[25]

В ядре Linux временные метки TCP включены по умолчанию.,^[26] и отключен по умолчанию в Windows Server 2008, 2012 и 2016.^[27]

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

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

TCP внеполосные данные не был разработан для современного Интернета. В срочный указатель только изменяет обработку на удаленном хосте и не ускоряет обработку в самой сети. Когда он попадает на удаленный хост, существуют две немного разные интерпретации протокола, что означает, что надежны только отдельные байты данных OOB. Предполагается, что он вообще надежен, так как это один из наименее часто используемых протокольных элементов и имеет тенденцию быть плохо реализованной.^[28][29]

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

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

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

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

RFC определяет PSH push-бит как «сообщение принимающему стеку TCP для немедленной отправки этих данных принимающему приложению».^[6] Невозможно указать или контролировать его в пространство пользователя с помощью Розетки Berkeley и это контролируется стек протоколов Только.^[30]

Уязвимости

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

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

Используя подделанный IP адрес и повторно отправка намеренно собранный Пакеты SYN, за которыми следует множество пакетов ACK, злоумышленники могут заставить сервер потреблять большое количество ресурсов, отслеживая фиктивные соединения. Это известно как SYN флуд атака. Предлагаемые решения этой проблемы включают: SYN файлы cookie и криптографические головоломки, хотя файлы cookie SYN имеют свой собственный набор уязвимостей.^[33] Sockstress похожая атака, которую можно смягчить с помощью управления системными ресурсами.^[34] Продвинутая DoS-атака с использованием таймера TCP Persist Timer была проанализирована в Phrack #66.^[35] PUSH и ACK флуд есть другие варианты.^[36]

Взлом соединения

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

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

Вето TCP

Злоумышленник, который может подслушать и предсказать размер следующего пакета, который будет отправлен, может заставить получатель принять вредоносную полезную нагрузку, не нарушая существующее соединение. Злоумышленник вводит вредоносный пакет с порядковым номером и размером полезной нагрузки следующего ожидаемого пакета. Когда законный пакет в конечном итоге получен, выясняется, что он имеет тот же порядковый номер и длину, что и уже полученный пакет, и молча отбрасывается как обычный дублированный пакет - законный пакет "наложен вето" на вредоносный пакет. В отличие от перехвата соединения, соединение никогда не десинхронизируется, и связь продолжается в обычном режиме после того, как вредоносная полезная нагрузка принята. Вето TCP дает злоумышленнику меньший контроль над коммуникацией, но делает атаку особенно устойчивой к обнаружению. Избегают значительного увеличения сетевого трафика из-за шторма ACK. Единственное свидетельство для получателя того, что что-то не так, - это один дублированный пакет, что является нормальным явлением в IP-сети. Отправитель пакета, на который наложено вето, никогда не видит никаких доказательств атаки.^[38]

Еще одна уязвимость Атака сброса TCP.

TCP порты

Использование TCP и UDP номера портов для идентификации конечных точек отправляющих и принимающих приложений на хосте, часто называемых Интернет-розетки. С каждой стороной TCP-соединения связан 16-битный номер порта без знака (0-65535), зарезервированный отправляющим или принимающим приложением. Поступающие TCP-пакеты идентифицируются как принадлежащие определенному TCP-соединению по его сокетам, то есть по комбинации адреса хоста источника, порта источника, адреса хоста назначения и порта назначения. Это означает, что серверный компьютер может предоставлять нескольким клиентам несколько услуг одновременно, если клиент заботится об инициации любых одновременных подключений к одному порту назначения из разных портов источника.

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

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

Разработка

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

Оригинал Алгоритм предотвращения перегрузки TCP был известен как "TCP Tahoe", но с тех пор было предложено много альтернативных алгоритмов (включая TCP Reno, TCP Vegas, БЫСТРЫЙ TCP, TCP Нью-Рино, и TCP Hybla).

TCP интерактивный (iTCP) ^[39] - это исследование расширений TCP, которое позволяет приложениям подписываться на события TCP и регистрировать компоненты обработчика, которые могут запускать приложения для различных целей, включая управление перегрузкой с помощью приложений.

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

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

tcpcrypt - это расширение, предложенное в июле 2010 года для обеспечения шифрования транспортного уровня непосредственно в TCP. Он разработан для прозрачной работы и не требует настройки. В отличие от TLS (SSL), tcpcrypt сам по себе не обеспечивает аутентификацию, но предоставляет простые примитивы для этого приложения. По состоянию на 2010 г.^{[Обновить]}опубликован первый черновик tcpcrypt IETF, и существуют его реализации для нескольких основных платформ.

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

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

TCP по беспроводным сетям

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

Ряд альтернативных алгоритмов контроля перегрузки, таких как Вегас, Westwood, Veno и Santa Cruz были предложены для решения проблемы беспроводной связи.^{[нужна цитата]}

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

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

Отладка

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

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

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

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

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

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

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

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

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

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

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

Расчет контрольной суммы

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC документы

• RFC 675 - Спецификация программы управления передачей через Интернет, версия от декабря 1974 г.
• RFC 793 - TCP v4
• STD 7 - Протокол управления передачей, спецификация протокола
• RFC 1122 - включает некоторые исправления ошибок для TCP
• RFC 1323 - Расширения TCP для высокой производительности [Устарело RFC 7323]
• RFC 1379 - Расширение TCP для транзакций - концепции [Устарело RFC 6247]
• RFC 1948 г. - Защита от атак по порядковому номеру
• RFC 2018 - Опции выборочного подтверждения TCP
• RFC 5681 - Контроль перегрузки TCP
• RFC 6247 - Перемещение неразвернутых расширений TCP RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, и RFC 1693 к историческому статусу
• RFC 6298 - Расчет таймера повторной передачи TCP
• RFC 6824 - Расширения TCP для многопутевой работы с несколькими адресами
• RFC 7323 - Расширения TCP для высокой производительности
• RFC 7414 - Дорожная карта для документов спецификации TCP

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

Примечания

Рекомендации

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

• Стивенс, В. Ричард (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
• Параметры IANA TCP
• Обзор TCP Джона Кристоффа (Основные концепции TCP и способы его использования для передачи данных между двумя конечными точками)
• Пример контрольной суммы
• Руководство по TCP