Mengapa soket tidak dapat digunakan untuk mengidentifikasi individu, bukan cookie?

Pertanyaan lain diajukan mengenai penggunaan alamat IP untuk mengidentifikasi masing-masing klien. Saya rasa saya mengerti mengapa alamat IP tidak cukup. Tetapi bagaimana dengan soket, yang memiliki lebih banyak informasi dan, dari apa yang saya pahami, adalah benar? Tidak bisakah itu berpotensi digunakan sebagai pengganti cookie?

sockets cookies

— Komunitas
sumber

Soketnya statefull, tetapi http tidak membuat koneksi tetap terbuka setelah Anda mengunduh halaman web. Ini menutup sekitar 15 detik setelah seluruh halaman web diunduh. ini adalah alasan utama Anda membutuhkan cookie untuk menjaga status

— MTilsted

Soket bukan sepotong data. Anda tidak dapat mengirimnya tentang. Pertanyaan Anda tidak masuk akal.

— user207421

Ini seperti bertanya mengapa Anda tidak dapat menggunakan kata kerja, bukan kata benda ...

— user541686

@ EJP: Saya menjawab dengan asumsi bahwa OP berarti (source_ip, source_port, target_ip, target_port) empat kali lipat bukan objek soket. Tetapi interpretasi Anda juga masuk akal.

— Jörg W Mittag

Anda bisa mencoba dan meniru cara firebase bekerja untuk mengelola negara atau identitas pengguna tanpa cookie atau sesi.

— JeffO

Jawaban:

Soket mengidentifikasi koneksi . Cookie biasanya digunakan untuk mengidentifikasi pengguna . Jika saya membuka dua tab browser untuk SE.SE, saya akan memiliki dua koneksi dan dengan demikian dua soket. Tapi saya ingin pengaturan saya bertahan di keduanya. (Bahkan, biasanya, browser membuka beberapa soket untuk satu halaman untuk mempercepat waktu pemuatan halaman; Saya yakin sebagian besar browser memiliki nilai maksimum default antara 4 dan 10 soket per halaman.)

Dan yang sebaliknya dapat terjadi juga: jika saya menutup tab browser saya, pengguna lain pada mesin dapat membuka tab browser untuk SE.SE, dan mungkin mendapatkan quadruple yang sama (source_ip, source_port, target_ip, target_port), dalam hal ini , dia akan mendapatkan semua pengaturan saya.

— Jörg W Mittag
sumber

Perlu dicatat bahwa dengan http2 (dan http pipelining) Anda mungkin tidak akan memiliki dua soket terbuka untuk SE. Browser Anda akan menggunakan kembali soket yang sama. Anda harus menjalankan browser yang berbeda.

— Matthew Steeples

Sebuah cek lokal sepele menunjukkan bahwa Chrome tidak menyimpan satu soket terbuka per tab - mungkin karena mereka Sandbox dan tidak ingin negara berbagi antara mereka - tapi socket setiap tab ini tampaknya menjadi gigih dan permintaan mungkin pipelined dalam tab tersebut.

— berguna

Perlu juga dicatat bahwa Anda juga tidak tahu apa yang terjadi di bagian belakang. Banyak penyeimbang beban akan memutuskan koneksi pengguna dan kemudian membuka sendiri ke server back end yang berarti bahwa Anda mungkin memiliki beberapa pengguna berbagi soket tunggal.

— Dan

@Useless IIRC SE memang menggunakan WebSockets atau polling panjang (fallback) untuk mengambil pembaruan (pertanyaan baru, suntingan, dll.) Jika Anda menguji di sini. Situs lain mungkin berperilaku berbeda - tidak ada gunanya menjaga soket terbuka tanpa batas di situs statis.

— Bob

Benar, saya perlu beberapa kali mencoba untuk menemukan situs yang benar-benar statis untuk diperiksa. Untuk itu, Chrome membuka beberapa soket per tab, dan masih tidak menggunakan kembali mereka di antara tab, tapi tidak dekat mereka sekali tab memiliki pemuatan selesai. Mereka mudah terlihat karena mereka menghabiskan begitu lama di TIME_WAIT.

— berguna

Soket TCP dirancang agar stateful sehingga secara umum mereka digunakan untuk mengidentifikasi sesi. Protokol seperti SSH dan ftp melakukan hal ini.

HTTP dirancang untuk menjadi tanpa kewarganegaraan dan setiap koneksi hanya dikaitkan dengan sumber daya yang akan diunduh. Setelah sumber daya diunduh, soket TCP yang digunakan permintaan HTTP ditutup. Alasan asli untuk ini adalah kesederhanaan. Tetapi efek sampingnya adalah server HTTP yang menjalankan situs web modern dapat menangani pengguna yang jauh lebih banyak daripada server berbasis soket seperti SSH atau ftp.

Jadi soket tidak dapat digunakan karena HTTP akan menutup soket setelah mengunduh halaman web.

Tentu saja, mengatakan HTTP akan menutup soket per sumber daya adalah menyederhanakan hal-hal karena HTTP memiliki fitur seperti pipelining dan koneksi persisten yang dapat mengunduh banyak sumber daya per soket. Tapi itu hanya optimasi. Setelah semuanya diunduh, browser Anda akan menutup soket setelah batas waktu tertentu.

HTTP pada awalnya dirancang sebagai protokol sederhana untuk mengunduh file HTML. Browser lama juga dapat mengunduh file HTML dari protokol lain seperti Gopher dan ftp. Karena itu, tidak ada alasan untuk membuat HTTP stateful karena file HTML hanyalah file teks sederhana.

Setelah formulir web diperkenalkan dan halaman HTML dapat mengirim data kembali ke halaman web server mulai perlu sesi. Dengan demikian cookie dibuat untuk memperkenalkan kembali status ke protokol stateless yang ditransmisikan melalui lapisan transfer stateful yang ditransmisikan melalui lapisan jaringan stateless. Jadi lapisan aplikasi lengkap adalah:

Ethernet, Wifi dll = stateless
IP = stateless
TCP = stateful
HTTP = stateless
HTTP + cookies = stateful

Saat ini kami memiliki soket web yang dapat menyimpan satu soket terbuka dari halaman web Anda ke server. Jadi dengan websockets Anda dapat menggunakan soket lagi untuk mengidentifikasi pengguna karena websocket itu sendiri stateful. Tetapi dalam kebanyakan kasus Anda masih akan membutuhkan cookie untuk halaman html utama yang memuat javascript yang memulai websocket.

— Slebetman
sumber

"Server HTTP yang menjalankan situs web modern dapat menangani pengguna yang jauh lebih banyak daripada server berbasis soket seperti SSH atau ftp" [rujukan?]

— el.pescado

@ el.pescado: Masuk akal. Karena server berbasis soket menjaga koneksi langsung, maka server berbasis soket terbatas pada jumlah maksimum deskriptor file yang dapat Anda buka (dan pada beberapa OS, soket bersaing dengan hard disk untuk deskriptor file). Jika Anda tidak perlu menjaga koneksi tetap hidup maka batas Anda hanyalah bandwidth. Perhatikan bahwa batas bandwidth adalah cuaca yang sama dengan Anda menjaga koneksi tetap hidup atau tidak. Server HTTP modern dapat menangani jutaan permintaan per detik. Jika mereka perlu mempertahankan jutaan soket saat Anda membaca halaman web server akan mati

— slebetman

+1 untuk "Maka cookie dibuat untuk memperkenalkan kembali status ke protokol stateless yang ditransmisikan melalui lapisan transfer stateful yang ditransmisikan melalui lapisan jaringan stateless". Itu indah

— mengembalikan Monica - dirkk

Saya menyukai jawaban ini. Ini memotong langsung ke inti masalah.

— Jim W

@slebetman HTTP server yang socket berbasis. Semuanya. Menurut definisi. Dan cookie tidak membuat server HTTP stateful. Bahkan menurut definisi mereka tidak, itulah sebabnya cookie ditransfer oleh klien setiap saat.

— Miles Rout