Комитет 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).
QUICтин негизги өзгөчөлүктөрү:
- TLS сыяктуу жогорку коопсуздук (чынында, QUIC UDP үстүнөн TLS колдонуу мүмкүнчүлүгүн камсыз кылат);
- Пакеттин жоголушун алдын алуу үчүн агымдын бүтүндүгүн көзөмөлдөө;
- Байланышты заматта орнотуу мүмкүнчүлүгү (0-RTT, болжол менен 75% учурларда маалыматтар туташууну орнотуу пакетин жөнөткөндөн кийин дароо берилиши мүмкүн) жана суроо-талапты жөнөтүү менен жооп алуунун ортосундагы минималдуу кечигүүлөрдү камсыз кылуу (RTT, Round Trip Time);
- Пакетти кайра жөнөтүүдө башка катар номерин колдонуу, ал кабыл алынган пакеттерди идентификациялоодо түшүнүксүздүктү болтурбайт жана тайм-ауттардан арылтат;
- Пакеттин жоголушу аны менен байланышкан агымдын жеткирилишине гана таасирин тийгизет жана учурдагы байланыш боюнча параллелдүү берилүүчү агымдарда маалыматтардын жеткирилишин токтотпойт;
- Жоголгон пакеттердин кайра жөнөтүлүшүнөн улам кечигүүлөрдү азайтуучу каталарды оңдоо куралдары. Жоголгон пакет маалыматтарын кайра жөнөтүүнү талап кылган кырдаалдарды азайтуу үчүн пакеттик деңгээлде катаны оңдоонун атайын коддорун колдонуу.
- Криптографиялык блоктун чек аралары QUIC пакетинин чек аралары менен дал келет, бул пакеттик жоготуулардын кийинки пакеттердин мазмунун декоддоосуна таасирин азайтат;
- TCP кезегин бөгөттөөдө көйгөйлөр жок;
- Мобилдик кардарлар үчүн кайра туташуу убактысын кыскартуу үчүн Connection ID колдоосу;
- Туташуу ашыкча жүктөөнү көзөмөлдөө үчүн өркүндөтүлгөн механизмдерди туташтыруу мүмкүнчүлүгү;
- Пакеттерди жөнөтүүнүн оптималдуу интенсивдүүлүгүн камсыз кылуу үчүн ар бир багытта өткөрүү жөндөмдүүлүгүн болжолдоо ыкмаларын колдонуу, пакеттердин жоготуусу болгон тыгын абалына өтүүнүн алдын алуу;
- TCP менен салыштырганда аткаруу жана өткөрүү жөндөмдүүлүгүнүн олуттуу өсүшү. YouTube сыяктуу видео кызматтары үчүн QUIC видеолорду көргөндө ребуферлөө операцияларын 30% кыскартат.
Source: opennet.ru