Sesja (informatyka) - Session (computer science)

W szczególności w informatyce i sieciach sesja jest tymczasową i interaktywną wymianą informacji między dwoma lub więcej komunikującymi się urządzeniami lub między komputerem a użytkownikiem (patrz sesja logowania ). Sesja nawiązywana jest w pewnym momencie, a następnie „zrywana” – doprowadzona do końca – w jakimś późniejszym momencie. Ustanowiona sesja komunikacyjna może obejmować więcej niż jedną wiadomość w każdym kierunku. Sesja jest zazwyczaj stanowa , co oznacza, że ​​co najmniej jedna ze stron komunikujących się musi przechowywać informacje o bieżącym stanie i informacje o historii sesji, aby móc się komunikować, w przeciwieństwie do komunikacji bezstanowej , gdzie komunikacja składa się z niezależnych żądań z odpowiedziami.

Ustanowiona sesja jest podstawowym warunkiem komunikacji zorientowanej na połączenie . Sesja jest również podstawowym krokiem do transmisji w trybach komunikacji bezpołączeniowej . Jednak żadna transmisja jednokierunkowa nie definiuje sesji.

Komunikacja Transport może być zaimplementowany jako część protokołów i usług w warstwie aplikacji , w warstwie sesji lub w warstwie transportu w modelu OSI .

W przypadku protokołów transportowych, które nie implementują formalnej warstwy sesji (np. UDP ) lub gdy sesje w warstwie aplikacji są ogólnie bardzo krótkotrwałe (np. HTTP), sesje są utrzymywane przez program wyższego poziomu przy użyciu zdefiniowanej metody w wymienianych danych. Na przykład wymiana HTTP między przeglądarką a zdalnym hostem może obejmować plik cookie HTTP, który identyfikuje stan, taki jak unikalny identyfikator sesji , informacje o preferencjach użytkownika lub poziomie autoryzacji.

Uważano, że protokół HTTP/1.0 umożliwia tylko jedno żądanie i odpowiedź podczas jednej sesji sieci Web/HTTP. Wersja protokołu HTTP/1.1 poprawiła to, uzupełniając interfejs Common Gateway Interface (CGI), ułatwiając utrzymanie sesji sieciowej oraz obsługując pliki cookie i przesyłanie plików HTTP .

Większość sesji klient-serwer jest obsługiwana przez warstwę transportową — pojedyncze połączenie dla pojedynczej sesji. Jednak każda faza transakcji sesji Web/HTTP tworzy osobne połączenie. Utrzymanie ciągłości sesji między fazami wymaga identyfikatora sesji . ID sesji jest osadzony w <A HREF> lub <FORM> linki dynamicznych stron internetowych tak, że jest przekazywana z powrotem CGI. CGI następnie używa identyfikatora sesji, aby zapewnić ciągłość sesji między fazami transakcji. Jedną z zalet jednego połączenia na fazę jest to, że działa dobrze w przypadku połączeń o niskiej przepustowości (modemu).

Wdrażanie oprogramowania

Sesje TCP są zazwyczaj implementowane w oprogramowaniu przy użyciu procesów podrzędnych i/lub wielowątkowości , gdzie nowy proces lub wątek jest tworzony, gdy komputer ustanawia sesję lub dołącza do niej. Sesje HTTP zazwyczaj nie są realizowane przy użyciu jednego wątku na sesję, ale za pomocą bazy danych zawierającej informacje o stanie każdej sesji. Zaletą wielu procesów lub wątków jest rozluźniona złożoność oprogramowania, ponieważ każdy wątek jest instancją z własną historią i enkapsulowanymi zmiennymi. Wadą jest duży narzut zasobów systemowych oraz możliwość przerwania sesji w przypadku ponownego uruchomienia systemu.

Gdy klient może połączyć się z dowolnym serwerem w klastrze serwerów, pojawia się specjalny problem w utrzymaniu spójności, gdy serwery muszą utrzymywać stan sesji. Klient musi być albo skierowany do tego samego serwera na czas trwania sesji, albo serwery muszą przesyłać informacje o sesji po stronie serwera za pośrednictwem współużytkowanego systemu plików lub bazy danych. W przeciwnym razie klient może ponownie połączyć się z innym serwerem niż ten, z którym rozpoczął sesję, co spowoduje problemy, gdy nowy serwer nie będzie miał dostępu do zapisanego stanu starego.

Sesje internetowe po stronie serwera

Sesje po stronie serwera są przydatne i wydajne, ale w połączeniu z systemami równoważenia obciążenia/wysokiej dostępności mogą być trudne do obsługi i nie nadają się do użytku w niektórych systemach wbudowanych bez pamięci masowej. Problem równoważenia obciążenia można rozwiązać, korzystając ze współdzielonej pamięci masowej lub stosując wymuszone połączenia równorzędne między każdym klientem a pojedynczym serwerem w klastrze, chociaż może to negatywnie wpłynąć na wydajność systemu i rozkład obciążenia.

Metodą korzystania z sesji po stronie serwera w systemach bez pamięci masowej jest zarezerwowanie części pamięci RAM na przechowywanie danych sesji. Ta metoda ma zastosowanie do serwerów z ograniczoną liczbą klientów (np. router lub punkt dostępowy z rzadkim lub niedozwolonym dostępem do więcej niż jednego klienta na raz).

Sesje internetowe po stronie klienta

Sesje po stronie klienta używają plików cookie i technik kryptograficznych w celu utrzymania stanu bez przechowywania tak dużej ilości danych na serwerze. Serwer prezentując dynamiczną stronę WWW przesyła aktualne dane o stanie do klienta (przeglądarki internetowej) w postaci ciasteczka. Klient zapisuje plik cookie w pamięci lub na dysku. Z każdym kolejnym żądaniem klient odsyła plik cookie z powrotem do serwera, a serwer wykorzystuje te dane do „zapamiętania” stanu aplikacji dla tego konkretnego klienta i wygenerowania odpowiedniej odpowiedzi.

Ten mechanizm może działać dobrze w niektórych kontekstach; jednak dane przechowywane na kliencie są podatne na manipulację przez użytkownika lub oprogramowanie, które ma dostęp do komputera klienckiego. Aby korzystać z sesji po stronie klienta, gdzie wymagana jest poufność i integralność, należy zapewnić:

  1. Poufność: nic poza serwerem nie powinno być w stanie zinterpretować danych sesji.
  2. Integralność danych: nic poza serwerem nie powinno manipulować danymi sesji (przypadkowo lub złośliwie).
  3. Autentyczność: nic poza serwerem nie powinno być w stanie zainicjować prawidłowych sesji.

Aby to osiągnąć, serwer musi zaszyfrować dane sesji przed wysłaniem ich do klienta, a modyfikację takich informacji przez jakąkolwiek inną stronę należy uniemożliwić za pomocą środków kryptograficznych.

Przesyłanie stanu tam iz powrotem przy każdym żądaniu jest praktyczne tylko wtedy, gdy rozmiar pliku cookie jest mały. Zasadniczo sesje po stronie klienta wymieniają miejsce na dysku serwera na dodatkową przepustowość, której będzie wymagać każde żądanie sieciowe. Ponadto przeglądarki internetowe ograniczają liczbę i rozmiar plików cookie, które mogą być przechowywane przez witrynę internetową. Aby poprawić wydajność i umożliwić więcej danych sesji, serwer może skompresować dane przed utworzeniem pliku cookie, dekompresując je później, gdy plik cookie zostanie zwrócony przez klienta.

Token sesji HTTP

Token sesji to unikalny identyfikator, który jest generowany i wysyłany z serwera do klienta w celu identyfikacji bieżącej sesji interakcji. Klient zazwyczaj przechowuje i wysyła token jako plik cookie HTTP i/lub wysyła go jako parametr w zapytaniach GET lub POST. Powodem używania tokenów sesji jest to, że klient musi tylko obsłużyć identyfikator — wszystkie dane sesji są przechowywane na serwerze (zwykle w bazie danych , do której klient nie ma bezpośredniego dostępu) połączonej z tym identyfikatorem. Przykłady nazw używanych przez niektóre języki programowania podczas nazywania swoich plików cookie HTTP obejmują JSESSIONID ( JSP ), PHPSESSID ( PHP ), CGISESSID ( CGI ) i ASPSESSIONID ( ASP ).

Zarządzanie sesją

W interakcji człowiek-komputer , zarządzania sesjami to proces śledzenia aktywności użytkownika między sesjami interakcji z systemem komputerowym .

Typowe zadania zarządzania sesjami w środowisku graficznym obejmują śledzenie, które aplikacje są otwarte i jakie dokumenty otworzyła każda aplikacja, dzięki czemu ten sam stan można przywrócić, gdy użytkownik wyloguje się i zaloguje później. W przypadku strony internetowej zarządzanie sesją może wiązać się z wymaganiem od użytkownika ponownego zalogowania się, jeśli sesja wygasła (tj. upłynął pewien czas bez aktywności użytkownika). Służy również do przechowywania informacji po stronie serwera pomiędzy żądaniami HTTP.

Zarządzanie sesjami pulpitu

Menedżer sesji pulpitu to program, który może zapisywać i przywracać sesje pulpitu. Sesja pulpitu to wszystkie aktualnie uruchomione okna i ich aktualna zawartość. Zarządzanie sesją w systemach opartych na systemie Linux zapewnia menedżer sesji X . W systemach Microsoft Windows zarządzanie sesjami zapewnia podsystem menedżera sesji (smss.exe); Funkcjonalność sesji użytkownika można rozszerzyć o aplikacje innych firm, takie jak twinsplay .

Zarządzanie sesją przeglądarki

Zarządzanie sesją jest szczególnie przydatne w przeglądarce internetowej, gdzie użytkownik może zapisać wszystkie otwarte strony i ustawienia oraz przywrócić je w późniejszym terminie lub na innym komputerze (patrz przenośność danych ).

Aby pomóc w odzyskaniu sprawności po awarii systemu lub aplikacji, strony i ustawienia można również przywrócić przy następnym uruchomieniu. Google Chrome , Mozilla Firefox , Internet Explorer , OmniWeb i Opera to przykłady przeglądarek internetowych obsługujących zarządzanie sesjami. Zarządzanie sesją jest często zarządzane za pomocą plików cookie .

Zarządzanie sesją serwera WWW

Protokół HTTP ( Hypertext Transfer Protocol ) jest bezstanowy: komputer kliencki z przeglądarką internetową musi ustanowić nowe połączenie sieciowe protokołu TCP ( Transmission Control Protocol ) z serwerem sieciowym przy każdym nowym żądaniu HTTP GET lub POST. Dlatego serwer sieciowy nie może polegać na ustanowionym połączeniu sieciowym TCP dłużej niż pojedyncza operacja HTTP GET lub POST. Zarządzanie sesją to technika wykorzystywana przez programistę do tworzenia stanu sesji obsługi bezstanowego protokołu HTTP. Na przykład po uwierzytelnieniu użytkownika na serwerze sieciowym następne żądanie HTTP użytkownika (GET lub POST) nie powinno powodować, że serwer sieciowy ponownie zażąda konta i hasła użytkownika. Aby zapoznać się z omówieniem metod użytych do osiągnięcia tego, zobacz plik cookie HTTP i identyfikator sesji

W sytuacjach, w których wiele serwerów WWW musi dzielić się wiedzą o stanie sesji (co jest typowe w środowisku klastra ), informacje o sesji muszą być udostępniane między węzłami klastra, na których działa oprogramowanie serwera WWW. Metody udostępniania stanu sesji między węzłami w klastrze obejmują: rozsyłanie informacji o sesji multiemisji do węzłów członkowskich ( jeden przykład tej techniki znajduje się w JGroups ), udostępnianie informacji o sesji z węzłem partnerskim przy użyciu rozproszonej pamięci współdzielonej lub wirtualizacji pamięci , udostępnianie informacji o sesji między węzłami przy użyciu gniazda sieciowe, przechowywanie informacji o sesji we współużytkowanym systemie plików, takim jak rozproszony system plików lub globalny system plików , lub przechowywanie informacji o sesji poza klastrem w bazie danych .

Jeśli informacja sesja jest uważana za przejściową, dane lotne, które nie są wymagane do niezaprzeczalności transakcji i nie zawierają danych, które są przedmiotem badania zgodności (w USA na przykład, zobacz Health Insurance przenoszenia i Accountability Act i Sarbanes-Oxley Posłuż się przykładami dwóch praw, które wymagają audytu zgodności), wtedy można zastosować dowolną metodę przechowywania informacji o sesji. Jeśli jednak informacje o sesji podlegają kontroli zgodności, należy zwrócić uwagę na metodę używaną do przechowywania sesji, replikacji i klastrowania.

W architekturze zorientowanej na usługi komunikaty Simple Object Access Protocol lub SOAP skonstruowane za pomocą komunikatów Extensible Markup Language ( XML ) mogą być używane przez aplikacje konsumenckie do powodowania tworzenia sesji przez serwery internetowe.

Zarządzanie sesją przez SMS

Tak jak HTTP jest protokołem bezstanowym , tak samo jest z SMS-em . Gdy w 1999 r. SMS-y stały się interoperacyjne w konkurencyjnych sieciach, a wiadomości tekstowe zaczęły stawać się wszechobecną globalną formą komunikacji, różne przedsiębiorstwa zainteresowały się wykorzystaniem kanału SMS do celów komercyjnych. Początkowe usługi nie wymagały zarządzania sesjami, ponieważ były tylko komunikacją jednokierunkową (na przykład w 2000 r. pierwsza mobilna usługa wiadomości była dostarczana za pośrednictwem SMS-ów w Finlandii ). Obecnie te aplikacje są określane jako komunikacja między aplikacjami (A2P) w odróżnieniu od komunikacji peer-to-peer (P2P) . Rozwój interaktywnych aplikacji korporacyjnych wymagał zarządzania sesjami, ale ponieważ SMS jest protokołem bezstanowym zdefiniowanym w standardach GSM, wczesne implementacje były kontrolowane po stronie klienta poprzez ręczne wprowadzanie poleceń i identyfikatorów usług przez użytkowników końcowych.

Zobacz też

Bibliografia

  1. ^ Protokół zorientowany na sesję i protokół zorientowany na sesję
  2. ^ InterCarrier Messaging Wytyczne (PDF) , CTIA , pobrane 2018-06-02
  3. ^ Hppy bthdy txt! BBC News World Edition, http://news.bbc.co.uk/2/hi/uk_news/2538083.stm 3 grudnia 2002 r.
  4. ^ GSM Doc 28/85 „Usługi i udogodnienia, które mają być świadczone w systemie GSM” rev2, czerwiec 1985

Linki zewnętrzne