Предыстория
Домашние маршрутизаторы сейчас есть практически в каждом доме. Есть спрос — и есть предложение, рынок наполнен различными моделями. Сейчас в тренде гигабитные роутеры с красивой надписью «300 Мбит», и никто особенно не вдается в подробности — гигабит там, 300 Мбит или 100. Ведь в действительности 80% устройств на рынке не обеспечивают заявленных цифр: «гигабитный» маршрутизатор не выдаст честный гигабит в режиме NAT между портами WAN и LAN, а 300 Мбит вы никогда не выжмете в реальном радио-эфире.
Но есть другая, более специфичная проблема: цифры становятся особенно важны, когда мы говорим про потоковое телевидение. И важно здесь не «количество», а «качество» этих самых мегабит, по нескольким причинам.
Потоковое ТВ (далее IPTV) многие провайдеры предоставляют по multicast технологии — это снижает нагрузку на оборудование провайдера, снижает задержки, отменяет понятие буфера и вообще удобно для конечного клиентского устройства, задача которого показать картинку. Вот только при этом проявляются и все недостатки UDP — провайдер ничего не знает о том, дошёл ли необходимый пакет до конечного устройства, а конечное устройство не может перезапросить потерянный пакет. Безусловно, если потерян одиночный фрейм — протокол исправит ошибку и потеря останется незамеченной. Но если оказались потеряны несколько фреймов или ключевой фрейм — клиент увидит «рассыпание» картинки. Чем больше потерь — тем хуже качество видео. И, на практике, самым узким местом здесь оказывается именно абонентский маршрутизатор: если ЦПУ устройства слишком занято — именно приходящие UDP-пакеты отправляются в мусорное ведро в первую очередь. И там, где в онлайн игре просто немного вырастет пинг — смотреть IPTV станет уже невозможно.
Прогресс не стоит на месте. В тренде сегодня устройства с так называемым аппаратным NAT’ом — в этих девайсах connection-tracking и непосредственно операцию преобразования адресов исполняет чип, что снижает нагрузку на процессор. Однако multicast трафик не подходит под это правило и он по-прежнему обрабатывается на процессоре — это отлично видно в некоторых тестах.
Методика тестирования
Как показала практика, для выявления потенциальных проблем, описанных выше, недостаточно просто включить какой-нибудь торрент-клиент и одновременно смотреть IPTV. Был необходим набор синтетических тестов, которые однозначно определяли бы, справится ли устройство с пиковой нагрузкой.
Виды тестов
По типу физического подключения
LAN
Тесты проводились при подключении к физическим ethernet-портам устройства так, чтобы создать эмуляцию работы в обычном для маршрутизатора режиме, т.е. к WAN- и LAN- портам. Соответственно нагрузочный трафик проходил через NAT, а multicast-трафик задействовал возможности встроеной IGMP-proxy и IGMP-snooping должен был пересылать UDP-пакеты с внешнего интерфейса устройства на необходимый интерфейс конечного клиента.
WLAN
Аналог предыдущего теста, однако теперь был задействован только один ethernet порт — WAN. Клиентское же устройство было подключено по беспроводному стандарту.
Нужно отметить, что если по-началу эти тесты проводились практически для всех устройств, то со временем я от них отказался: как правило, если устройство держало нагрузку при подключении кабелем, то оно справлялось и в беспроводной сети. Здесь NAT используется так же, а тест по большей части выявляет не проблемы железа, а проблемы радио-эфира. В общем, и без меня в интернете полно тестов радио-трактов популярных роутеров.
По характеру нагрузки
Long-Connections — длинные соединения
В этом режиме при запуске нагрузки (см. выше) от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера — X. Далее клиент начинать отправлять по M пакетов в сторону сервера, а сервер — по М пакетов в сторону клиента, создавая двухстороннюю нагрузку. Время, затраченное на этот цикл — фиксируется, после чего передача повторяется. Продолжительность жизни каждого такого соединения равна продолжительности всего теста.
Short-Connections — короткие соединения
Как и в прошлом случае, при запуске нагрузки, от клиентского устройства к серверу устанавливается N соединений. Для каждого соединения устанавливается размер буфера — X. Далее клиент отправляет M пакетов в сторону сервера, сервер отправляет M пакетов в сторону клиента, после чего соединение завершается. Время, затраченное на полный цикл — фиксируется, после чего устанавливается новое соединение. Количество активных соединений поддерживается на уровне, заявленном в тесте.
По размеру буфера
64B
Буфер приема/отправки X (см. выше) выставляется в 64 байта, а количество пакетов M равно 8. В таком случае полный цикл представляет из себя передачу 512 байт сначала в одну, а потом в другую сторону.
64KB
Буфер приема/отправки X выставляется в 64 килобайта, а количество пакетов M — 1. В таком случае полный цикл представляет из себя передачу суммарно 128 Кбайт данных (64 КБ от клиента на сервер, и 64 КБ от сервера — клиенту).
По количеству одновременных соединений
Каждый тест выполнялся в 3 режимах: 10, 100 и 1000 одновременных соединений.
По максимальной скорости
Стоит так же отметить, что некоторые гигабитные модели тестировались в двух режимах: сначала все тесты проводились при включении физических портов в 100-мегабитном режиме, затем порты переводились в гигабитный режим и повторялся полный набор тестов. Зачем? Во-первых, так уж получилось, что большинство абонентов включены в 100-мегабитные порты на свитчах, и в первую очередь актуален именно такой режим работы. Ну а во-вторых, к сожалению, большинство домашних устройств, носящих гордое название «гигабитный маршрутизатор» с этим самым гигабитом не справляется. Многие из них начинают терять пакеты уже при нагрузке более 200 Мбит, некоторые, особенно удачные, справляются с потоком в 500-700 Мбит. Что уж говорить о том, что в нагрузочном тестировании при 1000 соединений с суммарным потоком в 1 гигабит об IPTV на этих устройствах можно забыть. Так или иначе, эти тесты тоже представлены в таблице — там, где рядом с названием устройства написано «(GB)».
Результаты
Все графики доступны в общей таблице, вы можете сами посмотреть их и сделать выводы.
На данный момент в таблице представлены следующие модели:
- Asus RT-AC66U
- D-Link DIR-300 (rev. B7)
- D-Link DIR-300 (rev. C1)
- D-Link DIR-615 (rev. K1)
- D-Link DIR-651 (rev. A2)
- D-Link DSR-1000N
- Huawei WS329
- TP-Link Archer C7
- TP-Link TL-WDR3500
- TP-Link TL-WDR3600 N600
- TP-Link TL-WDR3600 N600 (GB)
- TP-Link TL-WDR4300 N750
- TP-Link TL-WDR4300 N750 (GB)
- TP-Link TL-WR710N
- TP-Link TL-WR741N rev. 1.4
- TP-Link TL-WR741ND rev. 4.20
- TP-Link TL-WR840N
- TP-Link TL-WR840N rev. 1.0
- TP-Link TL-WR841N rev. 8.2
- TP-Link TL-WR841ND rev. 8.1
- Ubiquiti AirRouter
- Zyxel Keenetic — rev. A
- Zyxel Keenetic Giga
- Zyxel Keenetic Lite — rev. A
- Zyxel Keenetic Lite — rev. B
