Джиттер и потери пакетов в вызове VPN: что сравнивать
Запаздывающая, но ровная речь и речь, распадающаяся на провалы, — это разные неисправности. Сравните статистику самого приложения, локальное радио и один загруженный путь.
Роботизированная речь и выпавшие слоги звучат по-разному, потому что это разные неисправности. Джиттер меняет момент прихода пакетов; потеря означает, что они не приходят вовсе. И то и другое может происходить, пока тест скорости показывает здоровое скачивание, ведь пропускная способность и своевременная доставка измеряют разные вещи. Сопоставьте доказательства со звуком, прежде чем менять любую настройку.
Почему запаздывающие и пропавшие пакеты звучат по-разному
Медиапоток покидает отправителя с постоянной скоростью, а реальные сети доставляют его с неравными интервалами. Приложения немного буферизуют, чтобы сгладить это, обменивая задержку на непрерывность: увеличьте буфер — разговор кажется медленным, уменьшите — появляются провалы. Пакет, пришедший после срока воспроизведения, фактически потерян, даже если его никогда не отбрасывали. Поэтому два соединения с одинаковой полосой могут давать совершенно разные вызовы.
Направление тоже важно. Входящие и исходящие медиапотоки могут идти разными путями, особенно когда одна сторона в мобильной сети.
Числа, которые нужно читать в плохом окне
Используйте статистику самого приложения там, где она есть, и читайте её, пока вызов плохой, а не после его окончания. Медиаретранслятор часто размещён на другом хосте, чем сайт сервиса, поэтому ping до главной страницы измеряет путь, который вызов не использует. Смотрите процент потерь, время кругового обхода и джиттер по отдельности и отмечайте, отправляет клиент проблему или получает. Переподключение VPN во время вызова — третье событие, которое нужно записать, а не смешивать с остальными.
Скриншоты панели статистики лучше воспоминания о вызове, потому что числа можно сравнить позже. Двадцать секунд процента потерь говорят, теряет ли путь пакеты сейчас, но не идут ли потери всплесками и когда они начались.
Для этого повторите измерение при втором условии, а не читайте одно окно как приговор. Два окна при разных условиях говорят больше, чем одно длинное окно без всяких условий.
Что джиттер-буфер делает со сроком
Джиттер-буфер ненадолго придерживает входящие пакеты, чтобы неравномерные приходы — колебание задержки, которое RFC 3393 определяет как метрику, — можно было воспроизводить по ровным часам. Размер буфера задаёт срок воспроизведения: каждый пакет, опоздавший к этому сроку, отбрасывается независимо от содержимого. Кодеки различаются тем, сколько они умеют скрывать, и кодек, интерполирующий пропущенный кадр, может скрыть одну потерю, но не серию. Поэтому один и тот же процент потерь даёт разное качество вызова на разных кодеках.
Настройка буфера — это компромисс, а не исправление. Больший буфер покупает непрерывность ценой задержки разговора, и он не может вернуть пакеты, пришедшие после срока.
Сравните радио и нагрузку перед выходом
Держите выход и приложение неизменными, меняя по одному локальному условию за раз. Сильный значок сигнала ничего не говорит о загруженности канала. Если проблема следует за одной комнатой или одной точкой доступа, следующее расследование — радио.
ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9
ping даёт число потерь и разброс, который можно сравнивать между условиями, а mtr показывает потери на каждом переходе вдоль пути. Промежуточные переходы, которые отказывают, пока следующие отвечают, обычно понижают приоритет ICMP, а не отбрасывают пользовательский трафик. Повторите оба, пока идёт контролируемая загрузка, потому что канал, хороший в покое и непригодный под нагрузкой, указывает на очереди, а не на VPN. Если проблему воспроизводит только одно условие, другое условие только что исключено.
Исправляйте только то, что подтверждает сравнение
Каждое сравнение подтверждает одно исправление, а применение нескольких сразу уничтожает доказательства. Слабый локальный путь требует лучшего канала или Ethernet, конкурирующий трафик требует планирования или дисциплины очереди, а один плохой выход требует сравнить другой выход при тех же условиях. Меняя транспорт VPN, сохраняйте профиль действительным и меняйте по одной переменной за раз. Повторно проверьте тот же разговор при обычной фоновой активности, вместо того чтобы судить об успехе по росту балла теста скорости.
Запишите направление, потери, джиттер, время кругового обхода и условие, при котором измерялось каждое. Эта запись превращает смутную жалобу на качество вызова в находку, с которой кто-то может работать. Храните её вместе с тикетом, чтобы следующее сравнение начиналось с той же базовой линии.