Сессия (информатика) - Session (computer science)

В Информатика и сеть в частности, сессия представляет собой временный и интерактивный обмен информацией между двумя или более взаимодействующими устройствами или между компьютером и пользователем (см. сеанс входа в систему ). Сессия устанавливается в определенный момент времени, а затем «разрывается» - доводится до конца - позже. Установленный сеанс связи может включать более одного сообщения в каждом направлении. Сеанс обычно сохранный, что означает, что по крайней мере одна из взаимодействующих сторон должна хранить информацию о текущем состоянии и сохранять информацию об истории сеанса, чтобы иметь возможность общаться, в отличие от без гражданства общение, при котором общение состоит из независимых запросов с ответами.

Установленный сеанс - основное требование для выполнения связь с установлением соединения. Сеанс также является основным шагом для передачи в связь без установления соединения режимы. Однако любая однонаправленная передача не определяет сеанс.[1]

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

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

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

Большинство сеансов клиент-сервер поддерживается транспортным уровнем - одно соединение для одного сеанса. Однако каждая фаза транзакции сеанса Web / HTTP создает отдельное соединение. Для поддержания непрерывности сеанса между фазами требуется идентификатор сессии. В идентификатор сессии встроен в ссылки или

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

Программная реализация

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

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

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

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

Метод использования сеансов на стороне сервера в системах без запоминающих устройств заключается в резервировании части ОЗУ для хранения данных сеанса. Этот метод применим для серверов с ограниченным количеством клиентов (например, маршрутизатор или точка доступа с нечастым или запрещенным доступом более чем к одному клиенту одновременно).

Клиентские веб-сеансы

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

Этот механизм может хорошо работать в некоторых контекстах; однако данные, хранящиеся на клиенте, уязвимы для подделки со стороны пользователя или программного обеспечения, имеющего доступ к клиентскому компьютеру. Чтобы использовать сеансы на стороне клиента, где требуются конфиденциальность и целостность, необходимо гарантировать следующее:

  1. Конфиденциальность: ничто, кроме сервера, не должно интерпретировать данные сеанса.
  2. Целостность данных: ничто, кроме сервера, не должно манипулировать данными сеанса (случайно или злонамеренно).
  3. Аутентичность: ничто, кроме сервера, не должно инициировать действительные сеансы.

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

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

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

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

Управление сессией

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

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

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

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

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

Управление сеансом особенно полезно в веб-браузер где пользователь может сохранить все открытые страницы и настройки и восстановить их позже или на другом компьютере (см. переносимость данных ).

Чтобы помочь восстановиться после сбоя системы или приложения, страницы и настройки также можно восстановить при следующем запуске. Гугл Хром, Mozilla Firefox, Internet Explorer, OmniWeb и Опера являются примерами веб-браузеров, поддерживающих управление сеансами. Управление сеансом часто осуществляется с помощью приложения печенье.

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

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

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

Если информация о сеансе считается временной, изменчивые данные, которые не требуются для неотречение транзакций и не содержит данных, которые подлежат аудиту соответствия (например, в США см. Медицинское страхование Портативность и Акт об ответственности и Закон Сарбейнса-Оксли для примеров двух законов, которые требуют аудита соответствия), то можно использовать любой метод хранения информации о сеансе. Однако, если информация о сеансе подлежит аудиту соответствия, следует рассмотреть метод, используемый для хранения сеанса, репликации и кластеризации.

В Сервис-Ориентированная Архитектура, Простой протокол доступа к объектам или МЫЛО сообщения, созданные с помощью Extensible Markup Language (XML ) сообщения могут использоваться потребительскими приложениями, чтобы заставить веб-серверы создавать сеансы.

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

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

Смотрите также

Рекомендации

  1. ^ Бессессионный протокол и сессионно-ориентированный протокол
  2. ^ Рекомендации по обмену сообщениями между операторами связи (PDF), CTIA, получено 2018-06-02
  3. ^ Привет, bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 декабря 2002 г.
  4. ^ GSM Doc 28/85 "Услуги и средства, предоставляемые в системе GSM" ред. 2, июнь 1985 г.
  • [1] Отрывок из статьи Майка Эндрюса и Джеймса А. Уиттакера «Как взломать веб-программное обеспечение: функциональное тестирование и тестирование безопасности веб-приложений и веб-служб».

внешняя ссылка