Socket.io: एडब्ल्यूएस ईसी 2 ईएलबी के पीछे हमेशा त्रुटि अप्रत्याशित प्रतिक्रिया कोड प्रिंट करता है: 400

इसके अलावा, मैंने बोवर के माध्यम से स्थापित किया है यदि यह मायने रखता है:

"सॉकेट.आईओ-क्लाइंट": "~ 1.1.0",

क्या आपके सर्वर पर चिपचिपा कनेक्शन है?

मुझे लगता है कि आप लोचदार बीनस्टॉक का उपयोग नहीं कर रहे हैं (निर्देश वहां बहुत आसान होंगे)।

EC2-> नेटवर्क और सुरक्षा-> लोड बैलेंसर्स पर जाएं

अपना लोड बैलेंसर चुनें और श्रोताओं पर जाएँ। सुनिश्चित करें कि लोड बैलेंसर प्रोटोकॉल और इंस्टेंस प्रोटोकॉल दोनों HTTP और HTTPS के बजाय पोर्ट 80 के लिए टीसीपी और पोर्ट 443 के लिए एसएसएल पर सेट हैं।

ओह आदमी। यह ठोस सलाह है जो मैंने कहीं और नहीं देखी। मैं AM . में कोशिश करूँगा
और वापस रिपोर्ट करें। आपको धन्यवाद!

बुध, अक्टूबर 29, 2014, शाम 7:48 अपराह्न वादिम कज़ाकोव नोटिफिकेशन @github.com
लिखा था:

मुझे लगता है कि आप लोचदार बीनस्टॉक का उपयोग नहीं कर रहे हैं (निर्देश वहां होंगे
बहुत आसान हो)।

EC2-> नेटवर्क और सुरक्षा-> लोड बैलेंसर्स पर जाएं

अपना लोड बैलेंसर चुनें और श्रोताओं पर जाएँ। सुनिश्चित करें कि दोनों लोड
बैलेंसर प्रोटोकॉल और इंस्टेंस प्रोटोकॉल पोर्ट 80 के लिए टीसीपी पर सेट हैं और
HTTP और HTTPS के बजाय पोर्ट 443 के लिए एसएसएल।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Automattic/socket.io/issues/1846#issuecomment -61038664
.

तो शायद मुझसे गलती हुई है, लेकिन हमारी साइट HTTPS (हमारे SSL प्रमाणपत्र के साथ) पर चल रही है। लाइन के नीचे बहुत सी चीजों को तोड़ने के लिए उन्हें बदलना। मैं यह सुनिश्चित करने के लिए अपने ऐप में एक्स-फॉरवर्डेड-प्रोटो की जांच कर रहा था कि अनुरोध HTTPS था और यदि नहीं, तो इसे रीडायरेक्ट करने के लिए मजबूर किया गया। जाहिर तौर पर एसएसएल/टीसीपी के साथ कोई एक्स-फॉरवर्डेड-प्रोटो हेडर नहीं है और एक्सप्रेस req.secure को गलत के रूप में रिपोर्ट कर रहा है (भले ही मैंने https टाइप किया हो)।

सुझाव?

निश्चित नहीं है, सॉकेट टीसीपी/एसएसएल प्रोटोकॉल का उपयोग करते हैं न कि एचटीटीपी, इसलिए वेब सॉकेट को काम करने के लिए आपको इसे टीसीपी/एसएसएल में बदलना होगा। जहां तक ​​आपके बाकी ऐप को ठीक करने का सवाल है, मुझे नहीं पता।

सहायता के लिए धन्यवाद। मुझे एक नया वातावरण बनाना होगा और थोड़ा गड़बड़ करना होगा। मशीन में बहुत सारे कॉग हैं!

क्या वेबसोकेट को अपने बंदरगाहों पर चलाना संभव है? यदि हां, तो क्या आप कुछ दस्तावेज लिंक कर सकते हैं? (मुझे पूरा यकीन है कि ऐसा नहीं है लेकिन मैं गलत हो सकता हूं)

वे जो भी पोर्ट आप चाहते हैं उस पर काम कर सकते हैं, बस निर्दिष्ट करें कि आप पोर्ट को कब कनेक्ट करते हैं:

io('https://myserver:123');

मैं इलास्टिकबीनस्टॉक का उपयोग कर रहा हूं और उसी मुद्दे का सामना कर रहा हूं, मेरे पास एसएसएल स्थापित नहीं है लेकिन नियमित http के माध्यम से जुड़ा हुआ है।

नमस्ते,
मुझे एक ही समस्या है, हालांकि मैं सॉकजेएस का उपयोग कर रहा हूं।
मेरा एप्लिकेशन जावा स्प्रिंग 4 एप्लिकेशन है, विकास मशीन पर काम करता है और
एडब्ल्यूएस पर एक ही त्रुटि हो रही है।
ऐसा लगता है कि अपग्रेड हेडर किसी के द्वारा छोड़ा जा रहा है, मैं इसे क्लाइंट पर देख सकता हूं।

अभी तक कोई समाधान ढूंढ सकता है ...

मैं एक ही नाव में हूं और एक एडब्ल्यूएस इंजीनियर के साथ लाइव चैट पर हूं और हम दोनों स्टम्प्ड हैं। मैंने पुष्टि की है कि ईएलबी को एचटीटीपी/एचटीटीपीएस से टीसीपी (या एसएसएल (सिक्योर टीसीपी)) में बदलने की जरूरत है, लेकिन मुझे अभी भी लगातार 400 त्रुटियां मिलती हैं। लोचदार बीनस्टॉक लोड संतुलित क्लस्टर में जाने तक यह समस्या कभी नहीं हुई।

कृपया किसी भी ऐप पर टिप्पणी करने का प्रयास करें। मिडलवेयर सामान (हेडर/कॉर्स संबंधित) का उपयोग करें, यदि कोई हो, या ऐप.गेट ("/", सुनिश्चित नहीं है कि कौन सा मेरे लिए काम करता है, लेकिन कृपया अपने परिणाम पोस्ट करें।

अद्यतन: मैंने पुष्टि की है कि यह ईएलबी है, चाहे वह HTTP या HTTPS ट्रैफ़िक के लिए कॉन्फ़िगर किया गया हो, socket.io विफल रहता है। जब मैं सीधे ईसी 2 में से किसी एक पर जाता हूं तो सब कुछ बढ़िया काम करता है।

संलग्न वह है जो मैं ईएलबी से गुजरते समय देख रहा हूं।

मुझे लगता है कि लोडबैलेंसर के सामने रूट 53 इंस्टेंस जोड़कर मेरी समस्या हल हो गई है।
अब मेरे पास एडब्ल्यूएस पर्यावरण के तहत सुरक्षित कनेक्शन के साथ एक कार्यशील वेबसोकेट है।

रूट 53 जोड़ने का प्रयास करें, अगर यह आपकी समस्या का समाधान नहीं कर रहा है, तो मुझे अपना कॉन्फ़िगरेशन साझा करने में खुशी होगी।

@ yoav200 को लगता है कि आप अपना पूरा कॉन्फिगरेशन साझा कर सकते हैं कि किन चीजों ने आपके लिए काम किया? यानी, ईबीएस सुरक्षा + प्रोटोकॉल (http/tcp) पर पोर्ट, आपके लिए आवश्यक कोई भी .ebextensions, आदि। मैंने अपग्रेड हेडर रखने और उन्हें नोड पर भेजने के लिए अपने nginx कॉन्फिग को हैक करने के लिए कई अलग-अलग चीजों की कोशिश की, लेकिन मेरे लिए कुछ भी काम नहीं किया। . एफडब्ल्यूआईडब्ल्यू - इसके लिए एक विकी पेज वास्तव में, वास्तव में मददगार होगा। काम करने वाली केवल एक चीज मेरे ईसी 2 इंस्टेंस पर सीधे जा रही थी।

मैंने एक रूट 53 इंस्टेंस स्थापित किया है जो मेरे डोमेन का प्रबंधन करता है।
मैंने एक होस्टेड ज़ोन को एक रिकॉर्ड के साथ कॉन्फ़िगर किया है जो मेरे डोमेन को सीधे लोड बैलेंसर पर इंगित करता है।

लोड बैलेंसर को मेरे टॉमकैट इंस्टेंस के अनुरोध को अग्रेषित करने के लिए कॉन्फ़िगर किया गया है, जैसा कि यहां दिखाया गया है:

ईएलबी के लिए सुरक्षा समूह काफी मानक है:

क्या आप nginx का उपयोग कर रहे हैं? क्या आपको कुछ विशेष विन्यास-वार करना था?

मैं यह काम करने के बहुत करीब हूं, पिछले दो दिनों में एडब्ल्यूएस सपोर्ट इंजीनियर के साथ लगभग 8 घंटे बिताए। मिक्स से nginx को चीरना था, लेकिन मैं बहुत करीब हूं, http पर ईएलबी के माध्यम से सॉकेट ठीक काम कर रहे हैं, कल मुझे लगता है कि मैं ईएलबी-स्तर के बजाय https सामान सर्वर-साइड को संभाल सकता हूं।

मैं अपने निष्कर्षों के साथ वापस रिपोर्ट करूंगा।

मैं nginx का उपयोग नहीं करता, मैं Amazon पर सब कुछ प्रबंधित करता हूं, मैंने अपने डोमेन को Amazon पर भी स्थानांतरित कर दिया है,
हालाँकि मैंने अपने एप्लिकेशन को एक होस्टेड क्लाउड वातावरण से माइग्रेट किया है जो उनके उदाहरणों के लिए AWS का उपयोग करता है लेकिन nginx के साथ लोड को प्रबंधित करता है और मुझे वहां कोई समस्या नहीं थी।

जब उनसे पूछा गया कि यह उनके लिए कैसे काम कर रहा है तो उनकी प्रतिक्रिया थी:

हम अमेज़ॅन इलास्टिक लोड बैलेंसर का उपयोग नहीं करते हैं, हम अपनी खुद की एनजीआईएनएक्स लोड बैलेंसिंग परत का उपयोग करते हैं।
एक समाधान यह हो सकता है कि ELB के बजाय Nginx या HAProxy सर्वर का उपयोग किया जाए और घटक की उच्च उपलब्धता सुनिश्चित करने के लिए haproxy/nginx के 1 नोड के साथ एक ऑटोस्केलिंग समूह का उपयोग किया जाए।

हाँ, मुझे बताया गया था कि HAProxy एक और विकल्प था, लेकिन मुझे पूरा यकीन है कि मैं इसे दिन के अंत तक निम्नलिखित सेवाओं के साथ काम करूंगा:

• लोचदार बीनस्टॉक
• ईएलबी
• EC2 ऑटोस्केलिंग समूह (EB द्वारा बनाया गया)
• आरडीएस
• इलास्टी कैश

नोड ऐप वर्तमान में इन सभी सेवाओं के साथ काम कर रहा है, लेकिन जैसा कि मैंने कहा, केवल HTTP पर, इसलिए उत्पादन के लिए तैयार होने के लिए बहुत कुछ नहीं बचा है। मैं बाद में अपने निष्कर्षों/कॉन्फ़िगरेशन के साथ रिपोर्ट करूंगा।

@niczak क्या आप यह साझा करने में सक्षम होंगे कि आपके पास यह कैसे काम कर रहा है?

अभी मैं ElastiCache's Redis का उपयोग करने के साथ-साथ EC2 पर अपने नोड इंस्टेंस पर Socket.IO से कनेक्ट करने का प्रयास कर रहा हूं।

मैंने सार्वजनिक आईपी पते के साथ प्रतिक्रिया के साथ जनता के लिए ईसी 2 उदाहरण खोला ताकि मैं आसानी से सॉकेट से जुड़ सकूं (http://coding-ceo.ghost.io/how-to-run-socket-io-behind -एल्ब-ऑन-एडब्ल्यूएस/)। मेरे ईएलबी पर मैं चिपचिपा सत्रों का उपयोग कर रहा हूं (उम्मीद है कि यह जुड़ा रहेगा), हालांकि मेरा सॉकेट अभी भी कनेक्ट नहीं होगा और मुझे प्यारा असफल देता है: हैंडशेक प्रतिक्रिया प्राप्त करने से पहले कनेक्शन बंद हो गया।

मतदान हालांकि ठीक काम करता है, लेकिन सॉकेट और पूरे पथ को ठीक काम करने की कोशिश कर रहा है।

यहां एक उपयोग के मामले को देखना अच्छा लगेगा ताकि मैं अपने उदाहरण को ठीक से कॉन्फ़िगर कर सकूं (भले ही यह केवल http और https के बजाय HTTP पर हो) क्योंकि मैं काफी समय से खुद को सिर तोड़ रहा हूं।

आपकी मदद के लिए बहुत बहुत धन्यवाद!

@पेट्रोगाड

हे पीट!

मेरे ELB श्रोता जितने सरल हो सकते हैं (चित्र देखें) और डिफ़ॉल्ट रूप से EC2 पोर्ट 80 पर iptables का उपयोग करके 8080 पर अग्रेषित किया जाता है। इसके साथ ही, मैं अपने सर्वर को एचटीटीपीएस पर हिट कर सकता हूं, फिर मेरा नोड ऐप 8080 पर सुनता है और एसएसएल प्रमाणपत्र को ही प्रस्तुत करता है।

सेर्ट्स को संभालने के लिए नोड कोड इस प्रकार है:

        files = ["COMODOHigh-AssuranceSecureServerCA.crt", "AddTrustExternalCARoot.crt"];
        ca = (function() {
            var _i, _len, _results;
            _results = [];
            for (_i = 0, _len = files.length; _i < _len; _i++) {
                file = files[_i];
                _results.push(fs.readFileSync('/etc/ssl/tcerts/' + file));
            }
            return _results;
            })();

        httpsOptions = {
            ca: ca,
            key: fs.readFileSync('/etc/ssl/tcerts/multidomain.key', 'utf8'),
            cert: fs.readFileSync('/etc/ssl/tcerts/14432575.crt', 'utf8')
        };

        this.serverPort = 8080;
        var httpsServer = https.createServer(httpsOptions, apiInstance);
        httpsServer.listen(this.serverPort);
        startSockets(httpsServer);

वेब सॉकेट के काम करने के लिए (लंबे मतदान में वापस आए बिना) I _had_ क्रॉस-ज़ोन लोड बैलेंसिंग को अक्षम करने के लिए। दुर्भाग्य से एडब्ल्यूएस अपने ईएलबी के माध्यम से वेब सॉकेट का समर्थन करने का दावा नहीं करता है, इसलिए इस प्रकार के कॉन्फ़िगरेशन "हैक्स" आवश्यक हैं। उम्मीद है कि यह आपको उठने और दौड़ने के लिए पर्याप्त होगा!

धन्यवाद @niczak !

सब कुछ पूरी तरह से काम कर रहा है, HTTP ट्रैफिक चल रहा था जो चीजों को फेंक रहा था। काम करने वाले कई उदाहरणों में रेडिस भी मिला; आखिरी चीज सिर्फ रीक्लस्टर पर काम कर रही है और एक टीसीपी रूट को किसी विशेष कार्यकर्ता के साथ रहने की इजाजत दे रही है।

क्या आपको इसमें बहुत सफलता मिली है? मैं एक्सप्रेस का उपयोग कर रहा हूं, इसलिए चिपचिपा-सत्र बहुत अच्छा काम नहीं कर रहा है। क्या आपको इसके साथ कोई भाग्य मिला है?

एक बार फिर धन्यवाद और उम्मीद है कि एक बार यह सब पूरा हो जाने के बाद एक समान वस्तु के साथ संघर्ष कर रहे अन्य लोगों के लिए एक अच्छा ब्लॉग पोस्ट मिल सकता है।

धन्यवाद @niczak !!

मुझे आखिरकार मेरा काम भी मिल गया। हालाँकि, कॉन्फ़िगर करने के अतिरिक्त
1) टीसीपी प्रोटोकॉल का उपयोग करने के लिए बैलेंसर लोड करें
2) क्रॉस-ज़ोन लोड बैलेंसिंग को अक्षम करने के लिए लोड बैलेंसर

मुझे भी सेट करना है
3) सॉफ़्टवेयर कॉन्फ़िगरेशन अनुभाग में प्रॉक्सी सर्वर "कोई नहीं" होना चाहिए।

AWS पर सॉकेट्स के लिए @aidanbon और @petrogad , huzzah बहुत अच्छी खबर है! :+1:

बहुत - बहुत धन्यवाद! इसने मेरी समस्या को लोचदार बीनस्टॉक के साथ हल किया। यह nginx प्रॉक्सी को हटाने के लिए समझ में आता है

मेरी मूल पोस्ट से एएन अपडेट:

मैंने अपने एचटीटीपीएस को एसएसएल (443 ---> मेरा कस्टम पोर्ट) में बदल दिया है और एचटीटीपी छोड़ दिया है (80 ---> मेरा कस्टम पोर्ट)।

मेरे पास कोड है जो एक्सप्रेस !req.secure && X-Forwarded-Proto !=== https के साथ जांच कर रहा था जो आपको पोर्ट 80 पर आने पर HTTPS पर रीडायरेक्ट करता है ...

हालाँकि

एसएसएल में बदलने से एक्स-फॉरवर्डेड-प्रोटो वापस अपरिभाषित हो जाता है ... इस कनेक्शन को तोड़ देता है। (req.secure भी ऐसा लगता है कि इसे पदावनत किया जा सकता है)

तो अब:

if (req.get('X-Forwarded-Proto') === 'http') {
            res.redirect('https://' + req.get('Host') + req.url);
        }

ऐसा लगता है कि बहुत अच्छा काम करता है, और मुझे अब कंसोल में 400 त्रुटि नहीं मिलती है।

हलो - मुझे यह नोड, एनजीआईएनएक्स, एसएसएल, और लोचदार बीनस्टॉक पर एक ईएलबी का उपयोग करके निम्न कार्य कर रहा है:

प्रॉक्सी वेबसोकेट को शामिल करने के लिए nginx कॉन्फ़िगरेशन स्क्रिप्ट को संशोधित करने के लिए .ebextensions में एक कंटेनर कमांड बनाएं:

container_commands:
    00proxy:
        command: sed -i 's/proxy_http_version.*/proxy_http_version\ 1.1\;\n\ \ \ \ \ \ \ \ proxy_set_header\ \ \ \ \ \ \ \ Upgrade\ \ \ \ \ \ \ \ \ \$http_upgrade\;\n\ \ \ \ \ \ \ \ proxy_set_header\ \ \ \ \ \ \ \ Connection\ \ \ \ \ \ \"upgrade\"\;/g' /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf

लोचदार बीनस्टॉक वेब कंसोल का उपयोग करके लोड बैलेंसर पर अपना एसएसएल प्रमाणपत्र स्थापित करें।

फिर ईसी 2 वेब कंसोल पर जाएं, और लोड बैलेंसर को एसएसएल 443 -> टीसीपी 80 पर सुनने के लिए बदलें। यह काम नहीं कर रहा था जब मैंने इसे ईबी वेब कंसोल में बदल दिया, मुझे इसे सीधे ईसी 2 में करना पड़ा।

वह सब कुछ काम करना चाहिए। मुझे कोई रीडायरेक्ट नहीं करना पड़ा और मैं एनजीआईएनएक्स को भी काम करने में कामयाब रहा।

@ChrisEdson क्या इस समाधान का उपयोग करने के लिए पैकेज में शामिल करने के लिए कुछ और है?
मैंने इसे आजमाया लेकिन त्रुटियों के कारण परिनियोजन विफल रहा। लॉग फोलोफ़िंग लाइन दिखाता है:

/etc/init.conf: Unable to load configuration: No such file or directory

क्या आप अपना कोड पोस्ट कर सकते हैं?

शुक्र, 4 सितंबर, 2015 को दोपहर 1:13 बजे, ट्रेयोन नोटिफिकेशन @github.com ने लिखा:

@ChrisEdson क्या इस समाधान का उपयोग करने के लिए पैकेज में शामिल करने के लिए कुछ और है?
मैंने इसे आजमाया लेकिन त्रुटियों के कारण परिनियोजन विफल रहा। लॉग फोलोफ़िंग लाइन दिखाता है:

/etc/init.conf: Unable to load configuration: No such file or directory

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/socketio/socket.io/issues/1846#issuecomment -137718880

ऐप कोड एक अत्यंत बुनियादी सॉकेट है।
केवल एक चीज जो मैंने जोड़ी है वह है .ebextensions में .config फ़ाइल, जिसमें मैंने आपके द्वारा पहले उद्धृत कोड स्निपेट की प्रतिलिपि बनाई थी।
तो मेरे पास पोस्ट करने के लिए बहुत कुछ नहीं है :)

कोई चिंता नहीं, कोड या लॉग के बिना डीबग करना मुश्किल है। क्या आप लॉग पोस्ट कर सकते हैं? शायद यहां पर टिके रहना उचित नहीं है, शायद उन्हें पेस्ट बिन में डाल दें।

शुक्र, 4 सितंबर, 2015 को अपराह्न 3:26 बजे, ट्रेयोन नोटिफिकेशन @github.com ने लिखा:

ऐप कोड एक अत्यंत बुनियादी सॉकेट है।
केवल एक चीज जो मैंने जोड़ी है वह है .ebextensions में .config फ़ाइल, जिसमें मैंने आपके द्वारा पहले उद्धृत कोड स्निपेट की प्रतिलिपि बनाई थी।

तो मेरे पास पोस्ट करने के लिए बहुत कुछ नहीं है :)

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/socketio/socket.io/issues/1846#issuecomment -137749890

हम, मैंने मैन्युअल पैकेजिंग के बजाय ग्रंट के माध्यम से अपना कोड प्रकाशित किया और यह एक आकर्षण की तरह काम करता है। स्वचालितकरण अनिवार्य होना चाहिए;)

सुन के अच्छा लगा!

मंगलवार, 8 सितंबर, 2015 को अपराह्न 3:14 बजे, ट्रेयोन नोटिफिकेशन @github.com ने लिखा:

हम, मैंने मैन्युअल पैकेजिंग के बजाय ग्रंट के माध्यम से अपना कोड प्रकाशित किया और यह एक आकर्षण की तरह काम करता है। स्वचालितकरण अनिवार्य होना चाहिए;)

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/socketio/socket.io/issues/1846#issuecomment -138572724

मेरा दिन बचाओ!

हमने इस बुनियादी मुद्दे को भी देखा। मूल रूप से, क्योंकि सॉकेटियो वेबसोकेट कनेक्शन स्थापित करने के लिए दो अनुरोध भेजता है, यदि वे कॉल उदाहरणों में फ़ेडरेटेड हो जाते हैं, तो सत्र आईडी की पहचान नहीं की जाती है और हैंडशेक विफल हो जाता है, जिससे सॉकेटियो लंबे मतदान में वापस आ जाता है। यह सच है कि आप ws या wss का उपयोग कर रहे हैं या नहीं; यह मानता है कि आपने लेयर -4 (टीसीपी) पर लोड बैलेंसिंग सेट की है, क्योंकि मुझे वेबसोकेट के साथ काम करने के लिए लेयर -7 (एचटीटीपी) लोड बैलेंसिंग नहीं मिल सका।

फिक्स स्टिकी सत्रों को सक्षम करने के लिए होगा, ताकि एक बार कॉल के एक उदाहरण पर जाने के बाद, लोड बैलेंसर उन अनुरोधों को उसी इंस्टेंस पर भेजना जारी रखे; हालाँकि, यदि आप AWS के ELB का उपयोग कर रहे हैं, तो वे आपको लेयर-4 लोड संतुलन के लिए स्टिकी सत्रों का उपयोग करने की अनुमति नहीं देते हैं।

हमने जो किया वह सॉकेटियो के बजाय कच्चे वेबसोकेट का उपयोग कर रहा था, क्योंकि तब कोई सत्र डेटा नहीं है जिसे कॉल के दौरान जारी रखने की आवश्यकता होती है (केवल एक कॉल, हैंडशेक होता है, और यह काम करता है)।

एडब्ल्यूएस के हिस्से पर एक फिक्स स्टिकी सत्रों को परत -4 लोड संतुलन के लिए किसी तरह से उपयोग करने की अनुमति देना होगा।

सॉकेटियो के हिस्से पर एक फिक्स इसे बनाना होगा ताकि वेबस्केट हैंडशेक को पूर्व सत्र आईडी के संदर्भ की आवश्यकता न हो (मुझे इसके आसपास के उद्देश्य या जीवन चक्र की जानकारी नहीं है; मुझे लगता है कि यह लंबे मतदान में मदद करने के लिए और अधिक के लिए मौजूद है। कनेक्शन समाप्त होने की स्थिति में जल्दी से फिर से कनेक्ट करें; यदि क्लाइंट निर्धारित करता है कि एक कनेक्शन मर गया है तो यह एक नया सत्र उत्पन्न कर सकता है और सफलतापूर्वक पुन: कनेक्ट हो सकता है, बजाय इसके कि बैकएंड हैंडशेक को मना कर दे क्योंकि यह माना जाता है कि एक कनेक्शन पहले से मौजूद है)।

सभी उदाहरणों में सत्र स्थिति को बनाए रखने के लिए रेडिस का उपयोग करने के लिए एक संभावित सुधार होगा। मैंने इसका परीक्षण नहीं किया है।

एक वैकल्पिक हल, यदि आपका लोड इसकी अनुमति देता है, तो प्रति उपलब्धता क्षेत्र में केवल एक नोड इंस्टेंस सुनिश्चित करना और क्रॉस-ज़ोन लोड संतुलन को अक्षम करना है। इस तरह, इस समस्या से बचने के लिए, सभी कॉल एकल नोड पर डिफ़ॉल्ट हो जाएंगी।

@aidanbon मुझे Proxy server to be "none" in the Software Configuration section ?

मैं बस एमयूपी परिनियोजन के साथ एक उबंटू सर्वर और उल्का जेएस का उपयोग कर रहा हूं .. क्या आप मुझे एक लिंक प्राप्त कर सकते हैं ??

चियर्स

@sahanDissanayake मुझे अपना प्रॉक्सी सर्वर कॉन्फ़िगरेशन विकल्प इसके माध्यम से मिला:

1. रुचि के वातावरण में "कॉन्फ़िगरेशन" पर क्लिक करें
2. कॉन्फ़िगरेशन पृष्ठ के भीतर से "सॉफ़्टवेयर कॉन्फ़िगरेशन" पर क्लिक करें
3. "प्रॉक्सी सर्वर" ड्रॉप-डाउन जैसा कि मेरे पिछले स्क्रीनशॉट में दिखाया गया है।

नोट: मेरे पर्यावरण का प्रावधान लगभग एक साल पहले किया गया था। सुनिश्चित नहीं है कि एडब्ल्यूएस पैनल नए वातावरण के लिए अद्यतन किया गया है। हालाँकि, मैं आज भी इस ड्रॉप-डाउन को अपने परिवेश में देख सकता हूँ।

@aidanbon मैं ec2 के अलावा किसी अन्य सेवाओं का उपयोग नहीं करता .. इसलिए आपकी सेटिंग्स मेरे लिए प्रासंगिक नहीं हैं? या क्या मुझे इस पॉक्सी सर्वर का उपयोग शुरू करने की आवश्यकता है?

तो मेरे पास जो समस्या है, वह यह है कि मेरा वेब ऐप वेबसोकेट पोर्ट 8080 में काम करता है, लेकिन पोर्ट 80 में नहीं।

यह है मुद्दा

@lostcolony सारांश के लिए धन्यवाद। मैं उसी निष्कर्ष पर पहुंचा हूं। क्या आपने इस ब्लॉग पोस्ट को पढ़ा है: https://medium.com/@Philmod/load -balancing-websockets-on-ec2-1da94584a5e9#.hd2ectz8t? वह अनिवार्य रूप से कह रहा है कि कोई HAProxy इंस्टेंस के माध्यम से लेयर -4 (TCP) को पास कर सकता है, जो तब PROXY हेडर को बंद कर देता है और स्टिकी सेशन का उपयोग करके ट्रैफ़िक को सही इंस्टेंस पर रूट करता है। हालांकि, यह मेरे लिए स्पष्ट नहीं है कि कैसे दो HAProxy अपनी "बैकएंड" सर्वर सूची को कॉन्फ़िगर करते हैं और यह कहां चलता है और वास्तविक सॉकेट.आईओ सर्वर कहां चलता है। क्या आप इसका कोई मतलब निकाल सकते हैं?

संपादित करें: मुझे लगता है कि मैंने अभी क्लिक किया है। वह सूची जानता है क्योंकि उसके पास सर्वरों का एक ज्ञात सेट है और उसे ऑटो-स्केलिंग की परवाह नहीं है ...

सर्वर सूची को प्रत्येक HAproxy बॉक्स पर कॉन्फ़िगर किया जाएगा। मुझे यकीन नहीं है कि कैसे
ऑटो स्केलिंग ec2 उदाहरणों के साथ उस काम को करने के लिए, जब तक कि आपने कुछ लिखा न हो
जब कोई नया सर्वर आया तो उस सूची को अद्यतन करने के लिए अतिरिक्त आधारभूत संरचना
ऑनलाइन। Socket.io वे अपने वेब ऐप के समान सर्वर पर चल रहे हैं, इसलिए
कनेक्शन एल्ब के माध्यम से आते हैं, एक HAproxy उदाहरण के लिए संघबद्ध होते हैं,
HAproxy उदाहरण यह सुनिश्चित करते हैं कि IP कनेक्शन हमेशा उसी पर जाएं
web/app सर्वर, जहां पर socket.io की स्थापना की गई थी।
13 जनवरी 2016 को पूर्वाह्न 2:50 बजे, "फेलिक्स श्लिटर" नोटिफिकेशन @github.com ने लिखा:

@lostcolony https://github.com/lostcolony सारांश के लिए धन्यवाद। मैं
इसी निष्कर्ष पर पहुंचे हैं। क्या आपने यह ब्लॉग पोस्ट पढ़ा है:
https://medium.com/@Philmod/load -balancing-websockets-on-ec2-1da94584a5e9#.hd2ectz8t?
वह अनिवार्य रूप से कह रहा है कि कोई परत -4 (टीसीपी) से होकर a . तक जा सकता है
HAProxy उदाहरण, जो तब PROXY हेडर को हटाता है और रूट करता है
स्टिकी सेशन का उपयोग करके सही उदाहरण के लिए ट्रैफ़िक। हालांकि, यह नहीं है
मेरे लिए स्पष्ट है कि कैसे दो HAProxy को उनकी "बैकएंड" सर्वर सूची मिलती है
कॉन्फ़िगर किया गया है और यह कहां चलता है और वास्तविक सॉकेट.आईओ सर्वर कहां चलता है।
क्या आप इसका कोई मतलब निकाल सकते हैं?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/socketio/socket.io/issues/1846#issuecomment -171208211
.

@lostcolony ठीक है, मैंने देखा कि HAProxy का उपयोग करके अमेज़ॅन पर ऑटो-स्केलिंग के संबंध में एक दिलचस्प परियोजना थी - संदर्भ के लिए कम से कम उपयोगी: https://github.com/markcaudill/haproxy-autoscale। जो मुझे नहीं मिलता है वह यह है कि HAProxy के सामने ELB का उपयोग क्यों करें? केवल एक HAProxy इंस्टेंस होना चाहिए, अन्यथा, आप कैसे गारंटी देंगे कि ELB सही HAProxy इंस्टेंस पर ट्रैफ़िक भेजता है? जब तक वे (HAProxy इंस्टेंसेस) किसी भी तरह ElastiCache या Redis या उन पंक्तियों के साथ कुछ का उपयोग करके एक आम चिपचिपा तालिका साझा नहीं करते? ... मुझे पता है कि हम विषय से दूर जा रहे हैं।

यदि आपके पास IP पर आधारित कनेक्शन को रूट करने के लिए HAProxy कॉन्फ़िगर किया गया है
गारंटी दे सकता है कि यह उसी उदाहरण पर समाप्त होगा। अर्थात्, यदि HAProxies
सभी का एक ही नियम था कि आईपी एबीसीडी को उदाहरण के लिए निर्देशित किया जाता है,
फिर इस बात की परवाह किए बिना कि ईएलबी किस HAProxy से टकराएगा, यह उसी पर समाप्त होगा
जगह। आपके द्वारा भेजे गए उस लिंक में यही हो रहा है, वे संतुलन बना रहे हैं
स्रोत के माध्यम से, जिसका अर्थ है कि HAProxy उदाहरण IP को हैश करता है और इसका उपयोग करता है
निर्धारित करें कि यह किस उदाहरण पर जाता है। एकाधिक HAProxy, बशर्ते वे सभी
एक ही उदाहरण के बारे में जानें, इस प्रकार एक स्थान से यातायात भेजेंगे
वही बैकएंड उदाहरण।

बुध, 13 जनवरी 2016 अपराह्न 1:19 बजे, फेलिक्स श्लिटर नोटिफिकेशन @github.com
लिखा था:

@lostcolony https://github.com/lostcolony ठीक है, मैंने देखा कि वहाँ एक था
अमेज़ॅन पर ऑटो-स्केलिंग के संबंध में दिलचस्प परियोजना, HAProxy का उपयोग कर -
संदर्भ के लिए कम से कम उपयोगी:
https://github.com/markcaudill/haproxy-autoscale। मुझे जो नहीं मिलता है वह क्यों है
HAProxy के सामने ELB का उपयोग करें? केवल एक HAProxy उदाहरण होना चाहिए,
अन्यथा, आप कैसे गारंटी देंगे कि ईएलबी यातायात को दाईं ओर भेजता है
हैप्रोक्सी उदाहरण? जब तक वे (HAProxy उदाहरण) एक साझा साझा नहीं करते
चिपचिपा तालिका किसी तरह इलास्टी कैश या रेडिस या उनके साथ कुछ का उपयोग कर रही है
लाइनें? ... मुझे पता है कि हम विषय से दूर जा रहे हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/socketio/socket.io/issues/1846#issuecomment -171386260
.

@lostcolony मैं समझता हूं कि हैश किसी दिए गए आईपी के लिए निश्चित रूप से व्युत्पन्न होता है, हालांकि, "हैश -> इंस्टेंस" का मानचित्रण होना चाहिए। आपके मामले में आप कह रहे हैं कि एक नियम है जो कह रहा है कि "एबीसीडी को उदाहरण के लिए निर्देशित किया गया है", लेकिन क्या आप नहीं चाहेंगे कि HAProxy यह निर्धारित करे कि उपलब्ध सर्वरों की सूची को देखते हुए कहां पुनर्निर्देशित किया जाए? आखिरकार, "एबीसीडी" केवल कुछ क्लाइंट का आईपी है और सामने से ज्ञात नहीं है।

हैश को एक उदाहरण में मैप करने का नियम सभी HAProxy पर समान है
उदाहरण। अर्थात्, ABCD का परिणाम समान हैश में होगा, चाहे कोई भी हो
HAProxy उदाहरण यह हिट करता है, और वह हैश उसी सर्वर पर मैप करेगा, नहीं
उपयोग में आने वाले HAProxy उदाहरण से कोई फर्क नहीं पड़ता, बशर्ते कि प्रत्येक HAProxy इसके बारे में जानता हो
वही उदाहरण (और संभवतः उसी क्रम में/समान नाम)।
वास्तविक आईपी को सामने से जानने की जरूरत नहीं है, क्योंकि वे सारहीन हैं।
कोई भी आईपी उसी सर्वर पर हैश करेगा, चाहे वह HAProxy से कुछ भी हो
के माध्यम से।

पूरी तरह से नकली उदाहरण के लिए (HAProxy कुछ ऐसा उपयोग करता है जो ऐसा नहीं है
उम्मीद के मुताबिक, मुझे यकीन है), कल्पना कीजिए कि हमारे पास तीन सर्वर हैं, जो कॉन्फ़िगर किए गए हैं
सर्वर0, सर्वर1 और सर्व 2 के क्रम में (वास्तविक विवरण कोई मायने नहीं रखता,
बस एक स्पष्ट आदेश है, निहित ठीक है)। हर हैप्रोक्सी
इंस्टेंस में समान सर्वर हैं, उसी क्रम में। उनके पास भी वही है
आने वाले आईपी पते से निपटने के तरीके के बारे में नियम। इस तुच्छ उदाहरण के लिए,
यह पते के सभी चार भागों को पूर्णांक के रूप में जोड़ता है (आसानी से एक्स्टेंसिबल to
IPv6 का समर्थन करें, सभी को हेक्स के रूप में आधार 10 में जोड़ें), और 3 से विभाजित करें, लें
शेष। तो आईपी 123.12.61.24 = (123+12+61+24)% 3, या 1. तो यह रूट हो जाता है
सर्वर1 के लिए। तो कोई फर्क नहीं पड़ता कि HAProxy उदाहरण किसमें आता है, कि
कनेक्शन सर्वर1 को भेजा जाएगा।

अब, यदि सर्वर1 ऑफ़लाइन हो जाता है, तो एल्गोरिथम सभी HAProxy में बदल जाता है
उदाहरण, सभी भागों को जोड़ने के लिए, मापांक 2.

और यह आम तौर पर काम करता है-जब तक- आपको नेटस्प्लिट नहीं मिलता है (या कॉन्फ़िगर करें
एक अलग सर्वर सूची रखने के लिए HAProxy उदाहरण)। जहां एक HAProxy देखता है
3 उदाहरण, और दूसरा 2 देखता है। यदि ऐसा होता है, तो आपको गारंटी नहीं दी जा सकती
उसी बैकएंड तक पहुंचने के लिए। और वास्तव में, यह एक समस्या साबित हो सकती है। लेकिन
यही समाधान लिंक में वर्णित किया जा रहा है।

बुध, 13 जनवरी 2016 अपराह्न 3:51 बजे, फेलिक्स श्लिटर नोटिफिकेशन @github.com
लिखा था:

@lostcolony https://github.com/lostcolony मैं समझता हूं कि हैश है
किसी दिए गए आईपी के लिए निश्चित रूप से व्युत्पन्न, हालांकि, एक मानचित्रण होना चाहिए
"हैश -> उदाहरण" का। आपके मामले में आप कह रहे हैं कि एक नियम है कि
यह कहते हुए कि "एबीसीडी एक उदाहरण के लिए निर्देशित है", लेकिन क्या आप नहीं चाहेंगे
HAProxy खुद को यह निर्धारित करने के लिए कि कहां रीडायरेक्ट करना है, उपलब्ध की एक सूची दी गई है
सर्वर? आखिरकार, "एबीसीडी" केवल कुछ क्लाइंट का आईपी है और ज्ञात नहीं है
सामने।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/socketio/socket.io/issues/1846#issuecomment -171428465
.

मैंने पाया कि लोचदार बीनस्टॉक पर भले ही मैंने वेब इंटरफेस के साथ टीसीपी और एसएसएल का उपयोग करने के लिए लोड बैलेंसर सेट किया था, जब मैंने सीधे लोड बैलेंसर कॉन्फ़िगरेशन की जांच की तो यह अभी भी सुरक्षित श्रोता के लिए HTTPS का उपयोग कर रहा था। तो आपको शायद ईसी 2> लोड बैलेंसर्स सेक्शन में जांच करनी चाहिए कि बंदरगाहों को सेटअप किया जाना चाहिए:

एक बार इसे सॉर्ट करने के बाद निम्नलिखित को .ebextensions में जोड़ें और सभी मेरे लिए अच्छा काम करते हैं :)

container_commands:
  01_nginx_static:
    command: |
      sed -i '/\s*proxy_set_header\s*Connection/c \
              proxy_set_header Upgrade $http_upgrade;\
              proxy_set_header Connection "upgrade";\
          ' /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf

यह केवल 100% काम करेगा जब आपके पास केवल एक उदाहरण होगा, क्योंकि चिपचिपा सत्र समर्थन टीसीपी पर काम नहीं करता है।

@lostcolony , @williamcoates पोस्ट ने अभी मुझे स्पष्टीकरण के लिए धन्यवाद देने के लिए याद दिलाया। विश्वास नहीं कर सकता मैं ऐसा करना भूल गया। आपका स्पष्टीकरण काफी मददगार था, इसलिए समय निकालने के लिए धन्यवाद।

https://github.com/indutny/sticky-session/issues/47#issuecomment -227499752

तो मुझे भी यही समस्या थी और यह पता चला कि मैंने HTTPS का उपयोग करने के लिए ECB की स्थापना की थी।
मैंने एचटीटीपीएस को एसएसएल में बदल दिया है और मुझे अब संदेश नहीं मिलता है।
इसलिए, केवल HTTP/HTTPS का उपयोग न करें लेकिन TCP/SSL

अगस्त 2016 तक आप "क्लासिक" ईएलबी के बजाय अमेज़ॅन के एप्लिकेशन लोड बैलेंसर (एएलबी) का उपयोग कर सकते हैं। HTTP 80 और HTTPS 443 पर श्रोताओं के साथ मेरे लिए "बॉक्स से बाहर" काम किया।

@ trans1t प्यारे आदमी, जानकारी के लिए धन्यवाद! मुझे उसकी जाँच करनी होगी।

@niczak - मैंने सॉकेट ट्रैफिक चिपचिपाहट के लिए

@aidanbon यह शानदार जानकारी है, साझा करने के लिए बहुत बहुत धन्यवाद!

किसी ऐसे व्यक्ति के लिए जिसे अभी भी AWS एप्लिकेशन लोड बैलेंसर में कोई समस्या है, अपनी सुरक्षा नीति को अपडेट करने का प्रयास करें, मैं उसी समस्या में भाग गया, भले ही यह किसी अन्य वेबसाइट के लिए सटीक सेटअप में पूरी तरह से ठीक काम कर रहा था, लेकिन देखा कि सुरक्षा नीति लगभग 1 वर्ष पीछे थी। ऐसा लगता है कि इसे एक नए में अपडेट करने से समस्या हल हो गई है।

@michaelmitchell क्या आपने कुछ भी बदला है, या बिना संशोधन के इसे अपडेट किया है?

मैंने अपने आवेदन में कुछ भी नहीं बदला, मैंने जो एकमात्र अतिरिक्त कदम उठाया, वह था एएलबी पर एचटीटीपीएस श्रोता को हटाना और फिर से जोड़ना क्योंकि नई नीति में बदलाव के बाद काम नहीं हुआ।

हालांकि मुझे पता चला कि सुरक्षा नीति को अपडेट करने के बाद भी त्रुटि देखना मेरे ब्राउज़र सत्र की पुरानी सुरक्षा नीति पर होने की संभावना थी, इसलिए मुझे यकीन नहीं है कि श्रोता को जोड़ने/फिर से जोड़ने की वास्तव में आवश्यकता थी, लेकिन गुप्त खोलने से यह ठीक काम करता था और बाद में मेरे सभी क्रोम सत्रों को बंद करना और इसे फिर से खोलना ठीक काम करता है और इसे तब से नहीं देखा है।

जानकर अच्छा लगा, धन्यवाद!

ले वेन। 31 मार्च 2017 12:02, माइकल मिशेल नोटिफिकेशन @github.com a
इक्रिट:

मैंने अपने आवेदन में कुछ भी नहीं बदला, केवल एक अतिरिक्त कदम जो मैंने किया
टेक को बाद में एएलबी पर एचटीटीपीएस श्रोता को हटाना और फिर से जोड़ना था
नई नीति में परिवर्तन करना काम नहीं आया।

हालाँकि मैंने सीखा कि सुरक्षा अद्यतन करने के बाद भी त्रुटि देखना
नीति की संभावना थी कि मेरा ब्राउज़र सत्र पुरानी सुरक्षा नीति पर आधारित था
इसलिए मुझे यकीन नहीं है कि श्रोता को जोड़ना/फिर से जोड़ना वास्तव में जरूरी था, लेकिन
गुप्त खोलना यह ठीक काम करता है और मेरे सभी क्रोम सत्र बंद करने के बाद
और इसे फिर से खोलना ठीक काम करता है और इसे तब से नहीं देखा है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/socketio/socket.io/issues/1846#issuecomment-290672158 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ADrIi_SXqccWOLUMIWF1IhClGXvKAGMcks5rrM8sgaJpZM4C0swP
.

ऐसा लगता है कि यह धागा AWS/socket.io के साथ समस्याओं का पता लगाने का स्थान बन गया है-

मेरा सेटअप यह है कि क्लाइंट एक socket.io कनेक्शन के लिए डेटा के साथ एक HTTPS अनुरोध करता है।
HTTPS अनुरोध को स्टिकी सत्रों के लिए आवश्यक कुकीज़ के साथ प्रतिक्रिया देनी चाहिए। मुद्दा यह है कि मैं socket.io कनेक्शन में cookie हेडर पास करने में असमर्थ हूं।

मैं इन श्रोताओं के साथ ALB का उपयोग कर रहा हूँ:

इस तरह से कॉन्फ़िगर किए गए चिपचिपाहट वाले लक्ष्य समूह को कौन सा इंगित करता है:

मैंने पहले HTTPS एंडपॉइंट मारा:

fetch(`https://${url}/hub/api/spinup/${uuid}`, {
                method: 'GET',
                headers: headers,
            })

फिर सॉकेट को इनिशियलाइज़ करें

connection = io(`wss://${url}:443/`, {
            path: `/user/${uuid}/spawn`,
        })

उदाहरण के लिए HTTPS अनुरोध _must_ को हिट करता है, उदाहरण के लिए सॉकेट कनेक्शन हिट होता है।

एक बार सॉकेट स्थापित हो जाने के बाद (यदि यह गूंगा भाग्य से सही उदाहरण हिट करता है) यह वहां रहता है और चीजें अच्छी तरह से काम करती हैं, तो समस्या वेबस्केट को उसी एंडपॉइंट को HTTPS अनुरोध के रूप में हिट करने के लिए मिल रही है।

मेरी पहली वृत्ति का उपयोग करना है

connection = io(`wss://${url}:443/`, {
    path: `/user/${uuid}/spawn`,
    extraHeaders: {
        cookie: cookieValueFromFetchResponse
    }
})

यह node में काम करता है , लेकिन ब्राउज़र में cookie XMLHTTPRequests पर निषिद्ध हेडर है, इसलिए मैं इसे साथ भेजने में असमर्थ हूं।

क्या किसी ने कुछ ऐसा ही किया है?

मैंने ऐसा नहीं किया है, लेकिन, जबकि एएलबी में अभी भी हेडर आधारित रूटिंग नहीं है, उनके पास होस्ट आधारित रूटिंग है। यह बेहद हैकिश है, लेकिन आप मूल रूप से इसे बना सकते हैं ताकि एएलबी के पीछे प्रत्येक उदाहरण के पास एक स्पष्ट पथ हो, जिसके बारे में उदाहरण जानता हो। जब वह प्रारंभिक HTTP अनुरोध समाप्त हो जाता है, तो प्रतिक्रिया के हिस्से में पथ शामिल होता है, और वेबसोकेट के कनेक्शन में वह पथ शामिल होता है। यानी, HTTP अनुरोध इंस्टेंस '5' हिट करता है (जो भी मानदंड के आधार पर; जेनरेट किए गए यूयूआईडी बेहतर होंगे), प्रतिक्रिया के हिस्से के रूप में '5' देता है, और वेबस्केट यूआरएल/5 पर खोला जाता है। एएलबी का एक नियम है कि यूआरएल/5 को उदाहरण 5 पर भेजा जाता है।

यदि आप ऑटो स्केलिंग का उपयोग कर रहे हैं (और आपके उदाहरण मवेशी नहीं पालतू जानवर हैं), तो आपको अपने कोड को उदाहरण पर चलाने की आवश्यकता होगी ताकि उपयुक्त डोमेन को रूट करने के लिए ALB सेटिंग्स को संशोधित किया जा सके।

यहां और पढ़ें: https://aws.amazon.com/blogs/aws/new-host-based-routing-support-for-aws-application-load-balancers/

हालांकि, मैं यह भी कहूंगा कि यदि संभव हो तो आप शायद उस पैटर्न से बचना चाहते हैं जिसका आप उपयोग कर रहे हैं। HTTP अनुरोध में आने वाले डेटा को इस तरह से संग्रहीत किया जाना चाहिए जो हर उदाहरण (DB या समान) के लिए सुलभ हो, या इसे स्थापित होने के बाद इसे वेबसोकेट कनेक्शन पर भेजा जाना चाहिए। वैसे भी, आप अभी भी HTTP अनुरोध और वेबसोकेट खोलने के बीच एक उदाहरण मर सकते हैं, और आप एक ही समस्या में भाग सकते हैं (यद्यपि बहुत कम बार)

@lostcolony सलाह के लिए धन्यवाद - यह निश्चित रूप से कोशिश करने लायक है।

http अनुरोध वह है जो वेबसोकेट सर्वर को ट्रिगर करता है (यह वास्तव में एक डॉकटर कंटेनर में है, लेकिन यह दूर है)। दो अनुरोधों को एक ही उदाहरण पर रूट करने की आवश्यकता है ताकि वेबसोकेट सर्वर उस इंस्टेंस पर मौजूद हो जिससे कनेक्ट किया जा रहा है

इस लाइन के साथ, यह ज्यूपिटर सर्वर को एल्ब के पीछे बैठने में मदद करता है।

service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp

अगर कोई इस टिकट पर कुबेरनेट्स के साथ आता है।

मैंने अभी HTTP2 अक्षम कर दिया है तो यह मेरे लिए ठीक है। आपको ईएलबी के बारे में और कुछ नहीं करना है।

नमस्ते,
मुझे एक ही समस्या है, हालांकि मैं सॉकजेएस का उपयोग कर रहा हूं।
मेरा एप्लिकेशन जावा स्प्रिंग 4 एप्लिकेशन है, विकास मशीन पर काम करता है और
एडब्ल्यूएस पर एक ही त्रुटि हो रही है।
ऐसा लगता है कि अपग्रेड हेडर किसी के द्वारा छोड़ा जा रहा है, मैं इसे क्लाइंट पर देख सकता हूं।

अभी तक कोई समाधान ढूंढ सकता है ...

हाय @ yoav200 ,

मुझे बचाओ।
मैं एक ही समस्या में फंस गया हूँ। कृपया सहायता कीजिए
मैं websocket के लिए स्प्रिंगबूट 2.x और सॉकजे का उपयोग कर रहा हूं
मैंने एडब्ल्यूएस में तैनात टॉमकैट एप्लिकेशन बनाया है,
क्लासिक लोड बैलेंसर के साथ लोचदार बीनस्टॉक

अब समस्या है
आईओएस डेवलपर कनेक्ट करने में असमर्थ है, यह मेरे बैकएंड तक पहुंचता है लेकिन यह हैंडशेक के दौरान विफल रहता है
नीचे वे लॉग हैं जो मुझे सीएलबी और एएलबी दोनों में मिलते हैं:

2019-12-13 15:21:22.662 डिबग 27543 --- [nio-8080-exec-2] oswsDispatcherServlet: GET "/wtchat/websocket", पैरामीटर={}
2019-12-13 15:21:22.701 डीबग 27543 --- [nio-8080-exec-2] oswsssWebSocketHandlerMapping: org.springframework.web.socket.sockjs.support पर मैप किया गया। SockJsHttpRequestHandler@30c6a17
2019-12-13 15:21:22.714 डिबग 27543 --- [nio-8080-exec-2] oswssthDefaultSockJsService: प्रोसेसिंग ट्रांसपोर्ट अनुरोध: http://mydomain.com/wtchat/websocket प्राप्त करें
2019-12-13 15:21:22.716 त्रुटि 27543 --- [nio-8080-exec-2] cwcMyHandshakeHandler: अमान्य अपग्रेड हेडर के कारण हैंडशेक विफल: शून्य

2019-12-13 15:21:22.717 DEBUG 27543 --- [nio-8080-exec-2] oswsDispatcherServlet: 400 BAD_REQUEST पूरा किया

आपने जो कहा है मैंने उसका पालन किया है

रूट 53 में एक रिकॉर्ड सेट बनाया जो सीधे बैलेंसर को लोड करने की ओर इशारा करता है।

ऐसा करने के बाद भी मुझे उपरोक्त त्रुटि के समान ही मिल रहा है।

मुझे और क्या करने की जरूरत है?