Как выбрать локацию для VPS в Европе: считаем по задержке

Вы решили взять VPS в Европе и застряли на выборе страны: Нидерланды, Франция, Латвия, Эстония - разница вроде бы есть, но какая именно? Короткий ответ на вопрос, как выбрать локацию для VPS: считать не по ощущениям и не по картинке на сайте хостинга, а по реальной задержке до вашей аудитории. Ещё более короткий: для блога, телеграм-бота, крон-задачи или хранилища бэкапов страна почти не важна - берите то, что дешевле и удобнее. Ниже разберём, когда задержка действительно решает, как померить её самому за пять минут и почему сервер «в соседней стране» иногда отвечает медленнее, чем сервер за полторы тысячи километров.

TL;DR. Задержка (RTT, round-trip time - время «туда и обратно») складывается из физики и маршрутизации. Физика: свет в оптоволокне идёт примерно 200 км за миллисекунду в одну сторону, то есть round trip набирает около 1 мс на каждые 100 км пути. Маршрутизация добавляет сверху ещё 30-100%. RTT из ping - это уже почти весь сетевой вклад в ожидание ответа (запрос ушёл, ответ вернулся), а при новом соединении сверху ложатся TCP/TLS-рукопожатия. Меряйте ping, mtr и curl -w со стороны ваших пользователей до конкретной локации-кандидата и решайте по числам. Из четырёх локаций WeaselCloud для Западной и Центральной Европы обычно ближе Нидерланды или Франция, для Балтии и аудитории из СНГ - Латвия или Эстония, но это гипотеза для проверки, а не закон. Глобальная аудитория или сайт за CDN - локация источника влияет мало.

Что такое RTT и почему это не вся задержка

Задержка (латентность) - это время, за которое пакет данных доходит от точки А до точки Б. На практике вы почти всегда видите RTT (round-trip time) - время в оба конца: запрос ушёл на сервер, ответ вернулся. Именно это число показывает ping.

Половину RTT иногда используют как очень грубую оценку задержки в одну сторону: если ping = 40 мс и маршрут симметричный, то распространение сигнала в одну сторону - примерно 20 мс. Но пользователь нажимает кнопку не для того, чтобы пакет дошёл до сервера, - ему нужен ответ обратно. Для уже установленного соединения цепочка «клиент → сервер → обработка → клиент» по сети занимает уже близко к полному RTT, а не к половине. А если соединение надо ещё установить, добавляются TCP- и TLS-рукопожатия - это ещё несколько RTT сверху. HTTP/3, переиспользование соединения и TLS 1.3 сокращают эти рукопожатия, но принцип остаётся: сетевой вклад в отклик - это порядка целого RTT, плюс время обработки на сервере.

Практический вывод простой. RTT 40 мс для интерактивной работы - это комфортно, человек почти не замечает. RTT 250 мс уже ощущается как вязкость интерфейса. Ориентируйтесь на полное значение из ping, а не на его половину.

Откуда задержка берётся - две составляющие.

• Физика. Свет в стекле оптоволокна идёт примерно на треть медленнее, чем в вакууме - около 200 000 км/с. Это ~200 км за миллисекунду в одну сторону, значит round trip набирает примерно 1 мс на каждые 100 км расстояния. Чем дальше от вас сервер, тем больше это число, и сделать с этим нельзя ничего.
• Маршрутизация (роутинг) - путь, которым трафик реально идёт через промежуточные маршрутизаторы. Кабель редко проложен по прямой, на каждом узле пакет чуть задерживается, иногда трафик делает крюк через другой город. В сумме это множит физический минимум примерно в 1,3-2 раза.

Отсюда грубое правило. Возьмите расстояние по карте до вашей аудитории, поделите на 100 - получите нижнюю границу RTT в миллисекундах. Реальность будет в полтора-два раза выше. Ниже физического минимума не прыгнет никто: ни оптимизация, ни «премиум-хостинг».

Когда локация важна, а когда почти нет

Задержка влияет только там, где много мелких обменов «запрос-ответ» в реальном времени и где их ждёт живой человек или жёсткий таймаут. Всё остальное к десяткам миллисекунд безразлично.

Разница на практике. Интерактивная панель, где каждый клик - это round trip к серверу, при RTT 20 мс ощущается мгновенной, при 200 мс - тормозной. Онлайн-игра с синхронизацией позиций при 150 мс уже некомфортна. Со статическим блогом за CDN сложнее: если HTML и статика реально кэшируются на ближайшем к пользователю узле, читатель почти всё время получает страницу с него, и расположение вашего VPS-источника значит мало - разница между Амстердамом и Ригой обычно небольшая. Но HTML часто не кэшируют, бывает промах кэша, а запросы к API идут прямо на источник - тогда география источника снова влияет. Бэкап на удалённое хранилище: для больших объёмов обычно важнее пропускная способность, чем лишние десятки миллисекунд RTT, - хотя на быстром канале с одним TCP-потоком высокая задержка тоже способна ограничивать скорость через механику TCP (окно перегрузки). Телеграм-бот на long polling (бот сам периодически ходит за обновлениями и держит соединение открытым) переживает и 300 мс - обычно остаётся вполне рабочим, хотя несколько лишних сетевых обменов Telegram и бот могут сложиться в заметную долю секунды.

Отдельно про SEO. Низкий TTFB (time to first byte - время до первого байта) ускоряет загрузку страницы и влияет на пользовательские метрики, в том числе на LCP. Google использует Core Web Vitals и другие сигналы качества страницы, но разница в пару десятков миллисекунд RTT из-за страны VPS сама по себе заметного преимущества в выдаче не даёт. Куда важнее, чтобы сервер не был перегружен и отдавал страницу быстро. Если аудитория глобальная, CDN даёт больше, чем удачный выбор страны.

Как измерить задержку со стороны вашей аудитории

Ключевой момент: мерять надо от пользователей к серверу-кандидату, а не от своего ноутбука или от VPS к себе. Если ваши читатели в основном в Польше, а вы в Тбилиси - ваш личный ping не скажет ничего полезного. Варианты: заказать сервер-кандидат на месяц и померить, попросить пользователя или знакомого в нужном регионе прогнать команду, либо воспользоваться браузерными тестами и RIPE Atlas (о них в конце раздела).

1. ping - базовый RTT и потери пакетов. Отправляем 20 пакетов, чтобы увидеть разброс, а не одно случайное значение.

ping -c 20 example.com

• -c 20 - число пакетов; на Windows вместо этого ping -n 20 example.com.

Что вы должны увидеть в последней строке: rtt min/avg/max/mdev = 12.3/14.1/22.7/2.1 ms. Смотрите на avg (среднее) и mdev (среднее отклонение RTT; в быту его называют джиттером, хотя строго это не одно и то же) - чем меньше mdev, тем стабильнее канал. Строка 0% packet loss означает, что потерь нет. Потери в ping - повод разобрать маршрут подробнее через mtr, но ещё не доказательство проблем с реальным трафиком: ICMP-пакеты многие сети и серверы ограничивают по скорости или фильтруют отдельно, при этом сайт нормально работает по TCP на порту 443.

2. mtr - показывает весь путь по шагам (hop за hop) и потери на каждом. Утилиты может не быть в системе, ставится пакетом mtr-tiny.

sudo apt install mtr-tiny
mtr -rw -c 100 example.com

• -r - вывести отчёт и выйти, а не крутить интерактивный режим;
• -w - широкий формат, не обрезает имена узлов;
• -c 100 - сто циклов, чтобы статистика была осмысленной.

Как читать. Если столбец Avg резко вырос на каком-то шаге и повышенная задержка держится на всех следующих узлах вплоть до конечного - скорее всего, дополнительная задержка появляется на этом участке маршрута. Слово «узкое место» здесь осторожное: промежуточные маршрутизаторы отвечают на служебные пакеты не так и не с тем приоритетом, как форвардят обычный трафик, поэтому один подскок RTT на среднем узле сам по себе ещё ни о чём не говорит. Потери (Loss%) на последнем шаге - реальная проблема; потери на промежуточном узле при нулевых на последнем означают, что маршрутизатор просто не отвечает на служебные пакеты, это можно игнорировать. По именам узлов (в них часто зашиты коды городов и аэропортов - fra, ams, waw) видно, если трафик уходит крюком. Для веб-сервера релевантнее бывает проба по TCP на порт 443, а не дефолтный ICMP:

sudo mtr -T -P 443 -rw -c 100 example.com

3. curl -w - измеряет TTFB, то есть сколько реально ждёт браузер до первого байта страницы. Это задержка плюс установка соединения плюс работа сервера - ровно то, что чувствует пользователь.

curl -w "%{time_starttransfer}\n" -o /dev/null -s https://example.com

• -w "%{time_starttransfer}\n" - вывести время до первого байта (в секундах) и перенос строки;
• -o /dev/null - тело ответа выбросить, оно нам не нужно;
• -s - без индикатора прогресса.

Запустите команду 5-10 раз подряд и смотрите на диапазон значений, а не на одно число. Каждый отдельный запуск curl - это новый процесс и новое сетевое соединение: «прогретый» коннект между запусками не переиспользуется. DNS при этом может быть закэширован системой, поэтому первый запуск иногда чуть медленнее остальных - это нормально. Чтобы понять, где именно ушло время, возьмите развёрнутую разбивку:

curl -w "dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n" -o /dev/null -s https://example.com

Здесь видно вклад каждого этапа: dns - резолв имени, tcp - установка TCP-соединения, tls - TLS-рукопожатие, ttfb - до первого байта ответа. Разница ttfb минус tls - это примерно один RTT плюс генерация ответа на сервере.

4. Браузерные тесты и RIPE Atlas. Если в нужном регионе у вас нет ни машины, ни знакомых - используйте сервисы вроде KeyCDN Performance Test и аналогов: они гонят запрос к вашему хосту из десятков точек мира и показывают TTFB с каждой. RIPE Atlas - сеть из тысяч зондов по всему миру; можно разово запустить ping или traceroute с зондов рядом с вашей аудиторией (тратятся кредиты, бесплатный лимит появляется, если вы сами держите зонд). Это лучший способ, когда «ваша аудитория» - конкретная страна, куда вы физически не дотягиваетесь.

Близко, но медленно: пиринг и транзит

Иногда сервер географически рядом, а ping до него хуже, чем до более далёкого. Причина - в том, как сети обмениваются трафиком.

Пиринг - когда две сети соединяются напрямую и обмениваются трафиком, обычно на точке обмена трафиком (IX) в конкретном городе: AMS-IX в Амстердаме, DE-CIX во Франкфурте, France-IX в Париже, RIX в Риге, TLLIX в Таллине. Транзит - когда вы платите крупной сети, чтобы она донесла ваш трафик до всех остальных. Если у провайдера в стране слабый локальный пиринг, трафик из соседнего города может уходить на обмен во Франкфурт или Стокгольм и возвращаться обратно - лишние сотни километров и плюс 20-40 мс на пустом месте. В Балтии это классическая история: пакет из Литвы в Латвию иногда путешествует через Швецию. Работает это и в обратную сторону: путь между двумя «дальними» странами бывает короче, чем ожидаешь по карте, если обе хорошо представлены на одном крупном IX.

Как это увидеть - тем же mtr -rw -c 100 (или с -T -P 443). Если на маршруте из Варшавы в Ригу мелькают узлы с sto или fra в имени, а Avg на них подскакивает - вот он, крюк. Лечится либо выбором провайдера, который присутствует на местной точке обмена, либо просто: померьте кандидатов и доверяйте числу, а не карте.

Как выбрать локацию для VPS под вашу аудиторию

Если измерения показали, что разница между вариантами - единицы миллисекунд, выбирайте по цене, юрисдикции и поддержке, а не по задержке. Если разница в десятки миллисекунд и проект интерактивный - нужен ориентир.

Таблица ниже - не универсальная карта Европы. Для Центральной Европы естественный кандидат - Германия, для Скандинавии - Стокгольм или Хельсинки, для Польши - Варшава; и пользователь из Восточной Европы не гарантированно получит меньший RTT до Риги, чем до Франкфурта, - решает BGP и пиринг конкретных провайдеров. Это стартовая гипотеза для выбора между четырьмя локациями, которые есть у WeaselCloud (NL, FR, LV, EE). Финальный выбор всё равно делайте по замерам.

У WeaselCloud европейские локации - Нидерланды, Франция, Латвия и Эстония. Прежде чем оформлять заказ, прогоните ping и curl -w до каждой из них со стороны вашей аудитории (или через RIPE Atlas и браузерный тест) и сравните числа. Если они близки - решайте по остальным критериям. Тарифы и действующие промокоды, если они сейчас есть, - на странице тарифов. Если вы не выбираете сервер с нуля, а переносите готовый проект, это отдельная тема - про неё будет отдельный разбор.

Таблица: типичная задержка между европейскими точками

Числа ниже - иллюстративные диапазоны, прикинутые из географического расстояния и типичного оверхеда маршрутизации (×1,3-2), а не результат единого замера. Ваш маршрут и ваш провайдер дадут другие значения. Это повод померить самому, а не готовый ответ.

Расстояние здесь географическое, по карте; реальный подводный кабель идёт не строго по прямой, поэтому «теоретический минимум» - это нижняя граница, ниже которой не бывает, а не то, что вы увидите. Из таблицы видно две вещи. Внутри Западной Европы всё укладывается в 5-25 мс - для большинства задач это одинаково быстро, и спор «Амстердам или Париж» чаще всего беспредметен. А трансатлантика и Азия - уже другой порядок: если у вас есть пользователи в США и в Европе одновременно, одним сервером хорошо не сделать, нужен CDN или второй узел.

FAQ

Какая задержка считается хорошей для VPS?

Для интерактивных задач ориентир такой: RTT до 30 мс - отлично, 30-80 мс - нормально и почти незаметно, 80-150 мс - терпимо, выше 150 мс - чувствуется в панелях, играх и звонках. Для блога, бота, бэкапов и фоновых задач подойдёт практически любое значение вплоть до 200-300 мс.

Ping и RTT - это одно и то же?

ping - это утилита, которая измеряет RTT (round-trip time), время прохождения пакета до хоста и обратно. Когда говорят «пинг 20 мс», имеют в виду именно RTT - полный оборот «туда и обратно». Половину RTT иногда берут как очень грубую оценку задержки в одну сторону, но время отклика приложения включает полный обмен запросом и ответом, а при новом соединении - ещё TCP/TLS-рукопожатия.

Влияет ли локация VPS на позиции сайта в поиске?

Косвенно и слабо. Низкий TTFB ускоряет загрузку и влияет на пользовательские метрики, в том числе на LCP, а Google использует Core Web Vitals в оценке качества страницы. Но разница в пару десятков миллисекунд RTT из-за страны сервера сама по себе позиции почти не двигает. Гораздо важнее не перегруженный сервер и, для глобальной аудитории, CDN.

Нужен ли VPS рядом с пользователями, если сайт за CDN?

Чаще всего нет - но с оговоркой. Если CDN реально кэширует нужный посетителю HTML и статику, тот получает их с ближайшего edge-узла, и локация источника становится вопросом удобства и цены. Если же HTML не кэшируется, случается промах кэша или на странице много запросов к API - эти обращения идут прямо на ваш сервер-источник, и его расположение снова влияет на скорость.

Почему сервер в соседней стране пингуется хуже, чем дальний?

Из-за маршрутизации и пиринга. Если у местного провайдера нет прямого обмена трафиком на локальной точке обмена, пакеты уходят на крупный хаб (Франкфурт, Стокгольм) и возвращаются, накручивая лишние километры и миллисекунды. Увидеть крюк можно в mtr по именам промежуточных узлов.

Как померить задержку до сервера, которого у меня ещё нет?

Три способа: заказать минимальный тариф на месяц и протестировать; попросить знакомого в нужном регионе прогнать ping и curl -w; запустить разовое измерение через RIPE Atlas с зондов рядом с вашей аудиторией. Многие провайдеры также публикуют тестовый IP или файл для каждой локации.

mtr показывает потери на промежуточном узле - это плохо?

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

Коротко

• Задержку задаёт физика (около 1 мс round trip на 100 км оптоволокна) плюс маршрутизация сверху (плюс 30-100%). Ниже физического минимума не опустится никто.
• Сетевой вклад в отклик приложения близок к полному RTT из ping, а при новом соединении добавляются TCP/TLS-рукопожатия. Половина RTT - лишь грубая оценка задержки в одну сторону.
• Локация критична для интерактивных панелей, игр, звонков, real-time API и трейдинга. Для блога за CDN, ботов, бэкапов, крона и очередей - почти не важна.
• Меряйте со стороны аудитории, а не от себя: ping -c 20, mtr -rw -c 100 (или -T -P 443), curl -w "%{time_starttransfer}\n" в 5-10 прогонов.
• Из четырёх локаций WeaselCloud: для Западной и Центральной Европы обычно ближе Нидерланды или Франция, для Балтии и аудитории из СНГ - Латвия или Эстония. Это гипотеза для проверки замером, а не универсальная карта Европы.
• «Близко, но медленно» - это про слабый пиринг: трафик делает крюк через дальний хаб. Видно в mtr.
• Таблица задержек - порядок величины. Перед покупкой прогоните ping до локации-кандидата сами.