HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

Структура HTTP-запроса

HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

Запрос в главной строке состоит из трех частей, разделенных пробелами:

Метод (иначе говоря, команда HTTP):

GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола -версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

Здесь запрашивается корневой файл из корневой директории web-сервера.

Строки после главной строки запроса имеют следующий формат:

Параметр: значениe .

Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
close ("закрыть") - соединение закрывается после ответа на данный запрос.

User-Agent - значением является "кодовое обозначение" браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

Referer - URL, с которого перешли на этот ресурс.

Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола - аналогичен соответствующему параметру запроса.

Код ошибки - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).

Словесное описание ошибки - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection - аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.

Content-Type ("тип содержимого") - содержит обозначение типа содержимого ответа.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html - текст в формате HTML (веб-страница);
text/plain - простой текст (аналогичен "блокнотовскому");
image/jpeg - картинка в формате JPEG;
image/gif - то же, в формате GIF;
application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length ("длина содержимого") - длина содержимого ответа в байтах.

Last-Modified ("Модифицирован в последний раз") - дата последнего изменения документа.

Цель лекции: сформировать представление о функционировании протокола HTTP/HTTPS.

HTTP (HyperText Transfer Protocol) – один из наиболее важных протоколов, который обеспечивает передачу данных через интернет. Протокол HTTP находится на седьмом, прикладном уровне модели OSI и работает на основе протокола TCP.

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

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

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

HTTP-запрос и HTTP-ответ сходны по своей структуре и называются HTTP-сообщениями . Фактически, все взаимодействие в рамках протокола HTTP сводится к пересылке HTTP-сообщений. Каждое HTTP-сообщение является обычной текстовой информацией, представленной в определенном формате. Давайте поподробнее рассмотрим формат HTTP-сообщения.

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

HTTP-запрос формируется на клиенте и отправляется на сервер с целью получения информации от него. В нем содержится информация о ресурсе, который необходимо загрузить, а также дополнительные сведения. Первая строка содержит метод запроса (который мы рассмотрим далее в этой лекции), имя ресурса (с указанием относительного пути на сервере), а также версию протокола. Например, вид приветственной строки может быть определен как "GET /images/corner1.png HTTP/1.1 ". Такой запрос обращается к серверу с требованием выдать методом GET изображение, расположенное в папке "images " и имеющее название "corner1.png ". HTTP-заголовки имеют важное значение для HTTP-запроса, поскольку в них указывается уточняющая информация о запросе – версия браузера, возможности клиента принимать сжатое содержимое, возможности кэширования и другие важные параметры, которые могут влиять на формирование ответа. В теле HTTP-запроса обычно содержится информация, которую необходимо передать на сервер. Например, если требуется загрузить файл на сервер, то содержимое файла будет находится в теле HTTP-запроса. Однако, размещение данных в теле HTTP-запроса допускается не для всех HTTP-методов. Например, тело HTTP-запроса всегда пустое, если используется метод GET . Таким образом, стандартный HTTP-запрос может выглядеть следующим образом.

В приведенном HTTP-запросе клиент обращается к серверу "microsoft.com ", запрашивает ресурс "images/corner.png " и указывает, что он способен принимать сжатое содержимое по алгоритму "gzip " или "deflate ", его языком является английский язык и указывает версию своего браузера. Как было отмечено ранее, количество и набор заголовков может существенно отличаться. Можно привести другой пример HTTP-запроса.

Этот запрос отличается от предыдущего тем, что в нем используется метод POST , который также загружает данные на сервер. При этом сами данные содержаться в теле HTTP-запроса после пустой строки.

HTTP-ответ генерируется веб-сервером в ответ на поступивший HTTP-запрос. По своей структуре он схож с HTTP-запросом, но имеет определенные отличия. Главное отличие содержится в первой строке. Вместо имени запрашиваемого ресурса и метода запроса в ней указывается статус ответа. Статус указывает на то, насколько успешно выполнился HTTP-запрос. Например, в случае, если документ найден на сервере и может быть выдан клиенту, то статус имеет значение "ОК ", которое говорит о том, что запрос выполнился успешно. Однако, могут появляться исключительные ситуации – например, документ отсутствует на сервере или у пользователя отсутствуют права на получение ресурса. Набор всевозможных статусных сообщений HTTP-ответа мы рассмотрим далее в этой лекции. Таким образом, первая строка HTTP-ответа может принимать значение "HTTP/1.1 200 OK ". HTTP-заголовки в HTTP-ответе также являются важным элементом. Они характеризуют содержимое, которое передается клиенту. Например, в этих HTTP-заголовках может содержаться информация о типе содержимого (HTML-документ, изображение и т.д.), длине содержимого (размер в байтах), дате модификации, режиме кэширования и др. Все эти заголовки влияют на способ отображения данных на клиенте, а также устанавливают правила хранения данных в клиентском кэше. Типичный вид HTTP-ответа может быть следующим.

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

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

Наиболее распространенными методами HTTP-запроса являются следующие типы методов:

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

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

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

Эти и другие статусные коды используются для передачи информации о статусе запроса от клиента к серверу.

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

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

По этой причине существует модификация этого протокола – HTTPS , т.е. протокол HTTP с поддержкой шифрования.

Как известно, существуют классические криптостойкие алгоритмы шифрования, которые шифруют данные на основе существующего ключа. Для шифрования и расшифровки данных используется один и тот же ключ – если кто-либо знает ключ к зашифрованной информации, то он может расшифровать ее. Ключ – это обычная последовательность бит определенной длины. Чем больше длина ключа, тем сложнее взломать алгоритм шифрования. Таким образом, для того, чтобы защитить свою информацию, необходимо хранить в секрете ключ шифрования. Однако, каким образом это обеспечить в рамках взаимодействия по протоколу HTTP? Ведь если передавать этот ключ в открытом виде, то смысл шифрования пропадает. В этом случае используют дополнительно другой вид шифрования – ассиметричный. В этом случае существует пара ключей – открытый и закрытый. С помощью открытого ключа можно только зашифровать информацию, а с помощью закрытого – расшифровать. Обычно при таком подходе закрытый ключ хранится в секрете, а открытый ключ является общедоступным. Однако, ассиметричный алгоритм работает медленнее, чем симметричный, поэтому его используют для первоначального обмена симметричными ключами. Давайте рассмотрим весь алгоритм работы зашифрованного соединения по HTTP.

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

Краткие итоги

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

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

Что такое HTTP протокол?

Давайте дадим определение тому, что такое HTTP протокол , но, прежде чем дать определение термину HTTP протокол, давайте разберемся со словом протокол. Слово протокол переводится с греческого дословно, как первый и клей. В древности это был листок, который клеился к свитку и на нем автор писал свое имя, дату написания и прочую никому ненужную информацию, вернее, служебную. Почему я говорю ненужную? Да потому, что рядовому обывателю интереснее само содержание свитка, а не то, кто его написал. Так и в HTTP протоколе : среднестатистическому пользователю вообще неинтересно как он получает страницы сайта, он просто открывает свой браузер. Еще одно определение слова протокол – это алгоритм, либо последовательность действий. Протокол – это свод правил и предписаний, которые регламентируют то или иное мероприятие. Протокол передачи данных – это стандарт, описывающий правила взаимодействия функциональных блоков при передаче данных.

Итак, мы определились, что HTTP – это протокол передачи данных, но что означает аббревиатура HTTP? HTTP или HyperText Transfer Protocol – это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

HTTP протокол – это правила дорожного движения в интернете, только если в жизни люди могут не соблюдать правила дорожного движения и им за это ничего не будет, то несоблюдение правил HTTP протокола ведет к тому, что пользователь не сможет работать в интернете.

HTTP протокол – это протокол передачи данных седьмого уровня модели OSI, работающий на основе технологии клиент-сервер.

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

HTTP протокол – изначально простой протокол передачи гипертекста, по которому сейчас можно передавать все, что угодно.

HTTP протокол – это транспорт для других протоколов, например, так как JSON.

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

Что же, я думаю, мы разобрались с тем, что такое HTTP протокол и можем теперь посмотреть, где он используется.

Для чего используется HTTP протокол

Скажу прямо HTTP протокол – это основа интернета, точнее не так, это та основа, которую видит конечный потребитель: посетители сайтов. Поэтому HTTP протокол в интернете везде. Фраза странно звучит, но другой я придумать не смог. Читая новости на сайте, вы используете HTTP протокол. Слушая музыку Вконтакте, вы используете HTTP протокол. Когда вы смотрите видео на YouTube – вы используете HTTP протокол. Когда вы играете в браузерную игру, вы тоже используете HTTP протокол. Поэтому я и пишу, что HTTP протокол используется везде в интернете. Без него вы бы не смогли и этот текст прочитать. Подведем итог: HTTP протокол используется для передачи данных в интернете, изначально он использовался для передачи HTML документов, но сейчас он позволяет передавать различный контент и различные .

Характеристики HTTP протокола

Давайте перечислим технические характеристики HTTP протокола :

1. HTTP протокол работает по технологии .
2. HTTP протокол относится к седьмому уровню .
3. HTTP протокол относится к семейству протоколов TCP/IP.
4. Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
5. Спецификация протокола RFC 2616.
6. Для идентификации ресурса HTTP протокол использует URI (читай про ).
7. HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
8. HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.

Это лишь часть технических характеристик протокола, но на мой взгляд, самых важных характеристик для понимания его сути.

HTTP протокол работает по принципу клиент-сервер

Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.

Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. (в данном случае покупатель) полностью управляет развитием событий, то есть (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.

История HTTP: стандарты HTTP протокола

Давайте теперь рассмотрим историю HTTP протокола на его стандартах.

1. – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
2. В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
3. В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, посылая информацию о себе в заголовке.
4. 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета.

Клиенты HTTP протокола

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

• Google Chrome;
• Mozilla FireFox;
• Opera;
• Internet Explorer;
• Яндекс Браузер;
• Safari.

Часто вместо термина клиент вы можете услышать агент пользователя, знайте, что HTTP протокол не делает никаких различий между терминами клиент и агент пользователя.

Серверы HTTP протокола

Статусная строка отделяется от заголовка символом CRLF в конце этой самой строки от HTTP заголовка (этот символ в Windows вы можете получить, нажав клавишу Enter – перенос строки), а HTTP заголовок отделяется от тела сообщения строкой, в которой только один символ – CRLF.

У запросов и ответов есть общие служебные заголовки, которые могут быть использованы, как при запросе, так и при ответе HTTP сервера. Так же хочу заметить, что есть группа заголовков относящихся к объектам (телу сообщения), они все могут быть использованы, как в запросах, так и в ответах, за исключением поля заголовка Allow, которое используется только в ответах сервера при взаимодействие по протоколу HTTP. У HTTP сообщения есть длина, которая измеряется в байтах, если у вашего HTTP сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:

1. Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
2. Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
3. Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
4. Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
5. Длина HTTP сообщения определяется закрытием соединения со стороны сервера.

Для ясности давайте рассмотрим примеры сообщений в HTTP протоколе и первое, что мы рассмотрим – пример запроса в HTTP протоколе:

POST /cgi-bin/process.cgi HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.example.com Content-Type: application/x-www-form-urlencoded Content-Length: length Accept-Language: ru-ru Accept-Encoding: gzip, deflate Connection: Keep-Alive licenseID=string&content=string&/paramsXML=string

Поля заголовка HTTP сообщения

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

Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:

1. Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
2. Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
3. Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
4. Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.

Кэширование HTTP протокола

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

Отмечу, что HTTP протокол реализован так, что этим директивам должны следовать все участники цепочки между клиентом и конечным сервером. Директивы условном можно поделить на клиентские и серверные. Давайте посмотрим на директивы HTTP протокола, предназначенные для управления кэшированием со стороны клиента.

А теперь взглянем на директивы, позволяющие .

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

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

А еще HTTP протокол позволяет присваивать каждому HTTP объекту тэг в поле заголовка ETag, по сути, это хэш сумма самого объекта и для каждого неповторяющегося объекта она уникальная, поэтому механизм кэширования HTTP протокола активно использует данное поле для проверки актуальности данных, которые хранятся в кэше.

Безопасность HTTP протокола

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

Но у HTTP протокола есть расширение HTTPS, обратите внимание HTTPS – это не протокол, а расширение HTTP протокола, которое использует TCP порт 433. Это расширение является связкой двух протоколов: HTTP и SSL или HTTP и TLS (TLS и SSL, суть одно и то же).

Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением !

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

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

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

Компоненты систем, основанных на HTTP

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

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

В реальности, между браузером и сервером гораздо больше различных устройств-посредников, которые играют какую-либо роль в обработке запроса: роутеры, модемы и так далее. Благодаря тому, что Сеть построена на основе системы уровней (слоёв) взаимодействия, эти посредники "спрятаны" на сетевом и транспортном уровнях. В этой системе уровней HTTP занимает самый верхний уровень, который называется "прикладным" (или "уровнем приложений"). Знания об уровнях сети, таких как представительский, сеансовый, транспортный, сетевой, канальный и физический, имея важное значение для понимания работы сети и диагностики возможных проблем, не требуются для описания и понимания HTTP.

Клиент: юзер-агент

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

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

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

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

Веб-сервер

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

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

Прокси

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

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

Основные аспекты HTTP

HTTP - прост

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

HTTP - расширяемый

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

HTTP не имеет состояния, но имеет сессию

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

HTTP и соединения

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

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

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

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

Чем можно управлять через HTTP

Естественная расширяемость HTTP со временем позволила большее управление и функциональность Сети. Кэш и методы аутентификации были ранними функциями в истории HTTP. Способность ослабить первоначальные ограничения, напротив, была добавлена в 2010-е.

Ниже перечислены общие функции, управляемые с HTTP.

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

HTTP поток

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

1. Открытие TCP соединения: TCP-соедиенение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.
2. Отправка HTTP-сообщения: HTTP-собщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсилуруются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. GET / HTTP/1.1 Host: сайт Accept-Language: fr
3. Читает ответ от сервера: 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
4. Закрывает или переиспользует соединение для дальнейщих запросов.

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

HTTP сообщения

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

6.1 Служба WWW

Служба WWW (World Wide Web) - предназначена для обмена гипертекстовой информацией.

Проект был предложен в 1989 году. В 1993 появился первый браузер.

WWW построена по схеме "клиент-сервер".

Браузер (Internet Explorer, Opera ...) является мультипротокольным клиентом и интерпретатором HTML. И как типичный интерпретатор, клиент в зависимости от команд (тегов) выполняет различные функции. В круг этих функций входит не только размещение текста на экране, но обмен информацией с сервером по мере анализа полученного HTML-текста, что наиболее наглядно происходит при отображении встроенных в текст графических образов.

Сервер HTTP (Apeche, IIS ...) обрабатывает запросы клиента на получение файла (в самом простом случае).

Взаимодействие клиент и сервера по протоколу HTTP.

В начале служба WWW базировалась на трех стандартах:

HTML (HyperText Markup Lan-guage) - язык гипертекстовой разметки документов;

URL (Universal Resource Locator) - универсальный способ адресации ресурсов в сети;

HTTP (HyperText Transfer Protocol) - протокол обмена гипертекстовой информацией.

CGI (Common Gateway Interface) - универсальный интерфейс шлюзов. Создан для взаимодействия HTTP - сервера с другими программами, установленными на сервере (например, СУБД).

6.2 Протокол HTTP

Первый документ (но не стандарт) - RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996)

Некоторые возможности программы:

задание глубины сканирования сайта, и внешних ссылок

задание типа файлов (расширение) для скачивания, например можно скачать только графику.

выставить лимит по размеру файла.

сканирование графических карт.

задание расписания работы, встроенный Scheduler.

задание название клиента, если есть ограничение для некоторых клиентов.

задание количества одновременно скачиваемых файлов.