Каким образом браузер определяет строки заголовка, которые нужно включить в запрос? Каким образом сервер определяет строки заголовка, которые нужно включить в ответ? Для браузера включаемые строки зависят от фирмы-разработчика, версии продукта (например, браузер, разработанный для спецификации НТТР/1.0, не сможет генерировать строки, характерные для спецификации НТТР/1.1), пользовательских настроек (например, языка), наличия на компьютере версии (возможно, устаревшей) запрашиваемого объекта. Аналогичная ситуация характерна для серверов: существуют различные программные продукты, их версии, настройки, совместно влияющие на включаемые строки заголовка.
9.5 Взаимодействие пользователя с сервером
Мы выяснили, что HTTP-сервер не запоминает информацию о состоянии соединения. Это упрощает разработку сервера и позволяет достичь значительной производительности за счет одновременного обслуживания сотен ТСР-соединений. Тем не менее возможность распознавания пользователей сервером является весьма желательной. Причиной этому может служить необходимость разграничения прав доступа к информации, находящейся на сервере, либо предоставление каждому пользователю собственного набора информационных услуг. Протокол HTTP предусматривает два механизма идентификации пользователей: авторизацию и объекты cookie.
9.6 Авторизация
Вероятно, вам приходилось сталкиваться с ситуациями, когда сервер предлагал вам ввести имя пользователя и пароль для доступа к своему информационному пространству. Подобный механизм доступа называется авторизацией. Запрос и получение авторизации в HTTP зачастую производятся с помощью особых заголовков и кодов состояния. Рассмотрим следующий пример. Пусть клиент инициирует запрос объекта, причем объект находится на сервере, требующем авторизации.
Сначала клиент формирует обычный запрос, не содержащий специальных строк. Сервер возвращает ответ с пустым телом и кодом состояния 401 Authorization Required. В специальной строке WWW-Authenticate: заголовка содержится описание метода проведения авторизации; как правило, это описание указывает на необходимость ввести имя пользователя и пароль.
Получив подобное сообщение, клиент запрашивает имя пользователя и пароль. По окончании ввода генерируется новый запрос, содержащий строку Authorization: с введенными пользователем данными. Получив первый объект, клиент продолжает отсылать серверу имя пользователя и пароль для всех остальных запрашиваемых объектов. Обычно это происходит до тех пор, пока работа клиента не будет завершена пользователем. Таким образом, в течение всего сеанса с клиентом имя пользователя и пароль кэшируются и не запрашиваются у пользователя многократно.
Механизм HTTP-авторизации не позволяет организовать надежную защиту данных сервера от несанкционированного доступа. Там же мы изучим более сложные и безопасные схемы авторизации.
9.7 Cookie
Объекты cookie являются альтернативным авторизации средством идентификации пользователей. Описание cookie находится в документе RFC 2109. Обычно объекты cookie находят применение в Интернет-порталах (например, Yahoo!), электронной коммерции (например, Amazon) и рекламе (например, DoubleClick).
Технология cookie подразумевает наличие четырех основных компонентов:
□ заголовочной cookie-строки в ответном сообщении сервера;
□ заголовочной cookie-строки в запросе клиента;
□ cookie-файла, находящегося на стороне клиента и обрабатываемого браузером;
□ удаленной базы данных, расположенной на web-сайте.
Рассмотрим типичный пример использования объекта cookie. Предположим, пользователь применяет для доступа в web один и тот же браузер (пусть это будет Internet Explorer) и впервые оказывается на сайте, предоставляющем услуги электронной коммерции. Доступ к сайту осуществляется при помощи технологии cookie. При первом доступе сервер генерирует уникальный идентификационный номер для пользователя, создает в своей базе данных запись с индексом, равным идентификационному номеру, и отсылает клиенту пользователя ответное сообщение, включающее специальную строку Set-cookie: заголовка, содержащую идентификационный номер. Пример такой строки:
Set-cookie: 1678453
Получив ответ, браузер анализирует его и добавляет строку
Set-cookie:
вcookie-файл. Этот файл содержит имена хостов и соответствующие идентификационные номера серверов. Каждый раз при формировании запроса к web-сайту браузер обращается к cookie-файлу, извлекает из него нужный идентификационный номер, включает его в запрос и отсылает серверу. В каждом таком запросе содержится строка заголовка вида:
cookie: 1678453
Таким образом, сервер может собирать информацию о деятельности у себя пользователя: времени доступа, посещенных страницах и т. п. Это, в свою очередь, позволяет серверу организовать «карту покупателя» со списком сделанных во время сеанса покупок и дает возможность сразу оплатить их.
При повторных входах на сайт идентификационный номер снова будет передан серверу. Сервер, располагающий информацией о предыдущих покупках пользователя, может на ее основе составить рекомендации о новых покупках. Зачастую подобные коммерческие сайты позволяют пользователям пройти регистрацию, указав свои имя, фамилию, почтовый адрес, номер кредитной карты, адрес электронного почтового ящика и др. Введенные данные заносятся в базу данных сервера. Именно с помощью описанного механизма осуществляется «покупка одним щелчком мыши» — потребность ввода личных данных отпадает.
Итак, объекты cookie представляют собой средство идентификации пользователей. При первом сеансе доступа пользователь вводит какой-либо идентификационный параметр (например, свое имя), а сервер в ответном сообщении отсылает пользователю заголовочную cookie-строку, идентифицируя его. Кроме того, технология cookie позволяет создать подобие дополнительного «сеансового уровня» для протокола HTTP, не запоминающего информацию о соединении. К примеру, когда пользователь подключается к web-приложению электронной почты, браузер отсылает cookie-информацию серверу, позволяющую идентифицировать пользователя во время сеанса.
Несмотря на то что объекты cookie позволяют упростить процесс покупок для пользователя, они, как и приведенная выше схема авторизации, весьма ненадежны с точки зрения обеспечения конфиденциальности информации. Как мы убедились, процедура регистрации приводит к выдаче пользователем данных личного характера, которые при использовании небезопасного cookie-доступа могут стать известны другим людям. Кроме того, объекты cookie могут применяться для сбора информации о поведении пользователя на множестве web-сайтов. Web-страницы, содержащие бан-нерную рекламу, прибегают к cookie для получения объектов баннерной рекламы (как правило, рисунков в формате JPEG и GIF) с серверов рекламного агентства. Каждый из запросов к серверу рекламного агентства может содержать объект cookie, генерируемый сайтом рекламного агентства. Поскольку агентства обычно связаны с множеством web-страниц, это позволяет им отслеживать пути отдельных пользователей в web и анализировать собранную информацию.
9.8 Метод GET
Web-кэширование, то есть сохранение уже загруженных объектов, способно ощутимо сократить время загрузки web-страниц и сетевой трафик. Кэширование может осуществляться как клиентом (браузером пользователя), так и промежуточным сетевым кэш-сервером. Последний будет рассмотрен в конце этой главы, а пока обратимся к кэшированию на клиенте.
Несмотря на то что кэширование способно снизить задержку на доставку объектов, необходимых для открытия документов, оно порождает новую проблему: содержимое кэшируемого объекта постоянно устаревает. Объект, находящийся на web-сервере, может быть изменен, после чего он перестает соответствовать уже загруженному объекту. К счастью, протокол HTTP располагает средством, позволяющим при необходимости обновлять кэшированные объекты; это средство представляет собой метод GET с условием. В HTTP существует так называемый условный GET-запрос, который использует метод GET и строку If-Modified-Since: заголовка.
Для того чтобы продемонстрировать описанный механизм в действии, рассмотрим пример. Пусть сначала браузер запрашивает некэшированный объект с web-сервера:
GET /fruit/kiwi. gifHTTP/1.0
User-agent: Mozilla/4.0
Затем происходит передача ответного сообщения сервера с требуемым объектом:
НТТР/1.0 200 ОК
Date: Wed, 12 Aug 1998 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 09:23:24
Content-Type: image/gif
(data data data data data …)
Клиент отображает объект на экране и сохраняет его в своем локальном кэше. Кроме того, вместе с объектом сохраняется время его последнего изменения. Пусть через неделю пользователь снова соединяется с тем же сервером, при этом объект остается в кэше. Поскольку за прошедшую неделю объект на сервере мог быть изменен, браузер формирует запрос, отправляемый методом GET с условием:
GET /fruit/kiwi. gif HTTP/1.0
User-agent: Mozilla/4.0
If-modified-since: Mon. 22 Jun 1998 09:23:24
Обратите внимание на то, что содержимое строки If-modified-since: совпадает с содержимым строки Last-Modified: первого запроса. Запрос является указанием серверу осуществить пересылку объекта в случае, если с момента предыдущей пересылки последний был изменен. Если изменения не произошло, будет получен следующий ответ:
HTTP/1.0 304 Not
ModifiedDate: Wed. 19 Aug 1998 15:39:29
Server: Apache/1.3.0 (Unix)
(пустое тело)
Как мы видим, несмотря на отсутствие изменений объекта, сервер отсылает клиенту ответ, однако тело сообщения остается пустым. Новая посылка идентичного объекта привела бы к бесполезной трате временных и сетевых ресурсов, особенно ощутимой при большом размере объекта. Обратите внимание на то, что в ответе содержится код состояния 304 NotModified, означающий, что клиент может использовать кэшированную версию объекта.
10. Резюме
На этой лекции мы рассмотрели концептуальные и практические аспекты, касающиеся сетевых приложений.
World Wide Web представляет собой распределенный репозитарий гипермедийной информации, доступ к которой осуществляется с помощью ни интерактивного броузера. Основная часть документов Web представлена на языке HTML, несмотря на то, что было предложено несколько альтернативных языков. Кроме текста, документ на языке HTML содержит теги, которые определяют компоновку документа и форматирование его элементов. Изображения не включаются непосредственно в документ — тег в документе указывает место, куда должно быть вставлено изображение, и источник изображения. Для указания элементов документа HTML, которые ссылаются на внешние ресурсы, применяется тег анкера. При отображении документа броузер отмечает такие элементы как предназначенные для выбора; если пользователь выбирает эти элементы, броузер следует по ссылке на внешний ресурс для получения нового документа.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |


