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

Eine weitere Frage betraf die Verwendung von IP-Adressen zur Identifizierung einzelner Clients. Ich denke, ich verstehe, warum eine IP-Adresse nicht ausreicht. Aber was ist mit der Steckdose, die mehr Informationen enthält und, soweit ich das verstehe, zustandsbehaftet ist? Könnte das nicht potenziell anstelle eines Cookies verwendet werden?

sockets cookies

— Gemeinschaft
quelle

Der Socket ist in einem Status, aber http lässt die Verbindung nicht offen, nachdem Sie die Webseite heruntergeladen haben. Es wird ungefähr 15 Sekunden nach dem Herunterladen der gesamten Webseite geschlossen. Dies ist der gesamte Grund, warum Sie Cookies benötigen, um den Status

— beizubehalten

Ein Socket ist kein Datenelement. Sie können es nicht senden. Deine Frage ergibt keinen Sinn.

— user207421

Es ist, als würde man fragen, warum man keine Verben anstelle von Substantiven verwenden kann ...

— Mehrdad

@EJP: Ich antwortete unter der Annahme, dass das OP das Vierfache (source_ip, source_port, target_ip, target_port) anstelle des Socket-Objekts bedeutet. Aber auch Ihre Interpretation macht Sinn.

— Jörg W Mittag

Sie können versuchen, die Funktionsweise von Firebase nachzuahmen, um den Status oder die Benutzeridentität ohne Cookies oder Sitzung zu verwalten.

— JeffO

Antworten:

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

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

— Jörg W. Mittag
quelle

Es ist erwähnenswert, dass mit http2 (und http-Pipelining) wahrscheinlich nicht zwei Sockets für SE geöffnet sind. Ihr Browser wird denselben Socket wiederverwenden. Es müssten verschiedene Browser ausgeführt werden.

— Matthew Steeples

Eine triviale lokale Prüfung zeigt an, dass Chrome hat eine Steckdose pro Tab geöffnet halten - wahrscheinlich , weil sie Sandbox sind und es will nicht teilen Zustand zwischen ihnen - aber jeder Sockel der Registerkarte scheint hartnäckig und Anfragen werden wahrscheinlich innerhalb dieser Registerkarte pipelined.

— Nutzlos

Es ist auch erwähnenswert, dass Sie auch nicht wissen, was am hinteren Ende los ist. Viele Load Balancer beenden eine Benutzerverbindung und öffnen dann ihre eigene Verbindung zu den Back-End-Servern. Dies bedeutet, dass möglicherweise mehrere Benutzer einen einzelnen Socket gemeinsam nutzen.

— Dan

@Useless IIRC SE verwendet entweder WebSockets oder Long-Polling (Fallback), um Aktualisierungen (neue Fragen, Bearbeitungen usw.) abzurufen, falls Sie hier testen. Andere Sites verhalten sich möglicherweise anders - es macht nicht viel Sinn, einen Socket auf unbestimmte Zeit auf einer statischen Site offen zu halten.

— Bob

Es stimmt, ich habe ein paar Mal versucht, eine wirklich statische Site zu finden, um sie zu überprüfen. Dafür öffnet Chrome mehrere Steckdosen pro Tab und sie immer noch nicht zwischen den Tabs nicht wiederverwendet werden , aber tut sie schließen , sobald die Registerkarte fertig geladen hat. Sie sind jedoch gut sichtbar, da sie so lange in TIME_WAIT verbringen.

— Nutzlos

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

HTTP ist so konzipiert, dass es keinen Status hat, und jede Verbindung ist nur mit einer herunterzuladenden Ressource verknüpft. Nachdem eine Ressource heruntergeladen wurde, wird der TCP-Socket geschlossen, auf dem die HTTP-Anforderung ausgeführt wird. Der ursprüngliche Grund dafür war die Einfachheit. Der Nebeneffekt ist jedoch, dass HTTP-Server, auf denen moderne Websites ausgeführt werden, weit mehr Benutzer verarbeiten können als Socket-basierte Server wie SSH oder FTP.

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

Zu sagen, dass HTTP den Socket pro Ressource schließt, vereinfacht die Dinge natürlich zu sehr, da HTTP Funktionen wie Pipelining und dauerhafte Verbindungen aufweist, mit denen mehrere Ressourcen pro Socket heruntergeladen werden können. Das ist aber nur Optimierung. Nachdem alles heruntergeladen wurde, schließt Ihr Browser nach einer gewissen 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, werden Sitzungen benötigt. Daher wurden Cookies erstellt, um den Status eines zustandslosen Protokolls wiederherzustellen, das über eine zustandsbehaftete Übertragungsschicht übertragen wird, die über eine zustandslose Netzwerkschicht übertragen wird. Die vollständigen Anwendungsschichten sind also:

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

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

— Slebetman
quelle

"HTTP-Server, auf denen moderne Websites ausgeführt werden, können weit mehr Benutzer verarbeiten als Socket-basierte Server wie SSH oder FTP"

— el.pescado

@ el.pescado: Es ist nur logisch. Da Socket-basierte Server eine Live-Verbindung unterhalten, sind Socket-basierte Server auf die maximale Anzahl von Dateideskriptoren beschränkt, die Sie öffnen können (und auf einigen Betriebssystemen konkurrieren Sockets mit Festplatten um Dateideskriptoren). Wenn Sie die Verbindung nicht aufrecht erhalten müssen, ist Ihr Limit nur die Bandbreite. Beachten Sie, dass das Bandbreitenlimit dem Wetter entspricht, bei dem Sie eine Verbindung aufrecht erhalten oder nicht. Moderne HTTP-Server können Millionen von Anforderungen pro Sekunde verarbeiten. Wenn sie diese Millionen von Sockets aufrechterhalten müssen, während Sie eine Webseite lesen, stirbt der Server

— slebetman

+1 für "Daher wurden Cookies erstellt, um den Status eines zustandslosen Protokolls wiederherzustellen, das über eine zustandsbehaftete Übertragungsschicht übertragen wird, die über eine zustandslose Netzwerkschicht übertragen wird." Das ist wunderschön

— Reinstate Monica - Dirkk

Mir hat diese Antwort gefallen. Es geht direkt zum Kern des Problems.

— Jim W

@slebetman HTTP - Server sind socket-basierte. Sie sind alle. Per Definition. Und Cookies Sie nicht HTTP - Server Stateful machen. Dies ist per Definition jedoch nicht der Fall, weshalb die Cookies jedes Mal vom Kunden übertragen werden.

— Miles Rout