Введение
Мы переходим к новой методике тестирования маршрутизаторов средствами IxChariot. Ниже показана схема подключения: на компьютере, подключённом к порту WAN, работает конечная точка Chariot, на втором компьютере, подключённом к порту LAN, вторая конечная точка и консоль.
Схема подключения.
Перед тестированием мы подготавливаем маршрутизаторы следующим образом:
- обновляем прошивку;
- сбрасываем настройки по умолчанию;
- отключаем QoS (если есть);
- помещаем клиента LAN в DMZ;
- отключаем SPI
Поясним последние два пункта. Конечная точка Chariot работает как сервер, поэтому, необходимо, как минимум, открыть порты, которые она использует. Но мы просто выносим машину в DMZ. Поскольку функция DMZ представляет собой всего лишь отдельный случай перенаправления портов, то это не влияет на производительность маршрутизации.
Практически все сегодняшние маршрутизаторы поддерживают NAT с функцией SPI (Stateful Packet Inspection), поэтому Chariot чаще всего не может дать результаты на тестовую консоль через брандмауэр NAT+SPI. По этой причине нам приходится отключать SPI, если это возможно. Если первые модели маршрутизаторов с NAT+SPI показывали существенно различающуюся производительность при использовании SPI и без него, то сегодня эта проблема практически исчезла.
После такой подготовки мы проводим следующие тесты.
Пропускная способность. Измеряется, насколько быстро маршрутизатор пропускает трафик между интерфейсами. При тестировании данные отправляются с одного компьютера на другой, при этом измеряется время и вычисляется результат в Мбит/с (мегабиты в секунду).
Для тестирования мы используем скрипт Throughput.scr Chariot, в котором изменяем размер файла передачи данных со 100 000 байт до 1 000 000 байт. При этом мы проводим три тестовых измерения продолжительностью по одной минуте.
- WAN — LAN. Данные передаются с интерфейса WAN на интерфейс LAN. Это тест скорости входящего потока.
- LAN — WAN. Данные передаются с интерфейса LAN на интерфейс WAN. Это тест скорости исходящего потока.
- Одновременная передача. Сочетание двух предыдущих тестов. Этим тестом мы оцениваем, как маршрутизатор работает одновременно с входящим и с исходящим трафиками. У множества современных маршрутизаторов скорость обработки превышает 100 Мбит/с, но они не оборудованы гигабитными портами. Этим тестом мы оцениваем пределы скорости маршрутизации, выходя за пределы интерфейса 100 Мбит/с Ethernet.
Максимальное количество подключений. Здесь мы оцениваем максимальное количество одновременных подключений или сессий, поддерживаемое маршрутизатором. Для этого мы используем скрипт throughput.scr, в котором изменяем размер файла передачи данных со 100 000 байт до 1 000 000 байт.
После предварительной подготовки мы запускаем минутные тесты для 2, 32, 64, 96, 128, 160 и 180 сессий, разделив их поровну для входящего и исходящего потока. В случае неудачи, тест повторяется два раза. В некоторых случаях проводятся дополнительные тесты для получения более точного результата количества сессий.
Время отклика. Измеряется задержка (lag, latency или время ping), которая появляется после прохождения пакетом данных маршрутизатора, по сути, результат выполнения команды ping.
Мы больше не тестируем этот параметр, поскольку все сегодняшние маршрутизаторы дают время отклика менее 1 мс, то есть ниже предела измерения Chariot и других тестовых систем.
Поток UDP. Этот тест позволяет оценить, как маршрутизатор справляется с непрерывным потоком данных. То есть, возникнут ли проблемы с интернет-радио или просмотром потокового видео. Подобные сервисы используют протокол UDP, который работает без установки соединения и добавляет меньше служебной информации, чем TCP.
На данный момент мы разрабатываем новую методику оценки тестирования потоковой передачи для более точного отражения возможностей в сфере видео-потоков и IPTV.
