TCP надежность транспорта
Мы все знакомы с протоколом TCP как надежный транспортный протокол, но как он обеспечивает надежность транспорта?
Для достижения надежной передачи необходимо учитывать много факторов, таких как коррупция данных, потеря, дублирование и наручные осколки. Если эти проблемы не могут быть решены, надежная передача не может быть достигнута.
Следовательно, в TCP используются такие механизмы, как номер последовательности, ответ на подтверждение, управление отправкой, управление соединением и управление окном для достижения надежной передачи.
В этой статье мы сосредоточимся на скользящем окне, управлении потоком и контролем заторов TCP. Механизм ретрансляции покрывается отдельно в следующем разделе.
Контроль сетевого потока
Контроль сетевого потока или знание как управление сетевым трафиком на самом деле является проявлением тонкой связи между производителями и потребителями. Вы, наверное, много сталкивались с этим сценарием на работе или в интервью. Если способность производителя производить значительно превышает способность потребителя потреблять, это приведет к росту очереди на неопределенный срок. В более серьезном случае вы можете знать, что когда сообщения RabbitMQ накапливаются слишком много, это может вызвать снижение производительности всего сервера MQ. То же самое верно для TCP; Если в сеть останется неконтролируемое, в сеть будет помещено слишком много сообщений, и потребители превысят свои возможности, в то время как производители будут продолжать отправлять дублирующиеся сообщения, что значительно повлияет на производительность сети.
Чтобы решить это явление, TCP предоставляет для отправителя механизм для управления объемом данных, отправляемых на основе фактической емкости приемника, который известен как управление потоком. Получатель поддерживает окно приема, в то время как отправитель поддерживает окно отправки. Следует отметить, что эти окна предназначены только для одного соединения TCP, и не все подключения совместно используют окно.
TCP обеспечивает управление потоком, используя переменную для окна приема. Окно приема дает отправителю указание на то, сколько места в кеше все еще доступно. Отправитель контролирует объем данных, отправляемых в соответствии с фактической приемной емкостью получателя.
Приемный хост уведомляет отправителя о размере полученных данных, и отправитель отправляет до этого предела. Этот предел - размер окна, помните заголовок TCP? Существует поле для приема, которое используется для указания количества байтов, которое получатель способен или готов получить.
Хост отправителя будет периодически отправлять пакет для зонда окон, который используется для определения того, может ли хост приемника до сих пор принимать данные. Когда буфер приемника находится под угрозой переполнения, размер окна устанавливается на меньшее значение для того, чтобы поручить отправителю контролировать количество отправленных данных.
Вот схема управления сетевым потоком:
Контроль заторов сети
Прежде чем вводить контроль за перегрузками, мы должны понимать, что в дополнение к окну приема и окну отправки также есть окно заторов, которое в основном используется для решения проблемы, по какой скорости отправитель начинает отправлять данные в окно приема. Следовательно, окно заторов также поддерживается отправителем TCP. Нам нужен алгоритм, чтобы решить, сколько данных подходит для отправки, поскольку отправка слишком мало или слишком много данных не является идеальной, следовательно, концепция окна заторов.
В предыдущем управлении сетевым потоком мы избегали, что отправитель заполнял кэш приемника данными, но мы не знали, что происходит в сети. Как правило, компьютерные сети находятся в общей среде. В результате может возникнуть перегрузка сети из -за связи между другими хостами.
Когда сеть перегружена, если большое количество пакетов будет отправлено, это может вызвать такие проблемы, как задержка и потеря пакетов. На этом этапе TCP будет повторно передавать данные, но ретрансляция увеличит бремя в сети, что приведет к большим задержкам и большему количеству потерь пакетов. Это может попасть в порочный цикл и продолжать становиться больше.
Таким образом, TCP не может игнорировать то, что происходит в сети. Когда сеть перегружена, TCP приносится в жертву, уменьшая объем отправленных данных.
Следовательно, предлагается контроль заторов, целью которого является избежать заполнения всей сети данных от отправителя. Чтобы регулировать объем данных, которые должен отправлять отправитель, TCP определяет концепцию, называемую окном заторов. Алгоритм управления перегрузками будет регулировать размер окна заторов в соответствии с степенью перегрузки сети, чтобы контролировать объем данных, отправляемых отправителем.
Что такое окно заторов? Какое это имеет отношение к окну отправки?
Окно перегрузки - это переменная состояния, поддерживаемая отправителем, которая определяет объем данных, которые отправитель может отправить отправитель. Окно перегрузки динамически изменяется в зависимости от уровня перегрузки сети.
Окно отправки - это согласованный размер окна между отправителем и приемником, который указывает сумму данных, которые может получить приемник. Окно перегрузки и отправляющее окно связаны; Отправляющее окно обычно равно минимуму заторов и приемных окон, то есть swnd = min (cwnd, rwnd).
Окно заторов изменяется следующим образом:
Если в сети нет перегрузки, то есть, время ожидания ретрансмиссии, окно перерыва увеличивается.
Если в сети застойны, окно перегрузки уменьшается.
Отправитель определяет, перегружен ли сеть, наблюдая, получен ли пакет подтверждения ACK в течение указанного времени. Если отправитель не получает пакет подтверждения ACK в течение указанного времени, считается, что сеть перегружена.
В дополнение к окну перегрузки пришло время обсудить алгоритм контроля заторов TCP. Алгоритм контроля перегрузки TCP состоит из трех основных частей:
Медленный старт:Первоначально окно заторов CWND является относительно невелико, и отправитель увеличивает окно заторов в геометрической прогрессии, чтобы быстро адаптироваться к емкости сети.
Отказ от заторов:После того, как окно перегрузки превышает определенный порог, отправитель линейно увеличивает окно заторов, чтобы замедлить скорость роста окна заторов и избежать перегрузки сети.
Быстрое восстановление:Если возникает перегрузка, отправитель вдвое увеличивает окно перегрузки и входит в состояние быстрого восстановления, чтобы определить местонахождение сети через полученные дублируемые акки, а затем продолжает увеличивать окно заторов.
Медленный старт
Когда соединение TCP установлено, окно заторов и первоначально устанавливается на минимальное значение MSS (максимальный размер сегмента). Таким образом, начальная скорость отправки составляет около MSS/RTT Byts/Second. Фактическая доступная полоса пропускания обычно намного больше, чем MSS/RTT, поэтому TCP хочет найти оптимальную скорость отправки, которая может быть достигнута с помощью медленного начала.
В процессе медленного начала значение CWND окна перегрузки будет инициализировано до 1 MSS, и каждый раз, когда будет признан переданный сегмент пакета, значение CWND будет увеличено на одну MSS, то есть значение CWND станет 2 MSS. После этого значение CWND удваивается для каждой успешной передачи сегмента пакета и так далее. Конкретный процесс роста показан на следующем рисунке.
Однако скорость отправки не всегда может расти; Рост должен закончиться когда -нибудь. Итак, когда закончится увеличение скорости отправки? Медленное начало обычно заканчивает увеличение скорости отправки одним из нескольких способов:
Первый путь - это случай потери пакета в процессе отправки медленного запуска. Когда происходит потеря пакета, TCP устанавливает окно перегрузки отправителя CWND на 1 и перезапускает медленный процесс. На этом этапе вводится концепция порога медленного запуска, начальное значение которого составляет половину значения CWND, которое генерирует потерю пакетов. То есть, когда обнаруживается затора, значение SSthresh составляет половину значения окна.
Второй способ состоит в том, чтобы напрямую коррелировать со значением медленного порога SSTHRESH. Поскольку значение SSTHRESH составляет половину значения окна при обнаружении перегрузки, потери пакета могут происходить с каждым удвоением, когда CWND больше, чем SSthresh. Следовательно, лучше всего установить CWND на SSTHRESH, что приведет к тому, что TCP переключится на режим управления перегрузками и заканчиваться медленным началом.
Последний путь, который может закончиться медленным стартом, - если обнаружены три избыточных тумана, TCP выполняет быструю повторную передачу и входит в состояние восстановления. (Если неясно, почему есть три пакета ACK, это будет объяснено отдельно в механизме повторного передачи.)
Отказ от заторов
Когда TCP входит в состояние контроля заторов, CWND устанавливается на половину порога заторов. Это означает, что значение CWND не может быть удвоено каждый раз, когда получается сегмент пакета. Вместо этого принимается относительно консервативный подход, в котором значение CWND увеличивается только одним MSS (максимальная длина сегмента пакетов) после завершения каждой передачи. Например, даже если признаются 10 сегментов пакетов, значение CWND будет увеличиваться только на одну MSS. Это линейная модель роста, которая также имеет верхнюю границу роста. Когда происходит потеря пакетов, значение CWND изменяется на MSS, а значение SSTHRESH устанавливается на половину CWND. Или это также остановит рост MSS, когда будут получены 3 избыточных ответа ACK. Если три избыточных акка все еще получают после вдвое значение значения CWND, значение SSTHRESH регистрируется как половина значения CWND, и введено состояние быстрого восстановления.
Быстрое восстановление
В состоянии быстрого восстановления ценность окна заторов CWND увеличивается на один MSS для каждого полученного избыточного ACK, то есть ACK, который не поступает в последовательности. Это должно использовать сегменты пакетов, которые были успешно переданы в сети, чтобы максимально повысить эффективность передачи.
Когда появляется ACK сегмента потерянного пакета, TCP уменьшает значение CWND, а затем входит в состояние избегания заторов. Это должно контролировать размер окна заторов и избежать дальнейшего увеличения заторов сети.
Если время ожидания происходит после состояния контроля перегрузки, состояние сети становится более серьезным, и TCP мигрирует из состояния избегания заторов в медленное состояние. В этом случае значение CWND окна заторов установлено на 1 MSS, максимальную длину сегмента пакета, а значение порогового порога медленного начала установлено на половину CWND. Цель этого состоит в том, чтобы повторно увеличить размер окна перегрузки после восстановления сети, чтобы сбалансировать скорость передачи и степень заторов сети.
Краткое содержание
В качестве надежного транспортного протокола TCP реализует надежный транспорт по номеру последовательности, подтверждению, управлению повторной передачей, управлением соединением и управлением окном. Среди них механизм управления потоком контролирует объем данных, отправляемых отправителем в соответствии с фактической приемной емкостью приемника, что позволяет избежать проблем заторов сети и ухудшения производительности. Механизм контроля заторов позволяет избежать возникновения перегрузки сети путем настройки объема данных, отправляемых отправителем. Концепции окна перегрузки и отправки окна связаны друг с другом, а объем данных у отправителя контролируется путем динамической регулировки размера окна заторов. Медленный запуск, устранение заторов и быстрое восстановление - это три основные части алгоритма управления затоки TCP, которые регулируют размер окна заторов посредством различных стратегий, чтобы адаптироваться к емкости и степени заторов в сети.
В следующем разделе мы подробно рассмотрим механизм ретрансляции TCP. Механизм ретрансмиссии является важной частью TCP для достижения надежной передачи. Он обеспечивает надежную передачу данных путем повторного передачи потерянных, поврежденных или отсроченных данных. Принцип реализации и стратегия механизма повторной передачи будут введены и подробно проанализированы в следующем разделе. Следите за обновлениями!
Время сообщения: 24-2025 февраля
