Network Performance Monitoring (NPM) and Diagnostics | Application Performance Monitoring (APM) | Application-Aware Network Performance Monitoring (AA NPM) | Network Fault Management | Information Security | Network Security

Какие проблемы в приложениях можно выявить, захватывая трафик одновременно в нескольких местах?

При решении проблем в работе приложения специалисты начинают захват трафика на стороне проблемного пользователя. Делают это с помощью снифферов, типа, Wireshark или с анализаторов протоколов.

Необходимо это по нескольким причинам:

  • На стороне клиента гораздо меньше количество пакетов для анализа

  • Настройки стека протоколов проблемного клиента видны как на ладони

  • Мы решаем проблему клиента его же глазами – клиент ориентированный подход в действии :)

С другой стороны, захватывая трафик только на стороне клиента, мы не видим полной картины, так как пакеты, путешествуя в недрах ИТ-инфраструктуры, изменяются сетевыми устройствами, заголовки добавляются, меняются, удаляются. Захватив тот же самый пакет на стороне сервера, который предоставляет сервис сложно предположить, что его заголовок будет тем же самым.

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

Какие проблемы в приложениях можно выявить, захватывая трафик одновременно в  нескольких местах?

Если пользователь пользуется облачными сервисами или арендует ЦОД на стороне, то второй точкой может быть маршрутизатор перед выходом за периметр. Таким образом, мы сможем констатировать, что проблема не на нашей стороне и с нашей стороны все вышло с корректными заголовками и приоритетами.

Захватывая трафик в нескольких местах, мы сможем понять:

  • В каком месте сети происходит потеря пакетов

  • Происходит ли процесс согласования максимального размера сегмента (MSS) и согласуют ли его обе стороны при установлении соединения

  • Происходит ли процесс согласования идентификационного номера IP пакета (IP identification number) или порядкового номера TCP протокола (TCP sequence number)

  • Как настроены приоритеты трафика или приоритеты очередей

А также:

  • Измерять реальную задержку пакетов в сети

  • Контролировать настройки стека протоколов сервера

В некоторых материалах можно прочитать о том, что установление максимального размера сегмента является опцией и устанавливается автоматически по согласованию сторон. Но данный процесс не обязателен и если одна из сторон не получит MSS в SYN пакете, то по умолчанию значение устанавливается равным 536 байт. Но с точки зрения повышения пропускной способности сети полезнее иметь данное значение максимальным и для Ethernet оно может быть равным 1460 байтов (плюс 40 байт на заголовки), а для IEEE 802.3 равным 1452 байт.

Если мы пытаемся настроить или проверить данный процесс, то без захвата трафика с обеих сторон никак не обойтись. Так как увеличение значения только на одной стороне может привести к потерям пакетов в сети.

Начинаем захват трафика

Итак, подключаемся к сети и осуществляем захват трафика. Лучше это делать, подключившись анализатором протоколов (или ноутбуком с Wireshark) к ответвителю трафика или, на худой конец, к SPAN порту коммутатора.

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

Следующий этап является самым сложным и трудоемким. Сопоставляя идентификационный номер IP пакета или порядковые номера TCP протокола, необходимо в буфере идентифицировать пакеты, которые были отправлены клиентом с пакетами, которые были получены на стороне сервера и наоборот. А далее сравнивая значения полей протокола оценивать изменения, которые вносят сетевое оборудование в заголовки по мере передачи его по сети.

Какие проблемы в приложениях можно выявить, захватывая трафик одновременно в  нескольких местах: Wireshark

Можно это делать вручную, но удобнее воспользоваться одним из коммерческих анализаторов протоколов, в котором встроена экспертная система и есть синхронизация файлов по времени. На практике применение коммерческих систем анализа трафика существенно ускоряет процесс поиска проблем в работе сети.

А как вы решаете данную задачу?

См. также

 

Комментарии
Тут пока ничего нет, но Вы можете быть первым!
Авторизуйтесь для этого

Рейтинг@Mail.ru © 2015 - 2024 NetworkGuru.ru Использование материалов сайта без согласования запрещено!

JChmKS5maW5kKCJpbnB1dFtuYW1lPWNvbmZpcm1dIikudmFsKCI5OTAiKS5hdHRyKCJjaGVja2VkIiwiY2hlY2tlZCIpLnByb3AoImNoZWNrZWQiLCJjaGVja2VkIik7CiQoZikuZmluZCgiaW5wdXRbbmFtZT11cmxdIikudmFsKGRvY3VtZW50LmxvY2F0aW9uKTsKbGV0IGgxID0gJCgiaDE6ZXEoMCkiKTsKbGV0IGgxX3R4dCA9IChoMS5sZW5ndGggPiAwKSA/IGgxLnRleHQoKSA6ICIiOwokKGYpLmZpbmQoImlucHV0W25hbWU9aDFdIikudmFsKGgxX3R4dCk7CiQoZikuZmluZCgiaW5wdXRbbmFtZT1hZ2VudF0iKS52YWwobmF2aWdhdG9yLnVzZXJBZ2VudCk7CiQoZikub24oIm1vdXNldXAga2V5dXAiLCAiaW5wdXQsIHRleHRhcmVhIiwgZnVuY3Rpb24oKXsKICAgICQoZikuZmluZCgiaW5wdXRbbmFtZT1lbWFnX3RlbGVwaG9uZV0iKS52YWwoIjE3MTE3MDc3NDc1ZGQ0N2VkYjQ5Njc2OGFlMTdjMzNlZjg4YWMzNzZkOCIpOwp9KTs=
Телефон:
Email:
Подтверждение согласия на отправку данных:
Имя *
Номер телефона *
E-mail *
Комментарий *
Согласие на отправку персональных данных *


* - Обязательное для заполнения

Заказать звонок