Предположим, что в офисе работают люди, которые хотят ограничить HTTP-загрузку до 40% пропускной способности скорости своего интернет-соединения, чтобы не блокировать другой трафик.
Мы говорим «это не поддерживается вашим брандмауэром», и они говорят неизбежную строку «раньше мы могли делать это с помощью нашего Netgear / DLink / DrayTek».
Если подумать, загрузка выглядит так:
HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.
Скорость определяется тем, насколько быстро сервер отправляет вам данные и насколько быстро вы их подтверждаете.
Итак, чтобы ограничить скорость загрузки, у вас есть два варианта:
1) Поручите серверу отправлять вам данные медленнее - и я не думаю, что есть какая-либо функция протокола, которая запрашивала бы это в TCP или HTTP.
2) Квитируйте пакеты медленнее, ограничивая скорость загрузки, а также снижайте скорость загрузки.
Как устройства делают это ограничение? Есть стандартный способ?
TCP сам реализует контроль перегрузки.
Эти ограничители скорости просто выбрасывают пакеты с превышением лимита. TCP обрабатывает это, гарантируя, что все пакеты прибывают и все прибывают по порядку; клиент не ACK для отброшенных пакетов, и они повторно отправляются сервером.
Стек TCP сервера повторно отправит пакеты, а также немного снизит скорость отправки, потому что считает, что между ним и клиентом существует перегрузка. Он будет ускоряться до тех пор, пока ограничитель скорости снова не сбросит пакеты, и так далее.
Лучшее описание, которое я когда-либо слышал, чтобы понять присущий TCP метод дросселирования, было из недавнего Подкаст Security Now. Процитирую Стива Гибсона:
Итак, по всеобщему соглашению, TCP является очень умным протоколом, поэтому он выполняет то, что называется «медленным запуском». Обычно дается разрешение на отправку некоторого количества пакетов без подтверждения. Итак, идея в том, чтобы просто сдвинуть дело с мертвой точки. И обычно это число - два. И поэтому, когда TCP запускается, он может отправить два пакета один за другим. Не получив подтверждения первого, он отправит вторую. Но потом он ждет. И затем правило дросселирования - мы позволяем количеству неподтвержденных пакетов увеличиваться на единицу для каждого полученного подтверждения.
Так что давайте подумаем об этом. Мы разрешаем увеличивать количество неподтвержденных пакетов на один для каждого полученного подтверждения. Итак, мы сначала отправляем два пакета в качестве согласованного начала. Их признают. Итак, у нас есть первое признание. Мы позволяли себе послать двоих. Теперь, получив это первое подтверждение, мы увеличиваем его с одного до трех. Итак, теперь мы можем отправить еще три пакета без дальнейшего подтверждения. Когда возвращается подтверждение того, что мы отправили ранее, мы увеличиваем его до четырех. Это известно как «окно перегрузки». Это не окно, которое когда-либо отправлялось в линию, то есть это не похоже на окно приема, которое представляет собой 16 бит заголовка TCP, который сообщает нам, сколько данных мы можем отправить вперед. Это - окно. По сути, это счетчик, поддерживаемый стеком TCP с целью предотвращения соединения, идея заключается в том, что в какой-то момент он сломается.
Если мы будем продолжать увеличивать количество неподтвержденных пакетов, которые нам разрешено отправлять, на один каждый раз, когда мы получаем подтверждение, в какой-то момент мы достигнем предела. И прелесть этой системы в том, что, когда мы начинаем пытаться отправлять пакеты быстрее, чем самое слабое звено, буквально звено между маршрутизаторами, в какой-то момент мы обнаруживаем точку, в которой самое слабое звено разрывается. Он отбрасывает пакеты, которые мы пытаемся отправить, потому что мы пытаемся отправить их слишком быстро. Таким образом, подтверждения с другого конца прекращаются, потому что данные больше не проходят.
И что делает TCP, если ему не удалось получить - и это зависит от стратегии. Со временем стратегия, фактическая стратегия предотвращения перегрузки сильно изменилась. Есть такие имена, как Тахо и Рино, и множество других, которые вы увидите, если поищете в Google или Википедии, и которые точно определяют поведение. Но идея состоит в том, что, когда отправитель понимает, что его данные больше не проходят из-за отсутствия подтверждений, он быстро снижает скорость отправки. Обычно он делит его пополам. Таким образом, он резко уменьшает его, а затем возвращается к увеличению.
По сути, это означает, что потеря пакетов является сигнальной функцией для «Мы не можем отправлять данные быстрее», и что отправители TCP на каждом конце соединения по всему Интернету всегда как бы ... они ' они пытаются работать быстрее максимальной скорости, доступной между двумя конечными точками, то есть самым слабым звеном, где бы оно ни находилось, и они всегда доводят ее до предела. Итак, учитывая, что где-то есть точка, более слабая, чем их способность отправлять пакеты, они собираются ее найти, потому что они будут перекачивать пакеты. Пока есть данные для отправки и у них есть соединение с высокой пропускной способностью, отправитель будет увеличивать скорость отправки, то есть количество ожидающих пакетов, пакетов, которым разрешено быть на лету в качестве подтверждений. вернуться, агрессивно продолжает двигать это число вверх, пока не зайдет слишком далеко. Затем он сильно отступает, а затем снова движется вперед.
Вот что на самом деле происходит между TCP-соединениями, которые, наверное, я не знаю, какой процент, но самый большой процент трафика в Интернете приходится на TCP-соединения. Все наши операционные системы в ядре, в так называемом стеке TCP, имеют эти счетчики. И когда мы отправляем файл, когда мы загружаем большой файл или получаем веб-страницу, сервер на другом конце делает то же самое. Он проталкивает для каждого отдельного соединения столько пакетов, которые еще не были подтверждены, насколько это возможно, увеличивая скорость передачи пакетов, пока не достигнет точки, в которой он начинает давать сбой или заикаться. Затем он отступает, чтобы позволить чему-то восстановиться, а затем снова начинает работать.
Так что в итоге получается что-то вроде саморегулирующейся системы, которая с учетом ограничений, я имею в виду, действительно кажется отчасти фанковой и грубой ".
Итак, чтобы ограничить скорость загрузки, у вас есть два варианта:
1) Поручите серверу отправлять вам данные медленнее - и я не думаю, что есть какая-либо функция протокола, которая запрашивала бы это в TCP или HTTP.
2) Квитируйте пакеты медленнее, ограничивая скорость загрузки, а также снижайте скорость загрузки.
3) Ваш маршрутизатор / брандмауэр помещает входящие данные в корзину QoS и очищает ее только с запрошенной вами скоростью. Входящие данные будут адаптироваться к этой скорости, поскольку компьютеры внутри будут видеть подтверждение приема только на этой скорости. Кроме того, случайный (намеренно) отброшенный пакет очень хорошо работает для замедления соединения.
Пытаясь найти устройство, которое справляется с этим, ищите QoS (качество обслуживания) в конфигурации / документации. Коробки Linux (или BSD) также удобны для этого.
Вы используете брандмауэр или устройство, которое поддерживает ограничение QoS (качества обслуживания).
Вы можете создать систему Linux, которая будет действовать как офисный шлюз, и использовать для этого формирование трафика. Просто нужно установить несколько сетевых адаптеров, и тогда каждая машина указывает на шлюз.
В качестве бонуса вы можете настроить на нем прокси-сервер, чтобы облегчить трафик. Что-то вроде Squid. Могут существовать готовые дистрибутивы устройств маршрутизации, которые тоже могут это делать.
Протокол HTTP не предоставляет средств для ограничения используемой полосы пропускания, и даже если бы это было так, это был бы параметр на стороне клиента, над которым сетевые администраторы не могли иметь никакого контроля.
Ограничение полосы пропускания (также известное как «Качество обслуживания») обычно осуществляется на маршрутизаторах / межсетевых экранах, которые обрабатывают весь входящий и исходящий трафик в / из сети; те, которые поддерживают это, обычно позволяют настраивать политики, такие как «разрешить любому клиентскому компьютеру использовать не более 10% всей доступной полосы пропускания» или «назначить SMTP приоритет над FTP, чтобы электронные письма могли передаваться, даже когда кто-то выполняет тяжелую загрузку. ".
Как именно это выполняется, зависит от используемого маршрутизатора / брандмауэра, но самый простой способ - просто выбросить пакеты, превышающие настроенные ограничения; TCP гарантирует, что они будут повторно переданы, и в конечном итоге сможет пройти через узкое место.