Как браузер решает, какое соединение ему открывать, TCP или UDP?

Подумай, с какого уровня сетевой модели (OSI/TCP-IP) браузер, как клиентское приложение, начинает свою работу. Какие решения он принимает на уровне прикладных протоколов (HTTP, DNS, WebRTC) и как эти решения связаны с выбором транспортного уровня?

Краткий ответ: Браузер не выбирает между TCP и UDP произвольно. Решение о типе транспортного протокола принимается на уровне протокола прикладного уровня (HTTP, DNS, WebRTC и т.д.) и встроено в саму архитектуру веб-платформы. Браузер лишь следует этим предопределенным правилам.

Теперь давайте разберем подробно, как это происходит на каждом этапе.

1. Отправная точка: Протокол прикладного уровня

Всё начинается с URL или действия пользователя. В зависимости от схемы (scheme) и контекста браузер определяет, какой высокоуровневый протокол использовать.

http:// или https:// → Протокол HTTP/1.1, HTTP/2. Эти протоколы исторически и по умолчанию используют TCP как транспорт.

ws:// или wss:// → WebSocket. Также поверх TCP.

Запрос к DNS-серверу (чтобы преобразовать example.com в IP-адрес). Использует протокол DNS, который по умолчанию использует UDP на порту 53, с fallback на TCP при больших ответах.

webtransport:// или WebRTC-соединения → Эти современные API предназначены для работы поверх UDP (используя QUIC и SRTP/DTLS соответственно).

Ключевой вывод: Решение "зашито" в спецификацию самого протокола, который браузер собирается использовать.

2. Эволюция HTTP: От TCP к UDP (через QUIC)

Здесь происходит самое интересное изменение за последние годы.

• HTTP/1.1 и HTTP/2: Жестко привязаны к TCP. Причины:
  • Надежность: TCP гарантирует доставку всех пакетов по порядку (в отличие от UDP). Для веб-страниц, где важен каждый байт HTML, CSS, JS, это критически важно.
  • Управление потоком и перегрузкой: Встроенные в TCP механизмы предотвращают "завал" сети.
  • Недостатки TCP: "Блокировка начала очереди" (Head-of-Line blocking) на транспортном уровне. Если один пакет в потоке теряется, все последующие пакеты (даже из других HTTP-запросов в рамках одного соединения HTTP/2) ждут его повторной передачи.
• HTTP/3 (главный сдвиг парадигмы): Это протокол, работающий поверх QUIC (Quick UDP Internet Connections). QUIC — это транспортный протокол, работающий поверх UDP.
  • Почему UDP? QUIC берет лучшие черты TCP (надежность, управление потоком), но реализует их на уровне приложения внутри самого протокола QUIC, работающего поверх "сырого" UDP.
  • Преимущества: Решает проблему "блокировки начала очереди" на транспортном уровне, обеспечивает более быстрое установление соединения (0-RTT в некоторых случаях), встроенное шифрование (TLS 1.3 — часть QUIC).
  • Как браузер решает? Браузер и сервер используют механизм Alt-Svc (Alternative Services). При первом подключении по HTTPS (через TCP) сервер может в ответе прислать заголовок: Alt-Svc: h3=":443". Это говорит браузеру: "Для следующего соединения к этому хосту попробуй использовать HTTP/3 (h3) на порту 443 через UDP".
  • Браузеры (Chrome, Firefox, Edge) теперь по умолчанию пытаются использовать HTTP/3, если сервер его объявляет. Решение перейти на UDP/QUIC принимается автоматически на основе поддержки клиентом и сервером.

3. Конкретные механизмы выбора в браузере

1. Для HTTP(S):
   • Браузер смотрит на URL и свою внутреннюю таблицу поддержки протоколов (например: [http/1.1, http/2, http/3]).
   • Если это новый хост, он пытается установить соединение по TCP, начиная с самой современной поддерживаемой версии (часто HTTP/2).
   • Если получен заголовок Alt-Svc с указанием h3, браузер параллельно пытается установить QUIC-соединение по UDP на указанный порт. Успешное соединение по QUIC становится приоритетным для всех последующих запросов.
2. Для DNS:
   • Браузер (или ОС, по запросу браузера) отправляет DNS-запрос по UDP на порт 53.
   • Если ответ слишком большой и обрывается, DNS-клиент автоматически повторяет запрос, используя TCP.
   • Современные браузеры также могут использовать DNS-over-HTTPS (DoH) или DNS-over-QUIC (DoQ), которые используют TCP и UDP соответственно, но через зашифрованный туннель.
3. Для WebRTC (видеозвонки, P2P):
   • Когда вы используете getUserMedia и RTCPeerConnection, браузер явно выбирает UDP в качестве транспорта (через протоколы SRTP, DTLS).
   • Причина: Для реального времени задержка (latency) критичнее, чем надежность. Потеря одного видеокадра (пакета) предпочтительнее, чем ожидание его повторной отправки и задержка всего потока.
   • В случае проблем с NAT/firewall возможен fallback на TCP (через TURN-сервер), но это крайняя мера.

Итого:

С точки зрения браузера, выбор TCP/UDP — это не ситуативное решение, а следствие выбора протокола прикладного уровня, который диктуется:

1. Схемой URL и типом API.
2. Объявленной поддержкой сервером современных протоколов (через Alt-Svc).
3. Спецификой данных: Надежность и порядок (TCP/QUIC) vs. низкая задержка устойчивость к потерям (чистый UDP).

Тренд современного веба: Миграция от "голого" TCP к QUIC-over-UDP для основного контента (HTTP/3) и использование чистого UDP для интерактивных мультимедийных данных (WebRTC, WebTransport). Браузер инкапсулирует эту сложность, предоставляя разработчику простые API (fetch, WebSocket, RTCPeerConnection), абстрагирующие выбор транспорта.