Министерство образования и науки Российской Федерации ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ (ТГУ) Факультет Информатики Кафедра теоретических основ информатики УДК 681.03 ДОПУСТИТЬ К ЗАЩИТЕ В ГАК Зав. кафедрой, доцент, канд. тех. Наук _______________________Фукс А. Л. «____»_________________2013 г. КВАЛИФИКАЦИОННАЯ РАБОТА БАКАЛАВРА Реализация Front-End сервера для проекта VDOM Кривчиков Иван Сергеевич Руководитель ВКР, ассистент Кафедры ТОИ ____________ М.С.Овсянников подпись «_____»__________2013 г. Автор работы студент группы № 1491 _____________ И.С.Кривчиков подпись Электронная версия бакалаврской работы Администратор электронной помещена в электронную библиотеку. библиотеки факультета _____________ Е.Н.Якунина подпись Томск 2013
41
Embed
УДК 681 - tsu.ruinf.tsu.ru/library/DiplomaWorks/CompScience/2013/... · совместной работы с сервером приложений vdom, поэтому в этой
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Министерство образования и науки Российской Федерации
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ (ТГУ)
Факультет Информатики
Кафедра теоретических основ информатики
УДК 681.03
ДОПУСТИТЬ К ЗАЩИТЕ В ГАК
Зав. кафедрой, доцент, канд. тех. Наук
_______________________Фукс А. Л.
«____»_________________2013 г.
КВАЛИФИКАЦИОННАЯ РАБОТА БАКАЛАВРА
Реализация Front-End сервера для проекта VDOM
Кривчиков Иван Сергеевич
Руководитель ВКР, ассистент
Кафедры ТОИ
____________ М.С.Овсянников
подпись
«_____»__________2013 г.
Автор работы
студент группы № 1491
_____________ И.С.Кривчиков
подпись
Электронная версия бакалаврской работы Администратор электронной
помещена в электронную библиотеку. библиотеки факультета
Литература ...................................................................................................................................................... 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 сервера. Он