Я хочу использовать trickle на Распбиане.
Кажется, это может быть использовано при запуске исполняемого файла следующим образом:
trickle -u {up} -d {down} {program}И это также может быть использовано для всех приложений. например:
trickled -d 50 -u 10Страница man говорит, что первое не может быть использовано в статически связанных исполняемых файлах. Поэтому мой вопрос: применим ли второй пример использования ко всем программам, независимо от того, связаны они статически или нет?
Спасибо
trickled использует ту же технику для ограничения пропускной способности, что и trickle . Он просто прослушивает сокет домена UNIX в /tmp для других trickle процессов. Когда другой процесс trickle запускается, он задаст trickled (если он работает) для глобальных параметров, и установить их в качестве настроек по умолчанию, если он не имеет отдельное переопределение для этого конкретного экземпляра trickle
Полностью статически связанный исполняемый файл (означающий, что все, включая libc, статически компилируется в двоичный файл) не может использоваться с процессом пользовательского пространства, таким как trickle . Что в конечном итоге происходит со статически связанным исполняемым файлом, так это то, что он делает системные вызовы непосредственно в стабильный двоичный интерфейс приложения (ABI) ядра Linux - <->. Он не пытается загрузить какие-либо библиотеки в /lib , /usr/lib , /usr/local/lib и т.д. Для разрешения символов.
Магия trickle в том , что она эффективно внедряет собственный код в процессы , которые динамически загружает библиотеку C из системы. Процессы, которые этого не делают, или процессы, которые имеют установленный root, не могут изменять свой код таким образом.
Чтобы по-настоящему контролировать все процессы в системе, этот уровень ограничения пропускной способности должен выполняться в самом ядре.
Существует несколько реализаций ядра, как старых, так и новых, с функциями формирования трафика (формирование трафика - это обобщенный термин для ограничения пропускной способности, и, как правило, это означает изменение синхронизации или планирования пакетов) в самом ядре Linux, и это гораздо больше. надежный. Вот более свежий пример, основанный на инфраструктуре nf, которая должна заменить iptables в качестве стека политик 3 и стека управления для современного Linux.