stringtranslate.com

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

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

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

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

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

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

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

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

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

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

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

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

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

TCP оптимизирован для точной доставки, а не для своевременной доставки, и может вызывать относительно большие задержки (порядка секунд) при ожидании сообщений, не соответствующих порядку, или повторной передачи потерянных сообщений. Поэтому он не особенно подходит для приложений реального времени, таких как передача голоса по IP . Для таких приложений обычно рекомендуются такие протоколы, как Real-time Transport Protocol (RTP), работающие поверх User Datagram Protocol (UDP). [13]

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

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

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

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

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

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

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

Исходный порт: 16 бит
Определяет порт отправки.
Порт назначения: 16 бит
Определяет порт приема.
Порядковый номер: 32 бита
Имеет двойную роль:
  • Если флаг SYN установлен (1), то это начальный порядковый номер. Порядковый номер фактического первого байта данных и подтвержденный номер в соответствующем ACK тогда являются этим порядковым номером плюс 1.
  • Если флаг SYN не установлен (0), то это накопленный порядковый номер первого байта данных этого сегмента для текущего сеанса.
Номер подтверждения: 32 бита
Если установлен флаг ACK, то значение этого поля — следующий порядковый номер, который ожидает отправитель ACK. Это подтверждает получение всех предыдущих байтов (если таковые имеются). [19] Первый ACK, отправленный каждым концом, подтверждает сам начальный порядковый номер другого конца, но не данные. [20]
Смещение данных  (DOffset): 4 бита
Указывает размер заголовка TCP в 32-битных словах . Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что дает минимальный размер 20 байт и максимальный — 60 байт, что позволяет использовать до 40 байт опций в заголовке. Это поле получило свое название из-за того, что оно также является смещением от начала сегмента TCP до фактических данных. [ необходима цитата ]
Зарезервировано  (Rsrvd): 4 бита
Для будущего использования и должны быть установлены на ноль; отправители не должны устанавливать их, а получатели должны игнорировать их, если они установлены, при отсутствии дальнейшей спецификации и реализации.
С 2003 по 2017 год последний бит (бит 103 заголовка) определялся как флаг NS (Nonce Sum) экспериментальным RFC 3540, ECN-nonce. ECN-nonce так и не получил широкого распространения, и RFC был перемещен в статус Historic. [21]
Флаги: 8 бит
Содержит 8 1-битных флагов (управляющих битов) следующим образом:
CWR: 1 бит
Флаг уменьшения окна перегрузки (CWR) устанавливается отправляющим хостом, чтобы указать, что он получил сегмент TCP с установленным флагом ECE и ответил в механизме управления перегрузкой. [22] [a]
ЕЭК: 1 бит
ECN-Echo имеет двойную роль, в зависимости от значения флага SYN. ​​Он указывает:
  • Если флаг SYN установлен (1), TCP-узел поддерживает ECN . [23]
  • Если флаг SYN не установлен (0), пакет с установленным флагом Congestion Experienced (ECN=11) в заголовке IP был получен во время нормальной передачи. [a] Это служит указанием на перегрузку сети (или надвигающуюся перегрузку) для отправителя TCP. [24]
URG: 1 бит
Указывает, что поле указателя срочности является значимым.
ACK: 1 бит
Указывает, что поле Acknowledgment имеет значение. Все пакеты после начального пакета SYN, отправленного клиентом, должны иметь этот установленный флаг. [25]
ПШ: 1 бит
Функция Push. Запрашивает отправку буферизованных данных в принимающее приложение.
RST: 1 бит
Сбросить соединение
SYN: 1 бит
Синхронизировать порядковые номера. Только первый пакет, отправленный с каждого конца, должен иметь установленный флаг. Некоторые другие флаги и поля меняют значение в зависимости от этого флага, и некоторые из них действительны только тогда, когда он установлен, а другие — когда он очищен.
ФИН: 1 бит
Последний пакет от отправителя
Окно: 16 бит
Размер окна приема , который указывает количество единиц размера окна [b] , которые отправитель этого сегмента в данный момент готов получить. [c] (См. § Управление потоком и § Масштабирование окна.)
Контрольная сумма : 16 бит
Поле контрольной суммы длиной 16 бит используется для проверки ошибок заголовка TCP, полезной нагрузки и псевдозаголовка IP. Псевдозаголовок состоит из исходного IP-адреса , IP-адреса назначения , номера протокола для протокола TCP (6) и длины заголовков TCP и полезной нагрузки (в байтах).
Указатель срочности: 16 бит
Если установлен флаг URG, то это 16-битное поле представляет собой смещение от порядкового номера, указывающего последний срочный байт данных.
Параметры  (TCP-параметр): переменная 0–320 бит, в единицах по 32 бита; размер(Параметры) == (DOffset - 5) * 32
Длина этого поля определяется полем смещения данных . Заполнение заголовка TCP используется для того, чтобы гарантировать, что заголовок TCP заканчивается, а данные начинаются на 32-битной границе. Заполнение состоит из нулей. [16]
Параметры имеют до трех полей: Option-Kind (1 байт), Option-Length (1 байт), Option-Data (переменная). Поле Option-Kind указывает тип параметра и является единственным полем, которое не является необязательным. В зависимости от значения Option-Kind могут быть установлены следующие два поля. Option-Length указывает общую длину параметра, а Option-Data содержит данные, связанные с параметром, если применимо. Например, байт Option-Kind, равный 1, указывает, что это параметр без операции, используемый только для заполнения, и не имеет полей Option-Length или Option-Data, следующих за ним. Байт Option-Kind, равный 0, отмечает конец параметров и также является всего одним байтом. Байт Option-Kind, равный 2, используется для указания параметра Максимальный размер сегмента и будет сопровождаться байтом Option-Length, указывающим длину поля MSS. Option-Length — это общая длина указанного поля опций, включая поля Option-Kind и Option-Length. Таким образом, хотя значение MSS обычно выражается двумя байтами, Option-Length будет 4. Например, поле опций MSS со значением 0x05B4 кодируется как ( 0x02 0x04 0x05B4 ) в разделе опций TCP.
Некоторые параметры могут быть отправлены только при установленном SYN; они обозначены ниже как [SYN]. Option-Kind и стандартные длины указаны как (Option-Kind, Option-Length).
Остальные значения Option-Kind являются историческими, устаревшими, экспериментальными, еще не стандартизированными или не назначенными. Назначение номеров опций поддерживается организацией Internet Assigned Numbers Authority (IANA). [30]
Данные : Переменные
Полезная нагрузка TCP-пакета

Протокол операции

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

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

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

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

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

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

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

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

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

Фаза завершения соединения использует четырехстороннее рукопожатие, при этом каждая сторона соединения завершает соединение независимо. Когда конечная точка хочет остановить свою половину соединения, она передает пакет FIN, который другая сторона подтверждает с помощью ACK. Таким образом, типичное завершение соединения требует пары сегментов FIN и ACK от каждой конечной точки TCP. После того, как сторона, отправившая первый FIN, ответила последним ACK, она ждет тайм-аута, прежде чем окончательно закрыть соединение, в течение которого локальный порт недоступен для новых подключений; это состояние позволяет клиенту TCP повторно отправить окончательное подтверждение на сервер в случае, если ACK будет потерян при передаче. Длительность времени зависит от реализации, но некоторые общие значения составляют 30 секунд, 1 минуту и ​​2 минуты. После тайм-аута клиент переходит в состояние CLOSED, и локальный порт становится доступным для новых подключений. [32]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда отправитель передает сегмент, он инициализирует таймер с консервативной оценкой времени прибытия подтверждения. Сегмент передается повторно, если таймер истекает, с новым порогом тайм-аута, вдвое превышающим предыдущее значение, что приводит к экспоненциальному поведению отсрочки. Обычно начальное значение таймера равно , где — гранулярность часов. [44] Это защищает от чрезмерного трафика передачи из-за неисправных или вредоносных субъектов, таких как злоумышленники, использующие атаку типа « человек посередине» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Избирательные благодарности

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

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

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

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

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

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

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

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

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

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

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

Существует два поля временной метки:

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

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

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

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

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

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

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

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

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

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

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

Уязвимости

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

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

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

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

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

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

TCP вето

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

TCP-порты

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

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

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

Разработка

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

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

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

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

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

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

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

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

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

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

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

Проводные данные TCP предоставляют наблюдателям на пути значительные возможности сбора и изменения информации, поскольку метаданные протокола передаются в открытом виде . [92] [93] Хотя эта прозрачность полезна для сетевых операторов [94] и исследователей, [95] информация, собранная из метаданных протокола, может снизить конфиденциальность конечного пользователя. [96] Эта видимость и пластичность метаданных привела к тому, что TCP стало трудно расширять — случай окостенения протокола — поскольку любой промежуточный узел (« middlebox ») может принимать решения на основе этих метаданных или даже изменять их, [97] [98] нарушая принцип сквозного соединения . [99] Одно измерение показало, что треть путей через Интернет сталкиваются по крайней мере с одним посредником, который изменяет метаданные TCP, и 6,5% путей сталкиваются с вредными эффектами окостенения от посредников. [100] Избегание рисков расширяемости от посредников наложило существенные ограничения на разработку MPTCP , [101] [102] и трудности, вызванные посредниками, затруднили развертывание TCP Fast Open в веб-браузерах . [103] Другим источником окостенения является сложность модификации функций TCP на конечных точках, как правило, в ядре операционной системы [104] или в оборудовании с механизмом разгрузки TCP . [105]

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

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

Установление соединения является основным фактором задержки, с которой сталкиваются веб-пользователи. [110] [111] Трехэтапное рукопожатие TCP вносит один RTT задержки во время установления соединения, прежде чем данные могут быть отправлены. [111] Для коротких потоков эти задержки очень значительны. [112] Безопасность транспортного уровня (TLS) требует собственного рукопожатия для обмена ключами при установлении соединения. Из-за многоуровневой конструкции рукопожатие TCP и рукопожатие TLS выполняются последовательно; рукопожатие TLS не может начаться, пока не завершится рукопожатие TCP. [113] Для установления соединения с TLS 1.2 по TCP требуются два RTT . [114] TLS 1.3 допускает возобновление соединения с нулевым RTT в некоторых обстоятельствах, но при наложении поверх TCP для рукопожатия TCP все еще требуется один RTT, и это не может помочь первоначальному соединению; Рукопожатия с нулевым RTT также представляют криптографические проблемы, поскольку эффективный, безопасный для повторного воспроизведения и прямой безопасный неинтерактивный обмен ключами является открытой темой для исследований. [115] TCP Fast Open позволяет передавать данные в начальных (т. е. SYN и SYN-ACK) пакетах, устраняя одну задержку RTT во время установления соединения. [116] Однако TCP Fast Open было сложно развернуть из-за окостенения протокола; по состоянию на 2020 год ни один веб-браузер не использовал его по умолчанию. [103]

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

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

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

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

Ускорение

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

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

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

Отладка

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

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

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

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

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

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

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

Протокол Venturi Transport Protocol (VTP) — запатентованный фирменный протокол , предназначенный для прозрачной замены TCP с целью преодоления предполагаемой неэффективности, связанной с беспроводной передачей данных.

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

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

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

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

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

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

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

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

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

Исходный адрес: 32 бита
Исходный адрес в заголовке IPv4
Адрес назначения: 32 бита
Адрес назначения в заголовке IPv4.
Нули: 8 бит; Нули == 0
Все нули.
Протокол: 8 бит
Значение протокола для TCP: 6 .
Длина TCP: 16 бит
Длина заголовка TCP и данных (измеряется в октетах). Например, предположим, что у нас есть пакет IPv4 с общей длиной 200 байт и значением IHL 5, что указывает на длину 5 × 32 бита = 160 бит = 20 байт. Мы можем вычислить длину TCP как , т.е. , что дает результат в байтах.

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

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

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

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

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

Исходный адрес: 128 бит
Адрес в заголовке IPv6.
Адрес назначения: 128 бит
Конечный пункт назначения; если пакет IPv6 не содержит заголовка маршрутизации, TCP использует адрес назначения в заголовке IPv6, в противном случае на исходном узле он использует адрес в последнем элементе заголовка маршрутизации, а на принимающем узле он использует адрес назначения в заголовке IPv6.
Длина TCP: 32 бита
Длина заголовка TCP и данных (измеряется в октетах).
Нули: 24 бита; Нули == 0
Все нули.
Следующий заголовок: 8 бит
Значение протокола для TCP: 6 .

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

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

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

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

Примечания

  1. ^ ab Добавлено в заголовок RFC 3168
  2. ^ По умолчанию единицами измерения размера Windows являются байты.
  3. ^ Размер окна зависит от сегмента, идентифицированного порядковым номером в поле подтверждения.
  4. ^ Эквивалентно, пара сетевых сокетов для источника и назначения, каждый из которых состоит из адреса и порта.
  5. ^ Согласно последнему стандарту HTTP/3 , в качестве транспорта вместо TCP используется QUIC .

Ссылки

  1. ^ Лабрадор, Мигель А.; Перес, Альфредо Дж.; Вайтман, Педро М. (2010). Информационные системы на основе определения местоположения, разрабатывающие приложения для отслеживания в реальном времени . CRC Press. ISBN 9781000556803.
  2. ^ Винтон Г. Серф; Роберт Э. Кан (май 1974 г.). «Протокол для пакетной сетевой интеркоммуникации» (PDF) . IEEE Transactions on Communications . 22 (5): 637–648. doi :10.1109/tcom.1974.1092259. Архивировано из оригинала (PDF) 4 марта 2016 г.
  3. ^ Беннетт, Ричард (сентябрь 2009 г.). «Создано для перемен: сквозные аргументы, инновации в Интернете и дебаты о нейтральности сети» (PDF) . Фонд информационных технологий и инноваций. стр. 11. Архивировано (PDF) из оригинала 29 августа 2019 г. . Получено 11 сентября 2017 г. .
  4. ^ RFC 675.
  5. ^ Рассел, Эндрю Лоуренс (2008). «Промышленные законодательные органы»: консенсусная стандартизация во Второй и Третьей промышленных революциях (диссертация).«См. Abbate, Inventing the Internet , 129–30; Vinton G. Cerf (октябрь 1980 г.). «Протоколы для взаимосвязанных пакетных сетей». ACM SIGCOMM Computer Communication Review . 10 (4): 10–11.; и RFC 760. doi : 10.17487/RFC0760 ."
  6. ^ Постел, Джон (15 августа 1977 г.), Комментарии к интернет-протоколу и TCP, IEN 2, архивировано из оригинала 16 мая 2019 г. , извлечено 11 июня 2016 г. , Мы портим дизайн интернет-протоколов, нарушая принцип многоуровневости. В частности, мы пытаемся использовать TCP для двух целей: служить сквозным протоколом уровня хоста и служить протоколом упаковки и маршрутизации интернета. Эти две вещи должны быть реализованы многоуровневым и модульным образом.
  7. ↑ Серф, Винтон Г. (1 апреля 1980 г.). «Заключительный отчет проекта Стэнфордского университета TCP».
  8. ^ Серф, Винтон Г.; Кейн, Эдвард (октябрь 1983 г.). «Модель архитектуры Интернета Министерства обороны». Компьютерные сети . 7 (5): 307–318. doi :10.1016/0376-5075(83)90042-9.
  9. ^ «Руководство по TCP/IP – Архитектура TCP/IP и модель TCP/IP». www.tcpipguide.com . Получено 11.02.2020 .
  10. ^ "Индекс заметок об эксперименте в Интернете". www.rfc-editor.org . Получено 21.01.2024 .
  11. ^ "Роберт Э. Кан – лауреат премии имени А. М. Тьюринга". amturing.acm.org . Архивировано из оригинала 2019-07-13 . Получено 2019-07-13 .
  12. ^ "Vinton Cerf – AM Turing Award Laureate". amturing.acm.org . Архивировано из оригинала 2021-10-11 . Получено 2019-07-13 .
  13. ^ abcdefghi Комер, Дуглас Э. (2006). Сетевое взаимодействие с TCP/IP: принципы, протоколы и архитектура . Том 1 (5-е изд.). Prentice Hall. ISBN 978-0-13-187671-2.
  14. ^ abc RFC 9293, 2.2. Ключевые концепции TCP.
  15. ↑ RFC 791, стр. 5–6.
  16. ^ abcd RFC 9293.
  17. ^ abc RFC 9293, 3.1. Формат заголовка.
  18. ^ RFC 9293, 3.8.5 Передача срочной информации.
  19. ^ RFC 9293, 3.4. Порядковые номера.
  20. ^ RFC 9293, 3.4.1. Выбор начального порядкового номера.
  21. ^ "Изменить RFC 3540 "Надежная явная сигнализация уведомлений о перегрузке (ECN) с одноразовыми числами" на исторический". datatracker.ietf.org . Получено 18.04.2023 .
  22. ↑ RFC 3168, стр. 13-14.
  23. ↑ RFC 3168, стр. 15.
  24. ^ RFC 3168, стр. 18-19.
  25. ^ RFC 793.
  26. ^ abc RFC 7323.
  27. ^ RFC 2018, 2. Вариант, разрешающий увольнение.
  28. ^ RFC 2018, 3. Формат опции Sack.
  29. ^ Хеффернан, Энди (август 1998 г.). «Защита сеансов BGP с помощью опции подписи TCP MD5». IETF . Получено 30 декабря 2023 г.
  30. ^ "Параметры протокола управления передачей (TCP): номера видов опций TCP". IANA. Архивировано из оригинала 2017-10-02 . Получено 2017-10-19 .
  31. ^ RFC 9293, 3.3.2. Обзор конечного автомата.
  32. ^ Куроуз, Джеймс Ф. (2017). Компьютерные сети: подход сверху вниз. Кейт В. Росс (7-е изд.). Харлоу, Англия. стр. 286. ISBN 978-0-13-359414-0. OCLC  936004518.{{cite book}}: CS1 maint: location missing publisher (link)
  33. ^ Таненбаум, Эндрю С. (2003-03-17). Компьютерные сети (четвертое издание). Prentice Hall. ISBN 978-0-13-066102-9.
  34. ^ RFC 1122, 4.2.2.13. Закрытие соединения.
  35. ^ Карн и Партридж 1991, стр. 364.
  36. ^ RFC 9002, 4.2. Монотонно возрастающие номера пакетов.
  37. ^ Матис; Мэтью; Семке; Махдави; Отт (1997). «Макроскопическое поведение алгоритма предотвращения перегрузки TCP». ACM SIGCOMM Computer Communication Review . 27 (3): 67–82. CiteSeerX 10.1.1.40.7002 . doi :10.1145/263932.264023. S2CID  1894993. 
  38. ↑ RFC 3522, стр. 4.
  39. ^ Leung, Ka-cheong; Li, Victor Ok; Yang, Daiqin (2007). «Обзор переупорядочения пакетов в протоколе управления передачей (TCP): проблемы, решения и задачи». Труды IEEE по параллельным и распределенным системам . 18 (4): 522–535. doi :10.1109/TPDS.2007.1011.
  40. ^ Йоханнессен, Мадс (2015). Исследование переупорядочения в Linux TCP (диссертация на степень магистра наук). Университет Осло.
  41. ^ Ченг, Юйчунг (2015). RACK: быстрое обнаружение потерь на основе времени для TCP draft-cheng-tcpm-rack-00 (PDF) . IETF94. Иокогама: IETF.
  42. ^ RFC 8985.
  43. ^ Ченг, Юйчунг; Кардвелл, Нил; Дуккипати, Нандита; Джа, Прияранджан (2017). RACK: быстрое восстановление потерь на основе времени draft-ietf-tcpm-rack-02 (PDF) . IETF100. Иокогама: IETF.
  44. ↑ RFC 6298, стр. 2.
  45. ^ ab Zhang 1986, стр. 399.
  46. ^ Карн и Партридж 1991, стр. 365.
  47. ^ Людвиг и Кац 2000, с. 31-33.
  48. ^ Гуртов и Людвиг 2003, стр. 2.
  49. ^ Гуртов и Флойд 2004, стр. 1.
  50. ^ ab RFC 6298, стр. 4.
  51. ^ Карн и Партридж 1991, стр. 370-372.
  52. ^ Оллман и Пэксон 1999, стр. 268.
  53. ↑ RFC 7323, стр. 7.
  54. ^ Стоун; Партридж (2000). «Когда контрольная сумма CRC и TCP не совпадает». Труды конференции по приложениям, технологиям, архитектурам и протоколам для компьютерной связи . Обзор компьютерной связи ACM SIGCOMM . С. 309–319. CiteSeerX 10.1.1.27.7611 . doi :10.1145/347059.347561. ISBN  978-1581132236. S2CID  9547018. Архивировано из оригинала 2008-05-05 . Получено 2008-04-28 .
  55. ^ RFC 5681.
  56. ^ RFC 6298.
  57. ^ RFC 1122.
  58. ^ RFC 2018, стр. 10.
  59. ^ RFC 9002, 4.4. Отказ невозможен.
  60. ^ "Масштабирование окна TCP и сломанные маршрутизаторы". LWN.net . Архивировано из оригинала 2020-03-31 . Получено 2016-07-21 .
  61. ^ RFC 3522.
  62. ^ "IP sysctl". Документация ядра Linux . Архивировано из оригинала 5 марта 2016 года . Получено 15 декабря 2018 года .
  63. ^ Ван, Ив. «TCP timestamp is disabled». Technet – Windows Server 2012 Essentials . Microsoft. Архивировано из оригинала 2018-12-15 . Получено 2018-12-15 .
  64. ^ Дэвид Мюррей; Терри Козинец; Себастьян Зандер; Майкл Диксон; Полихронис Кутсакис (2017). "Анализ изменяющихся характеристик трафика корпоративной сети" (PDF) . 23-я Азиатско-Тихоокеанская конференция по коммуникациям (APCC 2017). Архивировано (PDF) из оригинала 3 октября 2017 г. . Получено 3 октября 2017 г. .
  65. ^ Gont, Fernando (ноябрь 2008 г.). «О реализации срочных данных TCP». 73-я встреча IETF. Архивировано из оригинала 2019-05-16 . Получено 2009-01-04 .
  66. ^ Петерсон, Ларри (2003). Компьютерные сети . Морган Кауфманн. стр. 401. ISBN 978-1-55860-832-0.
  67. ^ Ричард У. Стивенс (ноябрь 2011 г.). TCP/IP Illustrated. Том 1, Протоколы . Addison-Wesley. стр. Глава 20. ISBN 978-0-201-63346-7.
  68. ^ "Оценка безопасности протокола управления передачей (TCP)" (PDF) . Архивировано из оригинала 6 марта 2009 г. Получено 2010-12-23 .{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  69. ^ Обзор методов усиления безопасности для реализаций протокола управления передачей (TCP)
  70. ^ Якоб Лелль (13 августа 2013 г.). "Быстрая слепая подмена TCP-подключения с помощью SYN-cookies". Архивировано из оригинала 22.02.2014 . Получено 05.02.2014 .
  71. ^ "Некоторые сведения о недавних уязвимостях TCP DoS (отказ в обслуживании)" (PDF) . Архивировано из оригинала (PDF) 2013-06-18 . Получено 2010-12-23 .
  72. ^ "Эксплуатация TCP и бесконечности постоянного таймера". Архивировано из оригинала 2010-01-22 . Получено 2010-01-22 .
  73. ^ "PUSH and ACK Flood". f5.com . Архивировано из оригинала 2017-09-28 . Получено 2017-09-27 .
  74. ^ Лоран Жоншерей (1995). "Простая активная атака против TCP" (PDF) . Получено 2023-06-04 .
  75. ^ Джон Т. Хаген; Барри Э. Маллинс (2013). "TCP veto: новая сетевая атака и ее применение к протоколам SCADA". 2013 IEEE PES Innovative Smart Grid Technologies Conference (ISGT) . Innovative Smart Grid Technologies (ISGT), 2013 IEEE PES . стр. 1–6. doi :10.1109/ISGT.2013.6497785. ISBN 978-1-4673-4896-6. S2CID  25353177.
  76. ^ RFC 9293, 4. Глоссарий.
  77. ↑ RFC 8095, стр. 6.
  78. ^ Пааш и Бонавентура 2014, с. 51.
  79. ^ RFC 6182.
  80. ^ RFC 6824.
  81. ^ Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). «Улучшение производительности и надежности центров обработки данных с помощью многопутевого TCP». ACM SIGCOMM Computer Communication Review . 41 (4): 266. CiteSeerX 10.1.1.306.3863 . doi :10.1145/2043164.2018467. Архивировано из оригинала 2020-04-04 . Получено 2011-06-29 . 
  82. ^ "MultiPath TCP – реализация ядра Linux". Архивировано из оригинала 2013-03-27 . Получено 2013-03-24 .
  83. ^ Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). «Насколько сложно это может быть? Проектирование и реализация развертываемого многопутевого TCP». Usenix NSDI : 399–412. Архивировано из оригинала 2013-06-03 . Получено 2013-03-24 .
  84. ^ Bonaventure; Seo (2016). "Multipath TCP Deployments". Журнал IETF . Архивировано из оригинала 2020-02-23 . Получено 2017-01-03 .
  85. ^ Криптографическая защита потоков TCP (tcpcrypt). Май 2019. doi : 10.17487/RFC8548 . RFC 8548.
  86. ^ Майкл Керриск (2012-08-01). "TCP Fast Open: ускорение веб-сервисов". LWN.net . Архивировано из оригинала 2014-08-03 . Получено 2014-07-21 .
  87. ^ RFC 7413.
  88. ^ RFC 6937.
  89. ^ Григорик, Илья (2013). Высокопроизводительные сетевые браузеры (1-е изд.). Пекин: O'Reilly. ISBN 978-1449344764.
  90. ^ RFC 6013.
  91. ^ RFC 7805.
  92. ↑ RFC 8546, стр. 6.
  93. ↑ RFC 8558, стр. 3.
  94. ^ RFC 9065, 2. Текущее использование транспортных заголовков в сети.
  95. ^ RFC 9065, 3. Исследования, разработки и внедрение.
  96. ↑ RFC 8558, стр. 8.
  97. ^ RFC 9170, 2.3. Многосторонние взаимодействия и промежуточные устройства.
  98. ^ RFC 9170, A.5. TCP.
  99. ^ Папастерджиу и др. 2017, с. 620.
  100. ^ Эделин и Доннет 2019, с. 175-176.
  101. ^ Райчиу и др. 2012, стр. 1.
  102. ^ Хесманс и др. 2013, стр. 1.
  103. ^ ab Рыбчинская 2020.
  104. ^ Папастерджиу и др. 2017, с. 621.
  105. ^ Корбет 2015.
  106. ^ Бриско и др. 2016, стр. 29–30.
  107. ^ Маркс 2020, Блокировка HOL в HTTP/1.1.
  108. ^ Маркс 2020, Бонус: Контроль транспортных заторов.
  109. ^ Рабочая группа IETF HTTP, Почему только одно TCP-соединение?.
  110. ^ Корбет 2018.
  111. ^ ab RFC 7413, стр. 3.
  112. ^ Sy et al. 2020, стр. 271.
  113. ^ Чен и др. 2021, стр. 8-9.
  114. ^ Гедини 2018.
  115. ^ Чен и др. 2021, стр. 3-4.
  116. ↑ RFC 7413, стр. 1.
  117. ^ Блэнтон и Оллман 2002, стр. 1-2.
  118. ^ Блэнтон и Оллман 2002, стр. 4-5.
  119. ^ Блэнтон и Оллман 2002, стр. 3-4.
  120. ^ Блэнтон и Оллман 2002, стр. 6-8.
  121. ^ Брюерон, Хемон и Чжан 1998, стр. 67.
  122. ^ Брюерон, Хемон и Чжан 1998, стр. 72.
  123. ^ Бхат, Ризк и Цинк 2017, стр. 14.
  124. ^ RFC 9002, 4.5. Дополнительные диапазоны ACK.
  125. ^ ab "Производительность TCP по CDMA2000 RLP". Архивировано из оригинала 2011-05-03 . Получено 2010-08-30 .
  126. ^ Мухаммад Адил и Ахмад Али Икбал (2007). "Оптимизация окна перегрузки TCP для сетей пакетной передачи данных CDMA2000". Четвертая международная конференция по информационным технологиям (ITNG'07) . стр. 31–35. doi :10.1109/ITNG.2007.190. ISBN 978-0-7695-2776-5. S2CID  8717768.
  127. ^ "TCP Acceleration". Архивировано из оригинала 2024-04-22 . Получено 2024-04-18 .
  128. ^ Юньхонг Гу, Синьвэй Хун и Роберт Л. Гроссман. «Анализ алгоритма AIMD с уменьшающимися увеличениями». Архивировано 05.03.2016 на Wayback Machine . 2004.
  129. ^ RFC 8200.
  130. ^ "Wireshark: Offloading". Архивировано из оригинала 2017-01-31 . Получено 2017-02-24 . Wireshark захватывает пакеты до того, как они будут отправлены на сетевой адаптер. Он не увидит правильную контрольную сумму, потому что она еще не рассчитана. Хуже того, большинство ОС не утруждают себя инициализацией этих данных, поэтому вы, вероятно, видите небольшие фрагменты памяти, которые не должны видеть. Новые установки Wireshark 1.2 и выше по умолчанию отключают проверку контрольной суммы IP, TCP и UDP. При необходимости вы можете отключить проверку контрольной суммы в каждом из этих диссекторов вручную.
  131. ^ "Wireshark: Контрольные суммы". Архивировано из оригинала 2016-10-22 . Получено 2017-02-24 . Выгрузка контрольных сумм часто вызывает путаницу, поскольку сетевые пакеты, которые должны быть переданы, передаются Wireshark до того, как контрольные суммы фактически вычисляются. Wireshark получает эти "пустые" контрольные суммы и отображает их как недействительные, хотя пакеты будут содержать действительные контрольные суммы, когда они позже покинут сетевое оборудование.

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

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

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

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

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

В Викиверситете есть обучающие ресурсы по протоколу управления передачей
На Викискладе есть медиафайлы по теме «Протокол управления передачей».