IETF (Internet Engineering Task Force), който се занимава с развитието на протоколи и архитектура на интернет, завърши формулирането на RFC за протокола QUIC и публикува свързани спецификации с идентификатори RFC 8999 (независими от версия свойства на протокола), RFC 9000 (транспорт върху UDP), RFC 9001 (TLS-криптиране на канала за комуникация QUIC) и RFC 9002 (управление на претоварване и определяне на загуба на пакети при предаване на данни).
RFC получиха статус „Предложен стандарт“, след което ще започне работа по придобиването на статус на черновен стандарт (Draft Standard), което фактически означава пълна стабилизация на протокола и отчитане на всички направени бележки. Протоколът HTTP/3, който определя използването на протокола QUIC като транспорт за HTTP/2, все още е на етап чернова спецификация, но скоро и той ще бъде окончателно стандартизиран в IETF.
Очаква се стандартизацията на QUIC да даде тласък за по-широко внедряване на този протокол, както и за развитието на базирани на него разширения, като WebTransport (технология за изпращане и получаване на данни между браузъра и сървър) и MASQUE (технология за проксиране на връзки, разширяваща възможностите на SOCKS и HTTP CONNECT, и използваща HTTPS върху QUIC като транспорт).
Напомняме, че протоколът QUIC (Quick UDP Internet Connections) от 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% намаление на операциите по повторно буфериране при гледане на видео.
Източник: opennet.ru
