अगर TCP या UDP का उपयोग न करें तो क्या होगा?

• नेटवर्क इंफ्रास्ट्रक्चर switch, bridge, router, load balancer, firewall आदि से बना होता है
• operating system packets को classify करता है, queue में रखता है, firewall rules लागू करता है, आदि के ज़रिए network communication को नियंत्रित करता है
• तो अगर मौजूद ही नहीं करने वाला transport layer protocol इस्तेमाल किया जाए, तो क्या होगा?
• क्या OS इसकी अनुमति देगा? क्या packets सच में पहुँचेंगे? क्या firewall इन्हें block करेगा?
• इसे सीधे experiment करके जाँचा गया

इंटरनेट प्रोटोकॉल का अवलोकन

• इंटरनेट कई protocol layers के ज़रिए data transfer करने के तरीके से काम करता है
• जब application request भेजती है, तो OS उसे कई network layer headers में लपेटकर transmit करता है
• Transport Layer: यहाँ TCP(6), UDP(17) जैसे protocols होते हैं
• अगर IP header के Protocol field को बदलकर उसमें अनुपयोगी number डाल दिया जाए, तो क्या होगा?

प्रयोग #1: अपने PC पर सीधे टेस्ट

प्रयोग की विधि

1. HDP (नकली protocol) परिभाषित करना: मौजूदा protocols से पूरी तरह अलग एक नया transport layer protocol design करना
2. server और client implement करना: packets भेजने और पाने वाला program बनाना
3. loopback टेस्ट: देखना कि OS packets को internally कैसे handle करता है

चलाने की प्रक्रिया

$ sudo cargo run --bin server  # 서버 실행  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # 클라이언트 실행  

परिणाम

• OS ने HDP packets को सामान्य रूप से process किया और वे loopback interface के ज़रिए फिर से receive हुए
• IP protocol number बदलकर अतिरिक्त tests किए गए
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → server पर detect नहीं हुआ
  • 50, 51 (IPSec से जुड़े protocols) → client पर transmission ही block हो गया
  • 256 (IP protocol number range से बाहर) → socket() call चरण में error हुआ

कारण विश्लेषण

• कुछ protocol numbers को OS system level पर reserve करके block करता है
• Darwin (BSD-आधारित macOS) में socket() call के समय protocol=0 सेट करने पर कुछ packets अपने-आप filter हो जाते हैं
• IPSec से जुड़े protocols सुरक्षा कारणों से block किए जाने की संभावना ज़्यादा है
• IPv4 protocol number 8-bit का होता है, इसलिए केवल 0~255 तक ही valid है

प्रयोग #2: इंटरनेट पर packet transmission

प्रयोग योजना

1. DigitalOcean VPS सेटअप: जर्मनी के Frankfurt में मौजूद cloud server पर test environment बनाना
2. HDP packets भेजना: मेरे PC (Saudi Arabia) से DigitalOcean server तक packets भेजना
3. network devices की प्रतिक्रिया का विश्लेषण: देखना कि packets पहुँचते हैं या firewall उन्हें block करता है

अपेक्षित परिणाम

• HDP packets सामान्य रूप से पहुँच सकते हैं, या कुछ ISP या DigitalOcean का firewall उन्हें block कर सकता है

वास्तविक परिणाम

• केवल पहला packet पहुँचा, उसके बाद के packets block हो गए
• tcpdump से जाँचने पर:
  • मेरे PC से packets सामान्य रूप से transmit हुए
  • DigitalOcean server पर केवल पहला packet detect हुआ
  • उसके बाद के packets कहीं न कहीं block हो गए (NAT, firewall, ISP आदि)

कारण विश्लेषण

• DigitalOcean non-standard IP protocols को support नहीं करता
• cloud provider की firewall policy इसका मुख्य कारण होने की संभावना है
• सिर्फ पहला packet ही क्यों पहुँचा, यह स्पष्ट नहीं है

AWS पर दोबारा प्रयोग

• AWS पर दो instances का उपयोग करके experiment फिर से किया गया
• एक ही data center के भीतर HDP packets सामान्य रूप से भेजे और पाए गए
• लेकिन इंटरनेट के ज़रिए transmit करने पर DigitalOcean जैसी ही सिर्फ पहला packet पहुँचने की समस्या हुई

मुख्य मुद्दे

• NAT (Network Address Translation): यह TCP/UDP ports के आधार पर काम करता है, इसलिए HDP जैसे नए protocol को संभालने का कोई तरीका नहीं है
• firewall/network filtering: ज़्यादातर ISP और cloud providers अनधिकृत IP protocols को block करते हैं
• network devices की optimization समस्या: कुछ network devices non-standard packets को बिना शर्त drop कर सकते हैं

निष्कर्ष: TCP और UDP का उपयोग करना सबसे अच्छा है

• अलग-अलग OS में network stack का implementation अलग होता है
  • Linux, macOS, Windows में socket() का व्यवहार एक-दूसरे से अलग है
• firewall और NAT devices non-standard protocols को block करते हैं
  • निजी network में यह काम कर भी जाए, तो इंटरनेट पर यह लगभग असंभव है
• performance improvement का कोई लाभ नहीं
  • UDP-आधारित QUIC जैसे पहले से verified alternatives मौजूद हैं
• TCP/UDP का उपयोग करें
  • standard protocols इस्तेमाल करने पर port-based NAT, firewall, routing आदि अपने-आप support हो जाते हैं

अतिरिक्त सामग्री

• UDP protocol specification
• IP protocol numbers की सूची
• Raw sockets में platform के अनुसार अंतर

[junhochoi]

https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ भी पढ़ें, इससे मदद मिल सकती है.

[secret3056]

पुराने StarCraft में जब Hamachi के साथ मल्टीप्लेयर खेलते थे, तब IPX होता था, और मुझे याद है कि उस समय मैं सच में सोचता था कि यह आखिर क्या है।

[secret3056]

सोचने पर लगता है कि NAT सब कुछ रोक देगा... अगर IPv6 पूरी तरह स्थापित हो जाए और NAT खत्म हो जाए (हालाँकि ऐसा होने की संभावना नहीं लगती), तो अपने बनाए हुए प्रोटोकॉल से communication करना भी संभव हो सकता है।

[tujuc]

ओहो, अच्छा प्रयास है...
नेटवर्क की बुनियाद को हिलाने वाली कोशिश अच्छी थी, लेकिन इस दुनिया के सारे नेटवर्क डिवाइस सिर्फ TCP/UDP के लिए ही optimized हैं...

जब तक यह पता नहीं होता कि नेटवर्क डिवाइस ढांचे में ढले हुए उत्पाद हैं... तब तक शायद यह संभव लग सकता है... लेकिन एक बार समझ में आ जाए, तो पता चलता है कि या तो आप इतने सफल हों कि सब लोग आपका protocol इस्तेमाल करने लगें, नहीं तो यह करना मुमकिन नहीं है...

[GN⁺]

Hacker News राय

• SCTP है, जो TCP से बेहतर लेकिन अपनाया न गया एक पुराना protocol है
  • क्योंकि network hardware ने TCP और UDP के अलावा बाकी सब कुछ block कर दिया था
• विभिन्न transport protocols implement कर चुके व्यक्ति के रूप में, IP के ऊपर layer बनाने में सबसे बड़ी रुकावट WAN router नहीं बल्कि consumer NAT devices हैं
  • कुछ Netgear routers में traffic आखिर तक बचा रहता था, लेकिन एक खास तरह की corruption होती थी जिसमें पहले 4 bytes 0 में बदल जाते थे
  • शक है कि इसे TCP/UDP की तरह handle किया गया, लेकिन इसने असली translation path follow नहीं किया
• अगर TCP या UDP का उपयोग न करें तो communication मुश्किल होगा
  • internet TCP और UDP को standard मानता है
  • बहुत से devices दूसरे protocols को handle नहीं कर सकते
  • internet hardware को पूरी तरह बदलने में IPv4 को phase out करने से भी ज्यादा समय लगेगा
  • नया protocol तभी support होगा जब उसका फायदा इतना बड़ा हो कि सभी कंपनियाँ और सरकारें भारी लागत लगाकर support implement करें
• लेख का अंत cliffhanger जैसा लगता है
  • जिज्ञासा है कि custom protocol का सिर्फ एक packet ही क्यों गुजर पाया और बाकी drop हो गए
• मैंने सोचा था कि TCP/UDP packets OS network stack द्वारा केवल उन processes को भेजे जाते हैं जो किसी specific port को listen कर रहे हों
  • यह एक security feature हो सकता है, और बिना अधिकार वाला process कुछ ports को listen नहीं कर सकता
  • उम्मीद नहीं थी कि कोई दूसरा process सारा traffic capture कर सकेगा
  • यह नहीं पता था कि कई transport layer protocols का traffic capture किया जा सकता है या नहीं
  • शायद उस system call के लिए high privilege चाहिए होगा
• अगर internet protocols और routing equipment आज पहली बार शुरू से design किए जाते, तो वे कैसे होते, यह सोचने लायक है
  • कहीं बड़े packets और UDP-style base protocol ने HTTP की जगह ली होती
  • एक simple streaming protocol ने TCP की जगह लेकर video playback support किया होता
  • ये दोनों protocols अधिकांश traffic को ज्यादा efficiently handle करते
• यह "अगर हम पहिया फिर से आविष्कार करें तो क्या होगा?" जैसी कल्पना है
• packet socket की जरूरत होगी
  • IP network को सब कुछ forward करना चाहिए, लेकिन NAT मुख्य समस्या है
  • इसे IPv6 पर आज़माना दिलचस्प होगा
• TCP/UDP/IP के सब पर हावी होने से पहले के दूसरे protocols का उपयोग किया गया होता
• सब UUCP का उपयोग कर रहे होते
  • इसने TCP/UDP से पहले मिलते-जुलते काम किए थे