управление перегрузкой канала в tcp осуществляется за счет

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.

Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.

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

Тройное рукопожатие

Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.

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

SYN ACK

Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.

Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.

Рис. 1. Тройное рукопожатие.

После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.

Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.

TCP Fast Open (TFO)

Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.

TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.

Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.

Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.

Контроль за перегрузкой

В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.

Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».

Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.

Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.

Контроль потока

Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).

Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.

Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.

Рис. 2. Передача значения окна приема.

Масштабирование окна (RFC 1323)

Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).

Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.

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

В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.

Источник

Русские Блоги

Механизм TCP-повторная передача, скользящее окно, управление потоком, контроль перегрузки

Эта статья Изучает программист обучение записки WeChat в Jogor, в неоригинальный, навязчивый.

TCP обеспечивает надежность передачи по серийному номеру, подтверждающий ответ, управлением повторной передачи, управление соединением и управление окном.

Во-первых, механизм повторной передачи

Когда TCP теряются за потери пакетов, механизм повторной передачи будет решен.

Следующие четыре общие механизмы повторной передачи.

1, тайм-аута повторной передачи

После отправки данных, установите одинтаймерПо истечении указанного времени превышен, то другая сторона не получила.ACK Эти данные будут переданы повторно после подтверждения ответного сообщения.

Причина для воспроизведения тайм-аута:

Что такое тайм-аут (RTO таймаут повторной передачи)?

Чуть больше, чем RTT (Round-Trip Time задержки туда-обратно)

2, быстрая повторная передача (быстрая повторная передача)

Не во время приводится в действие, данные отброшен.

Что ты имеешь в виду?

​ Когда отправитель получает три идентичных ACK, предыдущий SEQ не был получен, и потерял SEQ будет передан повторно до истечения таймера.

Примечание: Быстрая повторная передача произошло, как правило, часть пакета теряется, в результате трех последовательных трех ACKs.

3、 SACK

Мешок (Селективный Acknowledge избирательного подтверждения).

Этот метод требует, чтобы добавить один в заголовке TCP [опция] полеSACK S вещи. Он может послать карту кэша отправителю.

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

Примечание: Если вы хотите поддержать SCAK, вы должны поддерживать обе стороны.

Под Linux, вы можете передатьnet.ipv4.tcp_sack Параметр открывает эту функцию.

4、 D-SACK

DUPLICATE МЕШОК, МЕШОК повторно, в дополнение к тому, что используется в SACK, который уже получен, который неоднократно принимал. Как различить?

Вот индивидуальное понимание:

В это время, ACK явно превысил МЕШОК. В это время, SACK называется Дубликат Sack, называется D-Сак.

В это время, D-Sack используется, чтобы сообщить отправителю: (я уже получил его раньше, но ACK я потерял в сети передачи, вы не должны посылать эту SEQ мне позже

С точки зрения процесса:

Мешок используется для информирования отправителя, получатель не получил SEQ;

Д-Сак используется для информирования отправителя, и соответствующий ACK получен (потери пакетов) после приема SEQ но соответствующий ACK посылается (потеря пакетов).

Под Linux, вы можете передатьnet.ipv4.tcp_dsack Параметр открывает эту функцию.

Во-вторых, раздвижное окно

Решить проблему низкой эффективности одного человека.

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

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

Существует поле, называемое окно в голове TCP, то есть, размер окна (изменить).

1, окна отправителя

Состоит из размера окна + три указателей

SND.WND: Указывает размер окна передачи (размер определяется получателем)

SND.UNA: абсолютный указатель, который указывает на первый байт подтверждения, который был отправлен, но конфискованы.

SND.NXT: абсолютный указатель, который указывает на порядковый номер первого байта, который может быть передан, но не послал.

SND.UNA + SND.WND: Относительное указатель определяется размером окна старта +, указует на последние байты окна.

2, примите окно

Состоит из двух указателей:

Примечание: Окно отправки приблизительно равно принимающее окно.

В-третьих, управление движением

TCP предоставляет механизм, который позволяет отправитель [], чтобы контролировать количество данных, передаваемых в соответствии с реальной возможностью приема [Receiver], который называется управлением потоком.

Управление потока, чтобы избежать [отправителя], чтобы заполнить кэш [Receiver], но не знает, что процесс передачи сети произошел.

1, соотношение между буфером операционной системы и скользящим окном

Когда [Receive партии] не имеют возможностей обрабатывать пакеты кэша во время, он сообщит [отправителю], чтобы уменьшить размер окна, но область кэша не уменьшает (предотвращение потери пакетов) и т.д., то уменьшается после стабилизации области кэша.

​ Чтобы не допустить этого, правила TCP не позволяют одновременное сокращение кэширования и сжатия окна, но использовать первое окно сжатия, которое может уменьшить кэш в течение короткого периода времени, так что ситуация потери пакетов можно избежать.

2, окно закрыть

TCP позволяет [Приемник], чтобы указать, контроль трафика от размера данных (размер окна), полученные от [Отправитель] с помощью ACK.

​ Если размер окна равен 0, то отправитель будет препятствовать отправителю от передачи данных получателя, пока окно не является 0, что закрытие окна.

Окно закрывается существует риск

Когда [Receiver] обработана, ACK будет выдавать ACK сказать [отправителя] размер окна не 0, но если ACK потеряно, то большая проблема!

В это время [отправитель] ждем уведомления [Receiver], [Receive партии] ждем данных [отправитель]. Если не принимать меры, этот процесс ожидания друг друг вызвал затор.

Как решить / предотвращения этого тупика?

TCP соединение получено уведомление окна другого абонента ноль, началоСтойкий счетчик。

Таймер тайм-аут будет инициировать один разОкно Probe Packet [Receiver] После подтверждения этого сообщения, дайте свой собственный размер окна принять.

Если окно 0, то таймер сбрасывается.

Если окно не 0, мертвые брейки замка.

3, вставить синдром окна

Когда [Приемник] не оцениваются с данными из буферной зоны, окно посыла [отправителя] становится все меньше и меньше.

В конце концов,Если получатель имеет несколько байт и сообщить отправителю, в настоящее время существует несколько байт окна, и отправитель будет посылать эти байты, что является синдромом запутаться окном.。

Почему вы не можете это сделать?

Если у вас есть стоимость, глава TCP + IP имеет 40 байт, и в течение нескольких байт данных, это слишком экономично.

Как сделать получатель не информировать маленькое окно?

Когда [Размер окна] меньше, чем MIN (MSS, кэш пространства / 2), проинформирует [Send Party] размер окна 0

Как позволить отправители избежать отправок небольших данных?

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

До тех пор пока один из вышеуказанных условий не выполнено, отправитель принимает данные и знает, что условие выполнено.

Алгоритм Нэйгл открывается по умолчанию. Для небольшого взаимодействия данных, такие как Telnet или SSH является более интерактивным, вам нужно отключить алгоритм Нейк.

Вы можете отключить алгоритм в настройках сокета TCP_NODELAY

В-четвертых, контроль перегрузки

Почему у вас есть контроль перегрузки, не существует контроль трафика?

Таким образом, естьуправление перегрузкамиЦелью управления являетсяИзбегайте данные «отправитель», чтобы заполнить всю сеть.

Для того, чтобы регулировать количество данных, которые должны быть отправлены в [отправителя], один определен [окно заторы] Концепция чего-либо.

Что такое окно перегрузки? Какова связь с представляемым окном?

​ Окно заторы CWnd(Заторы окно) является переменным состояние поддерживается отправителем, который будет зависеть от степени загруженности сети.Динамические изменения。

Из выше, мы знаем, что окно отправки SWND и принимает окно RWND около равноправных отношений;

После введения концепции окна насыщения, то SWND = Min (CWnd, RWnd) посылает окно равного минимального значения окна перегрузки и окно приема.

CWnd правила вариации:

Как определить блокировку сети?

Когда произошел тайм-аута повторной передачи, в сети появились в сети.

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

Плавный запуск, предотвращение перегрузки, перегрузки, быстрое восстановление

1, медленный старт

Медленные стартовые правила являются:Получен ACK, окно перегрузки +1。

Можно видеть, что каждый получил ACK увеличивает CWnd. (((((1 + 1) + 2) +4) +8)

CWND представит экспоненциальный рост в соответствии с этой функцией.

Существует порог медленного стартаssthresh Slow Start Threshold переменная состояния.

2, предотвращение перегрузки

При SWND> = SSTHRESH, используется алгоритм предотвращения перегрузки:

Правила предотвращения перегрузки являются:Каждый из SWND добавляет 1 / CWnd каждый ACK, то есть, все ACKs, которые были получены ранее, SWND может увеличиться 1.

Я знаю, CWNDПредотвращение перегрузки Характеристики увеличиваются линейно.

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

Когда механизм повторной передачи срабатывают, то [перегрузки Избежания] Алгоритм вводятся.

3, заторы

Из приведенного выше механизма повторной передачи мы знаем, существует два основных механизм повторной передачи:

Два соответствующих различные алгоритмы перегрузки.

Скопление повторная передача возникает тайм-аут алгоритма

На этот раз, значение медленного старта и окно перегрузки CWnd ssthresh патриарх изменятся:

После того, что, обратно в медленный старт, начал медленно повторно друзей

Возникновение перегрузки быстрого алгоритма повторной передачи

Примечание: В этой точке величина CWnd и ssthresh одно и то же. Вошел быстрый алгоритм восстановления.

4, быстрое восстановление (+3, алгоритм)

Как следует из названия, в случае потери только один мешок, мы будем блокировать окно (CWnd) снизилась до половины, то мы будем быстрое восстановление CWnd для восстановления исходной скорости передачи.

Он не думает, что так интенсивно RTO, прямо вниз к 1, но помещение только половине избегания падения +3 и перегрузок.

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

​

Источник

Протокол TCP — как происходит управление перегрузкой

В прошлой статье мы рассматривали управление потоком в TCP, это способ предотвращения отправки в сеть слишком большого количества сегментов, которые не могут быть приняты получателем, у которого просто недостаточно и места в буфере.

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

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

Одновременно, большое количество компьютеров решили передавать данные, маршрутизаторы не способны передать такое большое количество пакетов в единицу времени и они вынуждены отбрасывать пакеты. В этом случае происходит перегрузка, отправители передают в сеть большое количество данных, однако большая часть из этих данных отбрасываются маршрутизаторами и не доходит до получателей. Таким образом, большая часть каналов сети занята, но полезные данные от отправителя до получателя почти не доходят.

Коллапс перезагрузки

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

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

Окно перегрузки в TCP

Таким образом в TCP у нас есть два типа окна. Окно управления потоком, которое мы рассматривали в статье «Протокол TCP — Управление Потоком». Размер этого окна задаются получателем, в зависимости от того сколько места в буфере, и передается отправителю в сегментах с подтверждением.

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

Управление скоростью передачи в TCP

Оба типа окна, окно управления потоком и окно перегрузки, используются для решения более общей задачи — управление скоростью передачи данных в TCP. Если размер скользящего окна будет слишком маленьким, то в сеть мы будем отправлять маленькое количество сегментов, сеть будет не загружена полностью, и скорость передачи будет маленькой, ниже чем возможно.

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

AIMD

В TCP для определения размера окна перегрузки используется метод аддитивного увеличения, мультипликативного уменьшения. Суть метода заключается в том, что при получении каждого подтверждения, мы прибавляем к размеру окна некоторые значения, как правило это размер одного сегмента TCP, а если перегрузка произошла, то мы умножаем размер окна на некоторые значения. Как правило это 1/2, то есть в TCP при перегрузке, размер окна уменьшается в два раза.

Размер окна AIMD

Вот график работы метода аддитивного увеличения, мультипликативного уменьшения. Мы начинаем передавать данные, поступает подтверждение,размер окна увеличивается, происходит аддитивное увеличение. Затем в сети произошла перегрузка, размер окна уменьшается в два раза, произошло мультипликативное уменьшение.

Затем данные снова передаются, размера окна при получение каждого подтверждения увеличивается на один сегмент, аддитивные увеличения. И так происходит пока не произойдет следующая перегрузка. Таким образом, размер окна у нас напоминают зубья пилы.

Сигнал о перезагрузке

Как отправитель узнает, о том что в сети произошла перегрузка? Это достаточно сложная задача, потому что сеть может быть составной, и перегрузка может происходить не на том сегменте сети, который подключен к отправителю, а на каком-то сегменте между отправителем и получателем, который находятся достаточно далеко от того и другого.

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

Медленный старт

Метод аддитивного увеличения мультипликативного уменьшения хорошо работал на медленных каналах связи, которые были во времена создания сети интернет, но у на современных, быстрых и надежных каналах связи, этот метод работает плохо. С помощью аддитивного увеличения, размер окна перегрузкой увеличивается очень медленно, для того чтобы решить эту проблему был предложен другой метод управления размером окна — медленный старт.

При медленном старте размер окна увеличивается на каждое подтверждение не на 1 сегмент, а на 2, благодаря этому происходит экспоненциальное увеличение размера окна. Сначала мы отправляем один сегмент, получили подтверждение, отправляем два сегмента, получили 2 подтверждения, на каждое подтверждение отправляем по два сегмента всего 4, потом 8, потом 16 и так далее. То есть несмотря на название медленный старт, размер окна увеличивается гораздо быстрее, чем при аддитивном увеличении, мультипликативном уменьшении.

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

Медленный старт и AIMD в TCP

В 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, обеспечивает явную отправку сигнала от маршрутизатора к отправителю, о том что в сети происходит перегрузка.

Explicit Congestion Notification (ECN)

Рассмотрим на схеме, как она работает. Отправитель передает сегмент в сеть, который доходит до маршрутизатора. Маршрутизатор находится в состоянии близкому к перегрузке, буфер заполнен, но не полностью. Для того чтобы предупредить отправителя о перегрузке в сети, маршрутизатор устанавливать специальные флаги в заголовке IP, которые говорят о том, что в сети произошла перегрузка.

Сегмент передается по сети дальше и достигает получателя. Получатель в заголовке IP видит что установлен флаг, свидетельствующий о перегрузке, для того чтобы о перегрузке узнал не только получатель, но и отправитель, получатель устанавливает соответствующие флаги уже в заголовке TCP, когда передает подтверждение.

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

ECN в заголовке IP

Рассмотрим, какие поля в заголовке IP и TCP используются в технологии Explicit Congestion Notification. В заголовке IP используются 2 бита в поле тип сервиса, значение 00 говорит о том, что перегрузки нет, а 11 означают что перегрузка произошла.

ECN в заголовке TCP

В заголовке TCP для этих целей используются три флага, NS, CWR, ECE.

Итоги

Мы рассмотрели управление перегрузкой в TCP — это предотвращение отправки в сеть слишком большого количества сегментов, которые приведут к перегрузке. Для того чтобы справиться с этой проблемой, используется окно перегрузки, которое определяет сколько сегментов можно отправить в сеть. Если раньше размер окна перегрузки был фиксированным 8 сегментов, то сейчас он определяется динамически в зависимости от того насколько загружена сеть.

TCP для определения размера окна перегрузки, использует комбинацию двух методов, аддитивное увеличение мультипликативное уменьшение и медленный старт. Сначала работает медленный старт, затем происходит переход на аддитивное увеличение мультипликативное уменьшение. Основным сигналом перегрузки являются потеря сегментов в сети, но также существуют и другие сигналы, эта задержка сегментов и явный сигнал от маршрутизатора.

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

Источник