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