В терминах TCP / IP, как работает ограничение скорости загрузки в офисе?

Предположим, что люди хотят ограничить загрузку 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, если он не получил - и это зависит от стратегии. Со временем стратегия, фактическая стратегия предотвращения перегрузок сильно изменилась. Есть такие имена, как Тахо и Рено, и множество других, которые вы увидите, если будете заниматься поиском в Google и Wikipediaing, в которых конкретно указано поведение. Но идея заключается в том, что, когда отправитель понимает, что его данные больше не проходят, поскольку он пропускает подтверждения, он быстро сокращает скорость отправки. Как правило, он делит его пополам. Таким образом, он резко сокращает его, а затем возвращается к его увеличению.

По сути, это означает, что потеря пакетов является сигнальной функцией для «Мы не можем отправлять данные быстрее», и что отправители TCP на каждом конце соединения по всему Интернету всегда своего рода - они мы пытаемся двигаться быстрее, чем максимальная скорость, доступная между двумя конечными точками, то есть это самое слабое звено, где бы оно ни было, и они всегда доводят его до предела. Итак, учитывая, что где-то есть точка, которая слабее, чем их способность отправлять пакеты, они найдут ее, потому что они будут откачивать пакеты. Пока есть данные для отправки и соединение с высокой пропускной способностью, отправитель будет увеличивать скорость отправки, то есть количество ожидающих пакетов, пакетов, которым разрешено быть на лету в качестве подтверждений Вернись, агрессивно продолжает двигать это число вверх, пока оно не вытолкнет его слишком далеко. Затем он много отступает, а затем снова движется вперед.

Так вот, что на самом деле происходит между TCP-соединениями, которые, как, наверное, я не знаю, какой процент, но самый большой процент трафика в Интернете по сравнению с TCP-соединениями. Все наши операционные системы в ядре, в так называемом стеке TCP, имеют эти счетчики. И когда мы отправляем файл, когда мы загружаем большой файл или получаем веб-страницу, сервер на другом конце делает то же самое. На каждом отдельном соединении он выталкивает как можно больше пакетов, которые еще не были подтверждены, увеличивая скорость передачи до тех пор, пока не достигнет точки, где он начинает отказывать или заикаться. Затем он отступает, чтобы позволить чему-то восстановиться, а затем снова начинает работать.

И так, в конечном итоге это становится своего рода саморегулирующейся системой, которая, учитывая ограничения, я имею в виду, на самом деле кажется довольно прикольной и грубой ».

Итак, чтобы ограничить скорость загрузки, у вас есть два варианта:

1) Проинструктируйте сервер отправлять вам данные медленнее - и я не думаю, что есть какая-либо функция протокола, чтобы запросить это в TCP или HTTP.

2) Медленнее распознавайте пакеты, ограничивая скорость загрузки, а также снижайте скорость загрузки.

3) Ваше устройство маршрутизатора / брандмауэра помещает входящие данные в корзину QoS и очищает эту корзину только с запрошенной вами скоростью. Входящие данные будут адаптироваться к этой скорости, так как компьютеры внутри будут видеть только подтверждение получения с этой скоростью. Кроме того, случайный (целенаправленно) отброшенный пакет работает очень хорошо для замедления соединения.

При попытке найти устройство, которое обрабатывает это, ищите QoS (Качество обслуживания) в конфигурации / документации. Linux (или BSD) коробки также удобны для этого.

Вы используете брандмауэр или устройство, которое поддерживает ограничение QoS (качество обслуживания).

Вы можете создать систему Linux, которая будет действовать как офисный шлюз, и использовать ее для формирования трафика. Просто нужно установить несколько сетевых карт, и каждая машина указывает на это как шлюз.

В качестве бонуса вы можете настроить прокси-сервер на нем, чтобы облегчить трафик тоже. Что-то вроде кальмара. Там могут быть дистрибутивы устройства маршрутизации под ключ, которые могут сделать это тоже.

Протокол HTTP не предоставляет средств для ограничения используемой полосы пропускания, и даже если бы это было так, это было бы установкой на стороне клиента, над которой сетевые администраторы не могли иметь никакого контроля.

Ограничение пропускной способности (также известное как «Качество обслуживания») обычно управляется на маршрутизаторах / брандмауэрах, которые обрабатывают весь входящий и исходящий трафик в / из сети; те, которые поддерживают это, обычно позволяют настраивать политики, такие как «разрешить любому клиентскому компьютеру использовать не более 10% всей доступной пропускной способности» или «отдавать приоритет SMTP над FTP, чтобы сообщения электронной почты могли передаваться даже при интенсивной загрузке». ».

Как именно это будет сделано, зависит от используемого маршрутизатора / брандмауэра, но самый простой способ - просто выбросить пакеты, которые превышают настроенные пределы; TCP обеспечит их повторную передачу и в конечном итоге сможет пройти через узкое место.