Лаги в голосовом чате — это три разные болезни с разными лекарствами. Задержка, потеря пакетов и джиттер проявляются по-разному, меряются разными цифрами и чинятся в разных местах. Чинить «лаги вообще» бесполезно — сначала нужно поставить диагноз, и TeamSpeak даёт для этого все инструменты прямо в клиенте.
Если связь не лагает, а вообще не устанавливается — это другая статья: разбор ошибок подключения.
Три болезни: как отличить по симптомам
| Симптом | Болезнь | Метрика в клиенте |
|---|---|---|
| Собеседники отвечают с опозданием, перебивают друг друга | Высокая задержка | Ping |
| Звук рвётся, выпадают слоги и слова | Потеря пакетов | Packet loss |
| Голос плавает, «булькает», звучит роботом | Джиттер | Число после «±» рядом с пингом |
Почему это три разные проблемы. Голос в TeamSpeak идёт по UDP — протоколу без повторной доставки. Пакет либо пришёл вовремя, либо бесполезен: досылать его поздно, момент воспроизведения прошёл.
Задержка — пакеты доходят все, но долго. Разговор превращается в рацию: вы закончили фразу, собеседник начал отвечать, а вы уже говорите следующую. Звук при этом чистый.
Потеря пакетов — пакеты не доходят вовсе. Каждый потерянный — дырка в звуке. При потерях 1–2 % слышны редкие щелчки, при 5–10 % выпадают слоги, дальше речь становится неразборчивой.
Джиттер — пакеты доходят, но неравномерно: один за 30 мс, следующий за 80. Клиент сглаживает это буфером — накапливает пакеты и проигрывает с небольшой задержкой. Когда колебания сильнее буфера, звук плавает и металлизируется. Коварство джиттера в том, что средний пинг при нём может быть отличным.
Где смотреть цифры: окно Connection Info
Кликните правой кнопкой по своему нику в дереве каналов и выберите Connection Info. То же окно открывается для любого участника — это пригодится для диагностики. Для сервера целиком есть отдельное окно: правый клик по имени сервера → Server Connection Info.
Что показывает окно:
- Ping — средняя задержка туда-обратно до сервера, в миллисекундах. Рядом через «±» — отклонение: насколько пинг скачет вокруг среднего. Это и есть мера джиттера.
- Packet loss — оценка доли потерянных пакетов, отдельно входящих (in) и исходящих (out). Разделение важно: потери «in» — пакеты теряются на пути от сервера к вам, потери «out» — от вас к серверу. Это разные маршруты и часто разные виновники.
- Счётчики пакетов и байтов по типам трафика — для диагностики лагов они не нужны.
Ориентиры — из практики, официальных норм TeamSpeak не публикует:
| Метрика | Хорошо | Терпимо | Проблема |
|---|---|---|---|
| Ping | до 50 мс | 50–100 мс | от 150 мс |
| Отклонение (±) | единицы мс | до 10–20 мс | десятки мс |
| Packet loss | 0 % | до 1–2 % | от 5 % |
Смотрите цифры в момент лага, а не после: показатели усредняются, и короткий всплеск через минуту растворится в благополучном среднем.
Минутный тест: у всех или у одного
Прежде чем копать настройки, откройте Connection Info двум-трём участникам и сравните.
Плохо у всех сразу — виноват сервер или его канал: перегрузка, узкая полоса, проблемы у хостера. Клиентские настройки можно не трогать.
Плохо у одного — проблема на его стороне или на его маршруте до сервера. Остальным чинить нечего.
Плохо у участников из одного региона, у остальных нормально — маршрут между этим регионом и сервером. Это аргумент за смену локации сервера, о ней ниже.
Этот тест занимает минуту и экономит часы: половина «лагающих серверов» при проверке оказывается одним участником на Wi-Fi.
Причины на стороне клиента
Wi-Fi. Главный производитель джиттера и потерь в домашних сетях. Радиоэфир делится со всеми устройствами и соседскими сетями, пакеты ждут своей очереди и теряются при помехах. Проверка стоит пять минут: подключите компьютер кабелем и посмотрите на те же цифры. Если по кабелю чисто — диагноз готов. Когда кабель невозможен, помогает диапазон 5 ГГц и сокращение расстояния до роутера, но кабель всё равно лучше любого Wi-Fi.
Загруженный канал. Торренты, стрим, облачная синхронизация, обновление игры в фоне — всё это забивает полосу, и голосовые пакеты встают в очередь. Особенно страдает исходящее направление: у домашних тарифов оно в разы уже входящего, и один активный торрент с раздачей давит ваш микрофонный поток целиком. Симптом в цифрах: у вас растут потери «out», собеседники слышат вас рывками, а вы их — нормально. Проверка: выключить всё качающее и раздающее, посмотреть на цифры. Канал при этом общий на квартиру — виноватым может быть чужой телевизор со стримингом.
VPN на пути. VPN добавляет свой участок маршрута и свою обработку каждого пакета. К пингу прибавляется дорога до VPN-сервера, а перегруженный VPN-узел добавляет джиттер. Если VPN для TeamSpeak не обязателен — исключите его из маршрута или выберите выходную точку ближе к серверу. Проверка та же: сравнить цифры с VPN и без.
Слабый роутер. Дешёвый или старый роутер захлёбывается при множестве одновременных соединений — те же торренты держат их тысячами. Голосовые пакеты теряются в переполненных очередях устройства. Симптомы: лаги при любой заметной нагрузке на сеть, лечится перезагрузкой на время. Если в роутере есть QoS — приоритизация трафика — включите её; радикальное лечение — роутер поновее.
Причины на стороне сервера
Узкий исходящий канал. Сервер TeamSpeak не микширует звук — каждому слушателю уходит отдельная копия потока каждого говорящего. Исходящий трафик растёт как произведение: полный канал на 30 человек с двумя-тремя говорящими — это уже 3–5 Мбит/с наружу. Расчёт по официальной формуле и таблицы полосы — в статье о выборе VDS. Симптом узкого канала: лаги появляются на общих сборах, когда в одном канале много людей, и исчезают, когда все расходятся по маленьким каналам.
Перегрузка машины. Сам процесс TeamSpeak почти не ест CPU, но на дешёвом VDS с общими ядрами процессорное время отбирают соседи по физическому хосту. Пакеты уходят рывками — это слышно как заикание и джиттер при идеальном пинге. Проверить изнутри: top на сервере — смотрите не только загрузку, но и показатель steal (st) — это время, отобранное гипервизором. Стабильные единицы процентов steal на «пустом» сервере — признак оверселлинга, и лечится он только сменой тарифа или хостера.
Плохая локация. Пинг — это в первую очередь география плюс качество маршрутов. Сервер в Германии для команды из Сибири — это 80–120 мс всем и каждому, и никакое железо этого не исправит. Отдельный случай — хостер, который режет UDP-трафик своими анти-DDoS-фильтрами: снаружи выглядит как необъяснимые потери при нормальном пинге.
Локация: география важнее мощности
Задержку нельзя купить процессором — только расположением. Сигнал физически идёт по оптике через конкретные магистрали, и каждый лишний узел маршрута добавляет миллисекунды.
Правило выбора: сервер ставят там, где живёт большинство участников, а не там, где живёт админ.
- Все в России и СНГ — Москва или Петербург: из большинства регионов 10–50 мс.
- Россия плюс Европа — Амстердам, Франкфурт или Хельсинки: из Москвы 30–50 мс, из Западной Европы 10–30 мс, приемлемо обеим сторонам.
- Разброс по миру — локация под ядро сообщества; остальным придётся мириться, и это честнее, чем всем плохо «посередине».
Проверять — измерением, а не по карте: у хостеров опубликованы тестовые IP площадок. Попросите нескольких участников из разных городов прогнать до них ping и сравните. Подробнее про выбор локации и остальные параметры VDS — в отдельной статье.
Проверка маршрута: ping и mtr
Когда цифры в клиенте плохие, а виновник не найден, смотрят на сам маршрут.
Длинный ping. Запустите на несколько минут и смотрите на разброс и потери:
ping -t адрес_сервера # Windows, остановка Ctrl+C
ping адрес_сервера # Linux/macOSВ конце вывода — статистика: минимум, максимум, среднее и процент потерь. Максимум, в разы превышающий минимум, — это и есть джиттер в сыром виде.
Трассировка с потерями. tracert в Windows и traceroute в Linux показывают маршрут, но по одному замеру на узел. Полезнее mtr (Linux/macOS) или WinMTR (Windows): они гоняют трассировку непрерывно и накапливают статистику потерь по каждому узлу:
mtr адрес_сервераКак читать результат — главная тонкость. Потери на промежуточном узле сами по себе ничего не доказывают. Маршрутизаторы отвечают на служебные запросы по остаточному принципу: транзитный трафик они пропускают полноценно, а на «прощупывание» отвечают когда не заняты. Узел с 30 % потерь посередине трассы, после которого все дальнейшие узлы чистые, — это здоровый маршрутизатор, которому некогда отвечать.
Настоящая проблема выглядит иначе: потери появляются на каком-то узле и сохраняются на всех последующих, включая конечный. Значит, пакеты действительно теряются начиная с этого участка. Если участок — сеть вашего провайдера, вывод mtr прикладывается к обращению в его поддержку; если сеть хостера — в поддержку хостера.
Учитывайте и ограничение метода: ping и mtr меряют служебный протокол ICMP, а голос ходит по UDP на порт 9987. Часть сетей обрабатывает их по-разному, поэтому финальный судья — не трассировка, а Packet loss в самом клиенте. Про порты и их проверку — справочник по портам.
Понизить битрейт кодека: когда помогает
Качество звука в TeamSpeak задаётся не в клиенте, а в настройках каждого канала: правый клик по каналу → Edit Channel → раздел Audio, кодек и ползунок качества 0–10. Актуальный кодек — Opus Voice; по документации TeamSpeak SDK его битрейт растёт с 4,1 Кбит/с на нуле до 45,1 Кбит/с на десятке, поверх добавляются накладные расходы протокола — около 18 Кбит/с на поток. Полная таблица битрейтов по ступеням — в справочнике по кодекам.
Понижение качества с 10 до 6–7 срезает чистый битрейт примерно на треть — с 45,1 до 28,7–32,8 Кбит/с. Это помогает ровно в одном случае: когда узкое место — пропускная способность. Узкий исходящий канал сервера, слабый мобильный интернет у участника, домашний сервер на тонком «уплинке» — везде, где потоки не влезают в полосу.
Что теряется: полнота звука. Речь остаётся разборчивой — Opus проектировался под голос на низких битрейтах, — но тембр беднеет, музыка и стримы звука деградируют заметно. Для игрового общения качество 6–7 — разумный компромисс; выкрученный на 10 ползунок в голосовом канале чаще дань перфекционизму, чем необходимость.
Чего понижение битрейта не лечит: потери на Wi-Fi, джиттер перегруженного сервера, длинный маршрут. Если цифры в Connection Info плохие при качестве 5 — крутить ползунок дальше бессмысленно, болезнь в другом месте.
Сервер дома: узкое место — канал вверх
Отдельный устойчивый сценарий: сервер стоит дома, вечером все собрались — и у всех участников разом потери и заикание, хотя интернет у хозяина «сто мегабит».
Разгадка в асимметрии. «100 Мбит/с» домашнего тарифа — это входящая скорость; исходящая обычно в разы меньше — 10–20 Мбит/с, а на мобильном интернете единицы. Серверу же нужен именно исходящий канал: он рассылает копию потока каждого говорящего каждому слушателю. Ограничитель домашнего сервера — именно upload.
Арифметика: канал на 20 человек с двумя говорящими — это около 2 Мбит/с исходящего потока непрерывно. На бумаге влезает даже в 10 Мбит/с, но канал общий: хозяин играет, стримит, на соседнем устройстве идёт бэкап в облако — и голосовые пакеты сервера конкурируют со всем этим за узкую исходящую полосу. Проигрывают все участники одновременно.
Что делать по нарастающей: убрать с домашнего канала фоновые загрузки на время игр; понизить битрейт каналов; включить на роутере QoS с приоритетом UDP-порта 9987. Постоянное решение — вынести сервер на VDS с симметричным каналом: младшие тарифы стоят 150–300 рублей в месяц, а заодно снимают проблемы динамического IP и проброса портов — сравнение домашнего хостинга с VDS разбирает это подробно.
Порядок действий при лагах: открыть Connection Info → определить болезнь по таблице симптомов → сравнить цифры у нескольких участников, чтобы понять, чья сторона виновата → чинить адресно. У клиента первые подозреваемые — Wi-Fi и забитый канал, у сервера — исходящая полоса, оверселлинг и локация. Если же соединение не лагает, а рвётся совсем или не устанавливается — это другой разбор, а проверка портов — в справочнике.