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

редактировать
Основной протокол, используемый для потоковой передачи данных по IP-сети

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

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

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

Содержание
  • 1 Историческое происхождение
  • 2 Сетевая функция
  • 3 Структура сегмента TCP
  • 4 Работа протокола
    • 4.1 Установление соединения
    • 4.2 Завершение соединения
    • 4.3 Использование ресурсов
    • 4.4 Передача данных
      • 4.4.1 Надежная передача
        • 4.4. 1.1 Повторная передача на основе дупаков
        • 4.4.1.2 Повторная передача на основе тайм-аута
      • 4.4.2 Обнаружение ошибок
      • 4.4.3 Управление потоком
      • 4.4.4 Управление перегрузкой
    • 4.5 Максимальный размер сегмента
    • 4.6 Выборочные подтверждения
    • 4.7 Масштабирование окна
    • 4.8 Временные метки TCP
    • 4.9ние данные
    • 4.10 Принудительная доставка данных
  • 5 Уязвимости
    • 5.1 Отказ в обслуживании
    • 5.2 Перехват соединения
    • 5.3 Вето TCP
  • 6 TCP-порты
  • 7 Разработка
  • 8 TCP в беспроводных сетях
  • 9 Аппаратные реализации
  • 10 От ладка
  • 11 Альтернативы
  • 12 Вычисление контрольной суммы
    • 12.1 TCP контрольная сумма для IPv4
    • 12.2 Контрольная сумма TCP для IPv6
    • 12.3 Выгрузка контрольной суммы
  • 13 Документы RFC
  • 14 См. также
  • 15 Примечания
  • 16 Ссылки
  • 17 Дополнительная литература
  • 18 Внешние ссылки
Историческое происхождение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заголовок сегмента TCP
С ущербОктет 0123
ОктетБит 76543210765432107654321076543210
00Порт источникаПорт назначения
432Порядковый номер
864Номер подтверждения (если установлен ACK)
1296Смещение данныхЗарезервировано. 0 0 0NSCWRECEURGACKPSHRSTSYNFINРазмер окна
16128Контрольная суммаСрочный указатель (если установлен УРГ)
20....160....Параметры (если смещение данных>5. При необходимости дополняется в конце байтами «0».)....
Порт источника (16 бит)
Определяет порт отправителя.
Порт назначения (16 битов))
Определяющий принимающий порт.
Порядковый номер (32 бита)
Имеет двойную роль:
  • Если установлен флаг SYN (1), то это начальный порядковый номер. Тогда порядковый номер фактического первого байта данных и подтвержденный номер в соответствующем ACK равны этому порядковому номеру плюс 1.
  • Если флаг SYN сброшен (0), то это накопленный порядковый номер первого байт данных этого сегмента для текущего сеанса.
Номер подтверждения (32 бита)
Если установлен флаг ACK, то значение этого поля является следующим порядковым номером, который отправитель ACK ожидая. Это подтверждает получение всех предыдущих байтов (если есть). Первый ACK, отправленный каждой стороной, подтверждает сам начальный порядковый номер другой стороны, но не данные.
Смещение данных (4 бита)
Определение размера заголовка TCP в 32-битном формате слова. Минимальный размер заголовка составляет 5 слов, а максимальный - 15 слов, что дает минимальный размер 20 байтов и максимум 60 байтов, что позволяет использовать до 40 байтов параметров в заголовке. Это поле получило свое название из-за того, что это также смещение от начала сегмента TCP до фактических данных.
Зарезервировано (3 бита)
Для будущего использования и должно быть установлено до нуля.
Флаги (9 бит)
Содержит 9 1-битных флагов (управляющих битов), а именно:
  • NS (1 бит): ECN-nonce - маскирование защиты
  • CWR (1 бит): флаг уменьшения окна перегрузки (CWR) устанавливается-отправителем, чтобы указать, что он получил сегмент TCP с установленным флагом ECE и ответил в механизме управления перегрузкой.
  • ECE (1 бит): ECN-Echo выполняет двойную роль в зависимости от значения флага SYN. Он указывает:
  • Если установлен флаг SYN (1), то TCP-узел ECN способен.
  • Если флаг SYN снят (0), то пакет с Установлен флаг перегрузки (ECN = 11) в заголовке IP во время нормальной передачи. Это служит индикатором перегрузки (или надвигающейся перегрузки) для отправителя TCP.
  • URG (1 бит): указывает, что поле указателя срочности имеет значение
  • ACK (1 бит): указывает, что Поле подтверждения является значимым. Этот флаг должен быть установлен для всех пакетов после исходного SYN-пакета, отправленного клиентом.
  • ПШ (1 бит): функция push. Просит передать буферизованные данные в принимающее приложение.
  • RST (1 бит): сбросить соединение
  • SYN (1 бит): синхронизировать порядковые номера. Этот флаг должен быть установлен только для первого пакета, отправленного с каждой стороны. Некоторые другие флаги и поля меняют значения в зависимости от этого флага, и некоторые из них действуют, только если они установлены, а другие - когда они сняты.
  • FIN (1 бит): последний пакет от отправителя
Размер окна (16 бит)
Размер окна приема, который определяет количество единиц размера окна, которые отправитель этого сегмента в настоящее время желает получить. (См. § Управление потоком и § Масштабирование окна.)
Контрольная сумма (16 бит)
16-битное поле контрольной суммы используется для проверки ошибок Псевдо-заголовок состоит из исходного IP-адреса, IP-адреса назначения, номера протокола для протокола TCP (6) заголовка TCP, полезной нагрузки и псевдозаголовка.
Срочный указатель (16 бит)
Если установлен флаг URG, то это 16 -битовое поле - это смещение от порядкового номера, последнего последнего
Опции (переменная 0–320 бит, в единицах 32 бита)
Длина этого поля определяется полем с размером данных. Параметры могут иметь до трех полей: Option-Kind (1 байт), Option-Length (1 байт), Option-Data (переменная). Поле Option-Kind указывает тип и является единственным полем, которое не является необязательным. ь установлены следующие два поля. - это общая длина опции, а 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; они обозначены ниже как. Тип и стандартная указаны как (Тип опции, Длина опции).
Вид опцииДлина опцииДанные опцииНазначениеПримечания
0Н / ДН / ДКонец списка опций
1Н / ДН / ДНет операцииЭто может быть роман для выравнивания полей опций по 32-битным границам для повышения производительности.
24ССМаксимальный размер сегментаСм. § Максимальный размер сегмента
33SМасштаб окнаПодробнее см. § Масштабирование окна
42Н / ДРазрешено выборочное подтверждениеПодробнее см. § Выборочные подтверждения
5N (10, 18, 26 или 34)BBBB, EEEE,...Избирательное подтверждение (SACK)За этими первыми двумя байтами следует список из 1–4 блоков, перечисленных как 32-битные указатели начала / конца.
810TTTT, EEEEОтметка времени и эхо предыдущей отметки времениПодробнее см. § Временные отметки TCP.
Оставшийся вариант - Значения вида историческими, устаревшими, экспериментальными, еще не стандартизованными или не присвоенными. Назначение номеров опций поддерживается IANA.
Заполнение
Заполнение заголовка TCP используется, чтобы опасность, что заголовок TCP заканчивается, а данные начинаются на 32-битной границе. Заполнение состоит из нулей.
Операция протокола
Упрощенная диаграмма состояний TCP. См. диаграмму TCP EFSM для более подробной диаграммы состояний, включая состояния внутри состояния УСТАНОВЛЕНО.

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

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

LISTEN
(server) представляет собой ожидание запроса на соединение любого удаленного конца TCP. -точка.
SYN-SENT
(клиент) представляет ожидание соответствующего запроса на соединение после отправки запроса на соединение.
SYN-RECEIVED
(сервер) представляет ожидание подтверждения подтверждения запроса на соединение после получения и отправки запроса на соединение.
ESTABLISHED
(и сервер, и клиент) представляет открытое соединение, полученные данные могут быть доставлены пользователю. Нормальное состояние для фазы передачи данных соединения.
FIN-WAIT-1
(и сервер, и клиент) представляет ожидание запроса на завершение соединения от удаленного TCP или подтверждения ранее отправленного запроса на завершение соединения.
FIN-WAIT-2
(и сервер, и клиент) означает ожидание запроса на прекращение соединения от удаленного TCP.
ЗАКРЫТЬ -WAIT
(и сервер, и клиент) означает ожидание запроса на прекращение соединения от локального пользователя.
ЗАКРЫТИЕ
(и сервер, и клиент) означает ожидание соединения подтверждение запроса на завершение от удаленного TCP.
LAST-ACK
(как сервер, так и клиент) представляет ожидание подтверждения запроса на завершение соединения, ранее отправленного удаленному TCP (который включает подтверждение запроса на завершение соединения).
TIME-WAIT
(сервер или клиент) означает ожидание достаточного количества t Время передать, чтобы убедиться, что удаленный TCP получил подтверждение своего запроса на разрыв соединения. [Согласно RFC 793 соединение может оставаться в режиме TIME-WAIT не более четырех минут, известных как два максимального срока жизни сегмента (MSL).]
ЗАКРЫТО
(и сервер, и клиент) представляют состояние отсутствия соединения вообще.

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

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

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

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

Завершение соединения

Завершение соединения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Повторная передача на основе дупаков

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

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

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

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

>Злоумышленники с отказом в обслуживании.

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

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

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

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

TCP использует скользящее окно поток протокол управления. В каждом сегменте 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 на сетевом пути между

Последняя правка сделана 2021-06-11 09:57:24
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте