TCP и UDP в VPN: чем отличаются и что выбрать

TCP и UDP — это два способа, которыми данные путешествуют по сети внутри VPN-туннеля. TCP гарантирует, что каждый пакет дойдёт и придёт в правильном порядке, но платит за это задержками. UDP отправляет пакеты и не ждёт подтверждения — быстрее, но без гарантий. Для VPN это значит разницу между более стабильным, но чуть более медленным соединением и более быстрым, но чувствительным к потерям пакетов.

Как работает TCP

TCP (Transmission Control Protocol) устроен как разговор с постоянной сверкой: отправитель шлёт пакет и ждёт подтверждения, что он дошёл. Если подтверждения нет, пакет отправляется заново. Порядок пакетов тоже контролируется — если один потерялся, остальные будут ждать, пока он не доедет.

Это делает TCP надёжным: данные точно придут и в правильном виде. Но у надёжности есть цена — каждое подтверждение и повтор добавляют время. На нестабильном канале, где пакеты периодически теряются, TCP может заметно тормозить, потому что вся передача упирается в ожидание одного застрявшего пакета.

Как работает UDP

UDP (User Datagram Protocol) проще: пакеты отправляются без подтверждений и без пересборки порядка. Если пакет потерялся — его никто не будет пересылать, приложение просто получит данные с пробелом. Зато накладных расходов почти нет, и задержка ниже.

Поэтому UDP исторически используют там, где важна скорость реакции, а не абсолютная точность: видеозвонки, стриминг, игры. Потеря одного кадра в видео почти не заметна, а вот задержка в полсекунды — заметна сразу.

При чём тут VPN

VPN шифрует и упаковывает трафик в один из двух транспортов. WireGuard изначально спроектирован под UDP — он минимизирует накладные расходы, потому что шифрование само по себе уже добавляет вычислительную нагрузку, и дублировать контроль доставки поверх него нет смысла.

Если завернуть уже TCP-трафик (например, обычный веб-сёрфинг) ещё и в TCP-туннель, получается ситуация, когда два уровня одновременно пытаются справляться с одними и теми же потерями пакетов — один ждёт подтверждения снаружи, другой внутри. Это может привести к эффекту, когда при малейшей потере пакетов скорость резко проседает, хотя каждый протокол по отдельности работает нормально.

У Reality, который использует DexterVPN, другая логика: этот протокол намеренно строится поверх TCP, потому что маскируется под обычное HTTPS-соединение, а TLS всегда идёт через TCP. Здесь транспорт — часть маскировки, а не свободный выбор ради скорости. Подробнее о том, как это устроено, можно почитать в статье про Reality, WireGuard и OpenVPN.

Что выбрать на практике

Если клиент вашего VPN даёт выбор транспорта, ориентируйтесь на задачу:

• Для игр и звонков обычно лучше UDP — ниже задержка, а потеря отдельных пакетов не так критична.
• На нестабильном мобильном интернете с частыми обрывами TCP иногда работает предсказуемее — он сам восстанавливает потерянные данные.
• Для протоколов, замаскированных под HTTPS вроде Reality, транспорт не выбирается отдельно — он часть механизма маскировки.

Важно понимать границы: выбор транспорта не добавляет скорости сверху того, что даёт канал. Если у оператора связь еле дышит, ни TCP, ни UDP это не исправят — они лишь по-разному реагируют на уже существующие потери и задержки.