На самом деле (( PRIORITY )) действительно работает???

Я создал тему с таким же вопросом, и так и не получил на него ответа. Похоже, что приоритет для входящих пакетов и портов в Mikrotik отсутствует, если вы хотите использовать всю входящую пропускную способность. Люди должны предупреждать других, что если вам нужен QoS, стоит избегать Mikrotik. На данный момент мы знаем, что Mikrotik может работать в условиях почти QoS только если вы установите жесткий лимит на максимальную скорость передачи на "дочерних" устройствах, который будет ниже максимальной скорости передачи "родительского" устройства, но это чистая трата пропускной способности. Если вы хотите загружать с максимальной скоростью и не хотите терять трафик, то Mikrotik вам не поможет. Возможно, есть какие-то скрипты или способы, которые известны лишь немногим, но на данный момент никакого руководства, историй или способов не существует. Каждый, кто говорит, что "это может регулировать входящую пропускную способность", - лжец, потому что если это правда и если вы действительно так считаете, то это не имеет для нас никакой ценности, и с точки зрения чистой математики это ложь. Пока кто-то не представит операционный QoS с актуальными приоритетами, которые смогут использовать максимальную пропускную способность и обеспечивать ультрабыстрый отклик и передачу для портов с высоким приоритетом, я могу сказать, что это обман. Mikrotik плохо подходит для QoS. Он не сравнится с мастер-шейперами или другими бесплатными шейперами. Возможно, в ранние дни Интернета QoS на дальнем конце не был приоритетом для клиентов, но сейчас исходящий QoS не столь важен, как входящий, и, похоже, что Mikrotik не может конкурировать с современными трендами. Это та же история, что и с мультиподключением через два PPPoE ADSL, и в итоге мы пришли к тому, что это на самом деле невозможно на Mikrotik, хотя два года нас дезинформировали. Ладно, похоже, теперь Mikrotik это исправил, и теперь это возможно.

Хорошо, теперь мы начинаем что-то понимать: на самом деле инбунд QoS не существует на MikroTik, и разговоры об этом — просто маркетинговый трюк. Слушай, именно сейчас я придумываю 10 способов, давайте обсудим несколько. Например, у нас есть входящая линия на 10 Мбит, мы хотим приоритизировать входящий трафик, и мы хотим установить ультравысокий приоритет для портов 80 и 443, а для остальных портов установить более низкие приоритеты. Например, для некоторых пассивных портов FTP или 119 для NNTP мы хотим дать им ультравнизкий приоритет. Мы хотим, чтобы у нас был ультрабыстрый интернет, как будто мы не используем никакой другой трафик, кроме порта 80, но на самом деле у нас должно быть входящее на более низких приоритетах, столько, сколько нужно для ультравысокой скорости отклика и низкой задержки для ультравысоких приоритетов. Как я вижу, D-Link делает это, Linksys — на новейших устройствах, Cisco тоже это делает, и бог знает кто еще. Если у тебя полный трафик на низких портах и ты запрашиваешь первый пакет с высоким приоритетом с порта 80, снижай скорость низкоприоритетного порта с шагами каждую секунду, пока не достигнешь наименьшего времени отклика. Установка шагов будет отличной идеей: например, шаг первый — снизить на 10%, шаг второй — на 20%, шаг третий — на 30% и так далее. В момент, когда высокая нагрузка на высокий приоритет остановится, скрипт сможет восстановить скорость до нормального уровня для низкоприоритетных портов. Это все равно что устанавливать максимальный лимит для портов, только с более плавными шагами. Один максимальный уровень для низкоприоритетного порта — это глупо и пустая трата пропускной способности, это устаревшая практика и должна быть запрещена. Второй пример — сбрасывать пакеты на низкоприоритетных портах, пока порты с высоким приоритетом не получат низкие задержки, и мы не получим хороший ответ на передачи с высоким приоритетом. Сбросить пакеты и запросить то же самое снова, пока требования к высоким портам не прекратятся. ... Есть способы, просто надо подумать креативно.

ping (icmp) — это простой тест. Вы можете наблюдать задержки в 1000 мс или тайм-ауты, и это не всегда означает, что путь медленный. Для маршрутизатора создание пакетов требует гораздо больше ресурсов, чем просто их маршрутизация. С этим решением это все еще основано на изменении исходящих пакетов, а не входящих. Почему бы просто не установить более высокий приоритет для вашего специфического (voip?) исходящего трафика? Мне кажется, у МакГайвера была хорошая идея… выложите свои правила. Из ваших первых нескольких сообщений складывается ощущение, что вы хотите найти способ снизить приоритет для долгосрочных подключений. Поскольку загрузка и серфинг — это одно и то же, вам нужно найти способ определить, что вы действительно хотите снизить приоритет. Возможно, на основе скачков, или типов MIME, или чего-то еще.

нет разницы в порте между просмотром страниц, загрузкой больших файлов и загрузкой маленьких файлов, все они используют порт 80 (конечно, я говорю о http загрузке)! и именно это я имел в виду... если у нас скорость загрузки 10 Мбит/с, и она полностью занята загрузками больших файлов различными пользователями, когда пользователь пытается открыть сайт небольшого размера, он не найдет доступной полосы пропускания для просмотра, (((страница не может быть отображена))) будет мигать у него на глазах, или в ЛУЧШИХ условиях он устроит себе сиесту, пока страница загружается! как MT может это распознать? как он может понять, что это пользователь, который просто хочет просмотреть эту маленькую страницу, пусть эти гиганты трафика немного замедлятся... ЧТО ДЕЛАЕТ ПРИОРИТЕТ MT?? некоторые люди на этом форуме (в предыдущих темах) пытались различить эти два типа трафика по их размеру подключения, что, как я обнаружил, плохо работает большую часть времени, возможно, здесь что-то упущено, а именно время подключения, так что мы можем учитывать не только размер подключения, но и активную продолжительность подключения... самое длительное большое соединение должно быть медленнее, чем новые соединения... это как с бурстом, но будет ли бурст работать, если общий трафик уже заполнен?

Приоритет в RouterOS — это настраиваемое решение, оно не предназначено для какой-то одной ситуации. Я часто использую приоритет, особенно для таких вещей, как VoIP, игры и потоковое видео. Для простоты, всякий раз, когда я упоминаю HTTP-трафик, я имею в виду трафик порта 80. Я не пытаюсь различать HTTP-трафик веб-сайтов и HTTP-трафик загрузок, так как в данный момент в этом нет необходимости. Однако я понимаю, как это может быть полезно. Как несколько участников выше отметили, основание веб-HTTP-трафика на размере пакета будет ненадежным. Я не тестировал следующую теорию и у меня нет на это времени, но, возможно, другие смогут попробовать и поделиться своими находками. Я считаю, что если создать несколько правил mangling для HTTP-трафика, вы сможете достичь желаемого. Когда клиент заходит на веб-сайт, создается много новых TCP-соединений, вы можете приоритизировать новые соединения отдельно от установленных. Признаю, это не идеально, так как данные веб-сайта приходят только после того, как TCP находится в установленном состоянии, но, на нагруженном канале, я верю, что вы должны увидеть достаточно разумное сокращение времени загрузки веб-сайта. Как только TCP-соединения установлены, в идеале все установленные соединения должны делить доступную полосу пропускания. Если этого не сделать, вы можете получить сообщение "страница не найдена", потому что соединение даже не смогло достичь этого состояния. Не забывайте, что приоритизация исходящих запросов также столь же важна, если не более. Удачи!