Как пассивно следить за потерей tcp-пакетов? (Linux)

Как я могу пассивно отслеживать потерю пакетов на TCP-соединениях с моей машиной?

По сути, мне нужен инструмент, который работает в фоновом режиме и наблюдает за тем, как TCP ack/nak/re-transforms генерирует отчет, по которому "равноправные" IP-адреса "кажутся" сильно потерянными.

Большинство подобных вопросов, которые я нахожу в SF, предлагают использовать такие инструменты, как iperf. Но мне нужно отслеживать соединения с реальным приложением на моей машине.

Эти данные просто находятся в стеке Linux TCP?

9 ответов

Для общего понимания масштаба вашей проблемы netstat -s будет отслеживать ваше общее количество повторных передач.

# netstat -s | grep retransmitted
     368644 segments retransmitted

Вы можете также 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 не сохраняют повторные передачи
  • stracing 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

Инструмент

Цель этого инструмента - предоставить более полные и точные результаты для идентификации и характеристики несоответствующих сегментов, чем те, которые были предоставлены предыдущими инструментами, такими как tcpanaly, tcpflows, LEAST и Mystery. Наша методология классифицирует каждый сегмент, который появляется вне последовательности (OOS) в трассировке пакета, в одну из следующих категорий: переупорядочение сети или повторная передача TCP, инициированная одним из тайм-аутов, дублированные ACK, частичные ACK, выборочные ACK или неявное восстановление. Кроме того, каждая повторная передача также оценивается на предмет необходимости или нет.

Я не скажу, что это качество продукции. Ранее я создавал быстрые Perl-сценарии для хранения кортежей ip / port / ack в памяти, а затем сообщал о дублированных данных из результатов сканирования pcap, похоже, он обеспечивает более тщательный анализ.

Вы можете посмотреть на dropwatch полезность.

В более новых системах netstatбольше не устанавливается по умолчанию. Человекочитаемый интерфейс для/proc/net/netstatбыл заменен наnstat. Обновленные команды следующие:

      $ nstat | grep Retrans
TcpRetransSegs                  862                0.0
TcpExtTCPLostRetransmit         7                  0.0
TcpExtTCPFastRetrans            5                  0.0
TcpExtTCPSlowStartRetrans       412                0.0
TcpExtTCPSynRetrans             414                0.0
      $ nstat | grep Seg
TcpInSegs                       62529              0.0
TcpOutSegs                      59093              0.0
TcpRetransSegs                  858                0.0
TcpExtTCPDSACKRecvSegs          12                 0.0

nstat -asможет использоваться для отключения функции истории, которая отображает статистику с момента последнего запуска команды, чтобы вместо этого отображалась статистика с момента загрузки. Команда непрерывного мониторинга будетwatch 'nstat -as | grep TcpRetransSegs'.

Выглядит как /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%, которое мы видели на других узлах. Один действительно плохой экземпляр достиг 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;

Очевидно, старый добрый sar может собирать повторную передачу (и другую статистику 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, с которым у меня нет никакого опыта - учтите, приложение, а не язык программирования)

В последних версиях Linux netstat был заменен на и . Другой ответ объясняет, как использоватьss. Сipвы можете получить количество отброшенных пакетов с помощью этой команды:

      ip -s link show eth0

Смотрите также:

Другие вопросы по тегам