Если я вас правильно понимаю, вас в основном интересует что-то вроде Linux 'strace' ( Введение ) для системных вызовов системы?
Возможно сочетание профилировщика и отладчика для сетевых приложений (т. Е. 'Ntrace'), обеспечивающих подробный анализ различных необязательных измерений?
В Linux утилита strace в значительной степени основана на функциональности, предоставляемой ядром Linux, а именно ptrace (отслеживание процесса) API:
Используя ptrace, можно получить большинство интересующих вас данных.
В Windows вы, вероятно, захотите изучить обхода , чтобы перехватывать / перенаправлять вызовы Winsock API для целей проверки / тестирования.
Если вам на самом деле не нужна вся эта многоуровневая информация, вы, вероятно, также можете напрямую использовать strace (в linux) и использовать ее только для отслеживания определенных системных вызовов, например, рассмотрите следующую строку, которая будет отслеживать только вызовы открытый системный вызов (используя дополнительный параметр -o FILE, вы можете перенаправить весь вывод в выходной файл):
strace -e trace=open -o results.log
Передав дополнительный флаг -v в strace, вы можете увеличить его многословность для получения дополнительной информации (при работе с SCM, такими как git, которые состоят из множества небольших утилит оболочки и автономных инструментов, вы, вероятно, также захотите изучить использование флага -f для отслеживания разветвленных процессов).
Итак, что вас заинтересует, так это все системные вызовы, связанные с сокетами , а именно:
- принять
- bind
- подключить
- getpeername
- getsockname
- getsockopt
- слушай
- recv
- recvfrom
- отправить
- sendto
- setsockopt
- выключение
- гнездо
- socketpair
(в начале вы, вероятно, захотите разобраться только с вызовами send ... / recv ...)
Чтобы упростить это, вы также можете использовать «сеть» в качестве параметра для трассировки, которая будет отслеживать все сетевые вызовы:
-e trace = network: отследить все системные вызовы, связанные с сетью.
Итак, соответствующий вызов strace может выглядеть так:
strace -v -e trace=accept,bind,connect,getpeername,getsockname,getsockopt,listen,recv,recvfrom,send,sendto setsockopt,shutdown,socket,socketpair -o results.log -f git pull
Когда программа завершит работу, вам, в основном, понадобится проверить файл журнала, чтобы оценить данные, этого можно легко достичь с помощью регулярных выражений.
Например, при запуске следующего в оболочке linux:
strace -v -o wget.log -e trace=connect,recv,recvfrom,send,sendto wget http://www.google.com
Полученный файл журнала содержит такие сообщения:
- recv (3, "HTTP / 1.0 302 Found \ r \ nРасположение: htt" ..., 511, MSG_PEEK) = 511
- sendto (4, "\ 24 \ 0 \ 0 \ 0 \ 26 \ 0 \ 1 \ 3 ^ \ 206 * J \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0" ..., 20, 0, {sa_family = AF_NETLINK, pid = 0, группы = 00000000}, 12) = 20
Глядя на справочные страницы для этих двух системных вызовов, очевидно, что 511 и, соответственно, 20 - это количество переданных байтов. Если вам также нужна подробная информация о времени, вы можете передать флаг -T в strace:
-T - время печати, потраченное на каждый системный вызов
Кроме того, вы можете получить некоторую статистику, передав флаг -c:
-c: подсчитывать время, вызовы и ошибки для каждого системного вызова и сообщать сводные данные о программе.
выход. В Linux это пытается показать системное время (процессорное время, потраченное на работу в ядре)не зависит от времени настенных часов. Если -c используется с -f или -F (ниже), только агрегат
итоги по всем отслеживаемым процессам сохраняются.
Если вам также необходимо проверить фактические обработанные данные, вы можете посмотреть спецификаторы чтения / записи:
-e read = set: выполнить полный шестнадцатеричный и ASCII-дамп всех данных, считанных из файла
дескрипторы перечислены в указанном наборе. Например, чтобы увидеть все действия ввода в файле
дескрипторы 3 и 5 используют -e read = 3,5. Обратите внимание, что это не зависит от нормального
трассировка системного вызова read (2), который управляется опцией -e trace = read.
-e write = set: выполнить полный шестнадцатеричный и ASCII-дамп всех данных, записанных в файл
дескрипторы перечислены в указанном наборе. Например, чтобы увидеть все выходные данные в файле
дескрипторы 3 и 5 используют -e write = 3,5. Обратите внимание, что это не зависит от нормального
трассировка системного вызова write (2), который управляется опцией -e trace = write.
Вы также можете настроить максимальную длину строк:
-s strsize: укажите максимальный размер строки для печати (по умолчанию 32). Обратите внимание, что
имена файлов не считаются строками и всегда печатаются полностью
Или строки в шестнадцатеричном формате:
-xx: печатать все строки в шестнадцатеричном формате.
Таким образом, использование strace для большей части этого похоже на хороший гибридный подход, потому что его очень легко сделать, но все же имеется достаточно большое количество информации низкого уровня, если вы обнаружите, что вам нужна дополнительная информация низкого уровня, вы можете вместо этого рассмотреть возможность расширения strace или подачи соответствующих запросов функций с проектом strace на sourceforge .
Однако, подумав немного об этом, менее сложном и более независимом от платформы способе реализации довольно простого эталона сетевого трафика, было бы использование некоторой формы промежуточного уровня между клиентом и фактическим сервером: сервером это в основном измерение, анализ и перенаправление трафика на реальный сервер.
Очень похоже на прокси-сервер (например, SOCKS ), поэтому весь трафик направляется через ваш анализатор, который, в свою очередь, может накапливать статистику и другие метрики.
Базовую версию чего-то подобного, вероятно, можно легко собрать, просто используя netcat и некоторые сценарии оболочки, однако более сложные версии могут выиграть от использования perl или python.
Для реализации сервера SOCKS на python вы можете рассмотреть pysocks .
Также есть, конечно, витая для питона:
Twisted - это управляемый событиями сетевой движок, написанный на Python.
и под лицензией MIT.
Если вам нужно иметь более низкоуровневую информацию, вы, вероятно, действительно захотите изучить перехват системных вызовов.
Если вам также нужны специфичные для протокола данные об эффективности, вы можете изучить tcpdump .