Протокол HTTP





HTTP (HyperText Transfer Protocol—«протокол передачи гипертекста»)—протокол прикладного уровня передачи данных, основанный на технологии «клиент-сервер». т.е. предполагается наличие клиентов, инициирующих соединение, посылающих запросы, и серверов, которые обрабатывают данные запросы, производят необходимые действия, и возвращающие обратно сообщение с результатом.
Объект манипуляции в протоколе HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Часто такими ресурсами могут быть файлы на сервере, а также логические объекты, или что-то абстрактное. Особенность HTTP в том, что интерпретация ресурса может быть определена с помощью HTTP-заголовка. С его помощью определяется язык, формат, кодировка и т.д. передаваемых данных, поэтому с помощью протокола можно обмениваться и двоичными данными, хотя изначально он являлся текстовым.
HTTP—протокол прикладного уровня, как FTP и SMTP. Обмен информацией идет по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов используются глобальные URI. В отличие от многих других протоколов HTTP не сохраняет своего состояния. Сам протокол не осведомлен о предыдущих запросах и ответах. Данную функцию могут осуществлять его компоненты («куки» клиента, «сессии» на сервере).

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

Недостатки
Недостатком протокола является избыточность передаваемой информации, и как следствие, большой размер сообщений по сравнению с передачей двоичных данных. Это нивелируется внедрением кэширования на стороне клиента, компрессии передаваемых данных от сервера. Также улучшает ситуацию использование прокси-серверов, позволяющих передавать информацию клиенту с наиболее близкого сервера, diff-кодирование, благодаря которому клиенту передается не весь объем данных, а только измененная их часть.
Также у недостаткам стоит отнести отсутствие навигации. У протокола отсутствую средства навигации среди ресурсов сервера. Клиент не может, как в FTP запросить список доступных файлов. Протокол предполагает, что пользователю уже известен URI интересующего его ресурса. Эта особенность достаточно прозрачна для пользователя, но неудобна для приложения, которому это иногда требуется. Разработчиками это решается вводом дополнительных компонентов. Со стороны клиента это может быть например веб-паук, проходящий по всем гиперссылкам документа, и собирающий данную информации. Со стороны сервера это например, карта сайта—специальная страница с перечислением доступных клиенту ресурсов. Карта сайта может использоваться как пользователем, так и роботами-пауками поисковых систем, уменьшая для них глубину просмотра—минимально необходимое количество переходов с главной страницы. Аналогичную функцию выполняют и файлы sitemap, но только для приложений. Данная проблема полностью решена в протоколе более высокго уровня WebDAV с помощью добавленного метода PROPFIND, который позволяет получить не только дерево каталогов, но и список параметров каждого ресурса.
Также недостатком HTTP является отсутствие поддержки распределенности. При решении ресурсоемких задач, требующих массу запросов, он становится беспомощен, т.к. сервер перестает справляться с нагрузкой.
Программное обеспечение
Все ПО для работы с HTTP классифифцируется на три категории:
Серверы—поставщики услуг, обрабатывающие запросы
Клиенты—конечные потребители
Прокси—выполнение траснпортных услуг.

Клиенты
Основными клиентами HTTP являются обычные браузеры: IE, Google Chrome, Mozilla Firefox, Opera, Safari. Существуют также т.н. «офлайн-браузеры» для просмотра сохраненного содержимого без подключения к интернет: Offline Explorer, HTTrack. Иногда клиентом выступают обычные приложения, скачивающие свои обновления. Некотрые программы (Gogle Earth) также используют HTTP. Кроме того, целый класс клиентов используется поисковыми системами для создания собственных индексов: это т.н. «веб-пауки», которые собирают исходную информацию для индексов.
Серверы
Самые распространенные: Apache, nginx, Internet Imformation Services (IIS), lighttpd
Прокси
Usergate,Nginx, Squid

Структура протокола
Каждое сообщение состоит из трех частей:
1. Стартовая строка, определяющая тип сообщения
2. Заголовки, характеризующие тело сообщения, параметры передачи и прочие сведения
3. Тело сообщения-данные

Стартовая строка
Различаются для запроса и ответа. Строка запроса выглядит так:
Метод URI HTTP/Версия
Метод—название запроса
URI-идентификатор ресурса
Версия –пара арабских цифр, разделенных точкой

Стартовая строка сервера имеет следующий формат:
HTTP/Версия КодСостояния Пояснение
Здесь
Версия—как и в запросе клиента пара арабских цифр разделенных точкой
КодСостояния (код статуса)—три арабские цифры, определяющие дальнейшее содержимое ответа и поведение клиента
Пояснение—текстовое пояснение к коду ответа пользователя. Является необязательным.
Методы
Метод HTTP это последовательность любых символов, указывающая на основную операцию над ресурсом. Каждый сервер должен поддерживать минимум два метода: GET и HEAD. Если сервер не распознал запрашиваемый метод, он должен вернуть статус 501 (Not Implemented). Если метод известен серверу, но к данному ресурсу неприменим, сервер возвращает сообщение с кодом 405 (Method Not Allowed). Еще один распространенный метод-POST.
OPTIONS
Используется для определения возможностей сервера, или параметров соединения. В ответ сервер включает заголовок Allow со списком поддерживаемых методов.
GET
Запрашивает содержимое указанного ресурса. Используется также для инициации какого-либо процесса. Во втором случае сервер должен в ответном сообщении вклюает информацию о ходе выполняемого процесса.
HEAD
Аналогичен GET, за исключением того, что в ответе сервера отсутствует тело. Применяется для извлечения метаданных, проверки изменения ресурса, и его наличия.
POST
Применяется для передачи данных пользователя к заданному ресурсу. Как, например, в блогах, пользователь комментирует пост, и введенная им информация с помощью метода POST передается серверу, и обрабатывается. В отличие от GET данный метод не считается идемпотентным, т.е. многократное повторение запросов POST может возвращать различные результаты (например после каждой отправки комментария будет появляться его одна копия на сервере). Сервер в тело ответа при результатах 200(Ok) и 204 (No Content) включает сообщение об итоге выполнения запроса. Если создается ресурс, сервер возвращает ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
PUT
Загружает содержимое запроса на указанный URI. Если ресурса не существовало, ервер создает его и возвращает 201(Created). Если ресурс существовал, сервер возвращает 200(Ok) или 204(No Content). Фундаментальное отличие PUT и POST заключается в следующем: в методе PUT агент пользователя знает, какой URI применить, и сервер не должен пытаться послать запрос другому ресурсу, в отличие от метода POST.
PATCH
Аналогичен PUT, но применяется только к фрагменту ресурса.
DELETE
Удаляет ресурс
TRACE
Возвращает полученный запрос так, что клиент видит, как сервер(ы) модифицируют запрос.
LINK
Устанавливает связь указанного ресурса с другим.
UNLINK
Удаляет связь указанного ресурса с другим.
CONNECT
Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через не шифрованный прокси.

Запись опубликована в рубрике Общее. Добавьте в закладки постоянную ссылку.

Добавить комментарий