Введение

Временной контекст для интерактивного обмена информацией

В информатике, и особенно в сетевых технологиях, сеанс – это ограниченная по времени двусторонняя связь, практический (относительно высокий) уровень в протоколе TCP/IP, обеспечивающий интерактивное взаимодействие и обмен информацией между двумя или более устройствами связи или конечными точками – будь то компьютеры, автоматизированные системы или активные пользователи (см. сеанс входа в систему). Сеанс устанавливается в определенный момент времени и затем «завершается» – прекращается в какой-то более поздний момент. В установленном сеансе связи может быть передано более одного сообщения в каждом направлении. Сеанс, как правило, является состоятельным, то есть по крайней мере одна из сторон, участвующих в обмене данными, должна хранить информацию о текущем состоянии и сохранять историю сеанса для обеспечения связи, в отличие от безгосударственной связи, где обмен данными состоит из независимых запросов и ответов. Установленный сеанс является базовым требованием для организации связи, ориентированной на установление соединения. Сеанс также является базовым шагом для передачи данных в режимах без установления соединения. Однако любое однонаправленное взаимодействие не определяет сеанс. Транспорт связи может быть реализован как часть протоколов и служб на уровне приложений, сеансовом или транспортном уровне в модели OSI. Примеры уровня приложений: HTTP-сеансы, позволяющие связывать информацию с отдельными посетителями; сеанс удаленного входа в систему telnet. Пример сеансового уровня: интернет-телефонный звонок на основе протокола инициирования сеанса (SIP). Пример транспортного уровня: TCP-сеанс, который является синонимом виртуальной цепи TCP, TCP-соединения или установленного TCP-сокета. В случае транспортных протоколов, которые не реализуют формальный сеансовый уровень (например, UDP) или где сеансы на уровне приложений обычно очень кратковременны (например, HTTP), сеансы поддерживаются программой более высокого уровня с использованием метода, определенного в передаваемых данных. Например, обмен HTTP между браузером и удаленным хостом может включать HTTP-cookie, идентифицирующий состояние, такое как уникальный идентификатор сеанса, информация о предпочтениях пользователя или уровне авторизации. HTTP/1.0 предполагал возможность только одного запроса и ответа в рамках одной Web/HTTP-сессии. Версия протокола HTTP/1.1 улучшила это, завершив реализацию Common Gateway Interface (CGI), что упростило поддержание Web-сессии и поддержку HTTP-cookie и загрузки файлов. Большинство клиент-серверных сеансов поддерживаются транспортным уровнем – одно соединение для одного сеанса. Однако каждая фаза транзакции Web/HTTP-сессии создает отдельное соединение. Для поддержания непрерывности сеанса между фазами требуется идентификатор сеанса. Идентификатор сеанса встраивается в ссылки <A HREF> или <FORM> динамических веб-страниц, чтобы он передавался обратно в CGI. CGI затем использует идентификатор сеанса для обеспечения непрерывности сеанса между фазами транзакции. Одним из преимуществ одного соединения на фазу является то, что оно хорошо работает при низкой пропускной способности канала связи (например, при использовании модема).

Внедрение программного обеспечения

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

Сеансы на сервере

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

Веб-сессии на стороне клиента

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

Токен сеанса HTTP

Токен сеанса — это уникальный идентификатор, который генерируется сервером и отправляется клиенту для идентификации текущей сессии взаимодействия. Клиент обычно хранит и отправляет токен в виде HTTP-cookie и/или передает его как параметр в GET- или POST-запросах. Использование токенов сеанса позволяет клиенту оперировать только идентификатором, в то время как все данные сеанса хранятся на сервере (обычно в базе данных, к которой у клиента нет прямого доступа) и связаны с этим идентификатором. Примеры имен, используемых некоторыми языками программирования для HTTP-cookie, включают JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI) и ASPSESSIONID (ASP).

Управление сеансом

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

Управление сеансом на рабочем столе

Менеджер сеансов рабочего стола — это программа, которая позволяет сохранять и восстанавливать сеансы рабочего стола. Сеанс рабочего стола включает в себя все запущенные в данный момент окна и их текущее содержимое. В Linux-системах управление сеансами осуществляется X-менеджером сеансов. В системах Microsoft Windows управление сеансами обеспечивается подсистемой управления сеансами (smss.exe), а функциональность пользовательских сеансов может быть расширена сторонними приложениями, например, twinsplay.

Управление сеансом браузера

Управление сеансами особенно полезно в веб-браузере, где пользователь может сохранить все открытые страницы и настройки и восстановить их позднее или на другом компьютере (см. переносимость данных). Для восстановления после сбоя системы или приложения страницы и настройки также могут быть восстановлены при следующем запуске. Google Chrome, Mozilla Firefox, Internet Explorer, OmniWeb и Opera — примеры веб-браузеров, поддерживающих управление сеансами. Управление сеансами часто реализуется с помощью файлов cookie.

Управление сеансом веб-сервера

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

В ситуациях, когда нескольким веб-серверам необходимо совместно использовать информацию о состоянии сеанса (что типично для кластерной среды), информация о сеансе должна быть доступна всем узлам кластера, на которых работает программное обеспечение веб-сервера. Методы совместного использования состояния сеанса между узлами кластера включают: многоадресную рассылку информации о сеансе узлам кластера (например, JGroups), обмен информацией о сеансе с парным узлом с использованием распределенной общей памяти или виртуализации памяти, обмен информацией о сеансе между узлами через сетевые сокеты, хранение информации о сеансе в общей файловой системе, такой как распределенная или глобальная файловая система, или хранение информации о сеансе вне кластера в базе данных. Если информация о сеансе рассматривается как временные, неустойчивые данные, не требуемые для неотрекаемости транзакций и не содержащие данные, подлежащие аудиту соответствия (например, в США – Закон о переносимости и подотчетности медицинского страхования и Закон Сарбейнса-Оксли, как примеры двух законов, требующих аудита соответствия), то можно использовать любой метод хранения информации о сеансе. Однако, если информация о сеансе подлежит аудиту соответствия, следует учитывать метод хранения, репликации и кластеризации сеанса. В сервисно-ориентированной архитектуре сообщения Simple Object Access Protocol (SOAP), построенные с использованием сообщений Extensible Markup Language (XML), могут использоваться клиентскими приложениями для инициирования создания сеансов на веб-серверах.

Управление сеансом через SMS

Как HTTP является протоколом без сохранения состояния, так и SMS. Когда в 1999 году SMS стал совместим с конкурирующими сетями, и текстовые сообщения начали стремительно набирать популярность, превращаясь в повсеместную глобальную форму общения, различные компании проявили интерес к использованию канала SMS в коммерческих целях. Первоначальные сервисы не требовали управления сеансами, поскольку представляли собой одностороннюю связь (например, в 2000 году первая мобильная служба новостей была запущена через SMS в Финляндии). Сегодня эти приложения называют сообщениями от приложения к пользователю (A2P), в отличие от сообщений от пользователя к пользователю (P2P). Разработка интерактивных корпоративных приложений потребовала управления сеансами, но поскольку SMS является протоколом без сохранения состояния, как это определено стандартами GSM, ранние реализации осуществлялись с помощью клиентского управления, требуя от конечных пользователей ручного ввода команд и идентификаторов услуг.