Приоритетное использование сигнала WI-FI
 

Доброе утро. Вопрос следующий: можно ли на wi-fi роутер настроить приоритет по скорости потребления? Имеется в виду чтобы один из двух подключаемых ноутбуков всегда, если так можно выразиться, получал столько интернета, сколько требуется, независимо от того, сколько грузит второй ноут? Роутер TRENDnet. Заранее благодарен

А модель нам, видимо, угадать нужно...

Нельзя. Простой пример - пользователь второго смотрит потоковое видео. Ограничить поступление данных этому пользователю по каналу провайдера не сможет никакой маршрутизатор.

Angry Demon , а что, есть несколько вариантов решения проблемы, зависящих от конкретной модели, или это так просто?

Бред.
Маршрутизаторы ALIX c Pfsense спокойно срежет скорость.

Если Вы так уверены, что моё достаточно очевидное утверждение является "бредом", может быть подскажете, каким образом по-Вашему маршрутизатор будет ограничивать ненужный трафик по каналу провайдера?

Если вы скажете, что у вас автомобиль Ford, и спросите, ездит ли он со скоростью свыше 200 км/ч, как вы думаете, что вам ответят?

Например обычным Limiterом, который вырежет скорость до нужной автору.

Представьте себе шоссе на котором имеется перекресток. При помощи светофоров на перекрестке Вы можете управлять потоком машин, который Вы пропускаете через этот перекресток. Вам несложно сделать так, чтобы за перекрестком пробок никогда не было - как только машин становится достаточно много, Вы просто включаете красный свет и никого не пропускаете. Но как Вы обеспечите отсутствие пробок перед перекрестком? Согласитесь, что это невозможно.
Теперь вернемся к нашей ситуации с маршрутизатором. Ограничить исходящий трафик (за маршрутизатором) легко. Вы можете пропускать все пакеты адресованные на один компьютер и отбрасывать адресованные на второй. Только не факт, что это Вам поможет - если Вы отбрасываете какие-то ненужные пакеты, значит они уже прошли по каналу от провайдера до маршрутизатора. И заняли собой какую-то часть его пропускной способности, не позволив пройти пакетам, которые Вы готовы были бы пропустить.
Видите аналогию с шоссе? Никакое управление полосой пропускания не может гарантировать отсутствие "пробки" перед маршрутизатором. Если бы ситуация обстояла бы иначе, не существовало бы и такой вещи как DOS атаки.

AMDBulldozer, Сравнивать DDOS атаку и потоковое видео не уместно.
Насчет того что Вы написали я тоже не соглашусь. Настраивать приоритет трафика можно по различным категориям, например как это делается в Layer7, но мало кто на это пойдет.
Ограниченная полосу пропускания c помощью Limiter мы вообще назначаем оптимальную скорость участникам сети, что позволит не забивать канал.
Если у Вас канал в 100 мб а у вашего друга в ноуте сетевуха на 10 мб он же не сможет забить канал?

У этих двух видов трафика есть одна общая особенность - они не требуют получения подтверждения доставки пакета. И рассылаются независимо от того может ли получатель его принять.
Вы написали что-то такое, что я не понял...
Очевидно это имеет отношение к QoS, но QoS не может быть применен на ingress.
Конечно сможет. Какое отношение имеет то количество информации, которое он физически в состоянии принять, к тому, которое он может заказать?
Если у Вас есть тысяча рублей, Вы можете заказать себе доставку товаров на миллион?

Вас не затруднит пояснить с какой целью Вы дали ссылку никак не относящуюся к теме вопроса? Если Вашей целью было привести мне список разных протоколов, то я могу посмотреть его в /etc/services. Если Вы хотели рассказать про приоретизацию трафика, то не пойму для чего Вам было тратиьь время - Вы можете пропускать на светофоре машины "Скорой помощи" вне очереди, но это никак не поможет им продвигаться быстрее в пробке перед светофором.

Не буду давать ссылок (тем более, совершенно бесполезных), поясню на пальцах. Допустим у Вас есть узенький канал 128 кбит/сек. Его делят два пользователя - Вася и Петя. Петя управляет маршрутизатором и может настроить его как сам захочет. А Вася ничем не управляет, он просто запускает на своём компьютере потоковое видео с битрейтом 500 Кбит/сек. И Петя может доприоритезироваться хоть до инсульта - интернет у него работать не будет. Точка.
(все числа в примере взяты произвольно - при их изменении основной принцип остается прежним)

AMDBulldozer, Только что поставил правило на 300 кб на Limiter+Layer7.
На сервер приходило порядка 600 кб с остановками, так что это фактически и было 300 кб.
Видео с 720p грузиться ну очень долго :)
Прошу заметить что я не говорю о плавном ограничении, но трафик зарезало очень сильно.

Картинка с ограничениями

Картинка без ограничений

Rezor666, спасибо. я имел в виду просто чтобы при одновременном пользовании каналом двумя компьютерами, скорость всегда была больше на одном из них

Angry Demon, модель TEW-65. Ну и что это меняет?

Rezor666, к чему Вы это написали? Никто никогда не отрицал, что поступающий процессам трафик можно лимитировать.
Если продолжить использование аналогии с перекрестком, Вы закрыли ворота и не пропускаете въезжающие машины. Дальше что? Что Вы этим пытаетесь доказать? Что все непропущенные Вами машины мистическим образом исчезнут с дороги и перестанут создавать пробку? Не перестанут - они по ней уже проехали к тому моменту, когда Вы решили их не пропустить.
Понимаете, Вы сейчас пытаетесь на скорую руку изобрести вечный двигатель. Сущность, которой в природе быть не может. Потому что не сушествует физического принципа, который она могла бы использовать.
Нельзя лимитировать трафик отправляемый Вам шлюзом провайдера. Поскольку в семействе протоколов TCP/IP отсутствуют формальные средства управления полосой пропускания.
Вы как-то упорно игнорируете все мои аргументы. Можете пояснить как Петя из предыдущего сообщения сможет заходить на web-сайты, когда Вася запустил передачу потокового видео? Чем ему поможет Ваш "Limiter+Layer7"?

Если Вы посмотрите на скрины то увидите что канал провайдера не забил наш канал.
600 кб меньше 23 мб? А в чем проблема тогда?
В связи с этим Петя может спокойно сидеть на сайтах а тот кто смотрит видео будет ждать пока оно загрузиться.

У Вас есть узенький канал на 23 мб/сек. Его делят 2 юзера - Вася и Петя. Петя управляет маршрутизатором и может настроить его как сам захочет. А Вася ничем не управляет, он просто запускает на своём компьютере потоковое видео с битрейтом 40 мб/сек.
А петя его режет до 300 кб/сек. Точка.

Или Вы хотите что бы я еще со второй машины показал что спокойно смотрю HD видео пока у второго оно не грузиться?

Rezor666, Вы действительно хотите показать "скрин работающего вечного двигателя"?
Вы совсем не понимаете, что Ваш "лимитер" режет пакеты, которые уже прошли по каналу провайдера?
Если у Вас "видео с 720p грузиться ну очень долго" - значит оно не потоковое. Потоковое вещание идет по определению в реальном времени.
Если хотите, могу дать Вам ссылку на сообщение в котором рассказывается про существующие способы попытаться ограничить трафик в канале провайдера. Маршрутизаторы Trendnet используют второй из описанных.
Понятно, что на потоковом видео ни один из двух работать не будет.
Поясню разницу на другом примере: Вы можете ограничить количество писем отправленных на Ваш почтовый ящик?
В некоторых случаях можете - если Вы ведете с кем-то переписку или получаете от кого-то рекламную рассылку, Вы можете попросить его больше Вам не писать. Маршрутизатор делает именно это. От имени адресата он просит отправителя посылать ему поменьше пакетов.
Гарантирует ли это уменьшение их количества? На ничего подобного! Спам Вы как получали, так и будете получать. Вы можете удалять письма со спамом сразу же по мере их получения. Но Ваш провайдер почтового сервиса всё равно засчитает их Вам как полученные.

Только что проверил на сайте pro-tv.net, там тоже не потоковое?
А на сервере картинка такая же.
Правда видео теперь прерывается :)

P.S И давай без твоих примеров, не ребенок. Если можешь объяснить почему ограничиваться на скринах "не ограничиваемое" то давай.

Rezor666, пример потокового видео - изображение с видеокамеры. После того как Вы выбрали формат и начали его принимать, оно идет с фиксированным битрейтом. Его можно ограничить на маршрутизаторе и картинка действительно начнет дергаться, но поток данных с этим заданным битрейтом в любом случае пройдет по каналу провайдера и займет либо часть, либо почти всю полосу пропускания. Если Вы верите в то, что его можно каким-то мистическим способ не пустить на шлюз провайдера - назовите мне этот способ. Только не путем указанния ссылки на программу chkdisk или другую столь же не относящуюся к данному случаю, а перескажите, если не затруднит, своими словами. Куда пропадут по дороге отаравленные видеокамерой пакеты? Она сама не снизит скорость передачи, даже если Вы вообще ни одного её пакета не пропустите. Заставить промежуточные узлы отбрасывать её пакеты Вы тоже не м ожете. Так что они в любом случае дойдут до маршрутизатора.

P.S. Заглянул на указанный Вами сайт. Насколько я понял, трансляция там идет в формате Adobe Flash. Это не потоковый протокол. Он использует обычные tcp-сессии

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

Всё верно, кроме вывода. Петя не сможет залезать на сайты. Потому что при ширине канала 128 кбит он будет полностью забит пакетами RTP.
Давайте посмотрим как это будет происходить в динамике: первоначально Петя шлялся по web-сайтам и получал с них информацию со скоростью 128 кбит/сек. Потом Вася включил потоковое видео с битрейтом 500 кбит/сек. На шлюз провайдера начало поступать 500+128=628 кбит/сек.
Которые провайдер начал резать до 128 - тарифной скорости подключения. При этом он отбрасывал пакеты случайным образом, не разбираясь кому они предназначены - Пете или Васе. Но вся беда в том, что Петя получает информацию по протоколу прикладного уровня HTTP, который использует протокол транспортного уровня TCP. А последний требует отправки подтверждения получения пакетов. И у Пети, и у Васи первоначально терялось по 80% пакетов. Но Петя еще мог несколько секунд бродить по сайтам со скоростью хотя бы 25 кбит/сек. Увы, его счастье было недолгим - заметив, что компьютер Пети не посылает подтверждения, сервер начал снижать скорость передачи. Допустим он в какой-то момент снизил её до 64 кбит/сек.
Но сервер потокового видео своей скорости снижать не стал. Значит на шлюз провайдера стало поступать 500+64=564кбит/сек. Шлюз по-прежнему отбросил случайным образом пакеты. В результате Вася стал получать чуть больше, чем раньше: его доля была 500/628=79.6%, а стала 500/564=88.6%, а Петя, соответственно, меньше. Заметив, что компьютер Пети по прежнему не принимает все отправленные пакеты, HTTP-сервер еще раз внизит скорость передачи.
...и всё описанное в предыдущем абзаце повторится. Чем дело закончится? Тем, что вся полоса пропускания достанется Васе. И никакие манипуляции с маршрутизатором, кроме полного отключения Васи от сети, чтобы он не мог запрашивать передачу потоковых данных, не позволят ситуацию изменить.

AMDBulldozer, Все логично...
Хм, но если я верно понимаю то Вася посылает информацию с битрейтом, а если маршрутизатор при пакете с определенном битрейтом начнет изменять битрейт в меньшую сторону и отсылать ее уже дальше провайдеру?

Если бы Вася что-то посылал, это был бы исходящий трафик, который элементарно поддается шейпингу. Вася посылает только запрос на начало передачи ему данных. После этого удаленный сервер начинает отправлять фиксированное число пакетов в секунду.
Результат будет такой же, как если бы Вася зашел по ssh на удаленный сервер и с него дал команду "ping -i 0.001 vasya.ru".
Канал от провайдера будет заполнен пакетами icmp echo request и маршрутизатор никак не сможет предотвратить поступление этих пакетов.
Только нагрузка которую создает ping не слишком велика (хотя командой ping -f несколько человек могут спокойно положить чей-то не слишком широкий канал), а потоковые данные с того сайта, который Вы указали, могут отправляться со скоростью до 5Мбит/сек.
При этом можно одновременно можно инициировать любое количество rtp-сессий.
Выполнять полисинг этого трафика можно только из желания насолить Васе и ни по какой иной причине - после того как он уже прошел по каналу провайдера и забил его, он становится безвреден (локальные сети обычно всегда имеют большую пропускную способность, чем канал провайдера).

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

AMDBulldozer, Вы меня не верно поняли.
В запросе Васи должен быть битрейт или скорость.
Маршутизатор ловит его запрос и изменяет, после этого отправляет дальше на сервер.
Таким образом уже не пользователь Вася будет выбирать битрейт а наш маршутизатор.
Например если у нас скорость в 23 мб и 2 клиента то маршутизатор при отправке запроса от Васи изменит битрейт до 15.5 мб/сек.

Рассуждая чисто теоретически, Вы правы. Таким образом можно было бы управлять скоростью поступления данных.
...если бы такой способ существовал в природе. К сожалению, его нет.
При запросе на передачу потоковых данных, битрейт выбирается не одним из полей запроса, а просто указанием URL.
Щелкнете по одной ссылке на сайте - будет один битрейт. Щелкнете по другой - другой. Или тот же самый. Непредсказуемо.
Сайт может предлагать несколько источников потоковых мультимедийных данных с разным битрейтом. Или несколько разных с одинаковым. Или один источник с несколькими битрейтами. Всё зависит от автора сайта. Даже если какой-то телеканал и можно смотреть с разном качествым (что далеко не всегда так), то автоматизации процесс выбора правильной ссылки абсолютно не поддается.
Еще раз повторю: сам протокол установления RTP-сессии не содержит поля битрейта, который можно было бы изменить.
Правда есть еще один момент, о котором необходимо упомянуть.
Формально до 5% от объема потоковых данных занимают пакеты управляющего протокола RTCP, в котором, в частности, передается статистика по проценту успешно принятых пакетов. Предполагалось, что, обнаружив высокий процент потерь, сервер потоковых данных может уменьшить скорость передачи.
На практике этого никогда не происходит. Почему? Потому что это почти всегда мультикаст - одни и те же данные пересылаются одновременно множеству клиентов. Снижать скорость передачи (даже если эта возможность вообще реализована на сервере) изза одного клиента никто не станет.
Поэтому идея у Вас в теории хорошая, но, увы, не реализуемая.
И это логично. Допустим, у Вас есть DVD диск, который Вы транслируете в интернет. Со стандартным битрейтом - 1.32Мбайт/сек. Тут Вам кто-то сообщает, что не успевает принимать данные и просит снизить битрейт. Как Вы это сделаете? Будете перекодировать видео "на лету" по требованию клиента? А если их сотня и каждый хочет свой собственный битрейт?

Так что единственный способ попытаться дать Пете спокойно пользоваться интернетом - это реагировать на любой большой трафик как на сетевую угрозу (помните, Вы меня в самом начале спрашивали что общего между DDOS и потоковым видео?) и блокировать ip с которого эти данные поступают. Какой-нибудь IDS. Snort, к примеру.
Разумеется это не помешает отправленным с сервера пакетам забить канал. Однако когда соединение с сервером разорвется, сервер перестанет отправлять данные (аналогично: запущенный по ssh ping продолжит работу, но прервется сама ssh сессия).
Но ведь это не то, что мы хотели, правда? Такое решение сводится по сути к отключению Васи от сети. А не к выделению ему остатков от полосы пропусканию не использованных Петей.
К тому же, подобная блокировка легко обходится путем использования proxy-сервера.

AMDBulldozer, Согласен, вы правы, признаю что был не прав.
Чисто теоретически можно сделать сканирование на наличие url с битрейтом и выбором оптимального варианта, но реализация очень затруднительна и вряд ли многие web программисты пойдут на систематизацию URL.

Откровенно говоря в наше время я уже не вижу в этом проблемы.
Если дома канал 100 мб то можно спокойно смотреть видео и лазить в интернете.
На предприятиях можно разделить трафик на группы.
Например:
http, https - wan1
httpvideo, torrent - wan2
VPN, RDP - wan 3
и.т.д

Да.

Так что в итоге?))))
Вот. к примеру, сейчас на втором устройстве скачивается торрент файл. вся скорость уходит на него. у меня никакое видео, ничего не грузится...

2gan, TRENDnet не знает, что выпустил такую модель.

Angry Demon, TRENDnet TEW-651BR. Зато я знаю. Ну вот уточнили модель, дальше что? или Вы просто из занудства спрашивали? Сертификаты нужно скопировать может?

2gan, спрашивают для того, чтобы вести разговор на одном языке. Воздержитесь от ехидства.

Любезнейший, похоже, что это мне очень нужно какую-то проблему решить, а не вам, судя по распальцовке и ехидству. Учтите, в гостях себя так не ведут, если вы не знали.

Роутер не обладает функцией шейпера. Вашу задачу с помощью него не решить.

Iska, ну так можно же нормально сказать, а не кидать умняки про форд и про то как мы должны догадаться о модели? Просто модель спросить нельзя?

Да ничего мне конкретно от Вас не надо. просто чем обвинять меня в ехидстве и распальцовке, последили бы за собой. Почему-то другие не стали умничать, а просто ответили.
... И если вы считайте этот форум своим домой, себя мегасуперкрутым хозяином-модератором, а меня своим гостем, мне больше сказать нечего...)

А нельзя просто сразу говорить о модели? Поверьте эта ошибка многих и просто надоедает в день по 10 раз говорить "А какая у Вас модель?".
Согласитесь что мы не телепаты тут и попробуйте нас понять.

Rezor666, "А модель нам, видимо, угадать нужно..." "Если вы скажете, что у вас автомобиль Ford, и спросите, ездит ли он со скоростью свыше 200 км/ч, как вы думаете, что вам ответят?" "TRENDnet не знает, что выпустил такую модель."
Ну да, конечно, просто спросить модель куда сложнее, особенно если надоело говорить по 10 раз...

Согласитесь что Вы сами не верно указали модель в начале.
Просто роутер может обладать функцией Shaper а может и не обладать и для того что бы это узнать нужна точная модель устройства.

Я понимаю что услышать
не очень приятно. Но Вы сами пренебрегли пунктом 2.7 в правилах.
Пункт гласит
Я уже не говорю о том что в поиске на сайте можно вбить
1- Shaper
2- Ограничения скорости
3- Распределение скорости

И все эти запросы Вас приведут к нужному ответу.

Rezor666, спасибо. Я Вас понял, надеюсь Вы меня тоже поняли