+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Лимит скорости скачивания на соединение, после какого-то времени.

Лимит скорости скачивания на соединение, после какого-то времени., RouterOS

WirelessRudy

Guest

07.08.2012 11:35:00

Клиент должен иметь возможность просматривать страницы на высокой скорости (например, 6 Мб), но когда он начинает загрузку, даже используя несколько соединений (download agent, p2p), я хочу, чтобы поток загрузки снижался до 2 Мб через 30 секунд, но 4 Мб избыток "канала" должны оставаться доступными для просмотра. Это нужно для того, чтобы скачивающие не перегружали мою сеть бесконечными загрузками, но при этом обеспечивать высокоскоростной просмотр. У меня беспроводная сеть, где ограничение клиентов происходит с помощью простых очередей в центральном устройстве, подключенном к интернету. С простыми очередями не удается найти простой способ это сделать. Я не хочу создавать сложные скрипты. Может, стоит сделать дерево очередей для такой группы клиентов? Или использовать специальный pcq в целевом устройстве для простой очереди? Какие-нибудь примеры или советы?

n21roadie

Guest

07.08.2012 14:06:00

Клиент должен иметь возможность быстро просматривать страницы (например, 6 Мбит/с), но когда он начинает скачивать, даже используя несколько соединений (скачивающий агент, p2p), я хочу, чтобы поток скачивания снижался до 2 Мбит/с через 30 секунд, но 4 Мбит/с избыточной пропускной способности "канала" должны оставаться доступными для просмотра. Поскольку мы обнаруживаем, что p2p, torrent и т.д. становятся очень сложными для обнаружения, как вы будете идентифицировать каждый IP-пакет и его истинное назначение? Что касается неправильного анализа пакетов, также рассмотрите дополнительную нагрузку на процессор, которую просто выполнение этой задачи создаст. Я применил другой подход: независимо от того, что скачивается, я хочу позволить клиенту быстро просматривать страницы и скачивать большинство обновлений в течение, скажем, 15 минут при скорости 7 Мбит/с, а через 30 минут скорость снижается до 1 Мбит/с. В настоящее время я использую простые очереди на AP с максимальным ограничением 3 Мбит/с/384 кбит/с и использую настройку "burst" для предоставления 7 Мбит/с в течение 900 секунд (15 минут), порог 64 кбит/с, а затем устанавливаю простую очередь на клиентском CPE для дополнения очереди AP с максимальным ограничением 1 Мбит/с/128 кбит/с и использую настройку "burst" для предоставления 3 Мбит/с в течение 1800 секунд (30 минут). Это даст мне целевые скорости для проблемных клиентов.

WirelessRudy

Guest

07.08.2012 14:47:00

Ну ладно, возможно, мои формулировки были не совсем ясны, но в общем и целом я хочу сделать ровно то же самое, что и ты. Любое соединение src IP/port-dst.IP/port может начинаться на максимальной скорости. Это нужно для того, чтобы каждое задание, которое выполняет клиент, было быстрым. Чтобы остановить длительные скачивания, занимающие мою полосу пропускания на продолжительное время, каждое соединение должно снижать скорость до гораздо более низкого значения после достижения выбранного порога. (Это произойдет только со скачиваниями, так как почти все остальные соединения в любом случае быстро отключаются…) Если во время медленного скачивания клиент открывает новое соединение (например, просмотр веб-страницы), то это новое соединение(я) должно(ы) начинать(ть) с максимальной скорости, разрешенной главным лимитом. Итак, 8 Мбит/с максимум доступно для каждого или всех соединений, которые каждое соединение снижает до 2 Мбит/с по истечении 10 минут, например. Если при работающем соединении на скорости 2 Мбит/с запускается новое соединение, то это новое соединение все еще имеет 8-2=6 Мбит/с для использования. (Чтобы предотвратить использование менеджером загрузок несколько соединений и все еще потреблять всю полосу пропускания, мне также нужно что-то, что предотвращает открытие таких программ более одного соединения. Поэтому, после 10 минут соединений src.IP/port-dst.IP не должно быть больше одного (или двух) соединений к одному dst-адресу). Моя проблема в том, что в настоящее время я использую только простые очереди, и я не хочу добавлять никаких дополнительных правил-скриптов-очередей на CPE клиентов, так как у меня все еще много старых плат, которые уже испытывают трудности с запуском NV2 на последних версиях ROS. Поэтому я ищу решение, которое можно реализовать на моем основном контроллере.

greencomputing

Guest

08.08.2012 10:28:00

Привет! Вместо использования временного порога, что если использовать пороговое значение объема уже скачанных байтов? Идея в чем: сейчас клиент скачал 12 мегабайт данных. Как только клиент достигнет порога в 15 мегабайт, он потеряет текущий приоритет 1 и будет классифицирован как приоритет 2 до тех пор, пока не достигнет нового порога в 30 мегабайт, где снова будет деклассифицирован как клиент с наименьшим приоритетом 3 (очередь), который будет оставаться там до завершения и закрытия соединения. Конечно, новые соединения будут отмечены независимо, поэтому новое соединение от того же клиента начнется с супербыстрого и блестящего приоритета 1. Можно определить 1, 2 N очередей, разделяя текущий статус каждого клиента централизованным способом, назначая каждому клиенту динамический приоритет, основанный на "истории потребленных им байтов в текущем соединении" (используется /ip firewall mangle connection-bytes намеренно). Вот обзор возможной процедуры конфигурации: (пример связан с загрузкой, почти аналогичный процесс происходит в направлении загрузки): создать очереди: Q1, Q2, Q3 … QN: /queue tree
добавить disabled=no limit-at=0 max-limit=80M name=GLOBAL_DOWN parent=global-in priority=1
добавить disabled=no limit-at=1k max-limit=80M name=QoS1_DOWN packet-mark=QoS1 parent=GLOBAL_DOWN priority=1 queue=pcq-download

добавить disabled=no limit-at=1k max-limit=80M name=QoS2_DOWN packet-mark=QoS2 parent=GLOBAL_DOWN priority=2 queue=pcq-download

... Классифицировать подписчиков динамически в зависимости от количества обмена байтами в соединении (реализовано через connection-bytes) /ip firewall mangle
добавить action=mark-packet chain=prerouting connection-bytes=1-15000000 disabled=no in-interface=ether2 new-packet-mark=Qos1 passthrough=no protocol=tcp
добавить action=mark-packet chain=prerouting connection-bytes=15000001-30000000 disabled=no in-interface=ether2 new-packet-mark=Qos2 passthrough=no protocol=tcp
...
добавить action=mark-packet chain=prerouting connection-bytes=1-15000000 disabled=no in-interface=ether2 new-packet-mark=Qos1 passthrough=no protocol=udp
добавить action=mark-packet chain=prerouting connection-bytes=15000001-30000000 disabled=no in-interface=ether2 new-packet-mark=Qos2 passthrough=no protocol=udp
...
/queue type
добавить kind=pcq name=pcq-download pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=128 \
pcq-limit=100 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=128 pcq-total-limit=20000 Предлагаемый тип очереди – pcq, классифицированный по dst address. Надеюсь, это поможет. Хорошего дня!

n21roadie

Guest

08.08.2012 15:00:00

Вместо использования порогов времени, а что если использовать порог объема скачанных байтов? Я могу говорить только за свою сеть и предполагать использование клиентами, но оно очень похоже на использование в других WISPs: примерно 80% моих клиентов используют низкую или среднюю пропускную способность в месяц, 15% — среднюю или высокую, 5% — высокую. Я не хочу наказывать или создавать возможные узкие места в своей сети из-за централизованной приоритизации трафика или дополнительных финансовых затрат на ее правильную реализацию, которые повлияют на 100% клиентов ради использования 20%. Я хочу просто наказывать 5% и предупреждать 15% пользователей с высоким потреблением. Моя политика проста: я связываюсь с плательщиком и информирую его о ситуации, и это очень эффективно.

Вопрос в том, как __отделить обычные обновления от скачивания скрытого торрента (и помните, не все торренты плохие?)__ + менеджеры загрузок также используются для обновления программ. Я хочу ввести более высокую скорость для клиентов, но пользователи с высоким потреблением просто будут "съедать" больше полосы пропускания без четко определенной политики добросовестного использования. И, возможно, местная приоритизация трафика на AP и CPE клиентов. Хотя я не хочу блокировать торренты, я бы хотел приостанавливать их в часы пик (с 17:00 до 22:00 ежедневно) и возобновлять после этих часов. Установив более высокие скорости, они будут скачивать быстрее. И когда они достигнут 75% триггерной загрузки, их соединение замедляется, еще медленнее — на 90%, 95% и 100% от ежемесячного объема. В этом случае им придется искать другого провайдера, и вскоре они поймут, что скачивание, которое некоторые еще не осознали, что потоковое видео тоже скачивание, будет стоить больше денег.

capital Guest	#6 0 15.11.2012 10:40:00 Привет, Greencomputing! Хотел бы внедрить это в свою сеть. Есть ли шанс получить твою помощь через консультацию? Подскажи, пожалуйста, контакты. Capital

PackElend Guest	#7 0 11.07.2021 20:08:00 Ты когда-нибудь решал это без burst? Хочу разрешить максимальную пропускную способность на 1 минуту, а потом она должна снизиться до 512 кБ. Это для беспроводного тестирования, чтобы пользователь не использовал Wi-Fi в обычном режиме. Это единственный способ убедиться, что канал останется максимально открытым, разве нет?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры