http - WebSocket सर्वर कई आने वाले कनेक्शन अनुरोधों को कैसे संभालता है?




नया गैस कनेक्शन की कीमत 2019 (3)

here अनुसार:

HTTP अपग्रेड हेडर अनुरोध करता है कि सर्वर HTTP से WebSocket प्रोटोकॉल में एप्लिकेशन-लेयर प्रोटोकॉल को स्विच करता है

क्लाइंट हैंडशेक ने IE10 और सर्वर के बीच HTTP-on-TCP कनेक्शन स्थापित किया। सर्वर द्वारा अपनी 101 प्रतिक्रिया देने के बाद, एप्लिकेशन-लेयर प्रोटोकॉल HTTP से WebSockets पर स्विच हो जाता है जो पहले से स्थापित टीसीपी कनेक्शन का उपयोग करता है।

इस बिंदु पर HTTP पूरी तरह से तस्वीर से बाहर है । हल्के WebSocket वायर प्रोटोकॉल का उपयोग करके, संदेश अब किसी भी समय समापन बिंदु द्वारा भेजे या प्राप्त किए जा सकते हैं।

इसलिए, मेरी समझ यह है कि 1 क्लाइंट द्वारा सर्वर के साथ हैंडशेक करने के बाद, सर्वर के 80 पोर्ट का वेबस्केट प्रोटोकॉल द्वारा एकाधिकार हो जाएगा। और HTTP अब 80 पोर्ट पर काम नहीं कर रहा है

तो सर्वर के साथ दूसरा क्लाइंट एक्सचेंज हैंडशेक कैसे कर सकता है। सभी WebSocket हैंडशेक HTTP फॉर्मेट में होने के बाद।

एडीडी 1

अब तक के सभी उत्तरों के लिए धन्यवाद। वे वास्तव में मददगार हैं।

अब मैं समझता हूं कि एक ही सर्वर के 80 पोर्ट को कई TCP कनेक्शन द्वारा साझा किया जाता है। और यह साझा करना पूरी तरह से ठीक है क्योंकि TCP कनेक्शन को 5-तत्व टपल द्वारा Jan-Philip Gehrcke रूप में Jan-Philip Gehrcke जाता है।

मैं कुछ विचार जोड़ना चाहूंगा।

WebSocket और HTTP दोनों ही एप्लिकेशन स्तर के प्रोटोकॉल हैं। आमतौर पर वे दोनों अपने प्रोटोकॉल के रूप में TCP प्रोटोकॉल पर भरोसा करते हैं।

पोर्ट 80 क्यों चुनें?

WebSocket डिज़ाइन जानबूझकर हैंडशेक और निम्न संचार दोनों के लिए सर्वर के पोर्ट 80 को चुनते हैं । मुझे लगता है कि डिजाइनर परिवहन स्तर के दृष्टिकोण (यानी सर्वर पोर्ट संख्या अभी भी 80 है) से सामान्य HTTP संचार की तरह WebSocket संचार करना चाहता है। लेकिन jfriend00 के जवाब के अनुसार, यह ट्रिक हमेशा नेटवर्क इन्फ्रास्ट्रक्चर को बेवकूफ नहीं बनाती है।

HTTP से WebSocket में प्रोटोकॉल कैसे बदलता है?

RFC 6455 से - वेबसोकेट प्रोटोकॉल

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

इसलिए मुझे लगता है कि मैं निम्नलिखित कथन पर गलत हूं:

हैंडशेक अनुरोध HTTP अनुरोध की नकल करता है लेकिन संचार जो इस प्रकार नहीं है। हैंडशेक अनुरोध पोर्ट 80 पर सर्वर पर आता है। क्योंकि यह 80 पोर्ट है, सर्वर इसे HTTP प्रोटोकॉल के साथ व्यवहार करेगा। और यही कारण है कि HTTP प्रारूप में WebSocket हैंडशेक अनुरोध होना चाहिए। यदि ऐसा है, तो मुझे लगता है कि HTTP प्रोटोकॉल को उन WebSocket- विशिष्ट चीजों को पहचानने के लिए संशोधित / विस्तारित किया जाना चाहिए । अन्यथा यह एहसास नहीं होगा कि यह WebSocket प्रोटोकॉल के लिए होना चाहिए।

मुझे लगता है कि इसे इस तरह समझा जाना चाहिए:

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

WebSocket और धूमकेतु

तो WebSocket Comet प्रौद्योगिकियों से अलग है, जिसमें WebSoket द्वि-दिशात्मक संचार समस्या को हल करने के लिए वर्तमान HTTP दायरे में खुद को सीमित नहीं करता है।

ADD 2

एक संबंधित प्रश्न: एक ब्राउज़र 80 पोर्ट पर एक वेब सर्वर के साथ संबंध कैसे स्थापित करता है? विवरण?


अन्य उत्तर पहले से ही सहायक हैं। मैं यह बताना चाहता हूं कि आपका प्रश्न बहुत अच्छा है, और इसका उत्तर listen() और accept() शामिल करने के दृष्टिकोण से देना चाहते हैं। इन दो सिस्टम कॉल का व्यवहार आपके प्रश्न का उत्तर देने के लिए पर्याप्त होना चाहिए।

आप रुचि रखते हैं कि टीसीपी / आईपी कैसे काम करता है!

प्रश्न के मुख्य भाग के लिए वास्तव में HTTP या WebSocket के आधार पर कोई अंतर नहीं है: IP पर सामान्य जमीन TCP है और यह आपके प्रश्न का उत्तर देने के लिए पर्याप्त है। फिर भी, आप एक जवाब के लायक हैं कि WebSocket TCP से कैसे संबंधित है (मैंने उस पर थोड़ा और विस्तार करने की कोशिश की here ): HTTP अनुरोध भेजने पर दो पक्षों के बीच एक स्थापित टीसीपी / आईपी कनेक्शन की आवश्यकता होती है। एक साधारण वेब ब्राउज़र / वेब सर्वर परिदृश्य के मामले में

  1. पहले, दोनों के बीच एक टीसीपी कनेक्शन स्थापित किया जाता है (क्लाइंट द्वारा शुरू किया गया)
  2. फिर उस टीसीपी कनेक्शन (क्लाइंट से सर्वर पर) के माध्यम से एक HTTP अनुरोध भेजा जाता है
  3. तब HTTP प्रतिसाद उसी टीसीपी कनेक्शन के माध्यम से भेजा जाता है (दूसरी दिशा में, सर्वर से क्लाइंट तक)

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

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

एक ही सॉकेट के माध्यम से कई आईपी कनेक्शन प्रयासों को संभालना, कैसे?

यह एक ऐसा विषय है जो मैं एक बार अपने आप से संघर्ष कर रहा था और बहुतों को समझ नहीं आ रहा है। हालांकि, अवधारणा वास्तव में बहुत सरल है जब कोई समझता है कि ऑपरेटिंग सिस्टम द्वारा प्रदान किए गए बुनियादी सॉकेट-संबंधित सिस्टम कॉल कैसे काम कर रहे हैं।

सबसे पहले, एक व्यक्ति को सराहना करने की आवश्यकता है कि आईपी कनेक्शन विशिष्ट रूप से सूचना के पांच टुकड़ों द्वारा परिभाषित किया गया है:

आईपी: मशीन ए और आईपी ​​का प्रकार: मशीन बी का प्रकार और प्रोटोकॉल (टीसीपी या यूडीपी)

अब, सॉकेट ऑब्जेक्ट को अक्सर कनेक्शन का प्रतिनिधित्व करने के लिए सोचा जाता है। लेकिन यह पूरी तरह सच नहीं है। वे विभिन्न चीजों का प्रतिनिधित्व कर सकते हैं: वे सक्रिय या निष्क्रिय हो सकते हैं। निष्क्रिय / सुन मोड में एक सॉकेट ऑब्जेक्ट कुछ विशेष करता है, और यह आपके प्रश्न का उत्तर देने के लिए महत्वपूर्ण है। http://linux.die.net/man/2/listen कहते हैं:

सुनें () सॉकेट द्वारा संदर्भित सॉकेट को एक निष्क्रिय सॉकेट के रूप में चिह्नित करता है, अर्थात, सॉकेट के रूप में जिसे स्वीकार (2) का उपयोग करके आने वाले कनेक्शन अनुरोधों को स्वीकार करने के लिए उपयोग किया जाएगा।

इसलिए, हम एक निष्क्रिय सॉकेट बना सकते हैं जो आने वाले कनेक्शन अनुरोधों के लिए सुनता है। परिभाषा के अनुसार, ऐसा सॉकेट कभी भी कनेक्शन का प्रतिनिधित्व नहीं कर सकता है। यह सिर्फ कनेक्शन अनुरोधों के लिए सुनता है।

चलो accept() करने के लिए सिर accept() ( http://linux.die.net/man/2/accept ):

कनेक्शन-आधारित सॉकेट प्रकार (SOCK_STREAM, SOCK_SEQPACKET) के साथ स्वीकार () सिस्टम कॉल का उपयोग किया जाता है। यह सुनने वाले सॉकेट के लिए लंबित कनेक्शन की कतार पर पहला कनेक्शन अनुरोध निकालता है, sockfd, एक नया कनेक्टेड सॉकेट बनाता है, और उस सॉकेट का जिक्र करते हुए एक नया फ़ाइल विवरणक लौटाता है। नव निर्मित सॉकेट सुनने की स्थिति में नहीं है। इस कॉल से मूल सॉकेट सॉकफ अप्रभावित है।

आपके प्रश्न का उत्तर देने के लिए हमें बस इतना ही पता होना चाहिए। accept() पहले बनाए गए निष्क्रिय सॉकेट की स्थिति को नहीं बदलता है। यह एक सक्रिय (कनेक्टेड) सॉकेट लौटाता है (ऐसा सॉकेट तब सूचना के पाँच टुकड़ों का प्रतिनिधित्व करता है जो ऊपर - सरल, सही है)। आमतौर पर, यह नव निर्मित सक्रिय सॉकेट ऑब्जेक्ट फिर किसी अन्य प्रक्रिया या थ्रेड या "इकाई" को सौंप दिया जाता है जो कनेक्शन का ख्याल रखता है। accept() बाद accept() ने इस जुड़े सॉकेट ऑब्जेक्ट को वापस कर दिया है, accept() निष्क्रिय सॉकेट पर फिर से कॉल किया जा सकता है, और फिर से - फिर से कुछ जिसे स्वीकार लूप के रूप में जाना जाता है। लेकिन कॉलिंग accept() में समय लगता है, है ना? क्या यह आने वाले कनेक्शन अनुरोधों को याद नहीं कर सकता है? बस उद्धृत सहायता पाठ में अधिक आवश्यक जानकारी है: लंबित कनेक्शन अनुरोधों की एक कतार है! यह आपके ऑपरेटिंग सिस्टम के TCP / IP स्टैक द्वारा स्वचालित रूप से हैंडल किया जाता है। इसका अर्थ है कि accept() समय accept() केवल आने वाले कनेक्शन अनुरोधों को एक-एक करके निपटा सकता है, जब कोई उच्च दर या (अर्ध-) एक साथ आने पर भी कोई आवक अनुरोध नहीं छोड़ा जाएगा। कोई कह सकता है कि accept() का व्यवहार accept() आवक कनेक्शन की आवृत्ति को सीमित कर रहा है जो आपके मशीन को संभाल सकता है। हालाँकि, यह एक तेज़ सिस्टम कॉल है और व्यवहार में, अन्य सीमाएं पहले हिट हो जाती हैं - आमतौर पर उन सभी कनेक्शनों को संभालने से संबंधित होती हैं जिन्हें अब तक स्वीकार किया गया है।


अपने प्रश्न का उत्तर देने के लिए: एक साथ वेबसोकेट और एचटीटीपी कनेक्शन को पोर्ट 80 पर संभाला जाता है ...

ठीक उसी तरह जिस तरह से एक साथ HTTP कनेक्शन पोर्ट 80 के लिए संभाला जाता है!

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

फिर कतार में आने वाले अनुरोध का इंतजार करता है या संभालता है।

यदि आप यह जानना चाहते हैं कि HTTP 1.1 और UPGRADE अनुरोध किस भाग पर चलते हैं, तो यह here यह here इसे बहुत महत्वपूर्ण बनाता है:

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

केवल वेबसोकेट सेवाओं को आमतौर पर वेब सर्वर में नहीं बनाया जाता है, इसलिए वास्तव में पोर्ट 80 में सुनने का इरादा नहीं है, बस इसके माध्यम से वेब सर्वर के पारदर्शी अग्रेषण के लिए सुलभ है। Apache Web सर्वर mod_proxy_wstunnel का उपयोग करता है।

बेशक, आपके पास एक वेब सर्वर भी हो सकता है जिसमें बिल्ट इन वेब सॉकेट्स का कार्यान्वयन हो: उदाहरण के लिए अपाचे टोमाकट

यहां मुख्य बात यह है: वेबसोकेट प्रोटोकॉल HTTP नहीं है। यह एक अलग उद्देश्य पूरा करता है। यह एक स्वतंत्र अनुप्रयोग-परत संचार प्रोटोकॉल है जो टीसीपी के शीर्ष पर भी बनाया गया है (हालांकि टीसीपी की आवश्यकता नहीं है, लेकिन एक परिवहन परत प्रोटोकॉल जो वेबसोकेट्स एप्लिकेशन परत प्रोटोकॉल की आवश्यकताओं को पूरा करता है)।

एक Websocket सेवा एक PARALLEL सेवा है जो वेब सर्वर सेवा के साथ चलती है।

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

आप Websocket क्लाइंट (आमतौर पर वेब ब्राउज़र) और उस सेवा के बीच निरंतर, गैर-HTTP कनेक्शन स्थापित करने के लिए एक Websocket सेवा की स्थापना या निर्माण करते हैं।

मुख्य लाभ यह है: वेबसोकेट सेवा ग्राहक को एक संदेश भेज सकती है जब भी उसे जरूरत होती है ("आप में से एक दोस्त जुड़ा है!" "आपकी टीम ने केवल एक गोल किया है!"), इसके बजाय ग्राहक के स्पष्ट अनुरोध की प्रतीक्षा करें! एक अद्यतन के लिए।

आप HTTP 1.1 का उपयोग करके एक निरंतर कनेक्शन स्थापित कर सकते हैं, लेकिन HTTP का अर्थ संसाधनों के एक सेट की सेवा के अलावा और कुछ नहीं है, फिर कनेक्शन को बंद करें।

हाल तक तक, सभी प्रमुख ब्राउज़रों में Websockets का समर्थन उपलब्ध होने से पहले, आपके पास वेब एप्लिकेशन पर वास्तविक समय अपडेट लागू करने के लिए केवल दो विकल्प थे:

  • AJAX के लंबे मतदान अनुरोधों को लागू करना, जो एक दर्दनाक और अक्षम प्रक्रिया है।

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

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

हमेशा की तरह, एक विशेष टीसीपी सॉकेट पर एक सेवा को सुनने वाले सभी कनेक्शन (server_ip: service_TCP_port) को एक विशिष्ट client_ip: client_TCP_port जोड़ी, क्लाइंट_TCP_port को उसके उपलब्ध टीसीपी बंदरगाहों के बीच ग्राहक द्वारा यादृच्छिक रूप से चुने जाने पर विभेदित किया जाएगा।

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


यह काफी सरल अवधारणा है, इसलिए मुझे उन सरल शब्दों में इसका वर्णन करने की कोशिश करें, जब कुछ अन्य खोई हुई आत्मा उन सभी लंबी व्याख्याओं को पढ़े बिना इसे समझ लेना चाहती है।

कई कनेक्शन

  1. वेब सर्वर कनेक्शन के लिए सुनना शुरू कर देता है। ऐसा होता है:

    • वेब सर्वर की मुख्य प्रक्रिया राज्य में एक निष्क्रिय सॉकेट खोलती है जो पोर्ट 80 पर listen , जैसे 9.9.9.9:80 ( 9.9.9.9 सर्वर आईपी और 80 पोर्ट है)।
  2. ब्राउज़र सर्वर पर 80 पोर्ट करने का अनुरोध करता है। ऐसा होता है:

    • ऑपरेटिंग सिस्टम (शॉर्ट ओएस में) क्लाइंट पर एक यादृच्छिक आउटबाउंड पोर्ट आवंटित करता है, कहते हैं: 1.1.1.1:6747 ( 1.1.1.1 क्लाइंट आईपी है और 6747 यादृच्छिक पोर्ट है)।

    • ओएस एक डेटा पैकेट स्रोत पते 1.1.1.1:6747 और गंतव्य पते 9.9.9.9:80 साथ भेजता है। यह विभिन्न राउटर और स्विच के माध्यम से जाता है और गंतव्य सर्वर पर आता है।

  3. सर्वर पैकेट प्राप्त करता है। ऐसा होता है:

    • सर्वर ओएस देखता है कि पैकेट का गंतव्य पता उसके स्वयं के आईपी पते में से एक है और गंतव्य पोर्ट के आधार पर इसे पोर्ट 80 जुड़े एप्लिकेशन को पास करता है।

    • वेब सर्वर की मुख्य प्रक्रिया एक नया सक्रिय सॉकेट बनाने वाले कनेक्शन को स्वीकार करती है। फिर यह आम तौर पर एक नई बच्चे की प्रक्रिया की तलाश करता है, जो सक्रिय सॉकेट पर ले जाता है। निष्क्रिय सॉकेट नए आने वाले कनेक्शन को स्वीकार करने के लिए खुला रहता है।

अब सर्वर से ग्राहक को भेजे जाने वाले प्रत्येक पैकेट में वे पते होंगे:

  • स्रोत: 9.9.9.9:1553 ; गंतव्य: 1.1.1.1:80 : 1.1.1.1:80

और ग्राहक से सर्वर पर भेजे जाने वाले हर पैकेट में वे पते होंगे:

  • स्रोत: 1.1.1.1:80 ; गंतव्य: 9.9.9.9:1553

HTTP -> वेबस्केट हैंडशेक

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

WebSocket HTTP पर आधारित नहीं है। यह एक द्विआधारी प्रोटोकॉल है जहां संदेशों की कई धाराएं एक ही समय (पूर्ण-द्वैध मोड) में दोनों दिशाओं में भेजी जा सकती हैं। इसकी वजह से एक नया HTTP मानक शुरू किए बिना सीधे WebSocket कनेक्शन स्थापित करना संभव नहीं होगा, उदाहरण के लिए HTTP/2 । लेकिन ऐसा तभी संभव होगा जब:

  1. WebSocket HTTP क्रियाओं / अनुरोधों का समर्थन करता है

  2. वेबसोकेट-विशिष्ट संचार के लिए 80 से अलग एक नया समर्पित पोर्ट था।

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





spring-websocket