Министерство образования и науки Российской Федерации

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ (ТГУ)

Факультет Информатики

Кафедра теоретических основ информатики

УДК 681.03

ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

Зав. кафедрой, доцент, канд. тех. Наук

_______________________Фукс А. Л.

«____»_________________2013 г.

КВАЛИФИКАЦИОННАЯ РАБОТА БАКАЛАВРА

Реализация Front-End сервера для проекта VDOM

Кривчиков Иван Сергеевич

Руководитель ВКР, ассистент

Кафедры ТОИ

____________ М.С.Овсянников

подпись

«_____»__________2013 г.

Автор работы

студент группы № 1491

_____________ И.С.Кривчиков

подпись

Электронная версия бакалаврской работы Администратор электронной

помещена в электронную библиотеку. библиотеки факультета

_____________ Е.Н.Якунина

подпись

Томск 2013

2

Реферат

Выпускная квалификационная работа 41 с., 13 рис., 28 ист., 1 прил.

СЕРВЕРНАЯ АРХИТЕКТУРА, FRONT-END СЕРВЕР, ВЫСОКОНАГРУЖЕННЫЕ

СИСТЕМЫ, VDOM BOX

Цель работы: реализация Front-End сервера для платформы VDOM.

Результат работы: спроектирована и реализован специализированный Front-End сервер для

платформы VDOM с использованием механизма автоматического портирования Python кода в

нативный.

3

Оглавление

Введение ........................................................................................................................................................... 4

1 Технологии построения серверной архитектуры веб-приложений ..................................................... 5

1.1 Требования по поддержке протокола HTTP веб-серверами ........................................................ 5

1.1.1 Поддержка постоянных (Keep-Alive) соединений ................................................................. 5

1.1.2 Поддержка кэширования ........................................................................................................ 6

1.1.3 Поддержка компрессии данных ............................................................................................. 6

1.1.4 Поддержка конвейерной обработки (HTTP pipelining) ......................................................... 7

1.1.5 Поддержка сообщений с комбинированным типом содержимого (multipart types) ........ 7

1.2 Обзор существующих моделей работы веб-серверов ................................................................... 8

1.2.1 Блокирующие сервера .............................................................................................................. 8

1.2.2 Неблокирующие сервера ......................................................................................................... 9

1.3 Обзор существующих серверных архитектур ............................................................................. 10

1.3.1 Одноуровневая серверная архитектура ............................................................................... 10

1.3.2 Двухуровневая серверная архитектура ................................................................................ 12

1.4 Обзор существующих Front-End серверов ................................................................................... 14

1.5 Обзор платформы VDOM ............................................................................................................... 15

1.6 Обзор компиляторов Python в нативный код .............................................................................. 16

2 Проектирование Front-End сервера для проекта VDOM .................................................................... 20

2.1 Сервер VDOM Server ....................................................................................................................... 20

2.2 Переход от одноуровневой сетевой архитектуры к двухуровневой ......................................... 22

2.3 Обновление правил обработки запросов .................................................................................... 24

2.4 Повышение производительности FE сервера .............................................................................. 25

3 Проксирующий Front-End сервер для проекта VDOM ....................................................................... 28

3.1 Архитектура сервера ...................................................................................................................... 28

3.2 Обработка запроса .......................................................................................................................... 31

3.3 Тестирование .................................................................................................................................. 33

Заключение ..................................................................................................................................................... 35

Литература ...................................................................................................................................................... 36

Приложение А. (руководство программиста) ............................................................................................. 38

4

Введение Проект VDOM (Visual Dynamic Object Model, визуальная динамическая объектная

модель) имеет в своем составе сервер VDOM Server. Это монолитный сервер, написанный на

языке Python и сочетающий в себе функции веб-сервера и специализированного сервера

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

потребление большого количества системных ресурсов при высоких нагрузках (большом

количестве одновременно обратившихся клиентов).

Стандартным решением подобных проблем является введение в серверную

архитектуру Front-End (FE) веб-сервера. Все сервера, которые раньше присутствовали в

серверной архитектуре, становятся Back-End (BE) серверами. На FE сервер полностью

перекладывается непосредственное взаимодействие с клиентами по HTTP: принятие

запросов, отправка ответов.

В качестве FE серверов можно использовать любой из множества уже готовых веб-

серверов. Более того, часть веб-серверов изначально создавалась для этого. Однако, все они

рассчитаны на как можно более универсальное применение и не учитывают особенностей

рассматриваемой платформы VDOM.

С учетом всего вышесказанного, целью данной ВКР является создание FE-сервера,

который бы инкапсулировал в себе обслуживание клиентов по протоколу HTTP,

минимизировал количество запросов к Back-End серверам, учитывал специфику и

эффективно использовал особенности имеющейся инфраструктуры VDOM.

Для достижения поставленной цели необходимо решить ряд задач:

• Выделить требования к веб-серверам в части оптимизации обмена по проколу HTTP.

• Рассмотреть принципы работы двухуровневой серверной архитектуры

• Проанализировать принципы функционирования веб-серверов и Front-End серверов в

частности.

• Найти способы повышения производительности существующего кода Front-End

сервера на языке Python, путем автоматической трансляции в нативный код.

• Спроектировать механизм взаимодействия разрабатываемого Front-End сервера с уже

имеющимися Back-End серверами проекта VDOM.

5

1 Технологии построения серверной архитектуры веб-приложений

Одной из основных задач серверной части любого веб-приложения является обмен с

клиентом по протоколу HTTP. Для решения этой задачи предназначен целый класс

программ, называемых веб-серверами. Однако, выбор конкретного веб-сервера, его

настройка и интеграция с остальными компонентами серверной архитектуры существенно

влияют на эффективность обмена HTTP сообщениями. В данной главе рассматриваются

назначение и принципы построения FE веб-серверов. FE сервер, как и любой другой веб-

сервер, должен решать как минимум две задачи: управление TCP соединениями и поддержка

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

решения как независимые.

Данная работа ориентирована на построение Front-End сервера конкретно для

совместной работы с сервером приложений VDOM, поэтому в этой главе будет дан краткий

обзор платформы VDOM.

1.1 Требования по поддержке протокола HTTP веб-серверами

Поддержка HTTP в большей степени следует стандарту [1] и не имеет каких-то

устоявшихся, широко используемых способов реализации. Максимально простая реализация

веб сервера должна поддерживать не весь стандарт, а только те его положения, которые

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

не представляет особого интереса в рамках данной работы. Более современный и

функциональный веб-сервер должен поддерживать дополнительные возможности протокола,

на которых стоит остановиться подробнее:

1.1.1 Поддержка постоянных (Keep-Alive) соединений

В версии 0.9 протокола HTTP, для каждого цикла передачи запроса и ответа

создавалось новое TCP соединение. TCP соединение устанавливается через процедуру

«тройного рукопожатия», при которой клиент и сервер должны два раза ожидать прихода

пакета с флагами. Т.е. обслуживание каждого запроса сопряжено с большими тратами

времени на установление соединения. Если учесть, что HTML страницы современных веб-

приложений требуют загрузки множества сопутствующих ресурсов (таблицы CSS,

изображения, клиентские скрипты и т.п.), то отображение страницы у клиента будет

происходить с существенной задержкой.

Для решения этой проблемы, стандарт HTTP 1.0 рекомендовал использовать

постоянные (Keep-Alive) соединения. Это обычное TCP соединение, которое используется

для обслуживания всех запросов одного конкретного клиента. Такое соединение разрывается

6

по инициативе одной из сторон (клиента или сервера), а не после каждого запроса. Для

установления постоянного соединения клиент должен передать запрос с заголовком

Connection: Keep-Alive, а сервер должен ответить на него с тем же заголовком Connection:

Keep-Alive. Разорвать постоянное соединение могут как сервер, так и клиент, послав

заголовок Connection: Close. Стандарт HTTP 1.1 сделал обязательным использование

постоянных соединений. Однако, браузеры до сих пор включают заголовок Connection:

Keep-Alive в свои запросы, на всякий случай. Более подробно все преимущества данного

подхода описаны в работе [2].

1.1.2 Поддержка кэширования

Чисто технически, сервер может кэшировать запрашиваемые ресурсы, но протокол

HTTP никак не регламентирует этот процесс. Так что, если сервер и кэширует какие-то

ресурсы, то этот процесс управляется настройками самого сервера и работающего на нем

веб-приложения. Зато, стандарт HTTP описывает процесс управления кэшем прокси-

серверов и клиентов. Веб-сервер, хотя и не владеет этими видами кэша, играет большую

роль в процессе управления ими. Сервер включает в ответ заголовки, которые указывают

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

статических ресурсов эти заголовки определяются на основании настроек сервера, а для

динамических – (в большинстве случаев) на основании архитектуры обслуживаемого веб-

приложения.

Ситуация осложняется тем, что версии 1.1 и 1.0 HTTP определяют разные подходы

(и, соответственно, разные заголовки) к управлению кэшированием. И хотя количество

клиентов и прокси-серверов, работающих по устаревшему протоколу HTTP 1.0, крайне мало,

желательно иметь возможность работы с ними со стороны сервера.

В статье [3] было проведено сравнение методов увеличения производительности

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

приростов.

1.1.3 Поддержка компрессии данных

Эта оптимизация появилась в HTTP 1.1. Она позволяет серверу передавать

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

клиент должен перечислить в заголовке запроса Accept-Encoding поддерживаемые им схемы

сжатия данных. Сервер может выбрать среди указанных типов компрессии тот, который он

поддерживает, указать его в заголовке ответа Content-Encoding, и с его помощью

закодировать тело ответа. Вообще говоря, решение сервера о применении сжатия может

7

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

компрессии, но и на внутренних настройках сервера и запущенного на нем веб-приложения.

Как показано в статье [3], компрессия существенно снижает общий объем HTTP трафика.

Этим обусловлено широкое применение сжатия.

1.1.4 Поддержка конвейерной обработки (HTTP pipelining)

Согласно обычному порядку обмена сообщениями по протоколу HTTP, клиент

уходит в ожидание ответа после отправки каждого запроса. Если у пользователя медленный

канал связи, то ожидания ответов могут занимать много времени и, тем самым, существенно

замедлять загрузку страниц. В версии 1.1, стандарт HTTP вводит конвейерную обработку

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

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

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

поддерживается большинством современных серверов, поскольку требует только большой

вместимости сетевого буфера (для хранения нескольких запросов). Однако, применение

конвейерной обработки ограниченно плохой поддержкой в современных браузерах.

1.1.5 Поддержка сообщений с комбинированным типом содержимого (multipart types)

Начиная с версии 1.0, формат HTTP сообщений во многом стал похож на MIME [4]

формат сообщений электронной почты. Аналогично MIME, в теле каждого HTTP сообщения

передается сущность. Сущность состоит из заголовков и тела. Тип информации,

передаваемой в теле сущности, указывается в заголовке Content-type. В качестве значения

этого заголовка указывается тип из системы MIME типов (так же называемой системой

медиа типов интернета – Internet media types). Большинство сущностей имеют простой тип,

т.е. содержат однотипную, логически законченную информацию (например фильм, песню,

книгу и т.п.). Для таких сущностей не требуется никакой особой обработки.

Иначе дело обстоит с сущностями комбинированного типа. Эти сущности, как

контейнеры, состоят из других сущностей и имеют один из multipart/* MIME типов. Такие

сущности нуждаются в соответствующей предварительной обработке (выделение всех

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

комбинированным типом является multipart/form-data, предназначенный для передачи

серверу пользовательских данных, указанных в HTML форме.

8

1.2 Обзор существующих моделей работы веб-серверов

С управлением соединениями TCP ситуация противоположна поддержке HTTP:

официально реализация ничем не регулируется, но неформально выделяют несколько

моделей работы с соединениями.

1.2.1 Блокирующие сервера

Подобные сервера работают с сокетами в блокирующем режиме, т.е. при вызове

любой операции над сокетом (прослушивание, чтение, запись, мультиплексирование),

управление не вернется в поток исполнения сервера до тех пор, пока данная операция не

будет выполнена. Эти серверы можно поделить на две категории:

1.2.1.1 Синхронные сервера

Эти сервера последовательно обрабатывают клиентские запросы. Сначала они

создают слушающий сокет, который организует очередь клиентских запросов на

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

обслуживается один клиент. Сначала из очереди выбирается запрос, по которому

устанавливается соединения с клиентом. В результате установления соединения создается

еще один сокет, через который сервер в дальнейшем обменивается пакетами с данным

клиентом. Закончив обслуживание клиента, сервер закрывает соединение с ним и переходит

на следующую итерацию рабочего цикла.

«Синхронность» сервера состоит в том, что все операции по установлению

соединения и отправке/получению пакетов выполняются в одном процессе и одном потоке.

Это означает, что сервер будет обслуживать клиентов последовательно: пока он не закончит

обмен информацией с первым клиентом, он не будет работать со всеми остальными. Эта

особенность может полностью «парализовать» работу сервера, если ему добавить поддержку

постоянных (Keep-Alive) соединений. В таком случае соединение с первым клиентом может

оставаться открытым неопределенно долгое время и заявки на соединение от всех остальных

клиентов возможно вообще никогда не будут обработаны. Поэтому синхронные сервера

практически не используются в реальных проектах.

1.2.1.2 Асинхронные сервера

В целом они выполняют те же операции, что и синхронные. Отличия появляются в

рабочем цикле. После установления соединения, все оставшиеся действия с этим

соединением сервер поручает «рабочему» («воркер», worker) и переходит на следующую

итерацию.

9

Асинхронные сервера отличаются по способу реализации «рабочих» и по способу

выделения «рабочего» для нового соединения. Если «рабочий» является дочерним

процессом, то сервер называется многопроцессным. Если «рабочий» – это дочерний поток,

то сервер называется многопоточным. Если для нового соединения создается новый

«рабочий», то сервер называется fork сервером. Если новый «рабочий» выбирается из пула,

то сервер называется pre-fork сервером.

Такая модель работы позволяет одновременно обслуживать большое количество

клиентов. Дополнительным преимуществом является то, что асинхронные сервера легко

могут работать в качестве серверов приложений: «рабочему» ничто не мешает запустить

скрипт веб-приложения для динамического формирования ответа. Именно поэтому

большинство серверов общего назначения как раз являются асинхронными. Самым

популярным асинхронным сервером является Apache.

1.2.2 Неблокирующие сервера

Это сервера, которые работают с сокетами в неблокирующем режиме. Операции над

сокетами возвращают управление потоку исполнения сервера почти сразу после вызова, а в

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

Таких событий может быть всего три: на слушающий сокет пришла заявка на установление

нового соединения, с сокета прочитана информация, на сокет записана информация.

На данный момент единственной моделью работы таких серверов является FSM

(Finite State Machine – конечный автомат). Здесь так же есть деление на основной процесс и

«рабочих». Разница в том, что каждый «рабочий» работает не с одним соединением, а сразу с

несколькими. Поэтому количество «рабочих» определяется настройками сервера, а не

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

правила: общее количество «рабочих» вместе с основным процессом не должно превышать

количество ядер в системе. Это позволяет использовать ресурсы процессора максимально

эффективно.

У каждого «рабочего» есть свой набор сокетов, который он с помощью

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

набора связан со своим обработчиком. «Рабочий» запускает связанный обработчик, если

обнаруживает новое событие на сокете. Обработчики работают по принципу конечного

автомата (отсюда и название). У них есть некоторое множество действий, которые они могут

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

текущего состояния и события, произошедшего на связанном сокете.

10

При запуске сервера, основной процесс создает слушающий сокет и раздает его всем

«рабочим». Каждый «рабочий» добавляет этот сокет в свой набор и связывает с ним

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

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

сокета создает новое соединение. Полученный при этом сокет он добавляет в набор сокетов

«рабочего» и ассоциирует с ним соответствующий обработчик. Таким образом, в наборе

«рабочего» появляются новые сокеты соединений. У сокетов соединения могут быть только

события прочтения или записи информации. По этим событиям связанные обработчики

выполняют обмен с клиентами.

Более подробно устройство неблокирующего сервера описано в статье [5]. В работе

[6] приведена примерная диаграмма состояний и переходов обработчиков соединений.

Неблокирующий сервер использует минимальное количество системных ресурсов на

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

неблокирующих операций, минимизируются «простои» потока исполнения сервера. В итоге

данная модель работы сервера наиболее эффективно работает с TCP соединениями.

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

новые события. Чтобы события успевали обрабатываться быстрее, чем они накапливаются,

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

скрипта веб-приложения не может быть действием обработчика. Ведь если разработчик

скрипта будет использовать продолжительные по времени операции (обращение к БД и т.п.),

то это может остановить работу всего сервера. Данная особенность не позволяет

использовать неблокирующие сервера в качестве серверов приложений.

Самый популярным FSM сервером на данный момент является nginx.

1.3 Обзор существующих серверных архитектур

В этом разделе серверная архитектура рассматривается только с точки зрения

взаимодействия с клиентом по протоколу HTTP. Остальные вопросы (такие как организация

сервера БД) не относятся к теме данной работы.

1.3.1 Одноуровневая серверная архитектура

Такая архитектура подразумевает использование одного сервера общего назначения

и в качестве веб-сервера и в качестве сервера приложений. Причем этот сервер может

обслуживать по несколько веб-приложений, используя технологию виртуального хостинга.

Единственным большим достоинством такой архитектуры является простота разворачивания

11

и администрирования сервера. Самым большим недостатком является неэффективность

работы сервера при высоких нагрузках (большом количестве одновременно обратившихся

клиентов). Причины этого недостатка могут быть разными, но все они так или иначе связаны

с тем, что сервера общего назначения реализуют асинхронную модель работы. Остановимся

на этих причинах подробнее:

Слишком высокая нагрузка на сервер. Как уже было сказано, асинхронный сервер

создает по одному «рабочему» (процессу или потоку) на каждое активное соединение.

Причем каждый «рабочий» потребляет достаточно много оперативной памяти (на

хранение служебных структур ОС), а переключением между «рабочими» потребляет

достаточно много процессорного времени (на переключение контекста). Поэтому, при

достаточно большом количестве одновременно обратившихся клиентов, серверу может

не хватить системных ресурсов (в первую очередь оперативной памяти и во вторую

процессорного времени) для нормальной работы, что вызовет его аварийное завершение.

В результате серверная часть веб-приложения может потерять свои данные, может не

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

Клиенты с медленным каналом. У клиентов может быть скорость канала настолько

низкой, что отправка ответа будет занимать в сотни и тысячи раз больше времени, чем

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

«рабочих», которые занимают много системных ресурсов, но постоянно находятся в

состоянии ожидания окончания обмена с клиентом и не выполняют никакой полезной

работы. В результате опять появляется возможность аварийного завершения работы

сервера.

Поддержка постоянных (Keep-Alive) соединений. Ситуация с Keep-Alive соединениями

аналогична клиентам с медленными каналами. Каждое такое соединение может

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

никакого обмена данными по этому соединению не происходит. Значит сервер опять

будет создавать большое количество бесполезных «рабочих», которые могут привести к

аварийному завершению. Для уменьшения дополнительной нагрузки на сервер за счет

постоянных соединений, некоторые браузеры могут разрывать соединение сразу после

отображения страницы, а серверы зачастую настраиваются на разрыв соединения по

истечению таймаута.

Помимо основного недостатка есть еще несколько менее существенных. Во-первых,

при аварийном завершении теряются и веб-сервер и сервер приложений. Поэтому, из-за

ошибок реализации веб-сервера, завершится и сервер приложений, который мог бы

12

продолжать работать. И наоборот. Во-вторых, если на каждое веб-приложение работает свой

сервер (не используется технология виртуального хостинга), то появляется неудобство в

администрировании нескольких веб-серверов, т.к. одни и те же настройки обмена по HTTP

приходится дублировать для всех серверов.

Ввиду всех описанных выше особенностей, целесообразно применять

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

1.3.2 Двухуровневая серверная архитектура

В двухуровневой архитектуре задействовано несколько серверов, которые условно

делятся на Front-End и Back-End. Обязанностью BE серверов является динамическое

формирование страниц веб-приложения. В обязанности FE сервера входит обмен с

клиентами по HTTP, обратное проксирование запросов на BE сервера, отдача статических

файлов клиентам. На Рис.1 схематично показана обработка клиентского запроса.

Рисунок 1 – Принцип работы двухуровневой серверной архитектуры

FE сервер принимает все запросы от клиентов. Если FE сервер может, то сам

выполняет полученные запросы (в основном это передача статических файлов и загрузка

файлов на сервер). Если не может, то перенаправляет запросы (выполняет обратное

проксирование) BE серверу (это запросы, требующие динамического формирования ответа).

Более подробно про организацию двухуровневой архитектуры написано в работах [7], [8],

[9], [10].

У проектировщиков серверной архитектуры есть абсолютная свобода выбора

протокола взаимодействия между FE и BE серверами. Чаще всего используются протоколы

HTTP и FastCGI [11]. Если используется FastCGI, то вместо BE серверов используется

специальный менеджер процессов FastCGI (который выполняет те же функции, что и сервер

приложений). Выбор такого менеджера процессов зависит языка, на котором пишется

серверная часть веб-приложения. Сам по себе протокол FastCGI лучше подходит для

13

взаимодействия FE и BE (за счет возможности передачи служебной передачи отдельно от

клиентской, большей безопасности и т.п.). С другой стороны, менеджеров процессов FastCGI

существует не так уж много и далеко не все они реализуют те преимущества протокола,

которые заложены в стандарте. Если используется HTTP, то в качестве BE серверов

используются популярные серверы общего назначения (такие как Apachе). Главным

преимуществом является то, что серверов с поддержкой HTTP больше, чем менеджеров

процессов FastCGI, эти сервера давно используются, надежней, лучше документированы и

оптимизированы. Однако недостаток в том, что BE сервера продолжают выполнять функции

веб-серверов, хотя и обслуживают только одного клиента – FE сервер.

В общем, такая архитектура позволяет эффективно исполнять веб-приложение в

случае высоких нагрузок, что подтверждается работой [3]. Остановимся более подробно на

основных преимуществах данной архитектуры:

Разделение функции веб-сервера и сервера приложений между уровнями. Это улучшает

распределение обязанностей между компонентами серверной части веб-приложения и

повышает отказоустойчивость всей системы (т.к. теперь отсутствует проблема

совместного аварийного завершения вер-сервера и сервера приложений).

Минимизация числа запросов к BE серверам. FE самостоятельно исполняет столько

запросов, сколько сможет. По большому счету FE может обсуживать все запросы на

статические файлы, перенаправляя BE серверам только те запросы, которые требуют

динамического формирования результата. Это минимизирует количество ресурсоемких

«рабочих», порождаемых BE серверами.

Защита от фактора медленных каналов и Keep-Alive соединений. Эти проблемы берет на

себя FE сервер, поскольку только он непосредственно обслуживает клиентов. С другой

стороны, FE сервер устанавливает обычные соединения с BE сервером и принимает

ответы от него настолько быстро, насколько может.

FE сервер может кэшировать некоторые ответы, ранее полученные от BE сервера.

Балансировка нагрузки. Если одно веб-приложение обслуживают несколько BE

серверов, то FE сервер может выбирать какому перенаправлять запрос, в зависимости от

их нагруженности.

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

реализовать виртуальный хостинг. Можно применять какие-то специфические политики

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

запросы на BE сервер в измененном, переработанном виде. Можно повысить

отказоустойчивость (например, FE дает базовую защиту от DDoS атак) [10]. Можно

14

обеспечить шифрование обмена информации с клиентом (например, FE сервер может

работать по протоколу HTTPS). Можно централизованно применить сжатие отдаваемых

клиенту страниц (это так же уменьшит проблему медленных каналов). Можно

централизованно накапливать статистические данные о запросах клиентов и ответах

сервера. Более подробно о том, как сконфигурировать FE сервер для получения

указанных преимуществ, написано в работе [9].

Недостатком этой архитектуры можно назвать сложность ее организации. Отдельно

стоит упомянуть, за счет чего достигается эффективная работа при высоких нагрузках.

Вообще говоря, должен наблюдаться обратный эффект, т.к. добавление еще одного звена в

обработке запроса (FE сервера) должно привести к дополнительным тратам системных

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

работы FE и BE серверов. Поскольку FE сервер сосредоточен на обслуживании клиентов и

не занимается динамическим формированием ответов, то лучше всего для него использовать

модель работы FSM. Именно это дает все преимущества в плане отказоустойчивости

серверной архитектуры.

В общем, двухуровневая архитектура рассчитана на использование в

высоконагруженных, крупных проектах.

1.4 Обзор существующих Front-End серверов

Существует достаточно много веб-серверов, которые можно использовать в качестве

Front-End. Приведем лишь некоторые из них в качестве примера.

Nginx – это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-

сервер [12]. На данный момент наиболее часто используется в качестве FE сервера. Он

работает согласно FSM модели.

Squid – программный пакет, реализующий функцию кэширующего прокси-сервера

для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS [13]. Этот

сервер является неблокирующим и выполнен согласно FSM модели.

Lighttpd – веб-сервер, разрабатываемый с расчётом на быстроту и защищённость, а

также соответствие стандартам [14]. Подобно предыдущим серверам разрабатывается как

неблокирующий веб-сервер.

Благодаря тому, что обратное проксирование происходит по протоколу HTTP, эти

сервера можно относительно легко интегрировать в имеющуюся серверную архитектуру

15

платформы VDOM и сделать ее двухуровневой. Однако, для осуществления

перенаправления запросов, FE должен постоянно синхронизировать с VDOM Server

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

принято решение о разработке собственного FE сервера, ориентированного на

инфраструктуру VDOM.

1.5 Обзор платформы VDOM

Центральное место в проекте VDOM [15] занимает устройство VDOM Box. Это

аппаратно-программное решение для быстрого создания и развертывания веб-приложений.

Сервер VDOM Box создан с учетом возможности установки в любой тип помещений и

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

простые пользователи могут разрабатывать свои веб-приложения, не обладая глубокими

знаниями в соответствующих областях.

Технология VDOM [16], [17] — клиент-серверная система для создания веб-

приложений на основе базовой объектной модели VDOM (VDOM Object Model).

Отличительной чертой этой технологии является то, что объектная модель описывает

пользовательский интерфейс веб-приложений. В результате получаются полностью

объектно-ориентированные веб-приложения. Каждый объект характеризуется

принадлежностью к какому-то типу. Тип определяет набор атрибутов и методов своих

объектов. В состав платформы VDOM входит система типов, описывающая базовую

объектную модель VDOM. Таким образом, технология VDOM позволяет реализовать

компонентную модель разработки веб-приложений.

VDOM объект может ссылаться на статические ресурсы. Если объект удаляется или

перестает ссылаться на ресурс, то этот статический ресурс удаляется. Т.е. платформа VDOM

осуществляет сборку мусора среди статических ресурсов.

Технология VDOM позволяет предоставлять некоторый функционал веб-приложений

в качестве веб-сервисов. Для передачи данных можно использовать следующие протоколы:

SOAP, REST и WebDAV.

Кроме указанных возможностей для построения веб-приложений, технология VDOM

предоставляет инструментарий для создания и управления этими самыми веб-

приложениями. VDOM IDE — среда разработки приложений, позволяющая создавать

пользовательский интерфейс в режиме WYSIWYG. Управлять веб-приложениями и

16

сервером VDOM Box вообще, можно с помощью специального веб-интерфейса

администратора.

Помимо основной технологии VDOM, проектом разработаны еще несколько решений.

Технология E2VDOM добавляет веб-приложениям событийно-ориентированную модель

работы. Серверная часть приложения получает обратную связь с клиентской частью за счет

появления событий у объектов пользовательского интерфейса. В ответ на произошедшее у

клиента событие, сервер посылает информацию об изменившихся элементах интерфейса, по

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

По сути, эта технология является аналогом AJAX (Asynchronous JavaScript And XML). Но в

отличие от AJAX фреймворков, E2VDOM не требует каких-то специальных знаний и

ускоряет разработку «отзывчивых» веб-приложений.

Технология WHOLE связывает офисные и веб-приложения. Она позволяет

преобразовать офисные документы в VDOM объекты и разместить их у себя на сайте. Более

того, документ и VDOM объект могут быть синхронизованы. Т.е. при изменении документа

в обычной офисной программе, VDOM объект отобразит эти изменения и наоборот.

Технология PrintToWeb позволяет «печатать» офисные документы на свой сайт.

PrintToWeb устанавливает в системе свой драйвер печати. Этот драйвер преобразует

описание исходного документа в формате PostScript сначала в объектное представление и

затем в представление веб-страницы (HTML, PDF, FLASH). Данная технология максимально

упрощает процесс публикации своих документов в веб.

1.6 Обзор компиляторов Python в нативный код

В дальнейшем будет рассмотрена необходимость повышения производительности

разрабатываемого FE сервера за счет автоматического портирования Python кода в нативный.

Для этой цели предназначены так называемые компиляторы Python.

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

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

полноценно компилировать Python можно только в байт-код интерпретатора. Однако, нам

как раз нужен компилятор, транслирующий в код на ассемблере (или промежуточный код,

который можно скомпилировать в ассемблерный). При построении такого компилятора

можно пойти двумя путями: компилятор должен встраивать интерпретатор (или его часть) в

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

На данный момент есть несколько компиляторов Python:

17

2c-python - транслятор из Python в С. Проект заброшен, информации по нему нет [18].

unPython - транслятор из Python в С. В язык вводится статическая типизация, с явным

указанием типа переменной через декораторы. Проект давно не развивается [19].

Shed Skin - транслятор из Python в С++. В язык добавлена статическая типизация.

Авторы акцентируют внимание на том, что это экспериментальный язык. Работает

только с Python 2.4-2.6, очень ограниченная поддержка стандартных библиотек [20].

Nuitka - транслятор из Python в С++. Во время исполнения, скомпилированные

приложения используют библиотеку интерпретатора libpython, которая обеспечивает

поддержку всех динамических особенностей языка. Другими словами, этот транслятор

старается скомпилировать все, что можно скомпилировать, а все что нельзя – оставляет

для интерпретации стандартными библиотеками CPython. Это позволяет компилировать

любую программу, написанную на Python. На данный момент реализована полная

поддержка Python 2.5-2.7 и Python 3.x [21].

Cython - транслятор в С и С++. Расширяет Python, сохраняя все его возможности и вводя

в него статическую типизацию. Изначально предназначен для простого создания

«быстрых» модулей расширения. Однако есть возможность встроить интерпретатор в

исполняемый файл [22].

RPython - транслятор в С и другие языки. Используется в проекте PyPy, как инструмент

для написания интерпретатора. Компилирует не все конструкции Python, а только то их

подмножество, к которому можно применить вывод типов и получить статическую

типизацию [23].

Из перечисленных выше проектов выбирать можно среди Nuitka, Cython, RPython. У

каждого транслятора есть свои сильные и слабые стороны:

Совместимость с Python и возможность использовать стандартные библиотеки. У Nuitka

в этом плане никаких проблем нет: можно транслировать любой код на Python и

свободно взаимодействовать со стандартной библиотекой. В Cython пока

поддерживаются не все особенности Python, но в работе со стандартными библиотеками

никаких проблем нет. Однако, проблема стандартных библиотек в Cython в том, что они

не учитывают специфики Cython и соответственно работают не так быстро как могли бы.

Портов стандартных библиотек, которые решали бы эту проблему, пока нет.

RPython реализует подмножество языка Python и не может взаимодействовать со

18

стандартной библиотекой. Хотя стоит отметить, что для RPython есть свои реализации

нескольких стандартных библиотек. В частности rsocket позволяет работать с сокетами.

Кроме того, у RPython в ходе трансляции выделяется так называемая фаза

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

Это немного "сглаживает" ограниченность RPythonа.

Типизация. В RPython применяется только статическая типизация, основанная на

выведении типов. В Nuitka динамическая типизация, за счет использования стандартных

библиотек CPython. Однако, в будущем планируется сделать выведение типов на этапе

компиляции для всех возможных случаев. В Cython переменная может быть

типизирована как динамически, так и статически. Это зависит от ее объявления.

Независимость от стандартного интерпретатора. RPython генерирует только

исполняемые приложения, которые не зависят от интерпретатора. Cython изначально

предназначался для создания модулей расширения для интерпретатора. Все же у него

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

случае Nuitka получается исполняемый файл, который пользуется разделяемой

библиотеки интерпретатора libpython.

Скорость работы приложения. Это рассматривается как основная цель или приятное

дополнение в любом проекте по созданию компилятора Python. Т.к. в RPython

полученный код полностью статически типизирован, то в итоге получается очень

быстрое приложение. В Cython скорость получаемого приложения зависит от того какой

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

разработки и дает большую вероятность внести ошибку в код приложения. Nuitka на

данный момент дает небольшой выигрыш в скорости, но в ближайшее время

планируется добавить в компилятор такие оптимизации как выведение типов, что

должно дать существенную прибавку в скорости.

Наличие сторонних библиотек. В Cython здесь та же проблема что и со стандартными

библиотеками. Можно использовать сторонние библиотеки написанные на чистом

Python, но библиотек, учитывающих особенности Cython, почти нет. Единственный

проект, чьи библиотеки можно использовать в данной работе – это Shrapnel [24]. В этом

проекте есть реализации сокетов и потоков на пользовательском уровне, написанные на

Cython. В рамках проекта PyPy для RPython реализовано несколько сторонних

библиотек. Среди них есть библиотека coroutines, которая так же реализуют

19

многопоточность на пользовательском уровне. Других сторонних библиотек для RPython

нет. С Nuitka можно использовать любые сторонние библиотеки, написанные на Python.

20

2 Проектирование Front-End сервера для проекта VDOM

2.1 Сервер VDOM Server

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

был разработан сервер VDOM Server. Это монолитное приложение, сочетающее в себе веб-

сервер и специализированный сервер приложений. VDOM Server разработан на ЯП Python с

использованием стандартной библиотеки TCPServer. На рисунках 2 и 3 представлены

диаграмма пакетов и диаграмма развертывания, отражающие текущее состояние VDOM

Server.

Рисунок 2 – Текущая диаграмма пакетов VDOM Server

21

Рисунок 3 – Текущая диаграмма развертывания VDOM Server

Функции веб-сервера реализуют:

HTTP слой (HTTP Layer), слой взаимодействия с модулями (Module Communication

Layer) и менеджер ресурсов (Resource Manager). HTTP слой отвечает за принятие запросов и

отправку ответов. Так же HTTP слой включает реализацию технологии E2 VDOM. Слой

взаимодействия с модулями предназначен для включения дополнительных этапов обработки

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

Например, технология WHOLE реализована как раз в качестве дополнительного модуля. Из

слоя взаимодействия с модулями, запрос перенаправляется либо к менеджеру ресурсов, либо

в компоненту веб-интерфейса администратора, либо в сервер приложений VDOM Engine.

Запрос, перенаправленный менеджеру ресурсов, в составе своего URI содержит GUID. У

менеджера ресурсов есть таблица соответствия расположения ресурса GUID’у. По этой

таблице менеджер ресурсов определяет, какой статический ресурс отправить в ответе. Как

уже говорилось, все статические ресурсы связаны с объектами VDOM. Если связи меняются,

то эти изменения отражаются в описанной таблице. Так же, на основании этих изменений,

менеджер ресурсов выполняет сборку мусора.

22

Функции сервера приложении выполняет компонента VDOM Engine. Если

запрашивается объект VDOM, то для такого запроса создается новый поток управления, в

котором VDOM Engine исполняет код запрашиваемого объекта и результат работы передает

в качестве ответа.

Так же в состав сервера входят компоненты для поддержки дополнительных

возможностей технологии VDOM. Компоненты SOAP, REST и WebDAV реализуют

соответствующие протоколы. Веб-приложения в процессе своей работы могут запросить у

сервера поддержку этих протоколов для предоставления своих сервисов. Компонента Admin

Interface реализует функции управления сервером VDOM Box и его веб-приложениями.

Компонента Logger предназначена для накопления информации о работе сервера и

используется всеми остальными компонентами. Дополнительная компонента Watcher, не

входящая в состав VDOM Server, контролирует функционирование сервера. Если VDOM

Server аварийно завершился, то Watcher заново запускает его. Помимо этого, Watcher имеет

возможность взаимодействия по протоколу TCP.

2.2 Переход от одноуровневой сетевой архитектуры к двухуровневой

Как было показано в предыдущем разделе, VDOM Server – асинхронный сервер,

который выполняет функции и веб-сервера и сервера приложений. Это означает, что текущая

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

является даже не столько разработка FE сервера, сколько переход к двухуровневой

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

которые касаются взаимодействия уровней.

Протокол HTTP не самым лучшим образом подходит для такого взаимодействия,

поскольку исключает обратную связь от BE к FE. Как уже говорилось, в этом плане у

разработчиков нет каких-то строгих ограничений. Поэтому можно было бы выбрать какой-то

другой способ взаимодействия. Однако, реальных альтернатив HTTP на данный момент нет,

поскольку VDOM Server поддерживает только его. Переход к другому способу

взаимодействия слоев означает существенное изменение VDOM Server и может

рассматриваться только как будущее развитие сетевой архитектуры.

На рисунках 4 и 5 представлены диаграмма пакетов и диаграмма развертывания,

которые показывают взаимосвязь FE сервера с остальной платформой в новой сетевой

архитектуре.

23

Рисунок 4 – Диаграмма основных пакетов FE Server и VDOM Server

Рисунок 5 – Диаграмма развертывания FE Server и VDOM Server

Исходя из диаграмм видно, что менеджер ресурсов теперь является частью FE

сервера. Это связано с тем, что VDOM сервер теперь исполняет только функции сервера

приложений и задачу отдачи статических ресурсов лучше переложить на FE веб-сервер.

24

Каждое веб-приложение обслуживается своей копией VDOM Server, запущенной в

отдельном процессе. Компонента интерфейса администратора не входит в состав VDOM

Server, поскольку нужный ему обмен по HTTP теперь осуществляет FE. Тем не менее,

интерфейс администратора должен реализовать свой HTTP слой для возможности обратного

проксирования ему запросов от FE сервера. Компонента логгирования так же стала

общесистемной.

2.3 Обновление правил обработки запросов

Обработка запросов в полученной архитектуре требует такой функциональности FE

сервера, которую не могут обеспечить готовые решения. Этому есть две причины. Во-

первых, с помощью интерфейса администратора можно изменять или удалять объекты веб-

приложений. Значит, могут изменяться связи объектов и статических ресурсов или ресурсы

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

менеджеру ресурсов, который теперь входит в состав FE сервера. Во-вторых, веб-

приложения в процессе работы могут начать пользоваться одним из протоколов SOAP,

REST, WebDAV, которые работают поверх HTTP.

Для отслеживания этих изменений требуется обратная связь от BE к FE. Как уже

было сказано, протокол HTTP не дает таких возможностей, поэтому обратную связь было

решено организовать с помощью платформы RabbitMQ [25]. RabbitMQ реализует систему

обмена сообщениями между компонентами программной системы. Компоненты могут

исполняться в разных процессах и на разных устройствах. Тем самым, RabbitMQ скрывает

все сложности обмена сообщениями между различными процессами. В качестве

транспортного протокола для передачи сообщений может быть использован AMQP

(Advanced Message Queuing Protocol), HTTP и ряд других [26]. Так же есть возможность

асинхронной обработки сообщений, что позволяет работать с сообщениями как с событиями.

Для работы с RabbitMQ необходимо настроить сервер, входящий в стандартную поставку, и

установить одну из клиентских библиотек для работы с RabbitMQ. Список клиентских

библиотек можно найти на странице [27]. Для данной работы была выбрана библиотека pika

[28]. В дальнейшем эту платформу можно рассматривать в качестве замены протокола HTTP

для обратного проксирования запросов.

FE сервер должен хранить какой-то список правил обработки поступивших

запросов. Эти правила можно поделить на две части: условие и действие. По условию можно

проверить, подходит ли клиентский запрос под данное правило, а действие определяет

процедуру получения ответа на этот запрос. Условия состоят из четырех элементов:

25

1. Список HTTP методов;

2. Регулярное выражение для доменного имени;

3. Регулярное выражение для пути к ресурсу;

4. Регулярное выражение для расширения ресурса.

Считается, что запрос попадает под правило, если его метод входит в список

методов правила, а доменное имя, путь и расширение ресурса подходят под

соответствующие регулярные выражения. При выборе правила обработки, в списке правил

ищется первое подходящее. На данный момент, действий по получению ответов всего два:

перенаправление запроса на BE и получение статического ресурса от менеджера ресурсов.

Для взаимодействия с менеджером ресурсов достаточно одного правила, у которого

в условии прописаны все расширения файлов статических ресурсов. Как уже говорилось, для

работы менеджеру ресурсов нужна таблица соответствия GUID — расположение ресурса. С

введением FE сервера, таблица будет обновляться как и раньше, только события будут

передаваться через сообщения RabbitMQ. Таким образом решается первая проблема:

возможность изменения объектов через интерфейс администратора.

При добавлении новых веб-сервисов, нужно добавить соответствующие правила

перенаправления в список. Обновление происходит по событиям, передаваемым через

RabbitMQ. В сообщении передается адрес, по которому необходимо перенаправлять запрос,

и условия для перенаправления. При возникновении такого события, FE сервер по

полученной информации создает новое правило в списке. Удаление правил происходит

аналогичным образом.

Надо отметить, что изменение и доступ к списку правил и таблице соответствия

GUID — размещение статического ресурса, должны происходить в потокобезопасной

манере. Такая необходимость вызвана тем, что список и таблица являются разделяемыми

данными между потоками сервера, причем одни потоки могут считывать из них данные, а

другие записывать.

2.4 Повышение производительности FE сервера

От производительности FE сервера очень сильно зависит производительность всей

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

алгоритма работы, либо путем оптимизации сгенерированного транслятором исполняемого

кода.

26

В плане оптимизации алгоритмов работы уже было показано, что выбор модели

работы сервера с TCP-соединениями оказывает наибольший эффект на производительность.

Лучшим выбором была бы FSM модель. Однако, практическая реализация такой модели

сервера выходит за рамки ВКР. К тому же, на данный момент сервера VDOM Box

объективно не испытывают таких высоких нагрузок. Если все же один из процессов VDOM

Box аварийно завершится, то компонента Wathcer запустит его заново. Помимо этого, целью

введения FE сервера было не столько повышение производительности, сколько разделение

обязанностей веб-сервера и сервера приложений. С учетом всего вышесказанного, за основу

FE было решено использовать асинхронный сервер ForkingTCPServer из комплекта

стандартных библиотек.

В плане оптимизаций сгенерированного кода имеет большое значение выбор

собственно самого этого транслятора. Тут можно повышать производительность двумя

путями. Во-первых, можно использовать специальные правила, «хороший стиль» написания

исходного кода. Такой исходный код будет учитывать специфику работы конкретного

транслятора, и в итоге сгенерируется более эффективный исполняемый код. Описывать эти

правила сейчас не имеет смысла, поскольку они не касаются тематики данной работы. Во-

вторых, можно просто выбрать другой транслятор. На этом вопросе стоит остановиться

поподробнее.

На первый взгляд для реализации FE хорошо подойдет Python и его интерпретатор

CPython 2.7, поскольку именно они используются во всем проекте VDOM. Этот выбор

упростит сопровождение проекта и позволит использовать уже готовую функциональность

(тот же менеджер ресурсов). Так же взаимодействие FE и BE серверов может упроститься,

если они будут исполняться в одной и той же (или совместимой) среде. Однако,

использование CPython даст существенные потери производительности. Основная проблема

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

осложняется наличием глобальной блокировки интерпретатора (GIL), которая значительно

снижает эффективность многопоточных приложений.

Ввиду всего вышесказанного, было решено вместо CPython использовать один из

компиляторов Python. Это даст повышение производительности за счет генерации нативного

кода вместо байт-кода. Ранее было дано сравнение трех основных компиляторов: Cython,

RPython и Nuitka. Среди них был выбран Nuitka, поскольку он поддерживает все языковые

конструкции Python, позволяет легко работать со стандартными и сторонними

библиотеками, поддерживает динамическую типизацию и неявно статическую за счет

27

выведения типов и, в конце концов, повышает производительность. Помимо этого, основной

целью Cython является создание модулей расширения для интерпретатора, а целью RPython

– создание трансляторов. Т.е. эти инструменты изначально предназначены для решения

узкоспециализированных задач.

Процесс трансляции с помощью Nuitka достаточно прост. Для получения

исполняемого файла необходимо выполнить только одну команду:

nuitka –recurse-all –output-dir=путь основной_модуль.py

Здесь путь – путь к папке, в которую необходимо поместить готовый исполняемый файл.

основной_модуль – модуль, с которого начинается процесс исполнения приложения.

Помимо этого повышение производительности будет достигаться за счет того, что

каждое веб-приложение обслуживается отдельным процессом VDOM Server, а не его

потоком. Это избавляет от необходимости использовать глобальную блокировку

интерпретатора (GIL).

28

3 Проксирующий Front-End сервер для проекта VDOM

Основная часть реализации направлена на поддержку протокола HTTP. Приходящие

запросы преобразуются из текстового представления в объектное. Ответы изначально

формируются в объектном виде, и преобразуются в текстовое представление при передаче.

Функции пред и пост обработки HTTP сообщении вынесены в отдельные модули. Новая

функциональность и поддержка новых особенностей протокола может быть добавлена путем

включения нового модуля в схему обработки сообщения.

Основная сложность реализации состоит в том, что в рамках данной работы нет

возможности изменять BE сервер (VDOM Server). Поэтому, того разделения VDOM Server,

которое было приведено на рисунках 4 и 5 пока не происходит. Однако, механизм

обновления правил обработки запросов позволяет в дальнейшем выполнить это разделение

без изменения реализации FE сервера. Так же, текущая реализация VDOM Server не работает

с RabbitMQ, а значит и не посылает сообщений FE серверу о изменениях в VDOM объектах

и веб-сервисах.

3.1 Архитектура сервера

FE сервер структурно поделен на следующие пакеты:

RequestHandling — основной пакет, содержит класс обработчика запросов и правила

обработки запросов.

HTTP — содержит классы, отвечающие за поддержку протокола HTTP

ResorceManager — содержит классы менеджера ресурсов

29

Рисунок 6 – Диаграмма пакетов FE сервера

Описание классов:

Рисунок 7 – Диаграмма классов пакета RequestHandling

FEServer – Класс FE сервера. Работа сервера начинается с экземпляра этого класса. Он

организует процесс обработки TCP-соединений и прием сообщений через RabbitMQ.

30

RequestHandler — Обработчик клиентских запросов. Этот класс определяет общую

последовательность действий по обработке клиентских запросов. Унаследован от

библиотечного класса SocketServer.StreamRequestHandler и является «связующим

звеном» между библиотечной частью (ForkingTCPServer) и собственной частью

реализации. В методе handle организуется цикл обработки завпросов.

Rules – класс, представляющий собой список правил обработки запросов. Методы

add_rule и del_rule реализуют функции обновления списка. Метод get_action возвращает

действие, необходимое для получения ответа на запрос.

BERedirect – класс, реализующий перенаправление запроса на BE сервер.

RMRedirect – класс, реализующий получение статических ресурсов через менеджер

ресурсов.

Рисунок 8 – Диаграмма классов пакета HTTP

Message — базовый класс для сообщений, передаваемых по протоколу HTTP. Его

экземпляры – объектное представление сообщений. Реализует паттерн Строитель

(Builder) для перевода объектного представления сообщения в текстовое и наоборот.

Методы parse_startline, parse_headers, parse_body преобразуют сообщение из текстового

представления в объектное. Методы get_startline_str, get_headers_str, get_body_str

преобразуют сообщение из объектного представления в текстовое.

31

Request — Переопределяет Message и его методы преобразования представлений, с

учетом специфики HTTP запросов.

Response — Переопределяет Message и его методы преобразования представлений, с

учетом специфики HTTP ответов.

Helper – Класс, координирующий обработку всех сообщений. Методы process_request и

process_response отвечают за обработку запросов и ответов соответственно.

Common – Класс, отвечающий за общую обработку и проверку сообщений. Методы

process_request и process_response отвечают за обработку запросов и ответов

соответственно.

Compression – Класс, отвечающий за сжатие данных. Методы process_request и

process_response отвечают за обработку запросов и ответов соответственно.

MIMETypes – Класс, отвечающий за обработку сообщений в соответствии с MIME

типами их содержимого. В случае POST запроса, сохраняет файлы на диске и вставляет

вместо них ссылки в тело сообщения. Методы process_request и process_response

отвечают за обработку запросов и ответов соответственно.

HTTPMessageError — Пользовательское исключение, которое представляет собой

ошибки, предусмотренные протоколом HTTP.

3.2 Обработка запроса

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

32

Рисунок 9 – Диаграмма последовательности обработки HTTP-запроса

При поступлении запроса, ForkingTCPServer создает новый экземпляр класса

RequestHandler в отдельном процессе. Затем вызывается метод handle экземпляра

RequestHandler, где с запросом выполняется следующая последовательность действий:

1. Объект класса Helper организует преобразование запроса из строкового представления

объектное (создается объект класса Request). Запрос обрабатывается модулями.

2. На основании содержимого запроса определяется действие, которое надо выполнить.

Метод get_action(), с помощью правил обработки запросов, возвращает действие,

производимое над запросом. В данном примере это объект класса BERedirect.

3. Применяется выбранное действие и получается объект ответа (объект класса Response).

4. Полученный ответ передается объекту класса Helper, который его обработку аналогично

запросу.

5. Далее производится постобработка ответа. Определяются такие факторы как

необходимость прервать соединение.

6. С помощью объекта ответа конструируется строковое представление ответа, которое

затем пересылается клиенту.

7. Если на одном из предыдущих шагов произошла ошибка в работе по протоколу HTTP

(поймано исключение HTTPMessageError), то клиенту отсылается ответ с указанием

ошибки и соединение закрывается.

33

Все эти операции выполняются в цикле, в соответствии с логикой работы Keep-Alive

соединений.

3.3 Тестирование

Поскольку реализация VDOM Server не менялась и не поддерживает обновление

правил обработки запросов, приведем только случай тестирования перенаправления запроса.

Обратное проксирование происходит по протоколу HTTP, поэтому в качестве BE сервера

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

сервер, который обслуживает сайт проекта VDOM (http://www.vdombox.ru). FE сервер

работал по адресу 127.0.0.1:8085 и в файле hosts для была добавлена запись:

127.0.0.1 FE www.FE

Правило перенаправления запросов было сформировано следующим образом:

(('GET', 'POST'), '.*FE', '.*', '.*', BERedirect('www.vdombox.ru', 80))

Запрос:

GET http://FE/home.vdom HTTP/1.1

Host: FE

Connection: keep-alive

Cache-Control: max-age=0

Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*

/*;q=0.8

User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36

(KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Accept-Encoding: gzip,deflate,sdch

Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4

Cookie: sid=35b3a5706eb1b1177dfcfdec3b9ba40e

Ответ:

HTTP/1.1 200 OK

Date: Wed, 11 Dec 2013 02:07:58 GMT

Server: VDOM v2 server 1.1.6777 Python/2.7.1

Content-type: text/html

Set-Cookie: sid=35b3a5706eb1b1177dfcfdec3b9ba40e

Vary: Accept-Encoding

Content-Encoding: gzip

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Transfer-Encoding: chunked

34

Отображение ответа браузером:

Рисунок 10 – Отображение результата перенаправления запросов

35

Заключение

В рамках выпускной квалификационной работы была сформулирована цель –

построить специализированный Front-End сервер, который бы инкапсулировал в себе

обслуживание клиентов по протоколу HTTP, минимизировал количество запросов к Back-

End серверам, учитывал специфику и эффективно использовал особенности имеющейся

инфраструктуры VDOM. Кроме того требовалось разработать программное решение с

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

решения был выбран проект Nuitka.

Таким образом, получилась следующая схема взаимодействия. Все сервера, которые

раньше присутствовали в серверной архитектуре, становятся Back-End серверами. На Front-

End сервер полностью перекладывается непосредственное взаимодействие с клиентами по

HTTP: принятие запросов, отправка ответов.

В ходе выполнения выпускной квалификационной работы были получены

следующие результаты:

Проанализированы существующие программные решения для повышения

производительности существующего кода сервера посредством автоматической

трансляции в нативный код;

Спроектирована модель двухуровневой серверной архитектуры для проекта VDOM;

Спроектирован и реализован Front-End сервер;

Реализован реализован механизм автоматического обновления правил обработки

запросов посредством подписки на события Back-End серверов.

36

Литература

1. Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners-Lee T. RFC2616.

Hypertext Transfer Protocol — HTTP/1.1 [Электронный ресурс]. – Электрон. дан. – 2013. –

URL: http://www.w3.org/Protocols/rfc2616/rfc2616.html/ (дата обращения: 03.09.2013).

2. Mogul J. C. The case for persistent-connection HTTP // SIGCOMM '95 Proceedings of the

conference on Applications, technologies, architectures, and protocols for computer

communication. New-York, 4 Oct 1995. – New-York. – С. 299–313.

3. Ботыгин И. А. Исследование методов увеличения производительности Web-приложений

/ И. А. Ботыгин, К. А. Каликин // Известия ТПУ – 2008. – Том 312. – № 5. – С. 109–114.

4. Freed N., Borenstein N. Multipurpose Internet Mail Extensions (MIME) Part One: Format of

Internet Message Bodies [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.ietf.org/rfc/rfc2045.txt/ (дата обращения: 03.09.2013).

5. Крижановский А. Как построить высокопроизводительный Front-End сервер //

Разработка высоконагруженных систем. По материалам конференции Highload++ 2010-

2011. – М., 2012. – С. 117–132.

6. Ju H-T. An efficient and lightweight embedded Web server for Web-based network element

management / H-T. Ju, M-J. Choi, J. W. Hong // International Jornal of Network Management

– 2000. – № 10. – С. 261–275.

7. Носков В. Ю. Оптимизация балансировки нагрузки между серверными платформами

веб-приложений / В. Ю. Носков, Е. А. Гой, А. В. Костромин // Научный журнал КубГАУ

– 2013. – № 89(05). – С. 97–112.

8. Сайфутдинова Л. Ж. Высоконагруженные системы (Back-End) // Материалы

конференции «Дни науки ОТИ НИЯУ МИФИ - 2012». Озерск, 25–26 апреля 2012 г. –

Челябинск:ОТИ НИЯУ МИФИ., 2012. – Том 1. – С. 86–87.

9. Sommerlad P. Reverse proxy patterns // 8th European Conference on Pattern Languages of

Programms (EuroPLoP '2003). Irsee, Germany, June 25-29, 2003. – UVK:Universitaetsverlag

Konstanz, 2004. – С. 431–458.

10. Грушко Е. И. Современная серверная архитектура «Front and Back ands» как средство

противодействия атакам типа DdoS, SYN-Flood и Slow-POST // Материалы конференции

«III Всеукраїнська конференція ІТБтаЗ». Озерск, 15 марта 2012 г. – Харьков:ДВНЗ

"НГУ" ТОВ "САЛВЕЙ", 2012. – С. 40–44.

11. Brown M. R. FastCGI Specification [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.fastcgi.com/drupal/node/6?q=node/22 (дата обращения: 03.09.2013).

37

12. Документация проекта nginx [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://nginx.org/ru/docs/ (дата обращения: 03.09.2013).

13. Документация проекта SQUID [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.squid-cache.org/Doc/ (дата обращения: 03.09.2013).

14. Документация проекта lighttpd [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://redmine.lighttpd.net/projects/lighttpd/wiki (дата обращения: 03.09.2013).

15. Продукты VDOM [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.vdombox.ru/products.vdom (дата обращения: 03.09.2013).

16. Технологии VDOM [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.vdombox.ru/tech_vdom.vdom (дата обращения: 03.09.2013).

17. Страница VDOM на Википедии [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://fr.wikipedia.org/wiki/VDOM (дата обращения: 03.09.2013).

18. Google Code [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://code.google.com/p/2c-python/w/list (дата обращения: 03.09.2013).

19. Google Code [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://code.google.com/p/unpython/w/list (дата обращения: 03.09.2013).

20. Google Code [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://code.google.com/p/shedskin/w/list (дата обращения: 03.09.2013).

21. Документация проекта Nuitka [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://nuitka.net/pages/documentation.html (дата обращения: 03.09.2013).

22. Документация проекта Cython [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://docs.cython.org/ (дата обращения: 03.09.2013).

23. Документация проекта PyPy [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://doc.pypy.org/en/latest/translation.html (дата обращения: 03.09.2013).

24. Документация проекта Shrapnel [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://ironport.github.io/shrapnel/index.html (дата обращения: 03.09.2013).

25. Проект RabbitMQ [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

http://www.rabbitmq.com/features.html (дата обращения: 03.09.2013).

26. Транспортные протоколы RabbitMQ [Электронный ресурс]. – Электрон. дан. – 2013. –

URL: http://www.rabbitmq.com/protocols.html (дата обращения: 03.09.2013).

27. Список клиентских библиотек RabbitMQ [Электронный ресурс]. – Электрон. дан. –

2013. – URL: http://www.rabbitmq.com/devtools.html (дата обращения: 03.09.2013).

28. Библиотека pika [Электронный ресурс]. – Электрон. дан. – 2013. – URL:

https://pika.readthedocs.org/en/0.9.13/ (дата обращения: 03.09.2013).

38

Приложение А. (руководство программиста)

FE сервер структурно поделен на следующие пакеты:

RequestHandling — основной пакет, содержит класс обработчика запросов и правила

обработки запросов.

HTTP — содержит классы, отвечающие за поддержку протокола HTTP

ResorceManager — содержит классы менеджера ресурсов

Рисунок 11 – Диаграмма пакетов FE сервера

Описание классов:

39

Рисунок 12 – Диаграмма классов пакета RequestHandling

FEServer – Класс FE сервера. Работа сервера начинается с экземпляра этого класса. Он

организует процесс обработки TCP-соединений и прием сообщений через RabbitMQ.

RequestHandler — Обработчик клиентских запросов. Этот класс определяет общую

последовательность действий по обработке клиентских запросов. Унаследован от

библиотечного класса SocketServer.StreamRequestHandler и является «связующим

звеном» между библиотечной частью (ForkingTCPServer) и собственной частью

реализации. В методе handle организуется цикл обработки завпросов.

Rules – класс, представляющий собой список правил обработки запросов. Методы

add_rule и del_rule реализуют функции обновления списка. Метод get_action возвращает

действие, необходимое для получения ответа на запрос.

BERedirect – класс, реализующий перенаправление запроса на BE сервер.

RMRedirect – класс, реализующий получение статических ресурсов через менеджер

ресурсов.

40

Рисунок 13 – Диаграмма классов пакета HTTP

Message — базовый класс для сообщений, передаваемых по протоколу HTTP. Его

экземпляры – объектное представление сообщений. Реализует паттерн Строитель

(Builder) для перевода объектного представления сообщения в текстовое и наоборот.

Методы parse_startline, parse_headers, parse_body преобразуют сообщение из текстового

представления в объектное. Методы get_startline_str, get_headers_str, get_body_str

преобразуют сообщение из объектного представления в текстовое.

Request — Переопределяет Message и его методы преобразования представлений, с

учетом специфики HTTP запросов.

Response — Переопределяет Message и его методы преобразования представлений, с

учетом специфики HTTP ответов.

Helper – Класс, координирующий обработку всех сообщений. Методы process_request и

process_response отвечают за обработку запросов и ответов соответственно.

Common – Класс, отвечающий за общую обработку и проверку сообщений. Методы

process_request и process_response отвечают за обработку запросов и ответов

соответственно.

Compression – Класс, отвечающий за сжатие данных. Методы process_request и

process_response отвечают за обработку запросов и ответов соответственно.

41

MIMETypes – Класс, отвечающий за обработку сообщений в соответствии с MIME

типами их содержимого. В случае POST запроса, сохраняет файлы на диске и вставляет

вместо них ссылки в тело сообщения. Методы process_request и process_response

отвечают за обработку запросов и ответов соответственно.

HTTPMessageError — Пользовательское исключение, которое представляет собой

ошибки, предусмотренные протоколом HTTP.