Mae protocol QUIC wedi derbyn statws safon arfaethedig.

Комитет 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 (технология для отправки и приёма данных между браузером и сервером) и 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).

Nodweddion allweddol QUIC:

• Diogelwch uchel tebyg i TLS (yn y bôn mae QUIC yn darparu'r gallu i ddefnyddio TLS dros CDU);
• Rheoli uniondeb llif, atal colli pecyn;
• Y gallu i sefydlu cysylltiad ar unwaith (0-RTT, mewn tua 75% o achosion gellir trosglwyddo data yn syth ar ôl anfon y pecyn sefydlu cysylltiad) a darparu ychydig o oedi rhwng anfon cais a derbyn ymateb (RTT, Round Trip Time);
• Defnyddio rhif dilyniant gwahanol wrth ail-ddarlledu pecyn, sy'n osgoi amwysedd wrth nodi pecynnau a dderbyniwyd ac sy'n cael gwared ar oramserau;
• Mae colli pecyn yn effeithio ar gyflenwi'r ffrwd sy'n gysylltiedig ag ef yn unig ac nid yw'n atal trosglwyddo data mewn ffrydiau cyfochrog a drosglwyddir trwy'r cysylltiad presennol;
• Nodweddion cywiro gwallau sy'n lleihau oedi oherwydd ail-drosglwyddo pecynnau coll. Defnyddio codau cywiro gwall arbennig ar lefel pecyn i leihau sefyllfaoedd lle mae angen ail-drosglwyddo data pecynnau coll.
• Mae ffiniau blociau cryptograffig yn cyd-fynd â ffiniau pecynnau QUIC, sy'n lleihau effaith colledion pecynnau ar ddadgodio cynnwys pecynnau dilynol;
• Dim problemau gyda blocio ciw TCP;
• Cefnogaeth ar gyfer dynodwr cysylltiad, sy'n lleihau'r amser y mae'n ei gymryd i sefydlu ailgysylltu ar gyfer cleientiaid symudol;
• Posibilrwydd cysylltu mecanweithiau rheoli tagfeydd cysylltiad uwch;
• Yn defnyddio technegau rhagweld trwybwn fesul cyfeiriad i sicrhau bod pecynnau'n cael eu hanfon ar y cyfraddau gorau posibl, gan eu hatal rhag mynd yn llawn tagfeydd ac achosi colli pecynnau;
• Cynnydd sylweddol mewn perfformiad a thrwybwn o gymharu â TCP. Ar gyfer gwasanaethau fideo fel YouTube, dangoswyd bod QUIC yn lleihau gweithrediadau ail-glustogi wrth wylio fideos 30%.

Ffynhonnell: opennet.ru