Боюсь, слишком короткая статья получится — «берём WLNAPi и снимаем с него Remote capture с помощью Wireshark». Да и потом, тут такое коммьюнити мощных людей, которые и свои железки для таких целей собирают, и вообще, что как-то совестно со своими крошечными открытиями туда соваться :)
Тревога! Тревога! Ширина канала под названием «20 МГц» на самом деле равна 22 МГц, первый канал заканчивается на 2423 МГц, пятый канал начинается на 2421 МГц!
Представьте: компания «Огурчик» выпускает роутер, в котором можно выбрать только три канала в 2,4 ГГц, а компания «Помидорчик» выпускает роутер, в котором можно выбрать 13 каналов. Как думаете, что благодарные пользователи напишут в отзывах? :)
Само собой, нельзя использовать iperf как измерительный инструмент — именно потому, что, во-первых, он не до конца отражает клиентские особенности, во-вторых, по сути зависит от используемого NIC. Вообще, про измерение радиоканалов, будь то Wi-Fi, точка-точка или точка-многоточка, можно написать отдельную статью: на ответ «Как вы сдаёте радиомагистрали заказчику так, чтобы обе стороны были довольны методологией измерения» самый разумный ответ, который я получил от коллег, звучал как «Забиваемся на пацана».
И да, RFC2544 не работает с радио из-за асимметричности любого беспроводного канала.
Господа, господа, 5 ГГц — это «старый» диапазон, возрастом с сам вайфай. Вот 6 ГГц — другое дело, тут интересны точки зрения людей, которые понимают в 802.11 поболее моего.
А если они вдруг появятся? Ну серьёзно, у нас же натурально миллиарды устройств минимум трёх одновременно живущих стандартов (и опционально ещё трёх полувымерших, но иногда всплывающих в самый не подходящий для этого момент).
Я рекомендую посмотреть на системы «точка-многоточка». Среди бюджетных (типа ubiquiti, cambium, mikrotik) очень популярно использовать физический уровень 802.11 со своим самописным проприетарным канальным уровнем. Клиенты все «свои», поэтому можем городить всё, что угодно, с целью выжать максимум пропускной способности из каждого мегагерца полосы, и это работает гораздо лучше и надёжнее вайфая — просто потому, что ассортимент клиентов суперузкий. Я согласен, что вариант «if (только свои) then (супер-дупер-эффективность и скорость) else (совместимость)» логичен, напрашивается сам собой и так далее, но причин, по которым им не воспользовались за двадцать лет, я назвать не готов, знаний недостаточно всё-таки.
На хабре совершенно точно есть замечательный Khorov, который входит в IEEE как Senior Member, принимает участие в разработке 802.11be (который Wi-Fi 7) и внёс мощный вклад в 802.11ax (который Wi-Fi 6). Может быть, когда-нибудь он нам ответит, было бы очень интересно почитать его мысли на этот счёт.
Ну, оно примерно так и работает: вне зависимости от того, какой ширины у нас канал, 20 или 160 МГц, весь менеджмент летит в первых двадцати (и, кстати, это причина, почему надо очень осторожно выбирать каналы шире 20 МГц: первые наши 20 МГц могут и не испытывать влияния других сетей, а где-нибудь на 60 МГц выше пролетело чего-то — и всё, коллизия, фрейм битый, переповторяем и теряем время).
Если мы перейдём на СОВСЕМ новый протокол, полностью не понятный другим, то как эти другие поймут, что мы передаём данные, и нам не надо в это время мешать?
Хотя, с другой стороны, такой протокол есть. Bluetooth, например. Передаётся в то же время, вайфай его не понимает, поэтому считает проблемой при уровне в 1000 раз бОльшем, чем соседский вайфай, и спокойно шлёт свои данные поверх, а потом клиент не может разобрать эти данные и просит повторить, так что всё равно время (и пропускная способность, потому что в вайфае время = пропускная способность, зависимость что ни на есть прямая) тратится впустую. Ну, или может разобрать, но поскольку уровень сигнала Bluetooth выше уровня шума, то вайфайным устройствам приходится понижать скорость передачи данных (потому что упало соотношение «сигнал-шум»), и снова теряется время.
Вряд ли Вы задаёте этот вопрос «из ниоткуда» :) Но ответ не настолько очевиден, как обычно пишут в дайджестах.
Да, есть механизм BSS Coloring, но он не является «серебряной пулей» и тотальным излечением от соканальной интерференции. Коротко: клиент при попытке что-то передать слушает эфир и, если слышит кадр 802.11 с уровнем +4 дБ относительно шума, считает эфир занятым, а передачу невозможной. Так вот, BSS Coloring позволяет разделить сети на «свою» и все остальные. Если мы слышим фрейм от «своей» сети, то считаем эфир занятым при, например, том же самом уровне +4 дБ от шума, а если слышим фрейм от кого-то ещё, то будем считать это проблемой только, например, при +15 дБ от уровня шума. То есть, клиент более «вежлив» с сетью «своего» цвета и менее — с сетью чужого цвета.
Но это, конечно, не повод тыкать все точки на один канал. Это просто даёт механизм чуть меньше страдать от соканальной интерференции. И сразу забегая вперёд: если «наша» точка на первом канале, а «не наша» — на третьем, то никакой BSS Coloring не поможет: обе сети не могут понять фреймы друг друга, не понимают, когда эфир занят, а когда нет, портят друг другу кадры, вызывая колизии, и резко просаживают пропускные способности друг другу.
Вообще, про каждую из технологий на инфографике из этой заметки можно написать отдельную жирную и богатую статью. Когда-нибудь я это сделаю, я надеюсь.
Не все абоненты сидят вплотную к точке доступа с высоким SNR, чтобы развить такие битрейты. Если кто-то не сможет понять такой management rate — пострадают все из-за колизии и увеличенного интервала между передачами после коллизии. Поэтому и не обновляют настолько решительно. Дело даже не столько в стандартах, сколько в «сопромате», который не обманешь.
ax — это действительно новый n по моим скромным предположениям, поскольку работает во всех доступных диапазонах (даже больше, чем n). Посмотрим, как поведут себя производители радиомодулей дальше.
Конечно, я не вкладывал в это слово никакой негативной коннотации. Наоборот, ряд проприетарных решений той же Apple следовало бы внедрить всем остальным — например, сквозной QoS от мобильного приложения до маршрутизатора при условии использования Apple и Cisco. И не всегда соответствие стандарту — это залог успеха: вспомним кучу производителей «точки-многоточки».
Абсолютно и однозначно нет. Преамбула та же самая, всё верно — это нужно для того, чтобы «старые» клиенты правильно поняли, что сеть будет занята на n миллисекунд времени, и не лезли в эфир. А что будет происходить в эти n миллисекунд — уже дело клиентов, которые будут передавать. Если они поддерживают ax, то могут получить множественный доступ и отправить/получить данные вдвоём-втроём-вдевятером, не помешав ничем всем остальным на точке.
Так что короткий ответ: нет. Точка будет с ними работать на n.
Вот про проактивность — золотые слова, ППКС. Как только я увидел сенсоры, которая Cisco приготовила для DNA (это был 2017-2018 год), я сразу понял, что единственный и правильный способ мониторить свою сеть — это вот такое вот стадо ручных клиентов.
Тем не менее, Максим рациональное зерно заложил не хуже: чем меньше неизвестных, тем проще найти решение, каким бы изысканным и эвристическим методом мы это не пытались делать. Количество часов на этапе планирования и интеграции обратно пропорционально количеству часов траблшутинга потом.
«Скорости были всегда выше» — это очень смелое заявление. С какими клиентами, только с Apple (сразу приходит в голову какой-нибудь проприетарный QAM256 в 2,4 ГГц по аналогии с NitroQAM от ASUS) или со всеми подряд? В каких радиоусловиях? И так далее. Слишком много неизвестных для того, чтобы можно было ответить что-то кроме «зависит от всего» :)
Тревога! Тревога! Ширина канала под названием «20 МГц» на самом деле равна 22 МГц, первый канал заканчивается на 2423 МГц, пятый канал начинается на 2421 МГц!
Представьте: компания «Огурчик» выпускает роутер, в котором можно выбрать только три канала в 2,4 ГГц, а компания «Помидорчик» выпускает роутер, в котором можно выбрать 13 каналов. Как думаете, что благодарные пользователи напишут в отзывах? :)
Само собой, нельзя использовать iperf как измерительный инструмент — именно потому, что, во-первых, он не до конца отражает клиентские особенности, во-вторых, по сути зависит от используемого NIC. Вообще, про измерение радиоканалов, будь то Wi-Fi, точка-точка или точка-многоточка, можно написать отдельную статью: на ответ «Как вы сдаёте радиомагистрали заказчику так, чтобы обе стороны были довольны методологией измерения» самый разумный ответ, который я получил от коллег, звучал как «Забиваемся на пацана».
И да, RFC2544 не работает с радио из-за асимметричности любого беспроводного канала.
Я рекомендую посмотреть на системы «точка-многоточка». Среди бюджетных (типа ubiquiti, cambium, mikrotik) очень популярно использовать физический уровень 802.11 со своим самописным проприетарным канальным уровнем. Клиенты все «свои», поэтому можем городить всё, что угодно, с целью выжать максимум пропускной способности из каждого мегагерца полосы, и это работает гораздо лучше и надёжнее вайфая — просто потому, что ассортимент клиентов суперузкий. Я согласен, что вариант «if (только свои) then (супер-дупер-эффективность и скорость) else (совместимость)» логичен, напрашивается сам собой и так далее, но причин, по которым им не воспользовались за двадцать лет, я назвать не готов, знаний недостаточно всё-таки.
На хабре совершенно точно есть замечательный Khorov, который входит в IEEE как Senior Member, принимает участие в разработке 802.11be (который Wi-Fi 7) и внёс мощный вклад в 802.11ax (который Wi-Fi 6). Может быть, когда-нибудь он нам ответит, было бы очень интересно почитать его мысли на этот счёт.
И вообще, не саботаж, а совместимость! :)
Хотя, с другой стороны, такой протокол есть. Bluetooth, например. Передаётся в то же время, вайфай его не понимает, поэтому считает проблемой при уровне в 1000 раз бОльшем, чем соседский вайфай, и спокойно шлёт свои данные поверх, а потом клиент не может разобрать эти данные и просит повторить, так что всё равно время (и пропускная способность, потому что в вайфае время = пропускная способность, зависимость что ни на есть прямая) тратится впустую. Ну, или может разобрать, но поскольку уровень сигнала Bluetooth выше уровня шума, то вайфайным устройствам приходится понижать скорость передачи данных (потому что упало соотношение «сигнал-шум»), и снова теряется время.
Да, есть механизм BSS Coloring, но он не является «серебряной пулей» и тотальным излечением от соканальной интерференции. Коротко: клиент при попытке что-то передать слушает эфир и, если слышит кадр 802.11 с уровнем +4 дБ относительно шума, считает эфир занятым, а передачу невозможной. Так вот, BSS Coloring позволяет разделить сети на «свою» и все остальные. Если мы слышим фрейм от «своей» сети, то считаем эфир занятым при, например, том же самом уровне +4 дБ от шума, а если слышим фрейм от кого-то ещё, то будем считать это проблемой только, например, при +15 дБ от уровня шума. То есть, клиент более «вежлив» с сетью «своего» цвета и менее — с сетью чужого цвета.
Но это, конечно, не повод тыкать все точки на один канал. Это просто даёт механизм чуть меньше страдать от соканальной интерференции. И сразу забегая вперёд: если «наша» точка на первом канале, а «не наша» — на третьем, то никакой BSS Coloring не поможет: обе сети не могут понять фреймы друг друга, не понимают, когда эфир занят, а когда нет, портят друг другу кадры, вызывая колизии, и резко просаживают пропускные способности друг другу.
Вообще, про каждую из технологий на инфографике из этой заметки можно написать отдельную жирную и богатую статью. Когда-нибудь я это сделаю, я надеюсь.
ax — это действительно новый n по моим скромным предположениям, поскольку работает во всех доступных диапазонах (даже больше, чем n). Посмотрим, как поведут себя производители радиомодулей дальше.
Так что короткий ответ: нет. Точка будет с ними работать на n.
Тем не менее, Максим рациональное зерно заложил не хуже: чем меньше неизвестных, тем проще найти решение, каким бы изысканным и эвристическим методом мы это не пытались делать. Количество часов на этапе планирования и интеграции обратно пропорционально количеству часов траблшутинга потом.