Комментарии 12
Продолжайте, пожалуйста, очень интересный инструмент
Этих статей на Хабре куча.
Как пример habr.com/post/204274. Да и вообще если по тэгу Wireshark пройтись можно найти много чего интересного.
Как пример habr.com/post/204274. Да и вообще если по тэгу Wireshark пройтись можно найти много чего интересного.
Follow/TCP Stream ведь!
Для отладки сетевых приложений и поиска "кто накосячил" 99% случаев.
Смотреть tcp поток по пакетам — это удел мазохистов. Не, если проблема в инфраструктуре, то да, но первое таки follow.
В моей практике обычно «накосячил» выражается в обрыве соединения. Поэтому я обычно смотрю именно пакеты и ищу от кого первым пришел пакет RST или FIN.
Возможно — у всех практики разные.
Но дело в том, что Follow по сути сначала делает Conversation filter, а потом показывает отдельное окошко с полезной нагрузкой. Зная приблизительно какая полезная нагрузка ожидается, можно частенько решить есть ли проблема, там ли она, где кажется, и прочее.
После этого ничего не мешает закрыть это окошко и смотреть на пакеты. Но зачем добровольно отказываться от предложения посмотреть на полезную нагрузку перед тем, как искать флаги в пакетах (то бишь использовать Conversation Filter супротив Follow для TCP соединения) мне решительно непонятно.
Но дело в том, что Follow по сути сначала делает Conversation filter, а потом показывает отдельное окошко с полезной нагрузкой. Зная приблизительно какая полезная нагрузка ожидается, можно частенько решить есть ли проблема, там ли она, где кажется, и прочее.
После этого ничего не мешает закрыть это окошко и смотреть на пакеты. Но зачем добровольно отказываться от предложения посмотреть на полезную нагрузку перед тем, как искать флаги в пакетах (то бишь использовать Conversation Filter супротив Follow для TCP соединения) мне решительно непонятно.
Это работает только когда известно какая полезная нагрузка ожидалась…
Но даже и в этом случае. Вот вы заметили что полезная нагрузка от сервера пришла правильная, но обрезанная. Кто в этом виноват — клиент или сервер? Кто первым оборвал соединение-то? Все равно же придется лезть смотреть пакеты…
Но даже и в этом случае. Вот вы заметили что полезная нагрузка от сервера пришла правильная, но обрезанная. Кто в этом виноват — клиент или сервер? Кто первым оборвал соединение-то? Все равно же придется лезть смотреть пакеты…
Конечно придется. Закрываете окошко с полезной нагрузкой — получаете то же, что и при Conversation Filter. Дел на секунду.
Но зато видно не только, кто первый закрыл, но и кто последний чего-то послал (тоже бывает полезно). Да и тупо меньше шансов промахнуться и фильтрануть не то соединение, если их там много всяких бегает.
Я не говорю, что пакеты глядеть не надо — конечно надо. Кто закрыл, какие таймстемпы, есть ли жопа в сети. Просто конкретный случай — Follow не хуже, чем Conversation.
Но зато видно не только, кто первый закрыл, но и кто последний чего-то послал (тоже бывает полезно). Да и тупо меньше шансов промахнуться и фильтрануть не то соединение, если их там много всяких бегает.
Я не говорю, что пакеты глядеть не надо — конечно надо. Кто закрыл, какие таймстемпы, есть ли жопа в сети. Просто конкретный случай — Follow не хуже, чем Conversation.
Эх, если бы он еще умел открыть .CAP файл гигов на 60 и не упасть при этом. Вот какого хрена он пытается его весь в память затянуть, а?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практические приёмы работы в Wireshark