This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Sunday, 28 December 2025
HTTP не розвинувся. примусово на зміну в фізиці, запізненні, і зловживання.
Кожна версія існує через те, що попередня версія вдалася у жорстке обмеження. Якщо ви розумієте ці обмеження, ви зрозумієте, чому веб працює так само, як і вона, і чому так багато " найкращих практик " насправді працюють з обмеженнями на протоколи, які ми перетягуємо вже тридцять років.
Я будую веб-програми з 1997 року. Я зневадила шторми зв'язку HTTP/1, а також спостерігала, як браузери відкривають шість з'єднань на кожен вузол як "функціональні," прокляті на TCP-головому блокі на мобільних мережах, і нарешті побачили HTTP/3, що ми знали все: мережа є проблемою.
Це не підручник з протоколу. Це історія про те, як ми сюди потрапили.
HTTP/ 1. 0 було розроблено у 1996 році для світу, який вже не існує. Щоб зрозуміти, чому він працює, вам слід зрозуміти, що означає " інтернет " у 1996 році:
У цьому світі, вузьке місце було пропускна здатністьНа додзвоні було 15 секунд завантаження сторінки 50 кБ.
Що оптимізовано HTTP/ 1. 0 для:
GET /index.html HTTP/1.0
Host: example.com
HTTP/1.0 200 OK
Content-Type: text/html
<html>...
Простісінький елегант, ідеальний 1996 року, і абсолютно непридатний для будь-чого, окрім отриманого документа.
Потім веб змінився.
До 1998 року сторінки були не лише документами, а й таблицями стилів, JavaScript, декількома зображеннями. Для однієї сторінки могли знадобитися окремі ресурси 20- 30.
Всі потрібні запити:
Сторінка з 20 ресурсами означала 20 рукостискання TCP. просто шахруючи руками. до перенесення будь-якого вмісту.
Основне припущення HTTP/ 1. 0:
Час був дешевий.
До 1999 року пропускна здатність покращувалась, але спізнення не було - и внезапно эти круглые поездки значат значение.
HTTP/ 1. 0 було розроблено для документів. Веб став платформою для роботи з програмою. Потрібно було щось дати.
У 1997 році з' явився HTTP/ 1. 1, саме тоді, коли вибухнув Інтернет. Розпочинався бум dotcom. Кожен бізнес потребував веб- сайта. Веб- сторінки отримували складні таблиці для компонування, JavaScript для взаємодії, зображення всюди.
Тиск був ясний: connection-per- request було перервано швидкодіюЗавелика інфраструктура вже залежала від цього, але рішення мало бути зворотно сумісне.
Що змінилося:
Connection: keep-alive типово) - повторно використовувати TCP- з' єднання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 насправді не розв'язував проблему з швидкодією. Він просто перемістив її.
Пробки на трубопроводі були невдалими. Специфікація дозволяла надсилати декілька запитів при одному з' єднанні, але:
Браузери списували, замість того, щоб виправити протокол, вони працювали над ним:
static1.example.com, static2.example.com) для збільшення з' єднаньНічого з цього не працювало як планований протокол, це була екосистема, що компенсувала фундаментальне обмеження HTTP/1. 1.
Змінено HTTP/1. 1 шахруванням, а не виправленням моделі.
працює HTTP/1. 1 досить добре на п'ятнадцять років. Не тому, що це було добре, а тому, що середовище компенсувалося:
Протокол все ще був зламаний. Нам просто пощастило, що світ його сховав.
Ці шість з'єднань на вузол не були вільними:
Веб став швидшим у епоху HTTP/1. 1. Але не через HTTP/1.1.
Ми будували програмну платформу на протоколі отримання документа. протокол програвав.
До 2010 року веб-ефективність стала сталою битвою з самим HTTP.
"Найкращі звичаї" епохи розповідають історію.
Кожна з них є робочим варіантом для "HTTP/1. 1 не може ефективно виконувати багато запитів."
Я створив багато цих маленьких інструментів, таких як генератори спрайтів, компресори CSS, ми почали використовувати реагування стиснення і т.д....
Переглядачі стали швидшими через покращення HTTP. Вони були швидшими, тому що працює навколо HTTP.
Шість з' єднань на один вузол не є можливістю. Це халепа. Обтяження домену - не найкраща практика. Це визнання невдачі.
Я роками навчав розробників скидати активи, спрайти та вбудовані критичні ресурси, але це не була "добра архітектура." керування пошкодженнями протоколу.
Міф "HTTP є простим," тому що складність була прихована у:
HTTP/1. 1 працював, тому що все навколо це працювало понаднормово, щоб компенсувати.
Якщо ви коли-небудь бачили діаграму HTTP, яка не показує запізнення, втрати або режимів невдач, вона бреше вам. Протокол простий. Насправді це не так.
До 2010 року Інтернет знову трансформувався і дві масивні зміни змінили все:
1 - Мобільне сталося. Айфон, запущений у 2007 році. До 2012 року, вибухнув мобільний мережевий трафік. Раптово користувачів не було на надсиланні широкосмугового зв' язку - вони були на 3G, потім 4G, зі змінною спізною і частою втратою пакетів. Припускається, що HTTP/1. 1 може бути пошкоджено.
2. Веб-програми замінили веб- сторінки. Gmail. Google Maps. Facebook. Twitter. Ці документи не були документами з посиланнями. Це були програми, які потребували десятків або сотень ресурсів, оновлення у режимі реального часу і миттєвої відповіді. Розробка " шість з' єднань на вузол " показала вік програми.
Гугл відчув цей біль гостро: вони мали величезні масштаби, інженери, які мали успіх, і дані, які доводили, що HTTP/1.1 - це вузьке місце. у 2009 вони розпочали SPDY - експериментальний протокол, який мав стати HTTP/2.
Що змінилося:
┌──────────────────────────────────────────┐
│ 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, коли стандартизувався, широкосмуговий зв'язок був всюди у розвинених країнах.
Те, що поліпшилось:
Для користувачів з обмеженими втратами пакетів 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/2 було розроблено для мобільного, але гарантії TCP зробили його гіршим, ніж протокол, який він замінив.
Початкові визначення HTTP/ 2 показали справжні покращення:
Але з самого хвоста Пізня розповів іншу історію. медіана Полегчало, а P99 - ще гірше.
Я бачив це на власні очі: клієнт увімкнув HTTP/2 через свій CDN і дивився мобільний P99 Lendncy збільшення 40%. Панелі приладів показали покращення на стільниці. Квитки підтримки надходили від користувачів мобільного зв' язку. Ми витратили тиждень, з'ясувавши, що " покращення " HTTP/ 2 погіршувало стан більшості з них.
Коли HTTP/2 працює, він чудово працює, коли пакет падає на мобільний зв'язок у найгірший момент, все замерзає.
Основна проблема:
HTTP/2 припустив, що TCP достатньо хороший.
Для широкосмугового зв'язку це було не так, і до того часу, коли HTTP/2 був стандартизований, мобільні телефони вже перемагали, ми просувалися так далеко, як TCP міг би взяти нас з собою.
До 2015 року було чітко видно докази: Проблема TCP.
З 2012 року Гугл проводив експерементальні експерименти: вони мали дані на мобільних мережах, знешкоджених WiFi, з'єднання з високою частотою, HTTP/2 над TCP було невдалим у спосіб, який неможливо виправити, не змінюючи транспортного шару.
Але ви не можете просто "виправити TCP" - його реалізовано в ядрах операційних систем, і його випікають у всіх маршрутизаторах, брандмауерах і середніх скриньках в інтернеті. зміни TCP означає очікування десятиліть на оновлення всієї інфраструктури інтернету.
Отже, Google зробив щось зухвале: Вони збудували новий протокол транспортування на вершині UDP.
UDP - це "dumb" за дизайном - він просто надсилає пакети без жодних гарантій, але саме це потрібно, якщо ви хочете реалізувати. ваш власний Сумнівна семантика: гарантія TCP (надійна, замовлена доставка), але робить це на потік замість на з' єднання.
HTTP/3 (2022) - це HTTP над JOIC. Це вхід, який ми повинні були перейти нижче HTTP, щоб виправити HTTP.
Що змінилося:
┌──────────────────────────────────────────┐
│ 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/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 розроблено для світу, в якому ми живемо:
Протокол, нарешті, відповідає мережевій реальності. Тридцять років після того, як HTTP/ 1. 0 надано надійних переданих з' єднань, HTTP/3 визнає, що надійність - це виняток, а не правило.
HTTP/ 3 не вільний:
Але для мобільних програм, ненадійних мереж та служб з підвищеною чутливістю до застарілих, 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, глобальне значення: "Нічого не можна" все ще йде...'
Шаблон ясний:
Протокол постійно віддаляється від мережі. Кожна абстракція, яка здавалась достатньою, була відчищена, коли цього вимагалося середовище.
Інші спостереження:
І ось вам незручна частина: незважаючи на 30 років протоколної еволюції:
Запити все ще не справджуються. Розділ Мережі. Сервери аварійно завершуються. Виникають перевищення часу очікування. Ваш код все ще потребує повторних спроб логіки.
Мережі досі брешуть. 200 OK не означає, що відповідь правильна. З' єднання закрито не означає, що запит не пройшов успішно. Тайм- аут не означає, що сервер не оброблював ваш запит.
Кеш все ще слугує застарілими даними.
Cache-Control є запитом, а не командою. Проксі роблять те, що хочуть. Ініціалізація CDN у найкращому випадку.
Клієнти все ще дуже намагаються. Натискання кнопки користувача, більше нічого не відбувається, натискання знову призведе до натискання кнопки. Тепер у вас два запити. Важливі функції.
Розробники все ще не розуміють ідентифікаційність. Get should be safe. PUT повинен бути idempotent. POST - дикий захід. Більшість API неправильно розуміють це.
// This is still your problem, regardless of HTTP version
public async Task<Result> 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 версії не оновлюються у розумінні споживача. Вони оптимізовані для різних дистрибутивів помилок.
І все ж, після всього цього, фундаментальні засади залишаються:
Протокол розвинувся, проблеми не зникли, вони просто перемістилися.
Програма для збирання систем, які витримують невдачі. Тест на реальних мережах. Зрозумійте, що кожна версія HTTP є компромісом, сформованим за її часів, а не оновленням, яке застаріло раніше.
Це тридцять років HTTP, це те, що ми побудували. і в іншому десятилітті, припущення HTTP/3, ймовірно, виглядатимуть так само, як і HTTP/1,1,1,000 зараз.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.