Почему в голосовых чатах хрипит звук и при чём тут UDP

Короткий ответ: голосовые чаты передают звук по UDP — протоколу, который ничего не пересылает повторно. Если пакет с кусочком вашей речи потерялся по дороге, программа просто пропускает этот кусочек и играет дальше. Ухо слышит это как хрип, дребезжание или роботизированный голос, а не как паузу или зависание.

Почему для голоса выбрали именно UDP

Есть два основных способа доставки данных в интернете — TCP и UDP. TCP гарантирует, что каждый байт дойдёт и в правильном порядке: если пакет потерялся, отправитель посылает его заново, а получатель ждёт. Для файла или веб-страницы это правильно — там нельзя потерять кусок текста или картинки.

Для голоса такая надёжность вредна. Пока TCP ждёт потерянный пакет и досылает его повторно, разговор уже ушёл на секунду вперёд, и повторно присланный кусок никому не нужен. Поэтому голосовые чаты используют UDP: пакеты летят без подтверждений, потерялся — забыли, зато без задержек на пересылку.

Что слышит ухо, когда пакеты теряются

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

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

При чём тут VPN

Здесь есть тонкость, о которой редко говорят. Многие протоколы для тоннелей построены на TCP: весь трафик, включая ваш голосовой UDP-поток, заворачивается в один TCP-канал и едет через тоннель как единый файл. Если в этом канале теряется хотя бы один пакет, весь тоннель ждёт его повторной отправки — и тормозит всё, что через него идёт, включая голос, который до этого прекрасно обходился без ожиданий.

Это называют эффектом "TCP поверх TCP": надёжность внутренней и внешней доставки складывается, а не помогает друг другу, и в сумме получается больше задержек, а не меньше. VPN может как снизить число потерянных пакетов на маршруте за счёт более прямого пути до сервера, так и добавить лишнюю причину для хрипа — зависит от того, какой транспорт несёт трафик и насколько стабилен канал до сервера.

Что реально влияет на качество звука

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

Что можно проверить самостоятельно:

• Подключиться к серверу ближе географически — меньше промежуточных узлов, меньше шансов на потери и джиттер. Если вы в европейской части, разница между Хельсинки или Франкфуртом и Лондоном может быть заметна на слух.
• Перейти с Wi-Fi на кабель или встать ближе к роутеру — на бытовом уровне пакеты чаще всего теряются именно на последнем беспроводном отрезке, а не где-то в середине маршрута.
• Закрыть фоновые загрузки и обновления на устройстве — они забирают канал и создают ту самую неравномерность задержки, из-за которой звук рвётся.

Если хрип остаётся что с VPN, что без него — дело не в тоннеле, а в самом канале до провайдера. Это тот редкий случай, когда никакой VPN не поможет: он передаёт данные, а не чинит слабый сигнал.