Ответ
HTTP (HyperText Transfer Protocol) — это основной протокол для передачи данных в вебе. Он прошел несколько этапов эволюции:
-
HTTP/0.9 (1991) — Самая первая, простейшая версия.
- Поддерживался только один метод:
GET. - Ответ сервера состоял только из тела документа (HTML), без заголовков и кодов состояния.
- Поддерживался только один метод:
-
HTTP/1.0 (1996) — Значительное расширение.
- Появились заголовки (headers) для запроса и ответа, что позволило передавать метаинформацию.
- Добавлены методы
POSTиHEAD. - Введены коды состояния (например,
200 OK,404 Not Found). - Соединение закрывалось после каждого запроса-ответа, что создавало большие накладные расходы.
-
HTTP/1.1 (1997) — Стандарт, который доминировал более 15 лет.
- Persistent Connections (Keep-Alive): Соединение по умолчанию остается открытым для нескольких запросов, что значительно снижает задержки.
- Pipelining: Возможность отправлять несколько запросов, не дожидаясь ответа на предыдущие (хотя на практике это вызывало проблемы с
Head-of-Line blocking). - Chunked Transfer Encoding: Позволяет передавать данные по частям (чанками).
- Улучшено кэширование, добавлены новые методы (
PUT,DELETE,OPTIONSи др.).
-
HTTP/2 (2015) — Революционное обновление, направленное на производительность.
- Бинарный протокол: Вместо текстового, что упрощает парсинг и уменьшает количество ошибок.
- Мультиплексирование: Позволяет передавать несколько запросов и ответов одновременно в рамках одного TCP-соединения, решая проблему
Head-of-Line blockingна уровне протокола. - Сжатие заголовков (HPACK): Уменьшает избыточность передаваемых данных.
- Server Push: Сервер может отправлять ресурсы клиенту до того, как он их запросит.
-
HTTP/3 (2022) — Новейшая версия, основанная на протоколе QUIC.
- Работает поверх QUIC (UDP) вместо TCP. Это решает проблему
Head-of-Line blockingна уровне транспортного протокола (TCP), так как потеря одного пакета не блокирует остальные потоки. - Более быстрое установление соединения (0-RTT или 1-RTT).
- Встроенное шифрование (TLS 1.3), что делает соединение более безопасным.
- Работает поверх QUIC (UDP) вместо TCP. Это решает проблему
Краткое сравнение:
| Версия | Протокол | Соединение | Блокировка (HOL) | Основное улучшение |
|---|---|---|---|---|
| HTTP/1.0 | Текстовый | 1 запрос/соединение | Да | Заголовки, методы, статусы |
| HTTP/1.1 | Текстовый | Переиспользуемое | Да (на уровне HTTP) | Keep-Alive, Pipelining |
| HTTP/2 | Бинарный | Переиспользуемое | Нет (на уровне HTTP) | Мультиплексирование, сжатие заголовков |
| HTTP/3 | Бинарный | Переиспользуемое | Нет (на уровне TCP) | Переход на QUIC/UDP, скорость |
Ответ 18+ 🔞
А, ну это же протокол, который всю эту вашу интернет-порнографию и котиков доставляет! HTTP, блядь. Слушай, как оно эволюционировало, это просто ёперный театр какой-то.
Начиналось всё, как обычно, с примитива. HTTP/0.9, 91-й год. Представь: один метод — GET, и сервер в ответ просто плюёт тебе в лицо голым HTML-шником. Ни заголовков, ни статусов, нихуя. Просто «на, получай, мудила». Соединение — раз и закрылось. Примитив, как палка-копалка.
Потом, в 96-м, подумали: «Да это же пиздец, как неудобно». И выкатили HTTP/1.0. Вот тут уже поинтереснее. Появились, блядь, заголовки! Методы POST и HEAD подтянулись. И главное — коды состояния. Теперь сервер мог культурно так сказать: «200, ОК, держи твой файлик» или «404, пошёл нахуй, нету тут ничего». Но проблема осталась: один запрос — одно соединение. Каждый раз новый коннект открывать — это ж овердохуища накладных расходов, волосы дыбом встают.
И вот в 97-м пришёл спаситель — HTTP/1.1. Это, можно сказать, классика, на которой всё держалось лет двадцать. Главный фишечка — Persistent Connections, он же Keep-Alive. Соединение не рвётся после каждого чиха, его можно переиспользовать. Красота! Ещё пипелайнинг добавили — в теории можно было несколько запросов пачкой отправить. Но на практике вышло так себе, потому что если первый запрос в очереди тормозил, то все остальные за ним стояли, как идиоты. Проблема «Head-of-Line blocking», ебать её в сраку. Но в целом — огромный шаг.
А потом всем стало мало. В 2015-м грянул HTTP/2. Вот это была революция, блядь! Во-первых, протокол стал бинарным, а не текстовым. Парсить его — одно удовольствие, ошибок меньше. Во-вторых, и это главное — мультиплексирование. В рамках одного соединения можно одновременно гонять кучу запросов и ответов. Проблему HOL на уровне HTTP решили на раз-два. Заголовки сжимать научились (HPACK), и ещё сервер получил право делать пуш — подсовывать тебе ресурсы, которые ты ещё даже не просил, но, по его мнению, скоро понадобятся. Хитрая жопа!
И вот, казалось бы, куда уж дальше? Ан нет. В 2022-м подкатил HTTP/3. Это уже, сука, полный улёт. Он вообще отказывается от TCP, этого старого пердуна. Всё работает поверх QUIC, который юзает UDP. Потерял один пакет? Да похуй! Остальные потоки не блокируются, летят себе дальше. Проблему HOL выкорчевали уже на транспортном уровне. Соединение устанавливается чуть ли не мгновенно (0-RTT или 1-RTT), и шифрование (TLS 1.3) в нём встроено из коробки. Скорость, безопасность — красота.
Короче, вот тебе краткая выжимка, чтобы не ебать мозг:
| Версия | На чём ездит | Соединение | Блокировка (HOL) | В чём прикол |
|---|---|---|---|---|
| HTTP/1.0 | Текст | Одноразовое | Да, полная | Заголовки и статусы появились |
| HTTP/1.1 | Текст | Многоразовое | Да, на уровне HTTP | Keep-Alive, пипелайнинг (кривой) |
| HTTP/2 | Бинарный | Многоразовое | Нет! (на уровне HTTP) | Мультиплексирование, сжатие заголовков |
| HTTP/3 | Бинарный | Многоразовое | Нет! (на уровне TCP) | QUIC/UDP, скорость, встроенное шифро |
Вот так, блядь, от палки-копалки до квантового бластера дошли. Чих-пых тебя в сраку, прогресс!