Дэниел Cтенберг (Daniel Stenberg), автор утилиты cURL, входящий в рабочие группы IETF, развивающие протоколы HTTP и QUIC,
сообщил (https://daniel.haxx.se/blog/2018/11/11/http-3/) об утверждении решения по продвижению протокола HTTP-over-QUIC в качестве будущего стандарта HTTP/3. Выбор имени для HTTP-over-QUIC вызвал большую дискуссию. Вначале рассматривалась возможность использования для стандартизации связки HTTP-over-QUIC имён HQ, QUIC/2, HTTP/QUIC и HTTP/2-encrypted-over-UDP, но в конце концов разработчики согласились с предложением (https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...) использовать имя HTTP/3, которое позволит сохранить привычную семантику.
Стандартизация QUIC в IETF разделена на два уровня: определение транспортного протокола QUIC и надстройки для обеспечения работы HTTP поверх QUIC. Связанные с HTTP части отныне будут рассматриваться как HTTP/3. Для транспортного протокола ситуация пока не однозначна, так как развиваемый в IETF протокол и вариант протокола от Google отличаются в некоторых деталях, неформально версию от IETF в сообществе именуют iQUIC, а вариант Google - gQUIC. После завершения стандартизации и синхронизации реализации компанией Google ожидается оставление за протоколом имени QUIC.
Напомним, что протокол QUIC (https://www.chromium.org/quic/) (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. Рассматриваемый протокол уже интегрирован в серверную инфраструктуру Google, входит в состав Chrome, запланирован (https://www.opennet.ru/opennews/art.shtml?num=48312) для включения в Firefox и активно применяется для обслуживания запросов клиентов на серверах Google.
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...) QUIC:
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
- Контроль за целостностью потока, предотвращающий потерю пакетов;
- Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
- Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
- Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
- Отсутствие проблем с блокировкой очереди TCP;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
- Возможность подключения расширенных механизмов контроля перегрузки соединения;
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
- Заметный прирост (http://web.cs.wpi.edu/~claypool/ms/quic/quic-thesis.pdf) производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
URL: https://daniel.haxx.se/blog/2018/11/11/http-3/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49594
