Блог

Я создал базовый TCP-сервер, который считывает входящие двоичные данные в формате буфера протокола и записывает двоичное сообщение в качестве ответа. Я хотел бы сравнить время в пути туда и обратно.

Я попробовал iperf, но не смог заставить его отправлять один и тот же входной файл несколько раз. Есть ли другой инструмент тестирования, который может повторно отправлять двоичный входной файл?

Если у вас есть доступ к машине Linux или unix¹, вам следует использовать tcptrace. Все, что вам нужно сделать, это выполнить цикл тестирования двоичного трафика во время записи с помощью файла wireshark или tcpdump.

После того, как у вас будет этот .pcap файл², проанализируйте с помощью tcptrace -xtraffic <pcap_filename> ³. При этом будут сгенерированы два текстовых файла, а средняя статистика RTT для всех подключений в этом pcap показана внизу вызываемого файла traffic_stats.dat .

 [mpenning@Bucksnort tcpperf]$ tcptrace -xtraffic willers.pcap
mod_traffic: characterizing traffic
1 arg remaining, starting with 'willers.pcap'
Ostermann's tcptrace -- version 6.6.1 -- Wed Nov 19, 2003

16522 packets seen, 16522 TCP packets traced
elapsed wallclock time: 0:00:00.200709, 82318 pkts/sec analyzed
trace file elapsed time: 0:03:21.754962
Dumping port statistics into file traffic_byport.dat
Dumping overall statistics into file traffic_stats.dat
Plotting performed at 15.000 second intervals
[mpenning@Bucksnort tcpperf]$
[mpenning@Bucksnort tcpperf]$ cat traffic_stats.dat


Overall Statistics over 201 seconds (0:03:21.754962):
4135308 ttl bytes sent, 20573.672 bytes/second
4135308 ttl non-rexmit bytes sent, 20573.672 bytes/second
0 ttl rexmit bytes sent, 0.000 bytes/second
16522 packets sent, 82.199 packets/second
200 connections opened, 0.995 conns/second
11 dupacks sent, 0.055 dupacks/second
0 rexmits sent, 0.000 rexmits/second
average RTT: 67.511 msecs        <------------------
[mpenning@Bucksnort tcpperf]$
  

.pcap Файл, используемый в этом примере, был файлом захвата, который я сгенерировал, когда я зацикливался на expect скрипте, который извлекал данные с одного из моих серверов. Именно так я сгенерировал цикл…

 #!/usr/bin/python
from subprocess import Popen, PIPE
import time

for ii in xrange(0,200):
    # willers.exp is an expect script
    Popen(['./willers.exp'], stdin=PIPE, stdout=PIPE, stderr=PIPE)
    time.sleep(1)
  

Вы можете настроить время ожидания между циклами на основе accept() производительности вашего сервера и продолжительности ваших тестов.

ПРИМЕЧАНИЯ К КОНЦУ:

1. Для этого подойдет Knoppix Live-CD
2. Фильтруется только для сбора тестового трафика
3. tcptrace способен отображать очень подробную статистику для каждого сокета, если вы используете другие параметры…

================================
[mpenning@Bucksnort tcpperf] $ tcptrace -lr willers.pcap
осталось 1 аргумент, начинающийся с 'willers.pcap'
Tcptrace Остерманна - версия 6.6.1 - Ср. 19 ноября 2003 г.

просмотрено 16522 пакета, отслежено 16522 TCP-пакета 
прошедшее время настенного синхронизации: 0:00:00.080496, проанализировано 205252 пкт / сек 
время, прошедшее с файла трассировки: 0:03:21.754962
Информация о TCP-соединении:
Отслежено 200 TCP-соединений:
TCP-соединение 1:
 хост c: myhost.local: 44781
 хост d: willers.local: 22
 завершить соединение: СБРОС (SYN: 2) (FINs: 1) 
 первый пакет: Вт, 31 мая, 22:52:24.154801 2011
 последний пакет: Вт, 31 мая, 22:52:25.668430 2011
 прошедшее время: 0:00:01.513628 
 общее количество пакетов: 73 
 имя файла: willers.pcap
 c-> d: d-> c:
 всего пакетов: 34 всего пакетов: 39 
 сброс отправленных: 4 сброс отправленных: 0 
 отправлено подтверждающих сообщений: 29 отправлено подтверждающих сообщений: 39 
 отправлено чистых подтверждений: 11 отправлено чистых подтверждений: 2 
 отправлено сообщений sack pkts: 0 отправлено сообщений sack pkts: 0
 отправлено сообщений dsack pkts: 0 Отправлено сообщений dsack pkts: 0 
 максимальное количество блокировок / ack: 0 максимальное количество блокировок / ack: 0 
 отправлено 2512 уникальных байт Отправлено 14336 
 фактические данные pkts: 17 фактические данные pkts: 36 
 фактические байты данных: 2512 фактические байты данных: 14336
 rexmt data pkts: 0 rexmt data pkts: 0
 rexmt байт данных: 0 rexmt байт данных: 0 
 pkts пробника zwnd: 0 pkts пробника zwnd: 0 
 байты проверки zwnd: 0 байты проверки zwnd: 0 
 исходящие pkts: 0 исходящие pkts: 0 
 количество отправленных данных: 17 количество отправленных данных: 33
 Отправлено SYN / FIN pkts: 1/1 Отправлено SYN / FIN pkts: 1/0
 запрос 1323 ws / ts: Y / Y запрос 1323 ws / ts: Y / Y 
 adv шкала ветра: 6 adv шкала ветра: 1 
 запрос sack: Y запрос sack: Y 
 отправлено sacks: 0 отправлено sacks: 0
 pkts срочных данных: 0 pkts срочных данных: 0 pkts 
 байты срочных данных: 0 байт байты срочных данных: 0 байт 
 запрошенный mss: 1460 байт запрошенный mss: 1460 байт 
 максимальный размер сегмента: 792 байта максимальный размер сегмента: 1448 байт 
 минимальный размер сегмента: 16 байт минимальный размер сегмента: 32 байта 
 средний размер сегмента: 147 байт Средний размер сегмента: 398 байт 
 максимальный выигрыш adv: 40832 байта максимальный выигрыш adv: 66608 байт 
 минимальный выигрыш adv: 5888 байт минимальный выигрыш adv: 66608 байт 
 нулевой выигрыш adv: 0 раз нулевой выигрыш adv: 0 раз 
 среднее значение win adv: 14035 байт среднее значение win adv: 66608 байт 
 начальное окно: 32 байта начальное окно: 40 байт 
 начальное окно: 1 pkts начальное окно: 1 pkts 
 длина потока ttl: 2512 байт Длина потока ttl: NA 
 пропущенные данные: 0 байт пропущенные данные: NA 
 усеченные данные: 0 байт усеченные данные: 0 байт
 усеченные пакеты: 0 pkts усеченные пакеты: 0 pkts 
 время передачи данных: 1.181 сек. время передачи данных: 1.236 сек. 
 максимальное время простоя: 196,9 мс максимальное время простоя: 196,9 мс 
 пропускная способность: 1660 бит / с пропускная способность: 9471 бит /с

 Образцы RTT: 18 Образцов RTT: 24
 RTT min: 43,8 мс RTT min: 0,0 мс
 Максимальное RTT: 142,5 мс, максимальное RTT: 7,2 мс
 Среднее значение RTT: 68,5 мс Среднее значение RTT: 0,7 мс
 RTT stdev: 35,8 мс RTT stdev: 1,6 мс

 RTT от 3WHS: 80,8 мс RTT от 3WHS: 0,0 мс

 RTT full_sz smpls: 1 RTT full_sz smpls: 3
 RTT full_sz min: 142,5 мс RTT full_sz min: 0,0 мс
 RTT full_sz max: 142,5 мс RTT full_sz max: 0,0 мс
 Среднее значение RTT full_sz: 142,5 мс Среднее значение RTT full_sz: 0,0 мс
 RTT full_sz stdev: 0.0 мс RTT full_sz stdev: 0.0 мс

 подтверждения после потери: 0 подтверждений после потери: 0 
 количество подтвержденных сегментов: 0 количество подтвержденных сегментов: 9 
 повторяющиеся подтверждения: 0 повторяющиеся подтверждения: 1 
 тройные дубликаты: 0 тройные дубликаты: 0
 максимальное количество повторных переводов: 0 максимальное количество повторных переводов: 0 
 минимальное время ретрансляции: 0.0 мс минимальное время ретрансляции: 0.0 мс 
 максимальное время возврата: 0.0 мс максимальное время возврата: 0.0 мс 
 среднее время возврата: 0.0 мс среднее время возврата: 0.0 мс 
 время возврата sdv: 0.0 мс время возврата sdv: 0.0 мс
================================

Вы всегда можете вставить цикл оболочки вокруг программы, такой как iperf. Кроме того, предполагая, что iperf может считывать данные из файла (таким образом, stdin) или таких программ, как ttcp, может позволить циклу оболочки передавать файл N раз в iperf / ttcp.

Если вам нужна программа, которая отправляет файл, ожидает вашего двоичного ответа, а затем отправляет другую копию файла, вам, вероятно, потребуется закодировать это самостоятельно.

Вам нужно будет измерить время в клиентском приложении для времени обхода или отслеживать сетевой трафик, исходящий от клиента и поступающий к клиенту, чтобы получить полный временной интервал. Измерение времени на сервере исключит любые задержки на уровне ядра на сервере и все время передачи по сети.

Обратите внимание, что производительность TCP будет снижаться по мере увеличения нагрузки. Если вы собираетесь тестировать под большой нагрузкой, вам нужны профессиональные инструменты, которые могут масштабироваться до тысяч (или даже миллионов в некоторых случаях) новых подключений / секунд или параллельно установленных TCP-соединений.

Я написал статью об этом в своем блоге (не стесняйтесь удалить, если это сочтут рекламой, но я думаю, что это имеет отношение к этой теме): http://synsynack.wordpress.com/2012/04/09/realistic-latency-measurement-in-the-application-layers

В качестве очень простого инструмента высокого уровня на ум приходит netcat… итак, что-то вроде time (nc hostname 1234 < input.binary | head -c 100) предположения, что ответ имеет длину 100 байт.