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