Все о протоколах передачи данных http и https. Протокол HTTP — что такое HyperText Transfer Protocol
.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
Прокси-серверы
История развития
HTTP/0.9
Кроме обычного метода GET , различают ещё и . Условные запросы GET содержат заголовки If-Modified-Since , If-Match , If-Range и подобные. Частичные GET содержат в запросе Range . Порядок выполнения подобных запросов определён стандартами отдельно.
HEAD
Аналогичен методу GET , за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных , проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.
POST
Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами - текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET , метод POST не считается идемпотентным , то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location .
Сообщение ответа сервера на выполнение метода POST не кэшируется.
PUT
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT , клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
DELETE
Удаляет указанный ресурс.
TRACE
Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
LINK
Устанавливает связь указанного ресурса с другими.
UNLINK
Убирает связь указанного ресурса с другими.
CONNECT
Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.
Коды состояния
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр . Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:
201 Webpage Created 403 Access allowed only for registered users 507 Insufficient Storage
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC . Введение новых кодов должно производиться только после согласования с IETF . Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния.
1xx Informational (рус. Информационный )В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
2xx Success (рус. Успех )Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
3xx Redirection (рус. Перенаправление )Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов , , , и относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location . При этом допускается использование фрагментов в целевом URI.
4xx Client Error (рус. Ошибка клиента )Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD , сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной мнемотехники
5xx Server Error (рус. Ошибка сервера )Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD , сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
Заголовки
Тело сообщения
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения (message-body) отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.
Message-body = entity-body
|
Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).
Включается или не включается тело сообщения (message-body) в сообщение ответа зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения (message-body), даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.
Примеры диалогов HTTP
Обычный GET-запрос
Различают два основных типа согласований:
- Управляемое сервером (англ. Server-Driven ).
- Управляемое клиентом (англ. Agent-Driven ).
Одновременно могут быть использованы оба типа или каждый из них по отдельности.
В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование (англ. Transparent Negotiation ) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, рус. Прозрачное согласование содержимого , см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.
Управляемое сервером
При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки Accept , Accept-Charset , Accept-Encoding , Accept-Languages и User-Agent . Серверу желательно включать в ответ заголовок Vary с указанием параметров, по которым различается содержимое по запрашиваемому URI.
Географическое положение клиента можно определить по удалённому IP-адресу . Это возможно за счёт того что IP-адреса, как и доменные имена , регистрируются на конкретного человека или организацию. При регистрации указывается регион, в котором будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в Интернете можно найти соответствующие свободно распространяемые базы данных и готовые программные модули для работы с ними (следует ориентироваться на ключевые слова «Geo IP»).
Следует помнить что такой метод способен определить местоположение максимум с точностью до города (отсюда определяется и страна). При этом информация актуальна только на момент регистрации адресного пространства. Например, если московский провайдер зарегистрирует диапазон адресов с указанием Москвы и начнёт предоставлять доступ клиентам из ближайшего Подмосковья, то его абоненты могут на некоторых сайтах наблюдать, что они из Москвы, а не из Красногорска или Дзержинского .
Управляемое сервером согласование имеет несколько недостатков:
- Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском).
- Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами - мало. Из-за этого оборудование испытывает избыточную нагрузку.
- Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей.
- Передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.
Управляемое клиентом
В данном случае тип содержимого определяется только на стороне клиента. Для этого сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий. Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш.
Основной недостаток - лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержимое.
Прозрачное согласование
Данное согласование полностью прозрачно для клиента и сервера. В данном случае используется общий кэш, в котором содержится список вариантов, как для управляемого клиентом согласования. Если кэш понимает все эти варианты, то он сам делает выбор, как при управляемом сервером согласовании. Это снижает нагрузки с исходного сервера и исключает дополнительный запрос со стороны клиента.
В основной спецификации по протоколу HTTP механизм прозрачного согласования подробно не описан.
Множественное содержимое
Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы multipart/* . Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа типом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как multipart/mixed .
Параметр boundary означает разделитель между различными типами передаваемых сообщений. Например передаваемый из формы параметр DestAddress передает значение e-mail адреса, а последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения формата.jpg
Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на при запросе нескольких фрагментов ресурса. В этом случае используется медиа тип multipart/byteranges .
Со стороны клиента при отправке HTML -формы чаще всего пользуются методом POST . Типичный пример: страницы отправки электронных писем со вложенными файлами. При отправке такого письма браузер формирует сообщение типа multipart/form-data , интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:
POST /send-message.html HTTP/1.1 Host: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form-data; boundary="Asrf456BGe4h" Content-Length: (суммарный объём, включая дочерние заголовки) Connection: keep-alive Keep-Alive: 300 (пустая строка) (отсутствующая преамбула) --Asrf456BGe4h Content-Disposition: form-data; name="DestAddress" (пустая строка) [email protected] --Asrf456BGe4h Content-Disposition: form-data; name="MessageTitle" (пустая строка) Я негодую --Asrf456BGe4h Content-Disposition: form-data; name="MessageText" (пустая строка) Привет, Василий! Твой ручной лев, которого ты оставил у меня на прошлой неделе, разодрал весь мой диван. Пожалуйста, забери его скорее! Во вложении две фотки с последствиями. --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое первой фотографии) --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Content-Type: image/jpeg (пустая строка) (двоичное содержимое второй фотографии) --Asrf456BGe4h-- (отсутствующий эпилог)
В примере в заголовках Content-Disposition параметр name соответствует атрибуту name в HTML-тегах и
Особенности протокола
Большинство протоколов предусматривают установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies ; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов - в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.
Примечания
См. также
Ссылки
Протокол передачи гипертекста 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 в рубрике 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 протокола :
- HTTP протокол работает по технологии .
- HTTP протокол относится к седьмому уровню .
- HTTP протокол относится к семейству протоколов TCP/IP.
- Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.
- Спецификация протокола RFC 2616.
- Для идентификации ресурса HTTP протокол использует URI (читай про ).
- HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.
- HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили.
Это лишь часть технических характеристик протокола, но на мой взгляд, самых важных характеристик для понимания его сути.
HTTP протокол работает по принципу клиент-сервер
Да, HTTP протокол работает по принципу клиент-сервер. Самый простой пример, что приходит мне сейчас в голову, дабы объяснить суть взаимодействия клиент-сервер, это пример покупателя и продавца в магазине. Покупатель приходит в магазин и говорит продавцу: Здрасти!. Если продавец грубый, он отвечает: забор покрасти!. Дальше покупатель улыбается, стоит, смотрит на витрину и выбирает: чего бы ему купить. А в это время продавец стоит и молчаливо ждет, пока клиент выберет. Клиент сделал выбор и говорит продавцу: а дайте мне вон ту коричневую хрень, что стоит на верхней полке в дальнем углу. Продавец говорит: щас. После чего берет табурет ставит его в дальний угол, снимает с полки коричневую хрень и несет покупателю. Покупатель берет коричневую хрень, отдает деньги и уходит. А продавец, получив деньги, кладет их в кассу.
Суть этой истории в том, чтобы показать взаимодействие клиент-сервер. (в данном случае покупатель) полностью управляет развитием событий, то есть (в нашем примере продавец) ни в коем случае сам не устанавливает контакт, он терпеливо ждет действий клиента и каким-то образом на них реагирует. Я привел самый простой пример. Но его можно и усложнить, например, покупатель дает сто рублей, а коричневая хрень стоит 90, в этом случае продавец даст клиенту сдачу. Продавец мог отреагировать на слова клиента: Здрасти!, как-нибудь по-другому. Или коричневая хрень могла быть не для продажи или для продажи, но только для особых клиентов. Я это веду к тому, что HTTP протокол – это протокол передачи данных основанный на взаимодействие клиент-сервер и он, в принципе, довольно полно описывает алгоритмы действия как для клиента, так и для сервера в различных ситуациях.
История HTTP: стандарты HTTP протокола
Давайте теперь рассмотрим историю HTTP протокола на его стандартах.
- – версия протокола HTTP9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
- В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0).
- В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Кстати, посылая информацию о себе в заголовке.
- 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 сообщения есть тело, то для определения длины сообщения действуют следующие правила по порядку:
- Любое HTTP сообщение ответа сервера, которое не должно включать тело сообщения, всегда должно быть завершено пустой строкой после заголовков.
- Если в заголовках HTTP сообщений присутствует поле Transfer-Encoding (кодирование HTTP) при это у этого поля значение chunked, то длину HTTP сообщения следует определять методом кодирования по кускам (chunked encoding).
- Если у заголовка HTTP сообщения есть поле Content-Length, то значение, которое записано в Content-Length является длиной HTTP сообщения, измеряется в байтах.
- Если HTTP сообщение использует медиа типы «multipart/byteranges», который само разграничен, то он и определяет длину.
- Длина 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
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 протоколе и его описание |
1 | HTTP коды состояний 1xx: информационные Такой код состояния сервер высылает в том случае, когда запрос получен, но еще не обработан. |
2 | HTTP коды состояний 2 xx : успешные Сервер отправит вам такой код в том случае, когда он успешно принял и обработал HTTP сообщение клиента. |
3 | HTTP коды состояний 3 xx : перенаправление Если вы получили от сервера код состояния, начинающийся на тройку, то это означает, что нужны дополнительные действия, чтобы завершить процесс обработки HTTP запроса. |
4 | HTTP коды состояний 4 xx : ошибка клиента Если вы увидели код состояния, который начинается с четверки, то это означает, что произошла ошибка по вине клиента. |
5 | HTTP коды состояний 5 xx : серверная ошибка Код состояния, начинающийся с пятерки, говорит о том, что произошла ошибка на стороне сервера. |
Поля заголовка HTTP сообщения
В протоколе HTTP есть поля заголовка, которые позволяют настроить взаимодействие между клиентом и сервером, а так же то, как и в каком виде полезную информацию будет получать конечный пользователь. Общий синтаксис полей заголовка довольно прост: имяполя: значение1 , значение2
Поля заголовка разделяются между собой символом CRLF. HTTP протокол делит поля заголовка на четыре группы:
- Общие поля заголовка. Такие заголовки могут быть использованы в любых сообщениях, передаваемых по HTTP протоколу.
- Поля заголовка запросов. Эти сообщения могут быть переданы только в запросах HTTP протокола.
- Поля заголовка ответов. Как понятно из названия, эти поля используются только при HTTP ответах.
- Поля заголовка тело сообщения. А эти поля используются тогда, когда необходимо определить, как и в каком виде будет представлена информация конечному пользователю, которая передается по HTTP.
Кэширование HTTP протокола
С целью уменьшения нагрузки на сеть и повышения эффективности HTTP протокола был реализован механизм кэширования. Зачастую бывает так, что пользователь даже не догадывается о том, что страница, открытая в его браузере, подгрузилась не с сайта, к которому он обращался, а из кэша. Мы не будем вдаваться во внутренние механизмы кэширования того или иного сервера/клиента, а лишь посмотрим, что есть непосредственно у протокола HTTP для управления кэшированием. И, как вы наверное уже догадались, в HTTP протоколе кэшированием управляют поля заголовка и директивы, то есть значения этих самых полей.
Отмечу, что HTTP протокол реализован так, что этим директивам должны следовать все участники цепочки между клиентом и конечным сервером. Директивы условном можно поделить на клиентские и серверные. Давайте посмотрим на директивы HTTP протокола, предназначенные для управления кэшированием со стороны клиента.
Номер | Директивы поля заголовка Cache — Control для клиента и их описание |
1 | no — cache Директива HTTP протокола no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера. |
2 | no — store Директива HTTP протокола no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности. |
3 | max — age = seconds Директива HTTP протокола max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах. |
4 | max — stale [ = seconds ] Директива HTTP протокола max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах. |
5 | min — fresh = seconds Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд. |
6 | Директива HTTP протокола min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований. |
7 | only
—
if
—
cached Директива HTTP протокола min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо. |
А теперь взглянем на директивы, позволяющие .
Номер | Директивы поля заголовка Cache — Control для сервера и их описание |
1 | public Директива HTTP протокола Public говорит о том, что ответ сервера можно сохранять в любом кэше. |
2 | private Директива HTTP протокола private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя. |
3 | no — cache Директива HTTP протокола no — cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки. |
4 | no — store Директива HTTP протокола no — store говорит о том, что ответ сервера нельзя сохранять в кэше. |
5 | no — transform Директива HTTP протокола no — transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки. |
6 | must — revalidate Директива HTTP протокола must — revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка. |
7 | proxy — revalidate Директива HTTP протокола proxy — revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов. |
8 | max — age = seconds Директива HTTP протокола max — age говорит о том, сколько живет кэш на сервере. |
9 | Директива поля заголовка Cache — Control ответа сервера: s — maxage = seconds Директива ответа сервера Public говорит о том, что и директива max-age, но для CDN-серверов |
И клиентские, и серверные 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, суть одно и то же).
Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением !
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.
задание название клиента, если есть ограничение для некоторых клиентов.
задание количества одновременно скачиваемых файлов.
Вашему вниманию предлагается описание основных аспектов протокола 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