Основы функционирования веб-приложений. Что такое HTTP-протокол

13.08.2019

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

HTTP – используется для получения данных с веб-сайтов в качестве прикладного протокола. HTTPS – расширение для протокола HTTP, которое имеет поддержку по протоколам SSL и TLS. Как видим HTTP и HTTPS это не разные протоколы, а HTTPS это только надстройка для шифрования, применяется для защищенного процесса обмена информацией и авторизации серверов, которым необходима дополнительная безопасность.

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

Безопасный HTTPS применяется для авторизации и защищенных транзакций. Он работает идентично HTTP, но использует дополнительный криптографический уровень защиты данных – протокол SSL. С технической стороны оба протокола применяют два разных порта для коммуникации: в отличии от HTTP, безопасный аналог применяет 443 TCP-порт. Благодаря SSL обмен данными производится на защищенном уровне, а это очень важно для сайтов, которые хранят конфиденциальную информацию клиентов, например, данные банковских карт.

Совсем не странно, что поисковая система Google более доверительно относится к сайтам, которые беспокоятся о безопасности посетителей, поэтому проекты с HTTPS ранжируются выше. Переход на “безопасный режим” будет полезен даже сайтам, которым не нужно беспокоиться о личных данных пользователей. Такие сайты получат преимущество в выдаче и соответственно привлекут еще больше посетителей на свои страницы.

Какие технические аспекты положены в основу TLS (Transport Layer Security) :

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

Хотя поисковик и ранжирует сайты с HTTPS выше, но пока этот фактор имеет малый вес по сравнению с другими, на которых он также обращает внимание, например, качественный контент.

Преимущества при переходе на HTTPS с точки зрения :

сохранение защищенных реферальных данных пользователя;
повышение позиций в поиске (хотя данный фактор пока мало весом, но в будущем он обязательно повысит свое значение);
конфиденциальность: шифрование всех коммуникаций, недоступность для третьих лиц, защита личной информации.

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

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

выбирайте необходимый для вашего ресурса сертификат: для одного домена, мульти или wildcard;
применяйте сертификаты с 2048-битными ключами;
не закрывайте от индексации HTTPS-страницы в файле robots.txt;
по максимуму старайтесь не использовать noindex в метатеге «robots»;
анализируйте переходы с HTTP на HTTPS в программе Google Webmaster Tools;
применяйте относительные URL без указания протокола для всех остальных доменов и тп.

Если придерживаться данных советов, можно безболезненно перейти на безопасный протокол HTTPS. Поверьте, Ваши посетители и клиенты это оценят. Ведь сайту, который беспокоится о сохранности данных своих пользователей доверяют намного больше. Переходи на HTTPS: Устанавливаем SSL бесплатно! Детали .

В компании HyperHost Вы сможете приобрести необходимый для вашего онлайн проекта SSL-сертификат и тем самым осуществить переход на HTTPS. Наша техническая поддержка поможет сделать все необходимые настройки и ответит на все интересующие Вас вопросы. О преимуществах SSL-сертификата и его видах можете ознакомиться в предыдущей статье: . Преимущества перехода на HTTPS описаны более детально .

5076 раз(а) 6 Сегодня просмотрено раз(а)

HTTP - это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

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

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию - 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

Методы

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

Существующие методы:

GET : получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

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

PUT : обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE : служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

Также HTTP поддерживает и другие методы:

HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

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

Коды состояния

В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
204 No Content : в теле ответа нет сообщения.
205 Reset Content : указание серверу о сбросе представления документа.
206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

400 Bad Request : вопрос был сформирован неверно.
401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
403 Forbidden : сервер не открыл доступ к ресурсу.
405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Message = *() CRLF [] = Request-Line | Status-Line = Field-Name ":" Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Формат запроса

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

SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

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

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP версия
Код статуса
Сообщение статуса, понятное для человека

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

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

Age время в секундах, когда сообщение было создано на сервере.
ETag MD5 сущности для проверки изменений и модификаций ответа.
Location используется для перенаправления и содержит новый URL адрес.
Server определяет сервер, где было сформирован ответ.

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

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый - это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler :

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP - jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

Итог

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

Протокол передачи гипертекста HTTP (Hypertext Transfer Protocol, RFC 1945, 2068) предназначен для передачи гипертекстовых документов от сервера к клиенту. Протокол HTTP относится к протоколам прикладного уровня. Согласно RFC, транспортным протоколом для него должен быть протокол с установлением соединения, надежной передачей данных и без сохранения границ между сообщениями. На практике в подавляющем большинстве случаев транспортным протоколом для HTTP является протокол TCP, причем сервер HTTP (сервер Web) находится в состоянии ожидания соединения со стороны клиента стандартно по порту 80 TCP, а клиент HTTP (браузер Web) является инициатором соединения.

В терминах Web все, к чему может получить доступ пользователь, – документы, изображения, программы, – называется ресурсами. Каждый ресурс имеет уникальный для Web адрес, называемый универсальным идентификатором ресурса (URI – Universal Resource Identifier). В самом общем случае URI выглядит следующим образом:

protocol://user:password@host:port/path/file?paremeters#fragment

Отдельные поля URI имеют следующий смысл:

protocol - прикладной протокол, посредством которого получают доступ к ресурсу;

user - пользователь, от имени которого получают доступ к ресурсу либо сам пользователь в качестве ресурса;

password - пароль пользователя для аутентификации при доступе к ресурсу;

host - IP-адрес или имя сервера, на котором расположен ресурс;

port - номер порта, на котором работает сервер, предоставляющий доступ к ресурсу;

path - путь к файлу, содержащему ресурс;

file - файл, содержащий ресурс;

parameters - параметры для обработки ресурсом-программой;

fragment - точка в файле, начиная с которой следует отображать ресурс.

Взаимодействие между клиентом и сервером Web осуществляется путем обмена сообщениями. Сообщения HTTP делятся на запросы клиента серверу и ответы сервера клиенту.

Сообщения запроса и ответа имеют общий формат. Оба типа сообщений выглядят следующим образом: сначала идет начальная строка (start-line), затем, возможно, одно или несколько полей заголовка, называемых, также, просто заголовками, затем пустая строка (то есть строка, состоящая из символов CR и LF), указывающая конец полей заголовка, а затем, возможно, тело сообщения:

начальная строка

поле заголовка 1

поле заголовка 2

поле заголовка N

тело сообщения

Формат начальной строки клиента и сервера различаются и будут рассмотрены далее. Заголовки бывают четырех видов:

общие заголовки (general-headers), которые могут присутствовать как в запросе, так и в ответе;

заголовки запросов (request-headers), которые могут присутствовать только в запросе;

заголовки ответов (response-headers), которые могут присутствовать только в ответе;

заголовки объекта (entity-headers), которые относятся к телу сообщения и описывают его содержимое.

Каждый заголовок состоит из названия, символа двоеточия ":" и значения. Наиболее важные заголовки приведены в табл. 1.

Таблица 1
Заголовки протокола HTTP
Заголовок	Назначение
Заголовки объекта
	Перечисляет поддерживаемые сервером методы
Content-Encoding	Способ, которым закодировано тело сообщения, например, с целью уменьшения размера
	Длина сообщения в байтах
	Тип содержимого и, возможно, некоторые параметры
	Уникальный тэг ресурса на сервере, позволяющий сравнивать ресурсы
	Дата и время, когда ресурс на сервере будет изменен, и его нужно получать заново
	Дата и время последней модификации содержимого
Заголовки ответа
	Число секунд, через которое нужно повторить запрос для получения нового содержимого
	URI ресурса, к которому нужно обратиться для получения содержимого
	Дата и время или число секунд, через которое нужно повторить запрос, чтобы получить успешный ответ
	Название программного обеспечения сервера, приславшего ответ
Заголовки запроса
	Типы содержимого, которое "понимает" клиент и может воспроизвести
	Кодировки символов, в которых клиент может принимать текстовое содержимое
	Способ, которым сервер может закодировать сообщение
	Хост и номер порта, с которого запрашивается документ
If-Modified-Since If-Unmodified-Since	Заголовки запроса для условного обращения к ресурсу
	Запрос части документа
	Название программного обеспечения клиента
Общие заголовки
	Указывает серверу на завершение (close) или продолжение (keep-alive) сеанса
	Дата и время формирования сообщения

Подробное описание заголовков HTTP/1.0 можно найти в RFC 2068.

В теле сообщения содержится собственно передаваемая информация – полезная нагрузка сообщения. Тело сообщения представляет собой последовательность октетов (байтов). Тело сообщения может быть закодировано, например, для уменьшения объема передаваемой информации, при этом способ кодирования указывается в заголовке объекта Content-Encoding.

Сообщение запроса от клиента к серверу состоит из строки запроса (request-line), заголовков (общих, запросов, объекта) и, возможно, тела сообщения. Строка запроса начинается с метода, затем следует идентификатор запрашиваемого ресурса, версия протокола и завершающие символы конца строки:

<Метод> <Идентификатор> <Версия HTTP>

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

HTTP/<версия>.<подверсия>

В RFC 2068 представлен протокол HTTP/1.1.

Рассмотрим основные методы протокола HTTP.

Метод OPTIONS выполняет запрос информации об опциях соединения (например, методах, типах документов, кодировках), которые поддерживает сервер для запрашиваемого ресурса. Этот метод позволяет клиенту определять опции и/или требования, связанные с ресурсом, или возможности сервера, не производя никаких действий над ресурсом и не инициируя его загрузку.

Если ответ сервера – это не сообщение об ошибке, то заголовки объекта содержат информацию, которую можно рассматривать как опции соединения. Например, в заголовке Allow перечислены все методы, поддерживаемые сервером для данного ресурса.

Если идентификатор запрашиваемого ресурса – звездочка ("*"), то запрос OPTIONS предназначен для обращения к серверу в целом.

Если идентификатор запрашиваемого ресурса – не звездочка, то запрос OPTIONS применяется к опциям, которые доступны при соединении с указанным ресурсом.

Метод GET позволяет получать любую информацию, связанную с запрашиваемым ресурсом. В большинстве случаев, если идентификатор запрашиваемого ресурса указывает на документ (например, документ HTML, текстовый документ, графическое изображение, видеоролик), то сервер возвращает содержимое этого документа (содержимое файла). Если запрашиваемый ресурс является приложением (программой), формирующим в процессе своей работы некоторые данные, то в теле сообщения ответа возвращаются эти данные, а не двоичный образ выполняемого файла. Это используется, например, при создании приложений CGI. Если идентификатор запрашиваемого ресурса указывает на директорию (каталог, папку), то, в зависимости от настроек сервера, может быть возвращено либо содержимое директории (список файлов), либо содержимое одного из файлов, находящегося в этой директории (как правило, index.html или Default.htm). В случае запроса папки ее имя может указываться как с символом "/" на конце, так и без него. При отсутствии на конце идентификатора ресурса данного символа сервер выдает один из ответов с перенаправлением (с кодами статуса 301 или 302).

Одной из разновидностей метода GET является "условный GET" ("conditional GET"), при котором сообщение запроса включает заголовки запроса If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Условный метод GET запрашивает передачу объекта, только если он удовлетворяет условиям, описанным в приведенных заголовках. Например, при наличии заголовка If-Modified-Since содержимое запрашиваемого ресурса будет получено только в том случае, если оно не изменялось после момента времени, указанного в качестве значения данного заголовка. Условный метод GET предназначен для уменьшения ненужной загрузки сети, поскольку позволяет не загружать вторично уже сохраненные клиентом данные.

Различают также "частичный GET" ("partial GET"), при котором сообщение запроса включает заголовок запроса Range. Частичный GET запрашивает передачу только части объекта. Частичный метод GET предназначен для уменьшения ненужной загрузки сети, за счет запроса только части объекта, когда другая часть уже загружена клиентом. Значением заголовка Range является строка "bytes=" с последующим указанием диапазона байтов, которые необходимо получить. Байты нумеруются с 0. Начальный и конечный байты диапазона разделяются символом "–". Как начальный, так и конечный байты в диапазоне могут отсутствовать. Если нужно получить несколько диапазонов, то они перечисляются через запятую. Если некоторые из перечисленных диапазонов пересекаются, то сервер осуществляет их объединение. Сообщение ответа в случае запроса с частичным методом GET должно содержать заголовок Content-Range, в котором указывается передаваемый диапазон. Если сервер передает несколько непересекающихся диапазонов, то заголовок Content-Type принимает специальное значение "multypart/byteranges". Тело сообщения разбивается на части, разделенные сгенерированным сервером разделителем и переданным в качестве параметра заголовка Content-Type. Каждая отдельная часть содержит собственные заголовки Content-Type и Content-Range с пустой строкой перед содержимым диапазона.

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

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

аннотация существующих ресурсов;

регистрация сообщения на электронной доске объявлений (BBS), в конференциях новостей (newsgroups), списках рассылки (mailing lists) или подобной группе статей;

передача блока данных, например результат ввода в форме, процессу обработки;

выполнение запросов к базам данных (БД);

Фактически функция, выполняемая методом POST, определяется приложением, на которое указывает идентификатор запрашиваемого ресурса. Наряду с методом GET, метод POST используется при создании приложений CGI. Браузер может формировать запросы с методом POST при отправке форм. Для этого элемент FORM документа HTML, содержащего форму, должен иметь атрибут method со значением POST.

Приложение, запуск которого инициируется методом POST, может выполнить действие на сервере и не передать никакого содержимого в качестве результата работы. В зависимости от того, включает ответ тело сообщения, описывающее результат, или нет, код состояния в ответе может быть как 200 (OK), так и 204 (Нет содержимого, No Content).

Если ресурс на сервере был создан, ответ содержит код состояния 201 (Создан, Created) и включает заголовок ответа Location.

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

Различие между методами POST и PUT заключается в различном значении идентификатора запрашиваемого ресурса. URI в запросе POST идентифицирует ресурс, который обрабатывает включенный в тело сообщения объект. Этим ресурсом может быть приложение, принимающее данные. Напротив, URI в запросе PUT идентифицирует объект, включенный в запрос в виде тела сообщения, то есть пользовательский агент назначает данный URI включенному ресурсу.

Метод DELETE запрашивает сервер об удалении ресурса, имеющего запрашиваемый идентификатор. Запрос с данным методом может быть отвергнут сервером, если у пользователя нет прав на удаление запрашиваемого ресурса.

Метод TRACE используется для возврата переданного запроса на уровне протокола HTTP. Получатель запроса (сервер Web) отправляет полученное сообщение обратно клиенту как тело сообщения ответа с кодом состояния 200 (OK). Запрос TRACE не должен содержать тела сообщения.

TRACE позволяет клиенту видеть, что получает на другом конце сервер и использовать эти данные для тестирования или диагностики.

Если запрос успешно выполнен, то ответ содержит все сообщение запроса в теле сообщения ответа, а заголовок объекта Content-Type имеет значение "message/http".

Подробную информацию о методах протокола HTTP/1.1 можно найти в RFC 2068.

После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP ответа.

Первая строка ответа – это строка состояния (Status-Line). Она состоит из версии протокола, числового кода состояния, поясняющей фразы, разделенных пробелами и завершающих символов конца строки:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Версия протокола имеет тот же смысл, что и в запросе.

Элемент код состояния (Status-Code) – это целочисленный трехразрядный (трехзначный) код результата понимания и удовлетворения запроса. Поясняющая фраза (Reason-Phrase) представляет собой короткое текстовое описание кода состояния. Код состояния предназначен для обработки программным обеспечением, а поясняющая фраза предназначена для пользователей.

Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры:

1xx: Информационные коды – запрос получен, продолжается обработка.

2xx: Успешные коды – действие было успешно получено, понято и обработано.

3xx: Коды перенаправления – для выполнения запроса должны быть предприняты дальнейшие действия.

4xx: Коды ошибок клиента – запрос имеет ошибку синтаксиса или не может быть выполнен.

5xx: Коды ошибок сервера – сервер не в состоянии выполнить допустимый запрос.

Поясняющие фразы для каждого кода состояния перечислены в RFC 2068 и являются рекомендуемыми, но могут быть заменены на эквивалентные без ограничений со стороны протокола. Например, в локализованных русскоязычных версиях HTTP серверов эти фразы заменены русскими. В табл. 2 приведены коды ответов сервера HTTP.

Таблица 2
Коды ответов сервера HTTP
	Поясняющая фраза согласно
1xx: Информационные коды
		Продолжать
2xx: Успешные коды


		Нет содержимого
		Сбросить содержимое
	Partial Content	Частичное содержимое
3xx: Коды перенаправления
	Moved Temporarily	Временно перемещен
		Не модифицирован
4xx: Коды ошибок клиента
		Испорченный запрос
		Несанкционированно
		Не найден
	Method Not Allowed	Метод не дозволен
	Request Timeout	Истекло время ожидания запроса
		Конфликт
	Length Required	Требуется длина
	Request Entity Too Large	Объект запроса слишком большой

Окончание табл. 2
	Поясняющая фраза согласно	Эквивалентная поясняющая фраза на русском языке
5xx: Коды ошибок сервера
	Internal Server Error	Внутренняя ошибка сервера
	Not Implemented	Не реализовано
	Service Unavailable	Сервис недоступен
	HTTP Version Not Supported	Не поддерживаемая версия HTTP

Подробную информацию о кодах ответа и заголовках, сопровождающих данные ответы, можно получить в RFC 2068.

За строкой состояния следуют заголовки (общие, ответа и объекта) и, возможно, тело сообщения.

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

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

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

Аббревиатура читается как «HyperText Transfer Protocol», что в переводе означает «протокол для передачи ». HTTP относится к группе прикладного уровня на основании специфики, использующейся OSI.

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

Для чего нужен HTTP

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

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

HTTP является протоколом для обмена информацией с помощью соединения IP/ ТСР. Как правило, для этого сервер использует порт 80 типа TCP. Если порт не прописан, программное обеспечение клиента будет использовать порт 80 типа TCP по умолчанию. В некоторых случаях могут использоваться и другие порты.

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

Чем отличается HTTP от HTTPS

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

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

Таким образом, HTTP применяется для передачи данных, а HTTPS позволяет осуществлять защищенную передачу данных с помощью шифрования и выполнять авторизацию на ресурсах с высоким уровнем безопасности.

Дополнительный функционал

HTTP отличается богатым функционалом, он совместим с различными расширениями. Используемая сегодня спецификация 1.1 позволяет применять заголовок Upgrade для переключения и работы через другие протоколы при обмене данными. Для этого пользователь должен отправить запрос серверу с данным заголовком. Если же сервер нуждается в переходе на специфичный обмен по иному протоколу, он возвращает клиенту запрос, в котором отображается статус «426 Upgrade Required».

Данная возможность особенно актуальна для обмена информацией через WebSocket (имеет спецификацию RFC 6455 , позволяет обмениваться данными в любой момент, без лишних HTTP-запросов). Для перехода на WebSocket один пользователь отправляет запрос с заголовком Upgrade и значением «websocket». Далее сервер отвечает «101 Switching Protocols». После этого момента начинается передача информация по WebSocket.

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol , «протокол передачи гипертекста». В соответствии со спецификацией OSI , HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616 .

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

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

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

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP - это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

Http://alizar.сайт/

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

Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:

Telnet alizar.сайт 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод - это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) - по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок - это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar..ru или m.. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется - и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.

Удачи и плодотворного обучения!

Теги:

http
alizar
spdy

Добавить метки