PHP на VDS: как latency и MTU ломают rsync и деплой

В продакшене на VDS часто всё сводится к тюнингу PHP, базы и кешей. Но реальные затыки по времени ответа нередко живут ниже — в сети: latency, MTU, перегруженные каналы и «кривые» маршруты. Внешне это выглядит как рандомные таймауты PHP, тормозящий rsync, дёрганые графики времени ответа и жалобы пользователей «сайт иногда подвисает».

Разберёмся, как задержка (latency) и размер MTU влияют на работу PHP-проектов на VDS, деплой по rsync и сетевую стабильность, и что вы как админ можете реально подкрутить.

Что такое latency и MTU простыми словами

Небольшое напоминание в прикладных терминах, без сетевой теории ради теории.

Latency — это время, за которое пакет идёт от источника к получателю и обратно (RTT). Для нас важно:

• время установления соединения (TCP handshake, TLS handshake);
• время ожидания ответа от сервиса (HTTP, база, Redis и т.п.);
• совокупная задержка при большом количестве мелких запросов.

MTU (Maximum Transmission Unit) — максимальный размер IP-пакета на конкретном участке сети. Если пакет больше MTU, он либо фрагментируется (что плохо), либо отбрасывается (ещё хуже), иногда с ICMP-ошибкой, иногда молча.

Классика: MTU 1500 на интерфейсе сервера, но по пути где-то туннель с меньшей эффективной MTU. В итоге крупные пакеты отбрасываются, а маленькие проходят — «иногда работает, иногда нет».

Почему latency важнее «ширины канала» для PHP и rsync

Для типичного PHP-проекта на VDS критичны не только мегабиты в секунду, но и то, сколько сетевых «поездок» нужно сделать, чтобы отрендерить страницу: HTTP-запросы к API, обращения к базе, Redis, очередям, внешним сервисам.

При большой latency:

• каждое соединение по TCP/TLS создаётся заметно дольше (TCP handshake + TLS handshake = несколько RTT);
• много мелких запросов к базе или Redis начинают «раздуваться» по времени, даже если сами операции мгновенные;
• rsync с дефолтными настройками может работать на порядок медленнее, чем ожидается от доступной полосы.

Для PHP-админов и девопсов отсюда первый практический вывод:

Оптимизация числа сетевых «поездок» и переиспользование соединений (keepalive, пулы, persistent-коннекты) даёт больший профит, чем попытки «выжать» ещё пару мегабит из сети.

Если вы только планируете перенос проекта на отдельный сервер, имеет смысл изначально выбирать площадку ближе к пользователям и бекендам. Для многих задач оптимальным компромиссом по цене и управляемости будет VDS с предсказуемыми сетевыми характеристиками, где вы можете контролировать MTU, маршрутизацию и сетевые демоны.

MTU: откуда берутся странные таймауты и «залипшие» соединения

С MTU история коварнее. Неверный или неучтённый MTU часто проявляется так:

• SSH-сессия иногда «подвисает», особенно при передаче файлов;
• rsync доходит до какой-то точки и встаёт намертво без явных ошибок;
• PHP-скрипты время от времени улетают в таймаут на внешних запросах (HTTP, gRPC, SMTP), хотя сервис жив;
• мониторинг показывает «пилообразный» RTT и случайные потери пакетов.

Частая причина: по пути от вашего VDS до клиента или другого сервера есть звено с меньшей MTU, а ICMP-сообщения о слишком большом пакете где-то отбрасываются. Path MTU Discovery не может адаптироваться — и у вас часть пакетов обрубается.

Диагностика latency: ping, mtr и реальная картина

Начинаем всегда с простого. Для полноты картины полезно прогнать тесты не только «локалка ↔ VDS», но и между всеми критичными компонентами: PHP-frontend, базы, кеши, брокеры очередей.

Измеряем базовую задержку

С вашей рабочей машины до VDS:

ping -c 10 your-vds.example.com

С VDS до рабочего места (если IP статический или есть VPN):

ping -c 10 your.workstation.example.com

И обязательно до других ключевых точек: БД, кэшей, сторонних API. На этом этапе фиксируем «норму» RTT, чтобы потом сравнивать в пиковые моменты нагрузки.

Смотрим маршрут и потери с mtr

На VDS установите утилиту mtr (если её ещё нет) и проверьте проблемные направления:

mtr -rwz -c 200 your.workstation.example.com
mtr -rwz -c 200 db.internal.example

Ключевые моменты:

• потери пакетов на последних хопах — тревожный знак;
• резкие скачки latency на каком-то звене, особенно если они плавающие;
• отличие показаний mtr в обе стороны (асимметричная маршрутизация).

Важно не путать ICMP rate limiting на промежуточных хопах с реальными потерями. Если последний хоп чистый, а какие-то средние иногда показывают 80–90% потерь, это может быть просто ограничение на ICMP.

Если вы используете VPN для доступа к админке или деплоя (например, WireGuard), на поведение latency и MTU в туннеле тоже стоит смотреть. Про практические нюансы keepalive и роуминга в подобных сценариях мы подробно писали в материале о настройке WireGuard для нестабильных сетей.

Проверяем и подбираем MTU на VDS

Сначала смотрим текущий MTU на интерфейсах:

ip -o link show

Типично вы увидите что-то вроде mtu 1500. Но это не гарантирует, что путь до клиента или другого сервера реально выдержит такие пакеты.

Подбор MTU опытным путём

Используем ping с флагами -M do (не фрагментировать) и -s (размер полезной нагрузки). К размеру ICMP-пакета добавляем 28 байт заголовка IP+ICMP, чтобы получить полный размер IP-пакета.

Например, с VDS до вашей рабочей машины:

ping -M do -s 1472 your.workstation.example.com
ping -M do -s 1464 your.workstation.example.com
ping -M do -s 1430 your.workstation.example.com

Если на каком-то размере начинаются ошибки Frag needed или вообще нет ответа — уменьшайте, пока не найдёте стабильное значение. Реальная эффективная MTU будет примерно payload + 28.

Например, если стабильно проходит -s 1430, то MTU по пути порядка 1458. Имеет смысл для интерфейса VDS задать MTU чуть ниже, например 1450.

Настройка MTU на VDS

Разово (до перезагрузки):

ip link set dev eth0 mtu 1450

Постоянно — через конфиг сети (netplan, NetworkManager или системный ifupdown, в зависимости от дистрибутива). Идея одна: прописать mtu 1450 для нужного интерфейса и перезапустить сеть.

Как latency и MTU «бьют» по SSH и rsync

При деплое PHP-проектов на VDS часто используется rsync по SSH. И тут оба фактора проявляются очень ярко: от простой заливки артефактов до синхронизации сотен тысяч файлов с медленного репозитория.

Latency и rsync

rsync много общается по сети мелкими блоками. На большом RTT это превращается в доминирующий фактор, даже если у вас гигабитный канал.

Практические рекомендации:

• используйте флаги -z и --compress-level там, где полезно (много текста, PHP/JS/CSS), и отключайте компрессию на уже сжатых медиа;
• ограничивайте количество мелких файлов (build-артефакты, лог-файлы) или группируйте их в архивы для передачи;
• используйте более «шустрый» шифр SSH при высокой latency, чтобы CPU не стал бутылочным горлышком.

Пример команды для деплоя с учётом latency (данные уже сжаты, поэтому без -z):

rsync -a --delete --info=progress2 -e "ssh -o Compression=no -o TCPKeepAlive=yes -o ServerAliveInterval=30" ./build/ deploy@vds:/var/www/project

ServerAliveInterval помогает не ронять соединение при плавающей задержке, а отключённая компрессия разгружает CPU при передаче уже сжатых артефактов.

MTU и странные подвисания rsync

Типичный кейс: rsync идёт нормальной скоростью до определённого объёма, затем «замирает», не завершается и не падает с ошибкой. Или обрывается с таймаутом, но только на определённом направлении (локальная машина → VDS, а обратно — нормально).

Алгоритм действий:

1. подобрать рабочий MTU с помощью ping, как выше;
2. поставить этот MTU на интерфейс VDS;
3. если вы за NAT или VPN — учесть MTU и там;
4. проверить повторно rsync и одновременно смотреть на mtr для контроля потерь.

Иногда помогает снижение MTU на клиентской стороне (рабочая станция или CI runner), особенно если там сложная цепочка VPN и туннелей.

PHP на VDS и latency: что можно сделать на уровне приложения

Если вы уже убедились, что сеть и MTU в адекватном состоянии, но RTT объективно велик (например, пользователи или CI находятся далеко от дата-центра VDS), нужно минимизировать количество сетевых «поездок» внутри одного запроса.

Оптимизируем запросы PHP к базе

Высокая latency между VDS и базой особенно болезненна для «болтливых» ORM и N+1 запросов.

• агрессивно убирайте N+1 — жадные выборки, джойны, кэширование результатов;
• используйте подготовленные запросы и батчи, где возможно;
• подумайте о реплике БД ближе к приложению, если сейчас база живёт в другом дата-центре или регионе.

На уровне драйвера или пула (PDO, Doctrine, Eloquent) следите за таймаутами подключения и выполнения запросов — они должны учитывать реальную latency, но не быть бесконечными.

HTTP и gRPC-запросы из PHP

При вызовах внешних API из PHP latency и MTU тоже могут играть роль:

• используйте keepalive и connection pooling в HTTP-клиентах (Guzzle, Symfony HttpClient);
• настраивайте отдельные таймауты на подключение и на ожидание ответа;
• при большом RTT увеличьте ретраи, но обязательно с backoff, чтобы не добить сервис.

Пример базовой конфигурации Guzzle с учётом задержки:

$client = new \GuzzleHttp\Client([
    'timeout'         => 5.0,
    'connect_timeout' => 1.0,
    'read_timeout'    => 4.0,
    'allow_redirects' => false,
    'headers'         => [
        'Connection' => 'keep-alive',
    ],
]);

Числа примерные: подстраивайте под ваши реальные RTT (смотрите по ping и данным мониторинга).

MTU и HTTP: когда проблему видно уже «на поверхности»

Некорректный MTU может проявиться даже в самом простом сценарии: пользователь загружает крупный файл, и на определённом размере загрузка ломается, хотя мелкие файлы проходят без проблем.

Признаки:

• обрывы загрузок на стороне браузера без воспроизводимых ошибок в логах сервера;
• нестабильное поведение POST или PUT-запросов большого размера;
• частые таймауты в прокси или балансировщике на передаче тела запроса.

Если у вас прокси перед PHP (Nginx, Apache, внешний балансировщик), он может быть в другой сети или дата-центре, где своя MTU. Отладка в этом случае:

1. проверить MTU между клиентом и фронтендом (публичный адрес сайта);
2. проверить MTU между фронтендом и VDS с PHP-FPM;
3. свести MTU «внизу» (на VDS) к гарантированно рабочему минимуму, если по пути есть туннели или VPN.

На уровне PHP или Nginx вы MTU не исправите, но можете снизить чувствительность к временным потерям: увеличить таймауты на чтение тела запроса, размер буферов, включить корректные ретраи на уровне клиента. Если ваш проект использует продвинутые механики HTTP (кеширование, preloading, раннюю отправку ответов), посмотрите также материал про использование HTTP 103 Early Hints в Nginx и Apache.

Latency, очереди и фоновые задачи PHP-проектов

Очереди (Redis, RabbitMQ, Kafka и т.п.) часто выносят на отдельные хосты или управляемые сервисы. При этом latency между VDS с PHP-воркерами и брокером очереди влияет на:

• длину и скорость обработки очередей;
• размер пакетов подтверждений и подписок;
• чувствительность к кратковременным сетевым «просадкам».

Практические моменты:

• там, где возможно, используйте батчевую обработку задач, чтобы меньше «чататься» по сети;
• настраивайте timeouts и heartbeat у брокера и клиентов с запасом на вашу фактическую latency;
• размещайте критичные для задержки компоненты (PHP-воркеры и брокер) максимально близко сетево.

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

Как собрать целостную картину: чек-лист для админа PHP-проекта на VDS

Сведём всё в компактный операционный список, который можно прогонять при любом «рандомном» подвисании.

1. Базовая сеть VDS

• Проверить RTT до ключевых точек: разработчики или CI, БД, кэши, брокеры, внешние API.
• Сделать mtr в обе стороны для спорных направлений.
• Зафиксировать типичные значения RTT и потерь, чтобы потом сравнивать.

2. MTU

• Подобрать рабочий MTU для VDS по ping с -M do и -s.
• Настроить MTU на интерфейсе VDS и, при необходимости, на своих VPN и туннелях.
• Перепроверить проблемные сценарии: rsync, загрузку больших файлов, длинные SSH-сессии.

3. rsync и деплой

• Проанализировать профиль деплоя: много ли мелких файлов, где реальные «затыки».
• Подобрать опции rsync и SSH под вашу комбинацию RTT и CPU.
• При большой latency рассмотреть упаковку артефактов в tar или zip перед отправкой.

4. PHP и прикладной уровень

• Минимизировать количество сетевых запросов в одном пользовательском запросе.
• Использовать пулы соединений и keepalive, где возможно (БД, HTTP-клиенты).
• Подстроить таймауты PHP и внешних клиентов под реальные сетевые характеристики.

5. Мониторинг

• Снимать RTT и потери по ключевым направлениям в динамике (node_exporter, blackbox и т.п.).
• Коррелировать скачки latency с пиками ошибок и таймаутов PHP.
• Хранить историю MTU и сетевых изменений, чтобы быстро откатываться при странных симптомах.

Итоги

Latency и MTU — не абстрактные сетевые термины, а вполне прикладные параметры, которые напрямую влияют на то, как живут ваши PHP-проекты на VDS: от скорости деплоя rsync до стабильности HTTP и фоновых воркеров.

Пока вы не промеряете реальные задержки, не подберёте рабочий MTU и не научитесь смотреть на сеть не только через «сколько мегабит написано в тарифе», любые «рандомные» таймауты и подвисания будут восприниматься как мистика. На практике же большинство проблем воспроизводимо диагностируется через ping, mtr и пару аккуратных изменений в сетевой и прикладной конфигурации.

Как только вы один раз пройдёте путь от странных зависаний rsync до осознанного тюнинга MTU и таймаутов в PHP, следующий VDS-проект будете настраивать уже с поправкой на сеть — и заметите, насколько более предсказуемым и спокойным станет продакшен.