VPS во Франкфурте: преимущества и выбор хостинга

Кому подходит VPS-хостинг во Франкфурте

VPS-хостинг во Франкфурте подходит проектам, чьи пользователи находятся в Германии, на более широком немецкоязычном рынке или распределены по всей территории Европейского союза. Франкфурт — один из узлов, где сходятся европейские сети и напрямую обмениваются трафиком, поэтому сервер в этом городе достигает большинства точек континента за несколько десятков миллисекунд. Если ваши пользователи преимущественно находятся в Северной Америке, европейский сервер будет казаться им медленным, независимо от производительности самой машины, так как расстояние создает задержку, которую невозможно устранить настройками.

Выбор локации определяется двумя отдельными вопросами, и их смешение приводит к неверным решениям. Первый вопрос — где находятся ваши пользователи; это вопрос о расстоянии и времени кругового обмена данными (RTT). Второй вопрос — где разрешено хранить ваши данные; это юридический и договорной вопрос. Франкфурт дает весомый ответ на первый вопрос для европейской аудитории. Что касается второго, он снимает одну конкретную проблему, но не решает остальные.

Почему Франкфурт обладает такой высокой связностью?

Во Франкфурте расположен DE-CIX (Deutsche Commercial Internet Exchange) — точка обмена интернет-трафиком (IXP), одна из крупнейших в мире по пиковой нагрузке и количеству подключенных сетей. IXP представляет собой общую коммутационную среду внутри дата-центра, где независимые сети соединяются друг с другом напрямую, вместо того чтобы платить крупным магистральным провайдерам за передачу трафика между ними. DE-CIX публикует текущую статистику трафика на своем сайте. Эти показатели постоянно меняются, поэтому лучше смотреть их там, а не доверять цифрам, скопированным в статью.

Практический эффект заключается в маршрутах, а не в общих объемах. Когда сеть вашего провайдера и сеть интернет-провайдера (ISP) вашего пользователя подключены к одной и той же точке обмена, трафик между ними проходит через один маршрутизируемый узел в этой точке. Если же они не обмениваются трафиком напрямую, данные должны пройти через третью сеть, которая связывает их обе, причем ближайшая точка передачи трафика этой сети может находиться в другой стране. Две немецкие сети, обменивающиеся трафиком через Амстердам или Лондон, дважды оплачивают лишнее расстояние — по разу в каждом направлении. Сетевые инженеры называют это «эффектом тромбона» (tromboning), и это основная причина, по которой сервер, находящийся географически близко, по результатам измерений оказывается «далеким».

Это можно не предполагать, а увидеть. Запустите mtr до вашего сервера из интересующей вас сети и изучите имена узлов в обратном DNS. Имена хостов маршрутизаторов обычно содержат коды аэропортов IATA, поэтому fra в имени узла означает Франкфурт, ams — Амстердам, а lhr — Лондон. Если путь от немецкого потребительского соединения до немецкого сервера показывает lhr посередине, это прямо указывает, где именно теряются лишние миллисекунды.

Как далеко Франкфурт находится от ваших пользователей?

Свет в оптоволокне распространяется примерно со скоростью две трети от скорости в вакууме, что составляет около 200 000 километров в секунду. Путь туда и обратно преодолевает расстояние дважды, поэтому минимально возможное время кругового маршрута на дистанции d километров составляет d/100 миллисекунд. Это теоретический предел, и он полезен тем, что быстрее него ничего быть не может.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

Эти значения рассчитаны исходя из расстояния по прямой, а не измерены фактически. Последний столбец следует воспринимать как наилучший сценарий, допустимый законами физики. Реальные измерения обычно в 1.5–2 раза превышают этот предел, так как оптоволокно прокладывается вдоль дорог и речных долин, а не по дуге большого круга, а каждый маршрутизатор на пути добавляет небольшую задержку на пересылку и постановку в очередь.

Берлин находится на расстоянии 424 км от Франкфурта, что дает минимальную задержку 4.2 мс. Мадрид удален на 1,419 км, с минимальной задержкой 14.2 мс, и это самый дальний угол ЕС отсюда. Нью-Йорк находится на расстоянии 6,206 км с минимальной задержкой 62.1 мс, поэтому работа с трансатлантической аудиторией — это вопрос выбора локации, а не настройки производительности.

Как медленный round trip влияет на время загрузки страницы?

Один round trip редко ограничивается одним обменом пакетами. Установление HTTPS-соединения требует одного round trip для TCP (transmission control protocol) handshake и еще одного для TLS (transport layer security) 1.3 handshake. Затем требуется третий round trip, прежде чем придет первый байт ответа. TLS 1.2 добавляет четвертый. DNS (domain name system) запрос, если он не закэширован, добавляет как минимум еще один, причем к другому серверу.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

Столбец с round trip здесь — это допущение о вероятном пути до сервера во Франкфурте, а второй столбец — результат арифметических вычислений: три round trip до получения первого байта. Пользователь во Франкфурте ждет 15 мс. Пользователь в Сингапуре при времени round trip в 170 мс ждет 510 мс того же ответа, прежде чем браузер начнет что-либо отрисовывать.

Множитель — это ключевой момент. Каждая лишняя миллисекунда RTT (round-trip time) добавляет около трех миллисекунд до получения первого байта, и задержка продолжает накапливаться. HTML ссылается на таблицу стилей, таблица стилей — на шрифт, и каждое такое обнаружение ресурса требует нового round trip по тому же соединению. Добавление пары сотен миллисекунд из-за расстояния превращает мгновенно загружавшуюся страницу в медленную, хотя сервер выполняет ту же работу за то же время.

Это также определяет границы возможностей CDN (content delivery network). Статические файлы, отдаваемые из кэша рядом с пользователем, позволяют избежать длинного пути. Но для авторизованной панели управления, которой нужно отправить запрос к базе данных, это не работает: такой запрос всё равно дважды преодолевает всё расстояние. Размещение origin-сервера рядом с пользователями, которые входят в систему, — это задача, которую не решает ни один кэш.

Как измерить это из сети, где находятся пользователи?

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

ping -c 20 your-server.example.com

Итоговая строка читается как rtt min/avg/max/mdev = .... Смотрите avg для типичного случая и mdev для джиттера (вариации задержки между пакетами). Нормальный avg при высоком mdev означает, что путь нестабилен, и это вредит интерактивной работе, такой как SSH или голосовая связь, сильнее, чем слегка повышенное среднее значение.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r выводит отчет вместо динамического отображения, -w сохраняет полные имена хостов, -z показывает номер AS (автономной системы) для каждого узла, а -c 50 отправляет пятьдесят циклов. Потери на одном промежуточном узле при отсутствии потерь на конечном — это нормально и не является неисправностью: многие маршрутизаторы ограничивают скорость ответов ICMP, которые они генерируют сами, при этом корректно пересылая остальной трафик. Потери, которые начинаются на определенном узле и сохраняются на всех последующих, являются реальными потерями.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

Каждое поле представляет собой накопленное время в секундах с момента начала запроса, поэтому их нужно читать путем вычитания. time_namelookup — это DNS. time_connect минус это значение — время TCP-рукопожатия, близкое к одному полному циклу обмена данными (round trip). time_appconnect минус time_connect — это TLS-рукопожатие. time_starttransfer минус time_appconnect — это время обработки запроса вашим приложением плюс еще один полный цикл обмена. Если эти интервалы малы, а total все еще велико, проблема в вашем коде, а не в географическом расположении.

Для измерения пропускной способности, а не задержки, запустите iperf3 -s на VPS, откройте соответствующий порт в брандмауэре и запустите iperf3 -c your-server.example.com -R на клиенте для тестирования скорости загрузки. Чтобы проводить измерения из мест, где у вас нет доступа к машине, используйте RIPE Atlas, который предоставляет зонды по всей Европе. При сравнении двух серверов, а не двух сетей, используйте фиксированную методику вместо разовых замеров; именно для этого предназначен воспроизводимый тест производительности VPS.

Делает ли сервер во Франкфурте мой проект соответствующим GDPR?

Нет, и причину стоит сформулировать точно. Регламент GDPR (General Data Protection Regulation) применяется в зависимости от того, чьи персональные данные вы обрабатываете и где зарегистрирована ваша организация, а не от страны, в которой находится оборудование. Перенос сервера во Франкфурт не обеспечивает соответствие, а работа сервера за пределами ЕС не нарушает его автоматически. Географическое положение — лишь один из многих факторов.

Что действительно упрощает хостинг внутри ЕС или ЕЭЗ (Европейской экономической зоны), так это вопрос международной передачи данных. В регламенте есть целая глава о передаче персональных данных за пределы ЕЭЗ, для чего требуется правовой инструмент, такой как решение об адекватности или стандартные договорные условия. Данные, которые остаются во Франкфурте, не передаются, поэтому данная глава к этому этапу не применяется. Это реальное упрощение, и именно в этом заключается объективная польза.

Всё остальное остаётся вашей зоной ответственности. Вам по-прежнему нужны законные основания для каждой цели обработки, работающие механизмы доступа и удаления данных для пользователей из вашей базы, лимиты хранения, которые вы реально соблюдаете, меры безопасности, соответствующие рискам, а также уведомление надзорного органа в течение 72 часов после обнаружения утечки персональных данных. Вам также потребуется договор с хостинг-провайдером, в Германии известный как Auftragsverarbeitungsvertrag или AVV. Учтите также, что сервер во Франкфурте может подразумевать передачу данных, если к нему имеют доступ сотрудники службы поддержки, находящиеся за пределами ЕЭЗ, поэтому проверяйте, у кого есть ключи доступа.

Германия добавляет свой уровень требований: федеральный закон BDSG (Bundesdatenschutzgesetz) дополняет регламент национальными правилами, и данные сотрудников — это та область, которая чаще всего становится неожиданностью. Этот раздел является общим обзором, а не юридической консультацией. Европейский совет по защите данных публикует официальные руководства на сайте edpb.europa.eu, и любые вопросы, имеющие реальные последствия, требуют обращения к квалифицированному консультанту, а не к учебному пособию.

Что нужно изменить на самом сервере?

Используйте системное время в формате UTC (всемирное координированное время), а форматирование меток времени выполняйте на уровне приложения. В Германии осуществляется переход на летнее время, поэтому местное время дважды в год сдвигается на час, а один час в конце октября повторяется. Логи, записанные по местному времени, содержат две записи 02:30 в эту ночь, из-за чего сопоставление событий между регионами превращается в догадки. Если вам всё же необходимо местное время на сервере, установите его явно и проверьте:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Вывод должен показывать Time zone: Europe/Berlin (CEST, +0200) летом и +0100 зимой.

Немецкий текст сортируется некорректно при использовании локали по умолчанию C, так как сортировка C сравнивает «сырые» байты. Сгенерируйте локаль и посмотрите на разницу:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

Первая сортировка ставит Äpfel после Zebra, так как первый байт в UTF-8 больше любого символа ASCII. Вторая ставит его рядом с Apfel, где его ожидает увидеть немецкий читатель. Это важнее, чем кажется, поскольку PostgreSQL и MySQL фиксируют правила сортировки (collation) при создании базы данных, и их изменение впоследствии потребует перестроения индексов. Примите решение до загрузки данных.

Немецкое зеркало репозиториев ускоряет выполнение apt. В Ubuntu 24.04 источники находятся в /etc/apt/sources.list.d/ubuntu.sources в формате deb822, поэтому измените строку URIs: на http://de.archive.ubuntu.com/ubuntu/, вместо того чтобы добавлять второй файл. Добавление файла приведет к Target Packages ... is configured multiple times, что вызывает ошибку дублирования источников deb822 и останавливает обновления до тех пор, пока вы её не устраните.

Опубликуйте запись AAAA. Некоторые немецкие интернет-провайдеры предоставляют потребительским подключениям конфигурацию DS-Lite (dual-stack lite), при которой у клиента вообще нет публичного IPv4-адреса, а его IPv4-трафик проходит через трансляционный шлюз провайдера. Этот шлюз добавляет задержки и перегружается в часы пик, в то время как IPv6-трафик идет напрямую. Проверьте оба пути после добавления записи:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

Результат 200 от второй команды означает, что IPv6 работает напрямую. Could not resolve host или ошибка подключения означают, что запись или слушающий процесс отсутствуют, и ваши посетители с DS-Lite используют медленный путь.

Когда Франкфурт — не лучший выбор

• Ваши пользователи находятся в США. Обслуживайте их оттуда: VPS в Далласе расположен в центре страны, а хостинг VPS в Нью-Йорке обеспечивает кратчайший путь для восточного побережья и трафика, который в любом случае пересекает Атлантику.
• Ваши пользователи находятся в Латинской Америке. Франкфурт дальше от Сан-Паулу, чем Нью-Йорк, поэтому VPS в Бразилии — оптимальное решение для этой аудитории.
• Ваши данные должны храниться в определённой стране за пределами ЕС. Работа с государственным сектором Канады — типичный пример, и в статье что действительно важно для канадского VPS-хостинга рассматриваются вопросы резидентности данных.
• Вы запускаете игровой сервер. Игроки чувствуют каждую миллисекунду времени кругового обхода (RTT), поэтому близость к ним важнее любых других характеристик: выбор VPS для игровых серверов подробно описывает этот процесс.

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

FAQ

Достаточно ли одного VPS во Франкфурте для всей Европы?

Для большинства проектов — да. Расстояние по прямой задает нижний предел в 12.0 мс до Стокгольма и 14.2 мс до Мадрида. Реальные маршруты обычно в 1.5–2 раза длиннее, поэтому почти весь Евросоюз остается в пределах нескольких десятков миллисекунд от одного сервера во Франкфурте. Добавляйте вторую локацию, только если вы получили реальные жалобы из конкретной страны или если вам требуется отказоустойчивость, а не скорость.

Делает ли хостинг во Франкфурте мой проект соответствующим GDPR?

Нет. GDPR применяется в зависимости от того, чьи персональные данные вы обрабатываете и где зарегистрирована ваша организация, а не от того, где находится сервер. Хостинг в ЕС снимает вопрос о трансграничной передаче данных для этого сегмента, что является реальным упрощением и единственным преимуществом. Вам по-прежнему нужны законные основания, реализация прав субъектов данных, лимиты хранения, меры безопасности, уведомление об утечках в течение 72 часов и договор с провайдером об обработке данных (в Германии называется AVV). Это общая информация, а не юридическая консультация.

Какую задержку ожидать между Франкфуртом и Берлином?

Расстояние между этими городами составляет 424 км, что задает физический предел round-trip time в 4.2 мс. Хорошо настроенный маршрут обычно дает задержку в 1.5–2 раза выше этого предела. Проверьте это с помощью ping -c 20 your-server.example.com из Берлина и посмотрите значение avg в строке rtt min/avg/max/mdev. Результат, значительно превышающий этот диапазон, обычно означает, что трафик покинул пределы Германии и вернулся обратно, что можно увидеть в именах хопов через mtr -rwzc 50.

Стоит ли устанавливать часовой пояс Europe/Berlin на сервере во Франкфурте?

Обычно нет. Оставьте системное время в UTC, чтобы логи оставались сопоставимыми, а временные метки — однозначными. Германия переходит на CEST весной и обратно на CET осенью. В осеннюю ночь один местный час повторяется дважды, поэтому два разных события могут получить одинаковую локальную временную метку. Форматируйте время в локальной зоне на уровне приложения, где у вас есть контекст для корректного отображения. Если вы все же хотите перевести всю систему на местное время, выполните sudo timedatectl set-timezone Europe/Berlin и проверьте результат командой timedatectl.

Будет ли сервер только с IPv4 проблемой для пользователей из Германии?

Он будет работать, но для некоторых пользователей соединение будет медленнее. Многие немецкие провайдеры используют для домашних подключений схему DS-Lite без публичного IPv4-адреса. Такие клиенты обращаются к серверу с поддержкой только IPv4 через трансляционный шлюз провайдера, что увеличивает задержку и создает перегрузки в часы пик. Публикация AAAA-записи и прослушивание IPv6 обеспечивают прямой путь. Протестируйте это с помощью dig AAAA your-server.example.com +short и запроса curl -6; ожидайте HTTP 200 для обоих семейств адресов.