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

HTTP speed test

HTTP speed test, RouterOS

neutronlaser Guest	#1 0 02.03.2019 00:52:00 Создайте инструмент для тестирования скорости HTTP

rextended Guest	#2 0 28.02.2023 13:15:00 Это как если бы ты ехал на автомобиле на полной скорости в городе, просто чтобы проверить, может ли он все еще достичь максимальной скорости...

cdhtlr Guest	#3 0 27.02.2023 19:31:00 Спустя 3 года MikroTik наконец начал поддерживать Контейнеры, что теперь позволяет нам проводить тесты скорости (http://forum.mikrotik.com/t/ookla-speedtest-container/163953/1) аналогично speedtest.net.

rextended Guest	#4 0 27.02.2023 20:42:00 Ты любишь копировать и вставлять? Конечно, если бы все рассуждали так же плохо, как ты, всё было бы заблокировано из-за бесконечных тестов, которые потребляют трафик без причины.

pe1chl Guest	#5 0 27.02.2023 21:01:00 Я не знаю, правда ли это до сих пор, но, похоже, что когда-то большинство пропускной способности Starlink использовали люди, которые постоянно проводили тесты скорости...

rextended

Guest

27.02.2023 21:19:00

Проблема довольно распространенная, как и для меня: вечером, когда они возвращаются, почти все клиенты начинают проводить тесты скорости, “чтобы проверить, все ли в порядке”, даже если нет ни малейшей проблемы… даже если им просто нужно отправить сообщение в WhatsApp… И мне приходится платить за ерунду, вместо того чтобы платить за фактическое использование услуги… Представьте, если бы были идиоты, которые регулярно запускали тесты скорости… и, конечно, это было бы так нелепо, что они решили бы запускать их все в одно “пиковое время”… Все было бы перегружено, 100 Мбит на клиента, для 4000 клиентов…

cdhtlr

Guest

27.02.2023 21:44:00

Итак, как автоматически изменить маршруты доступа в интернет, когда пропускная способность одного из маршрутов падает? Я пробовал множество способов: рекурсивное переключение маршрутов? Я это пробовал, но это не сработает, если пинг все еще работает, даже когда пропускная способность падает. Балансировка нагрузки? А что, если качество соединения отличается между маршрутами доступа в интернет? Пользователи моей сети жалуются на плохое качество. У одного пинг 30 мс, а у другого 1000 мс. Btest? Никто не предоставляет бесплатные серверы btest в моей стране. Извините, но я не думаю, что на мой вопрос ответили.

mkx

Guest

28.02.2023 06:57:00

Итак, как автоматически изменять маршруты доступа в интернет, когда пропускная способность одного из маршрутов падает? [/quote] Проблема не в маршрутизации, а в ёмкости канала. Некоторые провайдеры даже недостаточно разумны, чтобы приоритизировать трафик speedtest, заставляя клиентов верить, что их услуги отличные… что означает, что если слишком много клиентов запускают speedtests, обычный интернет-сервис для всех остальных будет страдать. И нет, ёмкость канала не бесплатна для провайдеров, и если достаточно клиентов будут недостаточно умны, чтобы постоянно запускать speedtests (и даже жаловаться, если не получают максимального сервиса всё время), провайдеру придётся вложиться (немалые деньги) в подключение к upstream… и эти расходы либо лягут на клиентов, либо провайдер разорится.

cdhtlr

Guest

28.02.2023 08:24:00

Пример ситуации: я подписан на услуги двух интернет-провайдеров, назовем их A и B. A является основным маршрутом доступа в интернет. В обычных условиях пропускная способность A составляет 10 Мбит/c, а у B — 5 Мбит/c. Когда пропускная способность, на которую я подписан у A, падает до 1 Мбит/c, как мне сделать так, чтобы доступ к интернету переключался на B автоматически, кроме как используя результаты speedtest в качестве параметра? Я понимаю, что постоянное проведение speedtest может создать проблемы в сети, и у меня уже есть решение для этого. Но я был бы очень благодарен, если у вас есть еще одно решение, лучшее, чем speedtest, для решения подобной проблемы.

pe1chl

Guest

#10

28.02.2023 09:33:00

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

mkx

Guest

#11

28.02.2023 09:55:00

Пока связка с провайдером A используется, запуск теста скорости a) мешает нормальному трафику и b) дает неопределенные результаты, поскольку нормальный трафик мешает тесту скорости. Так что снова, тест скорости действительно не является инструментом для рутинной оценки состояния сети. Лучше было бы запустить команду мониторинга на WAN интерфейсе и совместить её с результатами ping... если время обратного пинга превышает допустимый порог (например, в два раза больше нормы) и мониторинг интерфейса показывает скорости, значительно ниже подписанных/приемлемых, тогда пришло время переключаться (обратите внимание, что RTT может увеличиваться из-за перегрузки в любом направлении). Задержка ping — это "способ бедного человека" для определения, ограничен ли фактический throughput каким-то узким местом (когда данные буферизуются с любой стороны, RTT будет увеличиваться... на сколько, зависит от размеров буферов, но поскольку многие производители используют буферизацию для максимального увеличения throughput, это также делает максимальную задержку значительно выше) или throughput низкий из-за низкого спроса. Наблюдаемый throughput (в те моменты с увеличенным RTT) покажет, насколько узким является узкое место. И всё это без воздействия на нормальный трафик, выполняя глупые тесты.

cdhtlr

Guest

#12

28.02.2023 12:15:00

В этом и проблема: в моей стране очень редко встречаются интернет-провайдеры, которые это предоставляют, и даже не честны, если происходят падения скорости. В таких условиях speedtest становится более быстрым и честным решением.

cdhtlr

Guest

#13

28.02.2023 12:31:00

Я уже делал это раньше. К сожалению, у этого метода есть много недостатков. Мониторинг WAN-интерфейса не может показать реальные результаты, падает ли пропускная способность или нет. То же самое касается и пинга: независимо от того, хорошие ли условия по пропускной способности или они ухудшаются, результаты пинга всегда хорошие. Как я могу знать, падает ли моя пропускная способность, если использование WAN низкое, а пинг хороший? В этом случае мониторинг WAN-интерфейса в сочетании с результатами пинга не смогли определить статус интернет-пропускной способности. Особенно когда использование WAN-интерфейса низкое, условия по пропускной способности заявляются как ухудшающиеся, даже несмотря на то, что реальные результаты speedtest показывают хорошие результаты. Проще говоря, "мониторинг WAN-интерфейса показывает только использование WAN-интерфейса, а не фактическую максимальную пропускную способность, которую я могу использовать".

pe1chl

Guest

#14

28.02.2023 13:43:00

Ну, это аналогичная проблема, как "Я хочу использовать очередь на своем интернет-канале для QoS, но не знаю точно, какая скорость у моего канала, потому что это VDSL, и скорость зависит от качества линии и так далее". Вам нужно найти способ проверить текущую скорость uplink'а из модема (например, используя telnet, SNMP запрос или что-то подобное), а затем взять 95% от этой скорости и установить в качестве максимальной скорости очереди. Предпочтительно, чтобы максимальная скорость дочерних очередей настраивалась как процент от фактической скорости родительской очереди, а не в виде фиксированной скорости. Но это все еще мечта… слишком много препятствий, которые нужно преодолеть. К счастью, мой текущий VDSL модем может выполнять QoS на основе 802.11p, так что теперь не о чем беспокоиться, кроме того, что это, конечно, выявляет ошибки в RouterOS с обработкой DSCP.

Amm0 Guest	#15 0 28.02.2023 14:31:00 LOL, так и есть... но ты видишь, сколько времени ты ждешь на светофорах. В целом это похоже на проблему управления очередью — можно добавить несколько «экспресс-линий через город», которые помогут, но не всем это подойдет. Что можно сделать, так это наблюдать за задержкой как показателем пропускной способности, хотя это и не идеально. Для HTTP и TCP в общем скорость довольно хорошо коррелирует с задержкой. Новые тесты «http» и «icmp» в /tool/netwatch могут помочь. Но это все равно не скажет тебе максимальную скорость. Есть также более старый /tool/ping-speed — его оценка скорости совершенно неверна, но разница между несколькими запусками имеет значение, так как он использует задержку как эталон. В любом случае, если ты проведешь несколько «реальных тестов скорости»... когда задержка высокая и низкая (по измерениям /tool/netwatch «icmp» или «фейковым скоростям» /tool/ping-speed) — ты сможешь сам увидеть, как они коррелируют. Высокое время пинга == более низкие результаты тестов скорости. Это тоже правда. Мне все еще нравится иметь возможность легко отключать маршрут, если задержка высокая, так как icmp можно безопасно измерить (в отличие от «теста скорости», что просто плохая идея, если уже есть перегрузка). Простой «check-gateway=ping» довольно ограничен и является частью текущей проблемы. Если у тебя несколько маршрутов и один из них >500мс, это просто не будет очень использовано в большинстве случаев. См.: http://forum.mikrotik.com/t/feature-request-link-check-gateway-in-routes-to-a-netwatch-item-s/163771/1 — это не панацея, но это будет прогрессом.

Читают тему

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