वेबसॉफ़्ट प्रोटोकॉल बनाम एचटीटीपी

Question

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

उदाहरण के लिए (वेबसैट प्रेमियों के तर्क):

HTML5 वेब सॉकेट वेब संचार के अगले विकास का प्रतिनिधित्व करता है - एक पूर्ण-द्वैध, द्विदिश संचार चैनल जो वेब पर एकल सॉकेट के माध्यम से संचालित होता है। ( http://www.websocket.org/quantum.html )

HTTP स्ट्रीमिंग का समर्थन करता है: बॉडी स्ट्रीमिंग का अनुरोध करें (बड़ी फ़ाइलों को अपलोड करते समय आप इसका उपयोग कर रहे हैं) और बॉडी स्ट्रीमिंग का जवाब दें।

WebSocket के साथ संबंध बनाने के दौरान, क्लाइंट और सर्वर एक्सचेंज डेटा प्रति फ्रेम जो कि 2 बाइट्स है, जब आप निरंतर मतदान करते हैं, तो http हेडर के 8 किलो बाइट्स की तुलना में होता है।

उस 2 बाइट्स में tcp और tcp प्रोटोकॉल के तहत ओवरहेड शामिल क्यों नहीं है?

GET /about.html HTTP/1.1
Host: example.org

यह है ~ 48 बाइट्स http हेडर।

http chunked एन्कोडिंग - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• तो, प्रत्येक ठेकरे पर उपरि बड़ा नहीं है।

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

प्रशन:

1. Websockets प्रोटोकॉल बेहतर क्यों है?
2. Http प्रोटोकॉल अपडेट करने के बजाय इसे क्यों लागू किया गया?

Comments

क्या पूछते हैं?

— जोनास

@ जोनास, 1) क्यों वेबसोकेट प्रोटोकॉल बेहतर है? 2) http प्रोटोकॉल अपडेट करने के बजाय इसे क्यों लागू किया गया? 3) वेबसोकेट को इतना प्रचारित क्यों किया जाता है?

— 4esn0k

@JoachimPileborg, आप इसे डेस्कटॉप अनुप्रयोगों के लिए टीसीपी सॉकेट्स या http के साथ भी कर सकते हैं; और आपको वेबसाइट के लिए ब्राउज़र-टू-ब्राउज़र संचार बनाने के लिए WebRTC का उपयोग करना होगा

— 4esn0k

@JoachimPileborg, यह ब्राउज़र-टू-ब्राउज़र के लिए webRTC है, न कि websockets

— 4esn0k

@ 4esn0k, WS बेहतर नहीं है, वे कुछ विशिष्ट कार्यों के लिए अलग और बेहतर हैं। 3) यह एक नई सुविधा है जिसके बारे में लोगों को पता होना चाहिए और वेब के लिए नई संभावनाओं को खोलना चाहिए

— जोनास

Answer 1

1) WebSockets प्रोटोकॉल बेहतर क्यों है?

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

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

उदाहरण अनुरोध (कुकी डेटा सहित 2800 बाइट्स, कुकी डेटा के बिना 490 बाइट्स):

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

उदाहरण प्रतिक्रिया (355 बाइट्स):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

HTTP और WebSockets दोनों में समान आकार के प्रारंभिक कनेक्शन हैंडशेक हैं, लेकिन WebSocket कनेक्शन के साथ प्रारंभिक हैंडशेक एक बार किया जाता है और फिर छोटे संदेशों में केवल 6 बाइट्स ओवरहेड (हेडर के लिए 2 और मुखौटा मूल्य के लिए 4) होते हैं। लेटेंसी ओवरहेड हेडर के आकार से बहुत अधिक नहीं है, लेकिन उन हेडर को पार्स / हैंडल / स्टोर करने के तर्क से। इसके अलावा, टीसीपी कनेक्शन सेटअप विलंबता संभवतः प्रत्येक अनुरोध के लिए आकार या प्रसंस्करण समय से बड़ा कारक है।

2) HTTP प्रोटोकॉल को अपडेट करने के बजाय इसे क्यों लागू किया गया?

बेहतर प्रदर्शन और कम विलंबता जैसे SPDY , HTTP 2.0 और QUIC को प्राप्त करने के लिए HTTP प्रोटोकॉल को फिर से इंजीनियर करने के प्रयास हैं । यह सामान्य HTTP अनुरोधों के लिए स्थिति में सुधार करेगा, लेकिन यह संभावना है कि WebSockets और / या WebRTC DataChannel में अभी भी क्लाइंट के लिए HTTP प्रोटोकॉल की तुलना में सर्वर डेटा ट्रांसफर के लिए विलंबता होगी (या इसका उपयोग ऐसे मोड में किया जाएगा जो WebSockets पर बहुत अधिक दिखता है। वैसे भी)।

अपडेट :

वेब प्रोटोकॉल के बारे में सोचने के लिए यहाँ एक रूपरेखा है:

• टीसीपी : निम्न-स्तर, द्वि-दिशात्मक, पूर्ण-द्वैध, और गारंटीकृत आदेश परिवहन परत। कोई ब्राउज़र समर्थन (प्लगइन / फ्लैश के अलावा)।
• HTTP 1.0 : अनुरोध-प्रतिक्रिया परिवहन प्रोटोकॉल TCP पर स्तरित है। क्लाइंट एक पूर्ण अनुरोध करता है, सर्वर एक पूर्ण प्रतिक्रिया देता है, और फिर कनेक्शन बंद हो जाता है। अनुरोध विधि (GET, POST, HEAD) का सर्वर पर संसाधनों के लिए विशिष्ट लेन-देन अर्थ है।
• HTTP 1.1 : HTTP 1.0 के अनुरोध-प्रतिक्रिया की प्रकृति को बनाए रखता है, लेकिन कनेक्शन को कई पूर्ण अनुरोधों / पूर्ण प्रतिक्रियाओं (प्रति अनुरोध एक प्रतिक्रिया) के लिए खुला रहने देता है। अभी भी अनुरोध और प्रतिक्रिया में पूर्ण हेडर हैं, लेकिन कनेक्शन फिर से उपयोग किया जाता है और बंद नहीं होता है। HTTP 1.1 ने कुछ अतिरिक्त अनुरोध विधियाँ (विकल्प, PUT, DELETE, TRACE, CONNECT) भी जोड़ीं, जिनमें विशिष्ट लेन-देन के अर्थ भी हैं। हालाँकि, जैसा कि HTTP 2.0 ड्राफ्ट प्रस्ताव के परिचय में नोट किया गया है , HTTP 1.1 पाइपलाइनिंग व्यापक रूप से तैनात नहीं है, इसलिए यह ब्राउज़र और सर्वर के बीच विलंबता को हल करने के लिए HTTP 1.1 की उपयोगिता को बहुत सीमित करता है।
• लंबे समय के सर्वेक्षण : HTTP (या तो 1.0 या 1.1) के लिए एक "हैक" की तरह, जहां सर्वर ग्राहक के अनुरोध पर तुरंत (या केवल हेडर के साथ आंशिक रूप से जवाब नहीं) देता है। सर्वर प्रतिक्रिया के बाद, क्लाइंट तुरंत एक नया अनुरोध भेजता है (उसी कनेक्शन का उपयोग करके यदि HTTP 1.1 से अधिक हो)।
• HTTP स्ट्रीमिंग : विभिन्न प्रकार की तकनीकें (मल्टीपार्ट / चंकड रिस्पांस) जो सर्वर को एक क्लाइंट रिक्वेस्ट के एक से अधिक रिस्पांस भेजने की अनुमति देती हैं। W3C एक MIME प्रकार का उपयोग करके सर्वर-भेजे गए ईवेंट के रूप में इसे मानकीकृत कर रहा है text/event-stream। ब्राउज़र एपीआई (जो वेबसॉकेट एपीआई से काफी मिलता-जुलता है) को इवेंटसोर्स एपीआई कहा जाता है।
• धूमकेतु / सर्वर धक्का : यह एक छाता शब्द है जिसमें लंबी-पोल और HTTP स्ट्रीमिंग दोनों शामिल हैं। धूमकेतु पुस्तकालय आमतौर पर क्रॉस-ब्राउज़र और क्रॉस-सर्वर समर्थन को अधिकतम करने के लिए कई तकनीकों का समर्थन करते हैं।
• WebS Pocket : एक ट्रांसपोर्ट लेयर बिल्ट-ऑन टीसीपी जो HTTP फ्रेंडली अपग्रेड हैंडशेक का उपयोग करता है। टीसीपी के विपरीत, जो एक स्ट्रीमिंग ट्रांसपोर्ट है, वेबसॉकेट एक संदेश आधारित परिवहन है: संदेश तार पर सीमांकित होते हैं और आवेदन करने के लिए वितरण से पहले पूर्ण रूप से इकट्ठे होते हैं। WebSocket कनेक्शन द्वि-दिशात्मक, पूर्ण-द्वैध और लंबे समय तक रहने वाले हैं। प्रारंभिक हैंडशेक अनुरोध / प्रतिक्रिया के बाद, कोई भी व्यवहारिक शब्दार्थ नहीं है और प्रति संदेश बहुत कम है। क्लाइंट और सर्वर किसी भी समय संदेश भेज सकते हैं और संदेश रसीद को अतुल्यकालिक रूप से संभालना चाहिए।
• SPDY : एक Google ने अधिक कुशल वायर प्रोटोकॉल का उपयोग करके HTTP का विस्तार करने का प्रस्ताव शुरू किया, लेकिन सभी HTTP शब्दार्थ (अनुरोध / प्रतिक्रिया, कुकीज़, एन्कोडिंग) को बनाए रखा। SPDY एक नया फ़्रेमिंग प्रारूप (लंबाई-पूर्वनिर्मित फ़्रेम के साथ) का परिचय देता है और नई फ़्रेमिंग परत पर HTTP अनुरोध / प्रतिक्रिया जोड़े को स्तरित करने का एक तरीका निर्दिष्ट करता है। हेडर को संपीड़ित किया जा सकता है और कनेक्शन स्थापित होने के बाद नए हेडर भेजे जा सकते हैं। ब्राउज़रों और सर्वरों में SPDY के वास्तविक विश्व कार्यान्वयन हैं।
• HTTP 2.0 : में SPDY के समान लक्ष्य हैं: HTTP शब्दार्थ को संरक्षित करते हुए HTTP विलंबता और ओवरहेड को कम करें। वर्तमान ड्राफ्ट SPDY से लिया गया है और एक अपग्रेड हैंडशेक और डेटा फ्रेमिंग को परिभाषित करता है जो हैंडशेक और फ्रेमिंग के लिए वेबसोकेट मानक के समान है। एक वैकल्पिक HTTP 2.0 ड्राफ्ट प्रस्ताव (HTTPbis-speed-mobility) वास्तव में ट्रांसपोर्ट लेयर के लिए WebSockets का उपयोग करता है और SPDY मल्टीप्लेक्सिंग और HTTP मैपिंग को WebSocket एक्सटेंशन (हैंडस्कॉक के दौरान WebSocket एक्सटेंशन से बातचीत के रूप में) जोड़ा जाता है।
• WebRTC / CU-WebRTC : ब्राउज़रों के बीच सहकर्मी से सहकर्मी कनेक्टिविटी की अनुमति देने का प्रस्ताव। यह निम्न औसत और अधिकतम विलंबता संचार को सक्षम कर सकता है क्योंकि अंतर्निहित परिवहन टीसीपी के बजाय एसडीपी / डेटाग्राम है। यह पैकेट / संदेशों के आउट-ऑफ-ऑर्डर डिलीवरी की अनुमति देता है जो गिराए गए पैकेटों के कारण विलंबता स्पाइक्स के टीसीपी मुद्दे से बचा जाता है जो सभी बाद के पैकेटों की डिलीवरी में देरी करता है (इन-ऑर्डर डिलीवरी की गारंटी देने के लिए)।
• QUIC : एक प्रयोगात्मक प्रोटोकॉल है जिसका उद्देश्य टीसीपी पर वेब विलंबता को कम करना है। सतह पर, QUIC टीसीपी + टीएलएस + एसपीडीवाई के समान है जो यूडीपी पर लागू है। QUIC, HTTP / 2 के बराबर मल्टीप्लेक्सिंग और फ्लो कंट्रोल, TLS के बराबर सुरक्षा और कनेक्शन शब्दार्थ, विश्वसनीयता और कनेक्शन नियंत्रण को TCP प्रदान करता है। क्योंकि टीसीपी ऑपरेटिंग सिस्टम गुठली, और मिडिलबॉक्स फर्मवेयर में लागू किया गया है, टीसीपी में महत्वपूर्ण परिवर्तन करना असंभव के बगल में है। हालांकि, चूंकि QUIC UDP के शीर्ष पर बनाया गया है, इसलिए यह इस तरह की सीमाओं से ग्रस्त है। QUIC को HTTP / 2 शब्दार्थ के लिए डिज़ाइन और अनुकूलित किया गया है।

संदर्भ :

• HTTP :
  • विकिपीडिया HTTP पृष्ठ
  • W3C HTTP संबंधित ड्राफ्ट / प्रोटोकॉल की सूची
  • IETF HTTP / 1.1 और HTTP / 2.0 ड्राफ्ट की सूची
• सर्वर-प्रेषित ईवेंट :
  • W3C सर्वर-भेजे गए ईवेंट / EventSource उम्मीदवार अनुशंसा
  • W3C सर्वर-भेजे गए ईवेंट / EventSource ड्राफ्ट
• WebSockets :
  • IETF RFC 6455 WebSockets प्रोटोकॉल
  • IETF RFC 6455 WebSocket इरेटा
• एसपीडीवाई :
  • IETF SPDY ड्राफ्ट
• HTTP 2.0 :
  • IETF HTTP 2.0 httpbis-http2 ड्राफ्ट
  • IETF HTTP 2.0 httpbis-speed-mobility ड्राफ्ट
  • IETF httpbis-network-friendly Draft - एक पुराना HTTP 2.0 संबंधित प्रस्ताव
• WebRTC :
  • W3C WebRTC एपीआई ड्राफ्ट
  • IETF WebRTC ड्राफ्ट की सूची
  • IETF WebRTC ओवरव्यू ड्राफ्ट
  • IETF WebRTC डेटाचैनल ड्राफ्ट
  • Microsoft CU-WebRTC प्रस्ताव प्रारंभ पृष्ठ
• QUIC :
  • QUIC क्रोमिनम प्रोजेक्ट
  • IETF QUIC ड्राफ्ट

Comments

>> हालांकि, यह क्लाइंट के साथ सर्वर लेटेंसी के लिए मदद नहीं करता है जिसके लिए प्रत्येक क्लाइंट से सर्वर संदेश के लिए एक नए कनेक्शन की आवश्यकता होती है। - प्रतिक्रिया शरीर की स्ट्रीमिंग के बारे में क्या? मुझे पता है, XMLHttpRequest API इसकी अनुमति नहीं देता है, लेकिन यह मौजूद है। सर्वर पर स्ट्रीमिंग के साथ आप क्लाइंट की तरफ से स्ट्रीम कर सकते हैं।

— 4esn0k

@ फ़ीलिप, उन्होंने एक सवाल पूछा कि मैं वैसे भी पूरी तरह से शोध और दस्तावेज़ करना चाहता था। WebSockets बनाम अन्य HTTP आधारित तंत्र का सवाल काफी बार सामने आता है, हालांकि अब लिंक करने के लिए एक अच्छा संदर्भ है। लेकिन हां, ऐसा लगता है कि पूछने वाले की तलाश थी कि वह वेबस्केट्स बनाम एचटीटीपी के बारे में एक पूर्व धारणा के बारे में साक्ष्य की तलाश कर रहा था, खासतौर से क्योंकि उसने कभी जवाब नहीं चुना और न ही इनाम दिया।

— kanaka

यह बहुत अच्छा और सटीक अवलोकन के लिए बहुत बहुत धन्यवाद inprotocols।

— मार्टिन मेसेर

@WardC caniuse.com ब्राउज़र संगतता जानकारी (मोबाइल सहित) दें।

— कनक

@ www139, नहीं, WebSocket प्रोटोकॉल स्तर पर कनेक्शन तब तक खुला रहता है जब तक कि एक तरफ या दूसरी तरफ कनेक्शन बंद नहीं हो जाता। आपको टीसीपी टाइमआउट (किसी भी टीसीपी-आधारित प्रोटोकॉल के साथ एक समस्या) के बारे में चिंता करनी पड़ सकती है, लेकिन हर मिनट या दो पर किसी भी तरह का ट्रैफिक कनेक्शन खुला रखेगा। वास्तव में, WebSocket प्रोटोकॉल परिभाषा एक पिंग / पोंग फ्रेम प्रकार को निर्दिष्ट करती है, हालांकि इसके बिना भी आप एक सिंगल बाइट (प्लस दो बाइट हैडर) भेज सकते हैं और इससे कनेक्शन खुला रहेगा। हर मिनट में 2-3 बाइट्स एक महत्वपूर्ण बैंडविड्थ प्रभाव नहीं है।

— कनक

Answer 2

आपको लगता है कि WebSocket HTTP के लिए एक प्रतिस्थापन है। यह नहीं। यह एक विस्तार है।

WebSockets का मुख्य उपयोग केस जावास्क्रिप्ट अनुप्रयोग हैं जो वेब ब्राउज़र में चलते हैं और सर्वर से वास्तविक समय का डेटा प्राप्त करते हैं। खेल एक अच्छा उदाहरण हैं।

WebSockets से पहले, जावास्क्रिप्ट अनुप्रयोगों के लिए एक सर्वर के साथ बातचीत करने का एकमात्र तरीका था XmlHttpRequest। लेकिन इनका एक बड़ा नुकसान है: सर्वर तब तक डेटा नहीं भेज सकता जब तक कि ग्राहक ने स्पष्ट रूप से इसका अनुरोध नहीं किया हो।

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

तो क्यों नहीं स्ट्रीम और अनुरोधों के साथ सामान्य HTTP का उपयोग करें

एक अन्य उत्तर के लिए एक टिप्पणी में आपने ग्राहक अनुरोध और प्रतिक्रिया निकाय को एसिंक्रोनसली स्ट्रीम करने का सुझाव दिया।

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

Comments

>> जब तक ग्राहक ने इसका अनुरोध न किया हो, वह सर्वर डेटा नहीं भेज सकता है। वेब ब्राउज़र को WebSockets कनेक्शन शुरू करना चाहिए ... XMLHttpRequest

— 4esn0k

@ 4esn0k ब्राउज़र वेबस्केट कनेक्शन आरंभ करता है। लेकिन इसके स्थापित होने के बाद, दोनों पक्ष जब चाहें डेटा भेज सकते हैं। यह XmlHttpRequest के मामले में नहीं है।

— फिलीपींस

यह HTTP के साथ क्यों संभव नहीं है?

— 4esn0k

@Philipp, खेल एक अच्छा उदाहरण है जहाँ WebSockets चमकते हैं। हालाँकि, यह सर्वर से वास्तविक समय का डेटा नहीं है जहाँ आपको सबसे बड़ी जीत मिलती है। आप HTTP स्ट्रीमिंग / लंबे समय से आयोजित कनेक्शन का उपयोग करके लगभग अच्छे सर्वर-> क्लाइंट लेटेंसी के रूप में प्राप्त कर सकते हैं। और लंबे समय से आयोजित अनुरोधों के साथ सर्वर प्रभावी रूप से भेज सकते हैं जब भी उनके पास डेटा होता है क्योंकि ग्राहक ने पहले ही अनुरोध भेजा है और सर्वर के पास "अनुरोध को पकड़" है जब तक कि उसके पास डेटा नहीं है। WebSockets के लिए सबसे बड़ी जीत क्लाइंट-> सर्वर विलंबता (और इसलिए गोल-यात्रा) के साथ है। ग्राहक जब भी अनुरोध के बिना ओवरहेड भेजने में सक्षम हो रहा है, वह असली कुंजी है।

— कांका

@Philipp, एक और नोट: सर्वर के साथ इंटरेक्ट करने के लिए XMLHttpRequest और WebSockets के अलावा अन्य तरीके भी हैं, जिसमें छिपे हुए आइफ्रेम और लंबे-पोल स्क्रिप्ट टैग सहित सर्वर के साथ बातचीत करना है। अधिक जानकारी के लिए धूमकेतु विकिपीडिया पृष्ठ देखें: en.wikipedia.org/wiki/Comet_(programming)

— kanaka

Answer 3

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

WebSockets के साथ, हालाँकि संचार अभी भी एक प्रारंभिक HTTP हैंडशेक के रूप में शुरू होता है, यह WebSockets प्रोटोकॉल का पालन करने के लिए और अधिक उन्नयन है (अर्थात यदि सर्वर और क्लाइंट दोनों प्रोटोकॉल के अनुरूप हैं, तो सभी संस्थाएँ WebSockets प्रोटोकॉल का समर्थन नहीं करती हैं)।

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

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

आप वेबसोकेट पर एक गहरा गोता लेख देख सकते हैं जो इस प्रोटोकॉल के इतिहास को बताता है कि यह कैसे अस्तित्व में आया, इसका क्या उपयोग किया जाता है और आप इसे स्वयं कैसे लागू कर सकते हैं।

यहाँ प्रस्तुति से एक वीडियो है जो मैंने WebSockets के बारे में किया था और वे नियमित REST API का उपयोग करने से अलग कैसे हैं: डेटा स्ट्रीमिंग में घातीय वृद्धि का मानकीकरण और लाभ

Answer 4

TL; DR के लिए, यहाँ 2 सेंट और आपके प्रश्नों के लिए एक सरल संस्करण है:

1. WebSockets HTTP पर ये लाभ प्रदान करता है:

   • कनेक्शन की अवधि के लिए लगातार स्टेटफुल कनेक्शन
   • निम्न विलंबता: HTTP अनुरोध के रूप में प्रत्येक अनुरोध के लिए कनेक्शन पुन: स्थापित करने का कोई ओवरहेड नहीं होने के कारण सर्वर / क्लाइंट के बीच वास्तविक समय संचार।
   • पूर्ण द्वैध: सर्वर और क्लाइंट, दोनों को समान रूप से भेज / प्राप्त कर सकते हैं

2. WebSocket और HTTP प्रोटोकॉल को अलग-अलग समस्याओं को हल करने के लिए डिज़ाइन किया गया है, IE WebSocket को द्वि-दिशात्मक संचार में सुधार करने के लिए डिज़ाइन किया गया था जबकि HTTP को एक अनुरोध / प्रतिक्रिया मॉडल का उपयोग करके वितरित किया गया था। विरासत कारणों (फ़ायरवॉल / प्रॉक्सी पैठ) के लिए बंदरगाहों को साझा करने के अलावा, उन्हें एक प्रोटोकॉल में संयोजित करने के लिए एक सामान्य आधार नहीं है।

Comments

महत्वपूर्ण है कि आपने अपनी तुलना (Y) में स्टेटफुल और स्टेटलेस का उल्लेख किया है

— उत्सव टी

Answer 5

Websockets प्रोटोकॉल बेहतर क्यों है?

मुझे नहीं लगता कि हम उनकी तुलना इस तरह कर सकते हैं कि कौन बेहतर है। यह उचित तुलना नहीं होगी क्योंकि वे दो अलग-अलग समस्याओं को हल कर रहे हैं । उनकी आवश्यकताएं अलग हैं। यह सेब की तुलना संतरे से करने जैसा होगा। वे भिन्न हैं।

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

HTTP में, केवल क्लाइंट अनुरोध। सर्वर ही जवाब देता है।

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

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

एक बार सर्वर अनुरोध को समझ लेता है और वेबसोकेट प्रोटोकॉल में अपग्रेड हो जाता है, HTTP प्रोटोकॉल में से कोई भी लागू नहीं होता है।

इसलिए मेरा जवाब न तो एक दूसरे से बेहतर है। वे पूरी तरह से अलग हैं।

Http प्रोटोकॉल अपडेट करने के बजाय इसे क्यों लागू किया गया?

वैसे हम HTTP नाम से सब कुछ बना सकते हैं । लेकिन हम करेंगे? अगर वे दो अलग-अलग चीजें हैं, तो मैं दो अलग-अलग नामों को पसंद करूंगा। तो हिकसन और माइकल कार्टर करते हैं ।

Answer 6

अन्य उत्तर यहां एक महत्वपूर्ण पहलू पर स्पर्श नहीं करते हैं, और आप एक ग्राहक के रूप में वेब ब्राउज़र का समर्थन करने की आवश्यकता का कोई उल्लेख नहीं करते हैं। ऊपर सादे HTTP की अधिकांश सीमाएँ मान रही हैं कि आप ब्राउज़र / JS कार्यान्वयन के साथ काम करेंगे।

HTTP प्रोटोकॉल पूर्ण-द्वैध संचार में पूरी तरह से सक्षम है; यह मुमकिन है कि मुवक्किल ठग एन्कोडिंग ट्रांसफर के साथ POST करे और चंकड एन्कोडिंग बॉडी के साथ प्रतिक्रिया देने के लिए सर्वर करे। यह हेडर ओवरहेड को सिर्फ init समय पर हटा देगा।

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