[{"data":1,"prerenderedAt":265},["ShallowReactive",2],{"article-84-tr":3,"related-84":105,"ArticleBody_vEHTabLVp0BK3FGZOo3nYwqXTnjCPN1nxNYDAF1D4":260},{"id":4,"title":5,"slug":6,"content":7,"metaTitle":5,"metaDescription":8,"coverUrl":9,"views":10,"likes":11,"createdAt":12,"updatedAt":13,"category":14,"tags":22,"author":9,"tableOfContents":43,"locale":102,"translated":103,"indexable":104},84,"Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat","pochemu-ping-nichego-ne-govorit-jitter-poteri-paketov-i-bufferbloat","# Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n\n`ping 12 ms`. Отлично же, канал шикарный.\n\nА потом созвон рассыпается на слоги, в игре персонаж телепортируется, страницы то грузятся мгновенно, то думают по три секунды. Идёте проверять - `ping` всё те же 12 мс. Идёте на спидтест - 300 Мбит. По всем приборам здорово, по факту пользоваться невозможно.\n\nТак вот, `ping` не сломан. Он честно показывает ровно одну цифру, а вам нужны три другие. И самое обидное - та единственная цифра, которую он показывает, для половины реальных задач вообще не главная.\n\nРазберём, что там на самом деле происходит: почему средний пинг скрывает всё интересное, почему ICMP - это в принципе не ваш трафик, откуда берётся jitter и как он превращается в рваный звук, почему один процент потерь роняет гигабитный канал до полутора мегабит, и что такое bufferbloat - беда, которую породили из лучших побуждений.\n\n**Кому пригодится:** если выбираете хостера и смотрите только на пинг из своего города; если сервис «то работает, то нет», а метрики зелёные; или если хочется наконец понять, что показывает `mtr` и почему там красное на середине пути.\n\n> Половина команд ниже пересекается с [чеклистом по проверке VPS](vps-oversell-proverka-resursov.md) - там про то, что вам дали по железу, а тут про то, что дали по сети.\n\n---\n\n## Содержание\n\n1. [Что на самом деле меряет ping](#что-на-самом-деле-меряет-ping)\n2. [ICMP это не ваш трафик](#icmp-это-не-ваш-трафик)\n3. [Jitter: почему рассыпается голос](#jitter-почему-рассыпается-голос)\n4. [Один процент потерь и мёртвый гигабит](#один-процент-потерь-и-мёртвый-гигабит)\n5. [Bufferbloat: беда от лишней памяти](#bufferbloat-беда-от-лишней-памяти)\n6. [Как читать mtr и не паниковать](#как-читать-mtr-и-не-паниковать)\n7. [Чем мерить по-настоящему](#чем-мерить-по-настоящему)\n8. [Что чинится, а что нет](#что-чинится-а-что-нет)\n9. [Какая метрика под какую задачу](#какая-метрика-под-какую-задачу)\n10. [Частые ошибки](#частые-ошибки)\n11. [Где это проверять](#где-это-проверять)\n12. [Короткий итог](#короткий-итог)\n\n[Источники](#источники)\n\n---\n\n## Что на самом деле меряет ping\n\nУтилита отправляет ICMP Echo Request, ждёт Echo Reply, засекает время. Получается **RTT** - время туда и обратно. Одно число, усреднённое по десятку пакетов.\n\nСмотрим на типичный вывод внимательнее, чем обычно:\n\n```\n--- 1.1.1.1 ping statistics ---\n100 packets transmitted, 100 received, 0% packet loss, time 20147ms\nrtt min/avg/max/mdev = 11.2/14.8/197.4/21.3 ms\n```\n\nВсе смотрят на `avg` - 14,8 мс, красота. А теперь гляньте на `max`: 197 мс. Какой-то пакет ехал в тринадцать раз дольше средней. Средняя это проглотила и не поперхнулась, потому что среднее так и работает: девяносто девять хороших замеров прячут один плохой.\n\nДля скачивания файла такой выброс не значит ничего. Для голосового звонка это щелчок в ухе.\n\n**`mdev`** - самое полезное поле, и самое игнорируемое. Формально «среднее отклонение», по факту iputils считает там обычное стандартное отклонение RTT. То есть насколько замеры разбросаны вокруг средней. Вот это уже близко к тому, что называют jitter'ом, хотя строго говоря не он (настоящий jitter по RFC 3550 считается по-другому - как сглаженное среднее разниц между соседними пакетами, а не как разброс вокруг центра). Для бытовой диагностики разница несущественная: если `mdev` заметно больше нуля, канал дёргается.\n\n### Четыре вещи, которые ping не покажет никогда\n\n**Он не различает направления.** RTT - это сумма. 100 мс могут быть двадцатью туда и восьмьюдесятью обратно, и это не редкость: маршруты в интернете асимметричны по умолчанию, обратный путь почти всегда идёт не через те же роутеры. А чинить надо тот, который тормозит. По RTT вы не поймёте какой.\n\n**Он врёт про ваш собственный Wi-Fi.** Беспроводная сеть добавляет свой разброс: повторы, коллизии, смена скорости на лету, энергосбережение на ноутбуке. Меряете пинг до сервера по вайфаю и половину результата приносите из соседней комнаты. Меряйте по проводу, иначе диагностируете свой роутер, а думаете, что диагностируете хостера.\n\n**Он молчит про поведение под нагрузкой.** Пустой канал отвечает за 12 мс. Начали качать - и стало 800. Обычный `ping` в простое этого не увидит вообще, а именно это состояние вы и ощущаете как «интернет тупит».\n\n**Десять пакетов - не статистика.** Дефолтный `ping` на винде шлёт четыре пакета, на линуксе гоняет до Ctrl+C, но обычно люди смотрят секунд пять. А те проблемы, которые и портят жизнь, вылезают раз в минуту. Гоняйте так:\n\n```bash\nping -c 300 -i 0.2 1.1.1.1\n```\n\nТриста пакетов с интервалом в 200 мс, минута работы. И смотреть надо на `max` и `mdev`, а не на `avg`.\n\n---\n\n## ICMP это не ваш трафик\n\nВот это, пожалуй, главное, что стоит унести из статьи. Вы меряете один протокол, а пользуетесь другим, и сеть относится к ним по-разному.\n\n**Причина первая: роутеры ICMP не любят.** Когда пакет просто проезжает через маршрутизатор, его обрабатывает специализированное железо на полной скорости порта. А когда роутеру надо самому ответить (на ping или на traceroute-зонд с истёкшим TTL) - это работа для процессора управляющей платы. Процессор там слабенький, и защищать его надо, иначе любой школьник положит железку одним скриптом. Поэтому на всех нормальных роутерах стоит ограничение: отвечаю на столько-то ICMP в секунду, остальное молча выкидываю.\n\nВ линуксе, кстати, это видно прямо в sysctl:\n\n```bash\nsysctl net.ipv4.icmp_ratelimit\n# net.ipv4.icmp_ratelimit = 1000\n```\n\nЗначение в миллисекундах: минимальный интервал между ответами определённых типов. Ваш сервер тоже так делает, просто вы об этом не думали.\n\nИтог: потери в ping'е могут означать «роутер поленился ответить», а транзитный трафик через него в это время шёл без единой потери на полной скорости.\n\n**Причина вторая: провайдеры режут ICMP как класс.** Не со зла, а потому что он не приносит денег и его удобно душить первым при перегрузке. Некоторые вообще ставят ему низший приоритет в очередях. Ваш пинг деградирует первым, хотя реальный трафик ещё в порядке. Бывает и наоборот: у хостера ICMP пролетает шикарно, а TCP-сессии рвутся.\n\n**Причина третья, самая недооценённая: вы едете не по тому проводу.** Между крупными точками сети обычно не один линк, а несколько параллельных, и трафик по ним раскидывают через ECMP - хешируют пятёрку из адреса отправителя, адреса получателя, протокола и двух портов, и по хешу выбирают линк. Это нужно, чтобы пакеты одного соединения не переставлялись местами.\n\nТолько у ICMP портов нет. Вообще. Значит, и хеш у него считается по другим данным, значит, и линк ему достанется другой. Ваш `ping` едет по волокну номер три, а ваш HTTPS на 443-й порт - по волокну номер семь. Третье свободно, седьмое забито. Пинг прекрасен, сайт не грузится, и оба измерения честные.\n\n**Практический вывод.** Хотите узнать, как себя чувствует ваш трафик - меряйте тем же протоколом, каким ходите:\n\n```bash\n# TCP-режим mtr, зонды идут SYN-пакетами на 443\nmtr -T -P 443 -rwzbc 200 example.com\n\n# то же самое через hping3\nhping3 -S -p 443 -c 20 example.com\n```\n\nРазница между `mtr` и `mtr -T -P 443` до одного и того же адреса иногда шокирует. Если ICMP-вариант показывает 3% потерь, а TCP-вариант ноль - никаких потерь у вас нет, вам просто не отвечали.\n\nЭто же, кстати, причина не ставить в мониторинге проверку типа Ping и на том успокаиваться - подробнее в [статье про свой мониторинг](svoy-monitoring-uptime-kuma-ili-prometheus-grafana.md).\n\n---\n\n## Jitter: почему рассыпается голос\n\nJitter - разброс задержки. Не сама задержка, а то, насколько она скачет от пакета к пакету.\n\nИ вот тут контринтуитивная вещь, которую надо принять: **стабильные 80 мс лучше, чем скачущие от 20 до 200**. Даже если во втором случае бывает вдвое быстрее. Для всего реального времени - голос, видео, игры - предсказуемость важнее скорости.\n\n### Механизм: буфер джиттера\n\nГолос по сети едет мелкими пакетами, обычно по 20 мс звука в каждом. Отправитель шлёт их идеально ровно, через равные промежутки. Сеть эту ровность разрушает: один пакет постоял в очереди, второй проскочил, третий поехал другим маршрутом.\n\nНа приёмной стороне поток надо собрать обратно в ровный, иначе звук будет ускоряться и замедляться. Для этого стоит **jitter buffer**: приёмник придерживает пакеты, копит запас, скажем, на 50 мс, и отдаёт их декодеру равномерно.\n\nДальше самое интересное. Пакет, который опоздал сильнее, чем глубина буфера, - **выбрасывается**. Не потому, что сеть его потеряла, - сеть его честно доставила. Просто он приехал, когда этот кусочек звука уже прозвучал, и он больше не нужен.\n\nПолучается, **jitter превращается в потери на уровне приложения**, даже когда в сети потерь ноль. Вы смотрите на статистику канала, там `0% packet loss`, а собеседник слышит вас пунктиром.\n\nУмные буферы подстраиваются: видят разброс - увеличивают глубину. Меньше выброшенных пакетов, но растёт задержка, и разговор превращается в переговоры по рации с паузами и «алло, ты меня слышишь?». Выбор всегда один и тот же: либо рвётся, либо тормозит.\n\n### Сколько это в цифрах\n\nТут есть настоящий ориентир, а не выдуманный. В рекомендации ITU-T G.114 давно расписаны пороги по односторонней задержке: до 150 мс большинство людей не замечает вообще, 150-400 мс уже чувствуется, но разговаривать можно, выше 400 мс - разговор ломается, собеседники начинают перебивать друг друга.\n\nОбратите внимание: **односторонней**. То есть примерно половина того RTT, который вам показывает ping. Гоняете голос через сервер с пингом 250 мс - у вас 125 мс в одну сторону только на сеть, плюс кодирование, плюс буфер, плюс декодирование. Бюджет съеден.\n\nПро сам разброс жёсткого стандарта нет, но по практике: `mdev` в пределах единиц миллисекунд - канал ровный, десятки - уже слышно, сотни - можно не звонить.\n\n### Откуда берётся\n\n- **Очереди на перегруженном участке.** Основной источник. Пакет ждёт своей очереди столько, сколько занято впереди, а занятость всё время меняется.\n- **Wi-Fi.** Само по себе. Общая среда, коллизии, повторные передачи, адаптация скорости, засыпающий радиомодуль ради экономии батареи.\n- **Мобильная сеть.** Там задержка вообще живёт своей жизнью, особенно при переключении между сотами.\n- **Bufferbloat.** Об этом дальше отдельно, он даёт самый зрелищный разброс.\n\n---\n\n## Один процент потерь и мёртвый гигабит\n\n«Ну потерялся один пакет из ста, невелика беда, TCP же перешлёт». Перешлёт. Только сначала он сделает вывод.\n\nTCP в классических реализациях (Reno, CUBIC, который стоит по умолчанию в линуксе) считает потерю пакета сигналом перегрузки. Логика родом из восьмидесятых и вполне здравая: провода не теряют пакеты просто так, теряют переполненные очереди, значит сеть перегружена, значит надо сбавить. И отправитель режет окно, а потом медленно наращивает обратно.\n\nПока потери случайные и редкие - механизм работает. Когда потери идут постоянно, окно не успевает вырасти между просадками, и скорость встаёт колом. Причём **встаёт независимо от ширины канала**.\n\nСчитается это формулой Матиса. Верхняя граница для одного TCP-потока получается примерно такая: размер сегмента, делённый на RTT, умноженный на константу и делённый на корень из вероятности потери. Подставим реальные числа (сегмент 1460 байт):\n\n| Потери | RTT 20 мс | RTT 100 мс |\n|---|---|---|\n| 0,01% | ~71 Мбит/с | ~14 Мбит/с |\n| 0,1% | ~22 Мбит/с | ~4,5 Мбит/с |\n| 1% | ~7 Мбит/с | ~1,4 Мбит/с |\n\nПрочитайте правый нижний угол ещё раз. Один процент потерь на канале с пингом 100 мс - и одно TCP-соединение не разгонится выше полутора мегабит. Хоть у вас десятигигабитный порт, хоть сто. Ширина канала в формуле не участвует вообще.\n\nВот почему «у меня же гигабит, почему файл качается со скоростью модема» - вопрос не про гигабит.\n\n### Отсюда растёт куча знакомых странностей\n\n**Спидтест показывает норму, а скачивание ползёт.** Спидтесты качают в несколько потоков одновременно. Каждый поток по отдельности страдает от потерь, но их десять, и в сумме получается прилично. Одиночная закачка через `curl` - это один поток, и он получает свои полтора мегабита. Ровно этот эффект вы видите, когда `iperf3 -P 8` из чеклиста по [проверке VPS](vps-oversell-proverka-resursov.md) даёт совсем не то, что `iperf3` в один поток.\n\n**Браузер шустрее, чем консольная утилита.** По той же причине: он открывает несколько соединений и тянет ресурсы параллельно.\n\n**Помогает смена congestion control.** BBR не использует потери как основной сигнал перегрузки, он строит модель канала по измеренной полосе и минимальному RTT. На линии с фоновыми потерями разница бывает в разы, и именно поэтому его так любят вкручивать в прокси-конфиги. Правда, включается он не в конфиге прокси, а в ядре (`net.ipv4.tcp_congestion_control`), и если модуль не загружен, строчка в конфиге не значит ничего - я про это писал подробно в разборе конфигов Xray. Ещё BBR довольно нагло ведёт себя по отношению к соседним потокам, так что серебряной пулей его считать не стоит.\n\n### Не все потери одинаковы\n\nДля скорости важен процент. Для голоса и игр важнее **как** они распределены.\n\nОдин процент, размазанный ровно по всему потоку, современный голосовой кодек замаскирует так, что вы не заметите: он достроит недостающий кусочек по соседним. А вот тот же один процент, прилетевший пачкой из пяти пакетов подряд, - это сто миллисекунд тишины, которую ничем не замаскируешь. Такие пачки как раз и дают роутеры, когда переполняется очередь: они выкидывают не по одному, а всё, что не влезло, разом.\n\n### Отдельная категория для российских реалий\n\nПотери бывают не сетевыми. Если соединение стабильно рвётся на определённых сайтах, на определённом порту или строго после начала передачи данных, а до соседнего сервера в том же дата-центре всё летает - это уже не про качество канала. Отличить такое легко: настоящие сетевые потери не разбирают, куда вы идёте, и бьют одинаково по всем адресам за проблемным участком. Избирательность - признак того, что кто-то смотрит внутрь.\n\n---\n\n## Bufferbloat: беда от лишней памяти\n\nМоя любимая история в сетях, потому что она про то, как хорошее намерение всё сломало.\n\nПамять дешевела, и производители сетевого железа рассуждали логично: чем больше буфер, тем меньше пакетов придётся выбросить при всплеске нагрузки. Потери - это плохо, значит, буферы делаем побольше. И набили их в модемы, роутеры, базовые станции, драйверы сетевых карт.\n\nПроблема в том, что TCP узнаёт о перегрузке **из потерь**. Это его единственный надёжный сигнал.\n\nСмотрите, что получается. Канал забился, но пакеты не выбрасываются - они выстраиваются в очередь. Отправитель потерь не видит, делает вывод, что всё отлично, и разгоняется дальше. Очередь растёт. Отправитель разгоняется ещё. Очередь растёт ещё.\n\nК тому моменту, когда сигнал о перегрузке всё-таки дойдёт, в буфере уже лежат секунды трафика. И **каждый** пакет теперь проходит через эту очередь. Ваш DNS-запрос, ваш ping, ваш пакет с голосом - все послушно встают в хвост за тремя мегабайтами торрента.\n\nВот классическая картина, которую видел каждый, но мало кто знал, как она называется:\n\n```\nв простое:          ping 15 мс\nначалась закачка:   ping 780 мс\n```\n\nНикаких потерь, никаких ошибок. Просто интернет превратился в кисель, пока что-то качается. Буферы, которые ставили ради борьбы с потерями, обменяли потери на задержку - причём по грабительскому курсу.\n\n### Почему это не видно обычными тестами\n\nСпидтест меряет полосу. Полоса при bufferbloat отличная, буфер же её и обеспечивает. Ping в простое тоже отличный, очереди пустые.\n\nМерить надо **задержку под нагрузкой** - latency under load. То есть одновременно грузить канал и пинговать. Ровно это и делают специальные тесты вроде Waveform или LibreQoS: сначала замер в покое, потом заливка вниз с параллельным замером, потом заливка вверх, и на выходе оценка буквой от A+ до F. Первый раз это стоит прогнать просто из любопытства, результат обычно бодрит.\n\nРуками то же самое делается в два окна:\n\n```bash\n# окно 1\nping -i 0.2 1.1.1.1\n\n# окно 2 - грузим канал на 30 секунд\niperf3 -c \u003Cсервер> -t 30 -P 4\n```\n\nСмотрите, что происходит с пингом в первом окне в момент старта заливки. Вырос в десять раз - у вас bufferbloat.\n\n### Лечение: AQM\n\nИдея активного управления очередью в том, чтобы начинать отбрасывать пакеты **до** того, как очередь распухнет. Не когда буфер полон, а когда пакеты начали в нём залёживаться.\n\n**CoDel** (RFC 8289) зашёл с неожиданной стороны: он следит не за длиной очереди, а за **временем**, которое пакет в ней проводит. Логика в том, что длина очереди сама по себе ни о чём не говорит - короткий всплеск - это нормально, плохо, когда очередь не рассасывается. Как только время ожидания стабильно превышает целевое (по умолчанию 5 мс), CoDel начинает подкидывать дропы, и отправитель получает свой сигнал притормозить.\n\n**FQ-CoDel** (RFC 8290) добавил сверху справедливое разделение по потокам. Каждый поток получает свою очередь, и торрент в сорок соединений физически не может отодвинуть ваш единственный пакет с голосом в конец. Это и есть та штука, из-за которой на нормально настроенном роутере зум не замечает, что рядом качается образ убунты.\n\n**CAKE** - развитие идеи, всё в одном флаконе: шейпер, честное разделение, приоритизация, учёт накладных расходов канала. В ядре Linux с версии 4.19.\n\nНа сервере проверяется одной командой:\n\n```bash\nsysctl net.core.default_qdisc\ntc qdisc show dev eth0\n```\n\nХорошая новость: на современных дистрибутивах с systemd там, скорее всего, уже стоит `fq_codel` - systemd прописывает его в своих дефолтных sysctl'ах ещё с 2014 года, специально ради борьбы с bufferbloat. Так что если увидите древний `pfifo_fast` - либо система очень старая, либо кто-то это переопределил руками.\n\nМеняется так:\n\n```bash\n# разово\ntc qdisc replace dev eth0 root fq_codel\n\n# насовсем\necho 'net.core.default_qdisc = fq_codel' | sudo tee /etc/sysctl.d/99-aqm.conf\nsudo sysctl --system\n```\n\n### Честная оговорка про то, где это работает\n\nОчередь на вашем сервере управляет только **исходящим** трафиком с этого сервера. Если бутылочное горлышко находится у провайдера или на магистрали - вы этой очередью не управляете и сделать с ней ничего не можете. Никакой qdisc на VPS не починит перегруженный пиринг.\n\nНа домашнем роутере смысла больше, но там есть свой фокус: чтобы AQM работал, очередь должна образоваться **у вас**, а не у провайдера. Поэтому в настройках SQM скорость шейпера ставят на 85-95% от реальной - вы намеренно немного жертвуете полосой, зато узкое место переезжает на ваше устройство, где вы им распоряжаетесь. Отдать несколько процентов скорости в обмен на то, что задержка под нагрузкой не улетает в небо, - обмен более чем выгодный.\n\n### Куда всё это движется\n\nСовременное продолжение темы - **L4S** (RFC 9330). Идея в том, чтобы вообще перестать использовать потери как сигнал: сеть помечает пакеты специальным флагом ECN задолго до того, как очередь станет проблемой, а отправитель на это реагирует. Плюс две отдельные очереди, чтобы новый механизм не конфликтовал со старым. Дело уже не чисто теоретическое: оператор T-Mobile в США раскатал L4S по своей 5G-сети. До массовых домашних провайдеров дойдёт нескоро, но направление задано.\n\n---\n\n## Как читать mtr и не паниковать\n\n`mtr` - это traceroute и ping в одном флаконе: гоняет зонды непрерывно и показывает статистику по каждому хопу. Инструмент отличный, но читают его неправильно примерно все, и в поддержку хостеров ежедневно летят скриншоты с паникой на пустом месте.\n\nТипичный вывод:\n\n```\nHOST                          Loss%   Snt   Last   Avg  Best  Wrst StDev\n1. 192.168.1.1                 0.0%   200    0.4   0.5   0.3   1.2   0.1\n2. 10.20.0.1                   0.0%   200    2.1   2.4   1.9   8.7   0.6\n3. core1.isp.net              14.5%   200    3.8   4.1   3.2  12.4   0.9\n4. border.isp.net              0.0%   200    5.2   5.5   4.8  15.1   1.1\n5. ix-peering.net              0.0%   200   18.3  18.9  17.9  28.2   1.3\n6. target.example.com          0.0%   200   19.1  19.6  18.8  31.5   1.5\n```\n\nТретий хоп горит красным - 14,5% потерь. Вроде найден виновник, можно писать гневное письмо.\n\nНе надо. **Смотрите на строчку ниже: там ноль.**\n\nРазгадка в том, о чём мы говорили выше. Чтобы показаться в трассировке, роутер должен сам сгенерировать ICMP-ответ - а это работа для его управляющего процессора, и он её ограничивает. Транзитный трафик при этом идёт через ту же железку в полном порядке, потому что его обрабатывает совсем другой тракт. Роутер не потерял ваши пакеты, он поленился ответить на зонды.\n\n**Правило чтения ровно одно:** потери реальны, только если они начинаются на каком-то хопе и **держатся до самого конца**. Пропали на следующей строке - забудьте, это ограничение ICMP, а не проблема сети.\n\nИ наоборот, вот такая картина - настоящая беда:\n\n```\n3. core1.isp.net               6.2%   200    3.8   4.1   3.2  12.4   0.9\n4. border.isp.net              6.5%   200    5.2   5.5   4.8  15.1   1.1\n5. ix-peering.net              6.1%   200   18.3  18.9  17.9  28.2   1.3\n6. target.example.com          6.4%   200   19.1  19.6  18.8  31.5   1.5\n```\n\nПотери появились на третьем хопе и дошли до конца примерно теми же процентами. Вот теперь виноват третий, и вот с этим уже можно идти в поддержку.\n\nПоследняя строка вообще самая главная. Если на ней ноль - у вас всё хорошо, что бы ни творилось выше.\n\n### Второй момент, про который забывают: трасса односторонняя\n\n`mtr` видит только путь **от вас к цели**. Обратный путь может идти вообще через другие страны, и если проблема там - в вашей трассировке она не отобразится никак. Вы будете смотреть на идеальный вывод и не понимать, почему всё плохо.\n\nПоэтому правило обращения в поддержку: прикладывать **два** отчёта - свой до сервера и встречный, снятый на сервере до вашего адреса. Одностороннюю трассу поддержка первым делом попросит дополнить, так что сэкономьте себе круг переписки.\n\n```bash\n# у себя\nmtr -rwzbc 200 \u003CIP-сервера> > mtr-to-server.txt\n\n# на сервере (ваш публичный адрес узнаётся через curl ifconfig.me)\nmtr -rwzbc 200 \u003Cваш-IP> > mtr-from-server.txt\n```\n\nФлаги: `-r` отчёт вместо интерактива, `-w` широкий вывод с полными именами, `-z` показывать номера автономных систем (сразу видно, где кончается один оператор и начинается другой), `-b` показывать и имя, и адрес, `-c 200` сколько зондов гонять.\n\n---\n\n## Чем мерить по-настоящему\n\nСобрал в кучу то, чем реально пользуюсь.\n\n**Разброс задержки, без затей:**\n\n```bash\nping -c 300 -i 0.2 \u003Cцель>\n```\n\nТриста пакетов, минута. Смотрим `mdev` и `max`, на `avg` не ведёмся.\n\n**Тем протоколом, которым ходим:**\n\n```bash\nmtr -T -P 443 -rwzbc 200 \u003Cцель>\n```\n\nЕсли ICMP-версия показывает потери, а эта нет - потерь нет.\n\n**Честный jitter и потери разом.** UDP-режим `iperf3` для этого и сделан: он шлёт с заданной скоростью и на приёмнике считает и разброс, и сколько датаграмм не доехало.\n\n```bash\niperf3 -c \u003Cсервер> -u -b 50M -t 30\n```\n\nВ отчёте будут колонки `Jitter` и `Lost/Total`. Это самый прямой ответ на вопрос «что там с каналом», какой можно получить за тридцать секунд.\n\n**Односторонняя задержка.** Самая простая утилита для этого - `irtt`. Нужен свой сервер на другой стороне, зато вы наконец увидите, какое направление тормозит:\n\n```bash\n# на сервере\nirtt server\n\n# у себя\nirtt client -i 20ms -d 30s \u003Cсервер>\n```\n\n**Bufferbloat.** Браузерные тесты latency under load (Waveform, LibreQoS) дают оценку буквой за две минуты. Руками - `ping` в одном окне и `iperf3` в другом, как выше.\n\n**Быстрая общая картина.** `speed.cloudflare.com` кроме скорости показывает задержку под нагрузкой, разброс и потери. Для «глянуть одним глазом» удобнее всего.\n\n**Что за очередь стоит:**\n\n```bash\ntc qdisc show dev eth0\n```\n\n**Из-под винды:** `pathping` (встроенный, совмещает трассировку со статистикой потерь, только долго думает) и `psping` из Sysinternals - он умеет TCP-режим, то есть обходит проблему деприоритезации ICMP.\n\n### Два правила замера, без которых всё бессмысленно\n\n**Мерьте по проводу.** Wi-Fi добавляет свой разброс, и вы не отличите его от сетевого. Хотите проверить хостера - воткните кабель.\n\n**Мерьте в разное время суток.** Перегруженный пиринг живёт по расписанию: днём всё летает, вечером всё встаёт. Один замер в три часа дня не значит ничего - ровно та же история, что и с оверселлом железа.\n\n---\n\n## Что чинится, а что нет\n\nЧестное разделение, потому что половину проблем с сетью чинить бесполезно, и лучше знать об этом заранее.\n\n**Чинится вами:**\n\n- Домашний роутер и его буферы. SQM с fq_codel или CAKE, шейпер на 90% реальной скорости. Часто это вообще единственная реальная проблема, а грешат на провайдера.\n- Wi-Fi. Провод, смена канала, разнос точек. Скучно, но работает.\n- Очередь на исходящем интерфейсе вашего VPS - `fq_codel`, одна строчка в sysctl.\n- Алгоритм контроля перегрузки на вашем сервере. BBR вместо CUBIC там, где линия с фоновыми потерями.\n- MTU и фрагментация. Отдельная классика: где-то по пути MTU меньше вашего, а ICMP с сообщением об этом отфильтрован, и в результате мелкие пакеты ходят, а крупные исчезают. Выглядит как мистика («ping идёт, сайт не грузится»), лечится подбором MTU.\n\n**Не чинится вами никак:**\n\n- Перегруженный стык между вашим провайдером и хостером. Хоть обнастраивайтесь.\n- Потери в магистрали.\n- Кривая оптика на промежуточном участке.\n- Асимметричный маршрут, где обратный путь идёт через полмира.\n\nЕдинственное лекарство от второй группы - **сменить маршрут**. То есть другая локация дата-центра, другой хостер, другой аплинк. Иногда переезд сервера из одного города в другой у того же провайдера чинит всё, потому что трафик поехал через другой стык.\n\nИменно поэтому при выборе хостера пинг из вашего города - метрика более полезная, чем характеристики железа. Железо у всех примерно одинаковое, а вот маршруты до вашего провайдера у всех разные.\n\n---\n\n## Какая метрика под какую задачу\n\n| Задача | Что реально критично | Что почти не важно |\n|---|---|---|\n| Веб-сёрфинг | RTT: каждое новое соединение начинается с рукопожатий, и они складываются | jitter, полоса сверх десятков мегабит |\n| Видеозвонки | jitter и потери, они бьют напрямую по звуку | абсолютная скорость |\n| Игры | jitter и потери пачками, стабильность важнее среднего | полоса, там копейки трафика |\n| Скачивание большого файла | потери (см. таблицу выше) и полоса | jitter |\n| Просмотр видео | стабильность полосы, буфер плеера сглаживает остальное | RTT, jitter |\n| Прокси и VPN | потери плюс эффект TCP внутри TCP | средний RTT сам по себе |\n\nОтдельно про последнюю строку. Когда TCP-соединение едет внутри другого TCP-соединения, оба слоя начинают независимо реагировать на одни и те же потери и мешают друг другу: внешний уже перепослал, а внутренний тоже решил перепослать. Получается затор от одной-единственной пробки. Разбирал это подробно в [сравнении протоколов](amneziawg-vs-vless-vs-hysteria2.md), тут просто отмечу, что на рваном канале эффект вылезает первым делом, и именно поэтому протоколы поверх UDP на плохих линиях чувствуют себя заметно лучше.\n\n---\n\n## Частые ошибки\n\n- **Смотреть на `avg` и радоваться.** Средняя прячет ровно те выбросы, которые вы и ощущаете. Смотрите `max` и `mdev`.\n- **Судить о канале по десяти пакетам.** Проблема, которая всплывает раз в минуту, в пятисекундном замере не появится.\n- **Паниковать от красного посередине `mtr`.** Если на последнем хопе ноль - потерь нет, вам просто не отвечал промежуточный роутер.\n- **Мерить по Wi-Fi.** Вы диагностируете свою квартиру, а не хостера.\n- **Считать, что ping и рабочий трафик едут одинаково.** Разный приоритет, разное отношение оборудования, при ECMP - буквально разные провода.\n- **Игнорировать нагрузку.** Bufferbloat в простое не виден в принципе. Тест без нагрузки его не поймает никогда.\n- **Присылать в поддержку одну трассу.** Обратный путь другой, без встречного отчёта половина картины отсутствует.\n- **Гнаться за минимальным пингом любой ценой.** Стабильные 60 мс лучше, чем 25 с выбросами до 300. Для всего живого предсказуемость дороже.\n- **Верить одному замеру.** Вечерний час пик - отдельная реальность, и именно в ней вы обычно и пользуетесь интернетом.\n\n---\n\n## Где это проверять\n\nВсё, что выше, требует второй точки. Пинг сам с собой не померишь: чтобы понять, дело в канале или в сервисе, нужна машина на другом конце, про которую вы точно знаете, что с ней всё в порядке.\n\nДешёвый VPS в этой роли незаменим. На нём поднимается `iperf3 -s`, ставится `irtt server`, с него снимается встречный `mtr` - и внезапно все замеры становятся двусторонними и осмысленными. Плюс появляется возможность проверить главное перед покупкой чего-то серьёзного: как **из вашей сети** доезжает до **этого конкретного дата-центра**, потому что цифры в оффере про это не говорят ничего.\n\nЯ для такого держу самый младший тариф на [serv.host](https://serv.host/?from=22382) (промокод `promo22382`) - под `iperf3` и трассировки хватает минимальной конфигурации, а разные локации позволяют сравнить маршруты и выбрать тот, который до вас доезжает нормально.\n\nПорядок первой диагностики нового сервера, если нужен готовый список:\n\n1. `ping -c 300 -i 0.2` до сервера, смотрим `max` и `mdev`, не `avg`.\n2. `mtr -rwzbc 200` в обе стороны, читаем **последнюю строку**.\n3. `mtr -T -P 443` туда же, сравниваем с ICMP-версией.\n4. `iperf3 -u -b 50M -t 30` - получаем честные jitter и потери.\n5. `iperf3 -c ... -t 30` в один поток и `-P 8` - разница покажет, есть ли фоновые потери.\n6. Пинг под нагрузкой в двух окнах - ловим bufferbloat.\n7. Повторить вечером. Обязательно.\n\nСедьмой пункт снова главный, как и в проверке железа. Сеть - штука суточная.\n\n---\n\n## Короткий итог\n\n- **`ping` показывает одно усреднённое число туда-обратно.** Ни направления, ни разброса, ни поведения под нагрузкой в нём нет.\n- **ICMP - не ваш трафик.** Роутеры ограничивают ответы на своём управляющем процессоре, провайдеры его душат, а при ECMP он вообще едет по другому физическому линку. Меряйте TCP-зондами на тот порт, которым пользуетесь.\n- **Jitter превращается в потери на уровне приложения:** пакет, опоздавший сильнее глубины буфера, выбрасывает сам приёмник, хотя сеть его честно доставила. Стабильные 80 мс лучше скачущих 20-200.\n- **Один процент потерь при RTT 100 мс держит одно TCP-соединение на полутора мегабитах** независимо от ширины канала. Отсюда «спидтест норм, а файл ползёт».\n- **Bufferbloat** - это когда большие буферы прячут от TCP сигнал перегрузки, и он разгоняется, пока задержка не улетает в сотни миллисекунд. В простое не виден вообще, ловится только замером под нагрузкой.\n- **Лечится AQM:** CoDel следит за временем в очереди, FQ-CoDel добавляет честное разделение потоков, CAKE делает всё сразу. На линуксе `fq_codel` обычно уже стоит по умолчанию.\n- **В `mtr` реальны только те потери, что дошли до последней строки.** Красное посередине - почти всегда ограничение ICMP на промежуточном роутере.\n- **Половина проблем чинится на вашей стороне** (роутер, Wi-Fi, qdisc, congestion control), вторая половина не чинится вообще и лечится только сменой маршрута, то есть переездом.\n\nХороший канал определяется не маленьким пингом, а тем, что этот пинг **предсказуем** и не разваливается, когда по каналу что-то поехало. Померить это ровно на пять минут дольше, чем набрать `ping`.\n\n---\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n\n## Источники\n\n- [Bufferbloat.net - тесты и матчасть по проблеме](https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/)\n- [RFC 8289 - Controlled Delay Active Queue Management (CoDel)](https://datatracker.ietf.org/doc/html/rfc8289)\n- [RFC 8290 - FlowQueue-CoDel (FQ-CoDel)](https://datatracker.ietf.org/doc/html/rfc8290)\n- [RFC 9330 - архитектура L4S](https://datatracker.ietf.org/doc/rfc9330/)\n- [RFC 3550 - RTP, определение interarrival jitter](https://www.ietf.org/rfc/rfc3550.txt)\n- [RFC 5481 - Packet Delay Variation, разбор двух определений джиттера](https://datatracker.ietf.org/doc/html/rfc5481)\n- [tc-cake(8) - man-страница CAKE](https://man7.org/linux/man-pages/man8/tc-cake.8.html)\n- [Как правильно читать traceroute и MTR - блог APNIC](https://blog.apnic.net/2022/03/28/how-to-properly-interpret-a-traceroute-or-mtr/)\n- [irtt - замер односторонней задержки](https://github.com/heistp/irtt)\n- [iperf3 - официальный сайт](https://software.es.net/iperf/)\n","Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний м",null,91,0,"2026-08-09T05:55:28.579Z","2026-09-01T19:52:00.000Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":18},24,"gaydy","Гайды",{"id":19,"value":20,"content":21,"sortOrder":11},23,"obshchee","Общее",[23,27,31,35,39],{"id":24,"value":25,"content":26},19,"pravila","правила",{"id":28,"value":29,"content":30},113,"monitoring","Мониторинг",{"id":32,"value":33,"content":34},114,"bezopasnost","Безопасность",{"id":36,"value":37,"content":38},115,"rukovodstvo","Руководство",{"id":40,"value":41,"content":42},116,"instrukciya","Инструкция",[44,46,49,51,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100],{"level":45,"text":5},1,{"level":47,"text":48},2,"Содержание",{"level":47,"text":50},"Что на самом деле меряет ping",{"level":52,"text":53},3,"Четыре вещи, которые ping не покажет никогда",{"level":47,"text":55},"ICMP это не ваш трафик",{"level":47,"text":57},"Jitter: почему рассыпается голос",{"level":52,"text":59},"Механизм: буфер джиттера",{"level":52,"text":61},"Сколько это в цифрах",{"level":52,"text":63},"Откуда берётся",{"level":47,"text":65},"Один процент потерь и мёртвый гигабит",{"level":52,"text":67},"Отсюда растёт куча знакомых странностей",{"level":52,"text":69},"Не все потери одинаковы",{"level":52,"text":71},"Отдельная категория для российских реалий",{"level":47,"text":73},"Bufferbloat: беда от лишней памяти",{"level":52,"text":75},"Почему это не видно обычными тестами",{"level":52,"text":77},"Лечение: AQM",{"level":52,"text":79},"Честная оговорка про то, где это работает",{"level":52,"text":81},"Куда всё это движется",{"level":47,"text":83},"Как читать mtr и не паниковать",{"level":52,"text":85},"Второй момент, про который забывают: трасса односторонняя",{"level":47,"text":87},"Чем мерить по-настоящему",{"level":52,"text":89},"Два правила замера, без которых всё бессмысленно",{"level":47,"text":91},"Что чинится, а что нет",{"level":47,"text":93},"Какая метрика под какую задачу",{"level":47,"text":95},"Частые ошибки",{"level":47,"text":97},"Где это проверять",{"level":47,"text":99},"Короткий итог",{"level":47,"text":101},"Источники","tr",false,true,[106,139,153,166,175,196,210,223,235,246],{"id":107,"title":108,"slug":109,"content":110,"description":110,"coverUrl":9,"views":111,"likes":11,"createdAt":112,"category":113,"tags":115,"author":136},89,"Что такое uptime VPS и почему 99,9% - это не 100%","chto-takoe-uptime-vps","Что такое uptime VPS и почему 99,9% - это не 100% == Когда выбирают VPS, одним из первых показателей, на который обращают внимание, становится uptime. Провайдер",92,"2026-08-17T14:22:17.023Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":114},{"id":19,"value":20,"content":21,"sortOrder":11},[116,120,121,122,123,124,128,132],{"id":117,"value":118,"content":119},18,"gayd","гайд",{"id":24,"value":25,"content":26},{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":40,"value":41,"content":42},{"id":125,"value":126,"content":127},117,"tutorial","Туториал",{"id":129,"value":130,"content":131},119,"ustanovka","Установка",{"id":133,"value":134,"content":135},120,"sovety","Советы",{"id":137,"name":138,"slug":9},109,"serv.host",{"id":140,"title":141,"slug":142,"content":143,"description":143,"coverUrl":9,"views":144,"likes":45,"createdAt":145,"category":146,"tags":148,"author":9},86,"ИИ в технической работе: где помогает, а где нельзя доверять","ii-v-tehnicheskoy-rabote-gde-pomogaet-a-gde-nelzya-doveryat","ИИ в технической работе: где помогает, а где нельзя доверять Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой прое",100,"2026-08-09T09:26:13.317Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":147},{"id":19,"value":20,"content":21,"sortOrder":11},[149,150,151,152],{"id":117,"value":118,"content":119},{"id":24,"value":25,"content":26},{"id":36,"value":37,"content":38},{"id":133,"value":134,"content":135},{"id":154,"title":155,"slug":156,"content":157,"description":157,"coverUrl":9,"views":158,"likes":11,"createdAt":159,"category":160,"tags":162,"author":9},85,"Почему ИИ делает не то, что просили, и врёт слишком правдоподобно.","pochemu-ii-delaet-ne-to-chto-prosili-i-vret-slishkom-pravdopodobno","Почему ИИ делает не то, что просили, и врёт слишком правдоподобно. Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мо",97,"2026-08-09T08:51:02.943Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":161},{"id":19,"value":20,"content":21,"sortOrder":11},[163,164,165],{"id":24,"value":25,"content":26},{"id":36,"value":37,"content":38},{"id":133,"value":134,"content":135},{"id":4,"title":5,"slug":6,"content":8,"description":8,"coverUrl":9,"views":107,"likes":11,"createdAt":12,"category":167,"tags":169,"author":9},{"id":15,"value":16,"content":17,"sortOrder":11,"parent":168},{"id":19,"value":20,"content":21,"sortOrder":11},[170,171,172,173,174],{"id":24,"value":25,"content":26},{"id":28,"value":29,"content":30},{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":40,"value":41,"content":42},{"id":176,"title":177,"slug":178,"content":179,"description":179,"coverUrl":9,"views":111,"likes":45,"createdAt":180,"category":181,"tags":183,"author":9},83,"Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере","svoy-monitoring-uptime-kuma-ili-prometheus-s-grafana-i-pochemu-on-obyazan-jit-na-otdelnom-servere","Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере Вообще я микроразработчик, со мной можно связаться как угодн","2026-08-09T05:54:48.670Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":182},{"id":19,"value":20,"content":21,"sortOrder":11},[184,185,186,187,188,189,190,191,195],{"id":117,"value":118,"content":119},{"id":24,"value":25,"content":26},{"id":28,"value":29,"content":30},{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":40,"value":41,"content":42},{"id":125,"value":126,"content":127},{"id":192,"value":193,"content":194},118,"nastroyka","Настройка",{"id":133,"value":134,"content":135},{"id":197,"title":198,"slug":199,"content":200,"description":200,"coverUrl":9,"views":201,"likes":45,"createdAt":202,"category":203,"tags":205,"author":9},82,"TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS)","tls-fingerprinting-kak-server-uznaet-tvoy-klient-ja3ja4-utls","TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS) Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой",63,"2026-08-07T21:34:46.778Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":204},{"id":19,"value":20,"content":21,"sortOrder":11},[206,207,208,209],{"id":117,"value":118,"content":119},{"id":24,"value":25,"content":26},{"id":36,"value":37,"content":38},{"id":133,"value":134,"content":135},{"id":211,"title":212,"slug":213,"content":214,"description":214,"coverUrl":9,"views":215,"likes":45,"createdAt":216,"category":217,"tags":219,"author":9},81,"Whois-приватность: кто на самом деле видит твои данные при регистрации домена","whois-privatnost-kto-na-samom-dele-vidit-tvoi-dannye-pri-registracii-domena","Whois-приватность: кто на самом деле видит твои данные при регистрации домена Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему С",56,"2026-08-07T21:03:10.184Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":218},{"id":19,"value":20,"content":21,"sortOrder":11},[220,221,222],{"id":24,"value":25,"content":26},{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":224,"title":225,"slug":226,"content":227,"description":227,"coverUrl":9,"views":228,"likes":45,"createdAt":229,"category":230,"tags":232,"author":9},80,"Domain fronting: как работал обход SNI-фильтрации и почему умер","domain-fronting-kak-rabotal-obhod-sni-filtracii-i-pochemu-umer","Domain fronting: как работал обход SNI-фильтрации и почему умер Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой п",60,"2026-08-07T20:39:32.556Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":231},{"id":19,"value":20,"content":21,"sortOrder":11},[233,234],{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":236,"title":237,"slug":238,"content":239,"description":239,"coverUrl":9,"views":228,"likes":45,"createdAt":240,"category":241,"tags":243,"author":9},79,"Почему IP попадают в блэклисты и как получить «чистый» IP","pochemu-ip-popadayut-v-bleklisty-i-kak-poluchit-chistyy-ip","Почему IP попадают в блэклисты - и как получить «чистый» IP Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой проек","2026-08-07T20:38:40.819Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":242},{"id":19,"value":20,"content":21,"sortOrder":11},[244,245],{"id":32,"value":33,"content":34},{"id":133,"value":134,"content":135},{"id":247,"title":248,"slug":249,"content":250,"description":250,"coverUrl":9,"views":251,"likes":45,"createdAt":252,"category":253,"tags":255,"author":9},78,"Как находят настоящий IP сайта за Cloudflare и как его спрятать по-настоящему","kak-nahodyat-nastoyashchiy-ip-sayta-za-cloudflare-i-kak-ego-spryatat-po-nastoyashchemu","Как находят настоящий IP сайта за Cloudflare - и как его спрятать по-настоящему Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему",62,"2026-08-07T20:37:51.437Z",{"id":15,"value":16,"content":17,"sortOrder":11,"parent":254},{"id":19,"value":20,"content":21,"sortOrder":11},[256,257,258,259],{"id":32,"value":33,"content":34},{"id":36,"value":37,"content":38},{"id":40,"value":41,"content":42},{"id":133,"value":134,"content":135},["Island",261],{"key":262,"result":263},"ArticleBody_vEHTabLVp0BK3FGZOo3nYwqXTnjCPN1nxNYDAF1D4",{"head":264},{},1788480205487]