Комитет 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 даст толчок для более широкого внедрения данного протокола, а также для развития основанных на нём расширений, таких как WebTransport (технология для отправки и приёма данных между браузером и serverilt) и MASQUE (технология проксирования соединений, расширяющая возможности SOCKS и HTTP CONNECT, и использующая HTTPS поверх QUIC в качестве транспорта).
Напомним, что протокол QUIC (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. В процессе разработки в IETF стандарта в протокол были внесены изменения, что привело к возникновению двух параллельно существующих веток, одна для HTTP/3, а вторая поддерживаемая Google (Chrome поддерживает оба варианта, а Firefox вариант IETF).
QUICi põhijooned:
- Kõrge turvalisus, võrreldav TLS'iga (QUIC pakub tegelikult võimalust kasutada TLS'i UDP peal);
- Voolu terviklikkuse jälgimine, mis takistab pakettide kaotust;
- Võimalus luua ühendus koheselt (0-RTT, umbes 75% juhtudel saab andmeid edastada kohe pärast ühenduse loomise paketi saatmist) ja tagada minimaalne viivitus päringu saatmise ja vastuse saamise vahel (RTT, Round Trip Time);
- Paketi uuesti edastamisel kasutatakse teistsugust järjestuse numbrit, mis võimaldab vältida mitmeti mõistetavust saadud pakettide määratlemisel ja kõrvaldada aegumise probleemid;
- Paketi kaotus mõjutab ainult selle kaasnevat voolu ja ei peata andmete edastamist samaaegselt praeguse ühenduse kaudu edastatavatest voogudest;
- Vigade parandusmeetmed, mis minimeerivad viivitusi kadunud pakettide uuesti edastamise tõttu. Eriliste vigade parandamise koodide kasutamine paketi tasemel, et vähendada olukordi, mis nõuavad kadunud paketi andmete uuesti edastamist.
- Krüptograafiliste plokkide piirid on joondatud QUIC pakettide piiridega, mis vähendab pakettide kaotuse mõju järgmiste pakettide sisu dekodeerimisele;
- TCP järjekorra ummistumise probleemide puudumine;
- Ühenduse identifikaatori tugi, mis võimaldab vähendada mobiilsete klientide uuesti ühendamise aega;
- Võime ühendada laienevaid ühenduse ülekande kontrolli mehhanisme;
- Igas suunas läbilaskevõime ennustamise tehnika kasutamine, et tagada pakkide edastamise optimaalne intensiivsus, vältides üleminekuid koormuse seisundisse, kus esineb pakettide kaotust;
- Tähtis jõudluse ja ribalaiuse kasv võrreldes TCP-ga. Video teenustes, nagu YouTube, on QUIC-i kasutamine vähendanud videote vaatamisel vahemälu operatsioone 30%.
Allikas: opennet.ru
