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

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

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

Историческое происхождение [ править ]

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

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

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

Сетевая функция [ править ]

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

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

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

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

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

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

Структура сегмента TCP [ править ]

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

Термин пакет TCP встречается как в неформальном, так и в формальном использовании, тогда как в более точной терминологии сегмент относится к блоку данных протокола TCP (PDU), дейтаграмма ^{[8] -} к PDU IP, а кадр - к 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 - защита от маскировки ^[a]
• 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 управляется операционной системой через ресурс, который представляет локальную конечную точку для связи, Интернет-сокет . Во время существования TCP-соединения локальная конечная точка претерпевает серию изменений состояния : ^[16]

Установление соединения [ править ]

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

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, данные);закрыть (а);

Для потока программы, подобного описанному выше, стек 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 повторно передавать правильные сегменты.

Повторная передача по таймауту [ править ]

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

Обнаружение ошибки [ править ]

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

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

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

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

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

Когда получатель объявляет размер окна 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 используются в алгоритме, известном как защита от номеров последовательностей с оберткой или PAWS (подробности см. В RFC 1323 ). PAWS используется, когда окно приема пересекает границу обхода порядкового номера. В случае, когда пакет потенциально был повторно передан, он отвечает на вопрос: «Это порядковый номер в первых 4 ГБ или во вторых?» И временная метка используется, чтобы разорвать связь.

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

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

Отметки времени TCP включены по умолчанию в ядре Linux., ^[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-флуда . Предлагаемые решения этой проблемы включают файлы cookie SYN и криптографические головоломки, хотя файлы cookie SYN имеют свой собственный набор уязвимостей. ^[33] Sockstress - похожая атака, которую можно смягчить с помощью управления системными ресурсами. ^[34] Расширенная DoS-атака с использованием таймера TCP Persist Timer была проанализирована во фразе №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), TELNET (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 , Требования к хосту для Интернета Hosts, разъяснен ряд требований к реализации протокола TCP. Список из 8 требуемых спецификаций и более 20 настоятельно рекомендуемых улучшений доступен в RFC 7414 . Среди этого списка - RFC 2581 , TCP Congestion Control, один из наиболее важных RFC, связанных с TCP за последние годы, описывает обновленные алгоритмы, позволяющие избежать чрезмерной перегрузки. В 2001 году RFC 3168был написан для описания явного уведомления о перегрузке ( ECN ), механизма сигнализации предотвращения перегрузки.

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

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

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

TCP Cookie Transactions (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]}

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

Аппаратные реализации [ править ]

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

Отладка [ править ]

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

Альтернативы [ править ]

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

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

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

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

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

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

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

Протокол передачи данных на основе 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