Sitzung (Informatik) – Wikipedia

before-content-x4

Insbesondere in der Informatik und Netzwerktechnik, u.a Sitzung ist ein temporärer und interaktiver Informationsaustausch zwischen zwei oder mehreren kommunizierenden Geräten oder zwischen einem Computer und einem Benutzer (siehe Login-Sitzung). Eine Sitzung wird zu einem bestimmten Zeitpunkt aufgebaut und dann zu einem späteren Zeitpunkt „abgerissen“ – zu Ende gebracht. Eine aufgebaute Kommunikationssitzung kann mehr als eine Nachricht in jede Richtung umfassen. Eine Sitzung ist typischerweise zustandsbehaftet, was bedeutet, dass mindestens eine der kommunizierenden Parteien aktuelle Zustandsinformationen halten und Informationen über den Sitzungsverlauf speichern muss, um kommunizieren zu können, im Gegensatz zur zustandslosen Kommunikation, bei der die Kommunikation aus unabhängigen Anfragen mit Antworten besteht.

Eine aufgebaute Sitzung ist die Grundvoraussetzung für eine verbindungsorientierte Kommunikation. Eine Sitzung ist auch der grundlegende Schritt, um in verbindungslosen Kommunikationsmodi zu übertragen. Eine unidirektionale Übertragung definiert jedoch keine Sitzung.[1]

Kommunikation Transport können als Teil von Protokollen und Diensten auf der Anwendungsschicht, auf der Sitzungsschicht oder auf der Transportschicht im OSI-Modell implementiert werden.

  • Beispiele für Anwendungsschichten:
    • HTTP-Sitzungen, die es ermöglichen, Informationen einzelnen Besuchern zuzuordnen
    • Eine Telnet-Remote-Login-Sitzung
  • Beispiel für eine Sitzungsebene:
  • Beispiel für eine Transportschicht:

Bei Transportprotokollen, die keine formale Sitzungsschicht implementieren (z. B. UDP) oder bei denen Sitzungen auf der Anwendungsschicht im Allgemeinen sehr kurzlebig sind (z. B. HTTP), werden Sitzungen von einem übergeordneten Programm mit einer definierten Methode aufrechterhalten in den ausgetauschten Daten. Zum Beispiel kann ein HTTP-Austausch zwischen einem Browser und einem entfernten Host ein HTTP-Cookie enthalten, das den Status identifiziert, wie beispielsweise eine eindeutige Sitzungs-ID, Informationen über die Präferenzen des Benutzers oder die Autorisierungsebene.

HTTP/1.0 sollte nur eine einzige Anfrage und Antwort während einer Web-/HTTP-Sitzung erlauben. Die Protokollversion HTTP/1.1 verbesserte dies, indem sie das Common Gateway Interface (CGI) vervollständigte, die Verwaltung der Websitzung vereinfachte und HTTP-Cookies und Datei-Uploads unterstützte.

Die meisten Client-Server-Sitzungen werden von der Transportschicht verwaltet – eine einzelne Verbindung für eine einzelne Sitzung. Jede Transaktionsphase einer Web-/HTTP-Sitzung erstellt jedoch eine separate Verbindung. Um die Sitzungskontinuität zwischen den Phasen aufrechtzuerhalten, ist eine Sitzungs-ID erforderlich. Die Sitzungs-ID ist eingebettet in die oder

Links dynamischer Webseiten, damit diese an das CGI zurückgesendet werden. CGI verwendet dann die Sitzungs-ID, um die Sitzungskontinuität zwischen den Transaktionsphasen sicherzustellen. Ein Vorteil einer Verbindung pro Phase besteht darin, dass sie bei Verbindungen mit geringer Bandbreite (Modem) gut funktioniert.

Softwareimplementierung[edit]

TCP-Sitzungen werden typischerweise in Software implementiert, die untergeordnete Prozesse und/oder Multithreading verwendet, wobei ein neuer Prozess oder Thread erstellt wird, wenn der Computer eine Sitzung aufbaut oder einer Sitzung beitritt. HTTP-Sitzungen werden normalerweise nicht mit einem Thread pro Sitzung implementiert, sondern mithilfe einer Datenbank mit Informationen über den Status jeder Sitzung. Der Vorteil bei mehreren Prozessen oder Threads ist die entspannte Komplexität der Software, da jeder Thread eine Instanz mit eigener Historie und gekapselten Variablen ist. Der Nachteil ist ein großer Overhead in Bezug auf Systemressourcen und dass die Sitzung möglicherweise unterbrochen wird, wenn das System neu gestartet wird.

Wenn ein Client eine Verbindung zu einem beliebigen Server in einem Servercluster herstellen kann, tritt ein besonderes Problem beim Aufrechterhalten der Konsistenz auf, wenn die Server den Sitzungsstatus beibehalten müssen. Der Client muss entweder für die Dauer der Sitzung an denselben Server geleitet werden oder die Server müssen serverseitige Sitzungsinformationen über ein gemeinsam genutztes Dateisystem oder eine Datenbank übertragen. Andernfalls kann sich der Client erneut mit einem anderen Server als dem, mit dem er die Sitzung gestartet hat, verbinden, was zu Problemen führt, wenn der neue Server keinen Zugriff auf den gespeicherten Zustand des alten Servers hat.

Serverseitige Websitzungen[edit]

Serverseitige Sitzungen sind praktisch und effizient, können jedoch in Verbindung mit Lastausgleichs-/Hochverfügbarkeitssystemen schwierig zu handhaben sein und sind in einigen eingebetteten Systemen ohne Speicher überhaupt nicht verwendbar. Das Lastenausgleichsproblem kann durch die Verwendung von gemeinsam genutztem Speicher oder durch die Anwendung von erzwungenem Peering zwischen jedem Client und einem einzelnen Server im Cluster gelöst werden, obwohl dies die Systemeffizienz und Lastverteilung beeinträchtigen kann.

Ein Verfahren zur Verwendung serverseitiger Sitzungen in Systemen ohne Massenspeicherung besteht darin, einen Teil des RAM für die Speicherung von Sitzungsdaten zu reservieren. Diese Methode gilt für Server mit einer begrenzten Anzahl von Clients (z. B. Router oder Access Points mit seltenem oder unzulässigem Zugriff auf mehr als einen Client gleichzeitig).

Clientseitige Websitzungen[edit]

Clientseitige Sitzungen verwenden Cookies und kryptografische Techniken, um den Status aufrechtzuerhalten, ohne so viele Daten auf dem Server zu speichern. Bei der Darstellung einer dynamischen Webseite sendet der Server die aktuellen Zustandsdaten in Form eines Cookies an den Client (Webbrowser). Der Client speichert das Cookie im Arbeitsspeicher oder auf der Festplatte. Bei jeder nachfolgenden Anforderung sendet der Client das Cookie zurück an den Server, und der Server verwendet die Daten, um sich den Status der Anwendung für diesen speziellen Client zu “erinnern” und eine entsprechende Antwort zu generieren.

Dieser Mechanismus kann in einigen Kontexten gut funktionieren; auf dem Client gespeicherte Daten sind jedoch anfällig für Manipulationen durch den Benutzer oder durch Software, die Zugriff auf den Client-Computer hat. Um clientseitige Sitzungen zu nutzen, bei denen Vertraulichkeit und Integrität erforderlich sind, muss Folgendes gewährleistet sein:

  1. Vertraulichkeit: Nichts außer dem Server sollte in der Lage sein, Sitzungsdaten zu interpretieren.
  2. Datenintegrität: Nichts außer dem Server sollte Sitzungsdaten (versehentlich oder böswillig) manipulieren.
  3. Authentizität: Nichts außer dem Server sollte in der Lage sein, gültige Sitzungen zu initiieren.

Um dies zu erreichen, muss der Server die Sitzungsdaten verschlüsseln, bevor er sie an den Client sendet, und die Modifikation solcher Informationen durch eine andere Partei sollte durch kryptografische Mittel verhindert werden.

Den Status bei jeder Anfrage hin und her zu übertragen ist nur sinnvoll, wenn die Größe des Cookies klein ist. Im Wesentlichen tauschen clientseitige Sitzungen den Festplattenspeicher des Servers gegen die zusätzliche Bandbreite, die jede Webanforderung benötigt. Darüber hinaus begrenzen Webbrowser die Anzahl und Größe der Cookies, die von einer Website gespeichert werden können. Um die Effizienz zu verbessern und mehr Sitzungsdaten zu ermöglichen, kann der Server die Daten vor dem Erstellen des Cookies komprimieren und sie später dekomprimieren, wenn das Cookie vom Client zurückgegeben wird.

HTTP-Sitzungstoken[edit]

Ein Sitzungstoken ist eine eindeutige Kennung, die generiert und von einem Server an einen Client gesendet wird, um die aktuelle Interaktionssitzung zu identifizieren. Der Client speichert und sendet das Token normalerweise als HTTP-Cookie und/oder sendet es als Parameter in GET- oder POST-Abfragen. Der Grund für die Verwendung von Sitzungstoken besteht darin, dass der Client nur die Kennung verarbeiten muss – alle Sitzungsdaten werden auf dem Server (normalerweise in einer Datenbank, auf die der Client keinen direkten Zugriff hat) gespeichert, die mit dieser Kennung verknüpft ist. Beispiele für die Namen, die einige Programmiersprachen bei der Benennung ihres HTTP-Cookies verwenden, sind JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI) und ASPSESSIONID (ASP).

Sitzungsverwaltung[edit]

In der Mensch-Computer-Interaktion, Sitzungsverwaltung ist der Prozess, die Aktivität eines Benutzers über Interaktionssitzungen mit dem Computersystem hinweg zu verfolgen.

Zu den typischen Sitzungsverwaltungsaufgaben in einer Desktop-Umgebung gehört das Nachverfolgen, welche Anwendungen geöffnet sind und welche Dokumente jede Anwendung geöffnet hat, sodass derselbe Status wiederhergestellt werden kann, wenn sich der Benutzer abmeldet und später anmeldet. Bei einer Website kann die Sitzungsverwaltung dazu führen, dass der Benutzer sich erneut anmelden muss, wenn die Sitzung abgelaufen ist (dh ein bestimmtes Zeitlimit ohne Benutzeraktivität verstrichen ist). Es wird auch verwendet, um serverseitig Informationen zwischen HTTP-Anfragen zu speichern.

Desktop-Sitzungsverwaltung[edit]

Ein Desktop-Sitzungsmanager ist ein Programm, das Desktop-Sitzungen speichern und wiederherstellen kann. Eine Desktop-Sitzung umfasst alle derzeit ausgeführten Fenster und deren aktuelle Inhalte. Die Sitzungsverwaltung auf Linux-basierten Systemen wird vom X-Sitzungsmanager bereitgestellt. Auf Microsoft Windows-Systemen wird die Sitzungsverwaltung vom Session Manager Subsystem (smss.exe) bereitgestellt; Die Benutzersitzungsfunktionalität kann durch Anwendungen von Drittanbietern wie Twinsplay erweitert werden.

Verwaltung von Browsersitzungen[edit]

Besonders nützlich ist die Sitzungsverwaltung in einem Webbrowser, in dem ein Benutzer alle geöffneten Seiten und Einstellungen speichern und zu einem späteren Zeitpunkt oder auf einem anderen Computer wiederherstellen kann (siehe Datenübertragbarkeit).

Um die Wiederherstellung nach einem System- oder Anwendungsabsturz zu erleichtern, können Seiten und Einstellungen auch bei der nächsten Ausführung wiederhergestellt werden. Google Chrome, Mozilla Firefox, Internet Explorer, OmniWeb und Opera sind Beispiele für Webbrowser, die die Sitzungsverwaltung unterstützen. Die Sitzungsverwaltung wird häufig durch die Anwendung von Cookies verwaltet.

Verwaltung von Webserver-Sitzungen[edit]

Hypertext Transfer Protocol (HTTP) ist zustandslos: Ein Client-Computer, auf dem ein Webbrowser ausgeführt wird, muss bei jeder neuen HTTP GET- oder POST-Anfrage eine neue TCP-Netzwerkverbindung (Transmission Control Protocol) zum Webserver aufbauen. Der Webserver kann sich daher nicht länger als eine einzelne HTTP GET- oder POST-Operation auf eine aufgebaute TCP-Netzwerkverbindung verlassen. Sitzungsverwaltung ist die Technik, die vom Webentwickler verwendet wird, um den zustandslosen HTTP-Protokollunterstützungssitzungsstatus zu erstellen. Sobald ein Benutzer beispielsweise beim Webserver authentifiziert wurde, sollte die nächste HTTP-Anfrage des Benutzers (GET oder POST) nicht dazu führen, dass der Webserver erneut nach dem Benutzerkonto und dem Kennwort fragt. Eine Erläuterung der hierfür verwendeten Methoden finden Sie unter HTTP-Cookie und Sitzungs-ID

In Situationen, in denen mehrere Webserver das Wissen über den Sitzungsstatus teilen müssen (wie es in einer Clusterumgebung typisch ist), müssen Sitzungsinformationen zwischen den Clusterknoten geteilt werden, auf denen Webserversoftware ausgeführt wird. Zu den Methoden zur gemeinsamen Nutzung des Sitzungsstatus zwischen Knoten in einem Cluster gehören: Multicasting-Sitzungsinformationen an Mitgliedsknoten (ein Beispiel für diese Technik finden Sie unter JGroups), gemeinsame Nutzung von Sitzungsinformationen mit einem Partnerknoten mithilfe von verteiltem gemeinsam genutztem Speicher oder Speichervirtualisierung, gemeinsame Nutzung von Sitzungsinformationen zwischen Knoten mithilfe von Netzwerk-Sockets, Speichern von Sitzungsinformationen in einem gemeinsam genutzten Dateisystem wie einem verteilten Dateisystem oder einem globalen Dateisystem oder Speichern der Sitzungsinformationen außerhalb des Clusters in einer Datenbank.

Wenn Sitzungsinformationen als vorübergehende, flüchtige Daten angesehen werden, die nicht für die Nichtabstreitbarkeit von Transaktionen erforderlich sind und keine Daten enthalten, die einer Compliance-Prüfung unterliegen (in den USA beispielsweise siehe Health Insurance Portability and Accountability Act und Sarbanes-Oxley Befolgen Sie Beispiele für zwei Gesetze, die eine Compliance-Prüfung erfordern), dann kann jede Methode zum Speichern von Sitzungsinformationen verwendet werden. Wenn Sitzungsinformationen jedoch der Audit-Compliance unterliegen, sollte die für Sitzungsspeicher, Replikation und Clustering verwendete Methode in Betracht gezogen werden.

In einer serviceorientierten Architektur können mit XML-Nachrichten (Extensible Markup Language) erstellte Simple Object Access Protocol- oder SOAP-Nachrichten von Verbraucheranwendungen verwendet werden, um Webserver zum Erstellen von Sitzungen zu veranlassen.

Sitzungsverwaltung über SMS[edit]

So wie HTTP ein zustandsloses Protokoll ist, ist SMS auch. Als SMS 1999 über konkurrierende Netze hinweg interoperabel wurde,[2] und Textnachrichten begannen ihren Aufstieg zu einer allgegenwärtigen globalen Kommunikationsform,[3] verschiedene Unternehmen interessierten sich für die kommerzielle Nutzung des SMS-Kanals. Anfängliche Dienste erforderten kein Sitzungsmanagement, da es sich nur um unidirektionale Kommunikation handelte (zum Beispiel wurde im Jahr 2000 der erste mobile Nachrichtendienst in Finnland per SMS bereitgestellt). Heutzutage werden diese Anwendungen als Application-to-Peer (A2P) Messaging bezeichnet, im Unterschied zum Peer-to-Peer (P2P) Messaging. Die Entwicklung interaktiver Unternehmensanwendungen erforderte ein Sitzungsmanagement, aber da SMS ein zustandsloses Protokoll gemäß den GSM-Standards ist,[4] Frühe Implementierungen wurden clientseitig gesteuert, indem die Endbenutzer Befehle und Dienstkennungen manuell eingeben mussten.

Siehe auch[edit]

Verweise[edit]

Externe Links[edit]

after-content-x4