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

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

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

Клиентские технологии

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

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

Код, интерпретируемый браузером

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

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

Java-аплеты

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

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

Элементы управления ActiveX

Некоторые из современных браузеров (в частности, Microsoft Internet Explorer) могут служить контейнерами для элементов управления ActiveX специальных COM-серверов, выполняющихся в адресном пространстве браузера. Ссылки на такие элементы управления могут содержаться в составе веб-страницы. Сами элементы управления ActiveX представляют собой динамически загружаемые библиотеки, выполняющиеся в адресном пространстве браузера.

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

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

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

Приложения Macromedia Flash

Еще одна очень популярная веб-технология, основанная на выполнении кода в клиентском приложении, приложения Macromedia Flash. Macromedia Flash Player, как и виртуальная Java-машина, обладает ограниченными возможностями с точки зрения доступа к ресурсам клиентского компьютера. Так, приложения Flash не имеют доступа к файловой системе, за исключением служебного каталога Macromedia Flash Player, а доступ к внешним устройствам ограничивается микрофонами и видеокамерами. Доступ к сетевым ресурсам ограничивается доменом, с которого было получено данное приложение. Отметим, что, так же как и Java-аплеты и элементы управления ActiveX, приложения Flash могут управляться с помощью кода JavaScript, присутствующего на той же странице. Поскольку Macromedia Flash Player для Microsoft Internet Explorer сам по себе является элементом управления ActiveX, он использует некоторые возможности элементов управления ActiveX для доступа к свойствам приложений Flash из скриптовых языков.

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

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

Серверные технологии

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

Скрипты и исполняемые файлы

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

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

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

Проблему ограниченной производительности веб-приложений, которые выполняются в отдельном адресном пространстве, можно решить, создав приложение в виде библиотеки, загружающейся в адресное пространство веб-сервера и при необходимости остающейся там для обработки последующих запросов от других клиентов (понятно, что в этом случае веб-сервер должен поддерживать загрузку таких библиотек). Подобные приложения для Microsoft Internet Information Servise носят название ISAPI (Internet Server Application Program Interface), а такие библиотеки для весьма популярного веб-сервера Apache называются Apache DSO (Dynamic Shared Objects). Означенные технологии существуют уже довольно продолжительное время, но все еще весьма популярны.

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

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

Веб-страницы с фрагментами серверного кода

ASP и ASP .NET

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

Одной из наиболее популярных сегодня технологий, реализующих идею создания веб-страниц с фрагментами кода, является ASP .NET ключевая в архитектуре Microsoft .NET Framework. Основное отличие этой технологии от ASP в плане архитектуры приложений заключается в том, что код, присутствующий на веб-странице, не интерпретируется, а компилируется и кэшируется, что способствует повышению производительности приложений. Кроме того, указанная технология позволяет создавать так называемые серверные компоненты, возвращающие в браузер HTML-код с интерпретируемыми браузером фрагментами кода на скриптовых языках и способные предоставить более удобный пользовательский интерфейс, нежели обычный HTML-код. Важными особенностями серверных компонентов ASP .NET являются возможность обработки на сервере событий, возникающих в клиентском приложении, и возможность генерировать HTML-, WML- и CHTML-код в зависимости от типа клиента и поддерживаемых им языков разметки и протоколов передачи данных.

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

Java Server Pages

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

Веб-приложения, основанные на применении веб-страниц с внедренными в них фрагментами серверного кода

Говоря о технологии JSP, нельзя не отметить относительно новую спецификацию Sun под названием Java Server Faces. Эта спецификация описывает правила создания веб-приложений с удобным пользовательским интерфейсом (схожим по функциональности с интерфейсом Windows-приложений) и разработки серверных компонентов, реализующих подобный интерфейс. Средства разработки Java-приложений, поддерживающие указанную спецификацию, в идеале должны позволить создавать веб-приложения, основанные на J2EE, примерно с той же скоростью и степенью удобства, что и средства разработки.NET-приложений.

Из других популярных технологий, реализующих создание веб-страниц с фрагментами кода, выполняемого на сервере, отметим PHP (Personal Home Pages). Данная технология основана на применении CGI-приложений, интерпретирующих внедренный в HTML-страницу код на скриптовом языке. Несмотря на наличие недостатков, присущих всем CGI-приложениям, PHP пользуется немалой популярностью благодаря простоте разработки и доступности для различных платформ, особенно при создании приложений, не отличающихся высокими требованиями к масштабируемости и надежности.

Применение инфраструктурного ПО общего назначения

Чем выше посещаемость сайта и больше объем обрабатываемых им данных, тем более строгими будут требования к производительности и масштабируемости веб-приложений. Чем более серьезные задачи решаются с помощью веб-приложения, тем выше требования к его надежности и безопасности. Чаще всего для удовлетворения этих требований бизнес-логика, реализованная в веб-приложении, а также службы обработки данных и реализации транзакций отделяются от пользовательского интерфейса приложений и реализуются в виде отдельных приложений, библиотек, сервлетов, которые в общем случае называются бизнес-объектами. Сегодня в подавляющем большинстве современных корпоративных решений применяются либо серверы, поддерживающие спецификацию Java2 Enterprise Edition, либо серверы, базирующиеся на применении служб серверных версий Windows, технологиях COM и Microsoft .NET.

Бизнес-объекты могут обладать различной функциональностью. Как правило, они предоставляют доступ к данным, управляемым какой-либо серверной СУБД, нередко доступ к данным корпоративных информационных систем. Довольно часто бизнес-объекты реализуют какую-либо часть корпоративной информационной системы, создание которой изначально предполагало включение внешнего веб-сервера в качестве составной части корпоративной информационной системы (например, в качестве одного из источников данных для CRM-приложения). Готовые CRM- и ERP-системы ведущих производителей, таких как SAP, PeopleSoft, Siebel, обычно содержат в своем составе подобные бизнес-объекты, а зачастую и обращающиеся к ним готовые веб-приложения, например порталы для клиентов и удаленных пользователей, приложения для осуществления электронной коммерции и иные приложения.

Веб-службы

информационным системам многих предприятий уже не один десяток лет. А поскольку предприятия нередко начинали свое развитие со стихийной автоматизации отдельных видов деятельности, то сегодня многие из них сталкиваются с проблемой интеграции приложений, создававшихся в разные годы для разных платформ. Одним из средств подобной интеграции является технология веб-служб, использующая для обмена данными стандартный протокол HTTP. Создавать веб-службы можно и в виде исполняемых файлов, и в виде библиотек, и в виде интерпретируемого кода; существуют также средства представления бизнес-объектов, основанных на различных технологиях, в виде веб-служб (эту технологию сегодня поддерживают все ведущие производители офисных продуктов), средств разработки, СУБД, серверов приложений и операционных систем. Методы веб-служб можно вызывать из обычных приложений, веб-приложений, других веб-служб. В последнее время наблюдается массовое появление приложений, использующих веб-службы, в том числе предназначенных для конечных пользователей (к таким приложениям, например, относятся приложения семейства Microsoft Office System, позволяющие при помощи веб-служб пользоваться данными словарей, энциклопедий, систем онлайнового перевода, служб онлайнового заказа товаров, см., например, статью «Интернет и офисные приложения», № 10’2004).

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

[Введите текст]

Серверы. Основные понятия серверов

Модель клиент-сервер

Классификация стандартных серверов

Список использованной литературы

Серверы. Основные понятия серверов

Сервер (от англ. server, обслуживающий). В зависимости от предназначения существует несколько определений понятия сервер.

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

2. Сервер (программное обеспечение) - программное обеспечение, принимающее запросы от клиентов (в архитектуре клиент-сервер).

3. Сервер (аппаратное обеспечение) - компьютер (или специальное компьютерное оборудование) выделенный и/или специализированный для выполнения определенных сервисных функций.

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

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

Модель клиент-сервер

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

Формат запросов клиента и ответов сервера определяется протоколом. Спецификации открытых протоколов описываются открытыми стандартами, например, протоколы Интернета определяются в документах RFC.

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

Классификация стандартных серверов

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

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

inetd от англ. internet super-server daemon демон сервисов IP - стандартное средство UNIX-систем - программа, позволяющая писать серверы TCP/IP (и сетевых протоколов других семейств), работающие с клиентом через перенаправленные inetd потоки стандартного ввода и вывода (stdin и stdout).

RPC от англ. Remote Procedure Call удаленный вызов процедур - система интеграции серверов в виде процедур доступных для вызова удаленным пользователем через унифицированный интерфейс. Интерфейс изобретенный Sun Microsystems для своей операционной системы (SunOS, Solaris; Unix-система), в настоящее время используетстся как в большинстве Unix-систем, так и в Windows.

Прикладные клиент-серверные технологии Windows:

(D-)COM (англ. (Distributed) Component Object Model - модель составных объектов) и др. - Позволяет одним программам выполнять операции над объектами данных используя процедуры других программ. Изначально данная технология предназначена для их «внедрения и связывания объектов» (OLE англ. Object Linking and Embedding), но, в общем, позволяет писать широкий спектр различных прикладных серверов. COM работает только в пределах одного компьютера, DCOM доступна удаленно через RPC.

Active-X - Расширение COM и DCOM для создания мультимедиа-приложений.

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

Большинство внутренних и сетевых специфических серверов Windows работают через универсальные серверы (RPC, (D-)COM).

Сетевые службы обеспечивают функционирование сети, например серверы DHCP и BOOTP обеспечивают стартовую инициализацию серверов и рабочих станций, DNS - трансляцию имен в адреса и наоборот.

Серверы туннелирования (например, различные VPN-серверы) и прокси-серверы обеспечивают связь с сетью, недоступной роутингом.

Серверы AAA и Radius обеспечивают в сети единую аутентификацию, авторизацию и ведение логов доступа.

Информационные службы. К информационным службам можно отнести как простейшие серверы сообщающие информацию о хосте (time, daytime, motd), пользователях (finger, ident), так и серверы для мониторинга, например SNMP. Большинство информационных служб работают через универсальные серверы.

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

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

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

Другие серверы позволяют монтировать дисковые разделы сервера в дисковое пространство клиента и полноценно работать с файлами на них. Это позволяют серверы протоколов NFS и SMB. Серверы NFS и SMB работают через интерфейс RPC.

Недостатки файл-серверной системы:

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

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

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

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

Серверы доступа к данным обслуживают базу данных и отдают данные по запросам. Один из самых простых серверов подобного типа - LDAP (англ. Lightweight Directory Access Protocol - облегчённый протокол доступа к спискам).

Для доступа к серверам баз данных единого протокола не существует, однако все серверы баз данных объединяет использование единых правил формирования запросов - язык SQL (англ. Structured Query Language - язык структурированных запросов).

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

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

Для организации конференций существует серверы новостей, работающие по протоколу NNTP.

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

Существует большое количество других чат-протоколов, например ICQ или Jabber.

Серверы удаленного доступа

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

Для обеспечения доступа к командной строке служат серверы telnet, RSH, SSH.

Графический интерфейс для Unix-систем - X Window System, имеет встроенный сервер удаленного доступа, так как с такой возможностью разрабатывался изначально. Иногда возможность удаленного доступа к интерфейсу Х-Window неправильно называют «X-Server» (этим термином в X-Window называется видеодрайвер).

Стандартный сервер удаленного доступа к графическому интерфейсу Microsoft Windows называется терминальный сервер.

Некоторую разновидность управления (точнее мониторинга и конфигурирования), также, предоставляет протокол SNMP. Компьютер или аппаратное устройство для этого должно иметь SNMP-сервер.

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

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

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

Также необходимо выделить пакеты серверов и сопутствующих программ (например, комплект веб-сервер/PHP/MySQL для быстрой развертки хостинга) для установки под Windows (для Unix свойственна модульная или «пакетная» установка каждого компонента, поэтому такие решения редки).

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

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

Прокси-сервер (от англ. proxy - «представитель, уполномоченный») служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кеша (в случаях, если прокси имеет свой кеш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях. Также прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.

Вывод ы

сервер формат п рокси windows

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

Список использ ованной литературы

1. Дрога А.А., Жукова П.Н., Копонев Д.Н., Лукьянов Д.Б., Прокопенко А.Н. Информатика и математика. - Минск, 2008.

2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика - 3-е изд. - М.: «Вильямс», 2003.

3. Кузнецов С.Д. Основы баз данных. - 1-е изд. - М.: «Интернет- университет информационных технологий - ИНТУИТ.ру», 2005.

4. Скотт В. Эмблер, Прамодкумар Дж. Садаладж. Рефакторинг баз данных: эволюционное проектирование - М.: «Вильямс», 2007.

5. А.Н. Морозевич, А.М. Зеневич Информатика. Минск, 2008.

6.Титоренко Г.А. Информационные технологии управления. М., Юнити: 2002.

7. Мельников В. Защита информации в компьютерных системах. - М.: Финансы и статистика, Электронинформ, 1997.

Размещено на Allbest.ru

...

Подобные документы

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

контрольная работа , добавлен 13.12.2010

Общие сведения об операционной системе Linux. Анализ информации о серверах. Основные прикладные клиент-серверные технологии Windows. Сведения о SQL-сервере. Общая информация о MySQL–сервере. Установка и специфика конфигурирования MYSQL-сервера на LINUX.

курсовая работа , добавлен 16.12.2015

Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.

курсовая работа , добавлен 11.04.2010

Архитектура "клиент-сервер". Системный анализ базы данных "Газета объявлений", ее инфологическое и физическое проектирование. Программирование на стороне SQL-сервера. Разработка клиентской части в Borland C++ Builder 6.0 и с помощью Web-технологий.

курсовая работа , добавлен 07.07.2013

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

дипломная работа , добавлен 08.11.2010

Проектирование физической и логической моделей удаленной базы данных для АЗС. Разработка базы данных в СУБД Firebird с помощью утилиты IBExpert. Создание клиентского приложения для Windows с использованием клиент-серверной технологии в среде C++ Builder.

курсовая работа , добавлен 18.01.2017

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

курсовая работа , добавлен 24.08.2012

Проектирование и разработка базы данных в РСУБД Firebird. Последовательность создания приложения, основанного на клиент-серверной технологии и работающего в операционной системе Windows. Хранимые процедуры и триггеры. Доступ к сети и транзакции.

курсовая работа , добавлен 27.07.2013

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

курсовая работа , добавлен 28.07.2013

Архитектура "клиент-сервер". Параллельная обработка данных в многопроцессорных системах. Модернизация устаревших информационных систем. Характерные черты современных серверных СУБД. Наиболее популярные серверные СУБД. Распределенные запросы и транзакции.

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

Файл-серверная технология;

Технология клиент-сервер.

Файл-серверная технология – это работа в сетевом пространстве с доступом к файлам СУБД, хранящимся на сервере.

Обработка запроса одного пользователя:

· Обращение к БД (запрос)

· Перекачка данных с блокировкой доступа других пользователей

· Обработка данных на компьютере пользователя

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

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

Недостатки файл-серверной системы очевидны:

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

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

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

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

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

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

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

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

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

Таким образом, все вышеперечисленные недостатки файл-серверной схемы устраняются в архитектуре клиент-сервер :

Массивы данных не перекачиваются по сети от сервера БД на компьютер пользователя. Требования к пропускной способности сети понижаются. Это делает возможным одновременную работу большого числа пользователей с большими объемами данных.
Обработка данных осуществляется на сервере БД, а не в компьютере пользователей. Что позволяет использовать более простые, а значит, дешевые компьютеры на клиентских местах.
Блокировки (захвата) данных одним пользователем не происходит.
Обеспечивается доступ пользователя не к целому файлу, а только к тем данным из него, с которыми пользователь имеет право работать.

Департамент общего и профессионального образования Брянской области

Государственное образовательное учреждение

Клинцовский текстильный техникум

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Технология «Клиент – сервер»

Студент гр. А-90______________________(Петроченко А.О.)

Преподаватель _______________________ (Широкова А.Л.)

Клинцы – 2011

1. Серверы. Основные понятия серверов

2. Модель клиент-сервер

3. Классификация стандартных серверов

4. Вывод

1. Серверы. Основные понятия серверов

2. Модель клиент-сервер

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

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

По такой схеме могут быть построены системы обработки данных на основе СУБД, почтовые и другие системы. Мы будем говорить о базах данных и системах на их основе. И здесь удобнее будет не просто рассматривать клиент-серверную архитектуру, а сравнить ее с другой - файл-серверной.

В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..

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

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

Рис. Сравнение файл-серверной и клиент-серверной моделей

В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер, делящие между собой те функции, которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т.п..

Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).

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

Что дает архитектура клиент-сервер?

Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему?

Надежность

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

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

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

Масштабируемость

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

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

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

Безопасность

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

Гибкость

В приложении, работающем с данными, можно выделить три логических слоя:

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

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

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

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

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

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

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

1) В файл-серверной системе мы "просто" вносим изменения в приложение и обновляем его версии на рабочих станциях. Но это "просто" влечет за собой максимальные трудозатраты.

2) В двухуровневой клиент-серверной системе, если алгоритм расчета зарплаты реализован на сервере в виде правила расчета зарплаты, его выполняет сервер бизнес-правил, выполненный, например, в виде OLE-сервера, и мы обновим один из его объектов, ничего не меняя ни в клиентском приложении, ни на сервере баз данных.

Цель лекции: показать, каким образом в веб-технологиях реализуются общие принципы клиент-серверных технологий. Рассмотреть ключевые элементы базового протокола HTTP.

Предметом данного курса являются технологии глобальной сети World Wide Web (сокращенно WWW или просто Web). На русском языке распространенным вариантом является название "Веб".

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

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

Клиент-серверные технологии Веб

Базовым протоколом сети гипертекстовых ресурсов Веб является протокол HTTP. В его основу положено взаимодействие "клиент-сервер ", то есть предполагается, что:

Потребитель-клиент инициировав соединение с поставщиком-сервером посылает ему запрос;

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

При этом возможны два способа организации работы компьютера-клиента:

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

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

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

Протокол http

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста.

Центральным объектом в HTTP является ресурс , на который указывает URI в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя изначально данный протокол предназначен для передачи символьной информации. На первый взгляд это может показаться излишней тратой ресурсов. Действительно, данные в символьном виде занимают больше памяти, сообщения создают дополнительную нагрузку на каналы связи, однако подобный формат имеет много преимуществ. Сообщения, передаваемые по сети, удобочитаемы, и, проанализировав полученные данные, системный администратор может легко найти ошибку и устранить ее. При необходимости роль одного из взаимодействующих приложений может выполнять человек, вручную вводя сообщения в требуемом формате.

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

Всё программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:

Серверы - поставщики услуг хранения и обработки информации (обработка запросов).

Клиенты - конечные потребители услуг сервера (отправка запросов).

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

"Классическая" схема HTTP-сеанса выглядит так.

Установление TCP-соединения.

Запрос клиента.

Ответ сервера.

Разрыв TCP-соединения.

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

В состав HTTP-запроса, передаваемого клиентом серверу, входят следующие компоненты.

Строка состояния (иногда для ее обозначения используют также термины строка-статус, или строка запроса).

Поля заголовка.

Пустая строка.

Тело запроса.

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

Рис. 1.1. Структура запроса клиента.

Строка состояния имеет следующий формат:

метод_запроса URL_pecypca версия_протокола_НТТР

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

Метод , указанный в строке состояния, определяет способ воздействия на ресурс, URL которого задан в той же строке. Метод может принимать значения GET, POST, HEAD, PUT, DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST.

GET. Согласно формальному определению, метод GET предназначается для получения ресурса с указанным URL. Получив запрос GET, сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.

POST. Согласно тому же формальному определению, основное назначение метода POST - передача данных на сервер. Однако, подобно методу GET, метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET, URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.

Методы HEAD и PUT являются модификациями методов GET и POST.

Версия протокола HTTP , как правило, задается в следующем формате:

HTTP/версия.модификация

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

Имя_поля: Значение

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

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

Таблица 1.1. Поля заголовка запроса HTTP.
Поля заголовка HTTP-запроса	Значение
	Доменное имя или IP-адрес узла, к которому обращается клиент
	URL документа, который ссылается на ресурс, указанный в строке состояния
	Адрес электронной почты пользователя, работающего с клиентом
	MIME-типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
	Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
	Перечень поддерживаемых наборов символов
	MIME-тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
	Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
	Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
	Используется для управления TCP-соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP-соединение, чтобы оно могло быть использовано для последующих запросов
	Информация о клиенте

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

Ниже представлен пример HTML-запроса, сгенерированного браузером

GET http://oak.oakland.edu/ HTTP/1.0

Connection: Keep-Alive

User-Agent: Mozilla/4.04 (Win95; I)

Host: oak.oakland.edu

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Language: en

Accept-Charset: iso-8859-l,*,utf-8

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

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

Строка состояния.

Поля заголовка.

Пустая строка.

Тело ответа.

Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:

Версия_протокола Код_ответа Пояснительное_сообщение

Версия_протокола задается в том же формате, что и в запросе клиента, и имеет тот же смысл.

Код_ответа - это трехзначное десятичное число, представляющее в закодированном виде результат обслуживания запроса сервером.

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

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

HТТР/1.0 200 ОК

Как видно, за версией протокола HTTP 1.0 следует код 200. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) - номер данного сообщения.

В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов.

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

2 - успешная обработка запроса клиента.

3 - перенаправление запроса. Чтобы запрос был обслужен, необходимо предпринять дополнительные действия.

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

5 - ошибка сервера. По тем или иным причинам сервер не в состоянии выполнить запрос.

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

Таблица 1.2. Классы кодов ответа сервера.
	Расшифровка	Интерпретация
		Часть запроса принята, и сервер ожидает от клиента продолжения запроса
		Запрос успешно обработан, и в ответе клиента передаются данные, указанные в запросе
		В результате обработки запроса был создан новый ресурс
		Запрос принят сервером, но обработка его не окончена. Данный код ответа не гарантирует, что запрос будет обработан без ошибок.
	Partial Content	Сервер возвращает часть ресурса в ответ на запрос, содержавший поле заголовка Range
	Multiple Choice	Запрос указывает более чем на один ресурс. В теле ответа могут содержаться указания на то, как правильно идентифицировать запрашиваемый ресурс
	Moved Permanently	Затребованный ресурс больше не располагается на сервере
	Moved Temporarily	Затребованный ресурс временно изменил свой адрес
		В запросе клиента обнаружена синтаксическая ошибка
		Имеющийся на сервере ресурс недоступен для данного пользователя
		Ресурс, указанный клиентом, на сервере отсутствует
	Method Not Allowed	Сервер не поддерживает метод, указанный в запросе
	Internal Server Error	Один из компонентов сервера работает некорректно
	Not Implemented	Функциональных возможностей сервера недостаточно, чтобы выполнить запрос клиента
	Service Unavailable	Служба временно недоступна
	HTTP Version not Supported	Версия HTTP, указанная в запросе, не поддерживается сервером

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

Таблица 1.3. Поля заголовка ответа веб-сервера.
Имя поля	Описание содержимого
	Имя и номер версии сервера
	Время в секундах, прошедшее с момента создания ресурса
	Список методов, допустимых для данного ресурса
Content-Language	Языки, которые должен поддерживать клиент для того, чтобы корректно отобразить передаваемый ресурс
	MIME -тип данных, содержащихся в теле ответа сервера
	Число символов, содержащихся в теле ответа сервера
	Дата и время последнего изменения ресурса
	Дата и время, определяющие момент генерации ответа
	Дата и время, определяющие момент, после которого информация, переданная клиенту, считается устаревшей
	В этом поле указывается реальное расположение ресурса. Оно используется для перенаправления запроса
	Директивы управления кэшированием. Например, no-cache означает, что данные не должны кэшироваться

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

Ниже представлен пример ответа сервера на запрос, приведенный в предыдущем разделе. В теле ответа содержится исходный текст HTML-документа.

Server: Microsoft-IIS/5.1

X-Powered-By: ASP.NET

Content-Type: text/html

Accept-Ranges: bytes

ETag: "b66a667f948c92:8a5"

Content-Length: 426

Operand1:

Operand2:

Operation:

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

Поле с именем Content-type может встречаться как в запросе клиента, так и в ответе сервера. В качестве значения этого поля указывается MIME -тип содержимого запроса или ответа. MIME -тип также передается в поле заголовка Accept, присутствующего в запросе.

Спецификация MIME (Multipurpose Internet Mail Extension - многоцелевое почтовое расширение Internet) первоначально была разработана для того, чтобы обеспечить передачу различных форматов данных в составе электронных писем. Однако применение MIME не исчерпывается электронной почтой. Средства MIME успешно используются в WWW и, по сути, стали неотъемлемой частью этой системы.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority).

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

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

тип/подтип

Поскольку в подавляющем большинстве случаев в ответ на запрос клиента сервер возвращает исходный текст HTML-документа, то в поле Content-type ответа обычно содержится значение text/html. Здесь идентификатор text описывает тип, сообщая, что клиенту передается символьная информация, а идентификатор html описывает подтип, т.е. указывает на то, что последовательность символов, содержащаяся в теле ответа, представляет собой описание документа на языке HTML.

Перечень типов и подтипов MIME достаточно велик. В табл. 1.4 приведены примеры MIME -типов, наиболее часто встречающиеся в заголовках HTML-запросов и ответов.

Таблица 1.4. MIME типы данных.
Тип/подтип	Расширение файла	Описание
		Документ, предназначенный для обработки Acrobat Reader
application/msexcel		Документ в формате Microsoft Excel
application/postscript		Документ в формате PostScript
application/x-tex		Документ в формате ТеХ
application/msword		Документ в формате Microsoft Word
		Документ в формате RTF, отображаемый с помощью Microsoft Word
		Изображение в формате GIF
		Изображение в формате JPEG
		Изображение в формате TIFF
		Изображение в формате XBitmap
		ASCII-текст
		Документ в формате HTML
		Аудиофайл в формате MIDI
		Аудиофайл в формате WAV
		Почтовое сообщение
		Сообщение в группы новостей
	Mpeg, .mpg, .mpe	Видеофрагмент в формате MPEG
		Видеофрагмент в формате AVI

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

Единообразный идентификатор ресурса URI (Uniform Resource Identifier) представляет собой короткую последовательность символов, идентифицирующую абстрактный или физический ресурс. URI не указывает на то, как получить ресурс, а только идентифицирует его. Это даёт возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (имена, названия и т.п.). Самые известные примеры URI - это URL и URN.

URL (Uniform Resource Locator) - это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса.

URN (Uniform Resource Name) - это URI, который идентифицирует ресурс в определённом пространстве имён, но, в отличие от URL, URN не указывает на местонахождение этого ресурса.

URL имеет следующую структуру:

<схема>://<логин>:<пароль>@<хост>:<порт>/

схема - схема обращения к ресурсу (обычно сетевой протокол);

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

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

хост - полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста;

порт - порт хоста для подключения;

URL-путь - уточняющая информация о месте нахождения ресурса.