AMDBulldozer

N.B. Не переходите по ссылкам в этом сообщении - они ведут исключительно на документы "request for comments" (на английском) на сайте IETF. Исключительно для тех, кто хочет освежить свои сведения об упоминаемых стандартах.

Да, и вообще лучше это сообщение не читайте, если у Вас не Linux-система - оно окажется для Вас абсолютно бесполезным.
Кстати, даже если у Вас всё-таки Linux-система - всё равно не читайте. Поверьте на слово: текст длинный, нудный и неинтересный.

Часто приходится сталкиваться с ситуацией, когда одно соединение с провайдером одновременно используется несколькими клиентами. При этом неизбежно возникает вопрос о справедливом разделе полосы пропускания. Чтобы не отнимать время у людей, которые хотят сразу услышать окончательное резюме, скажу прямо: способов гарантированного резервирования полосы пропускания в семействе протоколов TCP/IP не предусмотрено. Точка.

Однако есть два способа, позволяющие, тем не менее, во многих случаях ограничивать входящий трафик.
Первый применим только к TCP-сессиям и заключается в управлении размером TCP окна.
Чтобы сообщение не разрослось до невероятных размеров, рассматривать данный способ мы не будем.
Второй способ основан на "обмане" сервера. Как в случае UDP-соединения, так и TCP-сессии, отправляющая сторона обычно следит за тем, чтобы все отправленные пакеты были приняты клиентом.

Давайте рассмотрим этот процесс немного подробнее. Допустим, вы хотите получить какой-то файл с FTP-сервера. Для передачи данных сервер устанавливает TCP-сессию (да-да, для данных - именно сервер. Клиент устанавливает TCP-сессию только для передачи команд). И начинает передавать данные. Но вот вопрос - с какой скоростью их передавать? Ширину полосы пропускания канала в интернет у клиента сервер не знает. Равно как и загруженность всех промежуточных переходов. Строго говоря, он даже ширину собственной полосы знать не обязан.
Поэтому сервер использует механизм известный под названием "медленный старт" (slow start). Он начинает передавать пакеты с небольшой скоростью, но постепенно её увеличивает. Как только передаваемые пакеты начинают систематически теряться - значит достигнут предел скорости передачи.
Это означает, что клиент может "обманывать" сервер, отбрасывая поступившие к нему пакеты и сообщая о них как о потерянных, чтобы вынудить сервер снизить скорость передачи.
Работает ли такой способ? Зачастую да. Почему "зачастую", а не всегда? Причин много, назову только одну - протоколов транспортного уровня модели OSI существует много. Некоторые из, такие как RTP (протокол для передачи потоковых данных) вообще не интересуются судьбой отправленных пакетов. Ну потерялись и потерялись, что же теперь поделаешь? Не будешь же повторно передавать несколько секунд фильма, который прямо сейчас выводится на экран телевизора клиента.
Что из этого следует? Что даже если использовать способы ограничения трафика, которые будут в дальнейшем предложены в этом сообщении, они не смогут гарантировать разным клиентам равный доступ в интернет. Запустил один из клиентов просмотр потокового видео - второй причитающейся ему доли пропускной способности уже не получит. Хотя и первый смотреть фильм нормально не сможет. А уж если он из вредности запустил сразу несколько RTP-сессий, второй вообще может рыдать и биться головой о стекло монитора - его долю полосы пропускания таким способом можно легко уменьшить до нуля.
Итак, повторю еще раз: способ отбрасывания пакетов работает не всегда. Даже при использовании транспортных протоколов TCP и UDP, которые вообще-то этот метод поддерживают.
Почему он может не работать (или работать недостаточно хорошо)? Чтобы ответить на этот вопрос, необходимо более детально проследить путь пакета от сервера к клиенту.
Все знают устоявшееся в компьютерном лексиконе значение слова "пинг" (ping). Его традиционно воспринимают как время прохождения пакетов от одного узла сети до другого и обратно. Обычно в прямом направлении отправляется пакет ICMP echo request ("пинг"), на который запрашиваемый узел отвечает пакетом ICMP echo reply ("понг"). ICMP echo reply в некоторых утилитах называют иногда ICMP echo response - это одно и то же.
Для удаленных узлов значение "пинга" может измеряться сотней (или сотнями) миллисекунд. На загруженных каналах эта величина может возрастать до тысяч миллисекунд.
Почему пакет идет так долго? Ведь скорость прохождения сигнала равна скорости распространения электромагнитного поля (скорости света). Независимо от среды, будь то медь или оптоволокно.
Маршрутизация самого пакета осуществляется узлом за доли миллисекунды. Тогда где же проводит пакет всё оставшееся время от отправки до получения? Ответ прост - стоит в очереди.
Любой узел имеет очередь отправки сообщений. Известный термин "bandwidth shaping" как раз и относится к технологии, которая позволяет пропускать одни пакеты без очереди и, напротив, придерживать другие (для этого обычно создается несколько очередей, но к нашему вопросу эти частности отношения не имеют).
Почему заполняются очереди? Чаще всего потому что не хватает пропускной способности канала связи между двумя узлами (хотя могут быть и другие причины, такие как недостаточная производительность маршрутизатора).
Но, какая бы причина ни была, появление очередей вызвано одним простым фактом - пакеты поступают на узел быстрее, чем он успевает их отправлять. Это может быть временная ситуация и, не успев заполниться до конца, очередь начнет опять сокращаться. Но может быть и более постоянная. Тогда очередь переполнится и узел начнет отбрасывать пакеты.
Естественно, извещая об этом узел-отправитель. Но такое поведение мешает осуществить нашу собственную стратегию - ведь это МЫ должны быть единственным узлом во всей цепочке, который отбрасывает пакеты, чтобы быть уверенными в том, что кроме нас никто скоростью передачи пакетов сервером не управляет.
Самую большую опасность представляет для нас наш собственный провайдер. По двум причинам. Во-первых, наш канал к нему - самое узкое место на всем пути прохождения пакетов. Во-вторых, ISP зачастую имеют очень большие очереди, которые снижают эффективность нашего управления практически до нуля.
В самом деле, представьте себе автомобиль в котором педаль тормоза есть у каждого пассажира, причем каждый ей пользуется, причем педаль водителя срабатывает только тогда, когда не тормозит никто другой и с большой задержкой по времени.
Реально ли управлять таким автомобилем? Думаю, что нет. Точно так же невозможно управлять потоком данных, который массу времени проводит в очереди провайдера.
Итак, чтобы мы могли ограничивать трафик нам для начала нужно чтобы никто другой (в частности провайдер) его не ограничивал.
Как этого добиться? Самым простым путем - пакеты поступающие для нас провайдеру не должны стоять в его очереди, а сразу попадать в наш канал. Это значит, что в нашем канале всегда должно быть место для приема пакета. А это, в свою очередь, значит, что нам нужно ограничить максимальную скорость приема пакетов до величины меньшей пропускной способности канала.
То есть, намеренно оставить часть канала свободной. Какую именно часть лучше всего подбирать индивидуально. Выбирая наилучший для конкретного пользователя компромисс между точностью ограничения трафика и процентом потери пропускной способности.
Обычно хорошим начальным приближением служит резервирование 10% пропускной способности канала. То есть, если у Вас на одном канале сидят два пользователя, начните с того, что выделите каждому по 45% ширины канала.

Как это сделать практически? Часто приходится слышать, что подобные действия осуществляются с помощью уже упомянутого traffic shaping'а. Строго говоря, это неверно. Как мы уже выяснили, эта технология служит для перестановки и задержки пакетов в очередях. С целью обеспечить равномерную загрузку канала.
При отправке пакетов всё работает замечательно. Но у нас речь идет о входящем (ingress), а не исходящем (egress) трафике.
Для входящего трафика понятие очереди, вообще говоря, особого смысла не имеет. Пакет уже поступил - какая там к черту очередь? Конечно, исключительно для удобства реализации, можно создавать и очереди входящих пакетов, и промежуточные виртуальные сетевые устройства с собственными очередями (IFB, IMQ), но назначение у них обычно сугубо прикладное - использовать код уже написанный для управления egress-трафиком с целью манипуляции потоком входящих пакетов.
Позволю себе повторить еще раз: traffic shaping служит для сглаживания неравномерности отправки исходящих пакетов, путем задержки отправляемых пакетов в очереди.
Это не то, что нам нужно. Нам нужно безо всякой очереди (потому что любая очередь означает задержку, которые должны быть сведены к минимуму) отбрасывать пакеты, которые поступают со скоростью большей, чем заранее заданная.
Для подобного действия тоже существует технология, которая называется traffic policing.
Её-то мы и будем использовать. В идеале она должна быть задействована на маршрутизаторе. К сожалению, идеалы в жизни встречаются редко - большинство маршрутизаторов traffic policing не поддерживает. Только traffic shaping.
Конечно, при отсутствии других вариантов можно использовать и shaping на выходном интерфейсе маршрутизатора. Но это влечет за собой снижение эффективности управления трафиком (для отбрасывания пакета приходится ждать переполнения очереди).
К тому же, наиболее распространенные маршрутизаторы даже этого не умеют.
Но Вам не о чем волноваться. Вспомните, что у Вас Linux-система (если у Вас не Linux прочитайте еще раз заголовок сообщения), в состав любого дистрибутива которой входит утилита с незамысловатым названием tc, которое является всего лишь аббревиатурой от словосочетания "traffic control".
С её помощью Вы можете лимитировать (описанным выше способом) входящий трафик на Ваш компьютер. Какое-либо участие маршрутизатора в данном процессе не требуется.
Предположим, что нисходящий (downstream) поток данных по Вашему тарифному плану составляет 10 "честных" (то есть без учета оболочки пакетов уровня ниже сетевого) мегабит в секунду.
Создадим правило, ограничивающее входной поток на интерфейсе величиной в 4500 килобит в секунду (таким образом два компьютера поровну поделят между собой 90% ширины канала, а 10%, увы, пропадет).

Для этого достаточно двух команд.
Первая создает корневую очередь на входящем интерфейсе, вторая добавляет к этой очереди правило фильтрации пакетов.

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 0.0.0.0/0 police rate 4500kbit buffer 10k drop flowid :1

Выполнить на обоих компьютерах. Повторять после каждой перезагрузки (способ зависит от дистрибутива. Например, добавить команды в rc.local).

Дело сделано! Правила установлены и будут работать. ...кое-как. На практике, добиться равномерного распределения канала на несколько пользователей легко удается при использовании телефонного модема. Или еще чего-нибудь столь же медленного.
Чем быстрее канал - тем хуже работает фильтр.

Можно еще поиграться с размером корзины, зарезервированным процентом пропускной способности и т.д.
Это не принципиально. Основную идею лимитирования скорости при помощи traffic policing, я думаю, все поняли.
Если кому будет интересно, следующий раз напишу такое же нудное сообщение на тему "лимитирование трафика с использованием IMQ".