Как выбрать локацию подключения для работы с серверами и облаками
Когда в приложении двадцать стран, хочется выбрать «самую быструю». Но быстрая для одной задачи страна бывает медленной для другой. Выбор зависит от того, с чем вы работаете.
Задержка зависит от расстояния
Сигнал в оптоволокне проходит около 200 тысяч километров в секунду. Значит, каждая тысяча километров маршрута добавляет примерно 10 миллисекунд к времени «туда и обратно». Кабели идут не по прямой, поэтому на практике задержка ещё выше. Из Европы до сервера в Северной Вирджинии она не опустится ниже нескольких десятков миллисекунд, как бы хорошо ни был настроен канал.
Для ориентира: от Москвы до Франкфурта около 2000 километров по прямой. Значит, меньше 20 миллисекунд туда и обратно между этими городами не получится ни при каком провайдере.
Вывод простой: выходите в сеть ближе к тому, с чем работаете чаще всего.
Пинг до локации и время до сервиса
Задержка через удалённую точку складывается из двух участков: от вас до локации и от локации до нужного сервера. Пинг в списке стран обычно показывает только первый участок. Поэтому страна с самым низким пингом не обязательно даст самый быстрый ответ от вашего API.
Правило такое: выбирайте локацию на пути к серверу или рядом с ним, а не в стороне. Крюк через третью страну удлиняет оба участка. Если вы в Европе, а сервер в Германии, разумно выбрать Германию или соседнюю страну. Если сервер в США, европейская локация рядом с вами даст тот же длинный участок через океан, только позже.
| Задача | Что важно | Как выбирать |
|---|---|---|
| SSH, удалённый рабочий стол, консоль базы | Задержка и её стабильность | Ближе к серверу |
| git clone, docker pull, npm install | Пропускная способность и отсутствие потерь | Самый стабильный канал: многие реестры раздают файлы через CDN |
| API облака и веб-панели | Задержка каждого запроса | Ближе к региону облака |
| Созвоны и демонстрация экрана | Задержка и джиттер | Ближе к себе или к собеседникам |
| Проверка сайта глазами пользователей из другой страны | Страна IP-адреса | Страна целевой аудитории |
В интерактивной работе каждая лишняя миллисекунда заметна: в SSH задержка добавляется к каждому нажатию клавиши. Для загрузок важнее потери пакетов. При потерях скорость одного TCP-соединения падает примерно обратно пропорционально задержке, поэтому далёкий маршрут с небольшими потерями качает заметно медленнее близкого.
Для созвонов важна не только средняя задержка, но и её разброс, джиттер. Если пинг постоянно скачет, звук будет прерываться даже при хорошем среднем значении.
Облачный регион и страна подключения
Ориентируйтесь на город дата-центра, а не на название провайдера. Провайдеры указывают расположение регионов в документации, а зоны доступности внутри одного региона находятся рядом друг с другом, так что для выбора локации они не важны. Соответствие для популярных регионов:
| Где ваши серверы | Какую локацию выбрать |
|---|---|
| AWS eu-central-1, Google Cloud europe-west3, Hetzner в Германии | Германия |
| Google Cloud europe-west4, Azure West Europe, DigitalOcean AMS3 | Нидерланды |
| Hetzner в Хельсинки, Google Cloud europe-north1 | Финляндия |
| AWS eu-west-2, Azure UK South | Великобритания |
| AWS eu-west-3, Scaleway | Франция |
| AWS eu-north-1 | Швеция |
| Google Cloud europe-central2, Azure Poland Central | Польша |
| AWS us-east-1, Google Cloud us-east4 | США |
| AWS ap-northeast-1 | Япония |
| AWS ap-southeast-1 | Сингапур |
| AWS ap-south-1 | Индия |
| AWS sa-east-1 | Бразилия |
Если сервис работает через CDN, расположение его серверов для статики почти не важно: файлы отдаёт ближайший к вам узел CDN. Но запросы к API и динамические страницы часто всё равно идут к основному серверу в одном регионе.
Как узнать, где на самом деле сервер
Регион не всегда очевиден из документации. Начните с адреса и его владельца (в Windows вместо dig подойдёт nslookup):
dig +short api.example.com
whois 203.0.113.10 | grep -i -E 'country|netname|orgname'Для адресов крупных облаков есть точный способ: AWS публикует диапазоны IP по регионам в файле ip-ranges.json, Google Cloud в файле cloud.json. Найдите в них свой адрес, и регион станет известен без догадок.
Для сервиса за CDN адрес покажет узел CDN, а не сервер приложения. Какой узел вам ответил, видно по заголовкам:
curl -sI https://example.com | grep -i -E 'cf-ray|x-amz-cf-pop|x-served-by|server'В заголовке cf-ray от Cloudflare в конце стоит код аэропорта города, где находится узел, например FRA для Франкфурта. У CloudFront ту же роль играет x-amz-cf-pop, у Fastly x-served-by. Если узел оказался на другом континенте, задержка будет высокой при любой локации.
Ещё одна ловушка: многие CDN выбирают узел по адресу DNS-резолвера. Если резолвер далеко от вас, вас могут направить на далёкий узел. Если сайт неожиданно медленный, сравните ответы через разные DNS-серверы.
Проверьте за минуту
Сравните две или три подходящие локации на своих задачах. Для сервера:
ping -c 20 your-server.example
mtr -rwc 50 your-server.exampleping покажет среднюю задержку и разброс (mdev в Linux, stddev в macOS), mtr покажет, на каком участке маршрута теряются пакеты. Для веб-сервисов и API удобнее curl:
curl -o /dev/null -s -w 'connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n' https://api.example.comДля загрузок задержка мало что говорит, проверяйте скорость. Скачайте крупный файл со своего сервера или из нужного реестра: переменная speed_download выводит среднюю скорость в байтах в секунду. Если у вас есть доступ к серверу, точнее измерит iperf3: на сервере iperf3 -s, у себя iperf3 -c your-server.example -R, где ключ -R проверяет направление от сервера к вам.
curl -o /dev/null -s -w 'speed %{speed_download}\n' https://your-server.example/big-file.binПовторите каждую проверку несколько раз. Одно измерение ничего не говорит, важны среднее значение и разброс.
Команды в Windows и macOS
- Windows:
ping -n 20 your-server.example. Вместоmtrподойдёт встроенныйpathping, он показывает потери на каждом узле маршрута. - В Windows PowerShell
curlможет оказаться псевдонимом другой команды, поэтому вызывайтеcurl.exe. Он входит в Windows 10 и 11. - Доступность порта проверяет
Test-NetConnection your-server.example -Port 22. - macOS:
mtrставится через Homebrew (brew install mtr) и запускается черезsudo. - Linux:
mtrобычно лежит в пакетеmtrилиmtr-tiny,iperf3в одноимённом пакете.
Когда переключаться
- Вечером нагрузка на сети растёт. Если привычная локация стала медленнее, переключитесь на соседнюю в том же регионе.
- Если
mtrпоказывает потери на дальнем участке маршрута, смена локации меняет и сам маршрут. Это часто помогает быстрее, чем ожидание. - Держите в избранном две или три страны под разные задачи: например, Германию для европейских серверов и США для американских API.
- Некоторые панели привязывают сессию к IP-адресу и после смены локации просят войти заново. Переключайтесь между задачами, а не посреди деплоя.
- Для проверки геозависимого поведения своего сайта (язык, валюта, редиректы) выбирайте страну пользователей, а не страну сервера.
Частые ошибки при выборе
- Выбирать страну по пингу до локации, а не по времени ответа нужного сервиса.
- Делать выводы по одному замеру в час пик.
- Забывать про кэш DNS. После смены локации система какое-то время может вести вас на старый узел CDN. Сбросьте кэш: в macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, в Windowsipconfig /flushdns, в Linux с systemd-resolvedresolvectl flush-caches. - Сравнивать локации на разных задачах: один замер на
git clone, другой на открытии сайта. Для честного сравнения используйте одну и ту же команду.
Коротко
- Каждая тысяча километров маршрута добавляет около 10 мс к времени туда и обратно.
- Выбирайте локацию на пути к серверу или рядом с ним, а не в стороне.
- Для SSH и API выбирайте локацию рядом с сервером, для загрузок самую стабильную.
- Регион облака сопоставляйте по городу дата-центра.
- Проверяйте
ping,mtrиcurl -w, делая по несколько замеров. - После смены локации сбросьте кэш DNS, если сайт ведёт себя странно.
- Смена локации не требует новой оплаты: все страны входят в один ключ.