Un altro domanda è stato chiesto in merito all'uso di indirizzi IP per identificare i singoli client. Penso di capire perché un indirizzo IP è insufficiente. Ma per quanto riguarda il socket, che ha più informazioni e, da quello che ho capito, è stato? Non potrebbe essere potenzialmente utilizzato al posto di un cookie?
Un socket identifica una connessione . I cookie vengono solitamente utilizzati per identificare un utente . Se apro due schede del browser in SE.SE, avrò due connessioni e quindi due socket. Ma voglio che le mie impostazioni persistano su entrambi. (In realtà, in genere, un browser apre più socket per una pagina per accelerare il caricamento della pagina, credo che la maggior parte dei browser abbia un valore massimo predefinito tra 4 e 10 prese per pagina.)
E può anche accadere il contrario: se chiudo la scheda del mio browser, un altro utente sulla macchina potrebbe aprire una scheda del browser su SE.SE, e potrebbe ottenere lo stesso quadruplo di (source_ip, source_port, target_ip, target_port), in tal caso, otterrà tutte le mie impostazioni.
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 stateless e ogni connessione è associata solo a una risorsa da scaricare. Dopo aver scaricato una risorsa, viene chiuso il socket TCP su cui viaggia la richiesta HTTP. La ragione originale per questo 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.
Ovviamente, dire che HTTP chiuderà il socket per risorsa sta semplificando eccessivamente le cose perché HTTP ha caratteristiche come pipelining e connessioni persistenti che possono scaricare più risorse per socket. Ma questa è solo ottimizzazione. Dopo che tutto è stato scaricato, il tuo browser chiuderà il socket dopo un certo timeout.
HTTP è stato originariamente progettato come un semplice protocollo per scaricare file HTML. I vecchi browser possono anche scaricare file HTML da altri protocolli come Gopher e ftp. Come tale, non c'era motivo di rendere lo stato HTTP perché i file HTML sono solo semplici file di testo.
Una volta che i moduli Web sono stati introdotti e le pagine HTML possono inviare dati al server, le pagine Web hanno iniziato a richiedere sessioni. Così sono stati creati i cookie per reintrodurre lo stato di un protocollo stateless che viene trasmesso attraverso un layer di trasferimento stato che viene trasmesso su un livello di rete stateless. Quindi i livelli completi dell'applicazione sono:
In questi giorni abbiamo web socket 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 è di per sé 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.