Протокол QUIC получил статус предложенного стандарта
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола QUIC и опубликовал связанные с ним спецификации под идентификаторами RFC 8999 (независящие от версии свойства протокола), RFC 9000 (транспорт поверх UDP), RFC 9001 (TLS-шифрование канала связи QUIC) и RFC 9002(управление перегрузкой и определение потери пакетов при передаче данных).
RFC получили статус «Предложенного стандарта», после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Протокол HTTP/3, который определяет использование протокола QUIC в качестве транспорта для HTTP/2, пока находится на стадии черновой спецификации, но в ближайшее время и он будет окончательно стандартизирован в IETF.
Напомним, что протокол QUIC (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. В процессе разработки в IETF стандарта в протокол были внесены изменения, что привело к возникновению двух параллельно существующих веток, одна для HTTP/3, а вторая поддерживаемая Google (Chrome поддерживает оба варианта, а Firefox вариант IETF).
Основные особенности QUIC:
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
Контроль за целостностью потока, предотвращающий потерю пакетов;
Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаев данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
- Использование при повторной передаче пакета другого номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
Отсутствие проблем с блокировкой очереди TCP;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
- Возможность подключения расширенных механизмов контроля перегрузки соединения;
Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
Заметный прирост производительности и пропускной способности по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
Источник: http://www.opennet.ru/opennews/art.shtml? num=55226
© OpenNet
