В частности, в информатике и сетевых технологиях сеанс — это двусторонняя связь с разделением по времени, практический (относительно высокий) уровень протокола TCP/IP , обеспечивающий интерактивное выражение и обмен информацией между двумя или более коммуникационными устройствами или концами — будь они компьютеры, автоматизированные системы или живые активные пользователи (см. сеанс входа в систему ). Сессия устанавливается в определенный момент времени, а затем «срывается» — завершается — в какой-то более поздний момент. Установленный сеанс связи может включать более одного сообщения в каждом направлении. Сеанс обычно имеет состояние , что означает, что по крайней мере одна из взаимодействующих сторон должна хранить информацию о текущем состоянии и сохранять информацию об истории сеанса, чтобы иметь возможность общаться, в отличие от связи без сохранения состояния , где связь состоит из независимых запросов с ответами.
Установленный сеанс является основным требованием для осуществления связи, ориентированной на соединение . Сеанс также является основным этапом передачи в режимах связи без установления соединения . Однако любая однонаправленная передача не определяет сеанс. [1]
Коммуникационный транспорт может быть реализован как часть протоколов и сервисов на уровне приложений , сеансовом уровне или транспортном уровне в модели OSI .
В случае транспортных протоколов, которые не реализуют формальный сеансовый уровень (например, UDP ) или где сеансы на прикладном уровне обычно очень кратковременны (например, HTTP), сеансы поддерживаются программой более высокого уровня с использованием определенного метода. в обмениваемых данных. Например, обмен HTTP между браузером и удаленным хостом может включать в себя файл cookie HTTP , который идентифицирует состояние, например уникальный идентификатор сеанса , информацию о предпочтениях пользователя или уровне авторизации.
Считалось, что HTTP/1.0 допускает только один запрос и ответ в течение одного сеанса Web/HTTP. Версия протокола HTTP/1.1 улучшила эту ситуацию за счет добавления общего интерфейса шлюза (CGI), упрощающего обслуживание веб-сеанса и поддерживающего файлы cookie HTTP и загрузку файлов.
Большинство сеансов клиент-сервер поддерживаются на транспортном уровне — одно соединение для одного сеанса. Однако каждая фаза транзакции сеанса Web/HTTP создает отдельное соединение. Для поддержания непрерывности сеанса между этапами требуется идентификатор сеанса . Идентификатор сеанса встраивается в ссылки <A HREF> или <FORM> динамических веб-страниц , поэтому он передается обратно в CGI. Затем CGI использует идентификатор сеанса для обеспечения непрерывности сеанса между фазами транзакции. Одним из преимуществ одного соединения на фазу является то, что оно хорошо работает при соединениях с низкой пропускной способностью (модем).
Сеансы TCP обычно реализуются в программном обеспечении с использованием дочерних процессов и/или многопоточности , когда новый процесс или поток создается, когда компьютер устанавливает сеанс или присоединяется к нему. Сеансы HTTP обычно реализуются не с использованием одного потока на сеанс, а с помощью базы данных с информацией о состоянии каждого сеанса. Преимущество нескольких процессов или потоков заключается в уменьшении сложности программного обеспечения, поскольку каждый поток представляет собой экземпляр со своей собственной историей и инкапсулированными переменными. Недостатком являются большие накладные расходы с точки зрения системных ресурсов и то, что сеанс может быть прерван при перезапуске системы.
Когда клиент может подключиться к любому серверу в кластере серверов, возникает особая проблема с поддержанием согласованности, когда серверы должны поддерживать состояние сеанса. Клиент должен быть либо направлен на один и тот же сервер на время сеанса, либо серверы должны передавать информацию о сеансе на стороне сервера через общую файловую систему или базу данных. В противном случае клиент может повторно подключиться к серверу, отличному от того, с которым он начал сеанс, что вызовет проблемы, когда новый сервер не будет иметь доступа к сохраненному состоянию старого.
Сеансы на стороне сервера удобны и эффективны, но их может быть сложно обрабатывать в сочетании с системами балансировки нагрузки/высокой доступности, и их вообще невозможно использовать в некоторых встроенных системах без хранилища. Проблему балансировки нагрузки можно решить, используя общее хранилище или применив принудительный пиринг между каждым клиентом и одним сервером в кластере, хотя это может поставить под угрозу эффективность системы и распределение нагрузки.
Метод использования сеансов на стороне сервера в системах без запоминающего устройства заключается в резервировании части оперативной памяти для хранения данных сеанса. Этот метод применим для серверов с ограниченным количеством клиентов (например, маршрутизатор или точка доступа с нечастым или запрещенным доступом к более чем одному клиенту одновременно).
В сеансах на стороне клиента используются файлы cookie и криптографические методы для поддержания состояния без хранения большого количества данных на сервере. При представлении динамической веб-страницы сервер отправляет данные о текущем состоянии клиенту (веб-браузеру) в виде файла cookie. Клиент сохраняет файл cookie в памяти или на диске. При каждом последующем запросе клиент отправляет файл cookie обратно на сервер, и сервер использует данные, чтобы «запомнить» состояние приложения для этого конкретного клиента и сгенерировать соответствующий ответ.
Этот механизм может хорошо работать в некоторых контекстах; однако данные, хранящиеся на клиенте, уязвимы для несанкционированного вмешательства со стороны пользователя или программного обеспечения, имеющего доступ к клиентскому компьютеру. Чтобы использовать сеансы на стороне клиента, где требуются конфиденциальность и целостность, необходимо гарантировать следующее:
Для этого серверу необходимо зашифровать данные сеанса перед отправкой их клиенту, а изменение такой информации любой другой стороной должно быть предотвращено с помощью криптографических средств.
Передача состояния туда и обратно при каждом запросе практична только в том случае, если размер файла cookie невелик. По сути, сеансы на стороне клиента обменивают дисковое пространство сервера на дополнительную пропускную способность, необходимую для каждого веб-запроса. Более того, веб-браузеры ограничивают количество и размер файлов cookie, которые могут храниться на веб-сайте. Чтобы повысить эффективность и разрешить обработку большего количества данных сеанса, сервер может сжимать данные перед созданием файла cookie и распаковывать их позже, когда файл cookie возвращается клиентом.
Токен сеанса — это уникальный идентификатор, который генерируется и отправляется с сервера клиенту для идентификации текущего сеанса взаимодействия . Клиент обычно хранит и отправляет токен в виде файла cookie HTTP и/или отправляет его в качестве параметра в запросах GET или POST. Причина использования токенов сеанса заключается в том, что клиент должен обрабатывать только идентификатор — все данные сеанса хранятся на сервере (обычно в базе данных , к которой клиент не имеет прямого доступа), связанном с этим идентификатором. Примеры имен, которые некоторые языки программирования используют при именовании своих файлов cookie HTTP, включают 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) не должен заставлять веб-сервер снова запрашивать учетную запись и пароль пользователя. Для обсуждения методов, используемых для этого, см. файлы cookie HTTP и идентификатор сеанса.
В ситуациях, когда несколько веб-серверов должны совместно использовать информацию о состоянии сеанса (что типично для среды кластера ), информация о сеансе должна быть разделена между узлами кластера, на которых работает программное обеспечение веб-сервера. Методы совместного использования состояния сеанса между узлами в кластере включают: многоадресную рассылку информации о сеансе узлам-членам ( один из примеров этого метода см. в JGroups), совместное использование информации о сеансе с партнерским узлом с использованием распределенной общей памяти или виртуализации памяти , совместное использование информации о сеансе между узлами с помощью сетевые сокеты, хранение информации о сеансе в общей файловой системе, такой как распределенная файловая система или глобальная файловая система , или хранение информации о сеансе вне кластера в базе данных .
Если информация о сеансе считается временными, изменчивыми данными, которые не требуются для невозможности отказа от транзакций и не содержат данных, подлежащих аудиту соответствия (например, в США см. Закон о переносимости и подотчетности медицинского страхования и Закон Сарбейнса-Оксли). Если привести примеры двух законов, которые требуют проведения аудита соответствия), то можно использовать любой метод хранения информации о сеансе. Однако если информация о сеансе подлежит проверке на соответствие требованиям, следует уделить внимание методу, используемому для хранения, репликации и кластеризации сеанса.
В сервис-ориентированной архитектуре сообщения Simple Object Access Protocol или SOAP , созданные с помощью сообщений Extensible Markup Language ( XML ), могут использоваться потребительскими приложениями, чтобы заставить веб-серверы создавать сеансы.
SMS является протоколом без сохранения состояния точно так же , как и HTTP . Когда в 1999 году SMS стали совместимыми в конкурирующих сетях [2] , а обмен текстовыми сообщениями начал становиться повсеместной глобальной формой связи, [3] различные предприятия заинтересовались использованием канала SMS в коммерческих целях. Первоначальные услуги не требовали управления сеансами, поскольку они представляли собой только одностороннюю связь (например, в 2000 году первая мобильная служба новостей была доставлена через SMS в Финляндии ). Сегодня эти приложения называются обменом сообщениями между узлами (A2P) в отличие от обмена сообщениями в одноранговой сети (P2P) . Разработка интерактивных корпоративных приложений требовала управления сеансами, но поскольку SMS является протоколом без сохранения состояния, как это определено стандартами GSM, [4] ранние реализации контролировались на стороне клиента , заставляя конечных пользователей вручную вводить команды и идентификаторы услуг.