Sesja (informatyka)

W informatyce , a w szczególności w sieciach , sesja to ograniczone czasowo dwukierunkowe łącze, praktyczna (stosunkowo wysoka) warstwa w protokole TCP/IP, umożliwiająca interaktywną ekspresję i wymianę informacji między dwoma lub większą liczbą urządzeń komunikacyjnych lub końców – czy to komputery, systemy zautomatyzowane lub aktywni użytkownicy na żywo (patrz sesja logowania ). Sesja jest ustanawiana w określonym momencie, a następnie „burzona” – doprowadzona do końca – w pewnym późniejszym momencie. Ustanowiona sesja komunikacyjna może obejmować więcej niż jeden komunikat w każdym kierunku. Sesja jest zwykle stanowa , co oznacza, że ​​przynajmniej jedna z komunikujących się stron musi przechowywać informacje o bieżącym stanie i zapisać informacje o historii sesji, aby móc się komunikować, w przeciwieństwie do komunikacji bezstanowej , w której komunikacja składa się z niezależnych żądań z odpowiedziami.

Ustanowienie sesji jest podstawowym wymogiem do realizacji komunikacji zorientowanej na połączenie . Sesja jest również podstawowym etapem transmisji w komunikacji bezpołączeniowej . Jednak żadna transmisja jednokierunkowa nie definiuje sesji.

Komunikacja Transport może być realizowany w ramach protokołów i usług w warstwie aplikacji , w warstwie sesyjnej lub w warstwie transportowej w modelu OSI .

W przypadku protokołów transportowych, które nie implementują formalnej warstwy sesyjnej (np. UDP ) lub gdy sesje w warstwie aplikacji są z reguły bardzo krótkotrwałe (np. HTTP), sesje są utrzymywane przez program wyższego poziomu przy użyciu metody zdefiniowanej 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 HTTP/1.0 zezwala tylko na jedno żądanie i odpowiedź podczas jednej sesji Web/HTTP. Wersja protokołu HTTP/1.1 poprawiła to, uzupełniając Common Gateway Interface (CGI), ułatwiając utrzymanie sesji sieciowej i obsługując pliki cookie HTTP oraz przesyłanie plików.

Większość sesji klient-serwer jest utrzymywana przez warstwę transportową — pojedyncze połączenie dla jednej sesji. Jednak każda faza transakcji sesji Web/HTTP tworzy osobne połączenie. Zachowanie ciągłości sesji między fazami wymaga identyfikatora sesji . Identyfikator sesji jest osadzony w linkach <A HREF> lub <FORM> dynamicznych stron internetowych , dzięki czemu jest przekazywany z powrotem do CGI. Następnie CGI 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ń modemowych o niskiej przepustowości.

Implementacja oprogramowania

Sesje TCP są zwykle implementowane w oprogramowaniu przy użyciu procesów potomnych 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 złagodzona złożoność oprogramowania, ponieważ każdy wątek jest instancją z własną historią i hermetyzowanymi zmiennymi. Wadą jest duże obciążenie 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, napotyka się szczególny problem z utrzymaniem spójności, gdy serwery muszą utrzymywać stan sesji. Klient musi być skierowany do tego samego serwera na czas trwania sesji lub serwery muszą przesyłać informacje o sesji po stronie serwera za pośrednictwem udostępnionego 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 mogą być trudne w obsłudze w połączeniu z systemami równoważenia obciążenia/wysokiej dostępności iw ogóle nie nadają się do użytku w niektórych systemach wbudowanych bez pamięci. Problem z równoważeniem obciążenia można rozwiązać, używając współużytkowanej pamięci masowej lub wymuszonej komunikacji równorzędnej 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ą wykorzystania sesji po stronie serwera w systemach bez pamięci masowej jest zarezerwowanie części pamięci RAM do przechowywania danych sesji. Ta metoda ma zastosowanie do serwerów z ograniczoną liczbą klientów (np. router lub punkt dostępowy z rzadkim lub zabronionym dostępem do więcej niż jednego klienta na raz).

Sesje internetowe po stronie klienta

Sesje po stronie klienta wykorzystują pliki cookie i techniki kryptograficzne do utrzymania stanu bez przechowywania tak dużej ilości danych na serwerze. Podczas prezentacji dynamicznej strony internetowej serwer przesyła dane o aktualnym stanie do klienta (przeglądarki internetowej) w postaci pliku cookie. 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 dane do „zapamiętania” stanu aplikacji dla tego konkretnego klienta i wygenerowania odpowiedniej odpowiedzi.

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

  1. Poufność: nic poza serwerem nie powinno być w stanie interpretować 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 inicjować prawidłowych sesji.

Aby to osiągnąć, serwer musi zaszyfrować dane sesji przed wysłaniem ich do klienta, a modyfikacja takich informacji przez jakąkolwiek inną stronę powinna być uniemożliwiona 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 stronę 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 generowany i wysyłany z serwera do klienta w celu identyfikacji bieżącej sesji interakcji. Klient zwykle 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 sesyjnych jest to, że klient musi obsłużyć tylko identyfikator – wszystkie dane sesji są przechowywane na serwerze (zwykle w bazie danych , do której klient nie ma bezpośredniego dostępu) powiązanego z tym identyfikatorem. Przykłady nazw używanych przez niektóre języki programowania podczas nazywania plików cookie HTTP to JSESSIONID ( JSP ), PHPSESSID ( PHP ), CGISESSID ( CGI ) i ASPSESSIONID ( ASP ).

Zarządzanie sesją

W interakcji człowiek-komputer zarządzanie sesją to proces śledzenia aktywności użytkownika podczas sesji interakcji z systemem komputerowym .

Typowe zadania zarządzania sesją w środowisku komputerowym obejmują śledzenie, które aplikacje są otwarte i jakie dokumenty zostały otwarte przez poszczególne aplikacje, tak aby można było przywrócić ten sam stan, gdy użytkownik wyloguje się i zaloguje później. W przypadku witryny internetowej zarządzanie sesją może wymagać od użytkownika ponownego zalogowania się, jeśli sesja wygasła (tj. minął określony czas bez aktywności użytkownika). Służy również do przechowywania informacji po stronie serwera między żądaniami HTTP.

Zarządzanie sesją 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 na Linuksie zapewnia menedżer sesji X. W systemach Microsoft Windows zarządzanie sesją zapewnia podsystem menedżera sesji (smss.exe); Funkcjonalność sesji użytkownika można rozszerzyć za pomocą aplikacji innych firm, takich 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 sesją. Zarządzanie sesją często odbywa się za pomocą plików cookie .

Zarządzanie sesją serwera WWW

Protokół przesyłania hipertekstu (HTTP) jest bezstanowy. Zarządzanie sesją to technika używana przez programistę WWW do wprowadzania stanu sesji obsługi bezstanowego protokołu HTTP. Na przykład, gdy użytkownik zostanie uwierzytelniony na serwerze WWW, następne żądanie HTTP użytkownika (GET lub POST) nie powinno powodować, że serwer WWW ponownie poprosi o podanie konta i hasła użytkownika. Aby zapoznać się z omówieniem metod użytych do osiągnięcia tego celu, zobacz plik cookie HTTP i identyfikator sesji

W sytuacjach, w których wiele serwerów WWW musi współdzielić wiedzę o stanie sesji (co jest typowe w środowisku klastrowym ), informacje o sesji muszą być współużytkowane przez węzły klastra, na których działa oprogramowanie serwera WWW. Metody udostępniania stanu sesji między węzłami w klastrze obejmują: multiemisję informacji o sesji do węzłów członkowskich (zobacz JGroups , aby zapoznać się z przykładem tej techniki), udostępnianie informacji o sesji węzłowi partnerskiemu za pomocą rozproszonej pamięci współdzielonej lub wirtualizacji pamięci , udostępnianie informacji o sesji między węzłami za pomocą gniazd sieciowych, przechowywanie informacji o sesji we współdzielonym 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 informacje o sesji są uważane za przejściowe, ulotne dane, które nie są wymagane do niezaprzeczalności transakcji i nie zawierają danych podlegających audytowi zgodności (na przykład w Stanach Zjednoczonych patrz ustawa Health Insurance Portability and Accountability Act oraz Sarbanes-Oxley Ustaw jako przykłady dwóch przepisów, 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 tworzenia klastrów.

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

Zarządzanie sesją przez SMS

Tak jak HTTP jest protokołem bezstanowym , tak samo jest z SMS . Gdy SMS stał się interoperacyjny w konkurencyjnych sieciach w 1999 r., a wiadomości tekstowe zaczęły się wspinać, stając 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 sesją, ponieważ były tylko jednokierunkową komunikacją (na przykład w 2000 r. pierwsza mobilna usługa informacyjna została dostarczona za pośrednictwem wiadomości SMS w Finlandii ). Obecnie aplikacje te są określane jako komunikaty Application-to-peer (A2P), w odróżnieniu od peer-to-peer (P2P) . Rozwój interaktywnych aplikacji korporacyjnych wymagał zarządzania sesją, ale ponieważ SMS jest protokołem bezstanowym, zgodnie z definicją standardów GSM, wczesne wdrożenia były kontrolowane po stronie klienta poprzez ręczne wprowadzanie poleceń i identyfikatorów usług przez użytkowników końcowych.

Zobacz też

  1. ^ Protokół zorientowany bez sesji i protokół zorientowany na sesję
  2. ^ Wytyczne dotyczące przesyłania wiadomości między przewoźnikami (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.
  4. ^ GSM Doc 28/85 „Usługi i udogodnienia, które mają być świadczone w systemie GSM”, wersja 2, czerwiec 1985

Linki zewnętrzne