Как я могу пассивно отслеживать потерю пакетов при TCP-соединениях с моей машиной?
По сути, мне нужен инструмент, который работает в фоновом режиме и наблюдает за TCP ack / nak / re-Transmit для создания отчета о том, какие одноранговые IP-адреса, по всей видимости, несут большие потери.
Большинство подобных вопросов, которые я нахожу в SF, предполагают использование таких инструментов, как iperf. Но мне нужно отслеживать подключения к / из реального приложения на моей машине.
Эти данные просто лежат в стеке TCP Linux?
Для общего представления о масштабе вашей проблемы netstat -s
будет отслеживать ваше общее количество повторных передач.
# netstat -s | grep retransmitted
368644 segments retransmitted
Вы можете aso grep для segments
чтобы получить более подробное представление:
# netstat -s | grep segments
149840 segments received
150373 segments sent out
161 segments retransmitted
13 bad segments received
Для более глубокого погружения вы, вероятно, захотите запустить Wireshark.
В Wireshark установите фильтр на tcp.analysis.retransmission
чтобы увидеть ретрансляции по потоку.
Это лучший вариант, который я могу придумать.
Исследуются и другие тупики:
netstat -s
показал, что это просто печать /proc/net/netstat
Эта статистика находится в / proc / net / netstat и collectl
будет отслеживать их в интерактивном режиме или записывать на диск для последующего воспроизведения:
[root@poker ~]# collectl -st
waiting for 1 second sample...
#<------------TCP------------->
#PureAcks HPAcks Loss FTrans
3 0 0 0
1 0 0 0
Конечно, если вы хотите видеть это рядом с сетевым трафиком, просто включите n
с участием -s
:
[root@poker ~]# collectl -stn
waiting for 1 second sample...
#<----------Network----------><------------TCP------------->
# KBIn PktIn KBOut PktOut PureAcks HPAcks Loss FTrans
0 1 0 1 1 0 0 0
0 1 0 1 1 0 0 0
Вы можете использовать ss
инструмент для получения подробной статистики TCP:
$ /sbin/ss -ti
В Debian используйте apt-get install iproute
чтобы получить двоичный файл.
Похоже, что некоторые ребята из Университета Северной Каролины (UNC) создали утилиту, чтобы исследовать именно это:
Методология
TCP - классический пример устаревшего протокола, который может быть изменен. К сожалению, оценка такой фундаментальной вещи, как механизм обнаружения / восстановления потерь TCP, не является исчерпывающей. Наша цель - выполнить полную реалистичную оценку потерь TCP и их влияния на производительность TCP.
Я полагаюсь на пассивный анализ реальных TCP-соединений для достижения необходимого уровня детализации и реализма в моем анализе.
http://www.cs.unc.edu/~jasleen/Research-passivetcp.htm#Tool
Инструмент
Цель этого инструмента - предоставить более полные и точные результаты для идентификации и характеристики сегментов вне последовательности, чем те, которые предоставлялись предыдущими инструментами, такими как tcpanaly, tcpflows, LEAST и Mystery. Наша методология классифицирует каждый сегмент, который появляется вне последовательности (OOS) в трассировке пакета, в одну из следующих категорий: переупорядочение сети или повторная передача TCP, инициированная одним из следующих параметров: тайм-аут, повторяющиеся ACK, частичные ACK, выборочные ACK или неявное восстановление. Кроме того, каждая повторная передача также оценивается на предмет необходимости в ней.
Не скажу, что это качество продукции. Ранее я создавал быстрые сценарии perl для хранения кортежей ip / port / ack в памяти, а затем сообщал о дублированных данных при сканировании вывода pcap, похоже, это обеспечивает более тщательный анализ.
Вы можете посмотреть на dropwatch
утилита.
Видимо старый добрый сар может собирать данные о повторных передачах (и другую статистику TCP) вместе со всеми видами другой системной статистики, которая также может быть интересна, если вы исследуете такие проблемы, как ЦП, память, дисковый ввод-вывод и т. д.
Возможно, вам потребуется установить пакет: sysstat и включить этот конкретный вид статистики с помощью переключателя -S SNMP, в RHEL / OracleLinux это настраивается в /etc/cron.d/sysstat, где вызывается / usr / lib64 / sa / sa1 каждые 5 минут по умолчанию, но это также можно настроить.
Для анализа этих данных используйте:
Выглядит как /proc/net/snmp
где значения для netstat -s
получены. Итак, вот сценарий быстрого gawk для определения процента сегментов, которые повторно передаются:
gawk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print "InSegs\t",$11,"\nOutSegs\t",$12,"\nRetransSegs\t",$13,"\nPctReTrans\t",($13/$12*100)}' /proc/net/snmp
InSegs 8567261339
OutSegs 9545034903
RetransSegs 2192165
PctReTrans 0.0229665
Показан внутренний (без общедоступного IP-адреса или общедоступного трафика) экземпляра AWS, который, как мы подозревали, имел сетевые проблемы с другими системами в VPC. 0,0229% ретранслировано, что более чем в 10 раз превышает 0,002% max мы видели на других узлах. Один действительно плохой экземпляр поднялся до 2,32% всех исходящих пакетов были повторно переданы сегменты.
Вы также можете увидеть частоту повторных передач в течение заданного временного окна, используя:
FIRST=$(netstat -s | grep -oP \'\d+(?= segments retransmit+ed)\');
sleep 30;
LAST=$(netstat -s | grep -oP \'\d+(?= segments retransmit+ed)\');
expr $LAST - $FIRST;