Asp управление сеансами

Содержание

14. Управление состоянием

Управление состоянием в приложениях ASP.NET 2.0, куки, ViewState, query string (строка запроса), Session ID и режим cookieless

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

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

При использовании серверного типа в вашем распоряжении:

· application state (информация приложения, общая для всех пользователей, например, информация о количестве посетителей Web-сайта);

· session state (информация конкретного пользователя, доступная только в его сеансе. Например, информация о выбранной им цветовой схеме);

· database state server — если информации состояния много, ее можно сохранять в базе (на SQL Server или другой). Этот способ можно использовать вместе с session state или c ookies.

· объект Cache — еще одна возможность работать с информацией состояния на уровне приложения.

При использовании клиентского типа вам доступны:

· куки — маленькие текстовые файлы, которые создаются на компьютере пользователя для хранения информации состояния;

· свойство ViewState — встроенная структура, которая обеспечивает хранение значений при повторном обращении к странице. Физически представляет собой скрытое поле в странице;

· query strings — информация состояния постепенно накапливается в строке запроса и передается при запросе каждой новой страницы, например:

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

Работа с application state обеспечивается классом HttpApplicationState , который автоматически создается для каждого активного приложения ASP.NET. Сам по себе этот объект — всего лишь коллекция пар имя ключа/значение. У него множество свойств и методов, которые почему-то не подсказываются (можно получить информацию только через документацию). Фактически это — глобальная структура хранения, которая доступна со всех страниц W eb -приложения. В эту структуру можно добавлять значения ключ/значение ан уровне всего приложения, а затем извлекать их. Обычно используется для хранения данных, общих для всех сеансов, которые меняются не часто.

Информация session state хранится при помощи объекта HttpSessionState. Этот объект автоматически создается для каждого активного сеанса Web-приложения. По существу это — такой же набор ключей/значений, однако по сравнению с HttpApplicationState для этого объекта предусмотрено множество специфических свойств, при помощи которых можно получить информацию о сеансе или настроить его свойства. При желании информацию HttpSessionState можно сохранять в базе данных или на state server .

Набор комбинаций ключ/сеанс, который используется в этих объектах, называется hashtable (структура, очень похожая на словарь).

Каждый активный сеанс Web-приложения идентифицируется и отслеживается по уникальному 120-битному Session >e less Session ID ) и по нему и идентифицируется сеанс пользователя.

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

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

Куки бывают двух видов:

· временные — живут только до закрытия окна броузера;

· постоянные — сохраняются на жестком диске компьютера и могут жить месяцами и годами (как им назначено). Internet Explorer сохраняет их в виде файлов с именами username @ domainname . txt .

Пользователь всегда может почистить куки на своем компьютере, так что такую возможность следует иметь в виду.

Куки — не очень безопасное решение (особенно по сравнению с применением HttpSessionState). пользователь легко может изменить значения куки на своем компьютере.

В каждом куки может храниться не более 4 Кбайт информации.

Теперь — о работе с файлом global.asax, который используется для обработки событий уровня приложений. Он автоматически создается на уровне Web-приложения и в нем присутствуют заранее готовые событийные процедуры на различные события в работе приложения (Application_Start, Session_Start, Application_BeginRequest, Session_End и т.п.)

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

Переменные уровня приложения и сеанса инициализируются в событийных процедурах типа Start в global.asax. Для хранения информации уровня приложения используется объект Application, а уровня сеанса — Session. Хранение, как уже говорилось, производится в парах ключ/значение, и может выглядеть так (для сеанса):

Sub Session_Start(ByVal Sender As Object, _

ByVal e As EventArgs)

и так ( для приложения ):

Sub Application_Start(ByVal Sender As Object, _

ByVal e As EventArgs)

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

Если с приложением может работать несколько пользователей, лучше обезопасить себя от проблем при одновременном изменении одних и тех же данных:

Считать записанную информацию можно также без всяких проблем:

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

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

Настройка тайм-аута для сеанса производится в файле web.config. Соответствующая часть выглядит так:

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

По умолчанию информация состояния всех сеансов хранится in process — то есть в памяти, которая относится к процессу данного Web-приложения. Главная проблема при этом — в большом расходе памяти на сервере, если с ним одновременно работает большое количество пользователей. Поэтому в ASP.NET есть возможность хранить информацию состояния сеансов out of process :

1) в базе данных SQL S erver;

2) на специальном State Server (это может быть компьютер под управлением Windows 2000 Server и выше). В этом случае информация сеансов пользователей просто складывается в его оперативную память.

Главное преимущество таких решений — масштабируемость и возможность использования Web farms.

Как сохранять информацию состояний сеансов out of process ;

1) настроить SQL Server или state server.

Для настройки SQL Server достаточно прогнать при помощи OSQL специальный скрипт:

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

Для настройки State Server достатчоно на нем запустить службу ASP . NET .

2) объяснить Web-приложению, где оно должно хранить информацию состояния сеансов. Это делается через тот же файл web . config :

sessionState mode =» SQLServer «

Если используется State Server , нужно вместо имени SQL Server просто указать имя компьютера, на котором работает служба ASP.NET.

Теперь — про куки и Session ID.

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

Куки создаются при помощи свойства Cookies объекта R esponse и класса Request. Свойство Cookies представляет коллекцию Cookies (экземпляр класса HttpCookieCollection ).

Создать новый куки с именем MyCookie можно так:

Dim objCookie As New HttpCookie(«myCookie»)

Dim now As DateTime = DateTime.Now

Добавить пары ключ/значение можно так:

Назначить время жизни Cookie — так:

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

Чтобы этот куки со всеми настроенными параметрами был передан на компьютер пользователя, его надо добавить к объекту Response:

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

Set-Cookie: Username=John+Chen; path=/; domain=microsoft.com;

Expires=Tuesday, 01-Feb-05 00.00.01 GMT

Атрибут Domain генерируется автоматически броузером пользователя. Куки будет передаваться только на тот Web-сайт, который совпадает с указанным доменом.

При обращении на сайт microsoft.com в заголовке HTTP-запроса клиента будет стоять

Cookie: Username: John+Chen

Сами куки хранятся в каталоге \Documents and Settings\Username\Cookies, а имя файла куки выглядит как Username@DomainName.txt.

Чтобы программно получить информацию о значении куки, нужно обратиться к коллекции Cookies объекта Request :

Dim objCookie As HttpCookie = Request.Cookies(«myCookie»)

А затем извлекать из него нужные значения:

lblTime.ForeColor = System.Drawing.Color.FromName _

lblTime.BackColor = System.Drawing.Color.FromName _

Есть возможность обойтись и без куки. Для каждого сеанса ASP.NET генерирует уникальный идентификатор — SessionID, который вполне можно использовать для идентификации сеанса. Его применение позволяет решить различные проблемы в ситуациях, когда работа с куки отключена в броузере пользователя. Сохранение состояния сеанса средствами SessionID называется cookieless session.

Включается работа с cookieless в файле web.config. В нем нужно найти раздел sessionState и поменять значение в нем на true (по умолчанию false).

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

Однако при этом нужно помнить:

· при использовании cookieless session в проекте нельзя использовать абсолютные ссылки — только относительные;

· в большинстве броузеров максимальная длина URL — 255 символов.

Уроки ASP-технологий

Объект Application

Теперь давайте рассмотрим объект Application. Он предназначен для хранения глобальных переменных ASP-приложения, то есть переменных, которые доступны каждому сеансу приложения. Эти переменные находятся в коллекции Contents, к которой обычно обращаются сокращенно. Например, запишем следующий код в файл default.asp.

Затем создадим файл test.asp и наберем такой код:

После этого исполним сценарий default.asp, а затем test.asp. Последний выведет строку test в окне браузера. Вообще, в какой бы сценарий приложения мы не вставили код test.asp, результат будет одним и тем же.

Объект Application предоставляет разработчикам два метода:

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

Кроме коллекций и свойств у объекта Application есть два события: Application_OnEnd и Application_OnStart, которые мы рассмотрим чуть позже.

Объект Session

Этот объект предназначен для управления сеансами. Он имеет четыре свойства:

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

Свойство SessionID доступно в режиме «только для чтения» и возвращает уникальный идентификатор сеанса. Использование:

Свойство TimeOut отвечает за время, через которое движок ASP прервет сеанс и удалит всю связанную с ним информацию на сервере. Установка этого свойства не позволяет оставлять данные о конкретном пользователе на сервере после того, как он отключился. Принимает значения в минутах. Например:

Объект Session имеет один метод — Abandon, который позволяет принудительно прервать сеанс до истечения срока, указанного в свойстве TimeOut. Пример использования:

В объекте Session, как и в объекте Application, можно хранить данные. Для этого используются переменные уровня сессии. Например:

Кроме того, объект Session предоставляет разработчикам два события: Session_OnStart и Session_OnEnd, которые мы рассмотрим немного ниже.

Файл Global.asa

С чего начинается … нет, не Родина �� — web-приложение? Ответ такой: с файла Global.asa. Он является главным файлом приложения. В этом файле могут существовать только следующие элементы:

Четыре события: Application_OnStart, Application_OnEnd, Session_OnStart, Session_OnEnd;
Тэги

Атрибут RUNAT всегда принимает значение Server. Атрибут SCOPE определяет область видимости компоненты (Application или Session). ID — это идентификатор, с помощью которого в дальнейшем можно будет получить доступ к объекту. Далее вы указываете PROGID или CLASSID, которые нужны, чтобы идентифицировать компонент.

Например, вы хотите создать экземпляр компонента BrowserCapabilities (он рассматривался выше), который был бы доступен каждому сеансу приложения. Для этого в файле global.asa необходимо написать примерно следующий код:

После этого вы получаете доступ к свойствам и методам данного компонента из любого сценария вашего приложения простым обращением к переменной MyBrowser. Например:

Также экземпляры ActiveX-компонентов можно создавать с помощью подключения библиотеки типов данной компоненты. Делается это следующим образом:

Атрибут TYPE всегда принимает значение TypeLib. В атрибуте FILE необходимо указать путь к библиотеке типов вашего компонента. UUID — это уникальный идентификатор этой библиотеки. Указывать можно либо FILE, либо UUID. VERSION — это, естественно, версия компоненты :-). Атрибут LCID отвечает за идентификатор локали.

Например, у вас есть библиотека динамической компоновки MyLib.dll, а у нее есть библиотека типов MyLib.lib. Вы можете подключить ее в файле global.asa вот таким способом:

Затем в любом сценарии приложения можно использовать этот компонент следующим образом:

Asp управление сеансами

2530 просмотра

2 ответа

46 Репутация автора

Мои требования — у меня есть веб-интерфейс, который дает мне все данные из базы данных. У меня есть веб-сайт .net, который использует этот API для получения всех данных. Теперь я хочу, чтобы при входе в систему на моем веб-сайте я хотел управлять сеансом в «API».

Я знаю, сессия в веб-API не очень хороший подход, но все же мне нужно сделать это.

Я уже реализовал управление сессиями в веб-интерфейсе API (взято здесь ), и он работает нормально, если я отправляю все свои запросы от почтальона (т.е. я устанавливаю переменные в сеансе, вызывая 1 метод, и извлекаю эту переменную сеанса, вызывая 2 метод). Но когда я делаю то же самое с веб-сайта asp.net с помощью jQuery, я не получаю хранимую переменную сеанса (я заметил, что каждый раз для каждого запроса я получаю разные идентификаторы сессии).

код сохранения переменной в сеансе

код извлечения переменной, сохраненной в сеансе

Что мне нужно сделать, чтобы достичь своей цели .. Ваше мнение спасет мои дни .

Ответы (2)

плюса

111 Репутация автора

Пожалуйста, прочитайте это хранилище Web Api Session ранее.

Чтобы получить данные из сеанса, используйте javascript sessionStorage (вместо ajax).

Как использовать управление сеансами с Load Balancer в Asp.Net

December 2020

11.7k раз

У меня есть четыре различных серверов и балансировка нагрузки. Я хочу использовать контроль над искаженным. Я сделал что-то с ним так:

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

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

А, В, С и D являются четыре сервера. Балансировщику маршруты нагрузки первого запроса на сервер. Который открывает главную страницу с сервера и создает пароль «123456». Это хранится в сессии на сервере. Затем пользователь вводит пароль и кнопка нажата. Теперь балансировки нагрузки маршрутов этот запрос на сервер B. Поскольку сессия в B Sever имеет нулевое значение, пароли не совпадают.

Asp управление сеансами

Обновлен: Ноябрь 2007

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

Чтобы преодолеть это ограничение, свойственное традиционному веб-программированию, в ASP.NET включено несколько параметров, которые помогают сохранить данные как на уровне страниц, так и на уровне приложения. Это следующие свойства:

Состояние элемента управления.

Состояние представления, состояние элемента управления, скрытые поля, объекты cookie и строки запросов включают хранение данных на стороне клиента различными способами. Однако состояние приложения, состояние сеанса и параметры профиля хранят данные в памяти на сервере. Каждый параметр имеет свои преимущества и недостатки, в зависимости от сценария.

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

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

Свойство ViewState предоставляет объект словаря данных для сохранения значений между несколькими запросами одной страницы. Этот метод используется по умолчанию, чтобы сохранить значения свойств страницы и элементов управления между циклами обработки.

При обработке страницы текущее состояние страницы и элементов управления будут хэшироваться в строку и сохраняться на странице как скрытое поле или как несколько скрытых полей, если объем данных, сохраненных в свойстве ViewState , превышает значение, указанное в свойстве MaxPageStateFieldLength . При отправке страницы обратно на сервер страница анализирует строку состояния представления при инициализации и восстанавливает сведения из свойств на странице.

В состоянии представления возможно также сохранение значений. Дополнительные сведения об использовании параметра «Состояние представления» см. в разделе Общие сведения о состоянии представления ASP.NET . Рекомендации по использованию состояния представления см. в разделе Рекомендации по управлению состоянием ASP.NET .

Состояние элемента управления

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

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

Скрытые поля

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

Злоумышленники могут легко просмотреть и изменить содержимое скрытого поля. В скрытом поле не следует сохранять сведения, которые являются важными или служат основой правильной работы приложения. Дополнительные сведения см. в разделе Рекомендации по управлению состоянием ASP.NET .

Элемент HiddenField хранит единственную переменную в свойстве Value и должен быть явно добавлен на страницу. Дополнительные сведения см. в разделе Общие сведения о серверном веб-элементе управления HiddenField .

Чтобы значения скрытого поля были доступны в процессе обработки страницы, для отправки страницы следует использовать команду HTTP POST. Если используются скрытые поля, и страница обрабатывается в ответ на ссылку или команду HTTP GET, то скрытые поля не будут доступны. Рекомендации по использованию см. в разделе Рекомендации по управлению состоянием ASP.NET .

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

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

Примечание о безопасности.

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

Дополнительные сведения о работе с cookies см. в разделах Cookies и Рекомендации по управлению состоянием ASP.NET .

Строки запроса

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

В этом URL-пути строка запроса начинается со знака вопроса (?) и включает две пары атрибут/значение, одна из которых называется «category», а вторая — «price».

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

Примечание о безопасности.

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

Чтобы значения строки запроса были доступны в процессе обработки страницы, для отправки страницы следует использовать команду HTTP GET. То есть невозможно воспользоваться строкой запроса, если страница обрабатывается в ответ на команду HTTP POST. Рекомендации по использованию см. в разделе Рекомендации по управлению состоянием ASP.NET .

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

Состояние приложения

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

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

После добавления специфичных для приложения сведений к состоянию приложения ими управляет сервер. Рекомендации по использованию см. в разделе Рекомендации по управлению состоянием ASP.NET .

Состояние сеанса

ASP.NET позволяет сохранять значения с помощью состояния сеанса, которое является экземпляром класса HttpSessionState , для всех активных сеансов веб-приложений. Для получения общих сведений см. Общие сведения о состоянии сеанса ASP.NET .

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

Состояние сеанса структурировано как словарь ключей/значений, используемый для хранения специфичных для сеанса сведений, которые необходимо отслеживать в промежутках между циклами запроса к серверу и между запросами страниц. Дополнительные сведения см. в разделе Общие сведения о состоянии сеанса ASP.NET .

С помощью состояния сеанса можно выполнять следующие задачи:

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

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

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

Asp управление сеансами

Обновлен: Ноябрь 2007

Состояние сеанса ASP.NET используется для хранения и извлечения значений сеанса пользователя.

В этом разделе рассматриваются следующие темы:

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

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

Состояние приложения, хранящее переменные, к которым могут обращаться все пользователи приложения ASP.NET.

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

Кэш ASP.NET, хранящий значения в памяти, доступной для приложений ASP.NET.

Состояние представления, хранящее значения на странице.

Строка запроса и поля на форме HTML, доступные из HTTP-запроса.

Сравнение различных вариантов управления состоянием см. в разделе Рекомендации по управлению состоянием ASP.NET .

Переменные сеанса

Переменные сеанса хранятся в объекте SessionStateItemCollection , доступного через свойство HttpContext Session . На странице ASP.NET доступ к переменным текущего сеанса можно получить при помощи свойства Session объекта Page .

Коллекция переменных сеанса индексирована по имени переменной или целочисленному индексу. Переменные сеанса создаются при ссылке на переменную по имени. Нет необходимости объявлять переменную сеанса или явно добавлять ее в коллекцию. В следующем примере кода создаются переменные сеанса на странице ASP.NET для имени и фамилии пользователя, им присваиваются значения, извлеченные из элемента управления TextBox .

В качестве типа переменных сеанса может быть использован любой допустимый тип .NET Framework. В следующем примере объект ArrayList сохраняется в переменной сеанса с именем StockPicks . Значение, возвращаемое переменной сеанса StockPicks , необходимо привести к соответствующему типу при его извлечении из коллекции SessionStateItemCollection .

Примечание о безопасности.

При использовании режима состояния сеанса, отличного от InProc , тип переменной сеанса должен быть типом .NET или сериализуемым типом. Это вызвано тем, что значение переменной сеанса хранится во внешнем хранилище данных. Дополнительные сведения см. в разделе Режимы состояний сеанса .

Идентификаторы сеансов

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

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

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

Примечание.

Значения P:System.Web.SessionState.HttpSessionState.SessionID передаются как текст в качестве файла Cookie или как часть URL-адреса. Пользователь-злоумышленник может получить доступ к сеансу другого пользователя, узнав значение идентификатора SessionID и включив его в запросы к серверу. Для хранения конфиденциальных сведений в состоянии сеанса рекомендуется использовать SSL для шифрования любого обмена данными между обозревателем и сервером, включая значение SessionID .

Значение SessionID по умолчанию хранится в бессрочном файле Cookie сеанса в обозревателе. Однако можно отменить сохранение идентификаторов сеанса в файле Cookie, если присвоить атрибуту cookieless значение true в разделе sessionState файла Web.config.

В следующем примере показан файл Web.config, который настраивает приложение ASP.NET для использования идентификатора сеанса без файлов Cookie.

Среда ASP.NET поддерживает состояние сеансов без объектов Cookie, автоматически вставляя уникальный идентификатор сеанса в URL-адрес страницы. Например, в следующий URL-адрес средствами ASP.NET был добавлен уникальный идентификатор сеанса lit3py55t21z5v55vlm25s55:

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

Идентификатор сеанса внедряется в URL-адрес после косой черты (/), следующей за именем приложения, и перед любым оставшимся идентификатором файла или виртуального каталога. Это позволяет ASP.NET обрабатывать имя приложения до включения объекта SessionStateModule в запрос.

Примечание о безопасности.

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

Повторное создание просроченных идентификаторов сеансов

Значения идентификатора сеанса, используемые в сеансах без файлов Cookie, создаются повторно по умолчанию. То есть, при поступлении запроса с просроченным идентификатором сеанса, запускается новый сеанс с предоставленным в этом запросе идентификатором SessionID . Это может привести к нежелательному совместному использованию данных, когда ссылка, содержащая идентификатор SessionID без файлов Cookie, используется совместно несколькими веб-обозревателями. (Это может произойти, если ссылка передается в поисковый двигатель при помощи сообщения электронной почты или другой программы.) Вероятность совместного использования данных несколькими клиентами можно сократить, отключив повторное использование идентификаторов сеанса. Для этого нужно присвоить атрибуту regenerateExpiredSessionId элемента конфигурации SessionState значение true . В результате при запросе сеанса без файлов Cookie с просроченным идентификатором сеанса создается новый идентификатор сеанса.

Примечание.

При поступлении запроса с просроченным идентификатором сеанса, созданного при помощи HTML-метода POST, любые переданные данные теряются, если значение regenerateExpiredSessionId равно true . Это происходит из-за того, что ASP.NET перенаправляет запрос, чтобы у обозревателя в URL-адресе был идентификатор сеанса.

Пользовательские идентификаторы сеанса

Можно реализовать пользовательский класс для предоставления и проверки значений идентификатора SessionID . Для этого следует создать класс, наследующий класс SessionIDManager , и переопределить методы CreateSessionID и Validate . Пример см. в описании метода CreateSessionID .

Можно заменить класс SessionIDManager , создав класс, реализующий интерфейс ISessionIDManager . Например, есть веб-приложение, которое связывает уникальный идентификатор с не-ASP.NET страницами, такими как HTML-страницы или изображения с использованием фильтра ISAPI. Можно реализовать пользовательский класс SessionIDManager , для использования этого уникального идентификатора с состоянием сеанса ASP.NET. Если пользовательский класс поддерживает идентификаторы сеансов без файлов Cookie, необходимо реализовать решение для отправки и получения идентификаторов сеансов в URL-адресе.

Режимы состояний сеанса

Состояние сеанса ASP.NET поддерживает несколько различных параметров хранения переменных сеанса. Каждый параметр определяется как тип состояния сеанса Mode . По умолчанию переменные сеанса хранятся в памяти рабочего процесса ASP.NET. Однако состояние сеанса можно также хранить в отдельном процессе, в базе данных SQL Server или пользовательском источнике данных. Если использование состояния сеанса для приложения не требуется, можно перейти в режим сеанса Off .

Дополнительные сведения см. в разделе Режимы состояний сеанса .

События сеанса

ASP.NET предоставляет два сеанса, помогающих управлять пользовательскими сеансами. Событие Session_OnStart возникает при запуске нового сеанса, а событие Session_OnEnd возникает, когда сеанс завершается или срока действия сеанса истекает. События сеанса указываются в файле Global.asax для приложения ASP.NET.

Событие Session_OnEnd не поддерживается, если значение свойства сеанса Mode отличается от InProc , что является режимом по умолчанию.

Примечание.

Если файл Global.asax или Web.config для приложения ASP.NET изменяется, приложение перезапускается и все значения, сохраненные в состоянии приложения или сеанса, теряются. Учтите, что некоторые антивирусные программы могут изменять дату и время последнего изменения файла Global.asax или файла Web.config приложения.

Дополнительные сведения см. в разделе События состояния сеанса .

Настройка состояния сеанса

Состояние сеанса настраивается при помощи элемента sessionState раздела конфигурации system.web . Кроме того, состояние сеанса можно настроить, используя значение EnableSessionState в директиве @ Page .

Элемент sessionState позволяет указывать следующие параметры.

Режим, в котором сеанс хранит данные.

Метод передачи идентификаторов сеанса между клиентом и сервером.

Поддержка значений на основе параметра сеанса Mode .

В следующем примере показан элемент sessionState , настраивающий приложение для использования режима сеанса SQLServer . Параметру Timeout присваивается значение 30 минут, а идентификаторы сеанса хранятся в URL-адресе.

Состояние сеанса для приложения можно отключить, установив режим состояния сеанса Off . Чтобы отключить состояние сеанса для отдельной страницы приложения, следует присвоить параметру EnableSessionState в директиве @ Page значение false . Параметру EnableSessionState можно присвоить значение ReadOnly , чтобы переменные сеанса были доступны только для чтения.

Основы архитектуры IIS, или запросопровод для ASP.NET

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.

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

2. Крупный план

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

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

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

Администрирование драйвера HTTP.sys.
Управление рабочими процессами.
Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

NetTcpActivator для протокола TCP;
NetPipeActivator для Named Pipes;
NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

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

Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
Исполняемый файл w3wp.exe – шаблон рабочего процесса.
Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

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

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

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

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

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

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

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >
Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

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

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

ASP.NET Состояние сеанса

Синтаксис

Session [«Session_Key»] = Obj_Value;

замечания

HTTP не имеет статуса. Состояние сеанса ASP.NET — это структура, которая облегчает сохранение состояния между запросами HTTP-страниц.

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

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

Хотя ViewState может использоваться для временного хранения данных пользователя, это не позволяет сохранять данные на нескольких страницах. Кроме того, viewstate является частью страницы и отправляется клиенту. В результате любая критическая информация, связанная с пользователем, не может быть сохранена в ViewState , и именно здесь переменные сеанса становятся полезными.

ASP объект Session

Объект Session используется для хранения информации о сессии пользователя (сессии), или изменить пользовательский сеанс (сеанс) настройки.

Объект Session

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

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

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

Сессия Когда начинать?

Сессия начинается с:

Новый пользователь запрашивает файл ASP, а также ссылки на файлы GLOBAL.ASA Session_OnStart подпрограммой
Значение хранится в переменной сессии
Пользователь запрашивает файл ASP, а Global.asa использовать тег, область сеанса, чтобы создать экземпляр объекта

Сессия закончится?

Если пользователь не запрашивает или обновить страницу в течение времени, указанного в заявке, сеанс будет завершен. Значение по умолчанию составляет 20 минут.

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

Следующий пример устанавливает интервал времени ожидания 5 минут:

Чтобы немедленно завершить сеанс, пожалуйста , используйте методAbandon:

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

Совет: В переменной сеанса , чтобы хранить только небольшое количество данных!

Переменные сеанса для хранения и извлечения

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

Следующие примеры «Donald Duck» Сессия , присвоенного переменной именипользователя,и «50» присваивается имя переменнойвозрастасессии:

Когда значение сохраняется в переменной сеанса, это может быть ASP приложениям использовать любую страницу:

Результаты Выше этой строки возвращает код: «Добро пожаловать» Дональда Дака.

Можно также сохранять пользовательские параметры в объекте Session, а затем доступ к этим параметрам, чтобы определить, что страница возвращается пользователю.

Ниже приведен пример, что если пользователь использует дисплей с низким разрешением, простой текст версия страницы возвращается:

Удалить Переменные сеанса

Коллекция Содержание содержит все переменные сессии.

Переменные сеанса могут быть удалены с помощью метода Remove.

В приведенном ниже примере, если «возраст» значения переменной сеанса составляет менее 18, а затем удалить переменную сеанса «продажи»:

Для того, чтобы удалить все переменной сеанса, используйте методы RemoveAll:

Коллекция Traversal Содержание

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

Если вы не знаете, количество элементов в коллекции Содержание, вы можете использовать свойство Count:

Обходе StaticObjects коллекция

Вы можете пройти через коллекцию StaticObjects, чтобы увидеть значения всех объектов, хранящихся в объекте Session:

Asp управление сеансами

Затем создадим файл test.asp и наберем такой код:

Объект Application предоставляет разработчикам два метода:

Этот объект предназначен для управления сеансами. Он имеет четыре свойства:

С чего начинается … нет, не Родина — web-приложение? Ответ такой: с файла Global.asa. Он является главным файлом приложения. В этом файле могут существовать только следующие элементы: