Теория и практика разработки современных клиентских веб-приложений

Введение. Структура веб-технологий

Разбить на страницы
Показывать лекцию целиком

Предметом данного курса являются технологии глобальной сети 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.

    Поля заголовка запроса HTTP
    Поля заголовка HTTP-запроса Значение
    Host Доменное имя или IP -адрес узла, к которому обращается клиент
    Referer URL документа, который ссылается на ресурс, указанный в строке состояния
    From Адрес электронной почты пользователя, работающего с клиентом
    Accept MIME -типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
    Accept-Language Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
    Accept-Charset Перечень поддерживаемых наборов символов
    Content-Type MIME -тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Content-Length Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Range Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
    Connection Используется для управления TCP -соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP -соединение, чтобы оно могло быть использовано для последующих запросов
    User-Agent Информация о клиенте

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

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

    GET http://oak.oakland.edu/ HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.04 [en]   (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.

    Классы кодов ответа сервера
    Код Расшифровка Интерпретация
    100 Continue Часть запроса принята, и сервер ожидает от клиента продолжения запроса
    200 OK Запрос успешно обработан, и в ответе клиента передаются данные, указанные в запросе
    201 Created В результате обработки запроса был создан новый ресурс
    202 Accepted Запрос принят сервером, но обработка его не окончена. Данный код ответа не гарантирует, что запрос будет обработан без ошибок
    206 Partial Content Сервер возвращает часть ресурса в ответ на запрос, содержавший поле заголовка Range
    301 Multiple Choice Запрос указывает более чем на один ресурс. В теле ответа могут содержаться указания на то, как правильно идентифицировать запрашиваемый ресурс
    302 Moved Permanently Затребованный ресурс больше не располагается на сервере
    302 Moved Temporarily Затребованный ресурс временно изменил свой адрес
    400 Bad Request В запросе клиента обнаружена синтаксическая ошибка
    403 Forbidden Имеющийся на сервере ресурс недоступен для данного пользователя
    404 Not Found Ресурс, указанный клиентом, на сервере отсутствует
    405 Method Not Allowed Сервер не поддерживает метод, указанный в запросе
    500 Internal Server Error Один из компонентов сервера работает некорректно
    501 Not Implemented Функциональных возможностей сервера недостаточно, чтобы выполнить запрос клиента
    503 Service Unavailable Служба временно недоступна
    505 HTTP Version not Supported Версия HTTP, указанная в запросе, не поддерживается сервером

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

    Поля заголовка ответа веб-сервера
    Имя поля Описание содержимого
    Server Имя и номер версии сервера
    Age Время в секундах, прошедшее с момента создания ресурса
    Allow Список методов, допустимых для данного ресурса
    Content-Language Языки, которые должен поддерживать клиент для того, чтобы корректно отобразить передаваемый ресурс
    Content-Type MIME -тип данных, содержащихся в теле ответа сервера
    Content-Length Число символов, содержащихся в теле ответа сервера
    Last-Modified Дата и время последнего изменения ресурса
    Date Дата и время, определяющие момент генерации ответа
    Expires Дата и время, определяющие момент, после которого информация, переданная клиенту, считается устаревшей
    Location В этом поле указывается реальное расположение ресурса. Оно используется для перенаправления запроса
    Cache-Control Директивы управления кэшированием. Например, no-cache означает, что данные не должны кэшироваться

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

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

    HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Mon, 20 OCT 2008 11:25:56 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Sat, 18 Oct 2008 15:05:44 GMT
ETag: "b66a667f948c92:8a5"
Content-Length: 426
 
<html>
<body>
  <form action='http://localhost/Scripts/test.pl'>
    <p>Operand1: <input type='text' name='A'></p>
    <p>Operand2: <input type='text' name='B'></p>
    <p>Operation:<br>
    <select name='op'>
      <option value='+'>+</option>
      <option value='-'>-</option>
      <option value='*'>*</option>
      <option value='/'>/</option>
    <select></p>
    <input type='submit' value='Calculate!'>
  </from>
</body>
</html>

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

    Поле с именем 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-запросов и ответов.

    MIME типы данных
    Тип/подтип Расширение файла Описание
    application/pdf .pdf Документ, предназначенный для обработки Acrobat Reader
    application/msexcel .xls Документ в формате Microsoft Excel
    application/postscript .ps, .eps Документ в формате PostScript
    application/x-tex .tex Документ в формате ТеХ
    application/msword .doc Документ в формате Microsoft Word
    application/rtf .rtf Документ в формате RTF, отображаемый с помощью Microsoft Word
    image/gif .gif Изображение в формате GIF
    image/ jpeg .jpeg, .jpg, Изображение в формате JPEG
    image/tiff .tiff, .tif Изображение в формате TIFF
    image/x-xbitmap .xbm Изображение в формате XBitmap
    text/plain .txt ASCII -текст
    text/html . html , . htm Документ в формате HTML
    audio/midi .midi, .mid Аудиофайл в формате MIDI
    audio/x-wav .wav Аудиофайл в формате WAV
    message/rfc822 Почтовое сообщение
    message/news Сообщение в группы новостей
    video /mpeg .mpeg, .mpg, .mpe Видеофрагмент в формате MPEG
    video/avi .avi Видеофрагмент в формате 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 имеет следующую структуру:

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

    где:

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

    Обеспечение безопасности передачи данных HTTP

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

    Самым простейшим является расширение HTTPS, при котором данные, передаваемые по протоколу HTTP, "упаковываются" в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера.

    SSL (Secure Sockets Layer) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создается защищенное соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший название TLS. Этот протокол использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надежность передачи данных за счет использования корректирующих кодов и безопасных хэш-функций. На нижнем уровне многоуровневого транспортного протокола (например, TCP ) он является протоколом записи и используется для инкапсуляции различных протоколов ( POP3, IMAP, SMTP или HTTP ). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнет передавать и получать данные.

    Для доступа к веб-страницам, защищенным протоколом SSL, в URL вместо схемы http, как правило, подставляется схема https, указывающая на то, что будет использоваться SSL -соединение. Стандартный TCP -порт для соединения по протоколу https - 443. Для работы SSL требуется, чтобы на сервере имелся SSL - сертификат.

    В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях:

  • Basic - базовая аутентификация, при которой имя пользователя и пароль передаются в заголовках http -пакетов. Пароль при этом не шифруется и присутствует в чистом виде в кодировке base64. Для данного типа аутентификации использование SSL является обязательным.
  • Digest - дайджест-аутентификация, при которой пароль пользователя передается в хешированном виде. По уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив удостоверение, он все равно получает доступ к конечной точке. Для данного типа аутентификации использование SSL является обязательным.
  • Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей, поэтому для него не требуется протокол SSL. Только при использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.
    •

    Cookie

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

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

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

    Такие сведения позволяет получить дополнительное средство под названием cookie. Механизм cookie позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.

    Инициатором записи cookie выступает сервер. Если в ответе сервера присутствует поле заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо прочей информации он передает серверу данные cookie. Для передачи указанной информации серверу используется поле заголовка Cookie.

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

  • Передача запроса серверу А.
  • Получение ответа от сервера А.
  • Передача запроса серверу В.
  • Получение ответа от сервера В. В состав ответа входит поле заголовка SetCookie. Получив его, клиент записывает cookie на диск.
  • Передача запроса серверу С. Несмотря на то что на диске хранится запись cookie, клиент не предпринимает никаких специальных действий, так как значение cookie было записано по инициативе другого сервера.
  • Получение ответа от сервера С.
  • Передача запроса серверу А. В этом случае клиент также никак не реагирует на тот факт, что на диске хранится cookie.
  • Получение ответа от сервера А.
  • Передача запроса серверу В. Перед тем как сформировать запрос, клиент определяет, что на диске хранится запись cookie, созданная после получения ответа от сервера В. Клиент проверяет, удовлетворяет ли данный запрос некоторым требованиям, и, если проверка дает положительный результат, включает в заголовок запроса поле Cookie.
    •

    Таким образом, процедуру записи и получения cookie можно представить себе как своеобразный "запрос" сервера, инкапсулированный в его ответе клиенту. Соответственно получение cookie также можно представить себе как ответ клиента, инкапсулированный в составе запроса тому же серверу.

    Рассмотрим подробнее, какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента.

    Поле Set-cookie имеет следующий формат:

    Set-cookie: имя = значение; expires = дата; path = путь; domain= имя_домена, secure

    где

  • Пара имя = значение - именованные данные, сохраняемые с помощью механизм cookie. Эти данные должны храниться на клиент-машине и передаваться серверу в составе очередного запроса клиента.
  • Дата, являющаяся значением параметра expires, определяет время, по истечении которого информация cookie теряет свою актуальность. Если ключевое слово expires отсутствует, данные cookie удаляются по окончании текущего сеанса работы браузера.
  • Значение параметра domain определяет домен, с которым связываются данные cookie. Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает доменное имя сервера, к которому он собирается обратиться, с доменами, которые связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет считаться положительным, если сервер, которому направляется запрос, принадлежит домену, связанному с cookie. Если соответствие не обнаружено, данные cookie не передаются.
  • Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую проверку и принять окончательное решение о том, следует ли передавать данные cookie в составе запроса. Помимо домена с записью cookie связывается путь. Если браузер обнаружил соответствие имени домена значению параметра domain, он проверяет, соответствует ли путь к ресурсу пути, связанному с cookie. Сравнение считается успешным, если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в одном из его подкаталогов. Если и эта проверка дает положительный результат, данные cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается, что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.
  • Последний параметр, secure, указывает на то, что данные cookie должны передаваться по защищенному каналу.
    •

    Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля достаточно простой:

    Cookie: имя=значение; имя=значение;  ...

    C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени домена и пути, указанным ранее в поле Set-cookie.

    Клиентские сценарии и приложения

    Как правило, Веб-приложение - приложение, в котором клиентом выступает браузер, а сервером - веб-сервер.

    Рассмотрим типы программ, обеспечивающих работу Веб и использующих HTTP-протокол.

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

    Результатом работы веб-приложения является веб-страница, отображаемая в окне браузера. При этом само веб-приложение может выполняться как на компьютере клиента, так и на компьютере сервера.

    Рассмотрим подробнее обе схемы.

    Программы, выполняющиеся на клиент-машине

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

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

    Программы, выполняющиеся на сервере

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

    Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и передает их клиенту. Взаимодействие клиента и сервера в этом случае показано на рисунке 1.2.

    (рис 1.2) Взаимодействие клиента с программой, выполняющейся на сервере

    Насыщенные интернет-приложения

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

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

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

    (рис 1.3) Передача клиенту Java-апплета

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

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

    Для разработки насыщенных интернет-приложений используются пакеты Curl, Macromedia Flash, Adobe Flex, Microsoft Silverlight и др.

    Серверные веб-приложения

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

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

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

    Веб-сервисы

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

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

    В основе SOA лежат принципы многократного использования функциональных элементов ИТ, унификации типовых операционных процессов. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые и слабо связанные, заменяемые сервисы-приложения.

    Интерфейс компонентов SОА-программы осуществляет инкапсуляцию деталей реализации конкретного компонента (ОС, языка программирования и т. п).

    SOA хорошо зарекомендовала себя при построении крупных корпоративных программных систем. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Microsoft .NET , IBM WebSphere, SAP NetWeaver, Diasoft и др.).

    Веб-сервисы .NET имеют следующие достоинства:

  • Открытость стандартов. В веб-сервисах отсутствуют какие-либо скрытые или недоступные элементы. Каждый аспект технологии, от способа поиска веб-сервисы до ее описания и организации связи с ней, определен общедоступными стандартами.
  • Межплатформенность. Язык программирования, который позволяет создавать XML-документы и отправлять информацию посредством HTTP, позволяет взаимодействовать с любым веб-сервисом. Можно получать веб-услугу из системы, отличной от .NET.
  • Простота.
  • Поддержка сообщений на понятном человеку языке. Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с веб-сервисами по обычным каналам HTTP.
    •

    Облачные вычисления

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

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

    Парадигма облачной обработки данных предполагает, что вся необходимая информация постоянно хранится на удаленных серверах в сети Интернет и лишь временно кэшируется на клиентской стороне. Это могут быть персональные компьютеры, смартфоны, ноутбуки и т.д.

    При этом пользователю такой системы предоставляются услуги, которые можно разделить на следующие виды:

  • IaaS (Infrastructure-as-a-Service) - инфраструктура как сервис.
  • PaaS (Platform-as-a-Service) - платформа как сервис.
  • SaaS (Software-as-a-Service) - программное обеспечение как сервис.
    •

    Usability

    Международный стандарт ISO 9241-11 определяет usability как "степень, с которой продукт может быть использован определенными пользователями при определенном контексте использования для достижения определенных целей с должной эффективностью, продуктивностью и удовлетворенностью".

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

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

  • Доступность: насколько легко пользователи, впервые обратившиеся к интерфейсу системы, могут выполнить базовые функции
  • Эффективность: насколько быстро пользователи выполняют работу после того, как они познакомились с особенностями интерфейса?
  • Запоминаемость: насколько легко пользователям восстановить эффективность работы с интерфейсом после того как они некоторое время не использовали его?
  • Ошибки: Как много ошибок делают пользователи, насколько серьезными они являются, и насколько просто их исправляют?
  • Удовлетворенность: насколько приятно работать с интерфейсом?
    •

    Можно назвать следующие аспекты хорошего usability веб-сайта:

  • Дизайн. Профессиональный дизайн делает сайт удобным для изучения, навигации и прочих действий посетителя.
  • Структура контента. Иерархия документов имеющихся на сайте не должна сбивать пользователя с толку.
  • Навигация сайта. То, насколько быстро пользователь может быть перенаправлен с главной страницы сайта на самые дальние имеет решающее значение. Профессионально выполненная навигационная компонента веб-сайта позволяет достигнуть хороших временных показателей пребывания посетителей на сайте.
  • Функционал веб-сайта связан с его работоспособностью и устойчивостью к ошибкам. В частности, он определяется тем насколько устойчиво он работает при просмотре в различных веб-браузерах.
  • Контент сайта. Определяет то, насколько информация, представленная на сайте окажется релевантной для пользователя.
    •
    Страницы:

    Предметом данного курса являются технологии глобальной сети 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.

    Поля заголовка запроса HTTP
    Поля заголовка HTTP-запроса Значение
    Host Доменное имя или IP -адрес узла, к которому обращается клиент
    Referer URL документа, который ссылается на ресурс, указанный в строке состояния
    From Адрес электронной почты пользователя, работающего с клиентом
    Accept MIME -типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
    Accept-Language Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
    Accept-Charset Перечень поддерживаемых наборов символов
    Content-Type MIME -тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Content-Length Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Range Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
    Connection Используется для управления TCP -соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP -соединение, чтобы оно могло быть использовано для последующих запросов
    User-Agent Информация о клиенте

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

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

    GET http://oak.oakland.edu/ HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.04 [en]   (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.

    Классы кодов ответа сервера
    Код Расшифровка Интерпретация
    100 Continue Часть запроса принята, и сервер ожидает от клиента продолжения запроса
    200 OK Запрос успешно обработан, и в ответе клиента передаются данные, указанные в запросе
    201 Created В результате обработки запроса был создан новый ресурс
    202 Accepted Запрос принят сервером, но обработка его не окончена. Данный код ответа не гарантирует, что запрос будет обработан без ошибок
    206 Partial Content Сервер возвращает часть ресурса в ответ на запрос, содержавший поле заголовка Range
    301 Multiple Choice Запрос указывает более чем на один ресурс. В теле ответа могут содержаться указания на то, как правильно идентифицировать запрашиваемый ресурс
    302 Moved Permanently Затребованный ресурс больше не располагается на сервере
    302 Moved Temporarily Затребованный ресурс временно изменил свой адрес
    400 Bad Request В запросе клиента обнаружена синтаксическая ошибка
    403 Forbidden Имеющийся на сервере ресурс недоступен для данного пользователя
    404 Not Found Ресурс, указанный клиентом, на сервере отсутствует
    405 Method Not Allowed Сервер не поддерживает метод, указанный в запросе
    500 Internal Server Error Один из компонентов сервера работает некорректно
    501 Not Implemented Функциональных возможностей сервера недостаточно, чтобы выполнить запрос клиента
    503 Service Unavailable Служба временно недоступна
    505 HTTP Version not Supported Версия HTTP, указанная в запросе, не поддерживается сервером

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

    Поля заголовка ответа веб-сервера
    Имя поля Описание содержимого
    Server Имя и номер версии сервера
    Age Время в секундах, прошедшее с момента создания ресурса
    Allow Список методов, допустимых для данного ресурса
    Content-Language Языки, которые должен поддерживать клиент для того, чтобы корректно отобразить передаваемый ресурс
    Content-Type MIME -тип данных, содержащихся в теле ответа сервера
    Content-Length Число символов, содержащихся в теле ответа сервера
    Last-Modified Дата и время последнего изменения ресурса
    Date Дата и время, определяющие момент генерации ответа
    Expires Дата и время, определяющие момент, после которого информация, переданная клиенту, считается устаревшей
    Location В этом поле указывается реальное расположение ресурса. Оно используется для перенаправления запроса
    Cache-Control Директивы управления кэшированием. Например, no-cache означает, что данные не должны кэшироваться

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

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

    HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Mon, 20 OCT 2008 11:25:56 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Sat, 18 Oct 2008 15:05:44 GMT
ETag: "b66a667f948c92:8a5"
Content-Length: 426
 
<html>
<body>
  <form action='http://localhost/Scripts/test.pl'>
    <p>Operand1: <input type='text' name='A'></p>
    <p>Operand2: <input type='text' name='B'></p>
    <p>Operation:<br>
    <select name='op'>
      <option value='+'>+</option>
      <option value='-'>-</option>
      <option value='*'>*</option>
      <option value='/'>/</option>
    <select></p>
    <input type='submit' value='Calculate!'>
  </from>
</body>
</html>

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

    Поле с именем 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-запросов и ответов.

    MIME типы данных
    Тип/подтип Расширение файла Описание
    application/pdf .pdf Документ, предназначенный для обработки Acrobat Reader
    application/msexcel .xls Документ в формате Microsoft Excel
    application/postscript .ps, .eps Документ в формате PostScript
    application/x-tex .tex Документ в формате ТеХ
    application/msword .doc Документ в формате Microsoft Word
    application/rtf .rtf Документ в формате RTF, отображаемый с помощью Microsoft Word
    image/gif .gif Изображение в формате GIF
    image/ jpeg .jpeg, .jpg, Изображение в формате JPEG
    image/tiff .tiff, .tif Изображение в формате TIFF
    image/x-xbitmap .xbm Изображение в формате XBitmap
    text/plain .txt ASCII -текст
    text/html . html , . htm Документ в формате HTML
    audio/midi .midi, .mid Аудиофайл в формате MIDI
    audio/x-wav .wav Аудиофайл в формате WAV
    message/rfc822 Почтовое сообщение
    message/news Сообщение в группы новостей
    video /mpeg .mpeg, .mpg, .mpe Видеофрагмент в формате MPEG
    video/avi .avi Видеофрагмент в формате 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 имеет следующую структуру:

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

    где:

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

    Обеспечение безопасности передачи данных HTTP

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

    Самым простейшим является расширение HTTPS, при котором данные, передаваемые по протоколу HTTP, "упаковываются" в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера.

    SSL (Secure Sockets Layer) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создается защищенное соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший название TLS. Этот протокол использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надежность передачи данных за счет использования корректирующих кодов и безопасных хэш-функций. На нижнем уровне многоуровневого транспортного протокола (например, TCP ) он является протоколом записи и используется для инкапсуляции различных протоколов ( POP3, IMAP, SMTP или HTTP ). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнет передавать и получать данные.

    Для доступа к веб-страницам, защищенным протоколом SSL, в URL вместо схемы http, как правило, подставляется схема https, указывающая на то, что будет использоваться SSL -соединение. Стандартный TCP -порт для соединения по протоколу https - 443. Для работы SSL требуется, чтобы на сервере имелся SSL - сертификат.

    В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях:

  • Basic - базовая аутентификация, при которой имя пользователя и пароль передаются в заголовках http -пакетов. Пароль при этом не шифруется и присутствует в чистом виде в кодировке base64. Для данного типа аутентификации использование SSL является обязательным.
  • Digest - дайджест-аутентификация, при которой пароль пользователя передается в хешированном виде. По уровню конфиденциальности паролей этот тип мало чем отличается от предыдущего, так как атакующему все равно, действительно ли это настоящий пароль или только хеш от него: перехватив удостоверение, он все равно получает доступ к конечной точке. Для данного типа аутентификации использование SSL является обязательным.
  • Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей, поэтому для него не требуется протокол SSL. Только при использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.
    •

    Cookie

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

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

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

    Такие сведения позволяет получить дополнительное средство под названием cookie. Механизм cookie позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.

    Инициатором записи cookie выступает сервер. Если в ответе сервера присутствует поле заголовка Set-cookie, клиент воспринимает это как команду на запись cookie. В дальнейшем, если клиент обращается к серверу, от которого он ранее принял поле заголовка Set-cookie, помимо прочей информации он передает серверу данные cookie. Для передачи указанной информации серверу используется поле заголовка Cookie.

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

  • Передача запроса серверу А.
  • Получение ответа от сервера А.
  • Передача запроса серверу В.
  • Получение ответа от сервера В. В состав ответа входит поле заголовка SetCookie. Получив его, клиент записывает cookie на диск.
  • Передача запроса серверу С. Несмотря на то что на диске хранится запись cookie, клиент не предпринимает никаких специальных действий, так как значение cookie было записано по инициативе другого сервера.
  • Получение ответа от сервера С.
  • Передача запроса серверу А. В этом случае клиент также никак не реагирует на тот факт, что на диске хранится cookie.
  • Получение ответа от сервера А.
  • Передача запроса серверу В. Перед тем как сформировать запрос, клиент определяет, что на диске хранится запись cookie, созданная после получения ответа от сервера В. Клиент проверяет, удовлетворяет ли данный запрос некоторым требованиям, и, если проверка дает положительный результат, включает в заголовок запроса поле Cookie.
    •

    Таким образом, процедуру записи и получения cookie можно представить себе как своеобразный "запрос" сервера, инкапсулированный в его ответе клиенту. Соответственно получение cookie также можно представить себе как ответ клиента, инкапсулированный в составе запроса тому же серверу.

    Рассмотрим подробнее, какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента.

    Поле Set-cookie имеет следующий формат:

    Set-cookie: имя = значение; expires = дата; path = путь; domain= имя_домена, secure

    где

  • Пара имя = значение - именованные данные, сохраняемые с помощью механизм cookie. Эти данные должны храниться на клиент-машине и передаваться серверу в составе очередного запроса клиента.
  • Дата, являющаяся значением параметра expires, определяет время, по истечении которого информация cookie теряет свою актуальность. Если ключевое слово expires отсутствует, данные cookie удаляются по окончании текущего сеанса работы браузера.
  • Значение параметра domain определяет домен, с которым связываются данные cookie. Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает доменное имя сервера, к которому он собирается обратиться, с доменами, которые связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет считаться положительным, если сервер, которому направляется запрос, принадлежит домену, связанному с cookie. Если соответствие не обнаружено, данные cookie не передаются.
  • Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую проверку и принять окончательное решение о том, следует ли передавать данные cookie в составе запроса. Помимо домена с записью cookie связывается путь. Если браузер обнаружил соответствие имени домена значению параметра domain, он проверяет, соответствует ли путь к ресурсу пути, связанному с cookie. Сравнение считается успешным, если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в одном из его подкаталогов. Если и эта проверка дает положительный результат, данные cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается, что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.
  • Последний параметр, secure, указывает на то, что данные cookie должны передаваться по защищенному каналу.
    •

    Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля достаточно простой:

    Cookie: имя=значение; имя=значение;  ...

    C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени домена и пути, указанным ранее в поле Set-cookie.

    Клиентские сценарии и приложения

    Как правило, Веб-приложение - приложение, в котором клиентом выступает браузер, а сервером - веб-сервер.

    Рассмотрим типы программ, обеспечивающих работу Веб и использующих HTTP-протокол.

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

    Результатом работы веб-приложения является веб-страница, отображаемая в окне браузера. При этом само веб-приложение может выполняться как на компьютере клиента, так и на компьютере сервера.

    Рассмотрим подробнее обе схемы.

    Программы, выполняющиеся на клиент-машине

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

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

    Программы, выполняющиеся на сервере

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

    Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и передает их клиенту. Взаимодействие клиента и сервера в этом случае показано на рисунке 1.2.

    (рис 1.2) Взаимодействие клиента с программой, выполняющейся на сервере

    Насыщенные интернет-приложения

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

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

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

    (рис 1.3) Передача клиенту Java-апплета

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

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

    Для разработки насыщенных интернет-приложений используются пакеты Curl, Macromedia Flash, Adobe Flex, Microsoft Silverlight и др.

    Серверные веб-приложения

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

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

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

    Веб-сервисы

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

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

    В основе SOA лежат принципы многократного использования функциональных элементов ИТ, унификации типовых операционных процессов. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые и слабо связанные, заменяемые сервисы-приложения.

    Интерфейс компонентов SОА-программы осуществляет инкапсуляцию деталей реализации конкретного компонента (ОС, языка программирования и т. п).

    SOA хорошо зарекомендовала себя при построении крупных корпоративных программных систем. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Microsoft .NET , IBM WebSphere, SAP NetWeaver, Diasoft и др.).

    Веб-сервисы .NET имеют следующие достоинства:

  • Открытость стандартов. В веб-сервисах отсутствуют какие-либо скрытые или недоступные элементы. Каждый аспект технологии, от способа поиска веб-сервисы до ее описания и организации связи с ней, определен общедоступными стандартами.
  • Межплатформенность. Язык программирования, который позволяет создавать XML-документы и отправлять информацию посредством HTTP, позволяет взаимодействовать с любым веб-сервисом. Можно получать веб-услугу из системы, отличной от .NET.
  • Простота.
  • Поддержка сообщений на понятном человеку языке. Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с веб-сервисами по обычным каналам HTTP.
    •

    Облачные вычисления

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

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

    Парадигма облачной обработки данных предполагает, что вся необходимая информация постоянно хранится на удаленных серверах в сети Интернет и лишь временно кэшируется на клиентской стороне. Это могут быть персональные компьютеры, смартфоны, ноутбуки и т.д.

    При этом пользователю такой системы предоставляются услуги, которые можно разделить на следующие виды:

  • IaaS (Infrastructure-as-a-Service) - инфраструктура как сервис.
  • PaaS (Platform-as-a-Service) - платформа как сервис.
  • SaaS (Software-as-a-Service) - программное обеспечение как сервис.
    •

    Usability

    Международный стандарт ISO 9241-11 определяет usability как "степень, с которой продукт может быть использован определенными пользователями при определенном контексте использования для достижения определенных целей с должной эффективностью, продуктивностью и удовлетворенностью".

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

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

  • Доступность: насколько легко пользователи, впервые обратившиеся к интерфейсу системы, могут выполнить базовые функции
  • Эффективность: насколько быстро пользователи выполняют работу после того, как они познакомились с особенностями интерфейса?
  • Запоминаемость: насколько легко пользователям восстановить эффективность работы с интерфейсом после того как они некоторое время не использовали его?
  • Ошибки: Как много ошибок делают пользователи, насколько серьезными они являются, и насколько просто их исправляют?
  • Удовлетворенность: насколько приятно работать с интерфейсом?
    •

    Можно назвать следующие аспекты хорошего usability веб-сайта:

  • Дизайн. Профессиональный дизайн делает сайт удобным для изучения, навигации и прочих действий посетителя.
  • Структура контента. Иерархия документов имеющихся на сайте не должна сбивать пользователя с толку.
  • Навигация сайта. То, насколько быстро пользователь может быть перенаправлен с главной страницы сайта на самые дальние имеет решающее значение. Профессионально выполненная навигационная компонента веб-сайта позволяет достигнуть хороших временных показателей пребывания посетителей на сайте.
  • Функционал веб-сайта связан с его работоспособностью и устойчивостью к ошибкам. В частности, он определяется тем насколько устойчиво он работает при просмотре в различных веб-браузерах.
  • Контент сайта. Определяет то, насколько информация, представленная на сайте окажется релевантной для пользователя.
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^