टेक्स्ट-आधारित इतने सारे इंटरनेट प्रोटोकॉल क्यों हैं?

Question

मैंने जो पाया है, उसमें बहुत अधिक मात्रा में प्रोटोकॉल जो इंटरनेट पर यात्रा करते हैं, बाइनरी के बजाय "टेक्स्ट-आधारित" हैं। विचाराधीन प्रोटोकॉल में शामिल हैं, लेकिन यह HTTP, SMTP, FTP (मुझे नहीं लगता कि यह सभी पाठ-आधारित है?), WHOIS, IRC तक सीमित हैं।

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

क्या इसके पीछे कोई कारण है? पाठ-आधारित प्रोटोकॉल में स्पष्ट रूप से एक ओवरहेड होता है क्योंकि उन्हें समान जानकारी को प्रसारित करने के लिए अधिक डेटा भेजने की आवश्यकता होती है (नीचे उदाहरण देखें)। इससे क्या फायदा होगा?

---

द्वारा पाठ आधारित , मेरा मतलब है प्रोटोकॉल में प्रयोग किया जाता पात्रों में से अधिकांश के बीच हैं 0x20(स्थान) और 0x7E( ~), कभी कभी "speical चरित्र" के लिए इस्तेमाल के साथ बहुत ही खास उद्देश्यों ऐसी नई-पंक्तियों, अशक्त, ETX, और EOT के रूप में,। यह कनेक्शन पर कच्चे, द्विआधारी डेटा को प्रसारित करने के विरोध में है।

उदाहरण के लिए, पूर्णांक 123456को पाठ के रूप में प्रसारित करने में स्ट्रिंग भेजना शामिल होगा 123456(जैसा कि हेक्स में दर्शाया गया है 31 32 33 34 35 36), जबकि 32-बिट बाइनरी मान (हेक्स में प्रतिनिधित्व) के रूप में भेजा जाएगा 0x0001E240(और जैसा कि आप देख सकते हैं, "विशेष अशक्त चरित्र" शामिल है) ।

Comments

5 उल्लिखित प्रोटोकॉल में से, HTTP, SMTP, WHOIS और IRC की मुख्य रूप से पाठ्य सामग्री के आदान-प्रदान के लिए कल्पना की गई थी।

— el.pescado

ध्यान दें कि HTTP / 2 एक बाइनरी प्रोटोकॉल है।

— isanae

आप ज्यादातर अनुप्रयोग और प्रस्तुति परत प्रोटोकॉल का जिक्र कर रहे हैं । निचले स्तर के प्रोटोकॉल (टीसीपी, आईपी, ईथरनेट) लगभग हमेशा बाइनरी होते हैं।

— निक टी

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

— केसी

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

— छद्म नाम

Answer 1

जब दुनिया छोटी थी, और कंप्यूटर सभी महिमामंडित पीसी नहीं थे, तो शब्द आकार विविध थे (एक डीईसी 2020 जो हमारे यहां था उसमें 36 बिट शब्द थे), द्विआधारी डेटा का प्रारूप एक विवादास्पद मुद्दा था (बड़ा एंडियन बनाम थोड़ा एंडियन, और यहां तक ​​कि अजीब बिट्स के आदेश यथोचित थे)। चरित्र के आकार / एन्कोडिंग (ASCII, EBCDIC के मुख्य दावेदार थे, पर हमारी सहमति बहुत कम थी, हमारे DEC में 5/6/7/8 बिट्स / चरित्र एन्कोडिंग थे)। ARPAnet (इंटरनेट पूर्ववर्ती) को किसी भी विवरण की मशीनों को जोड़ने के लिए डिज़ाइन किया गया था। सामान्य भाजक पाठ था (और अभी भी है)। आप यथोचित रूप से निश्चित हो सकते हैं कि 7-बिट एन्कोडेड टेक्स्ट डेटा को शिप करने के लिए अंतर्निहित माध्यमों से मंगाई नहीं जाएगी (काफी समय पहले तक, कुछ 8-बिट एन्कोडिंग में ईमेल भेजने से एक गारंटी मिली थी कि प्राप्तकर्ता को कटे हुए संदेश मिलेंगे,

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

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

Comments

समस्या निवारण में आसानी के साथ-साथ बहुत सुधार हुआ है। पैकेट कैप्चर पढ़ना काफी मुश्किल है, यह तब और भी बुरा होता है जब एप्लिकेशन मानव-पठनीय प्रारूप में संदेश नहीं भेजते हैं।

— जिम

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

— स्टीव जेसोप

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

— फेयरफॉक्स

मिडवेस्ट के विंटेज कंप्यूटर फेयर में, मुझे यह दिलचस्प लगा कि मोटोरोला S- रिकॉर्ड फॉर्मेट में कोड प्राप्त करने के लिए Altair 680 जैसी मशीनों की जरूरत थी, जिसमें हर 32 बाइट्स के लिए 76 अक्षर (ओवरहेड के 44 अक्षर) का इस्तेमाल होता था। यहां तक ​​कि अगर कोई 0-9 AZ + - * / = जैसे 41-वर्ण सेट का उपयोग करने के लिए सीमित था, तब भी इसे कम करना संभव है कि 57 वर्णों (ओवरहेड के 25 वर्ण) के करीब हो, जो समय को कम कर देगा ASR-33 को 4K से लगभग तीन तक 1K कोड खिलाना है। धीमी I / O गति को देखते हुए, मुझे आश्चर्य है कि ऐसी चीजें आम तौर पर क्यों नहीं लगती हैं?

— सुपरकाट

Answer 2

एक फायदा जिसे अनदेखा किया जा सकता है वह है प्रयोग करने की क्षमता । यदि आप ट्यूब के नीचे बिट्स को हिला रहे हैं, तो आपको कुछ उपयोगिता लिखने की आवश्यकता है जो कि या जैसे EHLOमें अनुवाद 0x18करता है। ऐसा करने के बजाय, आप बस एक मेल सर्वर में टेलनेट कर सकते हैं, भेज सकते हैं EHLOऔर अपने रास्ते पर हो सकते हैं।

असेंबली या ब्रेनफ़ * ck में कोड लिखने से इस दिन और आयु में कुछ भी आपको नहीं रोक रहा है , और आप ऐसा करने से कुछ बिट्स को अच्छी तरह से बचा सकते हैं। हालाँकि, यह बताना कि आपने किसी और के साथ वास्तव में क्या किया है ताकि वे समझ सकें और आपके कोड के साथ बातचीत करना आसान नहीं होगा यदि आप ऐसा करते हैं।

प्रोटोकॉल के साथ, यह महत्वपूर्ण है कि उपयोगकर्ता आसानी से सीख सकते हैं कि उनका उपयोग कैसे किया जाए, क्योंकि अधिकांश लोग दिन में वापस आ गए जो ARPAnet का उपयोग कर रहे थे या इंटरनेट की शुरुआत ऐसे लोग थे जो एक टर्मिनल के पीछे सहज महसूस करते थे।

इसी तरह के तर्क, आज कंपनियों में आयोजित किए जाते हैं। क्या हमें JSON या BSON (JSON के द्विआधारी प्रतिनिधित्व) को अनुक्रमित करना चाहिए ? यदि आप BSON को अनुक्रमित करते हैं, तो आप कुछ ओवरहेड बहाते हैं, लेकिन अब आपको अपने BSON को JSON और इसके विपरीत में रूपांतरित करने के लिए अनुवादक की आवश्यकता है, क्योंकि एक मानव को किसी बिंदु पर उस डेटा को पढ़ना होगा जब कुछ अनिवार्य रूप से गलत हो जाता है।

Comments

यदि प्रोटोकॉल को पहले से बाइनरी के रूप में डिज़ाइन किया गया था, तो टेक्स्ट प्रोटोकॉल के लिए बाइनरी शॉर्टहैंड के बजाय, आमतौर पर सहमत-टर्म शब्द भी नहीं हो सकता है EHLO। बाइनरी प्रोटोकॉल के लिए प्रत्येक मानव-प्रयोग करने योग्य दृश्य ने अपना नाम बना लिया होगा, अगर बाइनरी मानक नाम 0x18-इस-स्थिति में नहीं था।

— पीटर कॉर्ड्स

Answer 3

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

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

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

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

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

व्यक्तिगत अनुभव से, मैंने एक कंपनी बिल्डिंग राउटर के लिए काम किया है और मैंने टेलीमेट्री उपकरण बनाने वाली कंपनी के लिए भी काम किया है, इसलिए मुझे बाइनरी प्रोटोकॉल जैसे टीसीपी / आईपी, एआरपी, आईईसी 60870-5- के साथ काम करने का बहुत अनुभव मिला है। 101 और डीएनपी 3। मैंने HTTP, POP3 और NMEA जैसे टेक्स्ट प्रोटोकॉल के साथ भी काम किया है। मैंने बाइनरी डेटा फॉर्मेट जैसे ASN.1 और टेक्स्ट डेटा फॉर्मेट जैसे JSON और XML के साथ भी काम किया है। अगर मुझे चुनना होता तो मैं लगभग हर बार टेक्स्ट चुनता। केवल समय मैं बाइनरी चुनूंगा यदि प्रोटोकॉल वास्तव में निम्न-स्तर है (तो मैं बस इतना लागू करूंगा कि मैं शीर्ष पर या उस पर एक पाठ आधारित प्रोटोकॉल प्लैंक कर सकूं) या डेटा स्वाभाविक रूप से द्विआधारी है (जैसे ऑडियो फ़ाइलें) ।

Answer 4

संरचित बाइनरी में भी इसका विस्तार करने की सीमाएँ हैं। फिदनेट के साथ काम करने के मेरे दिनों और इसके और यूयूसीपी / यूएसनेट के बीच एक प्रवेश द्वार का निर्माण, फिडोनेट के संदेश हेडर एक संरचित बाइनरी थे। यहां तक ​​कि केवल एक बाइट को जोड़ने की कोशिश करने से इसका विस्तार करने का मतलब है कि वहाँ सब कुछ तोड़ना जो इसके साथ काम करने की कोशिश कर रहा है। टेक्स्ट हेडर या प्रोटोकॉल होने का मतलब है कि आप कुछ w / o ब्रेकिंग चीजों का विस्तार कर सकते हैं।

Comments

सबक सीखा: बाइनरी डेटा में एक संस्करण टैग डालें।

— पीटर -

Answer 5

आपके प्रश्न की व्याख्या तीन तरीकों से की जा सकती है:

1. पाठकीय प्रतिनिधित्व में संख्यात्मक डेटा क्यों प्रेषित किया जाता है, जैसे कि इसे उदाहरण के साथ मुद्रित किया गया था printf()?
2. क्‍लासिक एप्लिकेशन लेयर प्रोटोकॉल - जैसे कि ftp कंट्रोल चैनल, smtp, http - पारंपरिक रूप से सभी 7-बिट ASCII वर्ण सेट का उपयोग क्यों करते हैं? (7 बिट ASCII को "टेक्स्ट" माना जा सकता है क्योंकि अधिकांश बाइट्स प्रिंटेबल ग्लिफ़ या टेक्स्टलाइन कोड जैसे न्यूलाइन और फीड से मेल खाते हैं।)
3. बाइनरी डेटा के ब्लब्स को अक्सर 7 बिट एसिसी में क्यों बदल दिया जाता है जब उन्हें इंटरनेट पर भेजा जाता है, जैसे मेल अटैचमेंट?

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

दूसरे प्रश्न का उत्तर शायद यह है कि आरएफसी 206 (नोट निम्न संख्या - 1971!) टेलनेट प्रोटोकॉल का वर्णन करता है, जिस पर कई एप्लिकेशन लेयर प्रोटोकॉल आधारित होते हैं, प्रत्यक्ष टेलेटाइप प्रतिस्थापन के रूप में।

जिसका कार्य ऑनलाइन सिस्टम टर्मिनल बनाने का है, नेटवर्क में किसी भी टेले-टाइप-कम्पेटिबल, टाइम-शेयरिंग सिस्टम के रूप में प्रकट होता है जैसे कि वह सीधे उस सिस्टम से जुड़ा हो ।

(मूल पाठ में जोर।) कम से कम कुछ टेलेटाइप और विशेष रूप से टेलेटाइप नेटवर्क में 7 बिट ASCII का उपयोग चरित्र सेट के रूप में किया गया है जिसने इसे एक प्राकृतिक विकल्प बनाया होगा।

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