QUIC (Quick UDP Internet Connections) е протокол върху UDP, който поддържа всички функции на TCP, TLS и HTTP/2 и решава повечето от техните проблеми. Често се нарича нов или „експериментален“ протокол, но отдавна е надживял експерименталния етап: разработката продължава повече от 7 години. През това време протоколът не успя да се превърне в стандарт, но все пак стана широко разпространен. Например QUIC се използва от такива гиганти като Google и Facebook за ускоряване на трафика и намаляване на закъсненията в мобилните мрежи, а IETF обяви своето разклонение на протокола за основата на стандарта HTTP/3 (въпреки че HTTP/2 използва сайтове).
Понятие
QUIC е разработен като заместител на наследения TCP, който първоначално е проектиран за кабелни мрежи с ниски загуби. TCP доставя пакети в ред, така че ако един пакет бъде загубен, цялата опашка се спира (), което се отразява негативно на качеството и стабилността на връзката. За да избегнат големи загуби, клетъчните мрежи прибягват до използването на големи буфери, което от своя страна води до излишък и фалшив отрицателен отговор на протокола (). Освен това TCP прекарва много време за установяване на връзка: SYN/ACK и TLS заявките се обработват отделно, което изисква три двупосочни посещения вместо едно, както прави QUIC.
Тъй като QUIC съчетава замяна на TCP и внедряване на TLS 1.3, всички връзки винаги са криптирани и дешифрирането на такъв трафик не е по-лесно, отколкото ако преминава през HTTPS. В допълнение, QUIC се внедрява на ниво приложение, тъй като пълната подмяна на TCP стека би отнела вечност.
Въпреки поддръжката за мултиплексиране в HTTP/2, проблемът с блокирането на начален ред остава там поради необходимостта да се доставят пакети в ред. QUIC е внедрен върху UDP, така че по принцип няма блокиране и за да се предотврати загубата на пакети завинаги, те са номерирани и могат да съдържат части от „съседи“, осигурявайки излишък. Освен това QUIC разделя монолитната опашка на множество нишки за различни типове заявки в рамките на една връзка. По този начин, ако пакетът е загубен, проблеми могат да възникнат само за една опашка (например за прехвърляне на конкретен файл):
Употреба
Първоначално QUIC е разработен в Google и до голяма степен е пригоден за използване в компанията. През 2013 г. той беше прехвърлен към IETF за стандартизация (която все още продължава) и сега всеки може да участва в разработването на протокола, като предложи това, което му липсва. Работната група на IETF организира годишни срещи, по време на които се одобрява нов стандарт и се обсъждат иновациите. Тази реализация на QUIC се счита за основна и на нейна база е сертифициран стандартът HTTP/3.
Засега не се говори за включване на HTTP/3 като основен протокол, защото все още не е завършен и почти не се поддържа:
Но QUIC може да бъде внедрен като транспорт между приложението и сървъра, което беше успешно направено в Uber:
Коментар на Uber относно въвеждането на QUIC
За да вградим успешно QUIC и да подобрим производителността на приложенията в среди с лоша свързаност, заменихме стария стек (HTTP/2 през TLS/TCP) с протокола QUIC. Използвахме мрежовата библиотека на , който съдържа оригиналната, Google версия на протокола – gQUIC. Това изпълнение също непрекъснато се подобрява, за да следва най-новата IETF спецификация.
Първо интегрирахме Cronet в нашите приложения за Android, за да добавим поддръжка за QUIC. Интеграцията беше извършена по такъв начин, че да се намалят максимално разходите за миграция. Вместо напълно да замени стария мрежов стек, който използва библиотеката , интегрирахме Cronet ПОД рамката на OkHttp API. Правейки интеграцията по този начин, ние избегнахме промени в нашите мрежови повиквания (които се използват от ) на ниво API.
Подобно на подхода за устройства с Android, внедрихме Cronet в приложения на Uber на iOS, прихващайки HTTP трафик от мрежата Използване . Тази абстракция, предоставена от iOS Foundation, обработва специфични за протокол URL данни и гарантира, че можем да интегрираме Cronet в нашите iOS приложения без значителни разходи за миграция.
взето от Uber статии
В задната част те хванаха QUIC връзки чрез Google Cloud lb, което от средата на 2018 г.
Не е изненада, че Google Cloud работи чудесно с разработения от Google протокол, но какви са алтернативите?
Nginx
Неотдавна CloudFlare nginx (който не поддържа HTTP/3 по подразбиране) със своя инструмент Quiche. Внедряването е достъпно като единичен .patch файл, който се доставя с ръководство за инсталиране:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchТук можете да свържете вашите модули, ако е необходимо
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeОстава само да активирате HTTP/3 поддръжка
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
Все още не е възможно да се свържете чрез HTTP/3 в обикновени браузъри, но можете да използвате и го стартирайте с флага --enable-quic, отидете на вашия сървър или, например, на сайта quic.rocks и вижте типа връзка в Инструменти за разработчици:
Вместо HTTP/3 пише http2+quic/99, но по същество е едно и също нещо.
Други технологии
- QUIC също поддържа (който се свърза с Facebook чрез HTTP/3 с голяма фанфара) и прогресивен . Apache все още не може да го направи, но работата е в ход .
- 21 януари актуализиран
- Точно онзи ден Microsoft отвори , в който все още не са налични всички функции от IETF стандарта, но това вече е голям пробив.
Заключение
Интересът към QUIC е нестабилен, но нараства и се работи по стандартизирането му. Нови реализации на протокола се появяват почти всеки месец и всяка година все повече разработчици са убедени, че QUIC е бъдещето. Дори е възможно протоколът да бъде включен в бъдещи версии на TCP стека, което означава, че рано или късно целият Интернет ще премине към по-стабилни и по-бързи връзки.
Вече можете да конфигурирате QUIC взаимодействие за вашата инфраструктура или дори да го дадете на браузърите - всички те планират да добавят поддръжка за протокола и тъжната статистика с caniuse ще стане по-весела.
Източник: www.habr.com