Статус документа
Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.
Примечание IESG
Этот документ является воспроизведением RFC 1944 с корректировкой значений IP-адресов, которые были выделены для использования по умолчанию оборудованием для тестирования сетей (см. параграф C.2.2 ). Данный документ заменяет собой утративший силу RFC 1944.
Тезисы
В этом документе содержатся определения и обсуждение множества тестов, которые могут служить для определения параметров производительности устройств, используемых для соединения сетей. Кроме того, в документе описаны специфические форматы представления результатов тестирования. В Приложении A перечислены тесты и условия, которые в понимании авторов следует использовать в особых случаях, а также приведена дополнительная информация о практике тестирования. В Приложении B приведены справочные сведения о максимальных скоростях передачи кадров для различных технологий и размеров кадра. В Приложении C приведены примеры формата кадров, которые могут использоваться для тестирования.
1. Введение
Производители зачастую приукрашивают свою продукцию для ее продвижения на рынке. В стремлении занять большую часть рынка они иной раз вводят в заблуждение потенциальных пользователей своей продукции.
В этом документе определены наборы тестов, которые производители могут использовать для измерения параметров производительности сетевых устройств. Результаты таких тестов обеспечат пользователей сравнимыми данными о продукции разных компаний, которые можно использовать для оценки и выбора устройств.
Предшествующий документ "Benchmarking Terminology for Network Interconnect Devices" (RFC 1242) содержит определения множества терминов, используемых в этом документе. Рекомендуется прочесть документ, содержащий определения используемых терминов.
2. Реальный мир
При разработке этого документа авторы пытались не забывать о том, что оборудование для выполнения описываемых тестов, было реальным. Мы не знаем готового устройства, которое способно было бы выполнить все тесты, но считаем, что создать такое оборудование можно.
3. Тесты для выполнения
В этом документе рассматривается множество текстов. Не каждый из рассмотренных тестов применим ко всем типам тестируемых устройств (DUT, device under test). Производителям следует проводить все тесты, которые могут поддерживаться конкретным типом продукции. Авторы понимают, что выполнение всех тестов во всех рекомендуемых условиях потребует достаточно продолжительного времени. Мы надеемся, что результаты этих тестов послужат оправданием затраченных сил. В Приложении A перечислены некоторые тесты и условия, которые по мнению авторов следует включать в конкретных случаях.
4. Оценка результатов
Выполнение всех рекомендуемых тестов будут давать значительный объем данных. Значительная часть этих данных применима в ограниченном контексте работы устройств. Например, скорость пересылки маршрутизатором пакетов IPX не имеет существенного значения при выборе маршрутизатора для сети, в которой не поддерживается (и не будет поддерживаться) этот протокол. Выбор данных, которые имеют отношение к конкретной инсталляции, требует определенного опыта, который на практике может отсутствовать. Более того, выбор тестов и оценка результатов тестирования должны осуществляться с пониманием общих принципов тестирования в части повторяемости результатов, их погрешности и статистической значимости небольшого числа попыток.
5. Требования
В этом документе слова, задающие конкретный уровень требований выделены шрифтом. В число таких слов входят:
Должно (MUST) — это слово, а также слова требуется (REQUIRED) и нужно (SHALL) означает, что элемент является безусловно необходимым; Следует (SHOULD) — это слово, а также глагол рекомендуется (RECOMMENDED) используются в тех случаях, когда в определенных обстоятельствах требования допускается игнорировать, но делать это следует с пониманием и учетом всех обстоятельств; Возможно (MAY) — это слово, а также слово необязательно (OPTIONAL) используется для обозначения требований, выполнение которых отдается на усмотрение тестирующего; одни производители будут включать такие требования в связи с запросами рынка или по той причине, что это подчеркнет сильные стороны их продукции, а другой производитель может игнорировать такие требования.
Реализация, в которой не выполняется одно или несколько обязательных требований (должно — MUST), считается «не соответствующей» требованиям. Реализация, в которой выполняются все обязательные требования и рекомендации, считается «полностью соответствующей» требованиям, а реализация, в которой выполнены все обязательные требования, но не выполняется часть рекомендаций, считается «условно соответствующей».
6. Организация теста
Идеальным вариантом реализации описанной здесь последовательности тестов является использование тестера с приемным и передающим портом. Передающий порт тестера соединяется с приемным портом DUT, а передающий порт DUT подключается к приемному порту тестера (Рисунок 1). Поскольку тестер в этом случае будет передавать данные и принимать их обратно после пересылки тестируемым устройством (DUT), тестер легко может проверить все ли переданные пакеты были получены обратно и убедиться в корректности принятых пакетов. Такая же функциональность может быть достигнута при использовании раздельных устройств для передачи и приема данных (Рисунок 2), но пока эти устройства не контролируются удаленно неким компьютером для имитации единого тестера, некоторые тесты, требующие точности (в частности, проверка пропускной способности), не могут быть выполнены.
> +------------+
| |
+------------| tester |<-------------+
| | | |
| +------------+ |
| |
| +------------+ |
| | | |
+----------->| DUT |--------------+
| |
+------------+
Рисунок 1
+--------+ +------------+ +----------+ | | | | | | | sender |-------->| DUT |--------->| receiver | | | | | | | +--------+ +------------+ +----------+ Рисунок 2
6.1. Организация теста для разнотипных сред
При тестировании DUT, которые используются в реальных сетях для подключения к разнотипным средам (например, ЛВС Ethernet к магистрали FDDI), могут использоваться два варианта конфигурации. Тестер может поддерживать оба типа сред и в этом случае может использоваться конфигурация, показанная на рисунке 1.
В другом варианте используется два идентичных DUT (Рисунок 3). Во многих случаях такая конфигурация может более точно имитировать реальные ситуации. Примером может служить соединение двух ЛВС по каналу WAN или высокоскоростной магистрали. Однако такая конфигурация не будет в должной мере соответствовать случаям, когда клиенты из ЛВС Ethernet взаимодействуют с сервером на магистрали FDDI.
+-----------+
| |
+---------------------| tester |<---------------------+
| | | |
| +-----------+ |
| |
| +----------+ +----------+ |
| | | | | |
+------->| DUT 1 |-------------->| DUT 2 |---------+
| | | |
+----------+ +----------+
Рисунок 3
7. Настройка DUT
До начала тестирования устройство DUT должно быть настроено в соответствии с инструкциями для пользователей. В частности, предполагается, что все поддерживаемые протоколы настроены и включены перед организацией теста (см. Приложение A). Предполагается, что все тесты будут выполняться без изменения настроек DUT за исключением выполнения требований соответствующих тестов. Например, недопустимо изменение размера буферов, обслуживающих кадры, в интервале между тестами, определяющими скорости обработки кадров, или запрет всех прочих транспортных протоколов во время тестирования одного протокола. Конфигурацию требуется менять при определении влияния фильтров на пропускную способность, но единственным изменением должно быть включение соответствующего фильтра. При настройке DUT следует задавать рекомендуемое значение интервала обновления маршрутных данных и частоты передачи сообщений keep alive. Номера версий используемых программ и точная конфигурация DUT (включая запрет тех или иных функций) в процессе тестирования должны быть включены в отчет о результатах тестирования.
8. Форматы кадров
Форматы тестовых кадров Ethernet для тестирования TCP/IP показаны в Приложении C. Такой формат кадров следует использовать в описанных здесь тестах для данной комбинации протокол-среда и применять в качестве шаблонов при тестировании в других комбинациях протоколов и сред. Специфические форматы, используемые в конкретном наборе тестов, должны включаться в отчет о результатах тестирования.
9. Размеры кадров
Все описанные здесь тесты следует выполнять с множеством разных размеров кадра. В частности, следует проводить тесты с кадрами минимального и максимального допустимого для среды размера, чтобы получить полный набор характеристик работы DUT. Если явно не указано иное, для каждых условий тестирования следует использовать не менее пяти разных размеров кадра.
Теоретически минимальный кадр запроса UDP Echo будет содержать заголовок IP (не менее 20 октетов), заголовок UDP (8 октетов) и заголовок уровня MAC в соответствии с требованиями среды. Теоретический максимум для размера кадра определяется размером поля длины в заголовке IP. Почти во всех случаях значения минимального и максимального размера кадров задаются ограничениями среды.
В теории идеальным вариантом было бы такое распределение размеров кадров, которое бы обеспечило равномерное распределение теоретических значений скорости передачи кадров. В настоящих рекомендациях учитывается эта теория, но приводятся размеры кадров, которые просто понять и запомнить. Кроме того, рекомендуемые размеры кадров для разных сред позволяют легко сравнить параметры производительности.
Примечание: включение нереально малых размеров кадра (кадры, не способные передавать какие-либо данные) в некоторых типах сред обусловлено желанием получить параметры загрузки, порождаемой обработкой кадров в DUT.
9.1. Размеры кадров Ethernet
64, 128, 256, 512, 1024, 1280, 1518
Приведенные значения включают минимальный и максимальный размер кадров, допускаемых стандартом Ethernet, и промежуточные значения с более тонкой гранулярностью для малых размеров кадра и высоких скоростей передачи кадров.
9.2. Размеры кадров Token Ring 4/16 Мбит/с
54, 64, 128, 256, 1024, 1518, 2048, 4472
Рекомендации по размерам кадров Token Ring предполагают отсутствие поля RIF в кадрах маршрутизируемых протоколов. Поле RIF будет присутствовать во всех тестах производительности мостов source route. Минимальный размер кадра для UDP в сети Token Ring составляет 54 октета. Для Token Ring 16 Мбит/с рекомендуется максимальный размер в 4472 октета вместо теоретического максимума 17,9 кбайт, поскольку многие интерфейсы Token Ring вносят такое ограничение. Остальные рекомендуемые значения выбраны для обеспечения возможности прямого сравнения между двумя разными типами сред. В дополнение могут использоваться кадры IP (т. е., не UDP), если желательно обеспечить наиболее высокую скорость передачи кадров, требующую снижения размера кадров до 46 октетов.
9.3. Размеры кадров FDDI
54, 64, 128, 256, 1024, 1518, 2048, 4472
Минимальный размер кадра для UDP в среде FDDI составляет 53 октета, но рекомендуется использовать минимальный размер 54, обеспечивающий возможность прямого сравнения с Token Ring. В качестве максимального размера рекомендуется использовать 4472 октета взамен рекомендуемого значения 4500, чтобы обеспечить возможность прямого сравнения с Token Ring. При необходимости обеспечить наиболее высокую скорость передачи кадров, можно использовать пакеты IP (т. е., не UDP), позволяющие сократить размер кадра до 45 октетов.
9.4. Размеры кадров в присутствии несоразмерных MTU
Когда соединенные между собой DUT поддерживают соединительные каналы с несовпадающими значениями MTU, следует использовать размер кадра для канала с «большим» MTU, вплоть до значения. Ограничиваемого протоколом. Если соединенные между собой DUT не поддерживают фрагментации кадров в случае несовпадения MTU, для соответствующего размера кадров в отчете следует указывать нулевую скорость пересылки.
Например, тестирование пересылки IP мостом или маршрутизатором, связывающим сети FDDI и Ethernet, следует использовать размеры кадров FDDI при передаче из сети FDDI в канал Ethernet. Если мост не поддерживает фрагментации IP, скорость пересылки кадров, которые слишком велики для Ethernet, следует указывать в отчете с нулевым значением.
10. Проверка полученных кадров
Тестовому оборудованию следует отбрасывать все полученные во время теста кадры, которые не относятся к тестированию. Например, кадры keep-alive и кадры маршрутных обновлений не следует включать в число принятых кадров. Во всех случаях тестовому оборудованию следует проверять размер принятых кадров на предмет соответствия ожидаемому значению.
Тестовому оборудованию следует включать в передаваемые кадры порядковые номера и проверять эти номера в принимаемых кадрах. Если порядковые номера используются, в отчет следует включать число отброшенных кадров, число кадров, доставленных с нарушением порядка, число полученных дубликатов, а также число пропусков в порядковых номерах принятых пакетов. Такая функциональность требуется для некоторых тестов из числа описанных.
11. Изменение условий тестирования
Информация о работе DUT в разных условиях может оказаться весьма полезной; некоторые из таких условий отмечены ниже. В отчеты о результатах следует включать столько таких условий, сколько может сгенерировать тестовое оборудование. Набор тестов следует использовать сначала без варьирования условий, а потом повторять, меняя каждое условие отдельно. Для сохранения возможности сравнения результатов таких тестов все кадры, которые нужно генерировать в измененных условиях (например, запросы управления), будут включаться в тот же поток данных, что и обычные тестовые кадры, взамен одного из тестовых кадров и не будут передаваться DUT через отдельный сетевой порт.
11.1. Широковещательные кадры
В большинстве маршрутизаторов требуется специальная обработка при получении кадров в аппаратным широковещательным адресом. В мостах (или маршрутизаторах, работающих в режиме моста) такие широковещательные кадры должны рассылаться во множество портов. В поток тестовых кадров следует добавлять 1% кадров с аппаратными широковещательными адресами. По широковещательному адресу следует слать кадры такого типа, который не требуется обрабатывать с помощью маршрутизатора. Целью включения таких кадров является определение наличия любого воздействия этих кадров на скорость пересылки других данных в потоке. Конкретные кадры, которые следует использовать, включены в описание форматов тестовых кадров. Широковещательные кадры следует равномерно размещать в потоке данных (например, каждый 100-й кадр является широковещательным).
Такой же тест следует выполнять на подобных мостам DUT, но в этом случае широковещательные пакеты будут обрабатываться и пересылаться во все выходные порты.
Понятно, что уровень широковещательных пакетов в 1% значительно превышает реальное значение для многих сетей, но такой высокий уровень необходим для получения эффекта, который иначе не может быть получен при нормальных условиях работы. По конструктивным причинам часть тестового оборудования неспособна создавать столь низкую частоту чередования кадров. В таких случаях процент широковещательных кадров следует делать настолько малым, насколько позволяет тестовое оборудование, а реальную долю широковещательных следует включать в отчет.
11.2. Кадры управления
Большинство сетей передачи данных использует протоколы управления типа SNMP. Во многих средах может использоваться множество станций, одновременно передающих запросы одному устройству DUT.
Поток тестовых кадров следует дополнять одним запросом управления в качестве первого кадра каждой секунды в течение проверки. Результат запроса должен помещаться в кадр отклика. Кадры откликов следует проверять в тестовом оборудовании. Пример конкретного формата кадров, которые следует использовать, дан в Приложении C.
11.3. Кадры маршрутных обновлений
Обработка обновлений протоколов динамической маршрутизации может оказывать существенное влияние на способность маршрутизатора пересылать кадры данных. В поток тестовых кадров следует добавлять один кадр с маршрутными обновлениями, передаваемый в качестве первого кадра в испытании.
Кадры маршрутных обновлений следует передавать с частотой, указанной в Приложении C для конкретного протокола, который будет использоваться при тестировании. В Приложении C приведены два примера кадров маршрутных обновлений для использования TCP/IP в среде Ethernet. Кадры обновлений предназначены для обновления маршрутизации во множество сетей, которые не участвуют в пересылке тестовых данных. Первый кадр устанавливает таблицу маршрутизации в состояние A, а второй переводит ее в состояние B. Кадры должны чередоваться в течение испытания.
В процессе тестирования следует удостовериться, что маршрутные обновления были обработаны устройством DUT.
11.4. Фильтры
Фильтры используются в маршрутизаторах и мостах для селективного запрета пересылки пакетов. Обычно фильтрация служит для реализации мер защиты на границе между областями (сетями). Возможности фильтрации существенно различаются в разной продукции.
Устройство DUT следует сначала настроить с заданием одного фильтра, разрешающего пересылку тестовых данных и после этого выполнить тест. Для маршрутизаторов следует использовать фильтры вида:
forward input_protocol_address to output_protocol_address
Для мостов следует использовать фильтры вида:
forward destination_hardware_address
После этого для DUT следует задать 25 фильтров. Для первых 24 фильтров следует использовать форму:
block input_protocol_address to output_protocol_address
Для 24 входных и выходных протокольных адресов не следует использовать какие-либо адреса, присутствующие в тестовом потоке данных. В последнем фильтре следует разрешить пересылку тестового потока данных. Порядок включения фильтров выбран таким, чтобы выполнялось 25 проверок до принятия решения о пересылке кадра. Если DUT меняет порядок фильтров или не использует линейного просмотра правил, упорядочение фильтров при вводе будет утрачено.
Точную конфигурацию фильтров следует включать в отчет о результатах тестирования.
11.4.1 Адреса в фильтрах
Для фильтров требуется два набора адресов — один для случая с одним фильтром и другой для 25 фильтров.
Одиночному фильтру следует разрешать трафик с IP-адреса 198.18.1.2 на адрес 198.19.65.2 и отвергать весь остальной трафик.
В случае с 25 следует использовать приведенный набор фильтров.
deny aa.ba.1.1 to aa.ba.100.1 deny aa.ba.2.2 to aa.ba.101.2 deny aa.ba.3.3 to aa.ba.103.3 ... deny aa.ba.12.12 to aa.ba.112.12 allow aa.bc.1.2 to aa.bc.65.1 deny aa.ba.13.13 to aa.ba.113.13 deny aa.ba.14.14 to aa.ba.114.14 ... deny aa.ba.24.24 to aa.ba.124.24 deny all else
Перед вводом фильтров следует удалить из маршрутизатора все ранее заданные фильтры. Выбранная последовательность позволяет понять, сортирует маршрутизатор правила фильтрации или принимает их в порядке ввода. Обе эти процедуры будут оказывать большее влияние на производительность, нежели та или иная форма хэширования.
12. Протокольные адреса
Реализация тестов упрощается при использовании одного логического потока данных с одним протокольным адресом отправителя и одним протокольным адресом получателя, а также некоторых условий типа описанных выше фильтров. Реальные сети не ограничиваются единственным потоком данных. Набор тестов следует выполнять сначала для одной пары протокольных (аппаратных для моста) адресов отправителя и получателя. После этого следует повторить тесты с использованием случайных адресов получателей. При тестировании маршрутизаторов адреса следует случайно или равномерно распределять в диапазоне 256 сетей, а при тестировании мостов случайно или однородно распределять по полному диапазону значения MAC для моста. Конкретные диапазоны адресов при тестировании IP даны в Приложении C.
13. Организация маршрутов
Неразумно устанавливать вручную все маршрутные параметры, требуемые для пересылки тестового потока, особенно в случаях использования множества адресов. При запуске каждого теста устройству DUT должно передаваться обновление маршрутных данных. Это обновление должно включать все сетевые адреса, которые потребуются при тестировании. Все эти адреса следует преобразовывать в один следующий интервал маршрутизации. Обычно это адрес приемной части тестового оборудования. Обновление маршрутных данных следует повторять через интервалы, определяемые используемым протоколом маршрутизации. Пример формата кадров обновлений и сведения об интервалах обновления приведены в Приложении C.
14. Двунаправленный трафик
Обычный сетевой трафик передается в двух направлениях. Для тестирования двунаправленной работы DUT следует выполнять тесты с одинаковой скоростью данных для каждого направления. Суммарная скорость потоков данных от каждого из тестов в одном направлении не должна превосходить теоретические возможности среды.
15. Один путь для потока
Следует выполнять полный набор тестов во всех подходящих условиях с использованием одного входного и выходного порта DUT. Если в устройстве DUT имеется множество разных путей (например, множество интерфейсных плат с множеством сетевых портов на каждой), следует тестировать каждый путь по отдельности.
16. Множество портов
Многие современные мосты и маршрутизаторы поддерживают множество сетевых портов на одном модуле. При тестировании первая половина портов назначается входными, а вторая — выходными портами. Порты следует распределить равномерно с учетом архитектуры DUT. Например, для DUT с двумя сетевыми платами, каждая из которых имеет по четыре порта, два порта каждой платы назначаются входными, а два других порта — выходными. Заданные тесты выполняются с использованием одинаковой скорости для каждого из входных портов. Адреса во входящем потоке данных следует устанавливать так, чтобы кадры поочередно направлялись в каждый из выходных портов с примерно равным распределением между ними. Такая же конфигурация может использоваться для двунаправленного многопотокового теста. В этом случае все порты рассматриваются как входные и выходные и каждый поток данных должен включать кадры, адресованные во все порты.
Рассмотрим 6-портовое устройство DUT, показанное на рисунке.
--------------
---------| in A out X|--------
---------| in B out Y|--------
---------| in C out Z|--------
--------------
Для потоков данных следует задавать показанную ниже адресацию:
- поток, передаваемый на вход A:
- пакеты в выходные интерфейсы X, Y, Z
- поток, передаваемый на вход B:
- пакеты в выходные интерфейсы X, Y, Z
- поток, передаваемый на вход C
- пакеты в выходные интерфейсы X, Y, Z
Отметим, что во всех этих потоках используются одинаковые последовательности, поэтому сначала будут одновременно приходить 3 пакета на интерфейс X, затем 3 на интерфейс Y и после этого — 3 на Z. Такая процедура обеспечивает близкое соответствие реальным сетям и DUT будет иметь дело одновременно с множеством пакетов, адресованных в один выход.
17. Множество протоколов
В этом документе не рассматриваются вопросы тестирования эффектов многопротокольных сред. Если такое тестирование желательно провести, кадры следует распределять между всеми участвующими в тесте протоколами. Распределение может аппроксимировать условия в сетях, где будет использоваться DUT.
18. Множество размеров кадров
В этом документе не рассматривается тестирования эффектов использования сред со смешанными размерами кадров. Если такие тесты нужны, размеры кадров следует распределять между всеми значениями, перечисленными для тестируемого протокола. Распределение может аппроксимировать условия реальных сетей, в которых будет применяться DUT. У авторов нет никаких идей по поводу интерпретации результатов таких тестов за исключением прямого сравнения результатов для нескольких DUT, полученных для однотипных условий.
19. Тестирование более одного DUT
Парадигма тестирования одиночного DUT может быть описана как передача данных на вход DUT и мониторинг выхода. Результаты могут использоваться для формирования базовых характеристик устройства в заданных параметрами теста условиях.
Эта модель полезна в тех случаях, когда кадры на входе и выходе однотипны (например, 64-байтовые пакеты IP в кадрах 802.3 на входе и выходе DUT) или метод тестирования может различать разнотипные входы и выходы (например, 1518-байтовые пакеты IP в кадрах 802.3 на входе и 576-байтовые фрагменты IP в кадрах X.25 на выходе).
При расширении теста для случая нескольких DUT могут собираться результаты, относящиеся ко множеству DUT или гетерогенным средам. В таком расширенном тесте одно устройство DUT заменяется системой соединенных через сеть DUT. Такая методология позволяет тестировать множество комбинаций из устройств/сред/протоколов/служб. Например, конфигурация теста ЛВС-WAN-ЛВС может иметь вид:
(1) 802.3-> DUT 1 -> X.25 @ 64кбит/с -> DUT 2 -> 802.3
Или может тестироваться смешанная конфигурация ЛВС:
(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
В обоих примерах (1 и 2) можно эмпирически оценить сквозные параметры каждой системы. Для оценки других параметров могут служить промежуточные устройства. В примере 2 можно оценить возможности передачи данных между сетями FDDI через DUT 2.
Поскольку множество DUT трактуется как единая система, у такой методологии имеются ограничения. Например, можно получить агрегированные параметры для тестируемой системы в целом, однако результаты теста могут не отражать асимметрию поведения устройств DUT, задержки, вносимые другими устройствами (например, CSU/DSU, коммутаторами) и т.п.
Кроме того, при сравнении результатов таких тестов следует обращать внимание на различия возможностей/конфигураций устройств DUT в тестируемых системах.
20. Максимальная скорость передачи кадров
В качестве максимальных скоростей передачи кадров при тестировании соединений ЛВС следует использовать перечисленные в документе теоретически предельные значения для соответствующего размера кадров.
В качестве максимальных скоростей передачи кадров при тестировании соединений WAN следует использовать значения, превышающие указанную в документе теоретически максимальные значения скорости для соответствующего размера кадров. Более высокая скорость при тестировании WAN используется для компенсации компрессии заголовков, используемой многими производителями.
Список максимальных скоростей передачи кадров для соединений ЛВС приведен в Приложении B.
21. Пиковый трафик
Измерять производительность DUT удобно при стабильной загрузке, однако такие тесты не будут отражать работу DUT в реальных сетях, поскольку трафик в сети обычно представляет собой чередующиеся выбросы трафика. Некоторые из описанных ниже тестов следует выполнять при установившемся уровне трафика, а также при трафике, представляющем собой последовательность пиков. Кадры в пиках передаются с минимально допустимым временным интервалом.
Задачей такого теста является определение минимального интервала между пиками, при котором DUT еще сможет обрабатывать трафик без потери пакетов. В процессе тестирования число пакетов в каждом пике сохраняется постоянным, а варьируется интервал между пиками. Тесты следует выполнять для пиков, содержащих 16, 64, 256 и 1024 кадра.
22. Число кадров на маркер
Несмотря на возможность настройки некоторых интерфейсов Token Ring и FDDI для передачи более одного кадра на каждый принятый маркер, большинство доступных в настоящее время устройств передают по одному кадру на маркер. При тестировании следует сначала выполнить проверку в таком режиме (один кадр на маркер).
Некоторые современные высокопроизводительные серверы передают более одного кадра на маркер для повышения производительности сетей FDDI. Поскольку в будущем такое поведение может стать общепринятым для рабочих станций и серверов, сетевые устройства с интерфейсом FDDI следует тестировать в режимах передачи с 1, 4, 8 и 16 кадрами на маркер. В отчете следует указывать среднюю скорость передачи кадров за все время тестирования.
23. Описание испытания
Каждый тест состоит из множества испытаний, каждое из которых возвращает некий набор информации (например, частота потери кадров для заданного входного потока). Каждое испытание состоит из нескольких фаз:
Если DUT представляет собой маршрутизатор, сначала передается обновление маршрутных данных на «входной» порт и задается пауза в две секунды для пересчета маршрутов.
Передаются «кадры обучения» в «выходной порт» и устанавливается пауза в две секунды для завершения самообучения моста. Обучающие кадры для моста представляют собой кадры, в которых адреса отправителя совпадает с адресом получателя, используемым в тестовых кадрах. Кадры обучения для других протоколов служат для заполнения таблицы преобразования адресов в DUT. Для эти кадров следует использовать форматы, указанные в документе Test Frame Formats.
Выполняется испытание.
Устанавливается пауза в две секунды для получения всех остающихся в сети кадров.
Устанавливается пауза не менее пяти секунд для стабилизации DUT.
24. Продолжительность испытания
Целью этих тестов является определение скорости, непрерывно поддерживаемой DUT. Продолжительность каждого испытания определяется как компромисс между достижением этой цели и временем, затрачиваемым на выполнение всего набора тестов. Продолжительность каждого испытания следует задавать не менее 60 секунд. Тесты, включающие ту или иную форму бинарного поиска (например, проверка пропускной способности) для получения точного результата могут использовать сокращенные испытания для минимизации продолжительности поиска, но окончательное определение следует выполнять при полной продолжительности попыток.
25. Преобразование адресов
Устройствам DUT следует поддерживать отклики на запросы преобразования, передаваемые DUT в соответствии с требованиями протокола.
26. Тестирование производительности
Примечание: Слова «тип потока данных» говорят об описанных выше модификациях потока кадров с постоянным межкадровым интервалом (например, добавление фильтров трафика в конфигурацию DUT.
26.1. Пропускная способность
- Цель:
- Определение пропускной способности DUT в соответствии с RFC 1242.
- Процедура:
Через DUT передается заанное число кадров с указанной скоростью и определяется число кадров, переданных DUT. Если счетчик переданных DUT кадров совпадает с числом принятых, скорость увеличивается и испытание повторяется. Если число переданных кадров меньше числа пропущенных, испытание повторяется после снижения скорости.
Пропускная способность определяется максимальной скоростью, при которой число кадров, переданных DUT, еще равно числу кадров, переданных тестовым оборудованием.
- Описание результатов:
- Результаты теста пропускной способности следует представлять в виде графика. В этом случае по оси x следует указывать размер кадров, а по оси y — скорость передачи кадров. На графике следует указывать по крайней мере две линии, одна из которых показывает теоретическое значение скорости передачи кадров разного размера для данного типа среды. С помощью второй линии следует показывать реальные результаты теста. Можно также выводить дополнительные графики, показывающие результаты теста для разных типов потока данных. В сопровождающем график тексте следует указывать протокол, тип потока данных и тип среды, использованные при тестировании.
Мы предполагаем, что если для рекламных целей требуется одно значение производительности, производитель будет выбирать минимальный размер кадров для среды. В таких случаях результат должен выражаться числом кадров в секунду. Скорость также может указываться в битах (или байтах) в секунду. Заявленная производительность должна включать: a) измеренное значение максимальной скорости передачи кадров, b) размер использованных кадров, c) теоретический предел скорости для данной среду при использованном размере кадров и d) протокол, использованный для тестирования. Даже в тех случаях, когда для рекламных целей используется одно значение в описание продукции следует включать всю таблицу результатов тестирования пропускной способности.
26.2. Задержка
- Цель:
- Определение задержки в соответствии с RFC 1242.
- Процедура:
- Сначала определяется пропускная способность DUT для каждого размера кадров из списка. После этого через DUT передается поток кадров заданного размера с определенной полосой (пропускная способность), адресованных одному получателю. Продолжительность потока следует делать не менее 120 секунд. После 60 секунд испытания в поток следует включить идентификационную метку, тип которой зависит от реализации. Время завершения передачи этой метки фиксируется (время A). Логика приемной части тестера должна распознавать метку в потоке кадров и фиксировать время завершения приема кадра с меткой (время B).
Задержка составляет разницу значений B и A в соответствии с определением RFC 1242 (а именно, задержка для устройств пересылки или пересылки с промежуточным сохранением).
Тест должен повторяться не менее 20 с указанием в отчете среднего значения всех полученных задержек.
Для маркера следует использовать тот же адрес получателя, который задан для остальных кадров потока при этот для каждого испытания следует задавать новый адрес получателя.
- Описание результатов:
- В отчете должно быть указано, какое из определений задержки (из RFC 1242) было использовано при тестировании. Данные по задержкам следует представлять в формате таблицы, строки которой содержат значения задержки для каждого размера кадров, использованного в испытаниях. В таблицу следует включить колонки для размера кадров, скорости передачи данных во время теста для данного размера кадров и значения задержки.
26.3. Частота потери кадров
- Цель:
- Определение частоты потери кадров в соответствии с RFC 1242 во всем диапазоне скоростей данных на входе и размеров кадра.
- Процедура:
Передается заданное число кадров с заданной скоростью через устройство DUT и подсчитывается число кадров на выходе DUT. Частота потери кадров для каждого порта рассчитывается по формуле:
((input_count — output_count) * 100) / input_count
Первое испытание следует проводить при максимальной скорости для данного размера кадров во входной среде. При следующих испытаниях скорость снижается сначала до 90% от максимальной скорости, а затем до 80%. Снижение скорости на 10% следует повторять, пока не будет зафиксировано два результата без потери кадров. Гранулярность снижения скорости должна быть не более 10% от максимальной скорости; приветствуется снижение скорости с меньшим шагом.
- Описание результатов:
- Результаты определения частоты потери кадров следует представлять в форме графика. В этом случае по оси X должна указываться скорость передачи кадров на входе в процентах от теоретического максимума для данной среду при конкретном размере кадров. По оси Y должны указываться потери кадров в процентах. Начальные точки обеих осей должны соответствовать нулевым значениям, а конечные — 100 %. На графике могут выводиться несколько линий, соответствующих потерям кадров различного размера, разных протоколов и типов потока данных.
Примечание: В разделе 18 рассмотрены максимальные значения скорости передачи кадров, которые следует использовать.
26.4. Кадры, передаваемые с минимальными интервалами
- Цель:
- Определение возможностей DUT по обработке кадров back-to-back в соответствии с определением RFC 1242.
- Процедура:
Устройству DUT передается пакет кадров с минимальными межкадровыми интервалами и подсчитывается число кадров, пересланных устройством DUT. Если число переданных кадров совпадает с числом пересланных устройством на протяжении всего пика, пакет кадров увеличивается и испытание повторяется. Если число пересланных устройством кадром меньше числа переданных, размер пакета уменьшается и испытание повторяется.
Значение back-to-back определяется числом кадров в максимальном пакете, который устройство DUT смогло обработать без потери кадров. Продолжительность испытания должна быть не менее 2 секунд, а испытания следует повторять не менее 50 раз с усреднением значений.
- Описание результатов:
- Результаты теста back-to-back следует представлять в форме таблицы со строкой для каждого размера кадров, использованного при тестировании. В таблицу следует включать колонки размера кадров и среднего числа кадров в пакете для каждого типа потока данных. Можно также указывать в отчете величину стандартного отклонения для каждого измерения.
26.5. Восстановление системы
- Цель:
- Определение скорости восстановления DUT после перегрузки.
- Процедура:
Сначала определяется пропускная способность DUT для каждого из перечисленных размеров кадра.
Передается поток кадров со скоростью 110% от пропускной способности или максимальной скоростью среды (выбирается меньшее из 2 значений) в течение по крайней мере 60 секунд. В момент A интенсивность трафика снижается вдвое и записывается момент последней потери кадра (момент B). Время восстановления системы определяется как разность времен B и A. Тест следует повторить многократно и включить в отчет среднее время восстановления.
- Описание результатов:
- Результаты тестирования времени восстановления системы следует приводить в форме таблицы со строками для каждого размера кадров, использованного при тестировании. В колонках таблицы следует указывать размеры кадров, скорость передачи кадров для каждого типа потоков данных и измеренное время восстановления для каждого типа потоков данных в тесте.
26.6. Перезагрузка
- Цель:
- Определение скорости восстановления DUT после программного или аппаратного сброса (перезагрузки).
- Процедура:
Сначала определяется пропускная способность DUT для кадров минимального размера в соответствии с используемой для тестирования средой.
Передается непрерывный поток кадров с определенной пропускной способностью для минимального размера кадров. Выполняется сброс DUT с мониторингом выходного порта с записью времени последнего кадра перед сбросом (момент A) и первого кадра после сброса (момент B). При тестировании сброса по прерыванию питания выполняются такие же операции, но перезагрузка заменяется отключением питания DUT на 10 секунд.
Этот тест следует проводить только с использованием кадров, адресованных в сети, подключенные непосредственно к DUT, чтобы не возникало задержек, связанных с обновлением маршрутной информации после сброса.
Время перезагрузки определяется как разность между моментами B и A.
При тестировании следует выполнять программный и аппаратный сброс, а также сброс по отключению питания.
- Описание результатов:
- Значение времени перезагрузки следует для всех проверенных вариантов сброса устройства.
27. Вопросы безопасности
Вопросы безопасности не рассматриваются в этом документе.
Адреса редакторов
Scott Bradner
Harvard University
1350 Mass. Ave, room 813
Cambridge, MA 02138
Phone: +1 617 495-3864
Fax: +1 617 496-8500
EMail: ude.dravrah@bos
Jim McQuaid
NetScout Systems
4 Westford Tech Park Drive
Westford, MA 01886
Phone: +1 978 614-4116
Fax: +1 978 614-4004
EMail: moc.tuocsten@jdiauqcm
Приложение A: Рассмотрение тестов
A.1. Роль этого приложения
В этом приложении рассматриваются некоторые вопросы методологии тестирования, когда опыт или мнение могут играть роль при выборе испытаний или конфигурации теста для отдельного DUT. В любом случае это приложение не должно трактоваться как исправление методологии, описанной в основной части документа; оно является практическим руководством по тестированию.
Обычной практикой при тестировании является разрешение всех протоколов, которые будут тестироваться, и выполнение всех тестов без дополнительной настройки протоколов даже в тех случаях, когда для конкретного испытания нужен единственный протокол. Такой подход позволяет минимизировать работы при настройке DUT для каждого протокола.
Следует использовать наиболее распространенные функции фильтрации для обеспечения возможности сравнения тестов продукции разных производителей. В силу различий между продукцией, выполнение таких тестов и оценка их результатов могут зависеть от конкретного мнения по этому вопросу.
Нужно принимать во внимание вопросы архитектуры. Примером может служить выполнение теста с потоком трафика между портами одной интерфейсной платы и повторение тестов с портами разных интерфейсных плат. Почти во всех случаях эти две конфигурации относятся к лучшему и худшему варианту конфигурации теста для данной архитектуры DUT.
Тестирование с использованием потоков трафика, содержащего множество протоколов, не показывает существенных отличий от тестирования с применением монопротокольного трафика. Т. е., если результаты тестирования производительности для протоколов A и B различаются, тестирование при использовании смешанного трафика будет давать промежуточный результат.
Производительность сетей WAN может тестироваться путем установки двух идентичных устройств, соединенных с помощью модемов для имитации каналов WAN. Производительность измеряется между интерфейсами ЛВС двух устройств DUT.
Максимальная скорость передачи кадров в конфигурации ЛВС-WAN-ЛВС определяется оценкой, которая может быть основана на известных характеристиках системы в целом, включая эффекты компрессии, фрагментацию и скорость канала. На практике для скорости следует устанавливать значение не менее 110% от скорости самого медленного канала. Отдельное тестирование системы компрессии выходит за пределы данного документа.
Приложение B: Максимальные скорости передачи кадров
(Предоставил Roger Beeman, Cisco Systems)
Size Ethernet 16Mb Token Ring FDDI
(bytes) (pps) (pps) (pps)
64 14880 24691 152439
128 8445 13793 85616
256 4528 7326 45620
512 2349 3780 23585
768 1586 2547 15903
1024 1197 1921 11996
1280 961 1542 9630
1518 812 1302 8138
Размер кадров Ethernet
Preamble 64 bits
Frame 8 x N bits
Gap 96 bits
Размер кадров Token Ring 16 Мбит/с
SD 8 bits
AC 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
RI 48 bits ( 06 30 00 12 00 30 )
SNAP
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 8 bits
FS 8 bits
Маркеры и кадры бездействия (idle) между пакетами не указаны.
Размер кадров FDDI
Preamble 64 bits
SD 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
SNAP
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 4 bits
FS 12 bits
Приложение C: Форматы тестовых кадров
В этом приложении описаны форматы кадров, которые могут использоваться для тестирования. Кроме того, здесь приведены параметры TCP/IP в сетях Ethernet при использовании для тестирования.
C.1. Введение
Общая логика выбора параметров и форматов кадров для каждого случая рассматривается в разделе TCP/IP. Такая же логика используется и в других разделах. Комментарии приводятся лишь в тех случаях, когда нужно разъяснить специфику конкретного протокола. Параметры и форматы кадров для других протоколов пользователь может по аналогии определить самостоятельно.
C.2. Информация TCP/IP
В последующих параграфах приведена информация, связанная со стеком протоколов TCP/IP.
C.2.1. Тип кадров
Для протоколов, поддерживающих эхо-запросы прикладного уровня, при тестировании используются кадры с дейтаграммами таких запросов. Протокол передачи дейтаграмм используется для того, чтобы маршрутизатор не ожидал получения соответствующих инициализационных последовательностей, как в случаях использования потоковых протоколов с гарантированной доставкой данных. Конкретный протокол задается по той причине, что некоторые маршрутизаторы минимизации проверяют поле протокола в заголовке и могут отбрасывать пакеты неизвестных протоколов.
Для TCP/IP используются UDP-дейтаграммы Echo Request.
C.2.2. Протокольные адреса
Нужно определить два набора адресов — первый используется для присвоения портам маршрутизатора, а второй указывается в тестовых кадрах и маршрутных обновлениях.
Для этой цели агентством IANA были выделены сетевые адреса с 192.18.0.0 по 198.19.255.255, закрепленные за BMWG. Такое выделение адресов было предпринято для минимизации вероятности возникновения конфликтов при случайном подключении тестовой зоны к сети Internet. Специфика использования адресов рассмотрена ниже.
C.2.2.1. Протокольные адреса портов маршрутизаторов
Половину портов многопортового маршрутизатора мы называем «входными», а остальные — «выходными», даже в тех случаях, когда отдельные тесты используют все порты в качестве входных или выходных. Для «входных» портов резервируется непрерывный блок адресов в сетях класса C от 198.18.1.0 до 198.18.64.0. Второй блок (от 198.19.1.0 до 198.19.64.0) выделяется для «выходных» потов. Во всей случаях порт маршрутизатора является узлом 1 соответствующей сети. Например, 2-портовое устройство DUT будет иметь IP-адрес 198.18.1.1 на одном порту и 198.19.1.1 — на другом.
Некоторые из описанных тестов используют управляющее соединение с DUT по протоколу SNMP. Предполагается что для интерфейса управления DUT выделяется первый адрес из числа «входных» (198.18.1.1).
C.2.2.2. Адреса в кадрах
Некоторые из описанных тестов (например, проверка времени перезагрузки) предполагают маршрутизацию смежных сетей. IP-адрес в используемых для такого теста кадрах относится к узлу 2 соответствующей сети класса C (например, 198.19.1.2).
Если тест включает маршрутизацию несмежных сетей, фантомный маршрутизатор задается как узел 10 в соответствующей сети класса C. Группа сетей класса C от 198.18.65.0 до 198.18.254.0 используется для адресации устройств в сетях, доступных через фантомные маршрутизаторы на «входной» стороне DUT. Сети класса C от 198.19.65.0 до 198.19.254.0 выделены для адресации устройств, видимых через фантомные маршрутизаторы на «выходной» стороне DUT.
C.2.3. Частота маршрутных обновлений
Интервал обновления для каждого протокола маршрутизации может определяться спецификациями соответствующего протокола. Для IP RIP, Cisco IGRP и OSPF кадр или кадры маршрутных обновлений следует передавать за 5 секунд до каждого тестового потока. Такой частоты передачи обновлений достаточно для испытаний, продолжительностью до 60 секунд. При более длительных испытаниях кадры маршрутных обновлений следует включать в поток тестовых кадров. Периодичность передачи обновлений показана ниже.
| IP-RIP | 30 секунд |
| IGRP | 90 секунд |
| OSPF | 90 секунд |
C.2.4. Детальное обсуждение форматов кадров
C.2.4.1. Кадры обучения
В большинстве протоколов используется процедура отображения протокольных адресов на адреса MAC. В стеке TCP/IP для этого служит протокол преобразования адресов ARP. Для XNS и IPX такая процедура не требуется, поскольку MAC-адрес используется в качестве протокольного адреса узла.
В идеальном случае тестер будет способен отвечать на запросы ARP от DUT. В тех случаях, когда это невозможно, запросы ARP следует передавать в «выходной» порт маршрутизатора. Такой запрос следует рассматривать, как исходящий от конечного адресата тестового потока (т. е., фантомного маршрутизатора, как показано на рисунке 4 или конечного узла, если используется маршрутизация в смежную сеть). Предполагается, что маршрутизатор будет кэшировать MAC-адреса запрашивающих узлов. Запрос ARP следует передавать за 5 до начала передачи тестового потока в каждом испытании. Испытания продолжительностью более 50 могут потребовать увеличения тайм-аута ARP на маршрутизаторе.
+--------+ +------------+
| | | phantom |------ P LAN A
IN A------| DUT |------------| |------ P LAN B
| | OUT A | router |------ P LAN C
+--------+ +------------+
Рисунок 4: Случай использования полной маршрутизации
C.2.4.2. Кадры маршрутных обновлений
Если тест включает маршрутизации в сети, не являющиеся смежными, тестер должен обеспечить корректную маршрутную информацию с помощью маршрутных обновлений. Перед каждым испытанием для каждого порта «назначения» (см. параграф C.2.6.2) используется одно обновление маршрутных данных. Это обновление включает сетевые адреса, которые доступны через фантомный маршрутизатор в сети, подключенной к порту. При полносвязном тесте в маршрутном обновлении присутствует один адрес получателя для каждого из «входных» портов. Тестовый поток на каждом «входном» порту состоит из повторяющейся последовательности кадров (по одному на каждый «выходной» порт).
C.2.4.3. Кадры запросов управления
Тестирование издержек на управление использует протокол SNMP для запроса набора переменных, которые должны присутствовать во всех DUT, поддерживающих SNMP. Эти переменные для каждого интерфейса отдельно считываются NMS через заданные интервалы. Список переменных показан ниже:
sysUpTime ifInOctets ifOutOctets ifInUcastPkts ifOutUcastPkts
C.2.4.4. Тестовые кадры
Тестовые кадры представляют собой запросы UDP Echo Request с достаточным объемом данных для создания требуемого размера кадров. Данные не должны представлять собой набор только единиц или только нулей, поскольку такие последовательности могут приводить к активизации процессов добавления битов для обеспечения синхронизации каналов WAN, что, в свою очередь, ведет к увеличению размера кадров.
C.2.4.5. Форматы кадров — TCP/IP в сети Ethernet
Каждый из рассмотренных ниже кадров описывается для первой пары портов DUT («входного» порта 1 и «выходного» порта 1). Если кадры используются для других портов, адреса должны быть соответственно изменены.
C.2.6.1. Кадр «обучения»
Запрос ARP в сети Ethernet
-- Заголовок дейтаграммы offset data (hex) описание 00 FF FF FF FF FF FF широковещательный MAC-адрес для получателя broadcast address 06 xx xx xx xx xx xx указывается MAC-адрес отправителя 12 08 06 тип ARP 14 00 01 тип оборудования (Ethernet = 1) 16 08 00 протокол (IP = 800) 18 06 размер аппаратного адреса (48 битов для Ethernet) on Ethernet 19 04 размер протокольного адреса (4 октета для IP) for IP 20 00 01 код операции для запроса = 1 22 xx xx xx xx xx xx MAC-адрес отправителя 28 xx xx xx xx MAC-адрес запрашивающего устройства DUT 38 xx xx xx xx IP-адрес запрашивающего устройства DUT
C.2.6.2. Кадр маршрутных обновлений
-- Заголовок дейтаграммы
offset data (hex) описание
00 FF FF FF FF FF FF широковещательный MAC-адрес для получателя
06 xx xx xx xx xx xx аппаратный адрес отправителя
12 08 00 тип
-- Заголовок IP
14 45 версия IP - 4,
размер заголовка (в 4-байтовых словах) - 5
15 00 поле сервиса
16 00 EE общий размер
18 00 00 идентификатор (ID)
20 40 00 флаги (3 бита) 4 (не фрагментировать),
смещение фрагм. - 0
22 0A время жизни (TTL)
23 11 протокол - 17 (UDP)
24 C4 8D контрольная сумма заголовка
26 xx xx xx xx IP-адрес отправителя
30 xx xx xx IP-адрес получателя
33 FF номер хоста = FF для широковещания
-- UDP HEADER
34 02 08 порт отправителя 208 = RIP
36 02 08 порт получателя 208 = RIP
38 00 DA размер сообщения UDP
40 00 00 контрольная сумма UDP
-- Пакет RIP
42 02 команда/отклик (команда = 2)
43 01 версия = 1
44 00 00 0
-- сеть 1
46 00 02 family = IP
48 00 00 0
50 xx xx xx IP-адрес сети 1
53 00 сеть, а не узел
54 00 00 00 00 0
58 00 00 00 00 0
62 00 00 00 07 метрика 7
-- сеть 2
66 00 02 семейство = IP
68 00 00 0
70 xx xx xx IP-адрес сети 2
73 00 сеть, а не узел
74 00 00 00 00 0
78 00 00 00 00 0
82 00 00 00 07 метрика 7
-- сеть 3
86 00 02 семейство = IP
88 00 00 0
90 xx xx xx IP-адрес сети 3
93 00 сеть, а не узел
94 00 00 00 00 0
98 00 00 00 00 0
102 00 00 00 07 метрика 7
-- сеть 4
106 00 02 семейство = IP
108 00 00 0
110 xx xx xx IP-адрес сети 4
113 00 сеть, а не узел
114 00 00 00 00 0
118 00 00 00 00 0
122 00 00 00 07 метрика 7
-- сеть 5
126 00 02 семейство = IP
128 00 00 0
130 00 IP-адрес сети 5
133 00 сеть, а не узел
134 00 00 00 00 0
138 00 00 00 00 0
142 00 00 00 07 метрика 7
-- сеть 6
146 00 02 семейство = IP
148 00 00 0
150 xx xx xx IP-адрес сети 6
153 00 сеть, а не узел
154 00 00 00 00 0
158 00 00 00 00 0
162 00 00 00 07 метрика 7
C.2.4.6. Кадр управляющего запроса
Будет определен.
C.2.6.4. Тестовые кадры
Запрос UDP echo в среде Ethernet
-- Заголовок дейтаграммы
offset data (hex) Описание
00 xx xx xx xx xx xx MAC-адрес получателя
06 xx xx xx xx xx xx MAC-адрес отправителя
12 08 00 тип
-- IP HEADER
14 45 версия IP - 4,
размер заголовка (в 4-байтовых словах) - 5
15 00 TOS (тип обслуживания)
16 00 2E общий размер *
18 00 00 ID (идентификатор)
20 00 00 флаги (3 бита) 4 (не фрагментировать),
смещение фрагм. - 0
22 0A TTL (время жизни)
23 11 протокол - 17 (UDP)
24 C4 8D контрольная сумма заголовка *
26 xx xx xx xx IP-адрес отправителя **
30 xx xx xx xx IP-адрес получателя **
-- UDP HEADER
34 C0 20 порт отправителя
36 00 07 порт получателя - 07 = Echo
38 00 1A размер сообщения UDP *
40 00 00 контрольная сумма UDP
-- UDP DATA
42 00 01 02 03 04 05 06 07 произвольные данные ***
50 08 09 0A 0B 0C 0D 0E 0F
* - значение поля меняется в разных кадрах
** - меняется для разных логических потоков.
*** - Заполняют оставшуюся часть кадра нарастающими значениями с повторением,
если требуется по размеру кадра.
Значения, используемые с полях общего размера и размера сообщений UDP:
frame size total length UDP message length 64 00 2E 00 1A 128 00 6E 00 5A 256 00 EE 00 9A 512 01 EE 01 9A 768 02 EE 02 9A 1024 03 EE 03 9A 1280 04 EE 04 9A 1518 05 DC 05 C8