объединение пакетов wifi что это
Кое-что о Wi-Fi
Недавно побывал на конференции на тему “Построение беспроводных сетей”. Не смотря на то, что довольно длительный период работаю администратором, мне не каждый день приходится разворачивать беспроводные сети. Спешу с вами поделиться некоторыми нюансами. Всех заинтересованных приглашаю под кат.
Wi-Fi не имеет четкой границы распространения
Это значит что никто не проведя необходимой оценки не сможет дать вам гарантии что связь будет работать даже в пределах одного кабинета или комнаты.
Бывали случаи что в офисе раз в сутки пропадала связь где-то на пол часа. Сотрудник тех-поддержки производителя точки доступа попался опытный, по этому узнав время когда чаще всего ложилась связь (а чаще всего это случалось с 12-00 и до 14-00), предположил что виною всему является микроволновка. В данном офисе микроволновки в помине не было, но она была в соседнем, как раз за стеной к которой была привинчена точка доступа.
Здесь так же следует вспомнить всевозможные Wi-Fi-джаммеры, которыми могут воспользоваться ваши конкуренты, заплатив соседям за то, чтоб они включали её время от времени. 
Ввиду этого не рекомендуется использовать беспроводные сети как замену корпоративной ЛВС на витой паре или оптике. Либо делать это в крайнем случае, если проложить кабель не представляется возможным. Например если необходимо связать два недалеко расположенных офиса за городом.
Беспроводную сеть лучше всего рассматривать как замечательное дополнение к “традиционным” сетям. Например для организации гостевого доступа для своих клиентов.
Необходимо так же учесть, что сети Wi-Fi могут не одинаково хорошо работать с разными протоколами транспортного уровня. Так, например, протоколы TCP и UDP могут работать замечательно, а вот IPX из рук вон плохо.
Для того, чтобы понять как именно следует строить сеть, а так же попытаться определить возможную причину неисправности нужно слегка разобраться в существующих стандартах и их уязвимых местах.
На данный момент думаю, есть смысл рассматривать стандарты 802.11g и 802.11n.
802.11g
Стандарт работает на частотах 2,4-2,4835 ГГц и позволяет передавать данные с канальной скоростью 54-1 Мбит/сек, совместим со стандартом 802.11b. Для удобства передачи данных частота поделена на так называемые каналы.
Из изображения понятно что каналов всего 14, но в зависимости от страны, в которой мы находимся, разрешенными для использования могут быть только некоторые из них. Так например в Украине и России разрешено использовать с 1 по 13 канал, в Японии все 14. Но меньше всего повезло Франции и Испании, им разрешено использовать только 4 канала (2.457 — 2.472 ГГц). Так что если ваша точка доступа имеет каналов меньше 13, то возможно что она была ввезена серым путем, или на нее была залита прошивка не для вашего региона.
Еще одним подводным камнем при настройке беспроводной сети является перекрытие смежных каналов друг другом, что так же видно из рисунка, приведенного выше.
Ведь логично предположить что при настройке двух смежных точек доступа, достаточно просто их настроить на разные каналы. Например 1 и 2, или 1 и 3. Ан нет, так как эти каналы пересекаются друг с другом, то наши точки доступа, настроенные таким образом, будут создавать помехи друг для друга. То есть если нам доступно 13 каналов, то максимум рядом мы можем настроить 3 точки доступа стандарта b и g, которые будут нормально сосуществовать, например на 1, 6 и 11 канал. К сожалению в больших бизнес-центрах, где находятся десятки разных фирм и десятки точек доступа, и настроить идеально связь будет тяжело. Если же все точки доступа находящиеся в здании под вашим контролем и необходимо как-то сделать так чтобы они ужились все вместе, можно попробовать сбавить немного мощность вещания смежных точек.
Просмотреть ситуацию в эфире можно с помощью opensource-программы inSSIDer и ей подобных (NetStumbler, WiFi Hopper итп) 
Это скриншот, полученный мной из inSSIDer, в Ubuntu 10.10. Вы видите что программа отображает найденные сети, каналы, на которых они вещают, их MAC-адреса, уровень сигнала каждой, производителя и метод шифрования, используемый AP. Так же программа чертит очень наглядные графики, по которым легко определить какие именно точки доступа мешают друг другу.
Теперь давайте взглянем на стандарт 802.11n. Устройства 802.11n могут работать в двух диапазонах, 2,4 — 2,5 или 5,0 ГГц. Стандарт обратносовместим со стандартами 802.11g (а соответственно и 802.11b) и 802.11a (на частоте 5,0 ГГц). На частотах в 5,0 ГГц доступно 24 непересекающихся каналов. Теоретически канальная скорость передачи данных при использовании 802.11n может достигать 300 Мбит/сек (600 Мбит/сек при использовании 4-х антенн, но необходимо понимать за счет чего получилось увеличить скорость до таких показаний.
Объединение каналов (20/40 Coexistence Mechanism)
Стандарт 802.11n позволяет объединять смежные каналы для увеличения скорости передачи данных за момент времени. 
Объединение каналов возможно использовать в обоих диапазонах, но так как в диапазоне 2,4 ГГц доступно только 3 непересекающихся канала, использовать данную возможность в этом диапазоне крайне не рекомендуется. Так же нужно отметить что согласно стандарта, если в диапазоне 2,4 ГГц на котором используется канал удвоенной ширины появляется устройство, работающее на канале стандартной ширины, то устройство 802.11n обязано перейти на работу с каналом стандартной ширины.
Позволяет передавать и принимать данные с использованием нескольких антенн одновременно. При использовании 4-х антенн теоретически возможно достигнуть канальной скорости в 600 Мбит/сек.
Short Guard Interval
Для разделения передаваемых сигналов используется небольшой интервал между передаваемыми данными. Чтобы уменьшить время приходящееся на служебную информацию было принято решение использовать укороченный GI. При зашумленности канала или слабом сигнале это так же является узким местом. Так как пакет приходит поврежденным и его приходится дублировать, возможно так же не увеличение скорости, а совершенно наоборот.
Стандартная ширина интервала: 
Использование SGI: 
Получается что для того, чтобы достигнуть канальной скорости в 300 Мбит/сек при двух антеннах, или 600 Мбит/сек при четырех, нужно обеспечить минимальную зашумленность канала при максимальном уровне сигнала, и только при использовании всех трех вышеизложенных технологий (объединение каналов, укороченный GI и MIMO). Короче говоря 300 и 600 Мбит/сек — это сферический конь в вакууме. Для наглядности приведу таблицу взятую из Википедии:
Если предположить что нам таки удалось раскачать нашу сетку до 300 Мбит/сек, то эффективная скорость передачи данных все равно будет около 100 Мбит/сек, ведь как мы помним Wi-Fi обладает большой избыточностью. Если добавить сюда шифрование, то скорость может упасть еще процентов на 7. И весь этот канал так же делится между всеми клиентами AP. Поэтому количество подключенных узлов и характер передаваемых данных имеет очень большое значение. Так, например 8-10 человек — любителей веб-сёрфинга вполне мирно могут сосуществовать на одной точке доступа. Но если среди них найдется парочка торрентистов, то они могут очень испортить всем остальным удовольствие. Если же в качестве клиентов у вас выступают какие-то специфичные контроллеры, которые раз в час/сутки передают небольшой объем информации, то уместить таких узлов на одной точке можно гораздо больше.
Большинство современных точек доступа, роутеров и других устройств помимо основного режима — точки доступа, могут выступать так же в роли моста, репитера, итп. Так вот, стандартом поддерживается только основной режим — режим точки доступа, по этому если вы планируете использовать свои устройства в других режимах, то крайне желательно подбирать сопряженные устройства одного производителя и одной модели. То же касается и фирменных технологий типа Super G итп.
Преграды
Предположим у нас есть точка доступа прикрученная к стене, а с другой стороны стены, на расстоянии метров пяти находится клиент с ноутбуком. 
Преграда в виде стены толщиной в каких-то 10-20 сантиметров благодаря такому острому углу может вылиться в непроницаемые несколько метров железобетона. Сильно ухудшать сигнал могут так же зеркала из-за своего металлизированного покрытия. Массивные сейфы, расположенные между точкой и клиентом, так же могут свести на нет сигнал даже на небольшом расстоянии.
Это то, что касается сетей внутри помещения. Если же мы пытаемся прокинуть сигнал снаружи, здесь так же необходимо учитывать множество факторов: препятствия ну пути прохождения сигнала, погодные условия и даже время года. Например если сеть разворачивали зимой, а в конце весны деревья покрылись листвой, и слабый, но более-менее приемлемый сигнал совсем сошел на нет.
Антенны
Прежде всего, антенна — пассивный усилитель. Это значит, что она может расширять зону вещания одного направления только за счет другого. Каждая антенна имеет одну важную характеристику — диаграмму направленности.
Допустим вы развернули в своем офисе беспроводную сеть. Сигнал, на этаже, на котором установлена точка доступа, приемлемый. Но вот этажом выше, прямо над AP находится еще один клиент, у которого прием очень слабый. Вы решаете поставить более мощную антенну, на первом этаже сигнал становится вообще замечательным, а вот на втором этаже ситуация еще ухудшилась. Все потому, что мы не учли диаграмму направленности. У стандартной всенаправленной антенны, которыми обычно комплектуются беспроводные устройства диаграмма направленности может выглядеть примерно так:
У направленной антенны по-другому: 
Многие точки доступа помимо внешней антенны, имеют еще внутреннюю. При этом по-дефолту в качестве источника, используется та, с которой в данный момент идет более уверенный сигнал. По этому если вдруг вы решите заменить стандартную антенну, направленной внешней, необходимо так же указать в настройках точки доступа, какую именно антенну необходимо использовать. Если этого не сделать, то мы рискуем ловить более мощный, но не интересующий нас сигнал на внутреннюю антенну. На SOHO-точках данная опция может быть не реализована в веб-интерфейсе, но не стоит отчаиваться, очень часто возможно переключиться на нужную антенну через ssh или telnet. В любом случае стоит выкачать User Manual и изучить.
Зона Френеля
Так же стоит упомянуть о зоне Френеля. Не особо вдаваясь в технические подробности, можно сказать что это особая зона, в виде вытянутого за концы овала между нашими устройствами, в которую ничего не должно попадать. 
В данной статье я постарался раскрыть общие проблемы, не зависящие от производителя оборудования. Надеюсь по прочтению вы узнали для себя что-то новое. Если есть какие-то ошибки или неточности — пишите.
Настоящее суммирование интернет-каналов — OpenMPTCPRouter
Можно ли объединить несколько интернет-каналов в один? Вокруг этой темы куча заблуждений и мифов, даже сетевые инженеры с опытом часто не знают о том, что это возможно. В большинстве случаев, объединением каналов ошибочно называют балансировку на уровне NAT или failover. Но настоящее суммирование позволяет пустить одно единственное TCP-подключение одновременно по всем интернет-каналам, например видеотрансляцию так, чтобы при обрыве любого из интернет-каналов вещание не прерывалось.
Существуют дорогие коммерческие решения для видеотрансляций, но такие устройства стоят много килобаксов. В статье описывается настройка бесплатного, открытого пакета OpenMPTCPRouter, разбираются популярные мифы о суммировании каналов.
Мифы про суммирование каналов
Есть много бытовых роутеров, поддерживающих функцию Multi-WAN. Иногда производители называют это суммированием каналов, что не совсем верно. Многие сетевики верят, что кроме LACP и суммирования на L2 уровне, никакого другого объединения каналов не существует. Мне часто доводилось слышать, что это вообще невозможно от людей, которые работают в телекомах. Поэтому попробуем разобраться в популярных мифах.
Балансировка на уровне IP-подключений
Это самый доступный и популярный способ утилизировать несколько интернет-каналов одновременно. Для простоты представим, что у вас есть три интернет провайдера, каждый выдаёт вам реальный IP-адрес из своей сети. Все эти провайдеры подключены в роутер с поддержкой функции Multi-WAN. Это может быть OpenWRT с пакетом mwan3, mikrotik, ubiquiti или любой другой бытовой роутер, благо сейчас такая опция уже не редкость.
Для моделирования ситуации представим, что провайдеры выдали нам такие адреса:
То есть, подключаясь к удалённому серверу example.com через каждого из провайдеров, удаленный сервер будет видеть три независимых source ip клиента. Балансировка позволяет разделить нагрузку по каналам и использовать их все три одновременно. Для простоты представим, что мы делим нагрузку между всеми каналами поровну. В итоге, когда клиент открывает сайт, на котором условно три картинки, он загружает каждую картинку через отдельного провайдера. На стороне сайта это выглядит как подключения с трёх разных IP.
Такой режим балансировки часто несёт проблемы для пользователей. Например, многие сайты жёстко привязывают cookie и токены к IP-адресу клиента, и если он внезапно изменился, то запрос отбрасывается или клиента разлогинивает на сайте. Это часто воспроизводится в системах клиент-банка и на других сайтах со строгими правилами пользовательских сессий. Вот простой наглядный пример: музыкальные файлы в VK.com доступны только при действительном ключе сессии, который привязан к IP, и у клиентов, использующих такую балансировку, часто не проигрываются аудио, потому что запрос ушёл не через того провайдера, к которому привязана сессия.
При загрузке торрентов балансировка на уровне подключений суммирует пропускную способность всех каналов
Такая балансировка позволяет получить суммирование скорости интернет-канала, при использовании множества подключений. Например, если у каждого из трёх провайдеров скорость 100 Мегабит, то при загрузке торрентов мы получим 300 Мегабит. Потому что торрент открывает множество подключений, которые распределяются между всеми провайдерами и в итоге утилизируют весь канал.
Важно понимать, что одно единственное TCP-подключение всегда пройдёт только через одного провайдера. То есть если мы скачиваем один большой файл по HTTP, то это подключение будет выполнено через одного из провайдеров, и если связь с этим провайдером оборвется, то загрузка тоже сломается.
Одно подключение всегда будет использовать только один интернет-канал
Это справедливо и для видео-трансляций. Если вы вещаете потоковое видео на какой-то условный Twitch, то балансировка на уровне IP-подключений не даст никакой особенной пользы, так как видео-поток будет транслироваться внутри одного IP-подключения. В данном случае, если у провайдера WAN 3 начнутся проблемы со связью, например потери пакетов или снижение скорости, то вы не сможете моментально переключиться на другого провайдера. Трансляцию придётся останавливать и переподключаться заново.
Настоящее суммирование каналов
Реальное суммирование каналов даёт возможность пустить одно подключение к условному Twitch сразу через всех провайдеров таким образом, что, если любой из провайдеров сломается, подключение не оборвется. Это на удивление сложная задача, которая до сих пор не имеет оптимального решения. Многие даже не знают, что такое возможно!
По предыдущим иллюстрациям мы помним, что условный сервер Twitch может принять от нас видеопоток только от одного source IP адреса, значит он должен быть у нас всегда постоянным, вне зависимости от того, какие провайдеры у нас отвалились, а какие работают. Чтобы этого добиться, нам потребуется суммирующий сервер, который будет терминировать все наши подключения и объединять их в одно.
Суммирующий сервер агрегирует все каналы в один тоннель. Все подключения происходят с адреса суммирующего сервера
В такой схеме используются все провайдеры, и отключение любого из них не вызовет обрыв связи с сервером Twitch. По сути, это особый VPN-тоннель, под капотом у которого сразу несколько интернет-каналов. Главная задача такой схемы — получить максимально качественный канал связи. Если на одном из провайдеров начались проблемы, потеря пакетов, увеличение задержек, то это не должно никак отразиться на качестве связи, так как нагрузка автоматически будет распределяться по другим, более качественным каналам, которые есть в распоряжении.
Коммерческие решения
Эта проблема давно беспокоит тех, кто ведёт прямые трансляции мероприятий и не имеет доступа к качественному интернету. Для таких задач существуют несколько коммерческих решений, например компания Teradek делает такие монструозные роутеры, в которые вставляются пачки USB модемов:
Роутер для видеотрансляций с функцией суммирования каналов
В таких устройствах, обычно, встроена возможность захвата видеосигнала по HDMI или SDI. Вместе с роутером продаётся подписка на сервис суммирования каналов, а также обработки видеопотока, перекодирования его и ретрансляции дальше. Цена таких устройств начинается от 2к$ с комплектом модемов, плюс отдельно подписка на сервис.
Иногда это выглядит достаточно устрашающе:
Настраиваем OpenMPTCPRouter
Протокол MP-TCP (MultiPath TCP) придуман для возможности подключения сразу по нескольким каналам. Например, его поддерживает iOS и может одновременно подключать к удалённому серверу по WiFi и через сотовую сеть. Важно понимать, что это не два отдельных TCP-подключения, а именно одно подключение, установленное сразу по двум каналам. Чтобы это работало, удалённый сервер должен поддерживать MPTCP тоже.
OpenMPTCPRouter — это открытый проект программного роутера, позволяющего по-настоящему суммировать каналы. Авторы заявляют, что проект находится в статусе альфа-версии, но им уже можно пользоваться. Он состоит из двух частей — суммирующего сервера, который размещается в интернете и роутера, к которому подключаются несколько интернет-провайдеров и сами клиентские устройства: компьютеры, телефоны. В качестве пользовательского роутера может выступать Raspberry Pi, некоторые WiFi-роутеры или обычный компьютер. Есть готовые сборки под различные платформы, что очень удобно.
Принцип работы OpenMPTCPRouter
Настройка суммирующего сервера
Суммирующий сервер располагается в интернете и терминирует подключения со всех каналов клиентского роутера в одно. IP-адрес этого сервера будет внешним адресом при выходе в интернет через OpenMPTCPRouter.
Для этой задачи будем использовать VPS-сервер на Debian 10.
Требования к суммирующему серверу:
Результат успешной установки сервера.
Сохраняем пароли, они потребуются нам для настройки клиентского роутера, и перезагружаемся. Важно иметь в виду, что после установки SSH будет доступен на порту 65222. После перезагрузки нужно убедиться, что мы загрузились с новым ядром
Видим рядом с номером версии надпись mptcp, значит ядро установилось корректно.
Настройка клиентского роутера
На сайте проекта доступны готовые сборки для некоторых платформ, например Raspberry Pi, Banana Pi, роутеры Lynksys и виртуальные машины.
Эта часть openmptcprouter основана на OpenWRT, в качестве интерфейса используется LuCI, знакомый всем, кто когда-либо сталкивался с OpenWRT. Дистрибутив весит около 50Мб!
В качестве тестового стенда я буду использовать Raspberry Pi и несколько USB-модемов с разными операторами: МТС и Мегафон. Как записать образ на SD-карту, полагаю, не нужно рассказывать.
Изначально Ethernet-порт в Raspberry Pi настроен как lan со статическим IP-адресом 192.168.100.1. Чтобы не возиться с проводами на столе, я подключил Raspberry Pi к WiFi точке доступа и задал на WiFi-адаптере компьютера статический адрес 192.168.100.2. DHCP-сервер по умолчанию не включен, поэтому нужно использовать статические адреса.
Теперь можно зайти в веб-интерфейс 192.168.100.1
При первом входе система попросит задать пароль root, с этим же паролем будет доступен SSH.
В настройках LAN можно задать нужную подсеть и включить DHCP-сервер.
Я использую модемы, которые определяются как USB Ethernet интерфейсы с отдельным DHCP-сервером, поэтому это потребовало установки дополнительных пакетов. Процедура идентична настройке модемов в обычном OpenWRT, поэтому я не буду рассматривать её здесь.
Далее нужно настроить WAN-интерфейсы. Изначально в системе создано два виртуальных интерфейса WAN1 и WAN2. Им нужно назначить физическое устройство, в моем случае это имена интерфейсов USB-модемов.
Чтобы не запутаться в именах интерфейсов, я советую смотреть сообщения dmesg, подключившись по SSH.
Так как мои модемы сами выступают роутерами, и сами имеют DHCP-сервер, мне пришлось изменить настройки их внутренних диапазонов сетей и отключить DHCP-сервер, потому что изначально оба модема выдают адреса из одной сети, а это вызывает конфликт.
OpenMPTCPRouter требует, чтобы адреса WAN-интерфейсов были статическими, поэтому придумываем модемам подсети и настраиваем в меню system → openmptcprouter → interface settings. Здесь же нужно указать IP-адрес и ключ сервера, полученный на этапе установки суммирующего сервера.
В случае удачной настройки, на странице статуса должна появится похожая картина. Видно, что роутер смог достучаться до суммирующего сервера и оба канала работают штатно.
По умолчанию используется режим shadowsocks + mptcp. Это такой прокси, который заворачивает в себя все подключения. Изначально он настроен обрабатывать только TCP, но можно включить и UDP.
Если на странице статуса нет ошибок, на этом настройку можно считать законченной.
С некоторыми провайдерами может возникнуть ситуация, когда на пути следования трафика флаг mptcp обрезается, тогда будет такая ошибка:
В этом случае можно использовать другой режим работы, без использования MPTCP, подробнее об этом здесь.
Заключение
Проект OpenMPTCPRouter очень интересный и важный, так как это, пожалуй, единственное открытое комплексное решение проблемы суммирования каналов. Всё остальное либо наглухо закрытое и проприетарное, либо просто отдельные модули, разобраться с которыми обычному человеку не под силу. На текущем этапе развития проект ещё достаточно сырой, крайне бедная документация, многие вещи просто не описаны. Но при этом он всё-таки работает. Надеюсь, что он будет и дальше развиваться, и мы получим бытовые роутеры, которые будут уметь нормально объединять каналы из коробки.