> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/ru/concepts/latency-jitter-packet-loss.md).

# Задержка, джиттер и потери пакетов

Ваш тест скорости показывает 500 Мбит/с. Но видеозвонок всё равно прерывается. Как это может быть одновременно правдой?

Потому что скорость — лишь один аспект соединения, и часто не тот, что важен. Обычно разницу объясняют ещё три показателя.

## Три показателя простыми словами

Представьте, что вы отправили письмо и ждёте ответа.

**Задержка** — это время, которое занимает путь туда и обратно. Вы отправляете, они отвечают, ответ приходит. Измеряется в миллисекундах (мс). Именно это показывает ping-тест. Низкая задержка означает, что соединение кажется отзывчивым.

**Джиттер** — это то, насколько меняется время пути туда и обратно. Если ответы приходят через 20 мс, потом через 22 мс, потом через 21 мс, передача надёжна. Если они приходят через 20 мс, потом через 90 мс, потом через 15 мс, значит что-то нестабильно — хотя среднее значение выглядит нормально. Джиттер — это величина этого разброса, тоже в миллисекундах.

**Потеря пакетов** — это письма, которые вообще не доходят. Данные передаются маленькими частями, называемыми пакетами, и часть из них может быть потеряна по пути. Измеряется в процентах. Потерянные части обычно отправляются заново, а это занимает время; для живого аудио и видео времени на повторную отправку нет, поэтому пропуск просто слышен.

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

| Показатель             | На какой вопрос отвечает             | Единица измерения | Что портится                                          |
| ---------------------- | ------------------------------------ | ----------------- | ----------------------------------------------------- |
| Задержка               | Сколько времени до получения ответа? | мс                | Всё ощущается медленным; игры становятся непригодными |
| Джиттер                | Насколько стабильна задержка?        | мс                | Рваные, роботизированные голосовые звонки             |
| Потеря пакетов         | Сколько не доходит вовсе?            | %                 | Заикания, зависания, пропадания                       |
| Пропускная способность | Сколько помещается одновременно?     | Мбит/с            | Медленные загрузки; видео низкого качества            |

## Почему задержка — это не скорость

Это самая полезная мысль на этой странице.

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

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

Так что переход на более быстрый тариф не исправит лаги в игре на далёком сервере. Зато он сократит время загрузки больших файлов. Это разные проблемы.

## Что считается хорошим

Осторожно относитесь к любым единым порогам, включая эти. Что считается приемлемым, сильно зависит от того, чем вы занимаетесь, как далеко находится другой конец и какую технологию подключения вы используете. Круговой путь в 60 мс до сервера на другом континенте — отлично; те же 60 мс до сервера в вашем городе указывают на проблему. Мобильные и спутниковые подключения работают в совершенно других диапазонах, чем оптоволокно.

С учётом этой оговорки, вот грубые ориентиры для фиксированного домашнего соединения с достаточно близким сервером:

|                | Хорошо        | Допустимо   | Проблемно     |
| -------------- | ------------- | ----------- | ------------- |
| Задержка       | менее \~30 мс | \~30–100 мс | выше \~150 мс |
| Джиттер        | менее \~10 мс | \~10–30 мс  | выше \~30 мс  |
| Потеря пакетов | 0%            | менее \~1%  | выше \~2–3%   |

Две вещи важнее точных цифр.

Во-первых, **сравнивайте с собой**. Если соединение обычно показывает 18 мс, а сегодня — 90 мс, значит есть проблема, какой бы ни была таблица. Собственный базовый уровень — самый полезный ориентир, который у вас есть.

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

## Откуда на самом деле берётся задержка

Путь туда и обратно — это не одна задержка, а несколько, сложенных вместе.

* **Расстояние.** Неизбежная часть. Сигналы распространяются с конечной скоростью, а реальные оптоволоконные маршруты длиннее прямой линии на карте.
* **Переходы.** Каждый маршрутизатор на пути тратит мгновение, чтобы проверить и переслать каждый пакет. Маршрут с тридцатью переходами стоит дороже, чем маршрут с восемью.
* **Очереди.** Когда канал загружен сильнее, чем может обслужить, пакеты ждут в очереди. Это самый большой и самый переменный вклад на перегруженном соединении и главный источник джиттера.
* **Последняя миля.** Технология, соединяющая ваше здание, имеет значение. Оптоволокно добавляет совсем немного; старые медные и кабельные технологии — больше; мобильные и спутниковые — значительно больше.
* **Удалённый конец.** Самому серверу нужно время на обработку перед ответом. Медленное приложение может выглядеть точно так же, как медленная сеть.

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

## Что портит каждый из них

**Игры больше всего убивает задержка, а затем потеря пакетов.** Соревновательным играм нужно, чтобы ваш ввод дошёл до сервера, а результат вернулся, пока момент ещё не прошёл. Пропускная способность почти не важна — игры передают крошечные объёмы данных. Поэтому игрок на скромном соединении рядом с сервером побеждает игрока на очень быстром соединении, находящемся далеко. Потеря пакетов проявляется как rubber-banding, когда объекты рывком возвращаются туда, где были.

**Голосовые и видеозвонки больше всего убивает джиттер, а затем потеря пакетов.** Звук должен воспроизводиться с постоянной скоростью. Приложения держат небольшой буфер, чтобы сгладить колебания, но если поступление становится слишком нерегулярным, буфер опустошается, и появляется знакомый роботизированный, прерывистый голос. Потерянные пакеты нельзя отправить заново достаточно быстро, поэтому они превращаются в короткие паузы. Звонкам требуется удивительно мало пропускной способности, поэтому они ломаются даже на соединениях, которые по тесту кажутся быстрыми. См. [Что такое WebRTC?](/knowledge-base/ru/concepts/what-is-webrtc.md).

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

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

## Распространённые заблуждения

**«Больше Мбит/с устраняет лаги».** Нет. Лаг — это задержка. Пропускная способность и задержка — разные свойства канала.

**«Требуется нулевая потеря пакетов».** Редкие потери — нормальны и незаметны. Постоянная потеря свыше одного-двух процентов уже ухудшает работу — а потеря, которая видна только на одном участке traceroute, часто означает, что этот маршрутизатор понижает приоритет собственных ответов, а не то, что трафик действительно теряется.

**«Один тест говорит мне о качестве соединения».** Одно измерение — это снимок одного момента на одном маршруте. Повторяйте его в разное время и для разных направлений, прежде чем делать выводы.

**«Высокий пинг к одному сайту означает, что моё соединение плохое».** Это может означать, что сам сайт далеко или что один маршрут перегружен. Тестирование нескольких направлений помогает отличить локальную проблему от проблемы на маршруте.

{% hint style="info" %}
**Посмотрите сами в MyIP**

Инструмент [Тест скорости](/knowledge-base/ru/network-tests/speed-test.md) показывает не только показатели загрузки и отдачи: он также отображает задержку, джиттер и задержку, измеренную *при загруженном соединении* — а затем переводит всё это в оценки качества для видеостриминга, игр и видеочатов. Эта последняя строка и есть суть этой страницы — одним взглядом.

Чтобы увидеть, как эти числа меняются с расстоянием, [Глобальный тест задержки](/knowledge-base/ru/network-tests/global-latency-test.md) пингует ваш адрес с пробных узлов по всему миру. А когда конкретный маршрут выглядит плохо, [MTR-тест](/knowledge-base/ru/network-tests/mtr-test.md) разбивает путь на переходы и показывает задержку и потери на каждом из них, чтобы было видно, где начинается проблема.
{% endhint %}

## Связанные понятия

* [Что такое ASN?](/knowledge-base/ru/concepts/what-is-an-asn.md) — почему маршрут между сетями определяет вашу задержку
* [Что такое WebRTC?](/knowledge-base/ru/concepts/what-is-webrtc.md) — почему звонки так чувствительны к джиттеру
* [Публичные, частные и CGNAT-адреса](/knowledge-base/ru/concepts/public-private-cgnat.md) — дополнительные переходы между вами и интернетом
* [Почему мой интернет медленный?](/knowledge-base/ru/diagnose/why-is-my-internet-slow.md) — пошаговая диагностика


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/ru/concepts/latency-jitter-packet-loss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.