IETF (Internet Engineering Task Force), който се занимава с развитието на интернет протоколите и архитектурата, завърши оформянето на RFC за протокола QUIC и публикува свързаните с него спецификации с идентификаторите RFC 8999 (независими от версията свойства на протокола), RFC 9000 (транспорт върху UDP), RFC 9001 (шифроване на QUIC канала чрез TLS) и 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) се развива от Google от 2013 година като алтернатива на 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
