# HTTP протягом десятиліть: історія фізики, гнучкості та пристосування до життя HTTP не розвинувся. *примусово* на зміну в фізиці, запізненні, і зловживання. Кожна версія існує через те, що попередня версія вдалася у жорстке обмеження. Якщо ви розумієте ці обмеження, ви зрозумієте, чому веб працює так само, як і вона, і чому так багато " найкращих практик " насправді працюють з обмеженнями на протоколи, які ми перетягуємо вже тридцять років. Я будую веб-програми з 1997 року. Я зневадила шторми зв'язку HTTP/1, а також спостерігала, як браузери відкривають шість з'єднань на кожен вузол як "функціональні," прокляті на TCP-головому блокі на мобільних мережах, і нарешті побачили HTTP/3, що ми знали все: мережа є проблемою. Це не підручник з протоколу. Це історія про те, як ми сюди потрапили. [TOC] ## HTTP/ 1. 0: Невиправний текст над каналами з ненадійністю ### Світ, який створив його HTTP/ 1. 0 було розроблено у 1996 році для світу, який вже не існує. Щоб зрозуміти, чому він працює, вам слід зрозуміти, що означає " інтернет " у 1996 році: - **З' єднання додзвону** на 28. 8 кб/ с (якщо вам пощастило) - **Сторінки були документами** - текст, може кілька маленьких зображень, гіперпосилання - **Користувачі, на які було натиснуто і виконано очікування** - миттєва відповідь не була очікувана. - **Сервери дорого коштували.** - Університети та компанії, не всі. У цьому світі, вузьке місце було **пропускна здатність**На додзвоні було 15 секунд завантаження сторінки 50 кБ. **Що оптимізовано HTTP/ 1. 0 для:** - Простота (зневадження у telnet) - Безнадійність (сервери не відстежують з' єднання) - Доступність для читання (текстовий протокол) - Один запит, одна відповідь, з' єднання закрито ``` GET /index.html HTTP/1.0 Host: example.com HTTP/1.0 200 OK Content-Type: text/html ... ``` Простісінький елегант, ідеальний 1996 року, і абсолютно непридатний для будь-чого, окрім отриманого документа. ### Тиск, який порушував її Потім веб змінився. До 1998 року сторінки були не лише документами, а й таблицями стилів, JavaScript, декількома зображеннями. Для однієї сторінки могли знадобитися окремі ресурси 20- 30. Всі потрібні запити: 1. **Комбінація TCP** (1 кругла подорож) 2. **Запит надіслано** (1 кругла подорож) 3. **Отримано відповідь** 4. **З' єднання закрито** 5. Повторювати для кожного зображення, таблиці стилів, скрипт... Сторінка з 20 ресурсами означала 20 рукостискання TCP. *просто шахруючи руками.* до перенесення будь-якого вмісту. Основне припущення HTTP/ 1. 0: > **Час був дешевий.** До 1999 року пропускна здатність покращувалась, але **спізнення не було** - и внезапно эти круглые поездки значат значение. HTTP/ 1. 0 було розроблено для документів. Веб став платформою для роботи з програмою. Потрібно було щось дати. ## HTTP/1. 1: We'll patch It ### Світ, який створив його У 1997 році з' явився HTTP/ 1. 1, саме тоді, коли вибухнув Інтернет. Розпочинався бум dotcom. Кожен бізнес потребував веб- сайта. Веб- сторінки отримували складні таблиці для компонування, JavaScript для взаємодії, зображення всюди. Тиск був ясний: **connection-per- request було перервано швидкодію**Завелика інфраструктура вже залежала від цього, але рішення мало бути зворотно сумісне. **Що змінилося:** - **Постійні з' єднання** (`Connection: keep-alive` типово) - повторно використовувати TCP- з' єднання - **Кодування пересилання Chunked** (відповіді по стрічці, не знаючи розміру вгорі) - **Заголовки вузла** (віртуальна назва вузла - декілька сайтів на IP, вирішальна для спільного вузла) - **Семантика кочування** (`Cache-Control`, `ETag`, умовні запити) - **Калькуляризація** (відіслати декілька запитів без очікування на відповіді) **Те, що не змінилося:** - Все ще послідовні відповіді (навіть з трубопроводом) - Заголовки тексту все ще повторюються при кожному запиті) - Все ще одна відповідь за один раз на з' єднання ``` GET /page.html HTTP/1.1 Host: example.com Connection: keep-alive HTTP/1.1 200 OK Transfer-Encoding: chunked Cache-Control: max-age=3600 ... ``` ### Чому це спрацювало HTTP/1.1 насправді не розв'язував проблему з швидкодією. Він просто перемістив її. **Пробки на трубопроводі були невдалими.** Специфікація дозволяла надсилати декілька запитів при одному з' єднанні, але: - Відповідь мала повернутися. *впорядковано* (заблоковує верхній рядок) - Одна повільна реакція заблокувала все, що було позаду. - Запити відмінених трубопроводів Buggy proxies - Більшість переглядачів вимкнули його повністю Браузери списували, замість того, щоб виправити протокол, вони працювали над ним: - Відкрити **6 паралельних з' єднань на один вузол** (обмежене обмеження) - Користування **Гагання домену** (`static1.example.com`, `static2.example.com`) для збільшення з' єднань - **Штрихові аркуші** для об' єднання зображень - **Панель CSS/ JS** щоб зменшити запити - **CDNs** зменшити спізнення Нічого з цього не працювало як планований протокол, це була екосистема, що компенсувала фундаментальне обмеження HTTP/1. 1. > **Змінено HTTP/1. 1 шахруванням, а не виправленням моделі.** ### Чому вона все одно вижила працює HTTP/1. 1 *досить добре* на п'ятнадцять років. Не тому, що це було добре, а тому, що середовище компенсувалося: - **Приїхав Бродбанд.** 20 рукостискання замість 200м, біль був стерпний. - **Закон Мура допомагав.** Сервери можуть обробити шість з'єднань на один браузер до 2005 року. - **CDN замаскували проблему.** Сервери ребер на 20 м замість 200 мс. - **Стільниця домінувала.** Дротяні з'єднання, низька спізнення, надійні мережі. Протокол все ще був зламаний. Нам просто пощастило, що світ його сховав. ### Справжня ціна Ці шість з'єднань на вузол не були вільними: - Кожне з' єднання означало інше рукостискання TCP - Кожне з'єднання змагалося за пропускну здатність. - Серверам потрібно було підтримувати більше регулярних з' єднань - **Блокування " Head of line" тільки- но пересунуто до TCP** - Втрачається пакет при одному з'єднанні, це з'єднання призупиняється Веб став швидшим у епоху HTTP/1. 1. Але не через HTTP/1.1. - Мережі стали швидшими - Качінг став розумнішим. - CDN, поглинуті з запізненням - Браузери стали кращими в паралелізмі. Ми будували програмну платформу на протоколі отримання документа. протокол програвав. ## Незадовільна правда, яку ніхто не визнає До 2010 року веб-ефективність стала сталою битвою з самим HTTP. "Найкращі звичаї" епохи розповідають історію. - Зафіксувати всі ваші JavaScript в один файл - Зішквартувати всі ваші зображення разом - Вбудований критичний CSS - Використовувати адреси даних для уникнення запитів - Список доменів для відкриття більшої кількості з' єднань - Розташувати скрипти внизу сторінки Кожна з них є робочим варіантом для "HTTP/1. 1 не може ефективно виконувати багато запитів." Я створив багато цих маленьких інструментів, таких як генератори спрайтів, компресори CSS, ми почали використовувати реагування стиснення і т.д.... Переглядачі стали швидшими через покращення HTTP. Вони були швидшими, тому що **працює навколо HTTP**. Шість з' єднань на один вузол не є можливістю. Це халепа. Обтяження домену - не найкраща практика. Це визнання невдачі. Я роками навчав розробників скидати активи, спрайти та вбудовані критичні ресурси, але це не була "добра архітектура." **керування пошкодженнями протоколу**. Міф "HTTP є простим," тому що складність була прихована у: - Керування з' єднаннями навігатора - Логіка меж CDN - Інструмент збирання з' єднання - Компонування з' єднання з сервером HTTP/1. 1 працював, тому що все *навколо* це працювало понаднормово, щоб компенсувати. Якщо ви коли-небудь бачили діаграму HTTP, яка не показує запізнення, втрати або режимів невдач, вона бреше вам. Протокол простий. Насправді це не так. ## HTTP/2: ми встановили неправильний шар ### Світ, який створив його До 2010 року Інтернет знову трансформувався і дві масивні зміни змінили все: **1 - Мобільне сталося.** Айфон, запущений у 2007 році. До 2012 року, вибухнув мобільний мережевий трафік. Раптово користувачів не було на надсиланні широкосмугового зв' язку - вони були на 3G, потім 4G, зі змінною спізною і частою втратою пакетів. Припускається, що HTTP/1. 1 може бути пошкоджено. **2. Веб-програми замінили веб- сторінки.** Gmail. Google Maps. Facebook. Twitter. Ці документи не були документами з посиланнями. Це були програми, які потребували десятків або сотень ресурсів, оновлення у режимі реального часу і миттєвої відповіді. Розробка " шість з' єднань на вузол " показала вік програми. Гугл відчув цей біль гостро: вони мали величезні масштаби, інженери, які мали успіх, і дані, які доводили, що HTTP/1.1 - це вузьке місце. у 2009 вони розпочали SPDY - експериментальний протокол, який мав стати HTTP/2. **Що змінилося:** - **Двійкове обрамлення** (не текст - більш ефективна обробка) - **Множення** (з' єднання з декількома запитами/репонансами) - **Стиснення заголовка** (HPACK - більше не повторювати ті самі заголовки) - **Натискання сервера** (пошліть ресурси перед запитом клієнта - хоча цей спосіб виявився важким для налаштування і зараз здебільшого застарілим) - **Одноразове з' єднання на джерело** (Більше немає вибуху з' єднання) ``` ┌──────────────────────────────────────────┐ │ Single TCP Connection │ ├──────────────────────────────────────────┤ │ Stream 1: GET /page.html │ │ Stream 3: GET /style.css │ │ Stream 5: GET /app.js │ │ Stream 7: GET /logo.png │ │ (all interleaved, no ordering required) │ └──────────────────────────────────────────┘ ``` Це те, що має бути використано для конвеєрного звантаження HTTP/1. 1. Потіки є незалежними. Одна повільна відповідь не блокує інших. Заголовки стиснуті. Протокол, нарешті, відповідає тому, як ми користуємося інтернетом. ### Чому це спрацювало (на правильних мережах) HTTP/ 2 був **ідеальна для мережі широкосмугового зв' язку**І в 2015, коли стандартизувався, широкосмуговий зв'язок був всюди у розвинених країнах. **Те, що поліпшилось:** - Затримка під навантаженням світла (одне з' єднання без рукостискання на запит) - Менше з' єднань (менший сервер над головою, менше TCP повільного запуску) - Краще використання пропускної здатності (без обмежень на штучне з' єднання) - Стиснення заголовка (повторювані заголовки, наприклад, куки, які вже не коштують пропускної здатності) - Не потрібно ще згуртованості/ конфігурації (зараз у багатьох маленьких файлах все гаразд) Для користувачів з обмеженими втратами пакетів HTTP/2 було справжнім покращенням. Записи на лавках виглядали чудово. Номінали покращилися. Google оголосив перемогу. ### Тиск, який порушував її Але світ уже змінився. **Мобільний тепер був більшістю веб-трафіку.** І мобільні мережі мають фундаментальну властивість, якої не має широкосмуговий зв'язок: **втрата пакета є сталою**. гарантії TCP **доставка за порядком**Якщо пакет 47 втрачено, пакети 48-100 чекають на передачу 47, навіть якщо вони належать повністю незалежним потокам HTTP/ 2. ``` ┌──────────────────────────────────────────┐ │ TCP Receive Buffer │ ├──────────────────────────────────────────┤ │ [pkt 45][pkt 46][ ? ][pkt 48][pkt 49] │ │ ↑ │ │ Waiting for packet 47 │ │ │ │ Stream 1 data: BLOCKED │ │ Stream 3 data: BLOCKED │ │ Stream 5 data: BLOCKED (has pkt 48-49) │ │ Stream 7 data: BLOCKED │ └──────────────────────────────────────────┘ ``` HTTP/2 розв' язано блокування голови на рівні програми. Потім TCP повернув її на шарі транспорту. **Один загублений пакет затримує всі потоки.** На чистому переплетеному з' єднанні втрати пакетів трапляються рідко. На мобільних мережах, втрачені WiFi або розтягнені посилання? Втрата пакета є сталою. А оскільки HTTP/ 2 використовує a *single* З' єднання (за дизайном), один втрачений пакет тепер блоки *все* замість одного з шести зв'язків. Швидкодія HTTP/ 2: - **Дротяна, низька втрата**: Чудово - **Мобільна, помірна втрата**: Іноді *гірше* ніж HTTP/1. 1 - **Висока спізнення, будь-яка втрата**: Катастрофічна Іронія: HTTP/2 було розроблено для мобільного, але гарантії TCP зробили його гіршим, ніж протокол, який він замінив. ### Чому в HTTP/2 швидше з'являється (аж до тих пір, поки це не сталося) Початкові визначення HTTP/ 2 показали справжні покращення: - Менший рівень з' єднань означав пришвидшене початкове завантаження (ДЗ потискуванням один раз, а не шість разів) - Стиснення верхнього колонтитула зменшило надкладку - Множення працювало добре для активів з однакового походження Але з самого хвоста Пізня розповів іншу історію. *медіана* Полегчало, а P99 - ще гірше. Я бачив це на власні очі: клієнт увімкнув HTTP/2 через свій CDN і дивився мобільний P99 Lendncy *збільшення* 40%. Панелі приладів показали покращення на стільниці. Квитки підтримки надходили від користувачів мобільного зв' язку. Ми витратили тиждень, з'ясувавши, що " покращення " HTTP/ 2 погіршувало стан більшості з них. Коли HTTP/2 працює, він чудово працює, коли пакет падає на мобільний зв'язок у найгірший момент, все замерзає. Основна проблема: > **HTTP/2 припустив, що TCP достатньо хороший.** Для широкосмугового зв'язку це було не так, і до того часу, коли HTTP/2 був стандартизований, мобільні телефони вже перемагали, ми просувалися так далеко, як TCP міг би взяти нас з собою. ## HTTP/3: добре, ми перемістимо вниз стеблину ### Світ, який створив його До 2015 року було чітко видно докази: **Проблема TCP**. З 2012 року Гугл проводив експерементальні експерименти: вони мали дані на мобільних мережах, знешкоджених WiFi, з'єднання з високою частотою, HTTP/2 над TCP було невдалим у спосіб, який неможливо виправити, не змінюючи транспортного шару. Але ви не можете просто "виправити TCP" - його реалізовано в ядрах операційних систем, і його випікають у всіх маршрутизаторах, брандмауерах і середніх скриньках в інтернеті. зміни TCP означає очікування десятиліть на оновлення всієї інфраструктури інтернету. Отже, Google зробив щось зухвале: **Вони збудували новий протокол транспортування на вершині UDP**. UDP - це "dumb" за дизайном - він просто надсилає пакети без жодних гарантій, але саме це потрібно, якщо ви хочете реалізувати. *ваш власний* Сумнівна семантика: гарантія TCP (надійна, замовлена доставка), але робить це **на потік** замість на з' єднання. HTTP/3 (2022) - це HTTP над JOIC. Це вхід, який ми повинні були перейти нижче HTTP, щоб виправити HTTP. **Що змінилося:** - **ДІВЧИНА понад UDP** (не TCP) - **Відновлення втрати рівня потоку** (один загублений пакет затримує його потік) - **Налаштування швидкого з' єднання** Можливе перевизначення (0- RT) - **Типово, шифрування** (ХИЛА 1,3, збудований на QUIC) - **Міграція з' єднання** (змінює адресу IP) ``` ┌──────────────────────────────────────────┐ │ QUIC Connection │ ├──────────────────────────────────────────┤ │ Stream 1: [pkt][pkt][pkt] ← flowing │ │ Stream 3: [pkt][ ? ][pkt] ← waiting │ │ Stream 5: [pkt][pkt][pkt] ← flowing │ │ Stream 7: [pkt][pkt] ← flowing │ │ │ │ Lost packet only affects Stream 3 │ └──────────────────────────────────────────┘ ``` **Те, що залишилося таким же:** - HTTP семантика (GET, POST, заголовки, коди стану) - Логіка кешування - Зберігання візерунків - Все на шарі програми > **HTTP/3 не змінив HTTP. Він змінив спосіб, в який HTTP переживає реальність.** ### Чому ЄВРЕЙСЬКІ СПРАВИ ВІЧНЕ знаряддя гарантує надійність TCP. *на потік*Не за з' єднання. Це ключове розуміння. **TCP обіцяє:** "Кожен байт прибуде в порядку." **ЖІНКА:** "Кожен байт *у цьому потоці* виходить в порядку. " Ось чому HTTP/3 не падає на мережу з втратою якості. Інші особливості, що розв'язують довготривалі проблеми: **Міграція з' єднання:** ``` Phone on WiFi → walks out of range → switches to cellular TCP: Connection dies. Restart everything. QUIC: Connection ID maintained. Streams continue. ``` Це має значення, оскільки мобільні користувачі *постійно* Перемикання мережі. Виходьте з дому, втратите WiFi, перемкніться на стільниковий канал. За допомогою TCP всі зв' язки гинуть. З ВВК зв' язок продовжуватиметься. **Поновлення 0- RT:** ``` First connection: Full handshake (1-RTT) Returning user: Send data immediately (0-RTT) ``` **Шифрування всюди:** ``` TCP + TLS: Handshake, then encrypted tunnel QUIC: Encryption is the handshake (TLS 1.3 integrated) ``` ### Світ, який потребує його HTTP/3 розроблено для світу, в якому ми живемо: - **Мобільний перший**: Більше половини веб-трафіку мобільні - **Ненадійні мережі**: WiFi, стільниковий, переповнені громадськими мережами - **Загальні користувачі**: Високі з' єднання за запізненням з віддаленими серверами - **Очікується конфіденційності**: Шифрування є обов' язковим, а не обов' язковим Протокол, нарешті, відповідає мережевій реальності. Тридцять років після того, як HTTP/ 1. 0 надано надійних переданих з' єднань, HTTP/3 визнає, що надійність - це виняток, а не правило. ### Ціна прогресу HTTP/ 3 не вільний: - **UDP часто заблоковано** від корпоративних брандмауерів (потрібно повернутися до HTTP/ 2) - **Більше процесора** для реалізації простору користувача VOIC (не у ядрі на зразок TCP, хоча цей проміжок закривається за допомогою шунтування ядра і оптимізованих стосів) - **Нові інструменти зневаджування** (tcpdump показує зашифрований UDP, не придатний для читання HTTP) - **Перешкода в середній скриньці** (деякі мережі mangle UDP (непередбачено) Але для мобільних програм, ненадійних мереж та служб з підвищеною чутливістю до застарілих, HTTP/3 - це перша версія, яка відповідає поведінці мереж. ## Справжній урок у всіх перекладах Кожну версію HTTP було змінено, тому що **середовище змінилося швидше, ніж протокол**. Що ж до середовища, то чому він має бути таким же, як і раніше? |---------|-----|-------------|------------|--------------| Д-р Цукер: "% 1%-2-8-2-2-2-2-2-2-2-2-2-3-3-2-2-2-3-2-2-2-2-2-2-2-2!" } Д-р Цукер:" +-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-р-ро, +[ HTTP/1.1] 1999- 2010}Пружні, веб-applications}Унизьно пізнок' є неефективна------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 2015-2002 рр., кульмінація мобільного висхідного зв'язку достатньо надійна, TCP провалився 245 + 21 + 21 + + + + +001, глобальне значення: "Нічого не можна" все ще йде...' Шаблон ясний: 1. Протокол розроблено для поточного середовища 2. Зміни середовища (швидше, ніж протоколи можуть адаптуватися) 3. Об' єм роботи накопичується (CDNs, connection brokes, krunddling) 4. Новий протокол визнає реальність 5. Повторити Протокол постійно віддаляється від мережі. Кожна абстракція, яка здавалась достатньою, була відчищена, коли цього вимагалося середовище. **Інші спостереження:** - "Непристойний" - це брехня, яку ми наказуємо собі спати вночі. - Більшість перемог відтворено *робочі межі*, не чистота протоколів. CDNs, керування кешем, набору з' єднань, прохання про вугілля - все компенсується за обмеження протоколів. - "Просте" йшло далі. HTTP/ 1. 0 було простим. Потім нам потрібні були постійні з' єднання. Потім кратне з' єднання. Потім новий транспорт. Кожен шар складності розв' язано справжні проблеми. - **Час від часу.** HTTP/2 був би ідеальним, якби він прибув 2005 року. До 2015 мобільний телефон вже змінив гру. Протокол розв'язував вчорашню проблему. ## Що не змінилося з 1.0 І ось вам незручна частина: незважаючи на 30 років протоколної еволюції: **Запити все ще не справджуються.** Розділ Мережі. Сервери аварійно завершуються. Виникають перевищення часу очікування. Ваш код все ще потребує повторних спроб логіки. **Мережі досі брешуть.** 200 OK не означає, що відповідь правильна. З' єднання закрито не означає, що запит не пройшов успішно. Тайм- аут не означає, що сервер не оброблював ваш запит. **Кеш все ще слугує застарілими даними.** `Cache-Control` є запитом, а не командою. Проксі роблять те, що хочуть. Ініціалізація CDN у найкращому випадку. **Клієнти все ще дуже намагаються.** Натискання кнопки користувача, більше нічого не відбувається, натискання знову призведе до натискання кнопки. Тепер у вас два запити. Важливі функції. **Розробники все ще не розуміють ідентифікаційність.** Get should be safe. PUT повинен бути idempotent. POST - дикий захід. Більшість API неправильно розуміють це. ```csharp // This is still your problem, regardless of HTTP version public async Task CreateOrderAsync(Order order) { // What happens if this times out? // Did the server receive it? // Did it process it? // Will the client retry? // Will you create duplicate orders? // HTTP/3 doesn't save you here. // Idempotency keys do. } ``` > **Якщо ви їх не розумієте, HTTP/3 вас не врятує.** ## Чого я насправді навчився Після побудови веб-застосунок у всіх цих версіях протоколів, ось що залишилося: **Перший протокол - ненадійний шар.** HTTP надає вам запит/відключення семантики.Це не гарантує доставку, коректність, або абсолютно раз обробки. це ваша робота. **2 Нормальність - це ворог, а не пропускна здатність.** Більшість проблем з швидкодією пов' язані з округленням, а не зв' язані між собою. Зняття запитів має більше значення, ніж стискання вантажів. **У кожного "найкращого звичаю" є дата закінчення терміну дії.** Харчування доменів було необхідним для HTTP/ 1. 1. Це шкідливе для HTTP/ 2. Поновлення CSS було розумним. Тепер ми маємо поштовх до сервера (які також зазнали невдачі) і ранні підказки. Тактика змінюється. Мета (відновлює скасування латки) залишається однаковою. **4. Виміри на реальних мережах.** Бенчмарки на локальному вузлі нічого не доводять. Ваші користувачі знаходяться на мобільних мережах, готелі WiFi і насичених кавових крамницях. **5. Найбільше значення мають нудні частини.** Тайм- аут. Переривання. Переривання електричних сітківок. Ідепотентність. Ставлення до з' єднань. Ці нерадісні подробиці визначають, чи працює ваша система під навантаженням. ## Висновки HTTP не став швидшим, тому що став розумнішим. **проблема з мережею**. Кожна версія була правильною на свій час: - **HTTP/ 1. 0** було бездоганно для отримання документа додзвону - **HTTP/1. 1** чудово підходить для веб-програм широкосмугового доступу - **HTTP/ 2** чудово пасує до з' єднань з низькою кількістю пропущених - **HTTP/ 3** є побудований для реальності мобільної, ненадійної мережі, в якій ми насправді живемо. Ми помилилися, вважаючи, що будь-яка з них є постійним вирішенням проблеми, всі вони були реакцією на специфічний тиск навколишнього середовища. **HTTP версії не оновлюються у розумінні споживача. Вони оптимізовані для різних дистрибутивів помилок.** І все ж, після всього цього, фундаментальні засади залишаються: - Спроба надсилання запитів зазнала невдачіThe role of the transaction, in present tense - Мережі лежать - Кашет твердий. - Важливість недійсності Протокол розвинувся, проблеми не зникли, вони просто перемістилися. Програма для збирання систем, які витримують невдачі. Тест на реальних мережах. Зрозумійте, що кожна версія HTTP є компромісом, сформованим за її часів, а не оновленням, яке застаріло раніше. Це тридцять років HTTP, це те, що ми побудували. і в іншому десятилітті, припущення HTTP/3, ймовірно, виглядатимуть так само, як і HTTP/1,1,1,000 зараз. ## Подальше читання - [RFC 9114: HTTP/ 3](https://datatracker.ietf.org/doc/html/rfc9114) - Офіційна специфікація. - [RFC 9000: QUIC](https://datatracker.ietf.org/doc/html/rfc9000) - Протокол транспортування - [Пояснення HTTP/ 2](https://http2-explained.haxx.se/) - Чудовий огляд Деніела Стенберґа. - [Мережа перегляду високої швидкодії](https://hpbn.co/) - Глибоке занурення Іллі Ґрігорік (немає доступу в мережі)