rperf
v0.1.8
rperf — это альтернатива iperf на основе Rust, разработанная 3D-P с целью избежать некоторых проблем с надежностью и согласованностью, обнаруженных в iperf3 , одновременно предоставляя более полные данные метрик с упором на работу в устойчивой к потерям среде, более похожей на IoT. Хотя его можно использовать в качестве почти полной замены iperf , и это может иметь преимущества, его основное внимание уделяется периодическому сбору данных с помощью функции мониторинга в закрытой сети, что означает, что он подходит не для всех доменов. что iperf может служить.
rperf — это независимая реализация, ссылающаяся на алгоритмы iperf3 и zapwireless для оценки правильности и получения подходящих исправлений, но не копирующая код ни из одного из них.
В частности, наиболее важные проблемы, решаемые с помощью iperf3, следующие:
Любой сервер поддерживает несколько одновременных клиентов.
Реализация rperf RFC 1889 для расчета потокового джиттера начинается с предположения, что разница между первым и вторым пакетами в последовательности и пробелы в последовательности вызывают сброс счетчика. Для сравнения, iperf3 начинается с 0, что создает искусственно заниженные значения, а в случае пробела он просто продолжает наивно, что создает искусственно завышенные значения.
Дубликаты пакетов учитываются при обмене UDP, а пакеты с нарушением порядка считаются независимыми событиями.
Весь трафик может передаваться пропорционально с регулярными интервалами в доли секунды, что позволяет использовать конфигурации, которые более точно отражают реальные алгоритмы передачи и отправки данных.
Обмен конфигурацией потока и результатами осуществляется через выделенное соединение, и каждый путь данных имеет четко определенную семантику тайм-аута, завершения и сбоя, поэтому выполнение не зависает на неопределенный срок на любой стороне теста, когда ключевые пакеты потеряны.
Вывод JSON rperf структурно корректен. Никаких строк без кавычек, повторяющихся ключей или висячих запятых — все это требует предварительной обработки перед использованием или вызывает непредвиденные ошибки.
В отличие от zapwireless реализованы следующие улучшения:
rperf использует классическую клиент-серверную архитектуру, поэтому нет необходимости поддерживать работающий процесс на устройствах, ожидающих запроса на выполнение теста.
Джиттер рассчитывается.
IPv6 поддерживается.
В рамках теста можно запускать несколько потоков параллельно.
Доступна опция omit чтобы исключить время нарастания TCP из результатов.
Вывод доступен в формате JSON для упрощения сбора данных телеметрии.
rperf должен создаваться и работать на всех основных платформах, хотя его разработка и использование сосредоточены на системах на базе Linux, поэтому именно там он будет наиболее полнофункциональным.
Приветствуются запросы на реализацию эквивалентных функций для других систем.
Все описано в выводе --help , и большинство пользователей, знакомых с подобными инструментами, сразу почувствуют себя комфортно.
rperf работает во многом так же, как iperf3 , используя множество общих концепций и даже флагов командной строки. Одна из ключевых областей, где он отличается, заключается в том, что клиент управляет всем процессом настройки, в то время как сервер просто выполняет все свои возможности и предоставляет поток результатов. Это означает, что сервер не будет предоставлять результаты тестов непосредственно через свой интерфейс, а также что тесты TCP и UDP могут выполняться для одного и того же экземпляра, возможно, многими клиентами одновременно.
В обычном режиме работы клиент загружает данные на сервер; когда установлен reverse флаг, клиент получит данные.
В отличие от iperf3 , rperf по умолчанию не использует зарезервированный диапазон портов. Это сделано для того, чтобы он мог поддерживать произвольное количество клиентов параллельно без конкуренции за ресурсы, которые практически могут быть лишь небольшим количеством смежных портов. В предполагаемом объеме это не должно быть проблемой, но если речь идет о неразрешительных брандмауэрах и настройках NAT, параметры --tcp[6]-port-pool и --udp[6]-port-pool могут быть используется для выделения несмежных портов в набор, который будет использоваться для приема трафика.
Также не существует концепции производительности тестирования относительно фиксированного количества данных. Скорее, основное внимание уделяется измерению пропускной способности за примерно известный период времени.
Также важно то, что если сервер работает в режиме IPv6 и его хост поддерживает сопоставление IPv4 в конфигурации с двумя стеками, клиенты IPv4 и IPv6 могут подключаться к одному и тому же экземпляру.
rperf использует груз . Типичный процесс будет просто cargo build --release .
Cargo-deb также поддерживается и создаст полезный пакет Debian, который устанавливает отключенную по умолчанию службу rperf systemd . При запуске он запускается как nobody:nogroup , предполагая поддержку IPv6 по умолчанию.
Как и его современники, основная концепция rperf заключается в отправке потока данных TCP или UDP в IP-адрес с заранее установленной целевой скоростью. Объем фактически полученных данных отслеживается и используется для оценки пропускной способности сетевого канала.
Внутри этих доменов собираются и предоставляются для анализа дополнительные данные о качестве обмена.
Архитектурно rperf заставляет клиентов устанавливать TCP-соединение с сервером, после чего клиент отправляет подробную информацию о тесте, который необходимо выполнить, а сервер обязуется сообщать клиенту результаты наблюдения в течение всего процесса тестирования.
Клиент может запросить использование нескольких параллельных потоков для тестирования, чему способствует установление нескольких TCP-соединений или UDP-сокетов с собственным выделенным потоком с каждой стороны, которые могут быть дополнительно закреплены за одним логическим ядром ЦП, чтобы уменьшить влияние страницы. -сбои при обмене данными.
Отношения клиент-сервер рассматриваются как центральный аспект этой конструкции, в отличие от iperf3 , где они больше похожи на одноранговые узлы, и zapwireless , где каждый участник запускает свой собственный демон, а третий процесс организует связь.
Примечательно, что весь сбор, расчет и отображение данных происходит на стороне клиента, а сервер просто возвращает то, что он наблюдал. Это может привести к некоторому смещению записей, особенно в том, что касается времени (интервалы сервера, на несколько миллисекунд длиннее, чем соответствующие значения клиента, вовсе не редкость). Однако если предположить, что соединение не было потеряно, итоговые значения наблюдаемых данных будут совпадать во всех режимах работы.
Сервер использует три уровня потоков: один для основного потока, один для каждого обслуживаемого клиента и еще один для каждого потока, который взаимодействует с клиентом. На стороне клиента основной поток используется для связи с сервером и порождает дополнительный поток для каждого потока, который взаимодействует с сервером.
Когда сервер получает запрос от клиента, он создает поток, который обрабатывает конкретный запрос этого клиента; внутри каждый поток для теста создает обработчик, подобный итератору, с обеих сторон. И клиент, и сервер запускают эти аналоги итераторов друг против друга асинхронно до тех пор, пока не закончится период тестирования, после чего отправитель указывает на завершение в своем потоке.
Чтобы надежно справиться с возможностью отключения на уровне потока, механизм поддержания активности в потоке клиент-сервер, по которому результаты тестирования отправляются с сервера через регулярные промежутки времени, прерывает оставшиеся соединения после нескольких секунд бездействия.
Механизмы TCP и UDP хостовой ОС используются для всего фактического обмена трафиком с раскрытием некоторых параметров настройки. Этот подход был выбран вместо реализации пользовательского пространства поверх уровня 2 или уровня 3, поскольку он наиболее точно отражает поведение реальных приложений.
Значения «метки времени», видимые в данных интервала, сериализованных в формате JSON, относятся к хосту, поэтому, если ваша среда не имеет очень высокой точности системных часов, временные метки отправки следует сравнивать только с другими временными метками отправки, а также с временными метками приема. Однако в целом эти данные бесполезны за пределами проверки правильности.
В течение каждого интервала обмена предпринимается попытка отправить байты length за раз, пока объем, записанный в поток, не достигнет или не превысит целевую полосу пропускания, после чего отправитель замолкает до начала следующего интервала; данные, отправленные в течение интервала, должны быть равномерно распределены по периоду.
Индексы потоков начинаются с 0 , а не с 1 . Вероятно, это никого не удивит, но видеть в отчете «поток 0» не является поводом для беспокойства.
rperf распространяется компанией Evtech Solutions, Ltd., dba 3D-P, под лицензией GNU GPL версии 3, текст которой можно найти в COPYING .
Сведения об авторстве, особенности авторских прав и примечания о возможности передачи присутствуют в самом исходном коде.
