Комитет 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, राऊंड ट्रिप वेळ) प्राप्त करण्यात किमान विलंब प्रदान करणे;
- पॅकेट पुन्हा प्रसारित करताना भिन्न अनुक्रम क्रमांक वापरणे, जे प्राप्त पॅकेट ओळखण्यात अस्पष्टता टाळते आणि कालबाह्यतेपासून मुक्त होते;
- पॅकेटचे नुकसान केवळ त्याच्याशी संबंधित प्रवाहाच्या वितरणावर परिणाम करते आणि वर्तमान कनेक्शनद्वारे प्रसारित केलेल्या समांतर प्रवाहांमध्ये डेटाचे वितरण थांबवत नाही;
- त्रुटी सुधारण्याची वैशिष्ट्ये जी गमावलेल्या पॅकेटच्या पुनर्प्रसारणामुळे होणारा विलंब कमी करतात. हरवलेल्या पॅकेट डेटाचे पुनर्प्रसारण आवश्यक असलेल्या परिस्थिती कमी करण्यासाठी पॅकेट स्तरावर विशेष त्रुटी सुधारणा कोडचा वापर.
- क्रिप्टोग्राफिक ब्लॉक सीमा QUIC पॅकेट सीमांसह संरेखित केल्या आहेत, जे त्यानंतरच्या पॅकेटच्या सामग्रीच्या डीकोडिंगवर पॅकेट नुकसानाचा प्रभाव कमी करते;
- TCP रांग अवरोधित करण्यात कोणतीही समस्या नाही;
- कनेक्शन आयडेंटिफायरसाठी समर्थन, जे मोबाइल क्लायंटसाठी पुन्हा कनेक्शन स्थापित करण्यासाठी लागणारा वेळ कमी करते;
- प्रगत कनेक्शन कंजेशन कंट्रोल यंत्रणा कनेक्ट करण्याची शक्यता;
- पॅकेट इष्टतम दरांवर पाठवले जातील याची खात्री करण्यासाठी प्रति-दिशा थ्रूपुट अंदाज तंत्र वापरते, त्यांना गर्दी होण्यापासून आणि पॅकेटचे नुकसान होण्यापासून प्रतिबंधित करते;
- TCP च्या तुलनेत कार्यप्रदर्शन आणि थ्रूपुटमध्ये लक्षणीय वाढ. YouTube सारख्या व्हिडिओ सेवांसाठी, QUIC ने व्हिडिओ पाहताना रिबफरिंग ऑपरेशन्स 30% ने कमी केल्याचे दर्शविले आहे.
स्त्रोत: opennet.ru