Flow Control — опция необходима для защиты от переполнения буфера, включать необходимо при большом входящем трафике.
Включать или нет: только если наблюдаются странности в работе сети при большом количестве входящего трафика (обычно для игр включать ненужно).
Эта настройка предназначена для ситуаций, когда входящего трафика так много, что может произойти ошибка переполнения буфера, при котором оборудование отправляет команду паузы, после которой повторил отправку данных спустя некоторое время. Если подобную команду не послать — будет перегрузка, часть данных может потеряться, в итоге могут быть например глюки в игре. Также стоит понимать, что из-за команды паузы — увеличится значение пинга.
Функция полезна, когда происходит загрузка большого количества данных, например торренты. Игры обычно не имеют настолько активный трафик.
Функция например присутствует в сетевом адаптере D-Link DFE-550TX.
Flow Control включать стоит, когда наблюдаются непонятные задержки, обрывы, пропадания, лаги, тормоза при просмотре онлайн-видео. Также эту опцию включают при соединении разноскоростного оборудования или разноскоростных сетей, образно говоря, чтобы скоростная сеть не забила трафиком порт менеескоростной.
Опция сетевого адаптера Realtek:
Однако также спокойно может встречаться и в адаптерах других производителей, например Intel, Atheros.
Кстати открыть диспетчер устройств можно простым способом — зажмите Win + R, появится окошко Выполнить, вставьте команду devmgmt.msc и нажмите ОК.
Управление потоком IEEE 802.3x обеспечивает функции управления трафиком для режима полного дуплекса. Управление потоком позволяет улучшить работу сетевого адаптера в режиме полного дуплекса с коммутатором. При работе в полном дуплексе (при этом требуется непосредственное подключение к коммутатору) и при угрозе переполнения буфера данных коммутатора, сетевой адаптер получит специальный кадр паузы. Последующий промежуток времени защищает буфер от переполнения и предотвращает потерю данных. Эта технология может улучшить общую производительность сети, предотвращает потерю данных и помогает достичь оптимальной производительности в сети.
1) По сути Flow Control нужен в том случае если устройства на одном линке имеют разную произвиодительноть по приёму передаче кадров. Посылка стопового сигнала помогает избежпть потерь кадров.
2) Flow Control должен быть включён или выключен на обоих концах линка, т.е. сетевая карта конечно тоже должна поддерживать эту функцию и причём если на свитче она включена на сетвой карте она тоже должна быть включена.
3) Между управляемым и неуправляемым тоже может работать.
4) Последствия могут быть только если есть несоотвествие выбора режима работы функции на обоих концах линка.
5) На некоторых сериях свитчей например DES-30XX для корректной работы функции Bandwidth Control функция Flow control должна быть включена.
Управление потоком важно, потому что отправляющий компьютер может передавать информацию с большей скоростью, чем конечный компьютер может ее получать и обрабатывать. Это может произойти, если получающие компьютеры имеют большую нагрузку по трафику по сравнению с отправляющим компьютером или если принимающий компьютер имеет меньшую вычислительную мощность, чем отправляющий компьютер.
СОДЕРЖАНИЕ
Остановись и подожди
Операции
Если кадр или ACK потеряны во время передачи, кадр передается повторно. Этот процесс повторной передачи известен как ARQ ( автоматический запрос на повторение ).
Проблема с остановкой и ожиданием заключается в том, что за один раз может передаваться только один кадр, и это часто приводит к неэффективной передаче, потому что, пока отправитель не получит ACK, он не может передать ни одного нового пакета. В это время и отправитель, и канал не используются.
Плюсы и минусы остановки и ожидания
Остановка и ожидание также могут снизить эффективность при отправке более длительных передач. Когда отправляются более длинные передачи, вероятность ошибки в этом протоколе выше. Если сообщения короткие, скорее всего, ошибки будут обнаружены на ранней стадии. Большая неэффективность создается, когда отдельные сообщения разбиваются на отдельные кадры, поскольку это увеличивает продолжительность передачи.
Раздвижное окно
Метод управления потоком, при котором приемник дает передатчику разрешение на передачу данных до тех пор, пока не заполнится окно. Когда окно заполнено, передатчик должен прекратить передачу, пока приемник не объявит о большем окне.
Управление потоком через скользящее окно имеет гораздо лучшую производительность, чем управление потоком с остановкой и ожиданием. Например, в беспроводной среде, если скорость передачи данных низкая, а уровень шума очень высок, ожидание подтверждения для каждого передаваемого пакета не очень возможно. Следовательно, передача данных в виде большого количества данных даст лучшую производительность с точки зрения более высокой пропускной способности.
Вернуться N
Алгоритм автоматического запроса на повторение (ARQ), используемый для исправления ошибок, в котором отрицательное подтверждение (NAK) вызывает повторную передачу слова с ошибкой, а также следующих N – 1 слов. Значение N обычно выбирается таким образом, чтобы время, необходимое для передачи N слов, было меньше, чем задержка приема-передачи от передатчика к приемнику и обратно. Следовательно, в приемнике не требуется буфер.
Выборочный повтор
Сравнение
Остановись и подожди
Выборочный повтор
Управление потоком передачи
Управление потоком передачи может происходить:
Скорость передачи может контролироваться из-за требований сети или DTE. Управление потоком передачи может происходить независимо в двух направлениях передачи данных, что позволяет скоростям передачи в одном направлении отличаться от скоростей передачи в другом направлении. Управление потоком передачи может быть
Управление потоком может быть выполнено
Аппаратный контроль потока
В обычном RS-232 есть пары линий управления, которые обычно называют аппаратным управлением потоком :
Аппаратным управлением потоком данных обычно занимается DTE или «главный конец», поскольку он сначала поднимает или утверждает свою линию, чтобы передать команду другой стороне:
Примером аппаратного управления потоком данных является полудуплексный радиомодем с компьютерным интерфейсом. В этом случае управляющее программное обеспечение в модеме и компьютере может быть записано так, чтобы отдавать приоритет входящим радиосигналам, так что исходящие данные с компьютера приостанавливаются путем понижения CTS, если модем обнаруживает прием.
Программное управление потоком
И наоборот, XON / XOFF обычно называют программным управлением потоком.
Управление потоком без обратной связи
Механизм управления потоком без обратной связи отличается отсутствием обратной связи между приемником и передатчиком. Это простое средство контроля широко используется. Ресурсы должны выделяться по типу «предварительное резервирование» или «переход от участка к узлу».
Управление потоком без обратной связи включает два элемента управления; контроллер и регулятор. Регулятор может изменять входную переменную в ответ на сигнал от контроллера. Система без обратной связи не имеет механизма обратной связи или прямой связи, поэтому входные и выходные сигналы не связаны напрямую, и существует повышенная изменчивость трафика. В такой системе также более низкая скорость поступления и более высокая скорость потерь. В открытой системе управления контроллеры могут управлять регуляторами через равные промежутки времени, но нет гарантии, что выходная переменная может поддерживаться на желаемом уровне. Хотя использование этой модели может быть дешевле, модель с открытым контуром может быть нестабильной.
Управление потоком с обратной связью
Эта система включает в себя все основные элементы управления, такие как датчик, преобразователь, контроллер и регулятор. Датчик используется для захвата переменной процесса. Переменная процесса отправляется на передатчик, который транслирует переменную в контроллер. Контроллер проверяет информацию относительно желаемого значения и при необходимости инициирует корректирующее действие. Затем контроллер сообщает регулятору, какие действия необходимо предпринять, чтобы убедиться, что значение выходной переменной соответствует желаемому значению. Следовательно, существует высокая степень уверенности в том, что выходная переменная может поддерживаться на желаемом уровне. Система управления с обратной связью может быть системой обратной связи или прямой связи:
Система обратной связи с обратной связью имеет механизм обратной связи, который напрямую связывает входные и выходные сигналы. Механизм обратной связи контролирует выходную переменную и определяет, требуется ли дополнительная коррекция. Значение выходной переменной, подаваемое в обратном направлении, используется для инициирования корректирующего действия на регуляторе. Большинство контуров управления в отрасли относятся к типу обратной связи.
В замкнутой системе с прямой связью измеряемая переменная процесса является входной переменной. Затем измеренный сигнал используется так же, как в системе обратной связи.
Модель с обратной связью обеспечивает более низкий уровень потерь и задержек при постановке в очередь, а также приводит к трафику, реагирующему на перегрузки. Модель с обратной связью всегда устойчива, так как количество активных минимумов ограничено.
«Распределенное управление информационными потоками»/«Distributed Information Flow Control»
Мотивация Практически единственным способом обеспечивать безопасность и приватность данных в системе принято считать аутенификацию (отвечает на вопрос: «Кто это сказал?») и авторизацию («Что он имеет право делать с этими данными»). Т.е. если программе необходим доступ к некоторым данным, мы фактически имеем 2 варианта: отказать или поверить. Если мы не доверяем этой программе, то теряем возможность работать с ней и возможно лишаемся важной функциональности. Если же мы решаем, что доверяем программе (и/или ее разработчикам), то программа фактически становится «полновластным хозяином» этой информации (или копии). Такой принцип в литературе называют All-Or-Nothing — «Все или ничего».
Естественно, что этот принцип недостаточно гибок и кроме того является основной причиной многих уязвимостей в системах, таких как переполнение буфера. В общем случае, этот принцип не позволяет создавать более интересные приложения, где права доступа не ограничиваются традиционными: «no access», «read only» и «read/write». Оказывается, что существуют системы, которые позволяют намного более гибкие разграничения прав доступа к данным — системы с поддержкой управления информационными потоками. Самой главной особенностью этих систем является то, что они следят за данными на всем протяжении их жизненного цикла в системе. Вспомним, что традиционно система ответственна только за начальный доступ к данным, например, проверку имеет ли программа доступ к файлу, а что после этого программа делает с этими данными систему уже не интересует.
Классический пример. Допустим, что в системе есть 2 пользователя Алиса и Боб. Они хотят назначить встречу, но так чтобы не раскрывать слишком много информации о своем расписании недели. Можно ли в многопользовательской системе Linux/Unix/Windows написать программу таким образом, чтобы она имела одновременный доступ к календарям и Алисы, и Боба и гарантировала конфиденциальность обоих пользователей системы?
Самый простой способ — попросить «суперпользователя» написать такую программу или хотя бы правильно назначить права на уже существующе решение. Но этот путь создает как минимум 2 проблемы:
1. Нет гарантии, что программа не содержит логических ошибок и, например, не скопирует данные Алисы куда-нибудь еще (или админ неправильно назначит права). 2. Нужно доверять на все 100% «суперпользователю» и кроме того, такой процесс неинтерактивен, т.е. ждать пока админ напишет такую программу или выставит права.
Решение первой проблемы осуществляется при помощи систем с поддержкой управления информационными потоками.
В общем системы с поддержкой управления информационными потоками условно делятся на 2 категории: централизованные и распределенные (децентрализованные). К централизованным относят всем известные SELinux и AppArmor. В этой же статье я постараюсь рассказать о децентрализованных системах, на примере исследовательской (следовательно совершенно непригодной для реального использования, к сожалению) ОС Flume, т.к. имел некоторый опыт «общения» с ней. Децентрализованные системы позволяют избавиться и от второй проблемы — зависимость от суперпользователя.
(Distributed) Information Flow Control Если кратко, то идея контроля потока информации тривиальна и заключется в том, чтобы отслеживать как данные «перетекают» в системе от отправителя к получателю. Главная задача системы предотвратить несанкционированную утечку данных из нее. В общем случае, ни одна программа (кроме «привилегированной») не может иметь одновременный (в контексте жизни программы) доступ к приватным данным и любому «стоку информации» (sink), таким как монитор, принтер, сокет (AF_INET). Т.е. если программа один раз прочитала мои личные файлы, то после этого система не позволит этой программе иметь доступ к сети.
Для того чтобы сделать данные приватными необходимо явно это указать, например, с помощью специальных флагов/тэгов. Вот тут и главное различие между централизованными и распределенными системами. В первом случае существует особый пользователь — «менеджер безопасности», который ответственен за правильное «тэгирование» данных и определение прав доступа различных программ к таким данным. Например, можно назначить тэг «особо секретно» на файлы с вашими паролями или информацией о личных доходах и разрешить доступ к нему только для Vim/Emacs без прав (1) эти данные экспортировать куда бы то ни было и (2) снять эти тэги. Таким образом, даже если скомпроментировать ваши текстовые редакторы, то система (предполагая, что сама система безопасна и работает без ошибок) не позволит сохранить эти файлы где-либо в системе (/tmp) с другими более разрешающими тэгами и отослать их каким-либо образом в Интернет. Я не работал с SELinux, поэтому отсылаю вас к официальным руководствам за дальнейшей информацией.
В распределенных же системах любая программа/сущность может создавать свои тэги, назначать права и давать доступ к своим данным для других программ.
В ОС Flume вы можете создать тэг для доступа к некоторым личным данным. Причем у вас есть выбор. Можно отдать в открытый доступ права на назначение этого тэга и/или на его удаление. Допустим, что мы создали тэг tag1 и отдали в открытый доступ право , тогда любая программа может поместить этот тэг в свой собственный набор тэгов. Если мы создадим файл F и ассоциируем его с тэгом tag1, то любой процесс p1 может включить в свой набор тэгов этот тэг tag1 и после этого сможет читать все данные, помеченные tag1. Однако, так как не в открытом доступе, то этот процесс не сможет удалить tag1 со своего набора тэгов и отныне может общаться только с процессами, с набором тэгов, которые являются надмножеством аналогичного набора процесса p1.
В принципе система должна гарантировать, чтобы процесс мог послать сообщение другому только при условии, что получатель имеет как минимум такой же набор меток (или даже больший), что и отправитель, а также, что ни один процесс с непустым набором не имеет доступа к «стоку» информации (по мат индукции доказывается, что система с такими условиями безопасна). Disclaimer: в оригинальной статье более формальная формулировка и помимо тэга безопасности еще есть понятие тэга целостности, но в этой статье я его не рассматриваю.
Flume — это одна из разработанных систем, которая обеспечивает «правильность» потока информации. На системном уровне Flume — это Linux с модифицированной системой LSM, которая перехватывает основные системные вызовы, хранит информацию о тэгах, метках и проверяет на корректность потока данных от одного процесса к другому.
Теперь вернемся к примеру с календарем Алисы и Боба. В ОС Flume Алиса назначит тэг A для своего календаря, а Bob для своего — тэг B. Алиса отдает в открытый доступ , а Боб . Боб запускает программу с меткой , т.е. с возможностью доступа к обоим календарям. Эта программа находит несколько удобных временных промежутков, где ни Алиса, ни Боб не заняты, снимает с себя тэг B ( в открытом доступе) и записывает результат в файл F, который получает автоматический тэг A ( не в открытом доступе). Алиса открывает файл F, т.к. она является владельцем тэга A и выбирает конкретную дату из списка «предложенных Бобом». На всякий случай напомню, что не в открытом доступе, поэтому Алиса не может читать календарь Боба.
Заключение К сожалению, я не смогу охватить всех сфер применимости идей DIFC (даже тех, которые использовал в качестве мотивации проблемы) Есть немало отличных статей на эту тему, начинаю с самых классических (Jiff) до достаточно свежих HiStar/DStar или Resin. При наличии интереса к данной теме могу более подробно/формально рассказать о, например, фреймворке Resin от MIT. В свое время посчастливилось побеседовать с Барбарой Лисков (которая является, наверное, одной из главных авторитетов в данной области) на тему контроля потока информации, применимости этих принципов для других задач и просто заболел этой темой. Есть несколько интересных «видений» развития этой идеи: W5 (world wide web without walls) или Fabric. Но это уже совершенно другая история…
Опция BIOS Flow Control (Контроль потока) предназначена для настройки параметров работы сетевого оборудования компьютера. Как правило, эта опция может принимать значения None (Отсутствует), Software (Программный) и Hardware (Аппаратный).
Принцип работы
В сфере сетевых технологий термином Flow Control обозначается процесс управления объемом передаваемых данных между двумя узлами сети. Цель данного процесса – предотвращение ситуации, когда более быстрый узел, отправляющий данные, обгонял бы более медленный принимающий узел. Технология Flow Control предоставляет механизм, благодаря которому узел, отправляющий данные, способен контролировать скорость передачи таким образом, чтобы принимающий узел не переполнился бы данными.
Контроль потока следует отличать от контроля переполнения, который используется для контроля передаваемых данных в том случае, если переполнение уже произошло. Существует несколько методов контроля потока, которые можно разделить на две основные категории, разница между которыми состоит в том, посылает ли принимающий узел данные на отправляющий узел или нет.
Контроль потока является важной задачей, поскольку часто встречается ситуация, когда передающий компьютер отсылает информацию быстрее, чем принимающий компьютер способен ее обработать. Это может случиться в том случае, если принимающий информацию компьютер имеет дело с более загруженным сетевым трафиком или просто имеет меньшую вычислительную мощность по сравнению с передающим устройством.
По типу реализации можно выделить два основных способа контроля потока: программный и аппаратный. Аппаратный (Hardware) способ обычно осуществляется при помощи специальных сигнальных линий, которые присутствуют в интерфейсах передачи данных. Например, в интерфейсе последовательного порта для этой цели используются служебные линии Request To Send (запрос на отправление данных) и Clear To Send (готовность к приему данных). В программном (Software) способе контроля потока используются специальные символы, которые передаются по основному каналу данных и сигнализируют о начале и конце передачи. Обычно в качестве этих символов используются байты, которые обозначаются как XON (байт, возобновляющий передачу данных) и XOFF (байт, приостанавливающий передачу данных). Для того, чтобы работал какой-либо из методов контроля потока – программный или аппаратный, необходимо, чтобы его поддерживали бы оба устройства – как принимающее, так и передающее.
Опция BIOS Flow Control обычно присутствует на материнских платах со встроенными сетевыми картами. Значение опции Hardware позволяет выбрать аппаратный способ контроля потока, а Software – программный. Значение опции None позволяет не использовать какой-либо из способов контроля потока.
В некоторых BIOS в опции Flow Control вместо вариантов Hardware и Software могут встретиться варианты CTS/RTS (от терминов Request To Send и Clear To Send) и XON/XOFF. Первый вариант соответствует аппаратному способу контролю потока, а второй – программному.
Какое значение опции выбрать?
Если установить значение опции Flow Control, равное None, то это означает, что контроль потока будет отсутствовать. В такой ситуации в процессе передачи данных может возникнуть переполнение буфера принимающего компьютера. В большинстве случаев эта ситуация нежелательна. Установка значения опции, равного Hardware или Software, помогает избежать этого.
Однако на практике часто встречается такая ситуация, когда одно из двух сетевых устройств, соединенных между собой, не поддерживает технологию Flow Control. В таком случае эту опцию лучше всего выключить, чтобы избежать ошибок. По умолчанию в большинстве случаев опция Flow Control также установлена в значение None.
Flow Control — опция необходима для защиты от переполнения буфера, включать необходимо при большом входящем трафике.
