ajax - WebSockets प्रोटोकॉल बनाम HTTP




comet (4)

वेबसाकेट और HTTP के बारे में कई ब्लॉग और चर्चाएं हैं, और कई डेवलपर्स और साइटें दृढ़ता से websockets का समर्थन करती हैं, लेकिन मैं अभी भी समझ नहीं पा रहा हूं क्यों।

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

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

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

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

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

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

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

http खंडित एन्कोडिंग - http://ru.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 प्रोटोकॉल को अपडेट करने के बजाय इसे क्यों लागू किया गया था?

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

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

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

HTTP में, केवल ग्राहक अनुरोध। सर्वर केवल प्रतिक्रिया।

वेबसॉकेट एक अनुरोध-प्रतिक्रिया प्रोटोकॉल नहीं है जहां केवल क्लाइंट अनुरोध कर सकता है। यह एक सॉकेट है (टीसीपी सॉकेट के समान ही)। एक बार कनेक्शन खुला होने पर, कोई भी पक्ष टीसीपी कनेक्शन को अवरुद्ध होने तक डेटा भेज सकता है। यह एक सामान्य सॉकेट की तरह है। टीसीपी सॉकेट के साथ एकमात्र अंतर वेबसाईट वेब पर इस्तेमाल किया जा सकता है। वेब में, हमारे पास सामान्य सॉकेट के लिए बहुत अधिक प्रतिबंध होता है। अधिकांश फ़ायरवॉल अन्य पोर्ट को 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 नामक नाम के तहत भी बना सकते हैं। लेकिन क्या हम? यदि वे दो अलग-अलग चीजें हैं, तो मैं दो अलग-अलग नाम पसंद करूंगा। तो हिक्सन और माइकल कार्टर करो


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

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

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


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

  1. वेबसाकेट HTTP पर इन लाभ प्रदान करता है:

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


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

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

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

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

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

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

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

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

अपडेट करें :

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

  • टीसीपी : निम्न स्तर, द्वि-दिशात्मक, पूर्ण-डुप्लेक्स, और गारंटीकृत आदेश परिवहन परत। कोई ब्राउज़र समर्थन नहीं (प्लगइन / फ्लैश के माध्यम से छोड़कर)।
  • HTTP 1.0 : अनुरोध-प्रतिक्रिया परिवहन प्रोटोकॉल टीसीपी पर स्तरित। ग्राहक एक पूर्ण अनुरोध करता है, सर्वर एक पूर्ण प्रतिक्रिया देता है, और फिर कनेक्शन बंद हो जाता है। अनुरोध विधियों (प्राप्त करें, पोस्ट, HEAD) सर्वर पर संसाधनों के लिए विशिष्ट लेनदेन का अर्थ है।
  • HTTP 1.1 : HTTP 1.0 की अनुरोध-प्रतिक्रिया प्रकृति को बनाए रखता है, लेकिन कनेक्शन को एकाधिक पूर्ण अनुरोध / पूर्ण प्रतिक्रियाओं (प्रति अनुरोध एक प्रतिक्रिया) के लिए खुला रहने की अनुमति देता है। अनुरोध और प्रतिक्रिया में अभी भी पूर्ण शीर्षलेख हैं लेकिन कनेक्शन का पुनः उपयोग किया जाता है और बंद नहीं होता है। HTTP 1.1 ने कुछ अतिरिक्त अनुरोध विधियों को भी जोड़ा (विकल्प, पुट, डिलीट, ट्रेस, कनेक्ट) जिसमें विशिष्ट लेनदेन संबंधी अर्थ भी हैं। हालांकि, जैसा कि HTTP 2.0 ड्राफ्ट प्रस्ताव के introduction में उल्लेख किया गया है, HTTP 1.1 पाइपलाइनिंग व्यापक रूप से तैनात नहीं है, इसलिए यह ब्राउज़र 1.1 और सर्वर के बीच विलंबता को हल करने के लिए HTTP 1.1 की उपयोगिता को बहुत सीमित करता है।
  • लंबे मतदान : HTTP के लिए "हैक" की तरह (या तो 1.0 या 1.1) जहां सर्वर तुरंत अनुरोध नहीं करता है (या केवल हेडर के साथ आंशिक रूप से प्रतिक्रिया देता है) क्लाइंट अनुरोध पर। सर्वर प्रतिक्रिया के बाद, क्लाइंट तुरंत एक नया अनुरोध भेजता है (यदि HTTP 1.1 से अधिक कनेक्शन का उपयोग कर)।
  • HTTP स्ट्रीमिंग : विभिन्न तकनीकों (मल्टीपार्ट / खंडित प्रतिक्रिया) जो सर्वर को एक क्लाइंट अनुरोध के लिए एक से अधिक प्रतिक्रिया भेजने की अनुमति देती है। डब्ल्यू 3 सी इसे text/event-stream एमआईएमई प्रकार का उपयोग कर सर्वर-प्रेषित घटनाओं के रूप में मानकीकृत कर रहा है। ब्राउज़र एपीआई (जो कि वेबसाकेट एपीआई के समान है) को इवेंटसोर्स एपीआई कहा जाता है।
  • धूमकेतु / सर्वर पुश : यह एक छाता शब्द है जिसमें लंबी अवधि और HTTP स्ट्रीमिंग दोनों शामिल हैं। धूमकेतु पुस्तकालय आमतौर पर क्रॉस-ब्राउज़र और क्रॉस-सर्वर समर्थन को अधिकतम करने और अधिकतम करने के लिए कई तकनीकों का समर्थन करते हैं।
  • वेबसाकेट्स : टीसीपी पर निर्मित एक परिवहन परत जो HTTP अनुकूल अपग्रेड हैंडशेक का उपयोग करती है। टीसीपी के विपरीत, जो एक स्ट्रीमिंग ट्रांसपोर्ट है, वेबस्केट्स एक संदेश आधारित परिवहन है: संदेशों को तार पर सीमित किया जाता है और एप्लिकेशन को डिलीवरी से पहले पूरी तरह से इकट्ठा किया जाता है। वेबसॉकेट कनेक्शन द्वि-दिशात्मक, पूर्ण-डुप्लेक्स और लंबे समय तक जीवित हैं। शुरुआती हैंडशेक अनुरोध / प्रतिक्रिया के बाद, कोई लेनदेन संबंधी अर्थशास्त्र नहीं है और प्रति संदेश ओवरहेड बहुत कम है। ग्राहक और सर्वर किसी भी समय संदेश भेज सकता है और संदेश रसीद को असीमित रूप से संभाल लेना चाहिए।
  • एसपीडीवाई : एक Google ने अधिक कुशल तार प्रोटोकॉल का उपयोग करके HTTP का विस्तार करने के लिए प्रस्ताव शुरू किया लेकिन सभी HTTP अर्थशास्त्र (अनुरोध / प्रतिक्रिया, कुकीज़, एन्कोडिंग) को बनाए रखा। एसपीडीवाई ने एक नया फ़्रेमिंग प्रारूप (लम्बाई-प्रीफिक्स्ड फ्रेम के साथ) प्रस्तुत किया है और नई फ़्रेमिंग परत पर HTTP अनुरोध / प्रतिक्रिया जोड़े को लेयर करने का एक तरीका निर्दिष्ट करता है। हेडर को संकुचित किया जा सकता है और कनेक्शन स्थापित होने के बाद नए शीर्षलेख भेजे जा सकते हैं। ब्राउज़र और सर्वर में एसपीडीवाई के वास्तविक विश्व कार्यान्वयन हैं।
  • HTTP 2.0 : एसपीडीवाई के समान लक्ष्य हैं: HTTP सेमेन्टिक्स को संरक्षित करते समय HTTP विलंबता और ओवरहेड को कम करें। वर्तमान मसौदा एसपीडीवाई से लिया गया है और एक अपग्रेड हैंडशेक और डेटा फ़्रेमिंग को परिभाषित करता है जो हैंडशेक और फ़्रेमिंग के लिए वेबसेट मानक के समान है। एक वैकल्पिक HTTP 2.0 मसौदा प्रस्ताव (httpbis-speed-mobility) वास्तव में परिवहन परत के लिए वेबसाकेट का उपयोग करता है और एसपीडीवाई मल्टीप्लेक्सिंग और HTTP मैपिंग को वेबस्केट एक्सटेंशन के रूप में जोड़ता है (वेबशॉट एक्सटेंशन हैंडशेक के दौरान बातचीत की जाती हैं)।
  • वेबआरटीसी / सीयू-वेबआरटीसी : ब्राउज़र के बीच सहकर्मी-से-पीयर कनेक्टिविटी की अनुमति देने के प्रस्ताव। यह कम औसत और अधिकतम विलंबता संचार सक्षम कर सकता है क्योंकि अंतर्निहित परिवहन टीसीपी की बजाय एसडीपी / डेटाग्राम है। यह पैकेट / संदेशों की आउट-ऑफ-ऑर्डर डिलीवरी की अनुमति देता है जो गिराए गए पैकेट्स के कारण विलंबता स्पाइक्स के टीसीपी मुद्दे से बचाता है जो सभी बाद के पैकेट (ऑर्डर डिलीवरी की गारंटी के लिए) में देरी में देरी करता है।
  • QUIC : टीसीपी के ऊपर वेब विलंबता को कम करने के उद्देश्य से एक प्रयोगात्मक प्रोटोकॉल है। सतह पर, QUIC यूडीपी पर लागू टीसीपी + टीएलएस + एसपीडीवाई के समान ही है। QUIC HTTP / 2 के बराबर मल्टीप्लेक्सिंग और फ्लो कंट्रोल प्रदान करता है, टीएलएस के समतुल्य सुरक्षा, और कनेक्शन अर्थशास्त्र, विश्वसनीयता, और टीसीपी के समेकित कनेक्शन नियंत्रण। चूंकि टीसीपी ऑपरेटिंग सिस्टम कर्नेल और मिडलबॉक्स फर्मवेयर में लागू किया गया है, इसलिए टीसीपी में महत्वपूर्ण बदलाव करना असंभव के बगल में है। हालांकि, चूंकि QUIC यूडीपी के शीर्ष पर बनाया गया है, इसलिए ऐसी कोई सीमा नहीं है। QUIC को HTTP / 2 semantics के लिए डिज़ाइन और अनुकूलित किया गया है।

संदर्भ :







comet