Курсовая по кибернетике

1.0
Что такое HTTP
HTTP (
англ. HyperText Transfer Protocol — «протокол передачи гипертекста»)
— протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов). Основой HTTP является технология «клиент- сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков
(
серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола
HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и
SMTP.
Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами
«
запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

1.1
Общая Структура
HTTP основывается на парадигме запросов/ответов. Запрашивающая программа (обычно она называется клиент) устанавливает связь с обслуживающей программой-получателем (обычно называется сервер) и посылает запрос серверу в следующей форме: метод запроса, URI, версия протокола, за которой следует MIME-подобное сообщение, содержащее управляющую информацию запроса, информацию о клиенте и, может быть, тело сообщения. Сервер отвечает сообщением, содержащим строку статуса
(
включая версию протокола и код статуса - успех или ошибка), за которой следует MIME-подобное сообщение, включающее в себя информацию о сервере, метаинформацию о содержании ответа, и, вероятно, само тело ответа. Следует отметить, что одна программа может быть одновременно и клиентом и сервером. Использование этих терминов в данном тексте относится только к роли, выполняемой программой в течение данного конкретного сеанса связи, а не к общим функциям программы.
В Internet коммуникации обычно основываются на TCP/IP протоколах. Для
WWW номер порта по умолчанию - TCP 80, но также могут быть использованы и другие номера портов - это не исключает возможности использовать HTTP в качестве протокола верхнего уровня.
Для большинства приложений сеанс связи открывается клиентом для каждого запроса и закрывается сервером после окончания ответа на запрос. Тем не менее, это не является особенностью протокола. И клиент, и сервер должны иметь возможность закрывать сеанс связи, например, в результате какого- нибудь действия пользователя. В любом случае, разрыв связи, инициированный любой стороной, прерывает текущий запрос, независимо от его статуса.
1.2
Достоинства и недостатки.
Достоинства:
Простота
Протокол настолько прост в реализации, что позволяет с лёгкостью создавать клиентские приложения.
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

Расширяемость
Вы можете легко расширять возможности протокола благодаря внедрению своих собственных заголовков, сохраняя совместимость с другими клиентами и серверами. Они будут игнорировать неизвестные им заголовки, но при этом вы можете получить необходимый вам функционал при решении специфической задачи.
Распространённость
При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.
Недостатки:
Большой размер сообщений
Использование текстового формата в протоколе порождает соответствующий недостаток: большой размер сообщений по сравнению с передачей двоичных данных. Из-за этого возрастает нагрузка на оборудование при формировании, обработке и передаче сообщений. Для решения данной проблемы в протокол встроены средства для обеспечения кэширования на стороне клиента, а также средства компрессии передаваемого контента. Нормативными документами по протоколу предусмотрено наличие прокси-серверов, которые позволяют получить клиенту документ с наиболее близкого к нему сервера. Также в протокол было внедрено дельта-кодирование, чтобы клиенту передавался не весь документ, а только его изменённая часть.
Отсутствие «навигации»
Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него отсутствуют в явном виде средства навигации среди этих ресурсов.
Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Предполагалось, что конечный пользователь уже знает URI необходимого ему документа, закачав который, он будет производить навигацию благодаря гиперссылкам. Это вполне нормально и удобно для человека, но затруднительно, когда стоят задачи автоматической
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы лежит полностью на плечах разработчиков приложений, использующих данный протокол.
Нет поддержки распределённости
Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вообще не приниматься в расчёт. Но в промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается беспомощен. В 1998 году
W3C предложил альтернативный протокол HTTP-NG (англ. HTTP Next
Generation) для полной замены устаревшего с акцентированием внимания именно на этой области[2]. Идею его необходимости поддержали крупные специалисты по распределённым вычислениям, но данный протокол до сих пор находится на стадии разработки.
1.3
Программное обеспечение.
Всё программное обеспечение для работы с протоколом HTTP разделяется на три больших категории:
Серверы как основные поставщики услуг хранения и обработки информации
(
обработка запросов). (Apache, Internet Information Services (IIS), lighttpd, nginx.)
Клиенты — конечные потребители услуг сервера (отправка запроса).
(Internet Explorer, Safari, Opera, Mozilla…)
Прокси для выполнения транспортных служб.( Squid, UserGate, Multiproxy,
Naviscope, Nginx.)
Для отличия конечных серверов от прокси в официальной документации используется термин сервер происхождения (англ. Origin server). Разумеется, один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

2.0 HTTP
запрос.
Обшие сведения
Запрос - это сообщение, посылаемое клиентом серверу.
Первая строка этого сообщения включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса и используемую версию протокола. Для совместимости с протоколом HTTP/0.9, существует два формата HTTP запроса:
Запрос = Простой-Запрос | Полный-Запрос
Простой-Запрос = "GET" SP Запрашиваемый-URI CRLF
Полный-Запрос = Строка-Статус
*(
Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания
) CRLF
[
Содержание-Запроса ]
Строка Статус
Строка Статус начинается со строки с названием метода, за которым следует
URI-
Запроса и использующаяся версия протокола. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и
CR, за исключением заключающей последовательности CRLF.
Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF
Следует отметить, что отличие Строки Статус Полного-Запроса от Строки
Статус Простого- Запроса заключается в присутствии поля Версия-HTTP.
Метод
В поле Метод указывается метод, который должен быть применен к ресурсу, идентифицируемому URI-Запроса. Названия методов чувствительны к регистру. Существующий список методов может быть расширен.
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" | дополнительный - метод
Список методов, допускаемых отдельным ресурсом, может быть указан в поле Заголовок-Содержание "Баллов". Тем не менее, клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса, так как допустимость применения различных методов может динамически изменяться. Если данный метод известен серверу, но не допускается для указанного ресурса, сервер должен вернуть код статуса "405 Method Not Allowed", и код статуса "501 Not
Implemented", если метод не известен или не поддерживается данным сервером. Общие методы HTTP/1.0 описываются ниже.
2.1
Примеры запросов
В данном разделе рассмотрим некоторые http-запросы при помощи программы HTTPDebuggerPro.Ссылка на программу:
(http://www.luxter2.ru/apps/2115-http-debugger-pro-v3.1.html)
Основные особенности программы:
•
Контролирует и отлаживает все исходящие запросы HTTP от браузера (или любой другой отобранная программы) и получает ответы от сервера.
•
Прослеживает полную магистраль и содержание данных HTTP запросов и ответов.
•
Ловит автоматическую переадресацию браузеров.
•
Отслеживает запросы от всех установленных дополнений (Flash, ActiveX и т.п.).
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

•
Анализирует одни и те же страницы во всех современных браузерах одновременно.
•
Измеряет размер и время загрузки ваших веб-страниц, чтобы оптимизировать работу вашего веб-узла.
•
Рассматривайте gzip-ed содержимое.
•
Посматривает информацию, предоставляемую каждым веб-навигатором или любой программой, когда вы посещаете сайт.
•
Анализирует, как работают другие сайты, какие у них особенности.
•
Покажет то, как работает HTTP (полезна в случае программирования и сетевого проекта).
рис. 1 показан интерфейс программы
Описывать программу и её функции в данной курсовой мы не будем.
Воспользуемся только её основными окнами, в которых описываются наши http- запросы.
Get.
Метод GET служит для получения любой информации, идентифицированной
URI-
Запроса. Если URI- Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).
Итак рассмотрим простейший пример HTTP запроса. Если в адресном окошке браузера мы наберем адрес http://yandex.ru, то браузер определит IP адрес сервера yandex.ru и пошлет ему на 80-й порт такой HTTP запрос:
Рис. 2 запрос от клиента GET
Запрос передается в незашифрованном текстовом виде. Самая главная часть запроса расположена в первой строке: Это тип запроса (GET), URL адрес запрашиваемого документа и версия HTTP протокола (HTTP/1.1). Далее перечисляются параметры запроса. Каждая строка соответствует одному параметру. В начале строки идет имя параметра, затем двоеточие и значение параметра. Смысл параметров интуитивно ясен, однако опишем основные из них: Accept - тип данных, которые может принять браузер (в кодировке
MIME). Accept-Language - предпочтительный язык, на котором браузер хочет принять данные. User-Agent - тип программы, которая отослала запрос. Host
- DNS(
или IP) имя хоста к которому адресован запрос. Cookie - кукисы
(
данные, которые были сохранены сервером на локальном диске клиента, при посещении данного хоста прошлый раз). Referer - хост, со странички которого мы отсылаем запрос. Так например если мы находимся на странице http://
narod.ru, и нажимаем там ссылку http://yandex.ru, то запрос будут отправлен хосту yandex.ru, а поле запроса referer будет содержать имя хоста narod.ru.
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

Post.
Метод POST используется для запроса сервера, чтобы тот принял информацию, включенную в запрос, как субординантную для ресурса, указанного в Строке Статус в поле URI-Запроса. Метод POST был разработан, чтобы была возможность использовать один общий метод для следующих функций:
-
Аннотация существующих ресурсов
-
Добавление сообщений в группы новостей, почтовые списки или подобные группы статей
-
Доставка блоков данных процессам, обрабатывающим данные
-
Расширение баз данных через операцию добавления
Запрос POST очень похож на GET, с той лишь разницей что данные в запросе
POST передаются отдельно от самого собственно заголовка запроса. Так приведенный выше пример в варианте POST имеет вид:
Рис. 3 запрос клиента POST
Как мы видим данные о логине и пароле передаются отдельно в теле запроса.
Тело запроса должно отделяться от заголовка пустой строкой. Если сервер встречает пустую строку в POST запросе, то все что идет далее он считает телом запроса (передаваемыми данными). Отметим следующее: формат данных в теле POST запроса произволен. Несмотря на то, что чаще всего применяется CGI формат, он не обязателен. Кроме того POST запрос не требует наличия тела запроса, и может передавать данные также и через URL.
Помимо запросов GET и POST существуют и другие, например TRACE,
PUT.
Но они используются редко, и мы не будем на них останавливаться.
2.2 HTTP
ответ
Структура ответа
После получения и интерпретации запроса, сервер посылает ответ в соответствии со следующей формой:
Ответ = Простой-Ответ | Полный-Ответ
Простой-Ответ = [ Содержание-Ответа ]
Полный-Ответ = Строка-Статус
*(
Общий-Заголовок | Заголовок-Ответа | Заголовок-Содержания) CRLF
[
Содержание-Ответа ]
Простой-Ответ должен посылаться только в ответ на HTTP/0.9 Простой-
Запрос, или в том случае, если сервер поддерживает только ограниченный
PAGE 34
Document shared on www.docsity.com
Downloaded by: vasya-virastyuk (12vasalol@gmail.com)

HTTP/0.9 протокол. Если клиент посылает HTTP/1.0 Полный-Запрос и получает ответ, который не начинается со Строки-Статус, он должен предполагать, что ответ сервера представляет собой Простой-Ответ, и обрабатывать его в соответствии с этим. Следует заметить, что Простой-
Ответ состоит только из запрашиваемой информации (без заголовков) и поток данных прекращается в тот момент, когда сервер закрывает сеанс связи.
Рис. 4 Ответ сервера на запрос клиента
Строка Статус
Первая строка Полного-Запроса является Строкой-Статус, состоящей из версии протокола, за которой следует цифровой код статуса и ассоциированное с ним текстовое предложение. Все элементы Строки-Статус разделены пробелами. Не разрешены символы CR и LF, за исключением завершающей последовательности CRLF.
Строка-Статус= Версия-HTTP SP Статус-Код SP Фраза-Об'яснение.
Так как Строка-Статус всегда начинается с версии протокола "HTTP/"
1*
ЦИФРА "." 1*ЦИФРА (например HTTP/1.0), существование этого выражения рассматривается как основное для определения того, является ли ответ Простым-Ответом, или Полным-Ответом.
Статус-Код и пояснение к нему
Элемент Статус-Код представляет собой 3-х цифровой целый код, идентифицирующий результат попытки интерпретации и удовлетворения запроса. Фраза-Об'яснение, следующая за ним, предназначена для краткого текстового описания Статус-Кода. Статус-Код нацелен на то, чтобы его использовала машина, а Фраза-Объяснение предназначена для человека.
Клиент не обязан исследовать и выводить на экран Фразу-Объяснение.
Первая цифра Статус-Кода предназначена для определения класса ответа.
Последние две цифры не выполняют никакой категоризирующей роли.
Существует 5 значений для первой цифры:
1xx:
Информационный - Не используется, но зарезервирован для использования в будущем
2x
х: Успех - Запрос был полностью получен, понят, и принят к обработке.
3xx:
Перенаправление - Клиенту следует предпринять дальнейшие действия для успешного выполнения запроса. Необходимое дополнительное действие иногда может быть выполнено клиентом без взаимодействия с пользователем, но настоятельно рекомендуется, чтобы это имело место только в тех случаях, когда метод, использующийся в запросе безразличен (GET или HEAD).