Flow control управление потоком данных трафиком в сети

Скачать презентацию Flow control управление потоком данных трафиком в сети

6 - Flow control (управление трафиком).pptx

Количество слайдов: 32

Flow control– управление потоком данных (трафиком в сети): В чем состоит задача управления трафиком? – с. 2 Stop and wait (передача с остановкой и ожиданием подтверждения) – с. 5 Sliding window (окно пакетной передачи переменной длительности) – с. 29

Краткое содержание 1. В чем состоит задача управления трафиком? 2. Stop and wait (передача с остановкой и ожиданием подтверждения) 3. Какие недостатки у простого контроля траффика по методу stop-and-wait? 4. Sliding window (окно пакетной передачи переменной длительности) 2

Flow control (управление потоком данных) • Помогает осуществлять регулирование потока данных через маршрутизаторы для равномерного распределения нагрузки по всем сегментам сети • То есть выполняет контроль объёма передаваемых отправителем данных во избежание переполнения буферов и потери пакетов у получателя; может осуществляться как программно, так и аппаратно • Может реализовываться путем обмена служебными сигналами, при котором каждое устройство оповещает о готовности послать или принять данные

Управление потоком данных – задача:

Управление потоком данных - Stop-and-Wait • Необходимо посылать число пакетов, не превышающее число пакетов, которые получатель может принимать в единицу времени • Получатель направляет отправителю сигнал обратной связи • Существует два основных подхода к управлению трафиком: ▶ Stop and wait – передача с остановкой и ожиданием подтверждения ▶ Sliding window – окно (пакетной) передачи переменной длительности

Finite State Machines - конечные автоматы event causing state transition actions taken on state transition event action

Управление потоком данных - Stop-and-Wait • В пути находится в любой момент времени не более одного пакета • Отправитель посылает по одному пакету • Получатель отвечает пакетом-подтверждением после получения данных • После получения подтверждения, отправитель посылает новые данные, и т. д. • Если наступает событие «timeout» (превышение лимита времени, отведенного на ожидание подтверждения), отправитель посылает текущий пакет еще раз

Finite State Machines для метода “Stop-and-wait” • Получатель находится в одном и том же состоянии – ожидания пакетов • При наступлении события «получение пакета» , он отсылает пакетподтверждение отправителю, и передает полученные данные на вышестоящий прикладной уровень (приложению в соответствии с номером порта и т. д. …)

Finite State Machines для метода “Stop-and-wait” • Отправитель находится в двух состояниях – ожидания данных от приложения для передачи или ожидания подтверждения “ACK” о получении пакетов • При наступлении события «timeout» во втором состоянии, пакет посылается заново и вновь ожидается подтверждение о его получении • Если подтверждение получено, отправитель возвращается в исходное состояние, и находится в нем до получения новых данных от прикладного уровня для пересылки

Управление потоком данных - Stop-and-Wait Возможные сценарии при пересылке данных по методу с остановкой и ожиданием: Передача идет без ошибок, все пакеты с данными data и подтверждениями ACK доставляются в рамках заданного таймаута t Если потерян пакет с данными, то по истечении времени t он посылается заново, для него получается ACK, и все хорошо Если потеряно подтверждение ACK, то данные data просто посылаются заново, повторный пакет data подтверждается новым ACKи уничтожается на принимающей стороне, и все хорошо А что может произойти, если ACK приходит с запаздыванием – по истечении таймаута t – когда data уже посланы заново?

Управление потоком данных - Stop-and-Wait Возможные сценарии при пересылке данных по методу с остановкой и ожиданием: Передача идет без ошибок все хорошо Если ACK приходит с запаздыванием – по истечении таймаута t –когда data уже посланы заново, то отправитель воспринимает исходный запоздавший ACK как подтверждение для повторного пакета, и посылает новые данные. Получатель подтверждает второй (повторный пакет) еще одним ACK, который отправитель будет считать подтверждением уже для нового (3 -го) пакета, и начнет передачу следующего 4 -го пакета. Если же этот 3 -й пакет потеряется, то отправитель об этом не узнает. Схема не работает! То же самое происходит и в случае запаздывания пакета data (подумайте сами, почему)

Управление потоком данных - Stop-and-Wait • • • Как решить проблему с запаздывающими пакетами – как отслеживать дубликаты? Если использовать 1 -битовый счетчик в пакетах данных и подтверждений Ø Получатель сможет отличить новые данные от дубликатов Такой подход предполагает следующие упрощающие допущения: Ø Сеть не производит дубликат пакетов сама по себе Ø Пакеты не могут запаздывать более чем на один временной промежуток таймаута Выполнения последнего условия можно добиться либо увеличением таймаута, либо расширением диапазона счетчика (порядковых номеров)

Вопрос: какой главный недостаток контроля траффика по методу stopand-wait?

Управление потоком данных - sliding window • Более совершенный подход к управлению трафиком, чем Stop-and-wait – Sliding window или окно (пакетной) передачи переменной длительности • Все современные продвинутые протоколы используют его • Особенности метода Stop-and-Wait: Ø В пути находится в любой момент времени не более одного пакета Ø Отправитель посылает по одному пакету Ø Получатель отвечает пакетом-подтверждением после получения каждого пакета Ø После получения подтверждения, отправитель посылает новые данные Ø Если наступает событие «timeout» (превышение лимита времени, отведенного на ожидание подтверждения), отправитель посылает текущий пакет еще раз Ø Для отслеживания дубликатов, применяется 1 -битовый счетчик

Недостаток метода контроля траффиком Stop-and. Wait Узкое место (bottleneck) – участок, который ограничивает пропускную способность: 10 Mbps Москва Ростов Для характеристики временной задержки на двойном пробеге пакета или другими словами времени, затрачиваемом на получение ответа, применяют параметр RTT (Round-Trip Time) - время оборота сообщения, время кругового обращения пакета данных, то есть время прохождения пакета (сообщения, дейтаграммы) до адресата и обратно, например, от клиента серверу и обратно. Включает в себя задержки инициирования соединения, задержки пересылки, а иногда и время, затрачиваемое получателем на обработку сообщения от отправителя для формирования ответа. Параметр RTT в некоторых алгоритмах маршрутизации используется для определения оптимальных маршрутов, а также эффективности того или иного способа соединения.

Недостаток метода контроля траффиком Stop-and. Wait Узкое место (bottleneck) – участок, который ограничивает пропускную способность: 10 Mbps Москва Ростов 50 ms Пусть RTT=50 мс. Тогда каждую секунду передается 1000 мс / 50 мс/пакет = 20 pps (пакетов в секунду). Допустим для простоты, что пересылаются Ethernet-фрэймы, тогда один пакет обычно равен ~ 1. 5 kb (вспомните параметр MTU в сетях Ethernet, устанавливающий ограничение в 1518 байт). 1. 5 kb ~ 12 kbit. Следовательно, каждую секунду способно передаваться 20 pps * 12 kbit = 240 kbps. Сравните с узким местом в 10000 kbps! Используется только 2% пропускной способности сети.

Как эту проблему решает sliding window? Узкое место (bottleneck) – участок, который ограничивает пропускную способность: 10 Mbps Москва Ростов 50 ms Пусть RTT=50 мс. Как метод управления потоком sliding window преодолевает проблему неполной загруженности канала связи? • Обобщение метода stop-and-wait: разрешаются многочисленные “un-acked” сегменты (то есть получение которых еще не подтверждено). Вместо единственного пакета, «в полете» может находиться несколько • Ограничение на число таких сегментов называется окном (window) • Это позволяет заполнить линию передачи данных

Как эту проблему решает sliding window? data Москва Ростов ack Например, если число одновременно посылаемых пакетов n = 5, то на пути к получателю будет находиться 5 пакетов, а от него к отправителю – 5 подтверждений ack’s. Таким образом, идея состоит в том, чтобы подобрать число n (размер окна) так, чтобы использовать пропускную способность максимально эффективно. Если n = 1, то мы имеем просто опять stop-and-wait.

Как эту проблему решает sliding window? Узкое место (bottleneck) – участок, который ограничивает пропускную способность: 10 Mbps Москва Ростов 50 ms Какой должен быть размер окна n, чтобы добиться скорости 10 Mbps на рисунке выше? Если RTT=50 мс, то каждую секунду передается 1000/50 мс/пакет = 20 пакетов/с. Один пакет ~ 12 кбит. Тогда n*20*12 kb/s = 10 Mb/s = 10000 kb/s. Отсюда n = 10000/240 ~ 41. То есть оптимальная загрузка – когда в пути находятся 41 пакет одновременно.

Сравнение работы механизмов контроля траффика sender Stop-and-Wait receiver d 0 d 1 d 2 Sliding window (пусть n = 3) a 0 a 1 a 2 a 3 a 5 d 3 d 4 d 5 d 6 d 4

Работа отправителя в режиме sliding window • • • Каждому сегменту присваивается порядковый номер (Seq. No). В протоколах типа TCP обычно нумеруются байты т. к. пакеты могут иметь разный размер (см. предыдущие лекции), но по сути, это все равно что нумеровать пакеты Хранятся 3 переменные: Ø Размер окна на передачу - Send window size (SWS), например SWS = 3 как на предыдущем слайде Ø Номер последнего полученного подтверждения о доставке - Last acknowledgment received (LAR), например LAR = 4 Ø Последний посланный сегмент - Last segment sent (LSS) Отправитель поддерживает неизменным (инвариантным) значение следующего выражения: (LSS - LAR) ≤ SWS. Другими словами, если получен пакет с номером n на другом конце линии связи, то отправитель не может послать пакет с номером, превышающем значение (n+SWS) После получения каждого подтверждения о доставке, LAR увеличивается на 1 Происходит буферизация сегментов в количестве, не превышающем число SWS, на случай если получено подтверждение для всех пакетов в пути, и можно посылать сразу серию из SWS-пакетов Если получены все пакеты, кроме младшего с номером n, то окно «застопорится» до тех пор, пока не будет получено подтверждение для самого первого неподтвержденного пакета

Работа получателя в режиме sliding window • Получатель тоже хранит 3 переменные: Ø Размер окна на прием - Receive window size (RWS) Ø Номер последнего сегмента, который можно принять - Last acceptable segment (LAS). Если вдруг получен пакет с номером, превышающем LAS, то он просто игнорируется Ø Последний принятый сегмент - Last segment received (LSR) • Неизменным (инвариантным) поддерживается значение следующего выражения: (LAS - LSR) ≤ RWS • Например, если RWS = 5, LSR = 3, то будут приниматься только пакеты с номерами 4, 5, 6, 7, 8 • После получения каждого пакета, если его номер < LAS, отправляется подтверждение о получении Ø Зачастую отправляются кумулятивные (накопленные) подтвержденияacks: если получены пакеты 1, 2, 3, 5, то подтверждается только 3 – старший в серии подряд полученных сегментов Ø Особенность протокола TCP: в качестве acks применяется номер следующего ожидаемого сегмента (то есть для примера выше, ack = 4). Если получен сегмент с номером n, то получатель подтвердит сегмент с номером (n+1), или номер следующего ожидаемого байта в реальности

RWS, SWS, и пространство номеров сегментов • В stop-and-wait достаточно было одного байта для нумерации пакетов, при условии что они не задерживаются более чем на RTT. Какая нумерация необходима в sliding window для контроля дубликатов? • RWS ≥ 1, SWS ≥ 1 • RWS ≤ SWS (иначе бесполезные потери: отправитель никогда не отправит так много пакетов, и память буфера, выделенная на RWS, не будет задействована) • Однако, бывает что RWS < SWS, и все отлично работает • Если RWS = 1, то имеем дело с протоколом “go back N”, и тогда необходимы SWS+1 порядковых номеров сегментов Ø Пример: пусть SWS=3, RWS=1, отправлены пакеты 0, 1, 2 Ø Пусть они все получены – отправитель получил ack для пакета 2, тогда отправляются пакеты 3, 4 и 5 после подтверждения каждого из пакетов 0, 1, 2 Ø Если пакет 3 потерялся в пути, то получатель все же примет 4 и 5, но будет посылать опять ack для пакета 2 после получения 4 и 5 Ø Тогда, по истечении таймаута, отправитель пошлет опять пакеты 3, 4, 5 Ø Если бы RWS=3 тоже, то получатель мог бы буферизовать в памяти 4 и 5 и нужен был бы только 3, а так приходится все начинать с 3

RWS, SWS, и пространство номеров сегментов • Если RWS = 1, то имеем дело с протоколом “go back N”, и тогда необходимы SWS+1 порядковых номеров сегментов Ø Чтобы повторно посланный пакет имел другой номер и отличался от исходного, для которого например запоздал ack, необходима нумерация пакетов (SWS+1) числами • Если RWS = SWS, то необходимо 2*SWS порядковых номеров сегментов • В общем случае, необходимы RWS+SWS порядковых номеров сегментов Ø RWS-пакеты пребывают в неопределенном состоянии (их ACK может быть потерян, а может - нет) Ø SWS-пакеты, которые находятся в пути, не должны переполнять пространство номеров сегментов

Управление траффиком в протоколе TCP • Как это работает в реальности? • Ранее мы разбирали формат TCP-сегмента: 3 поля его заголовка отвечают за контроль траффика с плавающим окном

Управление траффиком в протоколе TCP • Получатель декларирует RWS с помощью поля “window”, в байтах – то есть размер буфера, в пределах которого будут приниматься пакеты • Отправитель может посылать данные только в пределах LAR + window, чтобы не переполнить буфер получателя • Таким образом и задается окно

Пример работы sliding window Для простоты опять говорим о пакетах, а не байтах как в TCP Пространство порядковых номеров – от 0 до 29 на рисунке ниже Пусть RWS = 5, SWS = 5 Посылаются первые 5 пакетов от 0 до 4, все они подтверждаются, отправляются следующие пакеты, но пакет 5 теряется • При получении следующих пактов, посылается все время ack 4 • Когда по истечении таймаута, пакет 5 посылается заново и доходит с подтверждением, то отправитель сразу может послать ack 8 (или ack 9), так как пакеты со следующими номерами могли быть сохранены в памяти буфера • •

Пример работы sliding window • Пусть RWS = 2, SWS = 3 • Посылаются первые 3 пакета от 0 до 2, все они приходят и подтверждаются, посылаются следующие пакеты один за другим • Допустим, получение пакета 3 подтверждается, а 4 – теряется • То есть ack 3 получен, пакет 5 - тоже, а 4 - потерян • Опять посылается ack 3, так как подтверждения кумулятивные • По истечении таймаута, пакет 4 посылается опять • Когда он успешно принимается, то посылается сразу ack 5 так как RWS = 2 и пакет 5 уже был буферизован ack 3 ack 5

Управление траффиком по методу sliding window • • • Резюме: Sliding window допускает нахождение в пути окна “window” пакетов, получение которых не подтверждено Если окно подобрано правильным образом, то емкость получателя используется по максимуму, в отличие от stop-and -wait При получении подтверждения, окно перемещается, подтверждения обычно кумулятивные Размер требуемого пространства порядковых номеров зависит от размера окна В протоколе TCP размеры задаются в байтах, а пространство порядковых номеров – большое, чтобы застраховаться от сильно запаздывающих пакетов