Perché i socket non possono essere utilizzati per identificare le persone anziché i cookie?

Un'altra domanda è stata posta sull'uso degli indirizzi IP per identificare i singoli client. Penso di capire perché un indirizzo IP è insufficiente. Ma che dire del socket, che ha più informazioni e, da quello che ho capito, è con stato? Non potrebbe essere potenzialmente utilizzato al posto di un cookie?

sockets cookies

— Comunità
fonte

Il socket è statefull, ma http non mantiene aperta la connessione dopo aver scaricato la pagina web. Si chiude circa 15 secondi dopo il download dell'intera pagina Web. questo è l'intero motivo per cui hai bisogno dei cookie per mantenere lo stato

— MTilsted

Un socket non è un dato. Non puoi inviarlo. La tua domanda non ha senso.

— user207421

È come chiedere perché non puoi usare i verbi invece dei nomi ...

— user541686

@EJP: ho risposto supponendo che l'OP significhi il quadruplo (source_ip, source_port, target_ip, target_port) anziché l'oggetto socket. Ma anche la tua interpretazione ha un senso.

— Jörg W Mittag,

Puoi provare a imitare il modo in cui Firebase funziona per gestire lo stato o l'identità dell'utente senza cookie o sessioni.

— JeffO,

Risposte:

Un socket identifica una connessione . I cookie vengono generalmente utilizzati per identificare un utente . Se apro due schede del browser su SE.SE, avrò due connessioni e quindi due socket. Ma voglio che le mie impostazioni persistano su entrambi. (In effetti, in genere, un browser apre più socket per una pagina per accelerare il tempo di caricamento della pagina; credo che la maggior parte dei browser abbia un valore massimo predefinito compreso tra 4 e 10 socket per pagina.)

E può accadere anche il contrario: se chiudo la scheda del browser, un altro utente sulla macchina potrebbe aprire una scheda del browser su SE.SE e ottenere lo stesso quadruplo di (source_ip, source_port, target_ip, target_port), nel qual caso , otterrà tutte le mie impostazioni.

— Jörg W Mittag
fonte

Vale la pena notare che con http2 (e http pipelining) probabilmente non avrai due socket aperti su SE. Il browser riutilizzerà lo stesso socket. Dovresti avere diversi browser in esecuzione.

— Matthew Steeples,

Un controllo locale banale indica che Chrome fa tenere una presa verde a scheda - probabilmente perché sono sandbox e non vuole lo stato di azioni tra loro - ma presa di ogni scheda sembra essere persistente e le richieste vengono probabilmente pipeline all'interno della scheda.

— Inutile

Vale anche la pena notare che non sai nemmeno cosa sta succedendo nel back-end. Molti servizi di bilanciamento del carico interromperanno la connessione di un utente e quindi apriranno la propria ai server back-end, il che significa che è possibile che più utenti condividano un singolo socket.

— Dan

@Useless IIRC SE utilizza WebSocket o polling lungo (fallback) per recuperare gli aggiornamenti (nuove domande, modifiche, ecc.) Nel caso in cui si stia testando qui. Altri siti potrebbero comportarsi diversamente: non ha molto senso mantenere un socket aperto indefinitamente su un sito statico.

— Bob

È vero, mi ci sono voluti alcuni tentativi per trovare un sito veramente statico da controllare. Per questo, Chrome apre prese multiple per scheda, e ancora non li riutilizzare tra le schede, ma fa chiudere una volta la scheda ha caricamento finito. Sono facilmente visibili però perché trascorrono così tanto tempo in TIME_WAIT.

— Inutile

I socket TCP sono progettati per essere stateful, quindi in generale vengono utilizzati per identificare le sessioni. Protocolli come SSH e ftp fanno esattamente questo.

HTTP è progettato per essere senza stato e ogni connessione è associata solo a una risorsa da scaricare. Dopo aver scaricato una risorsa, il socket TCP su cui si basa la richiesta HTTP viene chiuso. La ragione originale di ciò era la semplicità. Ma l'effetto collaterale è che i server HTTP che eseguono siti Web moderni possono gestire molti più utenti rispetto ai server basati su socket come SSH o ftp.

Quindi i socket non possono essere utilizzati perché HTTP chiuderà il socket dopo aver scaricato la pagina Web.

Naturalmente, dire che HTTP chiuderà il socket per risorsa sta semplificando eccessivamente le cose perché HTTP ha funzionalità come pipelining e connessioni persistenti che possono scaricare più risorse per socket. Ma questa è solo ottimizzazione. Dopo aver scaricato tutto, il browser chiuderà il socket dopo un certo timeout.

HTTP è stato originariamente progettato come un semplice protocollo per il download di file HTML. I vecchi browser possono anche scaricare file HTML da altri protocolli come Gopher e ftp. Pertanto, non vi era alcun motivo per rendere stateful HTTP perché i file HTML sono solo semplici file di testo.

Una volta introdotti i moduli Web e le pagine HTML possono inviare i dati ai server, le pagine Web hanno iniziato a richiedere sessioni. Pertanto, i cookie sono stati creati per reintrodurre lo stato in un protocollo stateless che viene trasmesso tramite un layer di trasferimento stateful che viene trasmesso su un layer di rete stateless. Quindi i livelli di applicazione completi sono:

Ethernet, Wifi ecc. = Apolidi
IP = apolide
TCP = stateful
HTTP = stateless
HTTP + cookies = stateful

In questi giorni abbiamo websocket che possono mantenere un singolo socket aperto dalla tua pagina web al server. Quindi con i websocket è possibile utilizzare nuovamente i socket per identificare un utente perché il websocket da solo è con stato. Ma nella maggior parte dei casi avrai ancora bisogno di un cookie per la pagina html principale che carica il javascript che avvia il websocket.

— slebetman
fonte

"I server HTTP che eseguono siti Web moderni possono gestire molti più utenti rispetto ai server basati su socket come SSH o ftp" [citazione necessaria]

— el.pescado

@ el.pescado: è semplicemente logico. Poiché i server basati su socket mantengono una connessione attiva, i server basati su socket sono limitati al numero massimo di descrittori di file che è possibile aprire (e su alcuni sistemi operativi i socket competono con il disco rigido per i descrittori di file). Se non è necessario mantenere attiva la connessione, il limite è solo la larghezza di banda. Si noti che il limite di larghezza di banda è lo stesso tempo in cui si mantiene attiva o meno una connessione. I moderni server HTTP possono gestire milioni di richieste al secondo. Se hanno bisogno di mantenere quei milioni di socket mentre leggi una pagina web il server morirebbe

— slebetman

+1 per "Così sono stati creati i cookie per reintrodurre lo stato in un protocollo stateless che viene trasmesso tramite un layer di trasferimento stateful che viene trasmesso su un layer di rete stateless". È bellissimo

— Reinstate Monica - dirkk il

Mi è piaciuta questa risposta. Taglia dritto al nocciolo della questione.

— Jim W,

I server HTTP @slebetman sono basati su socket. Lo sono tutti. Per definizione. E i cookie non rendono i server HTTP con stato. In realtà per definizione non lo sono, motivo per cui i cookie vengono trasferiti dal cliente ogni volta.

— Miles Rout,