Истоки управления перегрузкой TCP
В 1986 г. пропускная способность сети от LBL до Калифорнийского университета в Беркли резко упала с 32 Кбит/с до 40 бит/с из-за перегрузки. В статье Ван Якобсона 1988 г. «Предотвращение перегрузки и контроль» она началась с этой проблемы и предложила закон сохранения пакетов и медленного старта. алгоритмы быстрой повторной передачи, а в 1990 году был предложен алгоритм быстрого восстановления.
Принцип сохранения пакетов
Пакеты, проходящие в хорошо работающем TCP-соединении, должны быть консервативными, что означает, что новые пакеты могут быть добавлены к соединению только после того, как старые пакеты были успешно переданы партнеру. В протоколе TCP мы можем использовать ack в качестве основы для оценки того, успешно ли пакет данных достиг партнера, то есть когда отправитель получает хороший ack (подтверждение, которое больше, чем максимальное подтверждение, которое отправитель получил до сих пор). ), он может отправить новый пакет. Этот механизм принятия решения о продолжении отправки пакетов на основе подтверждения называется автосинхронизацией (также называемой синхронизацией подтверждения).
медленный старт
Благодаря принципу сохранения пакетов мы знаем, что мы можем решить, отправлять ли новые данные через ack, а чтобы получить ack, мы должны сначала отправить данные. Управление поведением, когда медленный старт начинает отправку данных. Общая идея медленного старта состоит в том, чтобы начать с очень низкого начального значения и постепенно увеличивать скорость передачи данных, пока не будет достигнут тайм-аут или потеря пакетов. Идея реализации медленного старта заключается в следующем:
- Каждое соединение поддерживает переменную cwnd (окно перегрузки).
- Когда соединение только что установлено или потеря пакета встречается, установите CWND на 1, устройство MSS (максимальный размер сегмента)
- Каждый получил новый ack, cwnd плюс один
- При отправке данных количество пакетов данных, которые могут быть отправлены, равно min (cwnd, awnd), а awnd — это размер объявляемого окна получателя (reciver's анонсируемое окно).
Можно предвидеть, что при отсутствии тайм-аута или потери пакетов скорость медленного старта растет экспоненциально, поэтому медленный старт на самом деле не такой уж "медленный", "медленный" медленный в начальной точке только с 1 MSS.
предотвращение перегрузки
Как упоминалось ранее, целью медленного запуска является постепенное увеличение скорости отправки для тестирования до тех пор, пока не произойдет перегрузка сети, а что делать, когда возникает перегрузка, и есть то, что делает «предотвращение перегрузки». Предотвращение перегрузки в основном состоит из двух частей:
- Механизм оценки текущей загруженности сети
- Механизм замедления скорости отправки при наличии перегрузки
Идея реализации предотвращения перегрузок выглядит следующим образом:
- При возникновении тайм-аута установите cwnd в половину текущего значения (то есть, когда происходит тайм-аут, считается, что есть перегрузка)
- Каждый раз при получении нового подтверждения cwnd увеличивается на 1/cwnd (то есть при успешной передаче пакетов cwnd размер окна увеличивается на единицу, то есть увеличивается линейно с RTT)
Два поведения изменения cwnd здесь обычно называют «мультипликативным уменьшением» и «аддитивным увеличением».
Алгоритмы, сочетающие медленный старт и предотвращение перегрузок
Стоит отметить, что медленный запуск и предотвращение перегрузки на самом деле являются двумя разными алгоритмами: один для проверки верхнего предела сетевых ресурсов, а другой — для поведения, когда использование ресурсов достигает или приближается к верхнему пределу. В статье 1988 г. дан алгоритм, сочетающий в себе медленный старт и предотвращение перегрузки.Конкретные идеи реализации заключаются в следующем:
- Отправитель поддерживает две переменные: окно перегрузки cwnd (окно перегрузки) и порог медленного запуска ssthresh (порог медленного запуска).Эти две переменные определяют, должен ли в данный момент выполняться алгоритм медленного запуска или алгоритм предотвращения перегрузки.
- При отправке данных количество пакетов, которые можно отправить, равно min(cwnd,awnd)
- Когда происходит тайм-аут, ssthresh обновляется до cwnd/2 (но не менее 2), а cwnd устанавливается в 1
- Каждый раз, когда получен новый zck, отправитель ведет себя следующим образом:
- если
cwnd<ssthresh,cwnd+=1(Фаза медленного запуска, экспоненциальный уровень окна увеличивается) - в противном случае
cwnd+=1/cwdn(Фаза предотвращения перегрузки, окно увеличивается линейно)
- если
быстрая ретрансляция
Цель быстрой повторной передачи — заставить отправителя почувствовать потерю пакета как можно скорее. Отправитель TCP запускает таймер каждый раз при отправке сегмента.Если соответствующее подтверждение пакета не отправляется обратно в течение определенного времени, отправитель предполагает, что сегмент потерян в сети и его необходимо отправить повторно. Это также измерение, используемое TCP для оценки RTT.
Повторить подтверждение
Повторное подтверждение основано на следующем процессе: если приемник получает сегмент данных, он добавит порядковый номер сегмента к значению длины байтов данных в качестве номера подтверждения подтверждения сегмента и отправит его обратно в отправителю, указывая, что ожидается отправка. Сторона отправляет сегмент следующего порядкового номера. Однако, если получатель получает сегмент с большим порядковым номером заранее или получает сегмент, который поступает не по порядку, получатель долженнемедленноОтправьте подтверждение сегмента, используя предыдущий номер подтверждения. В это время, если отправитель получает подтверждение сегмента с одним и тем же номером подтверждения от получателя более одного раза, и таймер тайм-аута сегмента соответствующего порядкового номера не истек, то это повторное подтверждение и необходимо ввести быструю повторную передачу. .
Быстрая повторная передача основана на следующем механизме: если порог повторения предполагается равным 3, когда отправитель получает 4 сегментных подтверждения с одинаковым номером подтверждения (первое получение подтверждения с ожидаемым порядковым номером, плюс 3 повторных подтверждения ожидаемой последовательности номер) ), можно считать, что продолжающаяся отправка сегментов с более высокими порядковыми номерами будет отброшена получателем и не будет доставлена по порядку. Отправитель должен игнорировать таймер ожидания повторной передачи и немедленно повторно передать сегмент с порядковым номером, соответствующим номеру подтверждения в подтверждении повторного сегмента.
Различные реализации управления перегрузкой TCP
Здесь реализация каждого контроля перегрузки TCP указана первой, а конкретное принятие будет добавлено позже.
- TCP Tahoe/Reno, фаза «быстрого восстановления» впервые добавлена в Reno.
- TCP Vegas
- TCP New Reno
- TCP BIC/CUBIC
- TCP Westwood/Westwood+
- Compound TCP
- TCP PRR
- TCP BBR