Сессия (информатика)

редактировать

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

Установленный сеанс является основным требованием для выполнения связи с установлением соединения. Сеанс также является основным этапом передачи в режимах связи без установления соединения. Однако любая однонаправленная передача не определяет сеанс.

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

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

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

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

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

Содержание

  • 1 Программная реализация
  • 2 Веб-сеансы на стороне сервера
  • 3 Веб-сеансы на стороне клиента
  • 4 Маркер сеанса HTTP
  • 5 Управление сеансом
    • 5.1 Управление сеансом рабочего стола
    • 5.2 Управление сеансом в браузере
    • 5.3 Управление сеансом веб-сервера
    • 5.4 Управление сеансом через SMS
  • 6 См. Также
  • 7 Ссылки
  • 8 Внешние ссылки

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

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

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

Веб-сеансы на стороне сервера

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

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

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

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

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

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

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

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

Маркер сеанса HTTP

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

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

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

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

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

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

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

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

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

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

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

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

В сервис-ориентированной архитектуре, могут использоваться сообщения Simple Object Access Protocol или SOAP, созданные с помощью расширяемого языка разметки (XML ) пользовательскими приложениями, чтобы веб-серверы создавали сеансы.

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

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

См. Также

Ссылки

  1. ^Протокол без сеанса и ориентированный на сеанс протокол
  2. ^InterCarrier Messaging Guidelines (PDF), CTIA, получено 02.06.2018
  3. ^Hppy 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 »rev2, июнь 1985 г.
  • [1] Выдержка из книги Майка Эндрюса и Джеймса А. Уиттакера« Как взломать веб-программное обеспечение: функциональное тестирование и тестирование безопасности веб-приложений и веб-служб ».

Внешние ссылки

Последняя правка сделана 2021-06-08 01:32:03
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте