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

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

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

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

Примеры прикладного уровня:
- HTTP-сессии , которые позволяют связывать информацию с отдельными посетителями.
- Сеанс систему telnet удаленного входа в
Пример сеансового уровня:
- ( на основе протокола инициации сеанса SIP) Интернет-телефонный звонок
Пример транспортного уровня:
- Сеанс TCP , который является синонимом виртуального канала TCP , соединения TCP или установленного сокета TCP .

В случае транспортных протоколов, которые не реализуют формальный сеансовый уровень (например, 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 возвращается клиентом.

Токен HTTP-сессии [ править ]

который генерируется и отправляется с сервера клиенту Токен сеанса — это уникальный идентификатор , для идентификации текущего сеанса взаимодействия. Клиент обычно хранит и отправляет токен в виде файла 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 [ править ]

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

См. также [ править ]

Ссылки [ править ]

^ Протокол, ориентированный на сеансы, и протокол, ориентированный на сеансы
^ Рекомендации по обмену сообщениями InterCarrier (PDF) , CTIA , получено 2 июня 2018 г.
^ С уважением, текст! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm , 3 декабря 2002 г.
^ GSM Doc 28/85 «Услуги и средства, предоставляемые в системе GSM», ред. 2, июнь 1985 г.

Внешние ссылки [ править ]

Сеансы Дуга Ли

[1] Протокол, ориентированный на сеансы, и протокол, ориентированный на сеансы

[2] Рекомендации по обмену сообщениями InterCarrier (PDF) , CTIA , получено 2 июня 2018 г.

[3] С уважением, текст! 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]

[2]

[3]

[4]