Web technologies http: Chapter 1. Web technologies and HTTP · HTTP/2 in Action

Эволюция HTTP — HTTP

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

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

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

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

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

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

 ПОЛУЧИТЬ /mypage.html
 

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

 
  Очень простая HTML-страница

 

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

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

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

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

 GET /mypage.html HTTP/1.0
Агент пользователя: NCSA_Mosaic/2.0 (Windows 3.1)
200 ОК
Дата: вторник, 15 ноября 1994 г. , 08:12:31 по Гринвичу.
Сервер: CERN/3.0 libwww/2.17
Тип содержимого: текст/html

Страница с изображением
  

 

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

 ПОЛУЧИТЬ /myimage.gif HTTP/1.0
Агент пользователя: NCSA_Mosaic/2.0 (Windows 3.1)
200 ОК
Дата: вторник, 15 ноября 1994 г., 08:12:32 по Гринвичу.
Сервер: CERN/3.0 libwww/2.17
Тип содержимого: текст/gif
(содержание изображения)
 

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

Тем временем велась надлежащая стандартизация. Это происходило параллельно с разнообразными реализациями HTTP/1.0. Первая стандартизированная версия HTTP, HTTP/1. 1, была опубликована в начале 1997 года, всего через несколько месяцев после HTTP/1.0.

HTTP/1.1 прояснил двусмысленности и внес многочисленные улучшения:

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

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

 GET /en-US/docs/Glossary/Simple_header HTTP/1. 1
Хост: developer.mozilla.org
Агент пользователя: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Принять: текст/html, приложение/xhtml+xml, приложение/xml; q = 0,9, */*; q = 0,8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Реферер: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 ОК
Соединение: Keep-Alive
Кодировка содержимого: gzip
Тип содержимого: текст/html; кодировка = utf-8
Дата: среда, 20 июля 2016 г., 10:55:30 по Гринвичу
Метка: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: таймаут=5, макс=1000
Последнее изменение: Вт, 19 июля 2016 г., 00:59:33 GMT
Сервер: Апач
Передача-кодирование: по частям
Варьировать: Cookie, Accept-Encoding
(содержание)
ПОЛУЧИТЬ /static/img/header-background.png HTTP/1.1
Хост: developer.mozilla.org
Агент пользователя: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Принимать: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Реферер: https://developer. mozilla.org/en-US/docs/Glossary/Simple_header
200 ОК
Возраст: 9578461
Cache-Control: public, max-age=315360000
Соединение: Keep-alive
Длина контента: 3077
Тип содержимого: изображение/png
Дата: Чт, 31 марта 2016 г., 13:34:46 по Гринвичу
Последнее изменение: ср, 21 октября 2015 г., 18:27:50 GMT
Сервер: Апач
(содержание изображения 3077 байт)
 

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

Расширяемость 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 для определенных целей:

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

Ослабление модели безопасности сети

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

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

С годами веб-страницы стали более сложными. Некоторые из них были даже самостоятельными приложениями. Было показано больше визуальных медиа, а также увеличился объем и размер сценариев, добавляющих интерактивность. Гораздо больше данных было передано через значительно большее количество 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 все еще используется для добавления новых функций. В частности, можно привести новые расширения протокола HTTP, появившиеся в 2016 году:

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

Следующая основная версия 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.

Обнаружили проблему с содержанием этой страницы?

• Отредактируйте страницу на GitHub.
• Сообщить о проблеме с содержимым.
• Посмотреть исходный код на GitHub.

Хотите принять участие?

Узнайте, как внести свой вклад.