Понимание [TCP ACKed невидимый сегмент] [TCP Предыдущий сегмент не занят]

Question

Мы проводим тестирование нагрузки на наших серверах, и я использую tshark для захвата некоторых данных в файл pcap, а затем с помощью графического интерфейса wirehark, чтобы узнать, какие ошибки или предупреждения показывают, идя для анализа -> эксперт Информация с моим PCAP загружен в ..

Я вижу различные вещи, которые я не знаю, или не до конца еще понимают ..

Под предупреждениями I имеют: 779 Предупреждения для сегмента TCP: ACKed, который не был захвачен (обычно при запуске захвата) 446 TCP: предыдущий сегмент не записан (обычный при запуске захвата)

Пример: 40292 0.000 xxx xxx TCP 90 [TCP ACKed невидимый сегмент] [TCP Предыдущий сегмент не записан] 11210> 37586 [PSH, ACK] Seq = 3812 Ack = 28611 Win = 768 Len = 24 TSval = 199317872 TSecr = 4506547

Мы также запустили файл PCAP, хотя хороший команда, которая создает команду столбец строки данных

команды

tshark -i 1 -w file.pcap -c 500000 

в основном только видел несколько вещей в tcp.analysis.lost_segment колонке, но не так много. \

Кто-нибудь просветит, что может быть? tshark не в состоянии идти в ногу с написанием данных, какой-то другой вопрос? Ложно положительный?

Answer 1

Это очень хорошо может быть ложным положительным. Как и в предупреждающем сообщении, обычно для начала записи в середине сеанса tcp. В этих случаях он не имеет такой информации. Если вы действительно пропустите acks, тогда пришло время начать смотреть вверх по течению от вашего хоста, где они исчезают. Возможно, что tshark не может идти в ногу с данными и поэтому он отбрасывает некоторые показатели. В конце вашего захвата он скажет вам, «упало ли ядро ​​пакета» и сколько. По умолчанию tshark отключает поиск dns, tcpdump этого не делает. Если вы используете tcpdump, вам нужно перейти в переключатель «-n». Если у вас есть проблема ввода-вывода на диске, вы можете сделать что-то вроде записи в память/dev/shm. НО будьте осторожны, потому что, если ваши захваты становятся очень большими, вы можете заставить свою машину начать замену.

Моя ставка заключается в том, что у вас очень длинные сеансы tcp и когда вы начинаете свой захват, вы просто пропускаете некоторые части сеанса tcp из-за этого. Сказав это, вот некоторые из вещей, которые я видел, вызывают дублирование/пропуски.

1. Переключатели - (очень маловероятно, но иногда они попадают в больном состоянии)
2. Маршрутизаторы - более вероятно, чем коммутаторы, но не так много
3. Firewall - Скорее, чем маршрутизаторы. Что нужно искать здесь истощение ресурсов (лицензии, процессор и т.д.)
4. стороны клиента программного обеспечения для фильтрации - антивирус, обнаружение вредоносных программ и т.д.

Answer 2

Другой причиной «TCP ACKed Невидимого» этим количество пакетов, которые могут получить падение в захвате. Если я запустил нефильтрованный захват для всего трафика на занятом интерфейсе, я иногда увижу большое количество «упавших» пакетов после остановки tshark.

В последнем захвате, который я сделал, когда увидел это, у меня было захвачено 2893204 пакетов, но как только я нажал Ctrl-C, я получил сообщение об отбрасывании пакетов 87581.Это 3% -ная потеря, поэтому, когда wirehark открывает захват, возможно, он будет пропускать пакеты и сообщать «невидимые» пакеты.

Как я уже упоминал, я захватил действительно занятый интерфейс без фильтра захвата, поэтому tshark пришлось сортировать все пакеты, когда я использую фильтр захвата для удаления некоторого шума, я больше не получаю ошибку.

Answer 3

Acked Unseen sample

Привет, ребята! Просто некоторые наблюдения из того, что я только что нашел в моем захвате:

Во многих случаях пакетный захват сообщает о «сегменте ACKed, который не был захвачен» на стороне клиента, который предупреждает о том, что клиентский компьютер отправил данные пакет, сервер подтверждает получение этого пакета, но захват пакета, сделанный на клиенте, не включает в себя пакет, посланный клиентом.

Первоначально я думал, что это указывает на отказ ПК записывать в захваченный пакет, который он отправляет потому что «например, машина, работающая Wireshark, медленна» (https://osqa-ask.wireshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue)
Однако, я заметил, что каждый раз, когда я вижу этот «неактивный сегмент ACKed», я вижу запись «неверного» пакета, отправленного клиентский ПК

• В примере захвата выше, кадр 67795 отправляет ACK для 10384

• Даже если Wireshark отчеты длину Поддельный IP (0), рамка 67795 является сообщается, длина 13194

• Рама 67800 посылает ACK для 23524
• 10384 + 13194 = 23578
• 23578 - 23524 = 54
• 54 в длину факта заголовков Ethernet/IP/TCP (14 для Ethernt, 20 для IP, 20 для TCP)
• Таким образом, в самом деле, рама 67796 действительно представляет большие TCP-пакеты (13194 байтов), которые операционная система пыталась надеть носил
  • драйвер NIC будет фрагментировать его на более мелкие 1500 байт части, чтобы передавать по сети
  • Но Wireshark работает на моем компьютере, не понимает, что это правильный пакет и разобрать его , Я считаю, что Wireshark работает на 2012 для Windows сервер читает эти снимки правильно
• Так в конце концов, эти «Богус IP длина» и «ACKed сегмент, который не был захвачен» оповещения на самом деле были ложных срабатываний в моем случае