Мой вопрос может быть довольно простым, основанным на TCP / IP / маршрутизаторе, но мне нужно выразить его в терминах пингплоттера приложения Winpcap, который я использовал.
Одной из функций, которые я использовал на последнем месте работы, было использование этого Win32-приложения PingPlotter для проверки потери пакетов TCP / IP и времени передачи для пакетов размером, скажем, 2000 байтов.
Теперь, чтобы включить эту функцию, нужно использовать драйвер Winpcap.
Это действительно похоже на черную магию: как можно выполнить тестирование случайной потери пакетов TCP / IP на удаленном сервере, когда принимающее приложение не находится на другой стороне?
Это просто поиск пакетов tcp / ip packet ack / nack и анализ стабильности IP на более низком уровне анализа протокола? Печатая свой вопрос, я, возможно, отвечаю на свой вопрос, но я действительно не понимаю никаких деталей, так что приятно проверить или исправить.
Моя вторая часть вопроса заключается в следующем: инструмент может создавать хорошие графики потери пакетов моего тестового пакета tcp / ip для каждого перехода на tracert.
На целевой сервер, который, как я знаю, является SQL-сервером, к которому я могу подключиться, он, по-видимому, не выполняет каждый пакет, хотя все переходы tracert, похоже, доставляются нормально. Могу ли я этого ожидать, если на машине установлен программный брандмауэр на базе операционной системы с некоторым описанием, который регулярно встречается на практике?
Отмечу, что PingPlotter в основном тестирует порт 80.
Есть ли у кого-нибудь еще какие-либо предложения, как мне лучше протестировать подключение клиента к серверу? Мы получаем сообщения из клиентской библиотеки SQL Server о том, что пакеты keep-alive иногда пропадают, поэтому я хотел настроить тестирование пакетов tcp / ip и нарисовать красивый график потери пакетов и времени передачи для пакета размером 1 КБ, отслеживаемого с ночевкой.
На последнем месте работы я сделал это и обнаружил много проблем, но неспособность проверить пакет tcp / ip, отправленный на порт 80, немного мешает, так как он немедленно сообщает о 100% потере пакетов, несмотря на то, что функционирует как рабочий и доступный SQL Server.
Не используйте для тестирования пакет размером 2000 байт. 2000 байтов могут быть больше, чем MTU некоторых устройств, что заставляет их фрагментировать / отбрасывать пакеты, что не даст вам четкого представления о потерях передачи только из-за ошибки канала.
Для мониторинга потери пакетов от клиента к серверу в беспроводных сетях с плохой связью я иногда просто использую ping. Команда Linux ping дает хорошее резюме в конце, например
--- www.l.google.com ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 8999ms
rtt min/avg/max/mdev = 102.921/123.423/144.075/12.673 ms
Таким образом, вы можете оставить ping включенным на ночь, а когда вы закончите ping, Ctrl + C тогда вы сможете увидеть процент потери пакетов и т. д.
Это также не лучший способ, поскольку это может быть односторонняя проблема в канале. Таким образом, пакеты могут достигать пункта назначения, но по некоторым причинам ответы могут теряться. В таких случаях работает (по назначению)
tcpdump -v -i eth0 'icmp'
чтобы увидеть, доходят ли запросы ping до места назначения, помогает прояснить ситуацию.
Если по какой-либо причине клиент Linux недоступен, попробуйте установить cygwin и используйте cygwin ping. Это может быть то же самое, что пинг Linux, и в конце вы должны увидеть статистику.
Нашел эта ссылка об использовании порта PingPlotter. Похоже, что TCP / IP «Ping», о котором вы говорите, просто отправляет TCP SYN на указанный порт и ждет ACK. Итак, если ваш сервер не отвечает на порт 80 (http), вы можете попробовать порт, который прослушивает служба SQL (1433 для MSSQL, 3306 для MySQL).