TCP или UDP — в чём разница, и почему твой сайт, скорее всего, уже ходит по UDP

Смотри, какая неожиданность. Все учебники говорят: «веб работает по TCP, а UDP — для игр». А потом ты открываешь вкладку Network в Chrome, включаешь колонку Protocol — и видишь h3.

Это HTTP/3. И он работает поверх UDP. Многие крупные сайты уже отдают страницы именно так. Значит, разница между TCP и UDP устроена хитрее, чем «надёжный против быстрого». Разберёмся.

Что делают TCP и UDP

Оба протокола решают одну задачу: доставить кусочки данных (пакеты) с одного компьютера на другой. Адрес — это IP и порт. Разница в том, как они доставляют.

TCP — заказное письмо с уведомлением. Сначала стороны «здороваются» и договариваются. Каждый пакет нумеруется. Получатель подтверждает доставку. Потерялся пакет — его шлют снова. На выходе данные всегда целые и строго по порядку.

UDP — открытки в почтовый ящик. Отправил и забыл. Никакого рукопожатия, подтверждений и повторов. Открытка может потеряться, прийти раньше предыдущей или вообще не прийти. Зато никто никого не ждёт.

Сравнение по пяти критериям

Таблицу заменим списком — так её удобнее читать с телефона.

• Надёжность. TCP гарантирует, что дойдёт всё. UDP — нет: потерянное пропало, если программа сама не перешлёт.
• Порядок. TCP выдаёт данные строго по порядку. UDP — как пришли.
• Задержка. Тут главный подвох TCP. Если потерялся один пакет, все следующие ждут, пока его перешлют, — даже если они уже пришли. Это называется блокировка начала очереди. В UDP такого нет: следующий пакет обрабатывается сразу.
• Где встретишь. TCP: обычные сайты на HTTP/1.1 и HTTP/2, WebSocket, почта, SSH, базы данных. UDP: видеозвонки, онлайн-игры, стриминг в реальном времени, DNS и тот самый HTTP/3.
• Доступ из браузера. Сырой UDP из JavaScript открыть нельзя. TCP напрямую тоже нельзя — только через HTTP и WebSocket. UDP-подобная доставка в браузере есть через WebRTC.

Почему звонкам и играм важна именно потеря

Представь видеозвонок. Потерялся пакет со звуком длиной 20 миллисекунд. Что лучше?

• По TCP: всё замирает, пока пакет перешлют. Собеседник «залипает», потом догоняет скороговоркой.
• По UDP: ты не услышишь крошечный кусочек. Скорее всего, даже не заметишь.

Старые данные в реальном времени бесполезны. Позиция игрока полсекунды назад уже никому не нужна — нужна свежая. Поэтому игры и звонки охотно жертвуют надёжностью ради низкой задержки.

Как HTTP/3 оказался на UDP

Вот тут красиво. Странице нужна надёжность: потерянный кусок картинки надо дослать. Почему же HTTP/3 выбрал UDP?

Из-за той самой блокировки очереди. В HTTP/2 картинки, стили и скрипты едут по одному TCP-соединению. Потерялся пакет картинки — встают все файлы. На плохом мобильном интернете это заметно.

Поэтому HTTP/3 построили на протоколе QUIC. QUIC берёт «голый» UDP и сам заново собирает над ним надёжность: нумерацию, подтверждения, повторы. Но отдельно для каждого файла. Потерялся пакет картинки — ждёт только картинка, стили грузятся дальше. А шифрование встроено сразу, как в HTTPS.

Есть и бонус для телефонов. TCP-соединение привязано к адресу: ушёл с Wi-Fi на мобильную сеть — соединение рвётся и собирается заново. QUIC узнаёт соединение по своему номеру, а не по адресу, поэтому загрузка переживает смену сети.

Итог парадоксальный: UDP — не «ненадёжный протокол», а чистый лист. На нём строят ровно ту надёжность, которая нужна задаче.

Кому что подойдёт

• Делаешь сайт, API, чат, админку — бери то, что дают HTTP и WebSocket. Это TCP или QUIC под капотом, и думать о пакетах тебе не нужно. Сервер и браузер договорятся о HTTP/3 сами.
• Делаешь видеозвонок или голосовой чат в браузере — бери WebRTC. Он сам работает поверх UDP и умеет терять старое ради свежего.
• Делаешь браузерную мультиплеер-игру, где важна каждая миллисекунда, — смотри на WebRTC data channel с настройками ordered: false и maxRetransmits: 0. Это почти UDP. Для пошаговой игры хватит обычного WebSocket.
• Не пиши свой протокол поверх UDP для обычного приложения. Надёжность, которую ты будешь собирать руками, уже есть в TCP и QUIC.

UDP быстрее TCP?

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

Как узнать, работает ли мой сайт по HTTP/3?

Открой DevTools → Network, нажми правой кнопкой на заголовок таблицы и включи колонку Protocol. h3 — это HTTP/3 поверх UDP, h2 — HTTP/2 поверх TCP. Обычно HTTP/3 включается на стороне хостинга или CDN.