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


61

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

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

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

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

Ответы:


50

Для общего понимания масштаба вашей проблемы 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 не сохраняют повторные передачи
  • расстановка netstat -sпоказала, что это просто печать/proc/net/netstat
  • Столбец 9 в / proc / net / tcp выглядел многообещающе, но, к сожалению, он не используется.

и вы можете отслеживать потерянные пакеты с помощью # watch 'netstat -s | grep retransmited '
нет

Это покажет только исходящие проблемы. «netstat -s | grep сегменты» кажется мне более разумным.
Акостадинов

1
Если вы управляете сетью разумного размера, я бы порекомендовал pastmon поверх wireshark для постоянного мониторинга - pastmon.sourceforge.net/Wikka-1.1.6.5/wikka.php?wakka=HomePage
symcbean

4
По какой-то причине это написано retransmitedдля меня (Ubuntu Server 14).
Судо

1
Какой хороший показатель для повторных передач по сравнению с отправленным или полученным?
abourget

12

Эта статистика находится в / 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

7

Вы можете использовать ssинструмент для получения подробной статистики по TCP:

$ /sbin/ss -ti

В Debian используйте apt-get install iprouteдля получения двоичного файла.


Обратите внимание, что человек, задающий вопрос, искал инструмент, который он мог бы наблюдать за результатами. Хотя некоторые из команд, упомянутых до сих пор, не работают таким образом, во всех ответах с поправками был указан по крайней мере один способ для этого.
Эндрю Б

2
@AndrewB: вы можете сделать watch ss -ti.
Джон Цвинк

3

Похоже, что некоторые ребята из Университета Северной Каролины (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, похоже, он обеспечивает более тщательный анализ.



0

Очевидно, старый добрый 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, с которым у меня нет никакого опыта - имейте в виду, приложение, а не язык программирования 😉)
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.