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

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

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

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

Пример: 40292 0,000 xxx xxx TCP 90 [TCP ACK-невидимый сегмент] [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 не в состоянии не отставать от записи данных, какая-то другая проблема? Ложно положительный?

Источник

4 ответа

Решение

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

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

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

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

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

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

Источник

Acked Невидимый образец

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

Во многих случаях на стороне клиента сообщается о захвате пакета "Сегмент ACK, который не был захвачен", который предупреждает о том, что клиентский ПК отправил пакет данных, сервер подтверждает получение этого пакета, но захват пакета выполнен на клиенте не входит пакет, отправленный клиентом

Сначала я подумал, что это означает, что ПК не смог записать в перехват пакет, который он отправляет, потому что "например, машина, на которой работает Wireshark, работает медленно" ( https://osqa-ask.wireshark.org/questions/25593/tcp -предыдущий-сегмент-не-захвачен-это-то-проблема с подключением)
Однако затем я заметил, что каждый раз, когда я вижу это предупреждение "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, работающий на Windows Server 2012, правильно читает эти записи
  • Так что, в конце концов, эти предупреждения о "фиктивной длине IP" и "сегменте ACKed, который не был захвачен" были фактически ложными срабатываниями
Источник

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

Источник
Другие вопросы по тегам