Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Тест скорости с блокировкой и перенаправлением через файрвол.

    Тест скорости с блокировкой и перенаправлением через файрвол.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Тест скорости с блокировкой и перенаправлением через файрвол., RouterOS
     
    homerwsmith
    Guest
    #1
    0
    30.11.2016 07:21:00
    Привет, ребята! Это довольно деликатная тема, поэтому прошу помочь, если можете, независимо от вашего мнения по этому вопросу. Я хочу перенаправить speedtest.net на локальный тест скорости в нашем NOC. Мы маленький WISP с 100 мегабитным оптоволоконным каналом от Time Warner light, который используем для обслуживания отдалённых районов. Мы не ограничиваем пользователям доступную пропускную способность — они получают то, что есть, что для одних много, а для других мало. Впрочем, скоро это изменится.

    Иногда интернет притормаживает, иногда наши каналы загружены, иногда и то, и другое, например, во время недавних выборов. Наши клиенты не очень понимают эти вещи, они используют speedtest.net для проверки скорости и не осознают, что speedtest.net никак не связан с их локальной линией, особенно если их локальная линия быстрее интернета в целом. Я добавил мини-скоростной тест от okla для наших внутренних линий, чтобы перенаправлять клиентов туда — чтобы они могли проверить, в чём проблема: у нас или в интернете в целом, с чем я ничего поделать не могу.

    Я хочу узнать, как полностью заблокировать доступ к speedtest или перенаправить на другой адрес, но похоже, что у них очень сложный набор IP-адресов, а сейчас, возможно, ещё и собственные протоколы. Меня ещё беспокоит, что когда пользователь выбирает для теста локальный сервер, он может выбрать сервер конкурента, который специально его туда поставил. Результаты с его сервера обычно хуже в течение дня, чем, например, у крупного провайдера в Сиракузах. Раньше я думал, что при скачивании с ближайшего сервера тестируется их скорость загрузки, а при закачивании на сервер — их скорость отдачи. Когда серверы конкурента загружены днём, это выглядит для нас очень плохо.

    Однако, посмотрев tcpdump этого процесса, я понял, что тесты фактически проходят между 10 и более серверами, которые расположены далеко друг от друга, и при этом напрямую с сетью конкурента это не связано во время теста. Поэтому я толком не понимаю, как speedtest.net выбирает свои сервера для каждого теста и почему скорость так сильно варьируется в зависимости от сервера на главной странице speedtest, если тесты вообще не идут в ту сеть.

    Что я упускаю? В общем, если кто-то готов поделиться опытом по блокировке или перенаправлению запросов к speedtest.net и другим подобным сайтам для теста скорости, буду очень признателен. Я хорошо разбираюсь в настройках файрволлов, но не знаю точной структуры speedtest.net.

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

    Спасибо!  
    Хомер Смит, CEO Lightlink Internet
     
     
     
    TomjNorthIdaho
    Guest
    #2
    0
    14.02.2017 18:36:00
    Гомер, чтобы ты был в курсе — я только что проверил скорость на ваших серверах speedtest. Думаю, тебе будет интересно посмотреть, что у меня получилось на ваших серверах. Вот результаты тестов:

    speedtestfv.lightlink.com (Fairview) — 13,35 Мбит/с на скачивание и 7,57 Мбит/с на загрузку  
    speedtestch.lightlink.com (Conn Hill) — не удалось подключиться  
    speedtestax.lightlink.com (South Hill Business Campus) — 2,92 Мбит/с на скачивание и 1,74 Мбит/с на загрузку  
    speedtestrp.lightlink.com (Roy Parks) — 9,91 Мбит/с на скачивание и 4,07 Мбит/с на загрузку  
    speedtest.net (Интернет) — 961,55 Мбит/с на скачивание и 945,87 Мбит/с на загрузку
     
     
     
    homerwsmith
    Guest
    #3
    0
    13.02.2017 20:35:00
    Я знаю, что это старое сообщение, но для меня оно всё ещё важно. Я не могу гарантировать то, что не могу контролировать. Насколько я знаю, пропускная способность всегда измеряется и предоставляется от точки А — дома клиента — до точки Б, например, до граничного роутера провайдера. Нельзя обещать скорости от клиентов до «интернета», потому что интернет — это не конкретное место. Скорости меняются в зависимости от того, куда вы заходите. Вот почему даже Speedtest предлагает множество разных серверов для теста от вашего дома. И все они тестируют по-разному, иногда некоторые результаты просто ужасные, и у нас это почти всегда «ближайший» сервер. Это создаёт настоящий шторм в техподдержке, когда клиенты принимают медленный тест за правду и начинают жаловаться.

    Мы продаём локальные каналы связи, точно так же, как Verizon продаёт DSL — так было всегда и так будет. Мы предлагаем минимальный best effort 5x1,5 беспроводной локальный канал до ближайшего основного роутера, но поскольку наши подключения не ограничены по трафику, часто клиенты получают гораздо больше. В наших печатных материалах указывается, что SD Netflix должен работать без перебоев в обычные вечера с 19:00 до 23:00. Если это не получается — мы стараемся проблему исправить.

    На нашем сайте есть несколько локальных серверов Speedtest, чтобы помочь клиентам понять, где они находятся в сети и определить, где может быть узкое место вдоль цепочки локальных роутеров до нашего ядра. Помимо того, что мы продаём локальные каналы, а не гарантируем доступ в «интернет», меня особенно тревожит, что speedtest.net выбирает ближайшим сервером нашего конкурента, чей трафик загружен полностью, и при этом клиенты получают от него постоянно низкие скорости.

    Раньше я думал, что тестирование происходит напрямую с сервером Speedtest на удалённой точке, и там я проверял только скорость между удалённым сервером и нами. Это была единственная логика, которая объясняла большие расхождения в результатах с разных локаций. Сейчас я всё ещё не понимаю, как работает Speedtest, но, судя по всему, процесс управляется удалённым сервером, который как-то одновременно собирает множество тестов с разных точек и выдаёт усреднённый «по интернету» результат. Если это так, то я всё равно не понимаю, почему результаты с разных удалённых серверов так сильно отличаются по скоростям загрузки и отдачи.

    В любом случае, мне не нравится speedtest.net — мне кажется, это какая-то афера, которая заставляет клиентов недолюбливать своего провайдера, а поскольку они не объясняют, КАК именно измеряют скорость, отсутствие прозрачности для меня абсолютно неприемлемо.

    Хомер У. Смит, генеральный директор Lightlink Internet
     
     
     
    TomjNorthIdaho
    Guest
    #4
    0
    14.02.2017 19:03:00
    Хомер, вот что тебе стоит подумать… Кэширующий прокси-сервер Squid. В середине-конце 90-х у меня был интернет с подключением 56k через Frame-Relay. Я собрал прокси-сервер Squid с кэшированием. Он сохранял веб-страницы и выдавал их локально, если этот контент недавно кто-то уже открывал. То есть, первый, кто запустит видеоклип, получал его на скорости 56k, а второй компьютер мог открыть ту же страницу уже на 100 мегабитах. Работало отлично и даже снижало нагрузку на мой WAN, потому что кеш постепенно наполнялся веб-страницами на локальном сервере.

    Примерно в 2004 году, когда у меня появилась связь на 45 мегабит, я снова собрал прокси-сервер Squid (на более мощном и быстром сервере) для клиентов моего провайдера. Многие пользователи моей оптоволоконной сети могли смотреть веб-страницы практически на скорости 1 гига (если данные уже были закэшированы, благодаря тому, что кто-то недавно заходил на те же сайты).

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

    Есть два основных способа настроить кэширующий прокси-сервер:  
    1. Опциональная настройка в браузере клиента, чтобы использовать прокси.  
    2. Принудительная настройка, когда все используют прокси вне зависимости от настроек браузера (если только они не направлены на другой прокси-сервер).

    С уважением, North Idaho Tom Jones
     
     
     
    pukkita
    Guest
    #5
    0
    14.02.2017 19:52:00
    Интересное обсуждение, не смог пройти мимо и решил вставить свои пять копеек. Полностью согласен с TomjNorthIdaho — обманывать своих клиентов никогда не выходило им на пользу. Установите свой локальный сервер для проверки скорости и обучайте клиентов, как уже говорилось — вы не можете контролировать скорость до всех серверов по всему миру. Некоторые (W)ISP ограничивают пропускную способность до своего speedtest-сервера «со стороны интернета» или понижают ему приоритет, поэтому иметь свой собственный всегда хорошая идея.

    Но наличие speedtest-сервера не решит проблему серьёзного недостатка трафика. Люди могут быть не слишком разбирающимися в технике, но вовсе не дураками; если им не нравится ваш сервис, они уйдут, даже если speedtest покажет отличную скорость. Применяйте политики QoS, чтобы трафик шел максимально плавно. QoS — это не замена реальной полосы пропускания, но позволяет обслужить больше клиентов на имеющейся скорости. По моему опыту, клиенты редко делают speedtest, если сайт или приложения работают шустро (а QoS в этом сильно помогает).

    Всегда найдутся те, кто не успокоится, пока их линия не будет загружена под завязку 24/7. Если у вас нет ресурсов, чтобы это обеспечить, лучше отпустите их или берите за это дополнительную плату.

    На мой взгляд, сейчас более 60% трафика, по моему опыту здесь, — это HTTPS (некэшируемый), так что кэширование имеет ограниченную полезность. Тем не менее, кэшировать обновления ОС и прочее может быть полезно (с небольшими настройками, не уверен, что всё давно не перешло на HTTPS). Для этого нужен мощный сервер с большим объёмом оперативки и быстрыми HDD. Это может быть не самое дорогое в развертывании кэширования, но обслуживание…

    Сегодня пропускная способность — одна из самых дешёвых статей в расходах. Так что, на мой взгляд, если у вас нет проблем с транзитом, инвестиции в неё — самое разумное вложение.
     
     
     
    TomjNorthIdaho
    Guest
    #6
    0
    14.02.2017 20:25:00
    Интересная дискуссия, не смог пройти мимо и решил вставить свои пять копеек... HTTPS (некешируемый), так что кеширование имеет ограниченную полезность; тем не менее, кешировать обновления ОС и прочее может быть полезно (с некоторыми доработками, не уверен, что всё уже перешло на HTTPS).  
    ... Для этого нужен мощный сервер с кучей оперативки и быстрыми HDD, что может быть не самой большой статьёй расходов при развертывании кеширования, но... обслуживание.  
    ... Что касается HTTPS и прокси — не уверен, но, кажется, Squid можно настроить так, чтобы он работал и с HTTP, и с HTTPS трафиком. И да — первоначальная настройка Squid требует некоторой возни, чтобы достичь оптимальной работы (например, размеры загрузок (мин. и макс.) для кеширования, процент загрузки для буферизации кеша, время истечения и т.д.).  
    Однако стандартных настроек обычно хватает, чтобы запустить всё в работу. Когда я запускал свой, сделал эту функцию доступной как опцию, которую мог включить клиент, если захочет. Если возникали проблемы — клиент всегда мог её отключить.  

    По поводу QOS — QOS не решает полностью проблемы с перегруженной или медленной сетью, но помогает. Возможно, сочетание QOS и кеш-прокси вместе смогут увеличить пропускную способность для клиента. Конфигурировать QOS достаточно просто. Squid Proxy потребует более тщательной настройки, выходящей за рамки базовых параметров.  

    Если бы я снова взялся за это, выбрал бы быстрый Xeon с многопоточностью, 64–256 ГБ оперативки и несколько 4-терабайтных SAS-дисков, на LTS-версии Ubuntu. Хорошо то, что после правильной настройки QOS и/или Squid практически не надо вмешиваться — просто запускаешь и работаешь.  

    North Idaho, Том Джонс
     
     
     
    pukkita
    Guest
    #7
    0
    15.02.2017 09:30:00
    Извините, что не выразился ясно, я имею в виду сценарии «прозрачного проксирования». HTTPS не кэшируется: в браузере клиента появится предупреждение, что кто-то пытается выдать себя за HTTPS-сайт. Чтобы использовать это, клиентам нужно об этом знать и установить правильный сертификат, что в зависимости от ситуации может быть не лучшим решением.
     
     
     
    enlace101
    Guest
    #8
    0
    28.06.2020 19:44:00
    Какое ваше мнение о сервере bequant? Сейчас я его тестирую. Качество значительно улучшилось. Боюсь, что это обманчивое впечатление. Посмотрите сами и скажите, действительно ли он работает. Спасибо.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры