Эволюция HTTP

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

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

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

Текстовый формат для представления гипертекстовых документов, HyperText Markup Language (HTML).
Простой протокол для обмена этими документами, HyperText Transfer Protocol (HTTP).
Клиент для отображения (и редактирования) этих документов, первый веб-браузер под названием WorldWideWeb.
Сервер для доступа к документу, раннюю версию httpd.

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

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

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

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

GET /mypage.html

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

<html>
  A very simple HTML page
</html>

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

HTTP/1.0 – Расширение возможностей

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

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

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

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

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="/myimage.gif">
</HTML>

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

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

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-адреса позволила размещение серверов.

Типичный поток запросов, все через одно соединение, выглядел так:

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.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
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

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

Более 15 лет расширений

Гибкость HTTP позволила легко создавать новые заголовки и методы. Хотя протокол HTTP/1.1 был доработан за две версии, RFC 2616, опубликованный в июне 1999 года, и RFC 7230-RFC 7235, опубликованные в июне 2014 года до выпуска HTTP/2, он оставался чрезвычайно стабильным более 15 лет.

Использование 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 для веб-страниц. Некоторые из этих API создают расширения протокола HTTP для специфических целей:

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

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

HTTP независим от модели безопасности веб-сайта, известной как политика одного источника. На самом деле, текущая модель безопасности веб-сайтов была разработана после создания HTTP! На протяжении многих лет было полезно ослабить некоторые ограничения этой политики при определенных условиях. Сервер передавал клиенту, насколько и когда ослабить эти ограничения, используя новый набор HTTP-заголовков. Эти заголовки были определены в спецификациях, таких как Cross-Origin Resource Sharing (CORS) и Content Security Policy (CSP).

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

END_OF_DOCUMENT_MARKER

HTTP/2 – Протокол для повышения производительности

На протяжении многих лет веб-страницы становились сложнее. Некоторые из них даже представляли собой полноценные приложения. Увеличивалось количество и размер визуальных медиа, а также объём и размер скриптов, добавляющих интерактивность. Больше данных передавалось через значительно большее количество HTTP-запросов, что создавало больше сложности и издержек для подключений HTTP/1.1. Чтобы учесть это, Google реализовал экспериментальный протокол SPDY в начале 2010-х годов. Этот альтернативный способ обмена данными между клиентом и сервером вызвал интерес у разработчиков, работающих как над браузерами, так и над серверами. 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 помогло гарантировать, что защищённые куки не могут быть изменены.

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

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

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

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

© 2005–2022 MDN contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP