Сервер Windows 2003.
У меня установлена последняя версия WireShark на сервере, и мне нужно захватывать пакеты на сервере, чтобы точно определить случайно возникшую проблему сброса / повторной передачи соединения. Когда происходит сброс соединения, он сбрасывает около 600 соединений в секунду, при этом нормальное значение должно быть ниже 100 / сек. Сервер фактически является виртуальной машиной на хосте Cisco UCS. Может ли захват пакета tshark помочь выяснить причину?
Еще один побочный вопрос: поскольку я собираюсь захватить весь трафик (не уверен, что это хорошая идея), я также выполняю нарезку пакетов. Мой вопрос в том, сколько байтов следует ограничить для каждого пакета. Похоже, что захваченный мной пакет имеет 54 байта для заголовка (кажется, включая фрейм, EthernetII, интернет-протокол, часть TCP). Должен ли я просто использовать
tshart -q -b "filesize:20000" -b "files:5" -s 54 -w c:\outfile.pcap
так что вся полезная нагрузка не будет сохранена? Пожалуйста, посоветуйте, спасибо!
Для обычного Ethernet ваш snaplen (-s option) должно быть 1500, если вы хотите получить весь пакет. Это даст вам весь пакет и позволит полностью декодировать протокол при загрузке в сам WireShark. В зависимости от того, что вы нюхаете, вы, вероятно, также захотите увеличить размер файла.
Чтобы получить хотя бы заголовки большинства пакетов, обычно достаточно snaplen 200. Он получит E_II, IP, TCP / UDP и некоторые заголовки протокола более высокого уровня.
Существует несколько типов сброса соединения, каждый из которых имеет свое значение.
Немедленный сброс всех существующих подключений
Этот стиль сброса проявляется в сниффах как большой блок RST, отправляемых сервером, вероятно, с очень небольшим трафиком между пакетами. Это может быть вызвано самопроизвольным сбросом приложения над стеком TCP / IP, которое, в свою очередь, сообщает стеку TCP / IP уничтожить все дескрипторы соединения, связанные с этим модулем.
Сброс всех существующих подключений при наличии трафика
Это проявляется в запахе с более скрытным рисунком. После определенного момента, в любое время существующее соединение получает трафик от клиентской станции, выдается пакет RST. То, что делает клиент, зависит от протокола более высокого уровня, возможно, будет предпринята попытка повторного подключения. Обычно это вызвано тем, что сам стек TCP / IP незаметно теряет состояние соединения. Что касается стека, этот пакет от клиента не связан с какими-либо открытыми соединениями, поэтому он просто выдает пакет RST и игнорирует его.
Сброс новых попыток подключения
Существующие соединения продолжают работать, но на SYN-пакеты отвечают RST. При нормальной работе это происходит, потому что для порта, указанного в SYN-пакете, нет открытого порта. Обычно это вызвано ошибкой в приложении более высокого уровня.
Что касается ваших повторных передач, они вызваны тем, что клиенты не получают пакеты, которые они ожидают получить. Это может быть вызвано прямой потерей пакетов или может быть, что сервер просто не отправляет эти пакеты вообще. Если ваш сниффер на сервере показывает пакеты повторной передачи, а список разговора показывает, что пакеты не передаются. послал сервером, это признак того, что что-то пошло не так на самом сервере. Это может быть связано с ошибками в приложении более высокого уровня, стеке TCP / IP или в самом драйвере сетевой карты. Я видел, как обновления драйверов сетевой карты исправляют это, но в виртуальной машине это менее вероятно. Подобные массовые перезагрузки могут быть вызваны исчерпанием ресурсов сервера.