Назад | Перейти на главную страницу

Как HTTP может работать через UDP (в случае протокола Google QUIC)?

Вот мое понимание того, как работает HTTP-сервер клиент-сервер.

  1. Клиент создает TCP сокетное соединение для подключения к серверу и отправки данных.
  2. Сервер создает TCP сокетное соединение для прослушивания входящих запросов.

Таким образом, похоже, что и клиент, и сервер должны согласиться на использование Transport protocol использовать (в данном случае TCP). Но если мы хотим, чтобы веб-сайт работал по протоколу UDP / QUIC, нам нужны и клиент, и сервер для создания UDP подключение к розетке. Но некоторые веб-сайты используют TCP, а другие - UDP ...

Значит ли это, что он должен выглядеть так?

if (URI == 'https://www.google.com') {
  // Website that works over UDP
  client.create.UDP.socket
  client.sendData

  server.create.UDP.socket
  server.receive.data
} else {
  // Website that works over TCP
  client.create.TCP.socket
  client.sendData

  server.create.TCP.socket
  server.receive.data
}

Итак, клиенту необходимо вести учет того, какой веб-сайт использует TCP, а какие веб-сайты используют UDP / QUIC, и создавать такой сокет для связи с ним?

HTTP - это кодировка для глаголов и ответов. Он может работать на любом транспорте, TCP, QUIC, SCTP. QUIC оптимизирован для HTTP / 2, но он действительно работает как универсальный транспорт.

Проблема в том, что URL-адреса https: // подразумевают TCP, из-за строгого чтения RFC 7230. Итак, заголовок Alt-Svc в начальном ответе TCP предлагает быстрое обновление до http 2 или 3. Замечания curl об альтернативных службах HTTP может быть полезно.

Таким образом, при запуске веб-сервера с помощью этого QUIC вам все равно нужно прослушивать TCP, чтобы пользовательские агенты могли обновиться. Если его не использовать, это не будет соответствовать стандартам и будет иметь проблемы с реализацией, согласно Обсуждение в рабочей группе QUIC.