HTTP по UDP - використовуємо з користю протокол QUIC
QUIC (Quick UDP Internet Connections) - це протокол поверх UDP, що підтримує всі можливості TCP, TLS і HTTP/2 і вирішує більшість їх проблем. Його часто називають новим або «експериментальним» протоколом, але він уже давно пережив стадію експерименту: розробка триває понад 7 років. За цей час протокол не встиг стати стандартом, але все ж таки набув широкого поширення. Наприклад, QUIC використовують для прискорення трафіку та зниження затримок у мобільних мережах такі гіганти як Google та Facebook, а IETF оголосила свій форк протоколу основою для стандарту HTTP/3 (при тому, що HTTP/2 використовує лише 44.8% сайтів).
Концепція
QUIC розроблявся як заміна застарілого TCP, який спочатку був заточений під провідні мережі з низьким відсотком втрат. TCP доставляє пакети по порядку, тому при втраті одного пакета встає вся черга (головне блокування), що негативно позначається на якості та стабільності з'єднання. Щоб уникнути масових втрат, стільникові мережі вдаються до використання великих буферів, що у свою чергу призводить до надмірності та false negative реакції протоколу (bufferbloat). Крім того, TCP витрачає дуже багато часу на встановлення з'єднання: SYN/ACK та TLS запити йдуть окремо, вимагаючи трьох roundtrip'ів замість одного, як це робить QUIC.
Так як QUIC поєднує в собі заміну TCP і реалізацію TLS 1.3, всі з'єднання завжди зашифровані, розшифрувати такий трафік не простіше, ніж якби він йшов HTTPS. Крім того, QUIC реалізований на прикладному рівні, як повна заміна TCP стека зайняла б вічність.
Незважаючи на підтримку мультиплексування в HTTP/2, проблема head-of-line blocking там залишилася через необхідність доставляти пакети по порядку. QUIC реалізований поверх UDP, тому в нього блокувань не буває в принципі, а щоб пакети не губилися безповоротно, вони нумеруються і можуть містити частини «сусідів», забезпечуючи надмірність. Крім того, QUIC розбиває монолітну чергу на кілька потоків для різних типів запитів усередині одного з'єднання. Таким чином, при втраті пакета проблеми можуть виникнути тільки в однієї черги (наприклад, на передачу файлу):
Використання
Спочатку QUIC розроблявся всередині Google і був багато в чому заточений під використання всередині компанії. У 2013 році його передали до IETF для стандартизації (яка йде досі), і тепер кожен може взяти участь у розвитку протоколу, запропонувавши те, чого не вистачає саме йому. Робоча група IETF щорічно організовує зустрічі, у рамках яких затверджується новий стандарт та ведеться обговорення нововведень. Ця реалізація QUIC вважається основною і на її основі сертифікується стандарт HTTP/3.
Поки що про включення HTTP/3 як основного протоколу не йдеться, тому що він ще не закінчений і майже не підтримується:
Але QUIC можна реалізувати як транспорт між програмою та сервером, що успішно проробили в Uber:
Коментар Uber про впровадження QUIC
Щоб успішно вбудувати QUIC та покращити продуктивність програми в умовах поганого зв'язку, ми замінили старий стек (HTTP/2 поверх TLS/TCP) на протокол QUIC. Ми задіяли мережеву бібліотеку Cronet з Chromium Projects, Що містить оригінальну, гуглівську версію протоколу - gQUIC. Ця реалізація також постійно вдосконалюється, щоб слідувати останній специфікації IETF.
Спочатку ми інтегрували Cronet у наші Android-програми, щоб додати підтримку QUIC. Інтеграцію було здійснено так, щоб максимально знизити витрати на міграцію. Замість того, щоб повністю замінити старий мережевий стек, який використовував бібліотеку OkHttp, ми інтегрували Cronet ПІД фреймворком OkHttp API. Виконавши інтеграцію у такий спосіб, ми уникли змін у наших мережевих викликах (який використовують Модифікувати) на рівні API.
Подібно до підходу до Android-пристроїв, ми впровадили Cronet у додатки Uber під iOS, перехоплюючи HTTP-трафік з мережевих API, використовуючи Протокол NSURL. Ця абстракція, надана iOS Foundation, обробляє протокол-специфічні URL-дані та гарантує, що ми можемо інтегрувати Cronet у наші iOS-додатки без істотних міграційних витрат.
На бекенді вони ловили 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 поки що не вийде, але можна взяти Chrome Canary і запустити його з прапором --enable-quic, звернутися до свого сервера або, наприклад, сайту quic.rocks і переглянути тип з'єднання в Developer Tools:
Замість HTTP/3 пишеться http2+quic/99, але це по суті те саме.
Інші технології
QUIC також підтримують LiteSpeed (які з великою помпою поєднувалися з Facebook по HTTP/3) та прогресивний Чайниця. Apache поки що не вміє, але робота йде повним ходом.
Буквально днями Microsoft відкрила код своєї реалізації msquic, в якій поки доступні не всі функції стандарту IETF, але це вже великий прорив.
Висновок
Інтерес до QUIC нестабільний, але зростає, ведеться робота над його стандартизацією. Нові реалізації протоколу з'являються майже щомісяця, і з кожним роком все більше розробників переконуються, що майбутнє за QUIC. Допускається навіть включення протоколу в майбутні версії TCP стека, а це означає, що рано чи пізно весь інтернет переїде на більш стійкі та швидкі з'єднання.
Вже зараз ви можете налаштувати QUIC-взаємодія для своєї інфраструктури або навіть віддавати його браузерам - вони всі планують додати підтримку протоколу, і сумна статистика з Canius стане веселіше.