Тюнинг сервера

Эта страница посвящена тюнингу на уровне операционной системы для сервера rVPN, особенно для высоколатентных или с потерями международных путей (например, клиенты в Китае, подключающиеся к серверу в США).

Симптомы, при которых поможет тюнинг

• Пинг через VPN сначала нормальный, но со временем растёт (например, 500 мс → 5–12 секунд).
• Пропускная способность падает до десятков кбит/с, хотя у сервера полно полосы.
• ss -ti показывает очень маленькое окно перегрузки (cwnd: 2), высокое число повторных передач и растущий bytes_retrans.
• Тот же клиент и сервер нормально работают в другой сети (например, 5G-мобильный интернет вместо проводного Wi-Fi).

Эти симптомы обычно означают, что TCP-соединение между клиентом и сервером идёт по каналу с потерями или сильным шейпингом. Стандартный контроллер перегрузки Linux, CUBIC, интерпретирует потерю пакетов как перегрузку сети и агрессивно уменьшает окно передачи, что приводит к взрывному росту задержек.

Переключитесь на BBR-контроль перегрузки

BBR (Bottleneck Bandwidth and RTT) моделирует канал вместо того, чтобы считать потери перегрузкой. На путях с высокими потерями и высоким RTT он сохраняет пропускную способность гораздо выше, а задержку — гораздо стабильнее, чем CUBIC.

Проверьте доступные алгоритмы

sysctl net.ipv4.tcp_available_congestion_control

Если bbr не в списке, загрузите модуль:

sudo modprobe tcp_bbr

Чтобы tcp_bbr загружался автоматически при загрузке, создайте /etc/modules-load.d/tcp_bbr.conf:

tcp_bbr

Примените BBR сейчас

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

Сохраните BBR между перезагрузками

Создайте /etc/sysctl.d/99-rvpn-tcp-tuning.conf:

# rVPN TCP tuning for high-latency / lossy international paths
net.ipv4.tcp_congestion_control=bbr
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 262144 16777216
net.ipv4.tcp_wmem=4096 262144 16777216
net.ipv4.tcp_notsent_lowat=16384

Примените:

sudo sysctl --system

Увеличение буферов даёт каждому TCP-соединению достаточно запаса для произведения пропускной способности и задержки при RTT 250–350 мс.

Убедитесь, что активное соединение использует BBR

После переподключения VPN-клиента (существующие соединения сохраняют свой старый контроллер перегрузки):

sudo ss -ti | grep -A5 'YOUR_CLIENT_IP'

Ищите:

bbr wscale:...

Если по-прежнему пишет cubic, значит клиент ещё не переподключился.

Тюнинг FreeBSD

FreeBSD тоже поддерживает BBR через модуль ядра cc_bbr, который является лучшим выбором для путей с высокими потерями и высоким RTT.

Загрузите BBR

Проверьте, загружен ли модуль:

kldstat | grep cc_bbr

Если не загружен:

sudo kldload cc_bbr

Чтобы загружать автоматически при загрузке, добавьте эту строку в /boot/loader.conf:

cc_bbr_load="YES"

Примените BBR и настройте буферы

sudo sysctl net.inet.tcp.cc.algorithm=bbr
sudo sysctl kern.ipc.maxsockbuf=16777216
sudo sysctl net.inet.tcp.recvspace=16777216
sudo sysctl net.inet.tcp.sendspace=16777216

Чтобы сохранить эти настройки между перезагрузками, создайте /etc/sysctl.conf:

# rVPN TCP tuning for high-latency / lossy international paths
net.inet.tcp.cc.algorithm=bbr
kern.ipc.maxsockbuf=16777216
net.inet.tcp.recvspace=16777216
net.inet.tcp.sendspace=16777216

Проверка на FreeBSD

Проверьте активный контроллер перегрузки:

sysctl net.inet.tcp.cc.algorithm

FreeBSD не показывает имена контроллеров перегрузки для каждого соединения так же удобно, как Linux через ss, поэтому проверяйте пропускную способность и задержку с помощью ping и iperf3 после переподключения клиента.

Что ещё проверить

• MTU интерфейса: Google Cloud VPC по умолчанию использует MTU 1460 байт. MTU TUN в rVPN — 1420, что комфортно помещается в MTU VPC с учётом накладных расходов TLS/WebSocket.
• CPU: rvpn-server однопоточен по крипто на каждое соединение, но асинхронный; VM с 1 vCPU обычно достаточно для одного-двух клиентов, но может стать узким местом при высокой пропускной способности.
• Диск / логирование: при уровне INFO по умолчанию сервер логирует каждый фрейм. На активном клиенте это может генерировать много I/O в journald. Рассмотрите снижение уровня логирования в проде.

Когда тюнинг не помогает

Если задержки и потери сохраняются после BBR и настройки буферов, проблема, вероятно, вне сервера:

• Проблемы ISP/маршрутизации на международном сегменте
• DPI или троттлинг у оператора, целящийся в TLS на порт 443
• Локальный Wi-Fi-роутер с агрессивным QoS или маленькими буферами

В таких случаях попробуйте другую клиентскую сеть (мобильную точку доступа, другого ISP) или другую локацию сервера ближе к клиенту.