Выбор локации игрового сервера по пингу
На выбор локации игрового сервера по пингу влияют не расстояния, а сети будущих игроков. Близкий город может проиграть, если пакеты идут к нему через перегруженный стык операторов. Для сравнения нужны несколько сетей, разные часы и пробная игровая сессия, так как служебные запросы ping могут проходить иначе, чем игровой трафик. Замеры проводите не из своей сети, а руками игроков: несколько человек из каждого города и от каждого оператора запускают один и тот же тест, а вы сводите результаты.
Какие тесты задержки провести до выбора локации?
До выбора локации нужны серии ping и трассировки из сетей игроков, затем пробная сессия на игровом сервере. Вместе они помогают оценить задержку, её колебания и потери в разные часы. Ответы на служебные запросы могут отличаться от поведения игрового трафика, поэтому одного ping недостаточно.
Для каких игроков выбираем сервер
Группы игроков различаются страной, городом, оператором и типом подключения. Даже у соседей с разными провайдерами путь до сервера бывает разным. Поэтому мерить нужно из тех сетей, которыми действительно пользуется аудитория. ASN, номер автономной системы, помогает различать сети.
Проверка задержки локации игрового сервера опирается на несколько добровольцев от каждой группы. Их результаты можно хранить под кодами G1-P1 и G1-P2, указав город, оператора и способ подключения. По Wi-Fi игрок меряет то подключение, которым и пользуется. Если результат у него заметно хуже, чем у остальных в группе, отдельный тест по кабелю покажет, дело в домашней сети или в маршруте.
До замеров стоит задать пороги: какая задержка, какая доля потерь и сколько разрывов сессии считаются приемлемыми. Пороги зависят от игры и ожиданий сообщества. Требования должны учитывать каждую значимую группу, ведь хороший средний результат легко скрывает проблемы меньшинства.
Какие серверы сравнивать
Локация должна остаться единственным отличием между кандидатами. У тестовых VM должны совпадать процессорные ресурсы, сетевые ограничения, версия игры и настройки firewall. У перегруженной машины задержки могут быть связаны с ресурсами. Список кандидатов включает доменное имя, фактический IP, игровой порт и срок доступа к стенду.
Провайдеры часто публикуют тестовый IP, по которому можно пинговать площадку до аренды. Этого хватает, чтобы отсеять явно далёкие регионы, но не чтобы выбрать между близкими: у поддержки стоит уточнить, относится ли адрес к нужной площадке и проходит ли через ту же защиту от атак, что будущая VM. Окончательные замеры идут уже на арендованной машине.
Показатели ping, jitter и packet loss отвечают на разные вопросы: как быстро приходит ответ, насколько ровно он приходит и сколько ответов не приходит вовсе. Низкое среднее спокойно уживается с рывками и пропажами. Маршруты IPv4 и IPv6 могут расходиться, поэтому при поддержке обоих протоколов их проверяют отдельно.
Как собрать сопоставимые замеры
Сравнение покажет, какую страну выбрать для VPS, только если каждый участник выполнит один и тот же сценарий для всех кандидатов. Для первого отбора подойдут несколько пятиминутных серий утром, вечером и в часы обычной игры. При близких результатах нужны дополнительные дни наблюдений.
Скрипт рассчитан на Linux с Bash, утилитой ping из пакета iputils и MTR. Код сохраните в test-region.sh. IP в команде запуска – адрес тестовой VM. Результаты и версии утилит попадут в отдельную папку с временем UTC.
Если mtr откажется открывать сокеты, запустите скрипт через sudo, так как на части сборок ему нужны права root.
#!/usr/bin/env bash
# Запуск: bash test-region.sh IP
export LC_ALL=C
ip="${1:?Укажите IPv4-адрес тестовой VM}"
out=$(mktemp -d "probe-$(date -u +%Y%m%dT%H%M%SZ)-XXXX")
printf '%s\n' "$ip" > "$out/target.txt"
ping -V > "$out/versions.txt" 2>&1
mtr --version >> "$out/versions.txt" 2>&1
ping -4 -n -D -c 300 -i 1 "$ip" > "$out/ping.txt" 2>&1
mtr -4 -n -r -w -c 60 "$ip" > "$out/mtr.txt" 2>&1
Ping отправит 300 запросов с интервалом в секунду, затем MTR соберёт отчёт о маршруте. Весь запуск займёт больше пяти минут. Порядок кандидатов между сериями стоит менять, чтобы один регион не проверялся всегда раньше остальных. Параметры команд доступны в документации ping и руководстве MTR.
Насколько jitter и потери важнее среднего ping?
Низкий средний ping не компенсирует частые скачки задержки и потери пакетов. Из-за них данные приходят неровно или не доходят до игры, даже если большинство ответов быстрые. Значимость каждого показателя зависит от механики игры и обработки потерь, поэтому окончательное сравнение требует проверки реальной сессии.
Что означают цифры в отчёте
RTT – время от отправки запроса до получения ответа. Медиана, или p50, делит полученные значения пополам. Показатель p95 отмечает задержку, которую не превышают примерно 95% полученных ответов. Так видны медленные ответы, скрытые за средним. Число запросов и ответов нужно для оценки выборки.
Для единообразия p95 можно считать так: расположить RTT по возрастанию и взять значение на позиции 0,95 × N с округлением вверх, где N означает число ответов. Для уверенных выводов по p99 короткой серии мало. График RTT по времени покажет, собрались ли всплески в один эпизод.
Словом jitter называют разные меры колебания задержки. Здесь это средняя абсолютная разница RTT между соседними запросами, у которых обоих есть ответ. Такой счёт не совпадает ни с mdev из вывода ping, ни с вариацией односторонней задержки по RFC 3393. Сравнивать числа из разных источников нельзя.
Доля запросов без ответа равна (tx − rx) / tx × 100%, где tx и rx означают число запросов и уникальных ответов. Пропуск не превращается ни в нулевой RTT, ни в задержку, равную таймауту. Через looking glass хостинга можно проверить связь со стороны провайдера, но замеры у игроков остаются необходимыми.
Как разобраться в неожиданном маршруте
Если один регион заметно проигрывает, traceroute до игрового сервера поможет увидеть отвечающие промежуточные узлы. MTR повторяет такие пробы и собирает статистику. Отчёты из нескольких сетей за проблемный период покажут, касается ли ухудшение одного оператора или нескольких.
Звёздочки и высокий процент потерь на отдельном промежуточном узле ещё не говорят о том, что он теряет проходящий трафик. Маршрутизатор может ограничивать служебные ответы, продолжая пересылать пакеты. Подозрение становится сильнее, когда ухудшение видно и на конечном адресе. Причину сбоя должен подтвердить оператор.
Названия узлов могут подсказать транзит через другой город, хотя география по имени или базе IP бывает неточной. Обратная трассировка с сервера до доступного адреса игрока добавит сведения о другом направлении. Прямой и обратный пути могут различаться, а RTT включает оба. Недоступный из-за NAT домашний адрес ограничивает такую проверку.
Проверка в самой игре
После сетевых проб нужна игровая сессия на каждом кандидате. У серверов должны совпадать версия игры, модификации, карта и настройки. Участникам лучше повторить похожие действия при одинаковом числе игроков. В отчёт пойдут задержка из клиента, разрывы соединения и доступные показатели потерь. У отдельных игр встроенный ping включает особенности обработки и сглаживания, поэтому он не обязан совпадать с ICMP RTT.
Нагрузка VM требует отдельного наблюдения. Например, в Minecraft MSPT означает миллисекунды на такт, а FPS относится к частоте кадров клиента. Медленные такты или падение FPS способны испортить игру при нормальной сети, поэтому эти показатели должны храниться отдельно от RTT.
Защита от DDoS может менять путь трафика. Часть провайдеров заворачивает его в центр очистки – выделенную площадку, где пакеты фильтруются и только потом идут к серверу. Другие фильтруют прямо на пограничных узлах, и тогда заметного крюка не появляется. Возможность теста нужно согласовать с провайдером, без самостоятельной организации атак. После известного включения или изменения фильтрации полезно повторить игровую сессию и сетевые пробы.
Почему ближайший на карте регион может оказаться медленнее?
1. Обмен трафиком между операторами, или peering, может идти через удалённую точку.
2. Перегруженный участок пути добавляет ожидание, даже если расстояние небольшое.
3. Фильтрация трафика может менять маршрут до сервера и увеличивать задержку.
Как выбрать по результатам
В таблице отдельная строка на каждое сочетание группы, кандидата и времени теста: удачный дневной запуск не должен скрыть плохой вечерний. Колонок четыре – p50, p95, колебания RTT и потери.
В сводном CSV поле group связывает строку с городом и оператором, trace хранит имя файла трассировки, game содержит итог пробной сессии.
player,group,region,utc,tx,rx,p50,p95,jitter,loss,trace,game
Поле player хранит условный код участника. Задержки заданы в мс, loss в процентах. Одна строка соответствует одной серии. Общий p95 нельзя получить усреднением p95 участников.
Кандидаты с нарушениями обязательных требований значимой группы выбывают из сравнения. Остальные получают оценки показателей по заранее заданной шкале, например от 0 до 5, где 5 означает лучший результат. Веса определяются до расчёта, ниже приведён пример для адаптации к своей игре.
Оценка каждого показателя умножается на его вес, а сумма даёт балл группы. Баллы групп учитываются пропорционально их доле в аудитории. При близких баллах решает стабильность маршрута: routing path, который меняет транзитного оператора от серии к серии, рискованнее ровного пути даже при равном p95. Учитывается и доступность измерительных endpoints, поскольку регион, который нечем перепроверить после запуска, теряет в надёжности сравнения. Если общего подходящего региона нет, стоит оценить несколько серверов для разных групп.
Когда повторять тесты
После запуска те же участники и тот же сценарий помогут проверить качество на постоянном IP. Новые замеры нужны после смены адреса, провайдера, настроек фильтрации или появления жалоб из конкретной сети.
География игроков тоже меняется. Новая большая группа может изменить выбор даже при прежнем качестве маршрутов. Поэтому список городов, операторов и долей активных участников нуждается в обновлении.
У отчёта должны быть автор, даты и часовой пояс, тестовые адреса, конфигурация VM, версии утилит и игры. Сводный CSV без сырых данных не перепроверить, поэтому рядом сохраняют ряды RTT, трассировки и заметки об игре. Перед публикацией из журналов удаляют домашние IP и другие личные данные. Рядом с выводом укажите дату замеров. Маршрутизация меняется, и вывод стареет вместе с ней.
Выбор локации игрового сервера по пингу заканчивается решением с понятными условиями: для каких групп подходит регион, где остаются ограничения и когда проходила проверка. При близких результатах стоит продлить тест. До окончательного переноса стоит сохранить возможность вернуться на прежнюю площадку, если новый маршрут окажется нестабильным
Технический дефолт ТТК в Омске: как провайдер два года врет абонентам, держит железо 2008 года и игнорирует Минцифры
Привет, Пикабу. Хочу предать огласке историю своей двухлетней борьбы с омским филиалом провайдера ТТК. Этот пост — детальный разбор и предупреждение для всех, кто ищет стабильный интернет в Омске для онлайн-игр, удаленной работы или просто ценит безопасность своих личных данных. Ниже я подробно распишу, как крупная федеральная телеком-компания умудряется в 2026 году продавать услуги через оборудование времен финансового кризиса, полностью игнорирует профильные министерства и оставляет критические уязвимости в безопасности всей домашней сети.
Часть 1. Музейный экспонат на чердаке и два года лжи.
Все началось с того, что я решил подключить тарифный план на 500 Мбит/с. Тариф официально рекламируется ТТК в Омске уже очень давно. Но подключить его мне не могут уже два года. Ответ поддержки всегда один и тот же, как под копирку: «Необходима модернизация сети на вашем доме».
Мне надоело слушать эти сказки, и я решил провести собственное расследование. Оказалось, что на наш стоквартирный дом ТТК до сих пор использует древний коммутатор 2008 года выпуска! У этого ископаемого железа максимальная скорость на порт физически ограничена 100 Мбит/с. Менять его компания просто отказывается из соображений копеечной экономии.
Для понимания масштаба позора: в этом же доме Дом.ру еще в 2019 году обновил инфраструктуру, поставил гигабитные железки Huawei и без проблем выдает до 900 Мбит/с. Ростелеком уже лет 8–10 стабильно возит по дому 600 Мбит/с. И только ТТК в 2026 году предлагает абонентам технологии времен финансового кризиса 2008 года.
Часть 2. Игровой ад по WinMTR и дырявая безопасность.
Из-за износа и перегрузки этого хлама страдает абсолютно всё:
Дикий джиттер и пакетлосс. Каждый божий день в играх и на видеоконференциях идут потери пакетов до 5%. Я собрал базу из 20+ скриншотов тестов утилиты WinMTR в разное время суток. Картина везде одинаковая: задержки (джиттер) на первом же хопе (кабель напрямую из квартиры в их свитч на чердаке) составляют от 50 до 100 мс! Играть в шутеры или онлайн-стратегии невозможно, пинг скачет как сумасшедший еще до того, как сигнал вышел из дома.
Слив данных соседей. Сеть настроена настолько некомпетентно, что на оборудовании отсутствует базовая изоляция портов. Обычная команда arp -a в консоли Windows напрямую выдает IP-адреса моих соседей по дому. Это грубейшее нарушение сетевой безопасности и конфиденциальности.
Часть 3. Круговая порука и игнор властей
Я прошел все возможные инстанции:
1) Написал 6 подробных обращений в личном кабинете ТТК — в ответ получил только шаблонные отписки.
2) Мою жалобу на джиттер перенаправили в Новосибирск, где местный техник хамски заявил, что 100 мс задержки на первом хопе — это «нормально», и просто закрыл тикет. Центральный офис в Москве проблему проигнорировал.
3) Я обратился в Минцифры. Специалист ведомства лично звонил директору Омского филиала ТТК. Результат? Директор омского ТТК просто проигнорировал звонки и запросы из профильного министерства.
4) Была отправлена подробная жалоба на 20 листах в Роскомнадзор с описанием нарушений безопасности и использования несертифицированного железа. Итог — ведомство прислало стандартную формальную отписку.
Подключать ТТК в миллионном городе в 2026 году — это сознательный шаг в каменный век. Пока другие операторы без проблем выдают честный гигабит, эти деятели будут годами кормить вас обещаниями о модернизации, скрывая, что на доме стоит свитч из 2008 года. Вы будете платить по современным тарифам, а взамен получите древний хлам на чердаке, слив ваших IP-адресов в общую сеть и полное наплевательство руководства. Голосуйте рублем за нормальных конкурентов, а эту контору обходите за километр. Не тратьте свои нервы на компанию, которая умудряется игнорировать даже профильное министерство. Выбирайте тех, кто следит за своим железом, а ТТК пусть и дальше сидит без клиентов со своими древними коммутаторами.
Снова любимый Ростелеком. Качественная услуга = потеря нервной клетки?
Не люблю писать публичные жалобы, но ситуация с Ростелекомом зашла в абсолютный тупик. Это история о том, как огромный провайдер превращает жизнь абонента в «день сурка» из-за программного сбоя в собственной системе.
Техническая суть: Уже неделю магистральная маршрутизация до азиатского сегмента (Япония, Сингапур) работает через... Европу. Вместо прямого пути в 30–50 мс, пакеты из Хабаровска летят в Москву/Франкфурт, а оттуда возвращаются в Азию. Итог — пинг 360+ мс.
Подобное уже случалось в 2023–2024 годах, и тогда проблема была массовой. Сейчас ситуация повторяется: судя по всему, у РТК либо упали прямые пиринги, либо криво настроены BGP-метрики, и трафик сливается дефолтным маршрутом через западные аплинки.
Замкнутый круг техподдержки: Я честно пытался решить это через поддержку. Раз десять. Но каждый раз натыкаюсь на стену: «У нас не работает программа диагностики, система обновляется. Без неё мы не можем зафиксировать обращение. Позвоните через 2 часа».
Я пытаюсь объяснить: проблема на сетевом уровне, на магистрали. Моя линия в порядке, задержка до шлюза <1 мс. Но оператор — заложник интерфейса: нет галочки от автоматического теста — кнопка «создать заявку» не нажимается.
Самое смешное: у соседа в моем же доме и у друга в доме напротив эта диагностика проходит без проблем. А на моем лицевом счету она стабильно «висит». Почему? Поддержка ответить не может. Получается идеальная схема: проблема есть, но заявить о ней нельзя, потому что инструмент для фиксации проблемы сломан именно на мне.
Пруфы для технарей: Чтобы исключить вопросы, я сделал замеры напрямую с роутера.
Маршрут: На 3-м хопе трафик покидает Хабаровск и мгновенно набирает задержку в 100 мс (привет, Москва и Европа).
Потери пакетов: На транзитных узлах (3, 4 и 5 хопы) стабильные потери пакетов 12–16%. Это не просто лаги, это полная невозможность пользоваться сервисами, чувствительными к задержкам.
Финал: Средний пинг до Японии — 362 мс. Расстояние 1500 км пакеты преодолевают так, будто летят через Луну.
Судя по тегу «Ростелеком», здесь в комментариях дежурят сотрудники первой линии. Я почти уверен, что сейчас придет официальный представитель и напишет: «Нам очень жаль, напишите нам в ЛС, и мы разберемся». Я напишу, и мне снова ответят, что «диагностика не работает, подождите 2 часа».
Буду держать читателей в курсе. Интересно, сможет ли компания признать проблему с маршрутами и починить этот «сломанный телефон» в поддержке, или Дальний Восток так и будет играть через Германию.
UPD: О чудо! Мы пробили стену первой линии поддержки Ростелекома! 🎉
Победа пока не окончательная, но промежуточный босс пройден. Пришлось пободаться в личных сообщениях и по телефону, отбиваясь от стандартных предложений «перезагрузить роутер» и «проверить кабель».
Помогла тяжелая артиллерия: отправил им сырые логи mtr напрямую из консоли роутера, где черным по белому видны потери пакетов и скачок задержки на их внутрироссийском магистральном узле. После этого скрипты у поддержки закончились, и заявку, наконец-то, передали на 2-ю линию








