Bagaimana untuk menyelesaikan masalah perkhidmatan proksi nginx socket.io

nginx bertindak sebagai proksi untuk dua pelayan socket.io. Mod kerja socket.io sedang mengundi dan menaik taraf kepada websocket

Fenomena

Apabila meminta perkhidmatan melalui nginx, sejumlah besar 400 ralat muncul dinaik taraf kepada websocket Kadangkala ia terus melaporkan ralat. Tetapi apabila mengakses terus melalui ip+端口, ia 100% berjaya.

Analisis

sid

sid adalah kunci kepada masalah kita. Apabila pada mulanya membuat sambungan (mod pengundian mensimulasikan sambungan yang panjang), pelanggan akan memulakan permintaan sedemikian:

https://***/?eio=3&transport=polling&t=1540820717277-0

Selepas menerimanya, pelayan akan mencipta objek, mengikatnya pada sambungan dan mengembalikan sid (id sesi) untuk menandakan sesi. Apakah maksud sesi? Sesi ialah satu siri interaksi, dan interaksi ini berkaitan Dalam senario kami, apabila permintaan http seterusnya datang, saya perlu mencari sambungan panjang yang sebelum ini terikat dengan teori (belum di sini) websocket, secara teorinya). Kami tahu bahawa permintaan http adalah tanpa kewarganegaraan dan setiap permintaan adalah bebas, jadi socket.io memperkenalkan sid untuk melakukan ini. Selepas menerima permintaan, pelayan akan menjana sid. Lihat jawapannya:

Salin kod adalah seperti berikut:

{"sid":"eogal3frqlptoalp5est", "upgrades":["websocket"] ,"pinginterval":8000,"pingtimeout":10000}

Setiap permintaan selepas ini perlu membawa sid ini, dan sambungan untuk mewujudkan permintaan websocket tidak terkecuali. Oleh itu, sid adalah kunci kepada pengundian dan menaik taraf pengundian kepada soket web. Permintaan selepas ini adalah serupa dengan:

https://***/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

or

wss://***/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

Maka persoalannya, apakah yang berlaku jika sid dalam permintaan tidak dijana oleh pelayan? Pelayan tidak akan mengenalinya dan akan mengembalikan 400 kepada anda dan memberitahu anda

invalid sid

Ini adalah masalah yang kami hadapi Strategi pengimbangan beban lalai nginx adalah pengundian, jadi permintaan mungkin tidak dihasilkan pergi ke mesin dengan SID ini, kita akan menerima 400 pada masa ini Jika kita bernasib baik, ia mungkin dihantar ke mesin asal Jika kita bernasib baik, kita boleh bertahan sehingga sambungan websocket diwujudkan.

Penyelesaian

Berikut adalah dua penyelesaian

1. nginx load balancing menggunakan ip_hash, yang boleh menjamin permintaan pelanggan Semua pergi ke pelayan

2. Jangan gunakan mod pengundian, hanya gunakan soket web

Kedua-dua pilihan mempunyai kebaikan dan keburukan tersendiri. Perkara kedua yang jelas ialah penyemak imbas dan pelanggan lama yang tidak menyokong soket web tidak akan berfungsi. Jenis masalah pertama disembunyikan dengan lebih mendalam. Bayangkan apa yang akan berlaku jika anda menambah atau mengalih keluar mesin Pada masa ini, mod dasar ip_hash akan berubah, dan semua sambungan sebelumnya akan menjadi tidak sah operasi yang kerap. (Terutama apabila produk dalam peringkat pembangunan), pengembangan dan pengecutan lossy ini kemungkinan besar tidak boleh diterima.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah perkhidmatan proksi nginx socket.io. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!