Я запускаю маршрутизатор Linux (точнее OpenWRT) в интернет-соединении с очень ограниченной пропускной способностью, около 1 Мбит / с в нисходящем направлении и несколько десятков кбит / с в восходящем направлении.
В сети есть несколько машин, которые занимаются вещами с низкой пропускной способностью, такими как воспроизведение веб-радио или отправка данных измерений. Другие машины могут иногда запускать обычные загрузки обновлений программного обеспечения.
Всякий раз, когда машина начинает загрузку, данные с низкой пропускной способностью становятся прерывистыми. Я полагаю, что полоса пропускания потока уменьшается из-за того, что на маршрутизаторе есть другое соединение, хотя оно хорошо "вписывается" в WAN ч / б. Это немного противоречит моей интуиции, и я хотел бы настроить маршрутизатор для более справедливого распределения полосы пропускания.
Под "справедливо" я имею в виду:
Предположим, что имеется пропускная способность нисходящего потока 1 Мбит / с, и используются 64 кбит / с. Следующий клиент, который обращается к глобальной сети, должен получить пропускную способность не более (1 МБит - 64 кбит) / с. Если и только если полоса пропускания нисходящего потока используется полностью, пропускная способность отдельных соединений должна быть снижена и должна быть адаптирована так, чтобы соединения регулировались пропорционально их размеру (чем меньше, тем меньше).
Во-первых, правильно ли я понимаю проблему? Если да, что я могу сделать, чтобы повлиять на распределение полосы пропускания маршрутизатора? Примечание: я делаю не хотят то, что обычно рекомендуется в литературе, а именно ограничение пропускной способности каждого клиента до доли от общей доступной пропускной способности. На моем сайте слишком малая скорость WAN для этого.
В целом вы правильно понимаете проблему, но предлагаемое вами решение ОЧЕНЬ сложно реализовать. Вопросы «Что такое клиент?» и "Что такое связь?" подойти, и может быть трудно ответить хорошо.
Более типичная стратегия ограничения полосы пропускания выглядит примерно так:
VOIP может использовать более 192 Кбит / сек, поэтому мы можем позволить ему заимствовать из пула «все» (или наоборот). Когда пул "все" насыщен, начните отбрасывать пакеты, как если бы восходящий канал был ДЕЙСТВИТЕЛЬНО насыщен (используя, например, Случайное раннее обнаружение выбрать жертв падения.
Обычно это делается для трафика UPSTREAM. Нисходящий трафик может быть ограничен таким же образом, но вы не можете избежать насыщения канала из-за нисходящего трафика (пакеты все равно должны поступить на ваш брандмауэр, прежде чем можно будет принять решение о сбросе, поэтому они все еще проходят по вашему проводу. Результат представляет собой всплеск трафика, за которым следует естественный спад, поскольку протокол TCP обнаруживает перегрузку "перегрузки канала" и удаленная сторона снижает скорость передачи до тех пор, пока не прекратится потеря пакетов).
Также обратите внимание, что это не гарантирует «справедливости» для клиентских машин, за исключением того, что случайное раннее обнаружение будет отбрасывать пакеты «случайным образом» (достаточно случайным образом, чтобы клиент A не всегда отбрасывал пакеты, когда соединение установлено. насыщенный). На что вы рассчитываете, так это на то, что «случайные» сбросы будут естественным образом формировать трафик до такой степени, что вам не нужно беспокоиться о том, что один клиент истощится, в то время как другой потребляет всю полосу пропускания.
Готовое решение в вашем конкретном случае может заключаться в ограничении пропускной способности, доступной для обновлений (предположительно, они поступают из известных подсетей, поэтому ограничьте их), но это все еще связано с оговорками, о которых я упоминал выше.
В качестве альтернативы, если у вас есть доступное оборудование, вы можете распространять свои обновления с локального сервера (WSUS, локальное зеркало APT и т. Д.) - это позволит вам запланировать получение этих обновлений локально в нерабочее время, когда никто не использует вашу сеть. , и в конечном итоге сэкономит вам много трафика, передавая отдельные обновления для каждой машины.
Поскольку обновления уже являются локальными, не имеет значения, когда отдельные клиентские машины их загрузят - они не выходят в Интернет, так что пока вы не перегружаете свою локальную сеть (довольно сложно!), Вы выиграли '' t страдают от серьезных проблем с производительностью. Обратной стороной, конечно же, является то, что вам нужно потратить время и оборудование на настройку сервера обновлений.
Вот этот довольно старый сценарий, который делает именно это. Пользуюсь им уже много лет.
Он делает довольно сложные вещи за кулисами, но фактическая конфигурация, ориентированная на пользователя, довольно проста.
Моя вилка: https://github.com/kalmi/FairNAT (В нем есть несколько небольших исправлений, позволяющих работать в последних версиях Linux)
Есть версия скрипта для openwrt, но пока не использовал.
(Мне пришлось отключить поддержку TOS, потому что это вызывало случайные сбросы TCP для некоторых сайтов (wikia, imgur и т. Д.). Вероятно, это из-за каких-то странностей с этим конкретным вышестоящим ISP, но я не знаю.)
Нет, сейчас нет хорошего способа сделать это. Основная проблема заключается в том, что ваш интернет-провайдер решает, какие пакеты передавать по вашей ссылке, и у него нет никакой информации, которую он мог бы использовать для принятия этого решения. Короткий печальный ответ заключается в том, что доступ в Интернет для потребителей просто не предназначен для этого.