क्या HTTP UDP का उपयोग करता है?


103

यह एक मूर्खतापूर्ण प्रश्न हो सकता है:

  • क्या HTTP कभी उपयोगकर्ता डेटाग्राम प्रोटोकॉल का उपयोग करता है?

उदाहरण के लिए:

यदि कोई HTTP का उपयोग करके एमपी 3 या वीडियो स्ट्रीमिंग कर रहा है, तो क्या यह आंतरिक रूप से परिवहन के लिए यूडीपी का उपयोग करता है?


आपका क्या मतलब है: "वेब"? आप एक ब्राउज़र का उपयोग कर मतलब है? या सार्वजनिक इंटरनेट पर?
सेंक

मेरे कहने का मतलब यह था कि किसी यूआरएल पर होस्ट किया गया है जैसे someserver / somemusic.mp3 । अगर यह किसी भी क्लाइंट - ब्राउज़र, डिवाइस आदि पर स्ट्रीम किया जाता है तो http इसे कैसे ट्रांसफर करता है। अगर मैं नीचे दिए गए उत्तरों को सही ढंग से समझता हूं, तो यह आरटीपी को सौंप दिया गया है।
शीश

पोर्ट 80 यूडीपी HTTP के लिए भी आरक्षित है, जो मुझे मनोरंजक लगता है क्योंकि मैंने इसका इस्तेमाल कभी नहीं देखा है, न ही मैं इसके लिए एक अच्छे उपयोग की कल्पना कर सकता हूं।
यहोशू

1
यह आरक्षित है क्योंकि IANA समिति में एक अधिक लचीली कल्पना है जो आप करते हैं। ;-) वे छवि है कि बस इसके लिए एक अच्छा उपयोग हो सकता है। इसके अलावा, यूडीपी / एचटीटीपी के लिए पोर्ट 80 को आरक्षित नहीं करने के लिए इसे कुछ अन्य यूडीपी प्रोटोकॉल के लिए खुला छोड़ दिया जाएगा, जो पोर्ट 80 के बारे में बात करते समय भ्रम पैदा करेगा।
जेसी चिशोल्म

जवाबों:


42

आमतौर पर, नहीं।

स्ट्रीमिंग शायद ही कभी HTTP पर उपयोग की जाती है, और HTTP शायद ही कभी UDP पर चलाया जाता है। देखें, फिर भी, आरटीपी

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

जैसा कि टिप्पणीकारों ने बताया है, हालांकि, HTTP पर वास्तव में स्ट्रीम करना निश्चित रूप से संभव है, और यह कुछ लोगों द्वारा किया गया है।


16
स्पष्ट रूप से गलत है, HTTP में ऐसा कुछ भी नहीं है जो स्ट्रीमिंग को रोकता है यह उतना कुशल नहीं है जितना कि एक समर्पित प्रोटोकॉल होगा। HTTP डायनामिक स्ट्रीमिंग चंक्स का उपयोग करते हुए: adobe.com/products/httpdynamicstreaming HTTP स्यूडो-स्ट्रीमिंग: longtailvideo.com/support/jw-player/jw-player-for-flash.v5/…
Steve-o

14
HTTP पर youtube स्ट्रीम।
ओपन स्कूल

6
@ snowcrash09 मैं इसे स्वयं हटा भी नहीं सकता, क्योंकि यह स्वीकार है। वह अजीब है। मैंने इसे फिर से लिखा, मुझे उम्मीद है कि अब यह कम अपमानजनक है।
खोलना

1
बस HTTP और स्ट्रीमिंग के बारे में पांडित्यपूर्ण होने के नाते - QuickTime वीडियो के अंधेरे युगों में, वहाँ था server push, जहाँ HTTP कनेक्शन MJPEG (एकाधिक JPEG चित्र) भेजते हैं, जो MIME मल्टीपार्ट प्रतिक्रिया के अलग-अलग भाग के रूप में HTTP अनुरोध को भेजते हैं। प्रत्येक JPEG छवि आती है और प्रदर्शन में पिछले को बदल देती है। लेकिन आप सही हैं @unwind, यह शायद ही कभी आज किया जाता है, क्योंकि RTP / RTSP बेहतर काम करता है।
जेसी चिशोल्म

3
@nos Youtube स्ट्रीमिंग नहीं है। ब्राउज़र एक फ़ाइल को कैश में डाउनलोड करता है और पूरी तरह से डाउनलोड होने से पहले फ़ाइल से खेलना शुरू कर देता है। हालांकि यह स्ट्रीमिंग का अनुकरण करता है, यह नहीं है।
साइमनस्टाइप

113

से RFC 2616 :

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

इसलिए हालांकि यह स्पष्ट रूप से ऐसा नहीं कहता है, यूडीपी का उपयोग नहीं किया जाता है क्योंकि यह "विश्वसनीय परिवहन" नहीं है।

EDIT - हाल ही में, QUIC प्रोटोकॉल (जो कि कड़ाई से छद्म परिवहन या सत्र परत प्रोटोकॉल है) HTTP / 2.0 ट्रैफ़िक को ले जाने के लिए UDP का उपयोग करता है और Google का अधिकांश ट्रैफ़िक पहले से ही इस प्रोटोकॉल का उपयोग करता है। यह वर्तमान में HTTP / 3 के रूप में मानकीकरण की ओर अग्रसर है ।


क्या ऐसे कोई वेबसर्वर हैं जिन्हें टीसीपी नहीं है, जो कनेक्शन स्वीकार करने के लिए कॉन्फ़िगर किया जा सकता है?
Spidey

1
टीसीपी के बजाए SCTP प्रोटोकॉल का उपयोग करने के लिए यहाँ श्रोणि ।.cel.udel.edu को अप करने के लिए संशोधन किया गया है ।
ओपन स्कूल

@nos Yup और Google के पास SPDY भी है। दोनों विश्वसनीय परिवहन तंत्र हैं, हालांकि।
अलनीतक

5
@Alnitak SPDY एक एप्लीकेशन लेयर प्रोटोकॉल है, ट्रांसपोर्ट लेयर प्रोटोकॉल नहीं।
विकी

@WalkingWiki आप निश्चित रूप से सही हैं - इस संदर्भ में SPDY HTTP को प्रतिस्थापित करता है, टीसीपी को नहीं।
अलनीतक

36

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


4
अधिक विशिष्ट होने के लिए, यूपीएनपी का वह भाग जो यूडीपी और एचटीटीपी जैसे संदेशों का उपयोग करता है, उसे एसएसडीपी (सिंपल सर्विस डिस्कवरी प्रोटोकॉल) कहा जाता है। संदेश संरचना समान है, लेकिन METHODसेट अलग है। उसके बाद, UPnP बाकी के लिए अन्य प्रोटोकॉल (और आमतौर पर टीसीपी) का उपयोग करता है।
जेसी चिशोल्म

20

हां, HTTP, एक एप्लिकेशन प्रोटोकॉल के रूप में, यूडीपी परिवहन प्रोटोकॉल पर स्थानांतरित किया जा सकता है। यहां कुछ सेवाएं हैं जो HTTP डेटा को स्थानांतरित करने के लिए UDP और एक अंतर्निहित प्रोटोकॉल का उपयोग करती हैं और इसे अंतिम-उपयोगकर्ता के लिए स्ट्रीमिंग करती हैं:

  • XMPP की जिंगल रॉ यूडीपी ट्रांसपोर्ट विधि
  • यूडीटी का उपयोग करने वाली सेवाओं के लिए एक नंबर --- यूडीपी आधारित डेटा ट्रांसफर प्रोटोकॉल, जो यूडीपी प्रोटोकॉल का सुपरसेट है।
  • ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) प्रोटोकॉल HTTP को घेरने के साथ-साथ उपर्युक्त एक्सएमपीपी और अन्य एप्लिकेशन प्रोटोकॉल का एक कार्यान्वयन है जो यूडीपी को अपनी परिवहन परत में उपयोग करता है; इस कार्यान्वयन को डाटाग्राम ट्रांसपोर्ट लेयर सिक्योरिटी (DTLS) कहा जाता है।
  • GNUTella में पुश सूचनाएं UDP परिवहन पर भेजे गए HTTP अनुरोध हैं।

इस लेख में UDP और इसके विश्वसनीय सुपरसेट, RUDP: विश्वसनीय UDP (RUDP): अगली बड़ी स्ट्रीमिंग प्रोटोकॉल पर स्ट्रीमिंग के बारे में अधिक विवरण हैं


1
एक अन्य प्रश्न: क्या प्रमुख वेब ब्राउज़र यूडीपी पर वेब पेज HTTP का समर्थन करते हैं?
user2284570

हाँ, क्योंकि HTTP एप्लिकेशन लेयर में है और ट्रांसपोर्ट लेयर में UDP है। ब्राउज़र टीसीपी या यूडीपी पैकेट नहीं लिखते हैं। न ही वे IP पैकेट लिखते हैं। जिन्हें OS और ड्राइवर संभालते हैं। ईथरनेट परत इतनी कम है कि यह इस बिंदु पर मैक के करीब चिप में हो सकती है।
यान बेलवेंस

@yanbellavance यह पूरी तरह से गलत है। हालांकि ब्राउज़र और वेब सर्वर वास्तव में कच्चे टीसीपी फ्रेम उत्पन्न नहीं करते हैं (न ही उस मामले के लिए यूडीपी वाले), उन्हें उपयोग करने के लिए परिवहन का चयन करना पड़ता है , और सामान्य HTTP के लिए जो हमेशा टीसीपी होता है। नए QUIC pseudo-प्रोटोकॉल हालांकि UDP का उपयोग करते हैं।
अलनीतक

18

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


6

हो सकता है कि इस विषय पर QUIC के साथ कुछ बदलाव हो

QUIC (क्विक यूडीपी इंटरनेट कनेक्शन्स, क्विक क्विक क्विक) Google द्वारा विकसित और 2013 में लागू किया गया एक प्रायोगिक ट्रांसपोर्ट लेयर नेटवर्क प्रोटोकॉल है। QUIC यूजर डेटाग्राम प्रोटोकॉल (UDP) के ऊपर दो एंडपॉइंट के बीच मल्टीप्लेक्स किए गए कनेक्शन के एक सेट का समर्थन करता है, और सुरक्षा सुरक्षा प्रदान करने के लिए डिज़ाइन किया गया था। कम कनेक्शन और परिवहन विलंबता के साथ टीएलएस / एसएसएल के बराबर, और भीड़ से बचने के लिए प्रत्येक दिशा में बैंडविड्थ का अनुमान। QUIC का मुख्य लक्ष्य वर्तमान में टीसीपी का उपयोग करके कनेक्शन-उन्मुख वेब अनुप्रयोगों का अनुकूलन करना है।


4

यदि आप एक एमपी 3 या वीडियो स्ट्रीम कर रहे हैं, जो जरूरी नहीं कि HTTP पर हो सकता है, वास्तव में अगर मैं ऐसा होता तो मैं आश्चर्यचकित हो जाता। यह शायद टीसीपी पर एक और प्रोटोकॉल होगा, लेकिन मुझे कोई कारण नहीं दिखता कि आप यूडीपी पर स्ट्रीम क्यों नहीं कर सकते।

यदि आपको यह ध्यान रखना है कि इस बात की कोई निश्चितता नहीं है कि आपका डेटा दूसरे छोर पर पहुंच जाएगा, लेकिन मैं इसे ले सकता हूं जिसे आप यूडीपी के बारे में जानते हैं।

आपको सवाल का जवाब देने के लिए, नहीं, HTTP यूडीपी का उपयोग नहीं करता है। यद्यपि आप किस बारे में बात करते हैं, एमपी 3 / वीडियो स्ट्रीमिंग COULD UDP पर होता है और मेरी राय में HTTP पर कभी नहीं होना चाहिए।


1
HTTP पर "स्ट्रीमिंग" को आम तौर पर कहा जाता है (जिसे मैं सबसे सटीक मानता हूं) "छद्म स्ट्रीमिंग" - HTTP पर डेटा की एक विनियमित बिट दर। जैसा कि हमारी दुनिया में बहुत अधिक है, विपणन प्रकारों ने नामकरण को दुर्व्यवहारों के लिए खुद को समझने जैसे विवरण-उन्मुख लोगों को छोड़ दिया है।
स्टु थॉम्पसन

4

सिद्धांत रूप में हां http के लिए UDP का उपयोग करना संभव है लेकिन यह समस्याग्रस्त हो सकता है। उदाहरण के लिए कहें तो आपके एमपी 3 या वीडियो को स्ट्रीम किया जा रहा है, ऑर्डर करने में समस्या होगी और कुछ बिट्स गायब हो सकते हैं क्योंकि यूडीपी कनेक्शन उन्मुख नहीं है, कोई रिट्रांसमिट तंत्र नहीं है।


1
अच्छी तरह से उल्लेख किया है UDP is not connection oriented there is no retransmit mechanism:।
ivanleoncz

4

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

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

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


3

जवाब: हां

कारण: OSI मॉडल देखें।

explaination:

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


1
आप उस स्तर पर अधिक जानकारी के बिना टीसीपी को हाथ से नहीं हरा सकते।
यहोशू

1
"UDP का उपयोग TCP पर किया जा सकता है"। वे दोनों परिवहन परत प्रोटोकॉल हैं, इसलिए यह एक या दूसरे है।
opyate


2

udp पर http का उपयोग कुछ धार ट्रैकर कार्यान्वयन (और सभी मुख्य ग्राहकों द्वारा समर्थन) द्वारा किया जाता है


4
कृपया अपने बयानों का समर्थन करने के लिए संदर्भ शामिल करें।
मैक्स लेसके

1
जैसा कि मैंने इसे पढ़ा, टोरेंट यूडीपी ट्रैकर प्रोटोकॉल द्विआधारी है, और बिल्कुल HTTP की तरह स्वरूपित नहीं है। xbtt.sourceforge.net/udp_tracker_protocol.html
जेसी चिशोल्म

2

(यह एक पुराना प्रश्न है, लेकिन यह एक अद्यतन जवाब के योग्य है।)

सभी संभावना में , HTTP / 3 QUIC प्रोटोकॉल का उपयोग किया जाएगा , जिसे इस प्रकार वर्णित किया गया है

UDP पर बहुस्तरीय परिवहन

इसलिए, एक निश्चित दृष्टिकोण से , आप कह सकते हैं कि HTTP / 3 यूडीपी का उपयोग करेगा।


1

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

यहां तक ​​कि स्ट्रीम विलंब टीसीपी से कम है। ऐसा इसलिए है क्योंकि टीसीपी (एक अधिक सुरक्षित प्रोटोकॉल के रूप में) लापता पैकेजों की मांग करता है, जो मौजूदा लोगों को अधिलेखित करता है।

तो टीसीपी एक प्रोटोकॉल है जिसे स्ट्रीमिंग के लिए उपयोग करने के लिए बहुत उन्नत है।


3
यह सवाल का जवाब नहीं देता है, हालांकि यह एक जवाब के लिए तर्क हो सकता है।
हैकेन

2
पुन: "स्ट्रीमिंग के लिए सर्वश्रेष्ठ प्रोटोकॉल" दिया गया है कि "व्यक्तिगत डेटा की गति" यह "सभी डेटा के माध्यम से प्राप्त करने" से अधिक महत्वपूर्ण है। यदि आपकी स्ट्रीम आसानी से गुम चनों से नहीं उबर पाती है, तो आप बेहतर तरीके से टीसीपी के साथ जा सकते हैं। कई सुरक्षा वीडियो प्रोटोकॉल उस कारण से टीसीपी चुनते हैं - विश्वसनीयता कच्ची गति से अधिक महत्वपूर्ण है।
जेसी चिशोल्म
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.