TCP vs UDP: как выбрать транспортный протокол для DevOps и системных администраторов в 2026 году

Выбирайте TCP, когда потеря, дублирование или нарушение порядка данных недопустимы: для HTTP/HTTPS, SSH, баз данных, файловых операций, очередей и большинства gRPC-сервисов. Гарантированная доставка TCP строится на установке соединения, нумерации байтов, подтверждениях, повторной передаче и контроле перегрузки.

Выбирайте UDP, когда приоритетом выступают минимальная задержка и независимость сообщений: для RTP в VoIP, игровых пакетов, DNS-запросов, statsd и части потокового видео. UDP не подтверждает доставку и не восстанавливает потерянные датаграммы. Если приложению нужна надежность поверх UDP, оно обязано само добавить нумерацию, тайм-ауты, повторные передачи, ограничение скорости или FEC.

Основные возможности панели

На примере Pterodactyl удобно разделить управляющий и пользовательский трафик. Panel обслуживает веб-интерфейс и API через HTTPS поверх TCP. Wings управляет контейнерами на нодах. Игровые процессы в контейнерах получают выделенные порты и используют TCP, UDP либо оба протокола по правилам конкретной игры. Panel не проксирует игровой поток между клиентом и контейнером.

Фраза «быстрый протокол UDP» требует уточнения. У UDP меньше служебных действий в ядре ОС: нет трехэтапного рукопожатия, очереди неподтвержденных байтов и обязательной повторной передачи. Это сокращает задержку отправки, но не делает полезную нагрузку автоматически быстрее при перегруженном канале. При потере пакетов приложение на UDP получает неполные данные, а неконтролируемая отправка способна перегрузить сеть.

Когда использовать TCP, когда UDP

Что TCP дает приложению

• Трехэтапное рукопожатие SYN, SYN-ACK, ACK перед передачей полезных данных.
• Упорядоченный поток байтов: получатель не увидит последующие байты, пока не будут восстановлены пропущенные.
• Подтверждения и повторную передачу при потере сегмента.
• Контроль потока, чтобы быстрый отправитель не переполнил буфер получателя.
• Контроль перегрузки, который снижает скорость отправки при признаках потерь и задержек в сети.

TCP подтверждает прием данных стеком удаленного хоста. Это не подтверждение обработки бизнес-операции. Например, запись в сокет базы данных может быть подтверждена TCP, но транзакция еще не зафиксирована. Для денежных операций, задач очереди и изменений состояния нужны прикладные идентификаторы, идемпотентность и подтверждение результата.

Ограничения UDP

• Датаграмма может потеряться, прийти дважды или поменяться местами с другой.
• UDP сохраняет границы сообщений, в отличие от TCP-потока байтов.
• Большая UDP-датаграмма может фрагментироваться на IP-уровне. При неизвестном MTU безопаснее держать полезную нагрузку около 1200 байт или меньше.
• Отправитель обязан ограничивать скорость. Отсутствие встроенного контроля перегрузки не дает права безлимитно посылать пакеты.

QUIC использует UDP как носитель, но добавляет шифрование, контроль перегрузки, восстановление потерь и надежные потоки. Поэтому выбор «UDP» для HTTP/3 не означает отказ от надежности. Он означает, что эти механизмы работают в реализации QUIC, а не в TCP ядра.

Для веб-сервисов HTTP/1.1 и HTTP/2 привычный транспорт - TCP. gRPC использует транспортный протокол HTTP/2 поверх TCP в типовой серверной схеме. Prometheus забирает метрики HTTP-запросами по TCP, а statsd чаще принимает UDP-датаграммы и допускает потери счетчиков при перегрузке. Потоковое видео UDP и RTP для VoIP подходят там, где поздний пакет хуже пропущенного: воспроизведение уже ушло вперед.

Panel и Wings

Pterodactyl состоит из Panel, веб-приложения для управления серверами, и Wings, агента на ноде с Docker. Разделение компонентов помогает заранее составить карту портов и не открыть наружу служебные сервисы.

Например, веб-интерфейс Minecraft часто принимает TCP-соединения, а игровые обновления в шутерах обычно идут по UDP. Для одного игрового продукта могут потребоваться оба транспорта на соседних портах. Перед публикацией allocation-портов проверьте документацию игры, Docker port publishing и правила фаервола. Сравнение панелей, моделей хостинга и требований игровых серверов есть в разборе инфраструктуры игровых серверов и панелей управления.

Установка Pterodactyl: подготовка сервера

Разделите Panel и Wings на разные хосты, если игровая нагрузка заметна или нода находится в другой сети. Panel хранит учетные записи, задания и конфигурацию. Wings запускает контейнеры, держит Docker-сеть и принимает пользовательский трафик. Такое деление сужает область доступа: компрометация игрового контейнера не должна открывать базу данных Panel.

Перед установкой зафиксируйте IP-адреса, FQDN, DNS-записи, порт Wings, SFTP-порт и диапазоны allocation-портов. Проверьте текущие слушающие сокеты и правила фильтрации:

ss -lntup
nft list ruleset
ip -br address
ip route

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

Минимальная схема правил фаервола

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow from <IP-Panel> to any port 8080 proto tcp
ufw allow 2022/tcp
ufw allow 27015:27025/udp
ufw allow 27015:27025/tcp

Порты 3306 и 6379 не публикуйте в интернет. Если Panel и база данных расположены на одном хосте, привяжите MariaDB и Redis к loopback-интерфейсу. При разнесении компонентов в закрытую сеть разрешайте TCP 3306 и TCP 6379 только между конкретными адресами. Облачный security group и фаервол ОС должны содержать одинаковую логику, иначе диагностика превратится в поиск правила в двух местах.

Базовые команды Linux, диагностика сети и безопасная работа с systemd собраны в руководстве по системному администрированию Linux.

Установка зависимостей

Panel нужны веб-сервер, PHP-FPM с расширениями, Composer, MariaDB или MySQL и Redis. Набор версий зависит от релиза Pterodactyl, поэтому сначала сверяйте требования релиза, а затем ставьте подходящие пакеты. Для Debian и Ubuntu базовый набор выглядит так:

apt-get update
apt-get install -y curl ca-certificates unzip tar nginx mariadb-server redis-server \
php-fpm php-cli php-mysql php-gd php-mbstring php-xml php-bcmath php-curl php-zip composer

После установки проверьте фактическую среду. Ошибка в одном PHP-расширении проявится при миграции или обработке задания, а не при открытии стартовой страницы.

php -v
php -m
systemctl is-active nginx mariadb redis-server
ss -lntp

MariaDB и Redis обмениваются с Panel по TCP даже на одном сервере, если в конфигурации указан адрес 127.0.0.1. Значение localhost у некоторых драйверов включает Unix socket. Оба варианта пригодны локально, но явный 127.0.0.1 упрощает проверку TCP-подключения и делает поведение одинаковым после разнесения компонентов.

Создание базы данных

Создайте отдельную базу и учетную запись Panel. Учетная запись не должна иметь глобальные привилегии и удаленный вход с произвольного адреса. Пример для MariaDB:

mariadb
CREATE DATABASE panel CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'panel'@'127.0.0.1' IDENTIFIED BY '<сложный-пароль>';
GRANT ALL PRIVILEGES ON panel.* TO 'panel'@'127.0.0.1';
FLUSH PRIVILEGES;

Проверьте подключение тем же способом, которым его будет открывать приложение:

mariadb -h 127.0.0.1 -u panel -p panel

Если база вынесена на отдельный сервер, используйте закрытую подсеть, TLS для соединения с MariaDB и правило фаервола, разрешающее TCP 3306 только IP Panel. Не подменяйте эту схему открытым портом базы в публичной сети. Потеря TCP-соединения с БД должна отражаться в логах приложения и алертах, а не маскироваться бесконечными ретраями.

Загрузка и настройка панели

Загрузите архив Panel из проверенного канала проекта, сверьте контрольную сумму релиза и распакуйте его в отдельный каталог. Не запускайте миграции на рабочей базе без резервной копии: команда меняет структуру таблиц.

install -d -o www-data -g www-data /var/www/pterodactyl
tar -xzf panel-release.tar.gz -C /var/www/pterodactyl
cd /var/www/pterodactyl
cp .env.example .env
composer install --no-dev --no-interaction --prefer-dist
php artisan key:generate --force
php artisan migrate --seed --force
php artisan p:user:make
chown -R www-data:www-data storage bootstrap/cache

В файле .env задайте адрес панели, подключение к БД и очередь Redis. Секреты храните вне репозитория и не вставляйте в тикеты, логи или shell history.

APP_ENV=production
APP_DEBUG=false
APP_URL=https://panel.example.net
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=panel
DB_USERNAME=panel
DB_PASSWORD=<сложный-пароль>
CACHE_STORE=redis
QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

HTTPS-панель использует TCP 443. Переключение игрового сервера на UDP никак не меняет транспорт веб-интерфейса Panel. Это разные потоки с разными требованиями: в административной части потеря ответа недопустима, а игровой пакет может устареть быстрее, чем успеет прийти повторно.

Планировщик и обработчик очередей

Планировщик запускает периодические задачи, а worker забирает длительные задания из Redis: отправку почты, операции с серверами и обновление состояния. Остановка worker не ломает TCP-порт Panel, но отложенные действия перестают выполняться. Проверьте работу обоих компонентов до подключения нод.

* * * * * www-data php /var/www/pterodactyl/artisan schedule:run >> /dev/null 2>&1

Создайте systemd unit для очереди:

[Unit]
Description=Pterodactyl queue worker
After=network.target redis-server.service

[Service]
User=www-data
Group=www-data
Restart=always
RestartSec=5
ExecStart=/usr/bin/php /var/www/pterodactyl/artisan queue:work redis --sleep=3 --tries=3 --timeout=120

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now pteroq.service
systemctl status pteroq.service
journalctl -u pteroq.service -n 100 --no-pager

Redis по TCP не превращает обработку задания в exactly-once. После тайм-аута или сбоя worker задача способна запуститься повторно. Для команд, меняющих состояние внешнего сервиса, используйте уникальный идентификатор операции и безопасную повторную обработку.

Настройка NGINX и SSL

NGINX принимает TLS на TCP 443 и передает PHP-запросы в PHP-FPM через Unix socket или локальный TCP-сокет. Оставляйте HTTP на TCP 80 только для перенаправления на HTTPS и получения сертификата. Если прокси включает HTTP/3, потребуется отдельное правило UDP 443. Не открывайте UDP 443 без фактической поддержки QUIC и теста клиентских сценариев.

server {
    listen 80;
    server_name panel.example.net;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name panel.example.net;
    root /var/www/pterodactyl/public;
    index index.php;
    client_max_body_size 100m;

    ssl_certificate /etc/ssl/panel/fullchain.pem;
    ssl_certificate_key /etc/ssl/panel/privkey.pem;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTP_PROXY "";
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    location ~ /\. {
        deny all;
    }
}

nginx -t
systemctl reload nginx
ss -lntp

Проверьте сертификат, цепочку доверия, редирект с 80 на 443, лимит загрузки и отсутствие доступа к служебным файлам. Практика ограничения административных портов, HTTPS и проверки правил через сетевой анализатор разобрана в руководстве по защите веб-интерфейсов серверов.

Установка Wings

Wings запускается на каждой игровой ноде и требует Docker. Скачайте бинарный файл Wings из проверенного канала, проверьте контрольную сумму, поместите файл в /usr/local/bin/wings и скопируйте конфигурацию, созданную Panel, в /etc/pterodactyl/config.yml. В конфигурации сверяйте FQDN, TLS, API-порт, SFTP-порт, адреса allocation и лимиты ресурсов.

install -d /etc/pterodactyl
install -m 0755 wings /usr/local/bin/wings
/usr/local/bin/wings --config /etc/pterodactyl/config.yml

Первый запуск в foreground нужен для чтения ошибок конфигурации. После успешной проверки создайте сервис:

[Unit]
Description=Pterodactyl Wings
After=docker.service
Requires=docker.service

[Service]
User=root
WorkingDirectory=/etc/pterodactyl
LimitNOFILE=4096
ExecStart=/usr/local/bin/wings
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now wings
systemctl status wings
journalctl -u wings -n 100 --no-pager

Wings получает управляющие команды по защищенному TCP-соединению. Пользовательский UDP-трафик должен пройти фаервол хоста, облачную сеть, Docker port publishing и правила самой игры. Проверьте опубликованные порты контейнеров:

docker ps
ss -lntup
tcpdump -ni any 'udp portrange 27015-27025'

Потери UDP оценивайте по счетчикам приложения, пакетам в capture и метрикам интерфейса. Команда nc -u не подтверждает доступность UDP-сервиса: у UDP нет рукопожатия, поэтому успешное завершение команды не доказывает, что удаленный процесс принял датаграмму.

Создание ноды в панели

При создании ноды укажите FQDN Wings, схему HTTPS, API-порт, SFTP-порт, объем памяти и диска, а затем добавьте allocation-порты. Включайте в диапазон только порты, которые нужны яйцам и игровым серверам. Широкий диапазон UDP без причины увеличивает поверхность атаки и усложняет поиск аномального трафика.

После привязки ноды проведите проверку по цепочке: Panel создает сервер, Wings получает команду, Docker стартует контейнер, TCP или UDP порт публикуется, клиент игры получает ответ. Отдельно протестируйте сценарии с потерей пакетов и задержкой в тестовой сети. Нагрузка с потерей 1% быстро показывает разницу между TCP, который восстанавливает данные ценой задержки, и UDP, который пропускает часть обновлений.

tc qdisc add dev eth0 root netem delay 30ms 10ms loss 1%
ss -ti
tcpdump -ni eth0 'tcp port 443 or udp portrange 27015-27025'
tc qdisc del dev eth0 root

Команды с tc netem выполняйте только в согласованном тестовом окне. На рабочей ноде они затронут весь трафик интерфейса.

Контрольный список перед публикацией сервисов

1. Для HTTP/HTTPS, SSH, API, БД, очередей и типового gRPC используйте TCP.
2. Для DNS разрешите UDP 53 и TCP 53 там, где сервер отвечает на большие сообщения, обслуживает zone transfer или принимает fallback-клиентов.
3. Для SIP разделите сигнализацию и медиапоток: SIP может работать по UDP, TCP или TLS, RTP обычно требует UDP и согласованного диапазона портов.
4. Для statsd определите допустимую потерю метрик. Если она недопустима, используйте TCP-режим агента либо локальный буфер с подтвержденной доставкой.
5. Для каждого UDP-сервиса измеряйте packets per second, drop, jitter и загрузку канала. Для TCP следите за retransmits, RTT, очередями сокета и числом соединений.
6. Не публикуйте наружу Redis, MariaDB и Wings API без ограничения по источнику. Откройте только нужные TCP- и UDP-порты.

UDP-сервисы часто становятся целью flood и amplification-атак, особенно при ошибочно открытых DNS-серверах. Алерты по всплеску UDP packets per second, объему входящего трафика и росту drop помогут заметить проблему до отказа игрового сервера. Схемы мониторинга, алертинга и автоматической блокировки описаны в практическом руководстве по защите от DDoS и мониторингу трафика.