пятница, 16 мая 2008 г.

Ограничение сетевого трафика для приложений

Допустим, Вы собрались закачивать что-то неимоверно тяжелое, или запустить какое-то приложение, нещадно пожирающее сетевые ресурсы. Допустим, Вам этих сетевых ресурсов жалко. Может быть Вы сейчас активно бороздите просторы веба. А может быть каналом пользуются ваши сотрудники, и загружать его полностью было бы по крайней мере нетактично. Но все же, если уж нам чего-то захотелось, то лучше это сделать сейчас, а не откладывать в долгий ящик. Для этого будет логичным пойти на компромис: запустить приложение с ограничением пропускной способности канала. К счастью, GNU/Linux как всегда предлагает простое и незатейливое решение. Отдельное спасибо Мариусу :-)

Если Вы еще не знакомы, то прошу любить и жаловать: мистер trickle!

$ sudo apt-get install trickle


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

Ладно, хватит болтовни, приступим к делу. Загрузим страничку mail.ru. Но поскольку она очень большая и тяжелая, ограничим скорость закачки до 2 КБ/сек, чтобы не перегружать наш драгоценный канал.

$ trickle -d 2 wget mail.ru
trickle: Could not reach trickled, working independently: No such file or directory
--14:40:28-- http://mail.ru/
=> `index.html.5'
Распознаётся mail.ru... 194.67.57.226, 194.67.57.26, 194.67.57.126
Устанавливается соединение с mail.ru|194.67.57.226|:80... соединение установлено.
Запрос HTTP послан, ожидается ответ... 200 OK
Длина: нет информации [text/html]
[ <=> ] 24 576 2.00K/s


И, как говорится, пошло говно по трубам! Но, на безопасной скорости :-)

Трикл имеет два наиболее интересных параметра:
-d - скорость закачки в килобайтах в секунду
и
-u - скорость откачки в тех же единицах измерения.
Список остальных параметров доступен в мане.

Обратите внимания на первую строку вывода команды: "trickle: Could not reach trickled, working independently: No such file or directory". Похоже на сообщение об ошибке, но это просто сообщение о том, каким образом будет работать трикл :-) Дело в том, что он может работать в двух режимах: независимо и через демон. Демон удобен в том случае, если вам нужно ограничить суммарный трафик для нескольких приложениях. Запускаем демона с указанием параметров ограничения

$ trickled -d 5


И теперь каждый экземпляр trickle будет подключаться к демону, при этом указывать пропускную способность больше не нужно. Как остановить демон в мануале не написано. Поэтому я это делаю посредством killall trickled.

По умолчанию утилита trickle общается с демоном trickled через сокет "/tmp/.trickled.sock". Если вам нужно запустить второго демона и направить на него другие экземпляры trickle, используйте параметр -n с указанием другого имени файла сокета.

$ trickled -d 1 -n /tmp/.trickled_1.sock
$ trickle -n /tmp/.trickled_1.sock wget rambler.ru


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

Ну, думаю, этого должно хватить с головой. А если не хватит, то спрашивайте.

Качайте на здоровье!

16 комментариев:

  1. Анонимный18 мая 2008 г., 15:55

    Хорошая статья, переведи на английский и отправь на debaday.debian.net , там статей не хватает

    ОтветитьУдалить
  2. Спасибо. У меня еле хватило времени, чтобы ее написать на русском. А на английском - уж точно руки не дойдут :-)

    ОтветитьУдалить
  3. Полезная информация, спасибо. Только пример с wget не очень удачный. У самого wget есть ключик для ограничения скорости скачивания:

    wget --limit-rate=2k mail.ru

    ОтветитьУдалить
  4. Да, пример чисто формальный и, прямо скажем, совершенно неудачный, поскольку не наводит на мысль о том, в чем именно это можно использовать :-) Лично я использовал это для ограничения скорости закачки утилиты apt-get.

    ОтветитьУдалить
  5. А есть что-нибудь аналогичное для ограничения IP адресов? (программа не должна потреблять "внешний" траффик, а только "внутрений").

    ОтветитьУдалить
  6. С таким к сожалению не сталкивался.

    ОтветитьУдалить
  7. Огромное спасибо за статью - давно не хватало чего-то подобного.

    2 анонимус:
    > А есть что-нибудь аналогичное для ограничения IP адресов? (программа не должна потреблять "внешний" траффик, а только "внутрений").

    Есть. Называется эта вещь "iptables" ;)

    ОтветитьУдалить
  8. Да, iptables рулят ))) Они настолько просты, что я, честно говоря, так и не научился ими пользоваться. Не запоминается. Намного больше мне в этом плане нравится Shorewall. Хоть он и сложнее, он раскладывает все по полочкам, и раз научившись им довольно просто пользоваться.

    ОтветитьУдалить
  9. А не подскажете ли такую программу для Linux, чтобы она работала на прокси-сервере linux, а на рабочих станциях Windows стоял бы клиент (наподобие VPN), чтобы с рабочей станции в интернет могли выходить только авторизованные программы? Т.е. на примере, на раб. станции есть Mozilla, адрес ее "exe-файла" прописывается в базу доверенных приложений и только эта прога с этого ip-адреса сможет выйти в интернет через прокси-сервер?

    ОтветитьУдалить
  10. С таким, к сожалению, не сталкивался. Могу только выразить свое сомнение в том, что VPN вам поможет решить поставленную задачу. И вообще слабо себе представляю, как сервер может определить, какая программа к нему подключается. Не помню, чтобы заголовки пакетов TCP/IP содержали такие данные. Попробуйте посмотреть на возможности различных прокси-серверов и поспрашивать на специализированных форумах.

    ОтветитьУдалить
  11. Дошло. Ставлю OpenVPN на шлюз и на раб. станции (авторизация по сертификату). На шлюзе брандмауэром блокирую все обращения из локальной сети, кроме порта OpenVPN.

    А на раб. станции ставлю брандмауэр с функцией контроля приложений, и разрешаю доступ к ip, созданному OpenVPN, только тем программам, которые должны иметь такой доступ. Вот. И тогда даже если внутри локалки все могут ходить куда захотят, но в интернет можно быдет попасть только через OpenVPN :)

    Паранойя рулит :)

    ОтветитьУдалить
  12. Если у Вас есть возможность установить на рабочей станции брандмауэр с функцией контроля приложений, то этого будет достаточно. Я не вижу никакой необходимости поднимать VPN.

    ОтветитьУдалить
  13. Честно говоря, мне и самому уже показалось, что я - извращенец! Я уже неделю обдумываю, как обстряпать мой вопрос - и, ух-ха-ха, ответ настолько тривиальный, что я и сам подивился :) Пора домой... А то еще хуже будет :)

    ОтветитьУдалить
  14. Я ведь уже шел ставить openvpn!!!

    ОтветитьУдалить
  15. Удачной Вам реализации задуманного! :)

    ОтветитьУдалить
  16. Для Raa: Не можешь пользоваться iptables, пользуйся shorewall - проще уже не куда, практически делает все за тебя... это генератор правил iptables. ;)

    ОтветитьУдалить