Изучение сессии в ASP.Net
ОГЛАВЛЕНИЕ
Данная статья описывает сессию в ASP.Net 2.0. Разные типы сессии, ее конфигурация. Также описана сессия в веб-ферме, балансировщике нагрузки, веб-саде, и т.д.
Введение
Данная статья дает хорошее понимание сессии. В ней описаны основы сессии, разные типы хранения объекта сессии, поведение сессии в веб-ферме, сессия в балансировщике нагрузки и т.д. Также объяснены особенности поведения сессии в условиях реального производства.
Что такое сессия?
Интернет не сохраняет состояние, а значит, новый экземпляр класса веб-страницы вновь создается при каждой отправке страницы на сервер. Как известно, HTTP - протокол без сохранения состояния, он не способен хранить клиентскую информацию о странице. Если пользователь вставит какие-то данные и перейдет на следующую страницу, то эти данные потеряются, и пользователь не сможет извлечь данные. Что нужно? Нужно хранить информацию. Сессия позволяет хранить информацию в памяти сервера. Она поддерживает хранение любого типа объекта наряду с пользовательским объектом. Для каждого клиента данные сессии хранятся отдельно, то есть данные сессии хранятся согласно клиенту. Посмотрите на следующую схему.
Рис. Для каждого клиента данные сессии хранятся отдельно
Управление состоянием с помощью сессии – одно из лучших средств asp.net, потому что оно безопасно, прозрачно от пользователей, и в ней можно хранить любой объект. Наряду с плюсами, порой сессия вызывает проблему быстродействия для сайтов с интенсивным трафиком, потому что сессия хранится в памяти сервера, и клиенты читают данные из самого сервера. Рассмотрим плюсы и минусы использования сессии в веб-приложении.
Плюсы и минусы сессии
Ниже приводятся основные плюсы и минусы использования сессии. Все типы сессий подробно описаны далее.
Плюсы:
• Сессия помогает хранить состояния и данные пользователя во всем приложении.
• Она легко реализуется и может хранить любой объект.
• Хранит данные каждого клиента отдельно.
• Сессия безопасна и прозрачна для пользователя.
Минусы:
• Издержки быстродействия в случае большого числа пользователей, так как данные сессии хранятся в памяти сервера.
• Издержки, связанные с сериализацией и десериализацией данных сессии, так как в случае режимов сессии StateServer и SQLServer объект надо сериализовать перед сохранением.
Кроме того, есть много плюсов и минусов сессии, обусловленных типами сессии. Все они разобраны далее.
Сохранение и извлечение значений из сессии
Сохранение и извлечение значений сессии очень похоже на ViewState. С состоянием сессии можно взаимодействовать с помощью класса System.Web.SessionState.HttpSessionState, потому что он предоставляет встроенный объект сессии со страницами Asp.Net.
Следующий код применяется для сохранения значения в сессии
//Сохранение UserName в сессии
Session["UserName"] = txtUser.Text;
Значения извлекаются из сессии так:
//Проверяется, пустая ли переменная сессии
if (Session["UserName"] != null)
{
//Извлечение UserName из сессии
lblWelcome.Text = "Welcome : " + Session["UserName"];
}
else
{
//Делается что-то другое
}
можно сохранить другой объект в сессии. Следующий пример показывает, как сохранить DataSet в сессии.
//Сохранение dataset(набор данных) в сессии
Session["DataSet"] = _objDataSet;
а следующий код показывает извлечение dataset из сессии
// Проверяется, пустая ли переменная сессии
if (Session["DataSet"] != null)
{
//Извлечение UserName из сессии
DataSet _MyDs = (DataSet)Session["DataSet"];
}
else
{
//Делается что-то другое
}
Идентификатор сессии
Asp.Net использует 120- битный идентификатор для отслеживания каждой сессии. Он достаточно безопасен и не подлежит расшифровке. Когда клиент общается с сервером, между ними передается только идентификатор сессии. Когда клиент запрашивает данные, ASP.NET смотрит на идентификатор сессии и извлекает соответствующие данные.
Это делается путем следующих шагов:
• Клиент обращается к веб-сайту, и какая-то информация сохраняется в сессии.
• Сервер создает уникальный идентификатор сессии для этого клиента и сохраняет его в поставщике состояния сессии.
• Снова клиент запрашивает какие-то данные с этим уникальным идентификатором сессии у сервера.
• Сервер смотрит на поставщики сессии и извлекает сериализованные данные из сервера состояний и приводит тип объекта.
Посмотрите на наглядную схему,
Рис. Взаимодействие клиента, веб-сервера и поставщика состояний
Режим сессии и поставщик состояний
В ASP.NET есть следующие режимы сессии:
• InProc
• StateServer
• SQLServer
• Custom
Для каждого состояния сессии есть поставщик сессии. Следующая схема показывает, как они связаны.
Рис. Архитектура состояния сессии
Можно выбрать поставщик состояния сессии исходя из того, какое состояние сессии выбирается. Когда ASP.NET запрашивает любую информацию на базе идентификатора сессии, состояние сессии и его соответствующий поставщик отвечают за отправку надлежащей информации на базе пользователя. Следующая таблица показывает режим сессии вместе с именем ее поставщика.
|
Режим состояния сессии |
Поставщик состояния |
|
|
Объект в памяти |
|
|
Aspnet_state.exe |
|
|
DataBase |
|
|
CustomProvider |
Есть еще один режим "Off". Если выбрать этот вариант, сессия будет отключена для приложения. Но использование сессии является целью, поэтому рассматриваются 4 режима состояния сессии.
Состояния сессии
Состояние сессии означает все настройки, сделанные для веб-приложения для сохранения сессии. Состояние сессии сообщает все о конфигурации сессии в web.config или из выделенного кода. В web.config, элементы <SessionState> используются для установки конфигурации сессии. Некоторые из них - Mode, Timeout, StateConnectionString, Custom provider и др. Рассмотрены все до единой части строки подключения. Перед рассмотрением режима сессии кратко ознакомимся с событием сессии.
Событие сессии
В Asp.net есть два типа событий сессии:
• Session_Start
• Session_End
оба этих события обрабатываются в файле global.asax веб-приложения. При запуске новой сессии возбуждается событие session_start, а при закрытии или окончании сессии возбуждается событие Session_End.
void Session_Start(object sender, EventArgs e)
{
// Код, выполняющийся при запуске новой сессии
}
void Session_End(object sender, EventArgs e)
{
// Код, выполняющийся при окончании сессии.
}
Режим сессии
Уже обсуждался режим сессии в ASP.NET. Ниже приводятся разные типы режимов сессии, имеющиеся в ASP.Net.
• Off
• InProc
• StateServer
• SQLServer
• Custom
Если установить режим сессии="off" в web.config, сессия будет отключена во всем приложении. Для этого надо сконфигурировать web.config таким образом:
Внутрипроцессный режим сессии
Это режим сессии по умолчанию в Asp.Net. Он хранит данные сессии в текущем домене приложения. Это лучший режим сессии исходя из быстродействия веб-приложения. Но главный недостаток в том, что данные теряются при перезапуске сервера. Есть еще несколько плюсов и минусов внутрипроцессного режима сессии. Они рассмотрены далее.
Обзор внутрипроцессного режима сессии
Внутрипроцессный режим хранит данные сессии в текущем домене приложения. Поэтому они легко и быстро доступны.
Внутрипроцессный режим сессии хранит данные сессии в объекте памяти в домене данного приложения. Этим управляет рабочий процесс в пуле приложений. Поэтому при перезапуске сервера данные сессии теряются. Если клиент запрашивает данные, поставщик состояния считывает данные из объекта в памяти и возвращает их клиенту. В web.config надо указать режим сессии и установить время ожидания.
Такая установка времени ожидания сессии сохраняет сессию в течение 30 минут. Это можно настроить и из выделенного кода.
Session.TimeOut=30;
В asp.net есть два типа событий сессии - Session_Start() и Session_End(). Это единственный режим, поддерживающий событие Session_End(). Это событие вызывается после истечения времени ожидания сессии. Общий порядок операций для внутрипроцессного состояния сессии таков:
От времени ожидания сессии зависит, когда вызовется Session_End(). Это очень быстрый механизм, потому что при сохранении и извлечении данных не происходит сериализации, и данные остаются в том же домене приложения.
Когда следует использовать внутрипроцессный режим сессии?
Внутрипроцессный – режим сессии по умолчанию. Он очень полезен для маленьких веб-сайтов и когда число пользователей очень маленькое. Избегайте внутрипроцессного режима в случае веб-сада (эта тема подробно рассмотрена далее).
Плюсы и минусы
Плюсы:
• Данные сессии хранятся в объекте памяти текущего домена приложения. Поэтому доступ к данным очень быстрый, и данные легко доступны.
• Для хранения данных при внутрипроцессном режиме сессии не требуется сериализация.
• Реализация очень простая, сходная с использованием состояния просмотра.
Минусы:
Несмотря на то, что внутрипроцессная сессия – самый быстрый, простой и стандартный механизм, он имеет много недостатков.
• Если рабочий процесс или домен приложения возвращается в исходное состояние, все данные сессии теряются.
• Хотя он самый быстрый, но много данных сессий и много пользователей снижают быстродействие из-за памяти.
• Его нельзя использовать в веб-саде.
• Этот режим сессии не подходит для веб-фермы.
Следовательно, внутрипроцессный – очень быстрый механизм сохранения сессии, но подходящий для маленького веб-приложения. Внутрипроцессные данные сессии теряются при перезапуске сервере или возврате домена приложения в исходное состояние. Он также не подходит для веб-фермы и веб-сада.
Теперь рассмотрим другие доступные варианты для преодоления этой проблемы. Первым идет режим сервера состояний.
Режим сессии сервера состояний
Обзор режима сессии сервера состояний
Он также называется внепроцессным режимом сессии. Сервер состояний использует автономные службы Windows, не зависящие от IIS и способные работать на отдельном сервере. Этим состоянием сессии полностью управляет aspnet_state.exe. Этот сервер может работать в той же системе, но он находится вне основного домена приложения, где работает веб-приложение. При перезапуске процесса asp.net данные сессии сохраняются. Такой подход имеет несколько недостатков из-за издержек сериализации и десериализации, он также увеличивает издержки доступа к данным, так как при каждом извлечении данных сессии пользователем приложение обращается к другому процессу.
Конфигурация для режима сессии сервера состояний
В StateServer данные сессии хранятся в отдельном сервере, не зависящем от IIS и управляемом aspnet_state.exe. Этот процесс работает как службы windows. Эту службу можно запустить из консоли управления windows или из командной строки.
По умолчанию "тип запуска" службы состояний ASP.NET установлен на ручной, надо установить его как "автоматический" тип запуска
из командной строки, набрав "net start aspnet_state". По умолчанию эта служба слушает порт TCP 42424, но можно изменить порт из редактора реестра, как показывает рисунок ниже.
Теперь посмотрим на конфигурацию web.config для установки сервера состояний. Для установки сервера состояний надо задать stateConnectionString. Она будет идентифицировать систему, являющуюся работающим сервером состояний. По умолчанию stateConnectionString использует IP-адрес 127.0.0.1 (localhost) и порт 42424.
При использовании сервера состояний можно сконфигурировать атрибуты stateNetworkTimeOut, чтобы задать максимальное число секунд ожидания ответа от службы до отмены запроса. Время по умолчанию - 10 секунд.
При использовании сервера состояний объект должен сериализоваться при сохранении и десериализоваться при извлечении. Это описано в примере.
Как работает режим сессии сервера состояний?
Режим сессии сервера состояний используется для предотвращения ненужной потери данных сессии при перезапуске веб-сервера. Сервер состояний обслуживается процессом aspnet_state.exe как служба windows. Этот процесс хранит все данные сессии. Но надо сериализовать данные перед их сохранением в режиме сессии сервера состояний.
Как показано на рисунке выше, сначала клиент отправляет запрос веб-серверу, затем веб-сервер сохраняет данные сессии на сервере состояний. Сервер состояний может быть текущей системой или другой системой. Но он абсолютно независим от IIS. Адрес сервера состояний будет зависеть от установки атрибута stateConnectionString в web.config. если установить его в 127.0.0.1:42424, он будет хранить данные в самой локальной системе. Чтобы сменить адрес сервера состояний, надо сменить IP и убедиться, что aspnet_state.exe запущен и работает в той системе. Иначе выдается следующее исключение при попытке сохранить данные в сессии.
Любой объект должен быть сериализован перед сохранением в сессии. Эти данные сохраняются в системе сервера состояний с помощью поставщика состояний. При извлечении данных поставщик состояний возвращает данные. Полный порядок операций дан на рисунке ниже.
Пример режима сессии сервера состояний:
Это простой пример использования режима сессии сервера состояний. Пример веб-приложения был создан прямо на IIS, чтобы было легко понять его применение.
Шаг 1: Открыть Visual Studio > Файл(File)>Новый(New)> Веб-сайты(Web Sites). Выбрать расположение как HTTP и создать веб-приложение.
Теперь если вы откроете IIS, то увидите виртуальный каталог, созданный с именем вашего веб-приложения, в данном примере это StateServer.
Шаг 2: Создать простой пользовательский интерфейс, принимающий номер списка и имя ученика. Имя и список будут сохраняться в сессии сервера состояний. Также был создан класс "StudentInfo", приведенный ниже.
[Serializable]
public class StudentInfo
{
//Конструктор по умолчанию
public StudentInfo()
{
}
/// <summary>
/// Создается объект класса студент
/// </summary>
/// <param name="intRoll">Int RollNumber</param>
/// <param name="strName">String Name</param>
public StudentInfo(int intRoll, string strName)
{
this.Roll = intRoll;
this.Name = strName;
}
private int intRoll;
private string strName;
public int Roll
{
get
{
return intRoll;
}
set
{
intRoll = value;
}
}
public string Name
{
get
{
return strName;
}
set
{
strName = value;
}
}
}
Теперь ознакомимся с кодом, отделенным от кода. Были добавлены две кнопки – одна для сохранения сессии, а вторая для извлечения сессии.
protected void btnSubmit_Click(object sender, EventArgs e)
{
StudentInfo _objStudentInfo = new StudentInfo(Int32.Parse( txtRoll.Text) ,txtUserName.Text);
Session["objStudentInfo"] = _objStudentInfo;
ResetField();
}
protected void btnRestore_Click(object sender, EventArgs e)
{
StudentInfo _objStudentInfo = (StudentInfo) Session["objStudentInfo"];
txtRoll.Text = _objStudentInfo.Roll.ToString();
txtUserName.Text = _objStudentInfo.Name;
}
Шаг 3: Сконфигурировать web.config для сервера состояний, как уже было сказано. Убедиться, что aspnet_state.exe запущен и работает на сконфигурированном сервере.
Шаг 4: Запустить приложение
Ввести данные, нажать на Отправить. Следующий тест покажет, в чем именно польза сервера состояний.
Первый: Удалите ключевое слово [Serializable] из класса studentinfo и попробуйте запустить приложение. При нажатии на кнопку «Отправить» вы получите следующую ошибку
которая ясно говорит, что надо сериализовать объект перед сохранением.
Второй: Запустите приложение, сохраните данные, нажав на кнопку «Отправить». Перезапустите IIS
Теперь в случае InProc вы уже потеряли данные сессии, но это StateServer. Щелкните по «Восстановить сессию» и получите исходные данные, потому что данные сервера состояний не зависят от IIS. Сервер состояний хранит данные отдельно.
Третий: Остановите aspnet_state.exe из консоли управления службами Windows и отправьте данные. Вы получите следующую ошибку,
потому что процесс сервера состояний не работает. Не забывайте про три перечисленных момента.
Плюсы и минусы
Исходя из вышесказанного:
Плюсы
• Данные хранятся отдельно от IIS, поэтому проблемы с IIS не мешают данным сессии.
• Он полезен в веб-ферме и веб-саде.
Минусы
• Процесс медленный из-за сериализации и десериализации
• Сервер состояний всегда должен быть запущен и работать.
С сервером состояний закончим. Дополнительные интересные особенности есть в разделе балансировщик нагрузки, веб-ферма, веб-сад.
Режим сессии SQL Server
Обзор режима сессии SQL Server
Этот режим сессии обеспечивает более безопасное и надежное управление сессиями в asp.net. В этом режиме сессии данные сессии сериализуются и сохраняются в базе данных SQL Server. Основные недостатки данных методов хранения сессии – издержки, связанные с сериализацией и десериализацией данных. Это лучший вариант для применения в веб-фермах.
Для настройки SQL Server надо воспользоваться двумя скриптами sql.
• Для установки: InstallSqlState.sql
• Для удаления: UninstallSQLState.sql
Простейший способ сконфигурировать SQL Server – использовать команду aspnet_regsql. Использование этого файла подробно объяснено в разделе конфигурации. Это наиболее полезное управление состоянием в веб-ферме.
Когда следует использовать режим сессии SQL Server?
• Режим сессии SQL Server – более надежное и безопасное управление состоянием сессии.
• Он хранит данные в централизованном месте (база данных).
• Следует использовать режим сессии SQL server, когда нужна более безопасная реализация сессии.
• Если сервер часто перезапускается, можно реализовать SQL server.
• Этот режим прекрасно подходит для веб-фермы и веб-сада (подробно объяснено далее).
• Можно использовать режим сессии SQL server, когда сессия совместно используется двумя разными приложениями.
Конфигурация для режима сессии SQL Server
В режиме сессии SQL Server данные сессии сохраняются в SQL Server, поэтому сначала надо прописать строку подключения к базе данных в web.config.Атрибут sqlConnectionString используется для указания строки подключения в web.config.
После установки строки подключения надо сконфигурировать SQL Server. SQL server конфигурируется с помощью команды aspnet_regsql следующим образом:
Шаг 1: Из командной строки перейдите в ваш каталог версии среды разработки
Например:c:\windows\microsoft.net\framework\<version>.
Шаг 2: Выполните команду aspnet_regsql со следующими параметрами
Ознакомьтесь с параметрами и их назначениями
|
Параметры |
Описание |
|
|
Добавить поддержку режима состояния сессии SQLServer. |
|
|
Pозначает сохраненный. Он сохраняет данные сессии на сервере. |
|
|
Задать имя сервера |
|
|
Задать имя пользователя |
|
|
Задать пароль |
После выполнения вы получите следующее сообщение,
только и всего.
Шаг 3: Откройте SQL Server Management Studio. Убедитесь, что новая база данных ASPState была создана, и в ней есть две таблицы,
• ASPStateTempApplications
• ASPStateTempSessions
Теперь измените строку конфигурации примера сервера состояний и запустите то же самое приложение, что и для сервера состояний.
Сохраните список и имя пользователя и щелкните по кнопке «Отправить», и откройте таблицу ASPStateTempSessions из SQL Server Management Studio, и увидите ваши данные сессии,
Теперь проделайте следующий тест, уже описанный в режиме сервера состояний.
1. Удалите ключевое слово serialize из класса StydentInfo
2. Перезапустите IIS и щелкните по «Восстановить сессию»
3. Остановите службу SQL Server
Плюсы и минусы
Плюсы:
• Данные сессии не страдают при перезапуске IIS.
• Самое надежное и безопасное управление сессиями.
• Данные хранятся в централизованном месте, легко доступном из другого приложения.
• Очень полезен для веб-фермы и веб-сада.
Минусы:
• Обработка очень медленная по характеру.
• Сериализация и десериализация объекта создает издержки для приложения.
• Поскольку данные сессии обрабатываются в другом сервере, приходится следить за SQL server. Он всегда должен быть запущен и работать.
Пользовательский режим сессии
Обзор пользовательского режима сессии:
Обычно в приложении используется режим сессии InProc, StateServer или SQL Server, но также нужно знать основы пользовательского режима сессии. Этот режим сессии весьма интересен, потому что пользовательская сессия позволяет полностью контролировать создание всего, даже идентификатора сессии. Можно написать собственный алгоритм генерации идентификатора сессии.
Можно реализовать пользовательские поставщики, сохраняющие данные сессии в других механизмах хранения путем наследования от класса SessionStateStoreProviderBase. Можно генерировать новый идентификатор сессии путем реализации ISessionIDManager.
Следующие методы вызываются во время реализации пользовательской сессии:
В методе Initialize устанавливается пользовательский поставщик. Он будет инициализировать соединение с заданным поставщиком. SetItemExpireCallback используется для установки SessionTimeOut, можно зарегистрировать любые методы, которые вызовутся при окончании сессии. InitializeRequest вызывается при каждом запросе, а CreateNewStoreData используется для создания нового экземпляра SessionStateStoreData.
Когда следует использовать пользовательский режим сессии?
Пользовательский режим сессии можно использовать в следующих случаях:
• Надо хранить данные сессии не в SQL Server.
• Надо использовать существующую таблицу для хранения данных сессии.
• Надо создать собственный идентификатор сессии.
Какая конфигурация требуется для него?
Надо сконфигурировать web.config так,
Плюсы и минусы
Плюсы:
• Можно использовать существующую таблицу для хранения данных сессии. Это полезно, когда приходится использовать старую базу данных вместо SQL Server.
• Он не зависит от IIS, поэтому перезапуск веб-сервера никак не влияет на данные сессии.
• Можно создать собственный алгоритм генерации идентификатора сессии.
Минусы:
• Обработка данных очень медленная.
• Создание пользовательского поставщика состояния – низкоуровневая задача, требующая аккуратного подхода для обеспечения безопасности.
Всегда рекомендуется использовать любой сторонний поставщик, а не создавать собственный.
Обзор производственного развертывания
Производственная среда означает, что приложение развертывается на настоящем рабочем сервере. Развертывание приложения на настоящем сервере – большая трудность для веб-разработчика, потому что в масштабной производственной среде много пользователей, и невозможно справиться с нагрузкой от них с помощью одного сервера. Отсюда появились модели веб-фермы, балансировщика нагрузки, веб-сада, и т.д.
Недавно одно веб-приложение было развернуто в реальной производственной среде, доступной для миллиона пользователей, где было более 10 Active Directory, более 10 веб-серверов на балансировщике нагрузки и много серверов баз данных, серверов Exchange Server, серверов LCS и др. Было несколько веб-серверов. Основной риск, связанный с несколькими серверами, - управление сессиями. Следующий рисунок показывает общую схему производственной среды.
Далее описаны разные ситуации, которые надо учесть при развертывании приложения.
Пул приложений
Это одна из самых важных вещей, которую надо создать для приложения в производственной среде. Пулы приложений применяются для отделения групп рабочих процессов IIS, совместно использующих одну и ту же конфигурацию. Пул приложений позволяет изолировать веб-приложение для лучшей безопасности, надежности и доступности. Рабочий процесс служит в качестве границы процессов, отделяющей каждый пул приложений, чтобы когда один рабочий процесс или приложение сталкивается с проблемой или возвращается в исходное состояние, другие приложения или рабочие процессы не страдали.
Удостоверение пула приложений
Конфигурация удостоверения пула приложений – важный аспект безопасности в IIS 6.0 и IIS 7.0, так как она определяет удостоверение рабочего процесса, когда процесс обращается к ресурсу. Эти настройки исходят из IIS 6.0. В IIS 7.0 есть заранее заданные удостоверения, такие же, как и в IIS 6.0.
|
Удостоверение пула приложений |
Описание |
|
|
LocalSystem– встроенная учетная запись, имеющая права администратора на сервере. Она может обращаться к локальным и удаленным ресурсам. Для любого вида доступа к файлам или ресурсам сервера надо задать удостоверение пула приложений Локальная система. |
|
|
LocalServices– встроенная учетная запись имеет права аутентифицированной учетной записи локального пользователя. Ей запрещен доступ к сети. |
|
|
Удостоверение пула приложений по умолчанию. NetworkServicesимеет права аутентифицированной учетной записи локального пользователя. |
Создание и назначение пула приложений
Откройте консоль IIS, щелкните правой кнопкой мыши по «Папка пула приложений» (Application Pool Folder) > Создать новый (Create New)
Введите Идентификатор пула приложений и нажмите Ok.
Теперь щелкните правой кнопкой мыши по «Виртуальный каталог» (используется StateServer Web sites) и назначьте StateServerAppPool виртуальному каталогу сервера состояний.
Итак, StateServer Web sites будет работать независимо в StateServerAppPool. Любая проблема, связанная с другим приложением, не повлияет на ваше приложение. Это главное преимущество создания отдельного пула приложений.
Веб-сад
По умолчанию каждый пул приложений работает с одним рабочим процессом (W3Wp.exe). Можно назначить несколько рабочих процессов одному пулу приложений. Пул приложений с несколькими рабочими процессами называется веб-сад. Много рабочих процессов в одном и том же пуле приложений иногда дают лучшую производительность и время реакции приложения. Каждый рабочий процесс должен иметь свой собственный поток и область памяти.
Как показано на рисунке, в сервере IIS может быть несколько пулов приложений, и каждый пул приложений имеет минимум один рабочий процесс. Веб-сад должен содержать несколько рабочих процессов.
Есть определенные ограничения на использование веб-сада в веб-приложении. Если используется внутрипроцессный режим сессии, приложение не будет работать правильно, потому что сессия будет обрабатываться другим рабочим процессом. Во избежание данной проблемы надо использовать внепроцессный режим сессии. Можно использовать "Сервер состояния сессии" или "Состояние сессии SQL-Server".
Главное преимущество: Рабочие процессы в веб-саде разделяют запросы, поступающие в конкретный пул приложений. Если один рабочий процесс откажет, другой рабочий процесс сможет продолжить обработку запросов.
Как создать веб-сад?
Щелкните правой кнопкой мыши по Пул приложений > Перейти во вкладку Производительность > Выбрать секцию веб-сад (выделена на рисунке)
По умолчанию стоит 1, измените на несколько.
Как сессия зависит от веб-сада?
InProc управляется рабочим процессом. Он хранит данные внутри своего объекта памяти. Если есть несколько рабочих процессов, то обрабатывать сессию будет очень трудно, потому что каждый рабочий процесс имеет свою собственную память. Поэтому если первый запрос пользователя уходит к WP1, и он хранит его данные сессии, и второй запрос того же пользователя уходит к WP2, и пользователь пытается извлечь данные сессии, они не вернутся, и выбросится ошибка. Поэтому не используйте веб-сад во внутрипроцессном режиме сессии.
В случае веб-сада можно использовать режим сессии StateServer или SQLServer, потому что эти два режима сессии не зависят от рабочего процесса. В примере показано, что после перезапуска IIS данные сессии успешно извлекаются.
|
Режим сессии |
Рекомендуется |
|
|
Нет |
|
|
Да |
|
|
Да |
Веб-ферма и балансировщик нагрузки
Это наиболее распространенный термин, используемый в производственном развертывании. Этот термин появляется при использовании нескольких веб-серверов для развертывания продукта. Нагрузка распределяется на несколько серверов. Балансировщик нагрузки применяется для распределения нагрузки на эти сервера.
На схеме клиент запрашивает url и попадает в балансировщик нагрузки, решающий, к какому серверу обратиться. Балансировщик нагрузки распределяет трафик на все веб-сервера.
Как это влияет на сессию?
Обработка сессии в веб-ферме и балансировщике нагрузки
Обработка сессии – одна из самых главных задач в веб-ферме.
InProc: При внутрипроцессном режиме сессии данные сессии хранятся в объекте в памяти рабочего процесса. Все до единого серверы имеют собственный рабочий процесс и хранят данные сессии в памяти.
Если в данный момент один сервер не работает, а запрос поступает другому серверу, пользователь не сможет получить данные сессии. Поэтому не рекомендуется использовать InProc в веб-ферме.
StateServer:Уже было объяснено, что такое сервер состояний, как сконфигурировать сервер состояний и др. Легко понять, насколько он важен для веб-фермы, потому что все данные сессии хранятся в одном месте.
Не забудьте проверить, что у всех веб-серверов одинаковый <machinekey>, и что все web.config имеют одинаковую конфигурацию (stateConnectionString) для состояния сессии.
SQL Server: Это другой подход, лучший для применения в веб-ферме. Сначала надо сконфигурировать базу данных. Шаги уже были рассмотрены.
Как показано на рисунке выше, все данные сессии веб-сервера хранятся в одной базе данных SQL Server. Она легко доступна. Помните, что надо сериализовать объект в режимах сервера состояний и SQL Server. При отключении одного веб-сервера балансировщик нагрузки распределяет нагрузку на другой сервер, и пользователь может прочитать данные сессии из сервера, потому что данные хранятся в централизованном сервере баз данных.
Таким образом, в веб-ферме можно использовать режим сессии сервера состояний или SQL. InProc не подходит.
Сессия и куки
Клиенты используют куки-файлы для работы с сессией, потому что клиенту надо предъявлять правильный идентификатор сессии с каждым запросом. Это можно сделать следующими способами:
Использование куки-файлов: По умолчанию ASP.NET создает специальные куки-файлы с именем ASP.NET_SessionId автоматически, когда используется коллекция сессий. Идентификатор сессии передается с помощью этих куки-файлов.
Изменение URL вместо куки: Некоторые старые барузеры не поддерживают куки, или пользователь может отключить куки в браузере, в таком случае ASP.Net передает идентификатор сессии в специально измененном URL.
Как работает изменение URL вместо куки?
Когда пользователь запрашивает страницу на сервере, сервер кодирует идентификатор сессии и добавляет ее к каждой ссылке href на странице. Когда пользователь щелкает по любой ссылке, ASP.NET декодирует этот идентификатор сессии и передает его странице, запрошенной пользователем. Теперь запрошенная страница может извлечь любую переменную сессию. Все это происходит автоматически, если ASP.NET обнаруживает, что браузер пользователя не поддерживает куки.
Как реализовать изменение URL вместо куки?
Для этого надо сделать состояние сессии лишенным куки.
Удаление сессии из переменной сессии
Ниже приведен список методов, применяемых для удаления сессии.
|
Метод |
Описание |
|
|
Удаляет элемент из коллекции состояний сессии |
|
|
Удаляет все элементы из коллекции сессий |
|
|
Удаляет все элементы из коллекции сессий. Замечание: Нет разницы между Clearи RemoveAll. RemoveAll() внутренне вызывает Clear(). |
|
|
Удаляет текущую сессию. |
Включение и отключение сессии
Для оптимизации производительности можно включить или отключить сессию, потому что каждое обращение к странице для чтения и записи сопряжено с издержками производительности. Поэтому лучше включать и отключать сессию на основе требований, а не делать ее всегда включенной. Можно включить и отключить состояние сессии двумя путями:
• Уровень страницы
• Уровень приложения
Уровень страницы:
Можно отключить состояние сессии на уровне страницы с помощью атрибутов EnableSessionState в директиве Страница.
Это отключает активность сессии для данной конкретной страницы.
Также можно сделать ее доступной только для чтения. Она будет разрешать обращаться к данным сессии, но не даст писать данные в сессию.
Уровень приложения:
Можно отключить состояние сессии во всем веб-приложении с помощью свойства EnableSessionState в Web.Config.
Обычно используется уровень страницы, потому что некоторые страницы не требуют данных сессии или только читают данные сессии.
Вывод
Теперь вы знакомы с сессией, ее использованием, как применять ее в веб-фермах и др. в ASP.NET 2.0. В качестве вывода,
• Внутрипроцессный (InProc) поставщик сессии – наиболее быстрый метод, потому что все хранится в памяти. Данные сессии теряются при перезапуске веб-сервера или при возврате рабочего процесса в исходное состояние. Он применяется в маленьких веб-приложениях с малым числом пользователей. Не используйте InProc в веб-ферме.
• В режиме сессии StateServer данные сессии хранятся с помощью aspnet_state.exe. Он держит данные сессии вне веб-сервера. Поэтому любая проблема с веб-сервером не влияет на данные сессии. Надо сериализовать объект перед сохранением данных в сессии сервера состояний. Его можно использовать в веб-ферме.
• Режим сессии SQLServer хранит данные в SQL Server, надо задать строку подключения. Также надо сериализовать данные перед сохранением их в сессии. Он очень полезен в производственной среде с режимом веб-фермы.
• Можно использовать пользовательский поставщик для пользовательского источника данных или при необходимости использовать существующую таблицу для хранения данных сессии. В пользовательском режиме также можно создать пользовательский идентификатор сессии. Но создавать собственный пользовательский поставщик не рекомендуется. Следует использовать любой сторонний поставщик.