it-swarm.com.de

Warum können Sockets nicht zur Identifizierung von Personen anstelle von Cookies verwendet werden?

Ein weiteres Frage wurde bezüglich der Verwendung von IP-Adressen zur Identifizierung einzelner Clients gestellt. Ich glaube zu verstehen, warum eine IP-Adresse nicht ausreicht. Aber was ist mit der Steckdose, die mehr Informationen enthält und nach meinem Verständnis zustandsbehaftet ist? Könnte das nicht möglicherweise anstelle eines Cookies verwendet werden?

17
user266715

Ein Socket identifiziert ein Verbindung. Cookies werden normalerweise verwendet, um einen Benutzer zu identifizieren. Wenn ich zwei Browser-Registerkarten für SE.SE öffne, habe ich zwei Verbindungen und damit zwei Sockets. Ich möchte jedoch, dass meine Einstellungen für beide beibehalten werden. (Tatsächlich öffnet ein Browser normalerweise mehrere Sockets für eine Seite, um die Ladezeit der Seite zu beschleunigen. Ich glaube, die meisten Browser haben einen Standardmaximalwert zwischen 4 und 10 Steckdosen pro Seite.)

Und das Gegenteil kann auch passieren: Wenn ich meine Browser-Registerkarte schließe, öffnet ein anderer Benutzer auf dem Computer möglicherweise eine Browser-Registerkarte für SE.SE und erhält in diesem Fall das gleiche Vierfache von (source_ip, source_port, target_ip, target_port) wird er alle meine Einstellungen bekommen.

64
Jörg W Mittag

TCP-Sockets sind so konzipiert, dass sie statusbehaftet sind, sodass sie im Allgemeinen zur Identifizierung von Sitzungen verwendet werden. Protokolle wie SSH und FTP machen genau das.

HTTP ist zustandslos und jede Verbindung ist nur einer herunterzuladenden Ressource zugeordnet. Nach dem Herunterladen einer Ressource wird der Socket TCP, auf dem die HTTP-Anforderung ausgeführt wird, geschlossen. Der ursprüngliche Grund dafür war die Einfachheit. Der Nebeneffekt ist jedoch, dass HTTP-Server, auf denen moderne Websites ausgeführt werden, weitaus mehr verarbeiten können Benutzer als Socket-basierte Server wie SSH oder FTP.

Sockets können also nicht verwendet werden, da HTTP den Socket nach dem Herunterladen der Webseite schließt.

Zu sagen, dass HTTP den Socket pro Ressource schließt, ist natürlich zu einfach, da HTTP über Funktionen wie Pipelining und dauerhafte Verbindungen verfügt, mit denen mehrere Ressourcen pro Socket heruntergeladen werden können. Das ist aber nur Optimierung. Nachdem alles heruntergeladen wurde, schließt Ihr Browser nach einiger Zeit den Socket.

HTTP wurde ursprünglich als einfaches Protokoll zum Herunterladen von HTML-Dateien entwickelt. Alte Browser können auch HTML-Dateien von anderen Protokollen wie Gopher und FTP herunterladen. Daher gab es keinen Grund, HTTP statusbehaftet zu machen, da HTML-Dateien nur einfache Textdateien sind.

Sobald Webformulare eingeführt wurden und HTML-Seiten Daten an die Server-Webseiten zurücksenden können, wurden Sitzungen benötigt. Daher wurden Cookies erstellt, um den Status wieder in ein zustandsloses Protokoll einzuführen, das über eine zustandsbehaftete Übertragungsschicht übertragen wird, die über eine zustandslose Netzwerkschicht übertragen wird. Die vollständigen Anwendungsschichten sind also:

  • Ethernet, Wifi etc. = zustandslos
  • IP = zustandslos
  • TCP = Stateful
  • HTTP = zustandslos
  • HTTP + Cookies = Stateful

Heutzutage haben wir Websockets, die einen einzelnen offenen Socket von Ihrer Webseite zum Server halten können. Mit Websockets können Sie also wieder Sockets verwenden, um einen Benutzer zu identifizieren, da der Websocket selbst statusbehaftet ist. In den meisten Fällen benötigen Sie jedoch weiterhin ein Cookie für die HTML-Hauptseite, auf der das Javascript geladen wird, mit dem der Websocket gestartet wird.

20
slebetman