В прошлой статье мы рассматривали управление потоком в TCP, это способ предотвращения отправки в сеть слишком большого количества сегментов, которые не могут быть приняты получателем, у которого просто недостаточно и места в буфере.
Получатель, при отправке каждого подтверждения, указывает в сегменте размер окна, количество байт, которые он может принять. Отправлять больше данных в сеть не имеет смысла.
Но возможна и другая проблема. В буфере получателя может быть достаточно свободного места, но сеть, через которую передаются данные, перегружена.
Одновременно, большое количество компьютеров решили передавать данные, маршрутизаторы не способны передать такое большое количество пакетов в единицу времени и они вынуждены отбрасывать пакеты. В этом случае происходит перегрузка, отправители передают в сеть большое количество данных, однако большая часть из этих данных отбрасываются маршрутизаторами и не доходит до получателей. Таким образом, большая часть каналов сети занята, но полезные данные от отправителя до получателя почти не доходят.
Коллапс перезагрузки
Первый раз такая ситуация произошла в интернет в 1986 году, она называлась коллапс перегрузки, хотя теоретически она была предсказана раньше. Чтобы решить эту проблему, стали учитывать загрузку сети при формировании размера окна, то есть при определении количества сегментов, которые можно отправить в сеть, не дожидаясь получения подтверждения.
Если раньше, до коллапса перегрузки, такое количество сегментов всегда было одинаково 8 штук, то после коллапса перегрузки решили, что это количество нужно определять динамически в зависимости от того загружена сеть или нет. И для того чтобы определить количество сегментов, которое можно отправить в сеть, используется окно перегрузки.
Окно перегрузки в TCP
Таким образом в TCP у нас есть два типа окна. Окно управления потоком, которое мы рассматривали в статье Протокол TCP Управление Потоком. Размер этого окна задаются получателем, в зависимости от того сколько места в буфере, и передается отправителю в сегментах с подтверждением.
Окно перегрузки, существует на стороне отправителя, его размер рассчитывается отправителем в зависимости от того, какая нагрузка на сеть, а не от того сколько данных может принять приложение. Приложение может быть готово принять много данных, но сеть загружена, в этом случае отправлять так много данных не имеет смысла.
Управление скоростью передачи в TCP
Оба типа окна, окно управления потоком и окно перегрузки, используются для решения более общей задачи управление скоростью передачи данных в TCP. Если размер скользящего окна будет слишком маленьким, то в сеть мы будем отправлять маленькое количество сегментов, сеть будет не загружена полностью, и скорость передачи будет маленькой, ниже чем возможно.
С другой стороны, если мы будем отправлять в сеть большое количество сегментов, то сеть может оказаться перегруженной, маршрутизаторы начнут отбрасывать наши сегменты, их нужно будет отправлять заново и скорость передачи данных опять окажется низкой. Таким образом нам нужно определить оптимальный размер окна, для того чтобы мы могли передавать данные по сети избегая загрузки, и приложение могло принять эти данные, и записать их в свой буфер.
AIMD
В TCP для определения размера окна перегрузки используется метод аддитивного увеличения, мультипликативного уменьшения. Суть метода заключается в том, что при получении каждого подтверждения, мы прибавляем к размеру окна некоторые значения, как правило это размер одного сегмента TCP, а если перегрузка произошла, то мы умножаем размер окна на некоторые значения. Как правило это 1/2, то есть в TCP при перегрузке, размер окна уменьшается в два раза.
- Где a максимальный размер сегмента (MSS);
- b- 1/2.
Вот график работы метода аддитивного увеличения, мультипликативного уменьшения. Мы начинаем передавать данные, поступает подтверждение,размер окна увеличивается, происходит аддитивное увеличение. Затем в сети произошла перегрузка, размер окна уменьшается в два раза, произошло мультипликативное уменьшение.
Затем данные снова передаются, размера окна при получение каждого подтверждения увеличивается на один сегмент, аддитивные увеличения. И так происходит пока не произойдет следующая перегрузка. Таким образом, размер окна у нас напоминают зубья пилы.
Сигнал о перезагрузке
Как отправитель узнает, о том что в сети произошла перегрузка? Это достаточно сложная задача, потому что сеть может быть составной, и перегрузка может происходить не на том сегменте сети, который подключен к отправителю, а на каком-то сегменте между отправителем и получателем, который находятся достаточно далеко от того и другого.
Чаще всего на практике, в качестве сигнала перегрузки используется потеря сегмента. Считается, что сейчас каналы связи уже хорошего качества и если произошла потеря сегмента, то не из-за ошибки канала, а из-за того, что сеть перегружена, поэтому нужно уменьшить размер окна, для того чтобы избежать дальнейшей перегрузки.
Медленный старт
Метод аддитивного увеличения мультипликативного уменьшения хорошо работал на медленных каналах связи, которые были во времена создания сети интернет, но у на современных, быстрых и надежных каналах связи, этот метод работает плохо. С помощью аддитивного увеличения, размер окна перегрузкой увеличивается очень медленно, для того чтобы решить эту проблему был предложен другой метод управления размером окна медленный старт.
При медленном старте размер окна увеличивается на каждое подтверждение не на 1 сегмент, а на 2, благодаря этому происходит экспоненциальное увеличение размера окна. Сначала мы отправляем один сегмент, получили подтверждение, отправляем два сегмента, получили 2 подтверждения, на каждое подтверждение отправляем по два сегмента всего 4, потом 8, потом 16 и так далее. То есть несмотря на название медленный старт, размер окна увеличивается гораздо быстрее, чем при аддитивном увеличении, мультипликативном уменьшении.
Недостаток метода заключается в том, что если произошла потеря сегмента, то размер окна уменьшается до нуля. Таким образом медленный старт быстро разгоняется, но также быстро тормозится.
В TCP используется комбинация медленного старта и аддитивного увеличения мультипликативного уменьшения. Cначала используется медленный старт, для того, чтобы быстро заполнить доступную пропускную способность канала. После того, как размер окна достиг определенного значения, порог медленного старта, происходит переход на аддитивное увеличение мультипликативное уменьшение. И дальше уже используется этот метод, размер окна увеличивается медленно, но если пришел сигнал о перегрузке, размер окна уменьшается в два раза, а не снижается до нуля.
Порог медленного старта определяется следующим образом. Сначала запускается медленный старт и работает до того, пока не поступит сигнал о перегрузке, после этого размера окна при котором пришел сигнал о перегрузке делится в два раза, и это значение выбирается порогом медленно старта. Таким образом, формируется достаточный запас размера окна, для того чтобы не произошла перегрузка, которые при аддитивном увеличении скорее всего не будет достигнут, если конечно загрузка сети останется на том же самом уровне.
Проблемы сигнала потеря сегмента
Если использовать потерю сегментов в качестве сигнала и перегрузки, то TCP фактически будет работать в режиме, который ведёт к перегрузке. TCP постоянно увеличивает размер окна пока перегрузка не произойдет, причем о перегрузке TCP узнает только после того, как она произошла, поэтому предотвратить ее при такой схеме нельзя.
Другая проблема называется глобальной синхронизацией TCP и TCP global synchronization, она заключается в том, что когда на маршрутизаторе на котором произошла перегрузка заканчивается место в буфере, он отбрасывает сегменты всех отправителей.
Отправитель обнаруживает потерю сегмента, понимает что произошла перегрузка уменьшает размер окна. В TCP в отличии от Ethernet или wi-fi, не встроена схема рандомизированное задержки, поэтому все отправители после уменьшения размера окна начинают передавать данные примерно в одно и то же время. В результате на маршрутизатор опять приходит большое количество пакетов, что в свою очередь ведет к перегрузке. Для того чтобы решить эти проблемы используются другие сигналы о перегрузке, которые мы сейчас рассмотрим.
Задержка сегмента
Один из возможных вариантов, задержка сегмента. В этом случае измеряется round trip time (RTT) время движения сегмента от отправителя до получателя и обратно.
Отправитель передавая сегменты, засекает RTT, измеряет средние время, и при существенном увеличении RTT уменьшается размер окна перегрузки.
Измерение времени задержки сегмента, позволяет обнаружить перегрузку до того как она произошла, но задержка может быть вызвана не только перегрузкой, но и другими причинами. Поэтому задержка сегмента не такой надежный сигнал, как его потеря.
Другая проблема заключается в том, что когда мы используем такой сигнал о перегрузке на загруженных каналах связи, то это приводит к не справедливому распределению пропускной способности. Наш компьютер начинает уменьшать размер окна перегрузки, когда увеличивается время задержки сегмента, в то же время другие компьютеры, которые используют сигнал о перегрузке потери сегмента, продолжают увеличивать размер окна пока перегрузка не произойдет.
Решением является совместное использование двух сигналов задержки и потери сегмента, такой подход используется например, в протоколе Compound TCP реализованного компанией Microsoft.
Сигнал о перегрузке
Следующий вариант, как отправитель может узнать о перегрузке это явный сигнал от маршрутизатора. Однако для этого маршрутизаторы должны поддерживать отправку сигналов. Одним из возможных вариантов является технология Random Early Detection, при этом маршрутизатор с некоторой вероятностью начинает отбрасывать пакеты еще до того как буфер полностью заполнен и началась перегрузка.
В результате отправители узнают о возможной перегрузке по потере сегмента ещё до того, как она произошла, и получают возможность заранее уменьшить окно перегрузки. Но это не явный тип сигнала, технологиях Explicit Congestion Notification, обеспечивает явную отправку сигнала от маршрутизатора к отправителю, о том что в сети происходит перегрузка.
Рассмотрим на схеме, как она работает. Отправитель передает сегмент в сеть, который доходит до маршрутизатора. Маршрутизатор находится в состоянии близкому к перегрузке, буфер заполнен, но не полностью. Для того чтобы предупредить отправителя о перегрузке в сети, маршрутизатор устанавливать специальные флаги в заголовке IP, которые говорят о том, что в сети произошла перегрузка.
Сегмент передается по сети дальше и достигает получателя. Получатель в заголовке IP видит что установлен флаг, свидетельствующий о перегрузке, для того чтобы о перегрузке узнал не только получатель, но и отправитель, получатель устанавливает соответствующие флаги уже в заголовке TCP, когда передает подтверждение.
Отправитель получает подтверждение доставки сообщения, и в этом подтверждении он видит, что флаг сигнализирующий о перегрузке установлен, это будет сигналом о том что нужно уменьшить размер окна перегрузки.
Рассмотрим, какие поля в заголовке IP и TCP используются в технологии Explicit Congestion Notification. В заголовке IP используются 2 бита в поле тип сервиса, значение 00 говорит о том, что перегрузки нет, а 11 означают что перегрузка произошла.
В заголовке TCP для этих целей используются три флага, NS, CWR, ECE.
- Получатель, который принял от маршрутизаторов заголовки IP сигнал о перегрузке, использует флаг ECE (ECN-Echo). Получатель устанавливает этот флаг в подтверждение получения сегмента, который он передает отправителю.
- Отправитель в качестве подтверждения того, что он получил сообщение о перегрузки при передаче следующего сегмента устанавливает флаг CWR (Congestion Window Reduced), который говорит о том, что размер окна управление перегрузкой уменьшен.
- Еще один флаг NS (ECN-none concealment protection) используется для защиты от случайного или злонамеренного изменения полей, который относится к технологии Explicit Congestion Notification.
Итоги
Мы рассмотрели управление перегрузкой в TCP это предотвращение отправки в сеть слишком большого количества сегментов, которые приведут к перегрузке. Для того чтобы справиться с этой проблемой, используется окно перегрузки, которое определяет сколько сегментов можно отправить в сеть. Если раньше размер окна перегрузки был фиксированным 8 сегментов, то сейчас он определяется динамически в зависимости от того насколько загружена сеть.
TCP для определения размера окна перегрузки, использует комбинацию двух методов, аддитивное увеличение мультипликативное уменьшение и медленный старт. Сначала работает медленный старт, затем происходит переход на аддитивное увеличение мультипликативное уменьшение. Основным сигналом перегрузки являются потеря сегментов в сети, но также существуют и другие сигналы, эта задержка сегментов и явный сигнал от маршрутизатора.
TCP использует три типа сигнала о перегрузке, это потеря сегментов, задержка сегментов и явный сигнал от маршрутизатор. Задержка сегментов позволяет быстрее узнать о перегрузке в сети, чем потеря сегментов, но надежность такого метода ниже и он может привести к несправедливому распределению пропускной способности в загруженной сети. Этот метод достаточно просто внедрить так как он требует изменений только на стороне отправителя сообщения, более совершенные технологии использования явных сигналов от маршрутизатора, она позволяет быстро и надежно получить сигнал, о том что в сети произошла перегрузка. Однако, для этого необходимо взаимодействие сетевого и транспортного уровня, поэтому необходимо вносить изменения в отправитель, в получатель, и во все промежуточные маршрутизаторы.
