Как измерить сетевую базу облачного Mac и найти проблему MTU

Если удалённый сеанс начинает терять кадры, а скорость загрузки зависимостей постоянно меняется, не спешите переустанавливать инструменты и не делайте выводы по одному тесту скорости. На работу облачного Mac одновременно влияют пропускная способность, задержка под нагрузкой, DNS, маршрутизация и MTU пути. Правильный подход — зафиксировать условия тестирования, собрать воспроизводимую базовую линию, а затем с помощью сравнительных тестов определить, где возникает проблема: в локальной сети пользователя, на пути передачи данных или из-за конкуренции задач на удалённой машине.

Сначала зафиксируйте условия тестирования

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

Сначала получите базовые показатели в состоянии простоя, а затем повторите измерения во время выполнения реальной задачи. Каждую серию запускайте не менее трёх раз и сохраняйте медианный результат, а не единичный пик. Узел SoarMac следует выбирать из конфигураций, доступных в консоли на момент тестирования. При сравнении разных регионов локальная сеть и тестовая цель также должны оставаться неизменными.

mkdir -p "$HOME/network-baseline"
cd "$HOME/network-baseline"

date -u
sw_vers
scutil --nwi
route -n get default
networkQuality -v | tee "networkquality-$(date +%Y%m%d-%H%M%S).log"

Команда scutil --nwi позволяет определить интерфейс, через который фактически передаётся трафик, а route показывает маршрут по умолчанию. Если в системе одновременно присутствуют проводной, беспроводной и туннельный интерфейсы, по одному лишь индикатору подключения в строке меню легко ошибиться в определении пути.

Цель базовой линии — не доказать, что сеть «быстрая», а получить набор данных, который можно сравнивать до и после сбоя, в простое и под нагрузкой, при прямом и туннельном подключении.

Оценивайте одновременно пропускную способность и отклик под нагрузкой

networkQuality показывает скорость загрузки, скорость отправки и отзывчивость соединения. Для синхронизации больших файлов важнее стабильная пропускная способность, а для удалённого рабочего стола, ввода команд по SSH и отладки — время двустороннего отклика под нагрузкой. Высокая пропускная способность сама по себе не гарантирует плавной интерактивной работы.

Выявляйте очереди с помощью параллельных измерений

Откройте два терминала. В первом запустите networkQuality -v, а во втором непрерывно отправляйте ping-запросы одной и той же цели:

export TARGET_HOST="your-controlled-endpoint"
ping -c 40 "$TARGET_HOST" | tee ping-under-load.log

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

Проверяйте DNS и маршрутизацию по отдельности

Сбой загрузки зависимостей не обязательно связан с пропускной способностью. Сначала проверьте, какие резолверы система использует фактически, а не ограничивайтесь просмотром интерфейса сетевых настроек:

scutil --dns | tee dns-state.log
dscacheutil -q host -a name "$TARGET_HOST"
route -n get "$TARGET_HOST" | tee target-route.log

scutil --dns может показать несколько групп резолверов и соответствующих им доменов. Если доступ по IP из командной строки работает, но имена узлов разрешаются нестабильно, сначала устраните проблему DNS. Если разрешение имён работает нормально, но трафик направляется через неожиданный туннельный интерфейс, проверьте приоритеты маршрутов. Сохраните вывод до изменения конфигурации и повторите тест теми же командами после него. Не меняйте несколько переменных одновременно.

Проверяйте порт, а не только ping

Некоторые цели не отвечают на ICMP, поэтому неудачный ping не означает, что служба недоступна. Для контролируемой вами цели проверьте фактический рабочий порт:

nc -vz -G 5 "$TARGET_HOST" 443

Если соединение с портом устанавливается, а ping не получает ответа, значит по меньшей мере путь для установления TCP-соединения работает. Если подключение к порту завершается по тайм-ауту, продолжите проверку маршрутов, правил межсетевого экрана и туннельного выхода. Не исключайте периодический сбой только потому, что браузеру один раз удалось открыть страницу.

Проверяйте MTU пути, последовательно увеличивая нагрузку

VPN и дополнительная инкапсуляция уменьшают доступный размер полезной нагрузки. Типичные признаки — небольшие запросы работают нормально, а передача больших файлов останавливается либо после установления соединения долго не появляется никакого прогресса. В macOS команда ping позволяет запретить фрагментацию и изменять размер полезной нагрузки:

export TARGET_IPV4="192.0.2.10"

for size in 1200 1300 1400 1450 1472; do
  echo "payload=$size"
  ping -D -c 3 -s "$size" "$TARGET_IPV4"
done

Замените адрес из примера на контролируемую вами IPv4-цель. Если пакеты с меньшей полезной нагрузкой проходят стабильно, а с большей постоянно теряются, зафиксируйте пороговое значение и повторите тест отдельно при прямом и туннельном подключении. Не уменьшайте MTU удалённого интерфейса сразу. Сначала определите, на каком участке пути действует ограничение, иначе изменение может скрыть настоящую проблему и повлиять на другие соединения.

Создайте проверяемый протокол приёмки

Полная запись должна включать версию системы, интерфейс, маршрут по умолчанию, состояние DNS, результаты networkQuality в простое и под нагрузкой, ping одной и той же цели, а также пороговое значение MTU. Перед публикацией удалите или замаскируйте конфиденциальные адреса и внутренние доменные имена, но сохраните время, параметры команд и условия тестирования.

После исправления повторите команды в исходном порядке. Не меняйте цель и не выбирайте только лучший результат. Для приёмки можно использовать следующие критерии: записаны показатели как в простое, так и под нагрузкой; во время удалённой работы нет устойчивой высокой задержки; разрешение доменного имени и подключение к рабочему порту стабильно выполняются; передача больших файлов завершается без сбоев; различия между прямым и туннельным подключением получили объяснение. Только такие выводы стоит добавлять в заявку или командное руководство по эксплуатации — они также позволят при следующем сбое сразу сопоставить новые результаты с базовой линией.

Часто задаваемые вопросы