Назад | Перейти на главную страницу

Как пассивно отслеживать потерю TCP-пакетов? (Linux)

Как я могу пассивно отслеживать потерю пакетов при 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 чтобы увидеть ретрансляции по потоку.

Это лучший вариант, который я могу придумать.

Исследуются и другие тупики:

  • Инструменты netfilter / conntrack, похоже, не сохраняют повторные передачи
  • охота netstat -s показал, что это просто печать /proc/net/netstat
  • столбец 9 в / proc / net / tcp выглядел многообещающим, но, к сожалению, не использовался.

Эта статистика находится в / 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 минут по умолчанию, но это также можно настроить.

Для анализа этих данных используйте:

  • sar (командная строка, текстовая)
  • sadf создает SVG в соответствии с http://sebastien.godard.pagesperso-orange.fr/matrix.html
  • ksar (который может строить красивые графики и работает на Java - есть несколько разных клонов, из которых можно выбрать на sf.net и github, если я правильно помню)
  • http://www.sargraph.com (на основе PHP, с которым у меня вообще нет опыта - заметьте, приложение, а не язык программирования 😉)

Выглядит как /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;