вышеГоворя о TCP (1): конечный автомат и механизм повторной передачиПредставлены конечный автомат и механизм повторной передачи TCP. Эта статья представляет流量控制(управление потоком, называемое управлением потоком) и拥塞控制(Контроль заторов). Таким образом, TCP защищаетQOS(Качество обслуживания).

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

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

Алгоритм RTT

Согласно предыдущему введению в механизм повторной передачи тайм-аута TCP, мы знаем, что настройка тайм-аута очень важна для повторной передачи:

• Если задана длина, повторная передача будет медленной, а повторная передача займет много времени, что неэффективно и имеет низкую производительность.
• Если он установлен коротким, это приведет к повторной передаче без потери. Следовательно, повторная передача выполняется быстрее, что увеличивает перегрузку сети, что приводит к большему количеству тайм-аутов, а большее количество тайм-аутов приводит к большему количеству повторных передач.

Более того, этот тайм-аут различен в разных сетевых средах и должен устанавливаться динамически. С этой целью TCP ввелRTT(Время приема-передачи): время с момента отправки пакета данных до момента его возврата. Таким образом, отправитель примерно знает, сколько времени требуется для нормальной передачи, и рассчитывает соответственноRTO(Retransmission TimeOut, время ожидания повторной передачи). Звучит просто: записывайте t0, когда отправитель отправляет пакет, и записывайте t1, когда получатель получает подтверждение, поэтому RTT = t1 – t0. Однако это только выборка, которая не может отражать общую ситуацию в сетевой среде.

Классический алгоритм

RFC793 определяет经典算法:

1. Сначала выберите RTT и отметьте значения RTT за последние несколько раз.

2. Затем используйте加权移动平均算法(метод взвешенного скользящего среднего) для сглаживания, расчетаSRTT(сглаженный RTT):

   SRTT = ( α * SRTT ) + ((1- α) * RTT) (通常取0.8≤α≤0.9，α越大收敛速度越快)
   

3. Наконец, рассчитайте RTO: RTO = мин. [UBOUND, макс. [LBOUND, (β * SRTT)]] (обычно 1,3≤β≤2,0)

Алгоритм Карна/Партриджа

Классический алгоритм описывает основную идею расчета RTO, но есть еще одна важная проблема: выборка RTT».первый разВремя отправки Seq + получение подтверждения", или "РетрансляцияSeq + время для получения подтверждения"?

Как показано на рисунке:

• В случае (а) выборка RTT представляет собой «время первой отправки Seq + получение Ack». Предполагая, что Seq, отправленный в первый раз, полностью потерян, время выборкиПересчет«Интервал от первой передачи до повторной передачи».
• В случае (b) выборка RTT представляет собой «последовательность повторной передачи + время для получения подтверждения». Предполагая, что передача подтверждения происходит медленно, подтверждение, отправленное получателем сразу после получения повторной передачи, тогда время выборкиСчитать меньше«Интервал от первой передачи до повторной передачи».

Суть проблемы в следующем:Отправитель не может отличить полученный ACK, соответствующий первому SEQ, или повторно переданному SEQ.(то же самое и при входе в сеть). Для этого вопросаKarn / PartridgeАлгоритм решает избежать проблемы повторной передачи:Игнорировать повторно переданные выборки, и выборка RTT берет только те выборки, которые не генерировали повторные передачи..

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

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

Алгоритм Якобсона/Карелса

Первые два алгоритма используют алгоритм взвешенного скользящего среднего для сглаживания.Самая большая проблема этого метода заключается в том, что трудно найти большие колебания значения RTT, потому что оно сглажено (1 - относительно мал, т. е. вес последнего RTT мало. ). Для этого вопросаJacobson / KarelsАлгоритм вводит разницу между вновь выбранным значением RTT и сглаженным значением SRTT в качестве фактора, а именноDevRTT(Отклонение RTT, степень отклонения RTT), учитывая инерцию, вызванную SRTT, и флуктуацию, вызванную DevRTT:

SRTT = SRTT + α(RTT – SRTT)  —— 计算SRTT
DevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) —— 计算SRTT和最新RTT的差距（加权移动平均）
RTO= µ * SRTT + ∂ *DevRTT —— 同时考虑SRTT（惯性）与DevRTT（波动）

Linux 2.6 использует этот алгоритм для расчета RTO: по умолчанию α = 0,125, β = 0,25, μ = 1, ∂ = 4 (метафизические параметры, знаете ли).

Скользящее окно TCP

Использование TCP滑动窗口(Скользящее окно) управлять потоком с помощью乱序重排. Неупорядоченное переупорядочивание было введено в механизм повторной передачи TCP, а управление потоком представлено ниже.

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

Наблюдайте за буфером отправки и буфером приема протокола TCP:

Предполагая, что номер позиции увеличивается слева направо (общий дизайн буфера чтения и записи), объясните:

• Sender: LastByteAcked указывает на позицию максимального последовательного полученного подтверждения; LastByteSent указывает на позицию последнего отправленного байта; LastByteWritten указывает на позицию последнего байта, записанного приложением верхнего уровня.
• Receiver: LastByteRead указывает на позицию последнего байта, прочитанного приложением верхнего уровня; NextByteExpected указывает на позицию полученного непрерывного максимального Seq; LastByteRcvd указывает на позицию последнего полученного байта. можно увидетьНекоторые последовательности между NextByteExpected и LastByteRcvd еще не получены, соответствующий пустой области.

Рассчитывается в приемнике соответственноAdvertisedWindow, рассчитывается на стороне отправителяEffectiveWindow:

• Приемник записывает свои в AckAdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead)и ответьте отправителю с помощью Ack.
• В соответствии со значением AdvertisedWindow в Ack отправитель должен убедиться, чтоLastByteSent - LastByteAcked ≤ AdvertisedWindow, оставшийся размер данных, которые можно отправить в окнеEffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked), чтобы получатель мог его обработать.

Рекламируемое окно и эффективное окно

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

Расчет рекламного окна

Из-за проблемы с нарушением порядка LastByteRcvd может указывать на Seq(LastByteSent), а Seq(LastByteAcked + 1) на Seq(LastByteSent - 1) все еще в пути.О том, чтобы добраться до приемника, лучший случай - не потерять пакет (он будет повторно утерян после потерянного пакета),После последнего пострадателя, получайте пространство буфера до границы максимальной длины передачи данных у отправителя(Повторная передача не является следующей передачей), поэтомуAdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead).

Расчет эффективного окна

LastByteRcvd также может указывать на Seq(LastByteAcked) (новый пакет не получен), очевидно, что формула AdvertisedWindow неизменна,И Seq(LastByteAcked + 1) в Seq(LastByteSent) все еще в пути, достигнет получателя и войдет в буфер приема в будущем, то "Seq(LastByteAcked + 1) to Seq(LastByteSent) еще в пути" не должно превышать оставшееся пространство буфера приема AdvertisedWindow (в настоящее время равно MaxRcvBuffer), который требует, чтобы последняя отправка удовлетворяла LastByteSent - LastByteAcked ≤ AdvertisedWindow,Тогда пространство после LastByteSent и перед границей оставшегося места в буфере приема является верхней границей длины оставшихся данных, которые могут быть отправлены в окне отправителя.,следовательно,EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked).

Конечно, EffectiveWindow принимает минимальное значение 0.

Пример 1

Вот скользящее окно буферов отправки:

Изображение выше разделено на 4 части:

• #1— подтвержденные данные, которые были отправлены, т. е. область перед LastByteAcked.
• #2Отправлены неподтвержденные данные, то есть область между LastByteAcked и LastByteSent, размер которых не превышает AdvertisedWindow.
• #3— это неотправленные данные в окне, то есть область между LastByteSent и правой границей окна, а размер равен EffectiveWindow (возможно, 0).
• #4— это неотправленные данные за пределами окна, то есть область между правой границей окна и LastByteWritten.

в,#2 + #3Формируется скользящее окно, и общий размер не превышает AdvertisedWindow.Соотношение двух зависит от скорости обработки получателя и условий сети (если потеря пакетов серьезная или скорость обработки медленнее, чем отправка скорость,#2:#3станет больше).

Пример 2

Ниже приведен процесс корректировки AdvertisedWindow, и EffectiveWindow изменяется соответствующим образом:

Zero Window

Понимание проблематично и не требует мастерства.

На рисунке выше мы видим, как медленный сервер (получатель) уменьшает размер окна отправки клиента (отправителя) до 0. Для получателя буфер приема в это время действительно заполнен, поэтому разумно уменьшить размер окна отправки отправителя до 0, чтобы временно запретить отправку. Затем, когда буфер приема получателя опустеет, как уведомить отправителя о новом размере окна?

В ответ на эту проблему технология ZWP (Zero Window Probe, нулевое уведомление окна) разработана для TCP: отправитель отправит ZWP-пакет получателю после того, как окно станет равным 0, и пусть получатель подтвердит свой размер окна. Повторная передача также следует стратегии экспоненциальной отсрочки, по умолчанию повторяет 3 попытки; если размер окна по-прежнему равен 0 после 3 попыток, считается, что получатель не в порядке, и отправляет RST для сброса соединения (部分文章写的是重试到window size正常？ ? ?).

Примечание. DDoS-атаки возможны везде, где есть ожидание, и Zero Window не является исключением. Некоторые злоумышленники устанавливают для окна значение 0 после установления соединения с сервером и отправки запроса GET, поэтому сервер может только ждать ZWP; тогда злоумышленник будет одновременно отправлять большое количество ZWP, истощая ресурсы сервера. (Как клиент ждет, чтобы использовать сервер? ? ?)

Контроль перегрузки TCP

Перегруженность в общении относится к:

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

Почему контроль перегрузки? Предполагая, что сеть уже перегружена, если с перегрузкой не справиться, задержка увеличится, больше пакетов будет потеряно, и отправитель будет вынужден повторно передавать данные, усугубляя перегрузку и продолжая порочный круг, пока сеть не будет парализована. . Можно видеть, что сценарии адаптации и цели управления перегрузкой и управления потоком различны.

Прежде чем возникнет перегрузка, это может предотвратить перегрузку сети из-за чрезмерного роста трафика; когда возникает перегрузка, единственный вариант — уменьшить трафик.. Управление перегрузкой в ​​основном осуществляется с использованием четырех алгоритмов:

1. медленный старт
2. предотвращение перегрузки
3. происходит затор
4. быстрое восстановление

Алгоритмы 1 и 2 применяются до возникновения перегрузки, алгоритм 3 применяется при возникновении перегрузки, а алгоритм 4 применяется после устранения перегрузки (эквивалентно до возникновения перегрузки).

rwnd и cwnd

Прежде чем официально представить вышеприведенный алгоритм, сначала добавим следующееrwnd(Окно приемника, окно приемника) сcwndКонцепция (окно перегрузки, окно перегрузки):

• rwnd — это размер окна, используемый для управления потоком, то есть AdvertisedWindow в приведенном выше управлении потоком, который в основном зависит от скорости обработки получателя и уведомляется получателем о пассивной настройке отправителя (подробную логику см. выше). .
• cwnd — это размер окна для обработки перегрузки, который активно регулируется отправителем, проверяющим сеть, в зависимости от сетевых условий.

При введении управления потоком мы не учитывали cwnd, а считали, что максимальное скользящее окно отправителя равно rwnd. По факту,Управление потоком и обработку перегрузки необходимо учитывать одновременно, размер окна отправителя не превышаетmin{rwnd, cwnd}. Следующие четыре алгоритма управления перегрузкой включают только регулировку cwnd.Как и при введении управления потоком, rwnd пока не рассматривается, и предполагается, что максимальное скользящее окно равно cwnd; однако читатель должен прояснить связь между rwnd, cwnd и размер окна отправителя.

4 алгоритма управления перегрузкой

алгоритм медленного старта

慢启动算法(Медленный старт) работает до возникновения перегрузки:Для соединения, которое только что присоединилось к сети, необходимо увеличивать скорость понемногу, а не пытаться добиться этого за один шаг.. следующее:

1. Соединение только что было установлено, и инициализировано cwnd = 1 (конечно, оно обычно не инициализируется значением 1, слишком мало), указывая на возможность передачи данных размера MSS.
2. Каждый ACK, CWND++, линейный рост.
3. После каждого RTT cwnd = cwnd * 2, экспоненциальный рост (основной источник роста).
4. Существует также ssthresh (порог медленного запуска), когда cwnd >= ssthresh, он войдет в алгоритм предотвращения перегрузки (см. ниже).

Следовательно, если скорость сети высокая, Ack возвращается быстро, а RTT короткий, то этот медленный старт вовсе не медленный. Следующая диаграмма иллюстрирует этот процесс:

Алгоритм предотвращения перегрузок

Как упоминалось выше, когда CWND> = Ssthresh (обычно Ssthresh = 65535), войдут拥塞避免算法(Предотвращение перегрузки):Медленный рост, тщательный поиск оптимального значения. следующее:

1. Каждый раз, когда принимается Ack, cwnd = cwnd + 1/cwnd, очевидно, при cwnd > 1 роста нет.
2. После каждого RTT cwnd++ увеличивается линейно (основной источник роста).

Алгоритм медленного старта в основном растет экспоненциально, грубо и быстро («медленно» относится к одному шагу), в то время как алгоритм предотвращения перегрузки в основном растет линейно, точно и медленно, но легче избежать перегрузки. оптимальное значение cwnd для сетевой среды.

Алгоритмы при перегрузке

Алгоритмы медленного старта и предотвращения перегрузки используются для увеличения cwnd с помощью различных стратегий до возникновения перегрузки; если перегрузка уже произошла, необходимо принять стратегию для уменьшения cwnd. Итак, как TCP определяет, что текущая сеть перегружена? очень простой,Если отправитель обнаруживает, что Seq не может быть отправлен (выражается как «потеря пакета»), он считает, что сеть перегружена..

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

1. Тайм-аут повторной передачи. TCP считает, что эта ситуация слишком плоха, и сила корректировки относительно велика:
   1. ssthresh = cwnd /2
   2. CWND = 1, повторно введите медленное начало (плохая сеть, медленно настроить)
2. Быстрая ретрансляция. TCP считает, что эта ситуация обычно лучше, чем тайм-аут RTO, а основная реализация TCP Reno имеет более мягкую настройку (реализация TCP Tahoe столь же жестока, как и тайм-аут RTO):
   1. ssthresh = cwnd /2
   2. cwnd = cwnd /2, ввести алгоритм быстрого восстановления (сеть не такая уж и плохая, можно быстро настроить, см. ниже)

Видно, что независимо от того, какой метод повторной передачи используется, ssthresh станет половиной cwnd, все еще _exponential fallback, а затем постепенно вырастет до нового оптимального значения после исчезновения перегрузки, обычно при оптимальном значении (динамическом) колеблется рядом.

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

алгоритм быстрого восстановления

Если срабатывает быстрая ретрансляция, то есть отправитель получает один и тот же Ack минимум 3 раза, то TCP думает, что ситуация в сети не так уж и плоха, и волноваться по этому поводу не стоит, и может восстанавливаться адекватно и смело . предназначен для этого快速恢复算法(Fast Recovery), реализация в TCP Reno описана ниже.

Напомним, что cwnd и sshthresh были обновлены перед переходом в режим быстрого восстановления:

1. ssthresh = cwnd /2
2. cwnd = cwnd /2

Затем введите алгоритм быстрого восстановления:

1. cwnd = ssthresh + 3 * MSS (попробуйте сделать это за один шаг)
2. Повторно передать Seq, соответствующий повторному Ack
3. Если повторный Ack получен снова, то cwnd++, линейный рост (медленная регулировка)
4. Если получен новый Ack, то cwnd = ssthresh, а затем вводится алгоритм предотвращения перегрузки (Почему я должен понижать sshthresh, когда получаю новый акк? ? ?)

Что пока игнорировать:

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

Пример

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

---

Ссылаться на:

• Эти вещи о TCP (ниже)
• Сетевой фонд 3 — транспортный уровень

---

Ссылка на эту статью:Говоря о TCP (2): управление потоком и контроль перегрузки
автор:обезьяна 007
Источник:monkeysayhi.github.io
Эта статья основана наCreative Commons Attribution-ShareAlike 4.0Международное лицензионное соглашение выпущено, его можно перепечатать, вывести или использовать в коммерческих целях, но авторство и ссылка на эту статью должны быть сохранены.