Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

Сегодня всё более важным и необходимым ресурсом становится информация. Благодаря интернету мы можем получать интересующую нас информацию в кротчайшие сроки. Но за процессом получения нами информации скрывается множество действий. Одним из важнейших действий является работа протоколов передачи информации. Только благодаря им вообще возможна передача какой-либо информации по сети. Эти протоколы разбиваются на уровни. Всего их семь. В данной курсовой работе будет рассмотрен самый верхний уровень – прикладной. Он служит для передачи информации конкретным клиентским приложениям, запущенным на сетевом компьютере.

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

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

Цель курсовой работы – исследовать прикладные протоколы и серверы приложений.

Задача курсовой работы:

Исследовать сетевую модель OSI и назначение прикладного уровня в ней;
Проанализировать структуру ряда прикладных протоколов;
Рассмотреть понятие и виды серверов приложений.

Вопросам исследования систем приложений и прикладных протоколов передачи информации посвящены работы таких авторов как: Таненбаум Э., Филимонов А., Грегер С. и других.

Данная курсовая работа состоит из введения, трёх глав, заключения, списка использованных источников.

Список использованных источников включает 6 трудов различных авторов. Данные источники представляются надёжными, так как они изданы известными издательствами, размещены на сайтах электронных библиотек ВУЗов России, рекомендованы методическими указаниями по изучению дисциплины «Распределенные системы обработки информации».

1 Прикладной уровень в сетевой модели OSI

Сетевая модель – это модель взаимодействия сетевых протоколов [1].

Для единого представления данных в сетях с неоднородными устройствами и программным обеспечением международная организация по стандартам ISO (International Standardization Organization) разработала базовую модель связи открытых систем OSI. Данную модель можно назвать стандартом. Именно согласно этой модели, руководствуются производители сетевых устройств при разработки новых продуктов.

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

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

Модель описывает только системные средства взаимодействия, ни коем образом, не затрагивая пользовательские приложения. Приложения в свою очередь разрабатывают свой протоколы, основываясь на системных средствах.

Любая информация перед передачей в сети разбивается на пакеты. Пакет – единица информации, передаваемая по сети [3].

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

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

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

Сетевая модель OSI состоит из следующих уровней [1]:

Прикладной – представляет набор интерфейсов, позволяющих получить доступ к сетевым службам;
Уровень представления – преобразует данные в общий формат для передачи по сети;
Сеансовый – поддерживает взаимодействие (сеанс) между удалёнными процессами;
Транспортный – управляет передачей данных по сети, обеспечивает подтверждение передачи;
Сетевой – маршрутизация, управление потоками данных, адресация сообщений для доставки. Преобразование логических сетевых адресов и имён в соответствующие им физические;
Канальный – делится на два подуровня:
- Контроль логической связи (LLC) – формирование кадров;
- Контроль доступа к среде (MAC) – управлением доступом к среде;
Физический уровень – обеспечивает битовые протоколы передачи информации.

Рис. 1. Схема уровней сетевой модели OSI

Рассмотрим более детально прикладной уровень.

Прикладной уровень – набор разнообразных протоколов, благодаря которым пользователи могут получить доступ к разделяемым ресурсам, таким как файлы, принтеры или web-странницы, а также организуют совместную работу, к примеру, с помощью почтового протокола [4].

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

Функции, присущие прикладному уровню [3]:

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

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

Таким образом, прикладной уровень является самым верхним (седьмым) уровнем в сетевой модели OSI и тесно связан непосредственно с пользовательскими приложениями, позволяя получать доступ к разделяемым ресурсам.

2 Протоколы прикладного уровня

2.1 Протокол FTP

FTP (File Transfer Protocol) – стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет) [2].

FTP выделяется среди других протоколов тем, что для передачи файлов он использует два TCP соединения [3]:

Управляющее соединение устанавливается как обычное соединение клиент-сервер. Сервер осуществляет пассивное открытие на заранее известный порт FTP (21) и ожидает запроса на соединение от клиента. Клиент осуществляет активное открытие на TCP порт 21, чтобы установить управляющее соединение. Управляющее соединение существует все время, пока клиент общается с сервером. Это соединение используется для передачи команд от клиента к серверу и для передачи откликов от сервера. Тип IP сервиса для управляющего соединения устанавливается для получения "минимальной задержки", так как команды обычно вводятся пользователем;
Соединение данных открывается каждый раз, когда осуществляется передача файла между клиентом и сервером. (Оно также открывается и в другие моменты, как мы увидим позже.) Тип сервиса IP для соединения данных должен быть "максимальная пропускная способность", так как это соединение используется для передачи файлов.

Рис. 2. Процессы, участвующие в передаче фалов

Работа FTP на пользовательском уровне состоит из нескольких этапов [4]:

Идентификация (ввод имени-идентификатора и пароля);
Выбор каталога;
Определение режима обмена (поблочный, поточный, ASCII или двоичный);
Выполнение команд обмена (get, mget, dir, mdel, mput или put);
Завершение процедуры (quit или close).

Протокол FTP поддерживает различные способы управление передачей и хранение файлов. Перед непосредственным использованием протокола необходимо сделать выбор по четырём пунктам [2].

Тип файла;
1. ASCII файлы (По умолчанию) - текстовый файл передается по соединению данных как NVT ASCII. При этом требуется, чтобы отправитель конвертировал локальный текстовый файл в NVT ASCII, а получатель конвертировал NVT ASCII в текстовый файл. Конец каждой строки передается в виде NVT ASCII символа возврата каретки, после чего следует перевод строки. Это означает, что получатель должен просматривать каждый байт в поисках пары символов CR, LF;
2. EBCDIC файлы - альтернативный способ передачи текстовых файлов, когда на обоих концах системы EBCDIC;
3. Двоичные или бинарные файлы - данные передаются как непрерывный поток битов;
4. Локальный тип файлов - способ передачи бинарных файлов между хостами, которые имеют различный размер байта. Количество битов в байте определяется отправителем. Для систем, которые используют 8-битные байты, локальный тип файла с размером байта равным 8 эквивалентен бинарному типу файла.
Управление форматом. Применим только для файлов типа ASCII и EBCDIC;
1. Nonprint (По умолчанию) - файл не содержит информацию вертикального формата;
2. Telnet format control - файл содержит управляющие символы вертикального формата Telnet, которые интерпретируются принтером;
3. Fortran carriage control - первый символ каждой строки это Fortran символ управления формата.
Структура;
1. Структура файла (По умолчанию) - файл воспринимается в виде непрерывного потока байтов. Файл не имеет внутренней структуры;
2. Структура записи - эта структура используется только в случае текстовых файлов (ASCII или EBCDIC);
3. Структура страницы - каждая страница передается с номером страницы, что позволяет получателю хранить страницы в случайном порядке.
Режим передачи. Указывает на то, как файл передается по соединению данных.
1. Режим потока (По умолчанию) – файл передается как поток байтов. Для файловой структуры конец файла указывает на то, что отправитель закрывает соединение данных. Для структуры записи специальная 2-байтовая последовательность обозначает конец записи и конец файла;
2. Режим блоков – файл передается как последовательность блоков, перед каждым из них стоит один или несколько байт заголовков;
3. Сжатый режим – простое кодирование неоднократно встречающихся повторяющихся байт. В текстовых файлах обычно сжимаются пустые строки или строки из пробелов, а в бинарных - строки из нулевых байт.

В итоге выходит весьма внушительное количество вариации передачи и хранения данных.

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

2.2 Протоколы SMTP и POP3

Простой протокол передачи почты (Simple Mail Transfer Protocol) – протокол, используемый для обмена почтовыми сообщениями в сети Internet [1].

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

Рис. 3. Схема взаимодействия по протоколу SMTP

Канал связи устанавливается непосредственно между отправителем и получателем, что позволяет выполнять доставку почты в течении нескольких секунд после её отправки.

Но организация работы с почтой используя только данный протокол влечёт за собой некоторые проблемы.

Основной проблемой является необходимость постоянной работы компьютера клиента для получения сообщений. Иначе сообщение не будет доставлено.

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

Но SMTP не позволяет добиться такого функционала. Поэтому для реализации такой схемы используется протокол POP (Post Office Protocol).

В настоящее время существуют две версии протокола POP - РОР2 и РОРЗ, обладающими примерно одинаковыми возможностями, однако несовместимыми друг с другом. Дело в том, что у РОР2 и РОРЗ разные номера портов протокола. Между ними отсутствует связь, аналогичная связи между SMTP и ESMTP. Протокол РОРЗ не является расширением или модификацией РОР2 – это совершенно другой протокол.

Рис. 4. Схема работы с почтовым сервером

В протоколе POP3 предусмотрено 3 состояния сеанс [3]:

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

Несмотря на то, что протокол РОР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]:

Стартовая строка (Starting line) — определяет тип сообщения;
Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
Тело сообщения (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]:

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

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

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

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

2.4 Протокол TELNET

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

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

Основой протокола является три базовые концепции [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]:

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

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

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

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

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

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <—> контейнер сервлетов <—> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь — через веб-сервер.

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

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

Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории [4]:

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

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) — технология доступа к приложениям через веб-сервер [5]. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM).

Контейнер сервлетов — один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов [6]. Сервлет — это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

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

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии .NET Framework. Основным средством разработки является язык C#.

Язык Python, получивший популярность во многом благодаря Google, является основным средством разработки для сервера веб-приложений Zope.

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

В серверах приложениях выделяют следующие преимущества [5]:

Целостность кода и данных. Размещение бизнес-логики на выделенном сервере или ограниченном числе серверных компьютеров гарантирует доступ к обновленному и модернизированному ПО для всех клиентов. Это исключает риск доступа и управления данными из устаревших и, возможно, несовместимых программ.
Централизованное управление. Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.
Безопасность. Централизованные средства, через которые поставщик услуг (сервис-провайдер) может управлять доступом к данным и компонентам приложения, позволяют выполнять проверку подлинности потенциально ненадежных клиентов в среднем слое и не затрагивать уровень базы данных.
Производительность. Сервер приложений может решать задачи балансировки сетевого трафика и распределения нагрузки между другими физическими серверами системы.
Общая стоимость владения. Совокупность перечисленных выше преимуществ, а в дополнение к ним перераспределение затрат на оборудование с клиентской на серверную сторону, может привести к экономии средств для организации. Так же на снижении общей стоимости владения может отразиться практика аренды программного обеспечения. Справедливости ради нужно отметить, что стоимость самого серверного ПО, а также затраты на его внедрение и сопровождение могут быть весьма высокими.

Но также выделяют и ряд недостатков [5]:

Централизация. Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям — «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении.
Защита информации. Эта проблема, в принципе, актуальна для любых сетевых решений, использующих для передачи данных инфраструктуру публичных сетей.

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

ЗАКЛЮЧЕНИЕ

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

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

Прикладной протокол FTP является одним из основных при передачи какой-либо информации. Он является крайне функциональным инструментом для обмена файлов различного типа и позволяет организовать процесс передачи данных огромным количеством способов.

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

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

Благодаря протоколу TELNET существует возможность удалённого управления. Хоть он и является одним из самых старых информационных технологий Интернет, всё ещё активно используется. Но из-за неимения никакой защиты соединения, данный вид протокола перестал использоваться как средство управления операционными системами.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Александер Б., Аллен Т. Руководство по технологиям объединенных сетей. 4-е изд. — М.: Вильямс, 2005. – 342 с.
Грегер С. Сервер приложений "Zope". Учебное пособие для вузов. М.: Горячая линия-Телеком, 2009. – 412 с.
Таненбаум Э., Стеен ван М., Распределенные системы / Э. Таненбаум, М. Ван Стеен. – Спб.: BHV, 2003. – 877 с.
Филимонов А. Построение мультисервисных сетей Ethernet. — М.: BHV, 2007. – 592 с.
Хомоненко А. Д., Базы данных / Под ред. проф. Хомоненко А.Д. – 6-е изд. – М: БИНОМ-Пресс; Спб., КОРОНА, 2007. – 736 с.
Хеффельфингер Д. Java EE 7 и сервер приложений GlassFish 4. М.: Издательство ДМК, 2016. – 367 с.