Файл: Понятие прикладных протоколов и серверы приложений(Прикладной уровень в сетевой модели OSI).pdf

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

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

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

2.3 Протокол HTTP

HTTP (Hyper Text Transfer Protocol) – протокол передачи данных (изначально только в виде HTML гипертекстовых документов, в настоящий момент – для произвольных данных) [4]. Основой протокола является технология «клиент-сервер», то есть предполагается существование [1]:

• Потребителей (клиентов), которые инициируют соединение и посылают запрос;
• Поставщиков (серверов), которые ожидают соединения для принятия запроса, выполняют необходимые действия и возвращают сообщение с результатом.

Данный протокол прежде всего ориентирован на предоставление информации программам просмотра веб-страниц, веб-браузерам, наиболее известными из которых являются такие приложения, как Microsoft Internet Explorer, Google Chrome, Mozilla Firefox.

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

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке [3]:

1. Стартовая строка (Starting line) — определяет тип сообщения;
2. Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
3. Тело сообщения (Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа.

---

Последняя часть стартовой строки — это версия HTTP.

Указание версии является скорее справочной информацией для сервера, нежели жестким указанием версии на которой нужно работать. Получая запрос сервер сравнивает свою версию с клиентской и определяет какой вид и какие правила оформления ответа следует использовать. Например, на сервере установлена версия 1.0, а в запросе указана версия 1.1. В таком случае сервер ответит в формате 1.0, это нормально, ведь более новая версия поддерживает более старые.

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

Заголовки делятся на 4 группы [3]:

• Основные заголовки — обязательно включаются в любое сообщение клиента и сервера;
• Заголовки запроса — можно встретить только в запросах от клиента;
• Заголовки ответа — можно встретить только в ответах от сервера;
• Заголовки сущности — описывают сущность каждого сообщения (может относиться как к клиенту, так и к серверу).

Основные заголовки:

• Cache-Control — параметры управления кэшированием.
• Connection — информация о соединении.
• Date — дата создания сообщения.
• Pragma — специфические опции для выполнения.
• Transfer-Encoding — перечень кодировок, применённых для формирования сообщения.
• Upgrade — перечень протоколов, с которыми может работать клиент. Сервер указывает один.
• Via — история прохождения запроса через прокси сервера, с указанием версии протокола.

Заголовки запроса:

• Accept — перечень форматов, с которыми работает ресурс. Остальные игнорируются.
• Accept-Charset — список кодировок с которыми может работать клиент.
• Accept-Encoding — список кодировок, применяемых при кодировании сущности при передаче.
• Accept-Language — перечень языков, с которыми может работать клиент.
• Host — указание доменного имени и порта хоста для запрашиваемого ресурса. Нужно для работы виртуальных хостингов.
• Max-Forwards — указывает предельное кол-во переходов по Proxy серверам.
• Referer — указывает URI ресурса, с которого клиент сделал запрос.
• User-Agent — перечень названий и версий компонентов системы клиента.

Заголовки ответа:

• Location — указывает URI ресурса или URI, на который нужно перейти.
• Public — перечисляет доступные методы, подобно Allow, но для всего сервера.
• Server — перечень названий и версий ПО на сервере, для прокси это поле Via.

Заголовки-сущности:

• Content-Encoding — указывает способ кодирования сущности.
• Content-Language — язык содержимого.
• Content-Length — размер сообщения выраженный в октетах.
• Content-Location — резервное расположение сущности.
• Content-MD5 — MD5-хэш для проверки целостности полученных данных.
• Content-Type — способ и формат отображения сущности.
• Link — ссылка на связанный с сущностью ресурс.
• Title — заголовок сущности.
• Allow — перечень методов, поддерживаемых именно этим ресурсом.

---

Метод HTTP (HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом [1]. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами.

В HTTP выделяют несколько методов [4]:

1. OPTIONS – используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.
2. GET – используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
3. HEAD – аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
4. POST – применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
5. PUT – применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content).
6. PATCH – аналогично PUT, но применяется только к фрагменту ресурса.
7. DELETE – удаляет указанный ресурс.
8. TRACE – возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
9. CONNECT – преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси.

Также одной из составляющих HTTP протокола являются коды сосотяний. Они используются для определения состояния запроса, разделены на 5 групп. Каждая группа имеет собственный «общий смысл» [3]:

• 1xx — информационные. Они описывают процесс передачи.
• 2xx — успешные. Эти говорят нам об успешной передаче.
• 3xx — перенаправленные. Эти же сигнализируют о перенаправлении запроса.
• 4xx — ошибка клиента. Ошибки в запросе, синтаксисе, хосте обращения и т.д.
• 5xx — ошибка сервера. Ошибки в выполнении запроса, связанные с сервером.

---

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

2.4 Протокол TELNET

TELNET – сетевой протокол, позволяющий установить TCP-соединение с сервером и передавать ему коды нажатия клавиш так, как если бы работа проводилась на консоли сервера [4]. Данный протокол служит для выполнения удалённого доступа к вычислительным ресурсам и базам данных.

Рис. 5. Схема клиент-сервера для TELNET

Основой протокола является три базовые концепции [3]:

1. Концепция «Сетевого Виртуального Терминала»;
2. Принцип согласования параметров;
3. Симметрия терминалов и процессов.

Когда устанавливается соединение, предполагается, что оно начинается и завершается на "Сетевом Виртуальном Терминале" (Network Virtual Terminal, NVT). NVT – это воображаемое устройство, которое создает промежуточное стандартное представление канонического терминала [2]. NVT является стандартным описанием наиболее широко используемых возможностей реальных физических терминальных устройств. NVT позволяет описать и преобразовать в стандартную форму способы отображения и ввода информации.

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

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

В качестве альтернативы можно считать "пользовательским" тот узел, который инициирует соединение.

Рис. 6. Схема работы NVT

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

---

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

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

Таким образом, протокол TELNET хоть и является одним из самых старых информационных технологий Интернет, позволяет решать сегодняшние проблемы удалённого управления.

3 Серверы приложений

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

Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере [5].

Рис. 7. Модель «сервер приложений»

Данная модель включает следующие уровни [6]:

1. Первый уровень, интерфейсный, как правило, графический (GUI).
2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.
3. Третий уровень, фоновый — базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.

В сетевой среде сервер приложений является посредником между фронт-эндами клиентов и серверами баз данных.

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например, javascript, апплеты, flash).

---