Я так и не понял, возможно ли ограничение скорости входящий трафик. Я понимаю что нет непосредственный метод, с помощью которого можно контролировать скорость отправки пакетов удаленным сервером (если только вы не контролируете обе конечные точки), но с учетом этого ограничения, как именно менеджеры загрузки позволяют мне успешно устанавливать ограничения скорости загрузки?
Есть ли связь между TCP медленный запуск а ограничение входящего трафика? Можно ли использовать методы, описанные в slow-start, для искусственного ограничения скорости отправки отправителем пакетов?
В качестве дополнительного соображения следует отметить, что сервер, на котором я хотел бы реализовать формирование трафика, сам устанавливает PPPoE-соединение и действует как маршрутизатор для остальной сети.
Обновить: Ответы на данный момент дают четкий обзор заданных мною вопросов, но я до сих пор не знаю, как менеджеры загрузок могут ограничивать входящий трафик, и, в частности, можно ли реализовать аналогичную стратегию на шлюзе Linux. коробка.
Менеджеры загрузки, скорее всего, работают так, как описано в тонкая бумага.
Процесс, использующий сокеты BSD, может выполнять собственное ограничение скорости. Для ограничения восходящего потока приложение может сделать это, просто ограничив скорость записи данных в сокет. Точно так же для ограничения нисходящего потока приложение может ограничить скорость чтения данных из сокета. Однако причина, по которой это работает, не сразу очевидна. Когда приложение игнорирует чтение некоторых данных из сокета, его буферы приема сокета заполняются. Это, в свою очередь, заставит принимающий TCP анонсировать меньшее окно получателя (rwnd), создавая обратное давление на базовое TCP-соединение, тем самым ограничивая его поток данных. В конечном итоге этот эффект «просачивания вниз» достигает сквозного ограничения скорости. В зависимости от буферизации на всех уровнях сетевого стека, этот эффект может проявиться некоторое время.
Если вам иногда нужно ограничить скорость одной программы в системе UNIX, простое решение: струйка. Реальное формирование трафика, как на шлюзе, может быть выполнено с tc. Это задокументировано в Глава 9. Дисциплины очередей для управления пропускной способностью руководства Linux Advanced Routing & Traffic Control HOWTO.
В случае модема 56k по сравнению с DSl-линией 4 Мбит / с, (обычно) нет никакой разницы в скорости, это просто разница в скорости соединения.
Причина, по которой трудно сформировать входящий трафик, заключается в том, что в среде передачи нет буфера. Вы либо принимаете входящие биты, либо они теряются. Для трафика, который собирается покинуть интерфейс, вы можете буферизовать и переупорядочивать пакеты столько, сколько захотите (или, по крайней мере, до доступной буферной памяти в устройстве).
Для протоколов, которые имеют слой поверх TCP (я не знаю, относится ли это к торрентам), это будет простой вопрос определения скорости запросов для дополнительных данных. В противном случае приложению потребуется взаимодействовать с ОС, чтобы отложить ACKing пакетов. Большинство протоколов на основе UDP по необходимости будут иметь логику ACK / повторной отправки в протоколе, зависящем от приложения, так что на этом этапе их выполнение будет почти тривиальным.
Одним из возможных маршрутов было бы формирование трафика из Интернета на стороне LAN вашего DSL-маршрутизатора, так как в этот момент вы должны формировать выходной порт.
Я не могу ответить, почему вы не нашли никаких решений, позволяющих формировать входящие данные (и не знаю ни одного из них в голове), но как отправитель знает, как быстро получатель может получать данные:
Базовая конструкция TCP / IP заключается в том, что для каждого пакета, который источник отправляет адресату, он должен ждать ответа от адресата (с ACK пакет), сообщая, что он получил пакет.
Итак, если у вас есть отправитель со скоростью 4 Мбит / с и получатель со скоростью 56 Кбит / с, тогда отправитель должен сидеть и ждать между отправкой пакетов, чтобы получатель ответил на каждый пакет (есть некоторые технические детали, чтобы уменьшить эти накладные расходы, но посылка все еще остается в абстрактной уровень).
Итак, что произойдет, если отправитель уже отправляет 56 Кбит / с данных, а затем пытается отправить немного больше?
Пакет теряется. (Ну, потенциально в очереди в буфере коммутатора, но когда он заполняется, пакет теряется). Поскольку пакет был потерян, получатель никогда его не получает и, следовательно, никогда не отправляет ACK пакет. Поскольку отправитель никогда не получает это ACK пакет (поскольку он никогда не был отправлен, но также может быть потерян или может произойти сбой в сети), отправитель должен Отправить дополнительный пакет. Он сидит и пытается повторно отправить пакет, пока он не пройдет и ACK ответ вернется к нему.
Итак, напомним, как только отправитель исчерпал полосу пропускания получателя, он должен останавливаться и повторно отправлять следующий пакет снова и снова, пока не станет достаточно доступной полосы пропускания для его прохождения. Это эффективно снижает скорость отправки до максимума, на котором может принимать клиент. (И есть методы оптимизации, позволяющие сократить количество повторных отправок пакета в этом случае, когда в основном отправитель замедляется каждый раз, когда ему нужно повторно отправить пакет, но это выходит за рамки этого упрощенного описания.
Вы можете сделать это с помощью интерфейса ifb.
С помощью интерфейса ifb вы можете направить входящий поток eth0 (или чего-то еще) на выход в ifb0 (например) и применить там правила ограничения.
Проверьте этот URL-адрес Linux Foundation: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb
И это скрипты, которые ограничивают входящую и исходящую полосу пропускания: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh
Обратите внимание на wondershaper: http://lartc.org/wondershaper/
По входящему трафику:
This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.
Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.
использовать UFW (Несложная противопожарная стена) http://ubuntuforums.org/showthread.php?t=1260812
В этом потоке показан простой пример, в котором по умолчанию запрещены IP-адреса с 6 попаданиями в течение 30 секунд:
sudo ufw limit ssh/tcp
Также более «продвинутая» команда с указанными значениями времени и количества попаданий.
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP