HTTP (протокол передачи гипертекста) — базовый протокол Всемирной паутины. Разработанный Тимом Бернерсом-Ли и его командой в период с 1989 по 1991 год, HTTP претерпел множество изменений, которые помогли сохранить его простоту и одновременно придать ему гибкость. Читайте дальше, чтобы узнать, как HTTP эволюционировал от протокола, предназначенного для обмена файлами в полудоверенной лабораторной среде, до современной интернет-сети, передающей изображения и видео в высоком разрешении и 3D.

Изобретение Всемирной паутины

В 1989 году, работая в CERN, Тим Бернерс-Ли написал предложение о создании системы гипертекста в интернете. Изначально названная Mesh, во время реализации в 1990 году она получила новое название — World Wide Web. Построенная поверх существующих протоколов TCP и IP, система состояла из четырёх основных компонентов:

• Текстовый формат для представления гипертекстовых документов — язык разметки гипертекста (HTML).
• Протокол для обмена этими документами — протокол передачи гипертекста (HTTP).
• Клиент для отображения (и редактирования) этих документов — первый веб-браузер под названием WorldWideWeb.
• Сервер для предоставления доступа к документам — ранняя версия httpd.

Эти четыре компонента были созданы к концу 1990 года, а к началу 1991 года первые серверы уже работали за пределами CERN. 6 августа 1991 года Тим Бернерс-Ли опубликовал сообщение в открытой группе новостей alt.hypertext. Сейчас это событие считается официальным началом Всемирной паутины как публичного проекта.

Протокол HTTP, использовавшийся на ранних этапах, был очень простым. Позже его назвали HTTP/0.9, а иногда — однострочным протоколом.

HTTP/0.9 — однострочный протокол

В первоначальной версии HTTP не было номера версии; позже её назвали 0.9, чтобы отличать от последующих версий. HTTP/0.9 был предельно простым: запросы состояли из одной строки и начинались с единственного возможного метода GET, за которым следовал путь к ресурсу. Полный URL не указывался, поскольку после подключения к серверу протокол, сервер и порт были не нужны.

GET /my-page.html

Ответ тоже был предельно простым: он состоял только из самого файла.

<html>
  A text-only web page
</html>

В отличие от последующих версий, заголовков HTTP не было. Это означало, что можно было передавать только HTML-файлы. Коды состояния и ошибки отсутствовали. При возникновении проблемы создавался специальный HTML-файл с описанием проблемы для пользователя.

HTTP/1.0 — расширяемость

HTTP/0.9 был очень ограниченным, но браузеры и серверы быстро сделали его более универсальным:

• В каждом запросе передавалась информация о версии (HTTP/1.0 добавлялась к строке GET).
• В начале ответа также передавалась строка с кодом состояния. Это позволяло самому браузеру определять, выполнен ли запрос успешно, и соответствующим образом менять своё поведение. Например, обновлять локальный кеш или использовать его определённым образом.
• Для запросов и ответов появились заголовки HTTP. Стало возможно передавать метаданные, а протокол приобрёл исключительную гибкость и расширяемость.
• Благодаря заголовку Content-Type стало возможно передавать документы, отличные от обычных HTML-файлов.

В то время типичные запрос и ответ выглядели так:

GET /my-page.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html

<HTML>
A page with an image
  <IMG SRC="/my-image.gif">
</HTML>

Затем устанавливалось второе соединение и отправлялся запрос на получение изображения (с соответствующим ответом):

GET /my-image.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif

(image content)

В период с 1991 по 1995 год новые возможности вводились методом проб и ошибок. Сервер или браузер добавлял функцию и смотрел, получит ли она распространение. Проблемы взаимодействия были обычным явлением. Чтобы решить эти проблемы, в ноябре 1996 года был опубликован информационный документ с описанием общих практик. Он был известен как RFC 1945 и определял HTTP/1.0.

HTTP/1.1 — стандартизированный протокол

Тем временем шла полноценная стандартизация. Она проходила параллельно с созданием различных реализаций HTTP/1.0. Первая стандартизированная версия HTTP — HTTP/1.1 — была опубликована в начале 1997 года, всего через несколько месяцев после HTTP/1.0.

HTTP/1.1 прояснил неоднозначности и привнёс множество улучшений:

• Соединение можно было использовать повторно, что экономило время. Больше не требовалось открывать его несколько раз для отображения ресурсов, встроенных в исходный документ.
• Была добавлена конвейеризация. Она позволяла отправить второй запрос до того, как ответ на первый был передан полностью. Это уменьшало задержку связи.
• Появилась поддержка ответов с передачей по частям.
• Были добавлены дополнительные механизмы управления кешем.
• Появилось согласование содержимого, в том числе языка, кодировки и типа. Теперь клиент и сервер могли согласовать, каким содержимым обмениваться.
• Благодаря заголовку Host появилась возможность размещать разные домены на одном IP-адресе, что позволило совместно размещать серверы.

В следующем примере показана типичная последовательность запросов HTTP/1.1, отправляемых через одно постоянное TCP-соединение, и продемонстрировано, как клиенты могут повторно использовать соединения для более эффективной загрузки ресурсов. Первый запрос получает веб-страницу, а сервер отвечает HTML-документом. Затем клиент последовательно отправляет дополнительные запросы, встречая в HTML CSS-ресурсы и JavaScript:

GET /en-US/docs/ HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive

HTTP/1.1 200 OK
accept-ranges: none
content-encoding: br
date: Tue, 01 Jul 2025 08:32:50 GMT
expires: Tue, 01 Jul 2025 09:26:50 GMT
cache-control: public, max-age=3600
age: 1926
last-modified: Sat, 28 Jun 2025 00:47:12 GMT
etag: W/"b55394ed2f274eea5d528cf6c91e1dcf"
content-type: text/html
vary: Accept-Encoding
content-length: 26178

[26178 bytes of HTML]

GET /static/css/main.9e7d1ce5.css HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd

HTTP/1.1 200 OK
content-encoding: br
content-length: 43694
date: Mon, 30 Jun 2025 21:13:12 GMT
expires: Mon, 30 Jun 2025 21:47:29 GMT
cache-control: public, max-age=31536000
age: 42704
last-modified: Mon, 30 Jun 2025 00:33:45 GMT
etag: W/"d4f4d0955482844ad842986a9bcb7e8a"
content-type: text/css
vary: Accept-Encoding

[43694 bytes of CSS]

GET /static/js/main.a918a4e7.js HTTP/1.1
Host: developer.mozilla.org
…

Установка TCP-соединения — затратная часть обмена данными между клиентом и сервером, а медленный старт TCP означает, что долгоживущие соединения работают быстрее, чем только что созданные. HTTP/1.1 позволяет повторно использовать TCP-соединение для нескольких запросов и ответов, поэтому не нужно создавать новое соединение для каждого запроса. Однако клиентам всё ещё приходилось ждать загрузки каждого ресурса, прежде чем запросить следующий (блокировка в начале очереди). Чтобы обойти это ограничение, большинство браузеров допускают до шести TCP-соединений на сайт (или источник). Используя шесть параллельных соединений, браузеры могут одновременно загружать несколько ресурсов по модели HTTP/1.1, что значительно повышает производительность.

HTTP/1.1 впервые был опубликован как RFC 2068 в январе 1997 года.

Более двух десятилетий развития

Расширяемость HTTP упростила создание новых заголовков и методов. Хотя протокол HTTP/1.1 совершенствовался в ходе двух редакций — RFC 2616, опубликованного в июне 1999 года, и RFC 7230–RFC 7235, опубликованных в июне 2014 года, до выхода HTTP/2, — он оставался чрезвычайно стабильным более 15 лет. В 2022 году HTTP/1.1 был обновлён документом RFC 9110. Обновился не только HTTP/1.1: была пересмотрена вся спецификация HTTP, и теперь она разделена на следующие документы: семантика (RFC 9110), кеширование (RFC 9111), применимое ко всем версиям HTTP, а также HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113) и HTTP/3 (RFC 9114). Кроме того, спецификация наконец получила статус интернет-стандарта (STD 97), тогда как прежде она всегда была предлагаемым стандартом или проектом стандарта.

Использование HTTP для безопасной передачи данных

Самое значительное изменение HTTP произошло в конце 1994 года. Вместо передачи HTTP поверх базового стека TCP/IP компания Netscape Communications, занимавшаяся компьютерными сервисами, создала дополнительный уровень шифрования поверх него — SSL. SSL 1.0 так и не был выпущен для широкой публики, но SSL 2.0 и его преемник SSL 3.0 позволили создавать сайты электронной коммерции. Для этого они шифровали сообщения между сервером и клиентом и гарантировали их подлинность. Впоследствии SSL был стандартизирован и стал TLS.

В тот же период стало ясно, что необходим зашифрованный транспортный уровень. Интернет уже не был преимущественно академической сетью, а превратился в джунгли, где рекламодатели, случайные пользователи и преступники боролись за доступ к как можно большему объёму личных данных. По мере того как приложения на основе HTTP становились мощнее и требовали доступа к личной информации — такой как адресные книги, электронная почта и местоположение пользователя, — TLS стал необходим не только для электронной коммерции.

Использование HTTP для сложных приложений

Изначально Тим Бернерс-Ли не задумывал HTTP как среду только для чтения. Он хотел создать сеть, в которой люди могли бы удалённо добавлять и перемещать документы, — своего рода распределённую файловую систему. Примерно в 1996 году HTTP был расширен для поддержки создания документов, и был создан стандарт под названием WebDAV. Он стал включать специализированные приложения, например CardDAV для работы с записями адресной книги и CalDAV для работы с календарями. Но у всех этих расширений *DAV был недостаток: их можно было использовать только при наличии соответствующей реализации на серверах.

В 2000 году был разработан новый подход к использованию HTTP — передача репрезентативного состояния (REST). API основывался не на новых методах HTTP, а на доступе к конкретным URI с помощью базовых методов HTTP/1.1. Благодаря этому любое веб-приложение могло позволить API получать и изменять свои данные без обновления браузеров или серверов. Вся необходимая информация встраивалась в файлы, которые веб-сайты предоставляли через стандартный HTTP/1.1. Недостаток модели REST заключался в том, что каждый веб-сайт определял собственный нестандартный RESTful API и полностью контролировал его. Это отличалось от расширений *DAV, где клиенты и серверы могли взаимодействовать друг с другом. RESTful API получили широкое распространение в 2010-х годах.

С 2005 года веб-страницам стало доступно больше API. Некоторые из них расширяют протокол HTTP для решения конкретных задач:

• События, отправляемые сервером, позволяют серверу передавать браузеру периодические сообщения.
• WebSocket — новый протокол, который можно установить, повысив уровень существующего HTTP-соединения.

Смягчение модели безопасности веба

HTTP не зависит от модели безопасности веба, известной как политика одного источника. Более того, текущая модель безопасности веба появилась уже после создания HTTP! Со временем стало полезно снимать некоторые ограничения этой политики при соблюдении определённых условий. Сервер сообщал клиенту, в каком объёме и когда можно снять такие ограничения, используя новый набор заголовков HTTP. Они были определены в спецификациях, таких как совместное использование ресурсов между источниками (CORS) и политика безопасности содержимого (CSP).

Помимо этих крупных расширений, были добавлены многие другие заголовки, иногда только в экспериментальном порядке. Среди примечательных заголовков — Do Not Track (DNT) для управления конфиденциальностью, X-Frame-Options и Upgrade-Insecure-Requests, но существуют и многие другие.

HTTP/2 — протокол с повышенной производительностью

С годами веб-страницы становились всё сложнее. Некоторые из них сами по себе превратились в приложения. На страницах стало больше визуального контента, а объём и размер скриптов, добавляющих интерактивность, увеличились. Значительно возрос объём данных, передаваемых по HTTP, и число запросов, что усложнило работу соединений HTTP/1.1 и увеличило накладные расходы. Чтобы решить эту проблему, в начале 2010-х годов Google реализовала экспериментальный протокол SPDY. Этот альтернативный способ обмена данными между клиентом и сервером заинтересовал разработчиков браузеров и серверов. SPDY обеспечивал более высокую отзывчивость и решал проблему дублирования передаваемых данных, став основой протокола HTTP/2.

Протокол HTTP/2 отличается от HTTP/1.1 несколькими особенностями:

• Это двоичный, а не текстовый протокол. Его нельзя прочитать и создать вручную. Несмотря на это ограничение, он позволяет реализовать улучшенные методы оптимизации.
• Это мультиплексированный протокол. Параллельные запросы могут выполняться через одно и то же соединение, что снимает ограничения протокола HTTP/1.x.
• Он сжимает заголовки. Поскольку заголовки часто похожи в группе запросов, это устраняет дублирование и сокращает объём передаваемых данных.

Официально стандартизированный в мае 2015 года, HTTP/2 достиг пика использования в январе 2022 года: его применяли 46,9% всех веб-сайтов (см. эту статистику). Сайты с высокой посещаемостью внедряли его быстрее всего, чтобы сократить накладные расходы на передачу данных и связанные с ними затраты.

Вероятно, быстрое распространение объясняется тем, что HTTP/2 не требовал изменений веб-сайтов и приложений. Для его использования был необходим только обновлённый сервер, взаимодействующий с современной версией браузера. Для внедрения требовалось участие лишь ограниченного числа групп, а по мере обновления устаревших версий браузеров и серверов использование протокола естественным образом росло, не требуя значительных усилий от веб-разработчиков.

Эволюция после HTTP/2

Расширяемость HTTP по-прежнему используется для добавления новых возможностей. Среди заметных расширений протокола HTTP, появившихся в 2016 году, можно отметить:

• Поддержка Alt-Svc позволила разделить идентификацию ресурса и его местоположение. Это привело к появлению более интеллектуального механизма кеширования CDN.
• Появление подсказок клиента позволило браузеру или клиенту заблаговременно сообщать серверу о своих требованиях и ограничениях оборудования.
• Появление префиксов, связанных с безопасностью, в заголовке Cookie помогло гарантировать, что защищённые файлы cookie не будут изменены.

HTTP/3 — HTTP поверх QUIC

Следующая основная версия HTTP, HTTP/3, имеет ту же семантику, что и предыдущие версии HTTP, но использует QUIC вместо TCP на транспортном уровне. По состоянию на октябрь 2022 года HTTP/3 использовали 26% всех веб-сайтов.

QUIC разработан для значительного снижения задержки HTTP-соединений. Как и HTTP/2, он является мультиплексированным протоколом, но HTTP/2 работает поверх одного TCP-соединения, поэтому обнаружение потери пакетов и их повторная передача на уровне TCP могут блокировать все потоки. QUIC запускает несколько потоков поверх UDP и независимо обрабатывает обнаружение потери пакетов и повторную передачу для каждого потока. Поэтому при возникновении ошибки блокируется только тот поток, в пакете которого содержатся данные.

Определённый в RFC 9114, HTTP/3 поддерживается большинством основных браузеров, включая Chromium (и его варианты, такие как Chrome и Edge), а также Firefox.

См. также

• Управление соединениями в HTTP/1.x
• Механизм обновления протокола
• Ресурсы и спецификации HTTP
• Термины глоссария:
  • HTTP
  • HTTP/2
  • QUIC
  • Время кругового обхода (RTT)
  • Медленный старт TCP
  • Протокол управления передачей (TCP)