Я пытаюсь воспроизвести проблему производительности, связанную с сетью, с удаленного сайта на облачную систему, за которую я отвечаю. Они получают ужасную производительность из своего местоположения, я получаю прекрасную производительность из своего местоположения. У меня есть аппаратный эмулятор WAN (в данном случае - Linktropy Mini2), который я могу использовать, чтобы смоделировать их сеть, чтобы воспроизвести проблему. Но сначала мне нужно знать характеристики производительности сети между ними и сервером.
Что мне нужно, так это краткий способ заставить обычного пользователя работать со своего ПК или что-то еще, что может суммировать пропускную способность, задержку, потерю пакетов и все, что я могу получить. В идеале они должны были бы просто ввести DNS-имя и сгенерировать несколько чисел, которые они могли бы мне скормить - я не могу заставить их выполнять все виды технической работы, заставлять их находить Linux и т.
Что было бы хорошим инструментом для характеристики сети между двумя точками?
iperf является бесплатным / с открытым исходным кодом, работает в Windows и * NIX, поддерживает TCP и UDP для проверки пропускной способности, задержки, джиттера, потери пакетов и т. д.
Есть ли у них другие проблемы с сетью? например упал широкополосный доступ, низкая производительность в целом и т.д.
Вы можете попробовать несколько запусков speedtest.net до ближайшего места к облачной системе. Pingtest.net несколько запускает.
Затем настройте ping-плоттер для проверки связи с облачной системой, которая даст вам представление о потере пакетов и т. Д.
Вполне возможно, что у них есть другие проблемы или маршрутизатор между ними и удаленной системой неисправен или неправильно настроен. Это может быть даже собственный роутер.
Похоже, Qcheck может быть инструментом для работы.
Попробуйте mtr, он отлично подходит для таких вещей. Nmap может помочь со сканированием сети, чтобы лучше понять ее.
Если вы хотите проанализировать пути, используемые в traceroute, вы можете обнаружить, что посередине есть хитрый провайдер, где-то сбрасывает много пакетов, или выбирается неоптимальный путь.
Вы могли бы использовать бин. У него есть ограничения - он использует ICMP и не может работать непрерывно, если клиент использует маршрутизатор NAT, но вы должны иметь возможность получить оценку пропускной способности. Если производительность не всегда плохая, вам может потребоваться какое-то ведение журнала в течение длительного периода времени.
Если вы подозреваете, что задержка или потеря пакетов являются причиной плохой производительности, вы можете с таким же успехом проверить поток управления TCP после захвата пакета - если вы видите медленный запуск или повторную передачу с вашей стороны, вы точно знаете.