Http

HTTP — это протокол для извлечения ресурсов, таких как HTML-документы. Это основа любого обмена данными в Интернете и это протокол клиент-сервер, что означает, что запросы инициируются получателем, обычно веб-браузером. Полный документ реконструируется из различных полученных поддокументов, например, текста, описания макета, изображений, видео, сценариев и многого другого.

Клиенты и серверы общаются, обмениваясь отдельными сообщениями (в отличие от потока данных). Сообщения, отправленные клиентом, обычно веб-браузером, называются запросами, а сообщения, отправленные сервером в качестве ответа, называются ответами.

Разработанный в начале 1990-х годов, HTTP является расширяемым протоколом, который развивался с течением времени. Это протокол прикладного уровня, который отправляется по TCP или по TCP-соединению, зашифрованному TLS, хотя теоретически может быть использован любой надежный транспортный протокол. Благодаря своей расширяемости он используется не только для извлечения гипертекстовых документов, но и изображений и видео или для публикации контента на серверах, как в случае с результатами HTML-форм. HTTP также можно использовать для извлечения частей документов для обновления веб-страниц по требованию.

HTTP — это клиент-серверный протокол: запросы отправляются одной сущностью, user-agent (или прокси-сервером от его имени). Большую часть времени пользовательским агентом является веб-браузер, но это может быть что угодно, например, робот, который сканирует Интернет для заполнения и поддержания индекса поисковой системы.

Каждый отдельный запрос отправляется на сервер, который обрабатывает его и предоставляет ответ, называемый ответом. Между клиентом и сервером существует множество сущностей, в совокупности называемых прокси, которые выполняют различные операции и действуют, например, как шлюзы или кэши.

На самом деле между браузером и сервером, обрабатывающим запрос, больше компьютеров: есть маршрутизаторы, модемы и многое другое. Благодаря многоуровневому дизайну Интернета они скрыты в сетевом и транспортном уровнях. HTTP находится сверху, на прикладном уровне. Хотя они важны для диагностики сетевых проблем, базовые слои в основном не имеют отношения к описанию HTTP.

User-agent - это любой инструмент, который действует от имени пользователя. Эта роль в основном выполняется веб-браузером, но она также может выполняться программами, используемыми инженерами и веб-разработчиками для отладки своих приложений.

Браузер всегда является сущностью, инициирующей запрос. Он никогда не является сервером (хотя некоторые механизмы были добавлены на протяжении многих лет для имитации сообщений, инициированных сервером).

Чтобы отобразить веб-страницу, браузер отправляет исходный запрос на получение HTML-документа, представляющего страницу. Затем он анализирует этот файл, делая дополнительные запросы, соответствующие сценариям выполнения, информации о макете (CSS) для отображения и подресурсам, содержащимся на странице (обычно изображениям и видео). Затем веб-браузер объединяет эти ресурсы для представления полного документа, веб-страницы. Сценарии, выполняемые браузером, могут извлекать больше ресурсов на более поздних этапах, и браузер соответствующим образом обновляет веб-страницу.

Веб-страница является гипертекстовым документом. Это означает, что некоторые части отображаемого содержимого являются ссылками, которые могут быть активированы (обычно щелчком мыши) для получения новой веб-страницы, что позволяет пользователю направлять свой пользовательский агент и перемещаться по Интернету. Браузер преобразует эти направления в HTTP-запросы и далее интерпретирует HTTP-ответы, чтобы предоставить пользователю четкий ответ.

На противоположной стороне канала связи находится сервер, который обслуживает документ по запросу клиента. Сервер выглядит как только одна машина виртуально; но на самом деле это может быть набор серверов, разделяющих нагрузку (балансировка нагрузки), или сложная часть программного обеспечения, опрашивающая другие компьютеры (например, кэш, сервер БД или серверы электронной коммерции), полностью или частично генерирующая документ по требованию.

Сервер не обязательно является одной машиной, но на одном компьютере может быть размещено несколько экземпляров серверного программного обеспечения. С HTTP/1.1 и заголовком Host они могут даже использовать один и тот же IP-адрес.

Между веб-браузером и сервером многочисленные компьютеры и машины ретранслируют HTTP-сообщения. Из-за многоуровневой структуры веб-стека большинство из них работают на транспортном, сетевом или физическом уровнях, становясь прозрачными на уровне HTTP и потенциально оказывая значительное влияние на производительность. Те, которые работают на прикладных уровнях, обычно называются прокси. Они могут быть прозрачными, пересылающими запросы, которые они получают, не изменяя их каким-либо образом, или непрозрачными, и в этом случае они каким-то образом изменят запрос, прежде чем передать его на сервер. Прокси могут выполнять множество функций:

кэширование (кэш может быть публичным или частным, как кэш браузера)
фильтрация (например, антивирусное сканирование или родительский контроль)
балансировка нагрузки (чтобы позволить нескольким серверам обслуживать разные запросы)
аутентификация (для управления доступом к различным ресурсам)
ведение журнала (позволяет хранить историческую информацию)

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

Введенные в HTTP/1.0, заголовки HTTP упрощают расширение и экспериментирование с этим протоколом. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.

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

Соединение контролируется на транспортном уровне и, следовательно, принципиально выходит за рамки HTTP. HTTP не требует, чтобы базовый транспортный протокол был основан на соединении; он только требует, чтобы он был надежным или не терял сообщения (как минимум, представляя ошибку в таких случаях). Среди двух наиболее распространенных транспортных протоколов в Интернете TCP надежен, а UDP — нет. Поэтому HTTP полагается на стандарт TCP, который основан на подключении.

Прежде чем клиент и сервер смогут обменяться парой HTTP-запрос/ответ, они должны установить TCP-соединение, процесс, который требует нескольких кругового пути. По умолчанию HTTP/1.0 открывается отдельное TCP-соединение для каждой пары HTTP-запрос/ответ. Это менее эффективно, чем совместное использование одного TCP-соединения, когда несколько запросов отправляются в тесной последовательности.

Чтобы смягчить этот недостаток, HTTP/1.1 ввел конвейеризацию (которую оказалось трудно реализовать) и постоянные соединения: базовое TCP-соединение можно частично контролировать с помощью заголовка Connection. HTTP/2 пошел еще дальше, мультиплексируя сообщения по одному соединению, помогая поддерживать соединение теплым и более эффективным.

В настоящее время проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google экспериментирует с QUIC, который основан на UDP, чтобы обеспечить более надежный и эффективный транспортный протокол.

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

Вот список общих функций, управляемых с помощью HTTP:

Кэширование Тем, как кэшируются документы, можно управлять по протоколу HTTP. Сервер может инструктировать прокси и клиенты о том, что кэшировать и как долго. Клиент может указать прокси-серверам промежуточного кэша игнорировать сохраненный документ.
Ослабление ограничения происхождения Чтобы предотвратить слежку и другие вторжения в частную жизнь, веб-браузеры обеспечивают строгое разделение между веб-сайтами. Только страницы из одного источника могут получить доступ ко всей информации веб-страницы. Хотя такое ограничение является бременем для сервера, заголовки HTTP могут ослабить это строгое разделение на стороне сервера, позволяя документу стать лоскутным одеялом информации, полученной из разных доменов; для этого могут быть даже причины, связанные с безопасностью.
Аутентификация Некоторые страницы могут быть защищены таким образом, чтобы только определенные пользователи могли получить к ним доступ. Обычная аутентификация может быть обеспечена http, либо с использованием WWW-Authenticate и аналогичных заголовков, либо путем настройки определенного сеанса с использованием файлов cookie HTTP.
Прокси и туннелирование Серверы или клиенты часто расположены в интрасетях и скрывают свой истинный IP-адрес от других компьютеров. Затем HTTP-запросы проходят через прокси-серверы, чтобы пересечь этот сетевой барьер. Не все прокси являются HTTP-прокси. Протокол SOCKS, например, работает на более низком уровне. Другие протоколы, такие как ftp, могут обрабатываться этими прокси.
Сеансов Использование файлов cookie HTTP позволяет связывать запросы с состоянием сервера. Это создает сеансы, несмотря на то, что базовый HTTP является протоколом без состояния. Это полезно не только для корзин покупок электронной коммерции, но и для любого сайта, позволяющего пользователю настраивать вывод.

Когда клиент хочет взаимодействовать с сервером, конечным сервером или промежуточным прокси-сервером, он выполняет следующие действия:

Открытие TCP-соединения: TCP-соединение используется для отправки запроса или нескольких и получения ответа. Клиент может открыть новое соединение, повторно использовать существующее или открыть несколько TCP-подключений к серверам.
Отправка HTTP-сообщения: HTTP-сообщения (до HTTP/2) читаются человеком. С HTTP/2 эти простые сообщения инкапсулируются в кадры, что делает их невозможными для непосредственного чтения, но принцип остается прежним. Например:GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr Копировать в буфер
Прочитайте ответ, отправленный сервером, например:

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

Прочитайте ответ, отправленный сервером, например:

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here come the 29769 bytes of the requested web page)

Закройте или повторно используйте подключение для дальнейших запросов.

Если активирована конвейеризация HTTP, можно отправить несколько запросов, не дожидаясь полного получения первого ответа. Конвейеризация HTTP оказалась трудной для реализации в существующих сетях, где старые части программного обеспечения сосуществуют с современными версиями. Конвейерная обработка HTTP была заменена в HTTP/2 более надежными мультиплексирующими запросами в рамках фрейма.

Сообщения HTTP, как определено в HTTP/1.1 и более ранних версиях, читаются человеком. В HTTP/2 эти сообщения встроены в двоичную структуру, фрейм, что позволяет оптимизировать, как сжатие заголовков и мультиплексирование. Даже если в этой версии HTTP отправляется только часть исходного HTTP-сообщения, семантика каждого сообщения остается неизменной, и клиент восстанавливает (виртуально) исходный запрос HTTP/1.1. Поэтому полезно понимать сообщения HTTP/2 в формате HTTP/1.1.

Существует два типа HTTP-сообщений, запросов и ответов, каждый из которых имеет свой собственный формат.

Пример HTTP-запроса:

Запросы состоят из следующих элементов:

Метод HTTP, обычно глагол, такой как GET, POST, или существительное, такое как OPTIONS или HEAD, который определяет операцию, которую клиент хочет выполнить. Как правило, клиент хочет получить ресурс (используя) или опубликовать значение HTML-формы (с помощью ), хотя в других случаях может потребоваться больше операций. GETPOST
Путь к извлекаемому ресурсу; URL-адрес ресурса, удаленный из элементов, которые очевидны из контекста, например без протокола (), домена (здесь) или TCP-порта (здесь, ).http://developer.mozilla.org80
Версия протокола HTTP.
Необязательные заголовки, передающие дополнительную информацию для серверов.
Тело, для некоторых методов, таких как , аналогично тем, которые содержат отправленный ресурс.POST

Пример ответа:

Ответы состоят из следующих элементов:

Версия протокола HTTP, которому они следуют.
Код состояния, указывающий, был ли запрос успешным или нет, и почему.
Сообщение о состоянии, недостоверное краткое описание кода состояния.
ЗАГОЛОВКИ HTTP, например, заголовки для запросов.
При необходимости — тело, содержащее извлекаемый ресурс.

Наиболее часто используемым API на основе HTTP является API XMLHttpRequest, который можно использовать для обмена данными между пользовательским агентом и сервером. Современный API выборки предоставляет те же функции с более мощным и гибким набором функций.

Другой API, события, отправленные сервером, представляет собой одностороннюю службу, которая позволяет серверу отправлять события клиенту, используя HTTP в качестве транспортного механизма. С помощью интерфейса EventSource клиент открывает подключение и устанавливает обработчики событий. Браузер клиента автоматически преобразует сообщения, поступающие в HTTP-поток, в соответствующие объекты событий. Затем он доставляет их обработчикам событий, которые были зарегистрированы для типа событий, если они известны, или в обработчик событий onmessage, если не был установлен обработчик событий для конкретного типа.

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

Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP-сообщения во фреймы для повышения производительности, базовая структура сообщений осталась неизменной со времен HTTP/1.0. Поток сеансов остается простым, что позволяет исследовать и отлаживать его с помощью простого монитора сообщений HTTP.