Клиентские технологии
Представление и отображение данных должно осуществляться в соответствии с определенным набором правил, в качестве которого используют html (Hypertext Markup Language). Html по сути не является языком программирования, поскольку не выполняет никаких функций по обработке материала, только по его оформлению и представлению. Теги этого метаязыка помогают получать в окне браузера информацию именно в том виде, в каком желает вебмастер. Отметим, что гипертекст разработан в 1989 году и изначально создавался с целью обмена различной документацией, позволяя браузерам отличать, например, заголовки и подзаголовки от рисунков и текста.
Интернет технологии развивались, html радикально изменился, с учетом новых возможностей появился "усовершенствованный" xhtml (Extensible Hypertext Markup Language) - язык расширенной разметки гипертекста для веб страниц, по возможностям сопоставимый с html и созданный на базе xml.
Разметка страниц со временем усложнилась, и ее стало трудно поддерживать. В связи с этим потребовалось отделить структуру документа от его визуального представления; появились каскадные таблицы стилей (Cascading Style Sheets - CSS). Впервые таблицы стилей в качестве рекомендаций W3C приняты в 1996 году и с тех пор широко используются для верстки сайтов. CSS верстка веб сайтов позволяет, например, одинаково оформить множество элементов, исправив всего одну строку в таблице стилей.
Конечно, оптимальные результаты верстки web сайта могут быть получены только путем умелого сочетания html-кода и каскадной таблицы стилей.
Обычный интернет-пользователь, заходя на тот или иной веб сайт, конечно, обращает внимание на выпадающие меню, падающий снег, бегущую строку. Подобные эффекты могут быть созданы с помощью технологии JavaScript.
JavaScript - это облегченный, интерпретируемый язык программирования с объектно-ориентированными возможностями. Универсальное ядро языка встроено в различные веб-браузеры. Клиентская версия JavaScript позволяет включать в веб-страницы исполняемое содержимое, то есть web страница не обязаны быть статическим html-кодом, а может включать в себя программы, взаимодействующие с пользователем, управляющие браузером и динамически создающие html.
JavaScript развивался много лет, в течение которых выпущено несколько версий этого языка. Например, Microsoft издала версии под именем Jscript. В свою очередь ассоциация Ecma, деятельность которой посвящена стандартизации информационных и коммуникационных технологий, опубликовала три версии, стандартизирующие JavaScript под названием EcmaScript. Последняя и определила стандартную версию базового языка JavaScript, а World Wide Web Consortiums опубликовала рекомендацию DOM, отражающую возможности браузеров по поддержке объектной модели.
Web - браузеры позволяют просматривать страницы сети Интернет.
Как показывает практика, различные браузеры показывают конкретную страницу по-разному. Отображение страниц зависит от работы алгоритмов коррекции, встроенных в браузер, а в разных браузерах эти алгоритмы различны. Internet Explorer и Netscape Navigator, работая под Windows, отображают страницы примерно одинаково, с различиями лишь в таких деталях, как поля и отступы. Однако другие браузеры могут серьезно исказить некоторые страницы. Разработчики с каждой новой версией совершенствуют свои продукты, поэтому чем новее версия браузера, тем меньше он искажает.
Серверные технологии
В области программирования для сети Интернет PHP - один из популярных скриптовых языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов на основе лицензии PHP.
Perl - высокоуровневый интерпретируемый динамический язык программирования общего назначения, созданный Ларри Уоллом, лингвистом по образованию. Основной особенностью языка считаются его богатые возможности для работы с текстом, в том числе работа с регулярными выражениями, встроенная в синтаксис. Перл унаследовал много свойств от языков Си, AWK, скриптовых языков командных оболочек UNIX.
JSP - одна из высокопроизводительных технологий, так как весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Контейнеры сервлетов, способные исполнять JSP страницы, написаны на языке Java, который может работать на различных платформах. JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своём упакованные в файловые архивы.war и.ear. Выгода, которую дает технология JSP в сравнении с другими веб-технологиями заключается в том, что JSP является платформонезависимой, переносимой и легко расширяемой технологией для разработки веб-приложений.
ASP.NET - технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. ASP.NET внешне во многом сохраняет схожесть с более старой технологией ASP, что позволяет разработчикам относительно легко перейти на ASP.NET. В то же время внутреннее устройство ASP.NET существенно отличается от ASP, поскольку она основана на платформе.NET и, следовательно, использует все новые возможности, предоставляемые этой платформой.
ASP.NET не является платформой.
IIS - проприетарный набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT.
Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
Департамент общего и профессионального образования Брянской области
Государственное образовательное учреждение
Клинцовский текстильный техникум
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
Технология «Клиент – сервер»
Студент гр. А-90______________________(Петроченко А.О.)
Преподаватель _______________________ (Широкова А.Л.)
Клинцы – 2011
1. Серверы. Основные понятия серверов
2. Модель клиент-сервер
3. Классификация стандартных серверов
4. Вывод
1. Серверы. Основные понятия серверов
Сервер (от англ. server, обслуживающий). В зависимости от предназначения существует несколько определений понятия сервер.
1. Сервер (сеть) - логический или физический узел сети, обслуживающий запросы к одному адресу и/или доменному имени (смежным доменным именам), состоящий из одного или системы аппаратных серверов, на котором выполняются один или система серверных программ
2. Сервер (программное обеспечение) - программное обеспечение, принимающее запросы от клиентов (в архитектуре клиент-сервер).
3. Сервер (аппаратное обеспечение) - компьютер (или специальное компьютерное оборудование) выделенный и/или специализированный для выполнения определенных сервисных функций.
3. Сервер в информационных технологиях - программный компонент вычислительной системы, выполняющий сервисные функции по запросу клиента, предоставляя ему доступ к определённым ресурсам.
Взаимосвязь понятий. Серверное приложение (сервер) запускается на компьютере, так же называемом "сервер", при этом при рассмотрении топологии сети, такой узел называют "сервером". В общем случае может быть так, что серверное приложение запущено на обычной рабочей станции, или серверное приложение, запущенное на серверном компьютере в рамках рассматриваемой топологии выступает в роли клиента (т.е. не является сервером с точки зрения сетевой топологии).
2. Модель клиент-сервер
Клиент-серверная система характеризуется наличием двух взаимодействующих самостоятельных процессов - клиента и сервера, которые, в общем случае, могут выполняться на разных компьютерах, обмениваясь данными по сети.
Процессы, реализующие некоторую службу, например службу файловой системы или базы данных, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посылки запроса и последующего ожидания ответа от сервера, называются клиентами (clients) .
По такой схеме могут быть построены системы обработки данных на основе СУБД, почтовые и другие системы. Мы будем говорить о базах данных и системах на их основе. И здесь удобнее будет не просто рассматривать клиент-серверную архитектуру, а сравнить ее с другой - файл-серверной.
В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..
Приложение на рабочей станции "отвечает за все" - за формирование пользовательского интерфейса, логическую обработку данных и за непосредственное манипулирование данными. Файловый сервер предоставляет услуги только самого низкого уровня - открытие, закрытие и модификацию файлов. Обратите внимание - файлов, а не базы данных. Система управления базами данных расположена на рабочей станции.
Таким образом, непосредственным манипулированием данными занимается несколько независимых и несогласованных между собой процессов. Кроме того, для осуществления любой обработки (поиск, модификация, суммирование и т.п.) все данные необходимо передать по сети с сервера на рабочую станцию (см. рис. Сравнение файл-серверной и клиент-серверной моделей)
Рис. Сравнение файл-серверной и клиент-серверной моделей
В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер, делящие между собой те функции, которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т.п..
Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).
Таким образом, непосредственным манипулированием данными занимается один процесс. При этом, обработка данных происходит там же, где данные хранятся - на сервере, что исключает необходимость передачи больших объемов данных по сети.
Что дает архитектура клиент-сервер?
Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему?
Надежность
Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:
- атомарность - при любых обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;
- независимость - транзакции, инициированные разными пользователями, не вмешиваются в дела друг друга;
- устойчивость к сбоям - после завершения транзакции, ее результаты уже не пропадут.
Механизм транзакций, поддерживаемый сервером баз данных, намного более эффективен, чем аналогичный механизм в настольных СУБД, т.к. сервер централизованно контролирует работу транзакций. Кроме того, в файл-серверной системе сбой на любой из рабочих станций может привести к потере данных и их недоступности для других рабочих станций, в то время, как в клиент-серверной системе сбой на клиенте, практически, никогда не сказывается на целостности данных и их доступности для других клиентов.
Масштабируемость
Масштабируемость - способность системы адаптироваться к росту количества пользователей и объема базы данных при адекватном повышении производительности аппаратной платформы, без замены программного обеспечения.
Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, разумеется, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что наиболее существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры.
Системы же на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - дайте им только соответствующую аппаратную платформу.
Безопасность
Сервер баз данных предоставляет мощные средства защиты данных от несанкционированного доступа, невозможные в настольных СУБД. При этом, права доступа администрируются очень гибко - до уровня полей таблиц. Кроме того, можно вообще запретить прямое обращение к таблицам, осуществляя взаимодействие пользователя с данными через промежуточные объекты - представления и хранимые процедуры. Так что администратор может быть уверен - никакой слишком умный пользователь не прочитает то, что ему читать неположено.
Гибкость
В приложении, работающем с данными, можно выделить три логических слоя:
- пользовательского интерфейса ;
- правил логической обработки (бизнес-правил);
- управления данными (не следует только путать логические слои с физическими уровнями, о которых речь пойдет ниже).
Как уже говорилось, в файл-серверной архитектуре все три слоя реализуются в одном монолитном приложении, функционирующем на рабочей станции. Поэтому изменения в любом из слоев приводят однозначно к модификации приложения и последующему обновлению его версий на рабочих станциях.
В двухуровневом клиент-серверном приложении, показанном на рисунке выше, как правило, все функции по формированию пользовательского интерфейса реализуются на клиенте, все функции по управлению данными - на сервере, а вот бизнес-правила можно реализовать как на сервере используя механизмы программирования сервера (хранимые процедуры, триггеры, представления и т.п.), так и на клиенте.
В трехуровневом приложении появляется третий, промежуточный уровень, реализующий бизнес-правила, которые являются наиболее часто изменяемыми компонентами приложения (см. рис. Трехуровневая модель клиент-серверного приложения )
Рис. Трехуровневая модель клиент-серверного приложения
Наличие не одного, а нескольких уровней позволяет гибко и с минимальными затратами адаптировать приложение к изменяющимся требованиям бизнеса.
Попробуем все вышеизложенное проиллюстрировать на маленьком примере. Предположим, в некоей организации изменились правила расчета заработной платы (бизнес-правила) и требуется обновить соответствующее программное обеспечение.
1) В файл-серверной системе мы "просто" вносим изменения в приложение и обновляем его версии на рабочих станциях. Но это "просто" влечет за собой максимальные трудозатраты.
2) В двухуровневой клиент-серверной системе, если алгоритм расчета зарплаты реализован на сервере в виде правила расчета зарплаты, его выполняет сервер бизнес-правил, выполненный, например, в виде OLE-сервера, и мы обновим один из его объектов, ничего не меняя ни в клиентском приложении, ни на сервере баз данных.
Web-сервер - это совокупность аппаратно-программных средств, которая принимает HTTP-запросы от клиентов (как правило, web- браузеров) и выдает HTTP-ответы. В простом случае ответ web- сервера - это содержание расположенных на нем файлов: документов, изображений, фильмов и так далее. Такие данные называют статическими: если пользователь запросит несколько раз информацию по одному и тому же адресу, web-сервер выдаст в точности одно и то же содержимое. Для динамического подхода, то есть когда выдаваемая информация будет меняться во времени и/или зависеть от параметров запроса, одного web-сервера недостаточно. В этом случае web-сервер служит переходным звеном между клиентом и некой программной средой, формирующей содержимое HTML-страницы. И здесь напрашивается вопрос: а зачем тогда нужен web-сервер, если динамическую страницу все равно формирует приложение.
При небольшой нагрузке на приложение - несколько одновременно подключенных пользователей (единицы) -web-сервер не является абсолютно необходимым звеном. Практически все существующие на сегодняшний день пакеты разработки web-приложений имеет в своем составе легковесный web-сервер. Достаточно запустить среду разработки на выполнение, и к ней можно подсоединиться браузером и работать с ней по протоколу HTTP.
Проблемы начинаются тогда, когда число одновременно работающих клиентов превышает некоторое критическое значение. И одна из функций web-сервера - это максимально возможное снижение нагрузки за счет ее распределения по разным частям системы. Оптимизация может затрагивать не только работу самого web-сервера, но и начинаться непосредственно с уровня ядра операционной системы. Современные операционные системы могут быть настроены таким образом, что после соединения с клиентом они не будут беспокоить web-сервер до тех пор, пока клиентская сокета не получит данные (с сокеты можно читать входной поток данных), либо пока не придет полный НТТР-запрос.
Такой подход позволяет web-серверу меньше времени простаивать в ожидании получения данных, повышая эффективность системы в целом.
Все современные (полновесные ) web-серверы используют асинхронную обработку поступающих от клиентов запросов. То есть после получения запроса от клиента сервер переадресует этот запрос потоку обработчика (worker). Сам сервер при этом продолжает принимать запросы от клиентов и переадресовывать их обработчикам. Существует несколько стратегий работы с обработчиками.
- - Количество worker может быть жестко задано. При старте сервера запускается, например, 10 потоков. При получении 11-го запроса сервер выдаст клиенту ответ временно недоступен.
- - Worker могут порождаться сервером динамически в зависимости от загрузки. При этом оговаривается начальное число worker, максимально допустимое количество, минимальное и максимальное количество свободных worker.
- - Worker может быть как процессом, так и потоком. Различные процессы не взаимодействуют между собой и не могут разделять данные. В отличие от процессов, потоки имеют общее разделяемое пространство данных и могут обмениваться информацией между собой.
- - Worker-процессы могут запускаться как внутри родительского серверного процесса, так и снаружи. При последнем варианте worker могут быть распределены по разным компьютерам.
- - Worker - вне родительского сервера могут представлять собой непосредственно процессы среды web-приложения.
- - Сервер может отслеживать разные варианты распределения нагрузки между порожденными worker: равномерную или поочередную загрузку.
Комбинируя эти факторы, можно попытаться добиться наилучшей производительности системы в целом.
Для логического разделения, оптимального распределения нагрузки по вычислительным мощностям Worker могут запускаться и на другом (-их) компьютере (-ах), не обязательно на том же самом, где расположен сам принимающий запросы от клиентов сервер. В этом случае общение между сервером и worker происходит по определенному сетевому протоколу. Это уже не может быть HTTP, потому что вместе с полученным запросом worker передается расширенная информация об окружении сервера. В частности, в качестве такого протокола общения может применяться FastCGI.
В современном интернете существует как минимум несколько десятков решений на тему web-серверов, как бесплатных, так и коммерческих. Как правило, коммерческие продукты имеют графический интерфейс управления и настройки сервера, с ними работать гораздо проще. В противоположность этому свободно распространяемые программные продукты обычно конфигурируются при помощи текстовых файлов.
Цель лекции: показать, каким образом в веб-технологиях реализуются общие принципы клиент-серверных технологий. Рассмотреть ключевые элементы базового протокола 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
