Эта статья показывает, как однопроцессный сервер может сочетать множество транспортных протоколов. Оговаривается основная идея одновременного использования протоколов TCP и UDP в одном процессе. Также рассматривается концепции реализации серверного ПО для последовательной и параллельной обработки запросов. Объясняется, как один процесс на сервере, может обслуживать несколько интернет-сервисов, даны иллюстрации идеи однопроцессного серверного ПО, обеспечивающего работу множества сервисов в сети. Наконец, представлены варианты использования подобного рода ПО для реальной работы в сети, а также при использовании в учебном процессе. 

Основания для использования

Во многих случаях, сервер обрабатывает запросы для одного определенного сервиса, используя один транспортный протокол. Рассмотрим компьютер, который обслуживает некоторый сетевой сервис, используя две серверных программы: одна обрабатывает UDP запросы, другая TCP запросы.

Главное преимущество такого подхода состоит в упрощенном управлении со стороны администратора системы, он может легко контролировать на каком протоколе будет работать данный сервис, т.к. это определяется запущенными в данный момент серверами. Недостаток такого метода заключается в репликации. Так как ко многим сервисам в сети доступ может быть осуществлен по TCP или UDP протоколу, то для обслуживания такого сервиса требуется два сервера. Более того, эти сервера обычно используют общий алгоритм для вычисления ответа, следовательно, они используют общий код, поэтому разработка и отладка такого ПО не выгодна для программиста. Программист должен быть уверен в идентичности серверных программ при исправлении ошибок или при интегрировании их с системным программным обеспечением. Другой недостаток использования отдельных серверов для разных протоколов состоит в неоправданном растрачивании системных ресурсов. Эта проблема становится еще более наглядной при использовании десятков TCP/IP сервисов для разных протоколов и решается разработкой многопротокольных серверов – программа обслуживающая несколько транспортных протоколов в одном процессе.

Структура многопротокольного серверного программного обеспечения

Многопротокольный сервер состоит из одного процесса, который использую асинхронный метод для обработки соединений по UDP или TCP протоколу. Изначально сервер открывает два сокета: первый использует неориентированный на соединение протокол UDP, второй – ориентированный на соединение протокол TCP. Потом он входит в фазу ожидания, используя асинхронный В/В. Как только активизировался TCP сокет, т.е. клиент запросил TCP соединение, сервер, используя функцию accept, пытается создать соединения для обмена данными. Если активизировался UDP сокет, т.е. клиент послал запрос в форме UDP датаграммы, сервер, использует функцию recvfrom для записи конечного адреса отправителя и при формировании ответа, сервер отсылает его назад клиенту с помощью функции sendto.

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

Многопротокольные сервера при параллельной обработке запросов

Последовательная реализация сервера не всегда может удовлетворять потребностям, особенно если требуется значительное время обработки запросов. В таких случаях разрабатывается многопротокольный сервер для параллельной обработки запросов. Реализовать его можно используя технику создания отдельных процессов для каждого TCP соединения, а UDP запросы обрабатывать последовательно. Также можно использовать однопроцессный вариант исполнения, когда параллельность достигается за счет одновременной обработки TCP и UDP запросов в одном процессе.

Пример использования

Сейчас в интернете в основном используются многопротокольные серверы. Если посмотреть на TCP/IP сервисы [RFC 1060], то видно, что многие из них обслуживают сразу два транспортных протоколов TCP и UDP. Для примера, рассмотрим следующую задачу, которая могла бы использоваться в университете или любом другом учебном заведении:

Предположим, требуется возможность оповещения студентов об их результатах по некоторым дисциплинам. Существует центральный сервер, где запущено серверное приложение, которое занимается проверкой идентичности пользователя и компьютера, с которого он делает запрос. Есть несколько локальных сетей (доверенные хосты) откуда разрешены запросы по данному сервису. При запросе, сервер проверяет IP адрес клиента, используя UDP транспорт, при успешной проверке пользователю предлагается ввести имя и пароль, здесь используется TCP соединение. После успешной авторизации пользователю (студенту) показываются его результаты по дисциплинам. Это все реализовывается с помощью многопротокольного сервера, который обслуживает вышеописанный сервис оповещения результатов студентов.

Описание сервера для обслуживания интернет-сервисов.

Объединение многопротокольного и многосервисного серверов.

В большинстве случаев, программисты разрабатывают для обслуживания каждого сервиса индивидуальный сервер. В предыдущих пунктах было показано реализация односервисного сервера использующего несколько транспортных протоколов. Все преимущества многопротокольного сервера, а именно, упрощенное обслуживание и уменьшение использования системных ресурсов, переносятся и на многосервисный сервер – программа объединяющая обслуживание несколько сервисов (сервер сервисов). Для того, чтобы убедиться в надобности использования многосервисного сервера следует обратить внимание на множество стандартных TCP/IP сервисов. Их существует большое количество, например, для тестирования, отладки и обслуживания компьютерной сети построенной на семействе TCP/IP протоколах. Не имеет смысла для каждого TCP/IP сервиса запускать отдельный сервис, т.к. этот сервис может быть и не востребован. Поэтому, используя сервер сервисов можно существенно уменьшить количество процессов в системе. Более того, много небольших сервисов могут иметь похожие реализации, значит, путем объединения программного кода этих сервисов существенно уменьшается общий код программы.

Ориентированные и неориентированные на соединения сервера

Многосервисный сервер может использовать как ориентированный (TCP), так и неориентированный (UDP) на соединения протокол. Следующие рисунки показывают структуру обоих реализаций.

Рисунок 2.1 показывает последовательный многосервисный UDP сервер, который обычно состоит из одного процесса и кода для каждого поддерживаемого сервиса. Сервер открывает UDP сокет для каждого сервиса и назначает соответствующий ему порт. Каждому дескриптору сокета соответствует процедура обработки сервиса на этом сокете. Используя функцию select, сервер ожидает запросов на любом из сокетов. При получении запроса вызывается соответствующая процедура для обработки запрашиваемого сервиса и посылается ответ.

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

Параллельный и последовательный многосервисный сервер.

Процедура для обработки сервиса может вызываться сразу после получения запроса (последовательный вариант) или же порождается отдельный процесс обслуживания сервиса (параллельный вариант). На самом деле, можно использовать смешанный вариант обработки сервисов – параллельно-последовательный, структура которого приведена на рис. 2.3.

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

Возможен вариант однопроцессного сервера сервисов. Здесь не порождается отдельные процессы для обработки соединений, а добавляется порожденные сокеты этих соединений в набор сокетов сервисов. Т.е. однопроцессный сервер, используя select ожидает запросов на сокетах сервисов и порожденных сокетах соединений. При получении запроса на сокете сервисов, вызывается accept для создания нового соединения. При получении запроса на порожденном сокете, используются read/write для обмена данными с клиентом.

Структура сервера обслуживающего большое количество сервисов

Главным недостатком вышеописанных реализаций сервера сервисов, является потеря универсальности: изменение кода одного из сервисов влечет за собой перекомпиляцию, остановку и перезапуск всего сервера. При небольшом количестве обслуживаемых сервисов это не так критично, но если создается сервер для обслуживания большого числа сервисов, то встает вопрос о его расширяемости и удобном обслуживании. В этом случае сервер разбивается на независимые компоненты в виде отдельных исполняемых программ для каждого сервиса. Рассмотрим структуру такого сервера, показанную на рис 2.4

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

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

Возможные варианты использования

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

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

- David L. Stevens, Douglas E. Comer [1992]. Internetworking with TCP/IP Volume III: Client-Server Programming and Application. Prentice-Hall.

- J.Postel, [RFC 793] Transmission Control Protocol.

- J. Postel, [RFC 768] User Datagram Protocol.

- J.K. Reynolds, J. Postel, [RFC 1010,1060] Assigned Numbers.