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

Архитектура клиент-сервер или Web: выбор разработчика

Везет разработчикам! Им редко приходится иметь дело с теми программными продуктами, которые они создают. Даже если, принимая очередное решение, разработчик исполнен благих намерений, это отнюдь не гарантирует продуктивной работы пользователей и администраторов с его приложением. В последнее время среди наиболее важных вопросов создания сетевых приложений появился еще один: какую выбрать архитектуру — клиент-серверную или основанную на службе Web?

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

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

Клиент-сервер и Web: рассмотрим поближе

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

Дело осложняется еще и тем, что довольно трудно дать точное определение двум рассматриваемым архитектурным подходам. В классической архитектуре клиент-сервер клиентская часть представлена так называемым «толстым» клиентом, т. е. приложением, разработанным с помощью пакета типа Visual Basic или Delphi . Свое «прозвище» он получил в связи с тем, что помимо уровня представления информации содержит еще и бизнес-логику прикладной задачи. Такой клиент работает не только с реляционной базой данных, но и с файл-сервером. Стандартное Web-приложение, как правило, используется лишь для представления данных. Вся бизнес-логика в этом случае выполняется на сервере приложений, который и обращается к СУБД.

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

Исследование производительности

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

Заложенная в программу бизнес-логика состояла в основном из SQL-запросов, и ее главной целью было просто загрузить процессор машины. Программы на «толстых» клиентах содержали как прикладную часть, так и функции управления пользовательским интерфейсом, например ввод и редактирование данных. Бизнес-логика, работавшая на серверах приложений, была создана преимущественно с помощью программного интерфейса ISAPI (Internet Server Application Programming Interface) фирмы Microsoft и содержала вызовы функций динамических библиотек, в частности отвечающих за формирования страниц HTML. Для доступа к таблицам базы данных обе версии приложений — и клиент-серверная и Web — использовали интерфейс ODBC (Open Database Connectivity).

В процессе запуска наших «доморощенных» приложений мы отметили, что динамические библиотеки, написанные на Delphi , работают быстрее DLL, созданных с помощью Visual Basic. И вообще, производительность Delphi нас приятно удивила. Дело в том, что мы использовали специальную библиотеку WebBridge фирмы Borland International, позволяющую абстрагироваться от конкретного способа взаимодействия с Web-сервером, будь то интерфейс ISAPI или NSAPI (Netscape Application Programming Interface) фирмы Netscape Communications.

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

Серверы баз данных различных поставщиков имеют собственный синтаксис хранимых процедур. Так, в сервере Oracle реализован язык PL/SQL, а в MS SQL Server — язык Transact-SQL. Это несколько ограничивает возможность применения хранимых процедур, ведь вам вряд ли захочется выбрасывать массу наработанного кода, если вы вдруг поменяете поставщика СУБД. Тем не менее мы считаем, что разумное использование хранимых процедур способно в равной степени повысить производительность приложений и в клиент-серверной среде и в среде Web.

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

Трафик Web-приложений имеет несколько иную структуру, поскольку сеть задействуется каждый раз при обращении пользователя к HTML-странице или к соответствующему фрагменту приложения на JavaScript или Java, хранящемуся на Web-сервере. Кроме того, повышенная сетевая активность наблюдалась при передаче данных с Web-клиента на Web-сервер, а также при обращении сервера приложений к СУБД. (В нашей конфигурации модули бизнес-логики и ПО Web-сервера работали на одном и том же компьютере.)

Интересно, что трафик в гораздо большей степени зависел от используемого сервера баз данных (Oracle, MS SQL Server или DB2), чем от архитектурного подхода. В частности, для Oracle мы наблюдали наименьший сетевой трафик, а для SQL Server — наибольший.

Большое значение имеют и используемые сетевые протоколы. Так, наиболее «разговорчивым» оказался протокол NetBEUI, IPX/SPX был более умеренным, и самым «лаконичным» был TCP/IP. Мы также смогли снизить трафик службы DNS (Domain Name Service), используя непосредственные адреса серверов баз данных вместо их доменных имен. Но для сетевых администраторов применение этого метода означает дополнительную работу при установке новых машин.

Загрузка администратора

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

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

В Web-среде у администратора примерно те же задачи. Однако на поддержку пользователей, связанную, например, с перезапуском «зависших» приложений, у него уходит гораздо меньше времени, поскольку Web-браузеры, такие, как Microsoft Internet Explorer или Netscape Navigator, «зависают» гораздо реже программ, выполненных с помощью средств разработки наподобие Visual Basic или Delphi . Кроме того, браузер автоматически получает классы мини-приложений Java с Web-сервера, поэтому администраторам не приходится заботиться о распространении пользовательских приложений на локальные диски.

Задача выравнивания нагрузки также обычно ложится на плечи сетевых администраторов. Она подразумевает добавление файл-серверов, Web-серверов, серверов баз данных и приложений по мере увеличения числа пользователей и последующую настройку приложений, с тем чтобы они могли распознавать добавленные ресурсы. Но если вы используете такое связующее ПО, как, например, монитор транзакций TUXEDO фирмы BEA Systems, то работы у вас будет намного меньше: этот продукт позволяет автоматически распознавать новые ресурсы, а также регулировать вычислительную мощность при изменении интенсивности транзакций.

Сравнение по надежности

Web-подход в общем оказался более надежным, чем клиент-серверный. Поддержка программы, т. е. необходимость внесения новых полей редактирования или изменение старых, делают ПО клиент-сервер менее стабильным. Эпитет «толстый» стал синонимом определения «сложный». Отладка и тестирование приложений клиент-сервер — довольно сложный процесс, поскольку они содержат большое число тесно взаимодействующих модулей. С другой стороны, когда во время тестирования неожиданно начинали «сыпаться» ошибки, обнаружить их в «толстом» клиенте было значительно легче: ОС Windows выводила на экран соответствующее сообщение.

Характерно, что в Web-среде «зависшая» DLL, написанная с помощью ISAPI, выводила сообщение на консоль сервера приложений, но пользователь при этом продолжал смотреть на неменяющийся экран браузера. В случае серьезной ошибки исполнения модуля DLL операционная система Windows NT будет вынуждена завершить работу Web-сервера IIS (Internet Information Server) вместе с приложением. С точки зрения надежности поставщикам следовало бы разрабатывать более совершенные методы отражения проблем сервера приложений для тех, кто использует Web-браузер.

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

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

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

Победителем становится.

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

Читать еще: Архитектура приложений клиент сервер

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

Архитектура современных Web-приложений

Алексей Федоров, Наталия Елманова

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

Следующим этапом развития Web стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем — на ISAPI. Common Gateway Interface (CGI) — это стандартный интерфейс с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Web-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Web-страниц и наполнение Web перестало быть чисто статическим.

Интерфейс ISAPI — это особенность Microsoft Internet Information Server (о последней версии этого продукта вы можете прочесть в статье «Internet Information Services 6.0». ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Web-сервера. У других Web-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Web-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Web-сервера Apache также имеется возможность выполнять Web-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

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

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Web-страницы кода, выполняемого Web-сервером. Наиболее известная из них на сегодняшний день — технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages — ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Web-приложения и Web-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Web-приложений.

В общем случае клиентом Web-сервера может быть не только персональный компьютер, оснащенный обычным Web-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Web-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP — Wireless Access Protocol) и соответствующие языки разметки (WML — Wireless Markup Language, СHTML — Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание «разумных» серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Web-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Web-браузере. В частности, современные Web-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Web-страницу, но интерпретируется не Web-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты — специальные Java-приложения, которые пользователь получает в составе Web-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX — выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Web-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Web-сайтов возрастают и требования к надежности, производительности и масштабируемости Web-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Web-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Web-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификацию J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Web-сайт с CRM-системами (CRM — Customer Relationship Management — приложения для автоматизации и повышения эффективности процессов, направленных на взаимоотношения с клиентами, таких как обработка заказов, маркетинг, обслуживание) или с ERP-системами (ERP — Enterprise Resource Planning — приложения для автоматизации управления внутрихозяйственными процессами предприятия, такими как производство, финансы, снабжение, управление персоналом и др.), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Internet — это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Internet таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа «предприятие—клиент» (B2C — business-to-consumer). Не менее важными становятся и задачи интеграции Web-приложений c данными и приложениями партнеров с целью реализации схемы «предприятие—предприятие» (B2B — business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

Нередко частью портального решения являются средства управления информационным наполнением Web-сайта — ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными «вручную» не представляется возможным. Подробнее об управлении информационным наполнением и средствах, с помощью которых оно осуществляется, вы сможете прочесть в статье «Управление информационным наполнением Web-сайтов».

Решение многих описанных выше задач, возникающих при создании современных Web-приложений, теперь начинает возлагаться на Web-сервисы — не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Web-приложений (а также из самих Web-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP. Для описания Web-сервисов используется XML-подобный язык WSDL, а для организации реестров Web-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах — интерфейс UDDI. Более подробно о технологиях, лежащих в основах Web-сервисов, можно прочитать в статье «Технологии для Web-сервисов», опубликованной в этом номере.

Читать еще: Ошибка 1603 при установке

Поддержка Web-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений, систем управления базами данных и средств разработки приложений. В публикуемой в данном номере статье «Платформы и средства создания Web-сервисов» мы подробно рассматриваем поддержку Web-сервисов в продуктах таких компаний, как BEA Systems, Borland, Hewlett-Packard, IBM, Microsoft, Oracle, Sun Microsystems и Sybase.

Заключение

В этой статье мы рассмотрели эволюцию архитектуры Web-решений, начиная от простейших хранилищ HTML-страниц и заканчивая современными корпоративными решениями, интегрированными с корпоративными информационными системами и информационными системами партнеров. Попутно мы обсудили задачи, возникающие на каждом этапе развития Web-приложений и технологии, решающие эти задачи, включая CGI, ISAPI, ASP, JSP, применение скриптовых языков, ActiveX и Java-аплетов, взаимодействие с серверами приложений и с базами данных, применение COM, CORBA и EJB, создание и применение Web-сервисов, основанных на XML. Мы также рассмотрели средства создания таких решений, а именно: корпоративные порталы, средства управления информационным наполнением Web-сайтов, приложения для электронной коммерции.

IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.

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

28.07.2016
Сервера и протоколы
Комментариев нет

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

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последних два примера – это не проста сервера, а целый набор серверов).

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу. Например, при помощи HTTP протокола браузер отправляет специальное HTTP сообщение, в котором указано какую информацию и в каком виде он хочет получить от сервера, сервер, получив такое сообщение, отсылает браузеру в ответ похожее по структуре сообщение (или несколько сообщений), в котором содержится нужная информация, обычно это HTML документ.

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

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

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

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

Простая схема взаимодействия клиент-сервер

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

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

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

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?». Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

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

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

Архитектура «клиент-сервер»

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

Двухуровневая модель взаимодействия клиент-сервер

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер). Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит распределение операций, но в то же самое время данный подход не такой надежный, как двухзвенная архитектура. На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

Многоуровневая архитектура взаимодействия клиент-сервер

Типичный пример трехуровневой модели клиент-сервер. Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

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

Преимущества и недостатки архитектуры клиент-сервер

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

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

Читать еще: Архитектура мобильного приложения

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