Show HN: कंप्यूटर मेरे सर्वर तक कैसे पहुँचा?
(how-did-i-get-here.net)- जब कोई विज़िटर वेबसाइट खोलता है, तो सर्वर public IP को target करके traceroute चलाता है और राउटर व नेटवर्क्स से होकर पैकेट जिस रास्ते से जाते हैं, उसे real-time text की तरह दिखाता है
- इसका अपना टूल ktr ICMP पैकेट्स के TTL मान को धीरे-धीरे बढ़ाते हुए हर hop के error responses इकट्ठा करता है, और साथ ही hop-दर-hop network जानकारी भी lookup करता है
- स्क्रीन अपडेट JavaScript से नहीं, बल्कि खुले HTTP response में लगातार HTML और CSS stream करके किए जाते हैं, इसलिए page load होने के दौरान नतीजे धीरे-धीरे दिखाई देते हैं
- दिखाई गई route वास्तव में सर्वर से विज़िटर के IP तक भेजे गए reverse traceroute को उलटकर दिखाती है, इसलिए bidirectional routing differences की वजह से यह असली route से पूरी तरह मेल नहीं भी खा सकती
- इंटरनेट routes BGP peering और routing table propagation के जरिए autonomous systems (AS) के बीच बनते हैं, और traffic आपस में जुड़े नेटवर्क्स के रास्ते चलता है
हर कनेक्शन पर बनता personalized traceroute
- पेज के ऊपर दिखने वाला हरा text कोई पहले से सेव किया गया example नहीं है, बल्कि वेबसाइट load होते समय विज़िटर के लिए तुरंत बनाया गया traceroute है
- traceroute उस यात्रा को दिखाता है जिसमें विज़िटर का कंप्यूटर या उसका पैकेट इंटरनेट के जरिए इस वेबसाइट को host करने वाले सर्वर तक पहुँचता है
- example route विज़िटर के router से शुरू होकर ISP network से गुजरती है, फिर कई नेटवर्क्स पार करके Hetzner के internal network में प्रवेश करती है और अंत में सर्वर तक पहुँचती है
- पहला router ping का जवाब न दे, यह संभव है; public router या VPN के पीछे होने पर यह आम बात है
- बीच में
(no response)दिख सकता है, और सभी सर्वर हमेशा जवाब नहीं देते
core3.sto.hetzner.comजैसे नाम traceroute से मिले IP213.239.252.74पर reverse DNS lookup चलाकर उसे इंसानों के लिए पढ़ने योग्य नाम में बदलने का नतीजा हैं- reverse DNS names आम तौर पर debugging आसान बनाने के लिए होते हैं, और कई बार वे वापस उसी original IP पर map नहीं होते
ktr और ICMP-आधारित traceroute
- वेबसाइट के implementation में इसका अपना traceroute प्रोग्राम ktr इस्तेमाल हुआ है
- साइट का source code भी GitHub पर public है
- ktr results को real-time में stream करता है और हर hop की जानकारी एक साथ lookup करता है
- इंटरनेट routing में पैकेट को process करने वाला कंप्यूटर या router अगला forwarding device चुनता है, और यह process तब तक चलता रहता है जब तक पैकेट ऐसे router तक न पहुँच जाए जो destination को सीधे भेज सके
- ktr का implementation ICMP इस्तेमाल करता है
- ICMP इंटरनेट पर diagnostic जानकारी भेजने के लिए बना protocol है
- लगभग सभी internet-connected devices ICMP को support करते हैं
- ICMP packets का TTL(time to live) field असली समय नहीं, बल्कि countdown value है
- हर बार जब कोई router ICMP packet forward करता है, तो उसे TTL को 1 कम करना होता है
- TTL 0 होने पर router packet को आगे भेजना रोक देता है और original source IP को maximum hop count पहुँचने का error message भेजता है
- traceroute TTL को 1, 2, 3 की तरह बढ़ाते हुए ICMP packets भेजता है और हर hop से लौटने वाले error responses इकट्ठा करता है
- error packets में diagnostic जानकारी होती है, जैसे error भेजने वाले device का IP address
- इससे इंटरनेट के पार पैकेट के लगभग route को trace किया जा सकता है
JavaScript के बिना भी real-time जैसा दिखने वाला स्क्रीन
- यह page JavaScript disabled होने पर भी काम करता है
- browser के नज़रिए से वेबसाइट बस धीरे-धीरे load होती हुई दिखती है
- user को traceroute real-time में आता हुआ महसूस होता है
- कनेक्ट होने पर सर्वर विज़िटर के IP address से आया HTTP request लेता है और तुरंत उसी IP के लिए traceroute चलाता है
- सर्वर पहले HTTP response का शुरुआती हिस्सा भेजता है और फिर connection खुला रखता है
- ktr traceroute updates सर्वर तक भेजता है
- सर्वर संबंधित HTML render करके विज़िटर के कंप्यूटर तक भेजता है
- traceroute खत्म होने पर बाकी text और वेबसाइट content भेजकर connection बंद कर देता है
- traceroute lines नीचे नहीं बल्कि ऊपर की तरफ धीरे-धीरे update होती हुई क्यों दिखती हैं, इसका कारण CSS block insertion है
- webpage मूल रूप से केवल आगे की दिशा में load हो सकता है
- हर बार traceroute display update करते समय, सर्वर पिछले display को छिपाने वाला CSS भी साथ inject करता है
- browser loading के दौरान CSS render करता है, इसलिए स्क्रीन समय के साथ edit होती हुई लगती है
reverse traceroute की सीमाएँ
- page जो route दिखाता है, वह “विज़िटर के packets सर्वर तक किस रास्ते से पहुँचे” उससे पूरी तरह समान नहीं है
- असली route निकालने के लिए विज़िटर के कंप्यूटर से सर्वर तक traceroute चलाना ज़रूरी होगा
- implementation सर्वर से विज़िटर के कंप्यूटर तक traceroute चलाती है, फिर उसके result को उलटकर दिखाती है
- इसी वजह से ऊपर वाला traceroute उल्टे क्रम में load होता हुआ दिखता है
- reverse traceroute कुछ accuracy की कीमत पर आता है
- पैकेट अगर उलटी दिशा में जाएँ, तो हर device अलग routing decisions ले सकता है
- एक device का अलग decision भी आगे का पूरा route बदल सकता है
- फिर भी route मोटे तौर पर मिलती-जुलती होती है, और फर्क अक्सर सिर्फ इस स्तर का होता है कि कौन-सा particular router packet देखता है
autonomous systems और WHOIS lookup
- traceroute में दिखने वाले “networks” से मतलब autonomous systems (AS) है
- AS आपस में privately connected routers और servers का समूह होता है
- आम तौर पर उसका मालिक एक ही company होती है
- AS owner किन दूसरे AS से जुड़ना है, यह चुनकर इंटरनेट का shape तय करते हैं
- internet traffic उन्हीं AS से होकर गुजरता है जिनके बीच peering agreements होते हैं
- इंटरनेट खुला नेटवर्क लगता है, लेकिन वास्तव में यह कंपनियों के स्वामित्व वाले नेटवर्क्स का network है, जहाँ access और control financial deals और bureaucratic processes से प्रभावित होते हैं
- अगर आप अपना autonomous system चाहते हैं, तो पाँच Regional Internet Registries (RIR) में से किसी एक के पास ASN के लिए apply कर सकते हैं
- लेकिन कंपनी का backing न हो या पर्याप्त internet interconnection points न हों, तो approval मिलना कठिन हो सकता है
- traceroute में दिखने वाला
AS4766जैसा नंबर ही ASN है
- ktr हर hop IP के owner AS की जानकारी पाने के लिए WHOIS protocol इस्तेमाल करता है
- कई organizations यह track करती हैं कि कौन-सा AS किन IP addresses को शामिल करता है
- बहुत-सी organizations WHOIS के जरिए ASN lookup देती हैं
- company जानकारी पहचानने के लिए PeeringDB का भी उपयोग होता है
- PeeringDB के पास कुल autonomous systems में से लगभग 1/3 की जानकारी है
- lookup results और सैकड़ों lines के if statements को मिलाकर network transit explanation बनाई जाती है
- WHOIS protocol specification लगभग कोई सख्त structure तय नहीं करती
- बस इतना तय है कि TCP connection बनाओ, query भेजो, server जानकारी लौटाए और फिर connection बंद कर दे
- वास्तविक WHOIS response structure server admins की conventions पर ज़्यादा निर्भर करती है, और ज़रूरी field names भी
origin,originasजैसे अलग-अलग हो सकते हैं - ktr का parser किसी strict parser से ज़्यादा उस इंसान जैसा है जो WHOIS result पढ़कर ज़रूरी ASN ढूँढ़ लेता है
BGP इंटरनेट route कैसे बनाता है
- network boundary पर मौजूद routers तय करते हैं कि packets को अगला किस network में भेजना है, और यही process तब तक चलता है जब तक वे destination device वाले network तक न पहुँच जाएँ
- ऐसे boundary routers Border Gateway Protocol(BGP) के जरिए एक-दूसरे से reachable networks की जानकारी साझा करते हैं
- BGP वही protocol है जो इंटरनेट का shape बनाता है
- आम users सीधे BGP से बात नहीं कर सकते
- BGP का शुरुआती version 1989 में Cisco और IBM engineers द्वारा प्रकाशित RFC 1105 में वर्णित है
- 1969 के ARPANET prototype में messages आंशिक रूप से transmit हुए थे, और उसके बाद कई universities, government agencies और companies ने अपने-अपने networks बनाकर उन्हें आपस में जोड़ना शुरू किया
- 1990 में BGP v2 आया
- 1994 में BGP v4 को RFC 1654 के रूप में निर्दिष्ट किया गया
- BGP v4 को 1995 और 2006 में revisions और patches मिले, और आज के इंटरनेट में inter-network route selection के लिए अब भी यही इस्तेमाल होता है
BGP routes, peering, और routing tables
- autonomous system boundary पर मौजूद router, यानी border gateway, अपने ज्ञात सभी BGP routes की सूची रखने वाली routing table बनाए रखता है
- हर BGP route उस ASN path को निर्दिष्ट करती है जिसे follow करके किसी खास IP address set को control करने वाले AS तक पहुँचा जा सकता है
- BGP routes ASes के बीच peering relationships से बनती हैं
- जब दो AS के border gateways peer करते हैं, तो उन दोनों routers के बीच traffic जा सकता है
- वे अपने ज्ञात BGP route information को updated रखते हुए साझा करते हैं
- उदाहरण के लिए, अगर AS0001 का Router A और AS0002 का Router B physically connected होकर peering करना चाहते हैं, तो वे BGP messages exchange करके BGP session स्थापित करते हैं
- Router A को पता चलता है कि AS0002 से शुरू होने वाले BGP routes तक Router B के जरिए पहुँचना है
- Router B को भी विपरीत दिशा की जानकारी मिल जाती है
- peers route advertisement प्रक्रिया के जरिए अपने ज्ञात routes साझा करते हैं
- अगर Router A, Router B को अपने सभी ज्ञात routes बताता है, तो Router B routing table में AS0001 से शुरू होने वाले routes जोड़ देता है
- और अगर Router A का कोई दूसरा peer नया route advertise करता है, तो Router A उसे Router B तक भी पहुँचा देता है
- यह advertisement पूरे AS network में फैलते हुए हर border gateway को इंटरनेट पर किसी भी IP तक पहुँचने के एक या अधिक AS paths के बारे में बता देती है
- जब router किसी खास IP को packet भेजता है, तो वह routing table में उस IP को control करने वाले AS तक जाने वाला route ढूँढ़ता है
- उसके बाद कई heuristics के आधार पर “सबसे अच्छा” route चुना जाता है
- heuristics में shortest path selection और कुछ खास AS के लिए hardcoded preference या non-preference शामिल हो सकते हैं
- फिर router चुने गए route के पहले AS के साथ peered gateway router को packet भेज देता है
traceroute results को BGP नज़रिए से पढ़ना
- example traceroute का AS path AS4766 → AS201011 → AS24940 है
- किसी बिंदु पर packet AS4766 के किसी router तक पहुँचा, और वह router AS201011 के किसी router के साथ peered था
- router ने routing table में यह तय किया कि destination IP, AS201011 से शुरू होने वाले route के जरिए reachable है
- फिर packet को connected AS201011 router की तरफ भेज दिया गया
- एक ही ASN के अंदर भी कई hops दिख सकते हैं
- जैसे Hetzner Online के भीतर दिखने वाले छह hops; traceroute सिर्फ AS boundary routers ही नहीं, बल्कि packet जिन सभी routers से गुजरा, उन्हें दिखाता है
- AS के अंदर के routers, अगर उन्हें efficient internal route पता हो, तो वे external BGP route की बजाय internal route को प्राथमिकता दे सकते हैं
- internal routes internal BGP, किसी दूसरे internal routing protocol, या hardcoding से सीखे जा सकते हैं
- इंटरनेट की reachability तय करने वाली असली चीज़ internal hops नहीं, बल्कि अलग-अलग ASes के बीच के peering agreements हैं
1 टिप्पणियां
Hacker News की राय
नमस्ते, मैं Lexi हूँ। मैं 17 साल की हूँ, और इन दिनों मेरी दिलचस्पी कंप्यूटर कैसे काम करते हैं इसे और गहराई से समझने और उसे नए तरीके से दिखाने में है
कुछ महीने पहले मैंने https://cpu.land सार्वजनिक किया था, और उससे जुड़ी चर्चा https://news.ycombinator.com/item?id=37062422 पर है
cpu.land के बाद एक और बहुत बड़ा नतीजा/प्रोजेक्ट बनाने का दबाव काफी था, लेकिन कोई आइडिया खास आकर्षक नहीं लग रहा था। इसलिए मैं तरह-तरह के personal projects आज़मा रही थी, और इसी दौरान इंटरनेट कैसे काम करता है यह संयोग से सीखते हुए मैंने शुरुआत से एक traceroute प्रोग्राम बना दिया, जो वेबसाइट पर real-time में stream होता है
मैंने वेब पर इस तरह की चीज़ पहले नहीं देखी थी, और मुझे लगा कि यह इंटरनेट के ढांचे को visualize करने का काफी नया और शानदार तरीका है, इसलिए मैंने इसे polish करके एक सुंदर साइट बना दिया
इस प्रक्रिया में मैंने BGP और इंटरनेट के ढांचे के बारे में कई दिलचस्प बातें सीखीं, इसलिए traceroute tool और उस ज्ञान को साझा करने वाला लेख—दोनों को साथ जोड़ दिया
मैं अभी भी इसे लगातार सुधार रही हूँ और code कहीं न कहीं ज़रूर टूटेगा, इसलिए अगर आपके पास सुझाव हों तो बताइए
और हाँ, Rust क्यों—क्योंकि मुझे नहीं लगता कि programming language चुनना बहुत निर्णायक है, लेकिन मैं जल्दी से एक भरोसेमंद low-level program लिखना चाहती थी और Rust के error-handling primitives मुझे पसंद आए
करीब 30 साल पहले मैंने जो पहले CGI programs बनाए थे, उनमें से एक Perl script थी जो traceroute को wrap करती थी और server push के ज़रिये results stream करती थी
पुरानी चीज़ें फिर से नई हो जाती हैं, लेकिन फिर भी साइट की प्रस्तुति बहुत अच्छी है
संदर्भ के लिए, IPv4 TTL कानूनी/औपचारिक रूप से seconds में होता है, लेकिन कोई भी router 1 second से ज़्यादा नहीं खाता और minimum decrement 1 है, इसलिए व्यवहार में इसे hop count की तरह इस्तेमाल किया जाता है। जो middlebox छिपे रहना चाहते हैं, वे कभी-कभी इसे घटाते ही नहीं
साथ ही Linux/Unix traceroute डिफ़ॉल्ट रूप से probe packets के लिए ICMP के बजाय high-numbered, आम तौर पर closed port पर जाने वाला UDP इस्तेमाल करता है, क्योंकि ऐतिहासिक रूप से UDP के ICMP की तुलना में drop या filter होने की संभावना कम थी
traceroute कैसे काम करता है, यह पूछना interview questions में से एक है, लेकिन ज़्यादातर लोग नहीं जानते; और जान भी लें तो सवाल की उपयोगिता कम हो जाती है। TCP/IP के बारे में चाहे कितने भी सवाल पूछ लें, कई लोग first principles से inference नहीं कर पाते, और फिर भी क्या वे इसे solve कर सकते हैं—मेरे हिसाब से यह एक reasonable problem-solving question है
उदाहरण: https://www.bgplookingglass.com/
https://www.oreilly.com/openbook/cgi/ch06_06.html
सोच रहा हूँ कि ICMP के बजाय TCP या UDP इस्तेमाल करने से क्या ज़्यादा accurate results मिल सकते हैं। पारंपरिक traceroute में भी UDP option होता है, mtr [1] TCP या UDP इस्तेमाल कर सकता है, और tcptraceroute [2] TCP इस्तेमाल कर सकता है
और इसमें Talking Heads का quote डालना बिल्कुल फिट बैठेगा: “And you may ask yourself, well, how did I get here?” [3]
[1] https://github.com/traviscross/mtr
[2] https://linux.die.net/man/1/tcptraceroute
[3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
अब बस यह पता चल जाए कि किसी खास workstation से कंपनी के Cisco access switch, core switch, AWS transit gateway तक जाने वाली BGP tunnel से होकर EC2 instance की VPC routing table तक पहुँचने तक हर hop पर traceroute कैसे चलवाना है, तो शायद नेटवर्क वाला कहलाया जा सकेगा
अफ़सोस, बहुत सारे nodes traceroute packets ignore कर देते हैं, इसलिए बस ऐसा दिखा कि मेरा exit node Linode से जुड़ता है और Linode तुम्हारे computer से जुड़ता है
forward traceroute में भी कुछ ऐसा ही है: router respond करता है, server respond करता है, और किस्मत अच्छी हो तो ISP network का शायद एक node दिख जाता है। बाकी सब मजबूती से बंद है
कहा गया कि “BGP वह protocol है जो इंटरनेट को आकार देता है, और आप उससे सीधे बात नहीं कर सकते,” लेकिन असल में किसी व्यक्ति के लिए ASN हासिल करना और BGP बोलना चौंकाने लायक आसान है
अगर ऐसे tools बनाना दिलचस्प लगता है, तो इसे एक बार आज़माने लायक है। रुचि हो तो मैंने पहले एक introductory लेख लिखा था: https://qt.ax/asn
यह “मेरा computer तुम्हारे server तक कैसे पहुँचता है” से ज़्यादा तुम्हारा server मेरे computer तक कैसे पहुँचता है, उसके उल्टे रास्ते जैसा है। दोनों दिशाओं की routing ज़्यादातर मामलों में काफी अलग हो सकती है
संक्षेप में, मेरे अनुभव में जिन networks से रास्ता गुजरता है वे आम तौर पर बहुत मिलते-जुलते थे, और किसी भी दिशा में content relevant और दिलचस्प है
traceroute कैसे काम करता है, इससे जुड़ा एक दिलचस्प पेपर है। नेटवर्किंग से बाहर के लोग अक्सर जिस बात को मिस कर देते हैं, वह यह है कि traceroute ज़रूरी नहीं कि symmetric हो। return path अलग हो सकता है
https://archive.nanog.org/sites/default/files/traceroute-201...
यह अब तक इंटरनेट पर देखे गए ECMP count का लगभग दोगुना कहा जा सकता है
और Cairo office से UK core तक जाने वाला traffic और उल्टी दिशा का traffic भी अलग-अलग routes ले रहा है। London→Cairo direct है और अभी भी भारी loss है, लेकिन Cairo→London अब ntt के ज़रिए जा रहा है और ठीक दिख रहा है। अगर कल तक ठीक नहीं हुआ तो local preference बदलनी पड़ सकती है
कहा गया कि “WHOIS parser बनाने के लिए एक दिलचस्प protocol है”, लेकिन असल में यह लगभग असंभव है
response मूल रूप से free-form होता है, और server response न भी दे सकता है। मैंने भी कोशिश की थी; 10 साल पहले के हिसाब से addresses या domains के 90% पर काम करने वाला ad-hoc parser बना पाया था, लेकिन बाकी को handle करना नामुमकिन था
आजकल यह और खराब हो गया है, और लगभग सब कुछ privacy shield के पीछे छिपा है। दावा है कि इससे PII की रक्षा होती है, लेकिन WHOIS records मूल रूप से personal information रखने के लिए नहीं, बल्कि network operator contact details रखने के लिए बने थे
मुझे लगता है यह ICANN की गलती है। ICANN के पास नियम था कि networks को public WHOIS server देना होगा, लेकिन उसने उसे enforce नहीं किया, और अब वह rule हटा दिया गया है
हालांकि हर जगह RDAP server नहीं चलाती। अच्छा होगा अगर ICANN/IANA या कोई और इसे enforce करे
network operator information भी PII हो सकती है। मेरी information PII है, और मेरे पास domain name है, तो मेरी information WHOIS में डालना PII को WHOIS में डालना ही है
privacy protection service बस spam को छोड़कर बाकी सब कुछ मुझे forward कर देती है
company के लिए privacy protection service की अनुमति देने का कोई अच्छा कारण मुझे नहीं दिखता, लेकिन अभी सभी domains बड़ी कंपनियों के मालिकाना नहीं हैं
अलग ICMP ECHO tracing के बजाय, client browser और web server के बीच existing HTTP TCP connection का उपयोग करें तो एक कदम आगे जा सकते हैं
इससे client-side NAT या stateful firewall को पार किया जा सकता है
reverse traceroute पर पहले के कुछ काम मौजूद हैं
https://research.cs.washington.edu/networking/astronomy/reve...
पेपर: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
वीडियो: http://www.usenix.org/multimedia/nsdi10katz-bassett
यह भी जानने लायक है कि TCP session के packets अक्सर इंटरनेट से गुजरते समय asymmetric paths लेते हैं। मेरे अनुभव में सबसे आम कारण cost से जुड़े business rules और इंसानी गलती रहे हैं
IP कैसे काम करता है, यह सोचें तो यह अपने-आप में कोई खास समस्या नहीं है, लेकिन routing को समझना और मुश्किल हो सकता है
Boise State University और University of Idaho, Idaho state के दो छोरों पर स्थित schools हैं। उत्तर में UIdaho, Spokane के करीब है और उसकी अधिकांश connectivity Seattle से आती है, जबकि Boise, Salt Lake side के करीब है और अक्सर Portland या Salt Lake City के ज़रिए connect होता है
दोनों schools के बीच state के मध्य भाग में पहाड़ी इलाका है, इसलिए बड़े पैमाने की connectivity लगभग नहीं थी, लेकिन पहले UofIdaho के southern region में remote classrooms थे, इसलिए एक छोटी line थी
90s के आखिर में किसी समय BSU network engineer और UofI engineer को पता चला कि उनके switches और routing equipment एक ही building में हैं, तो उन्होंने दोनों के बीच Ethernet cable जोड़ दी
नतीजा disaster था। दोनों networks ने एक-दूसरे को BGP advertise करना शुरू कर दिया, और वह connection पूरे इंटरनेट पर announce हो गया। अचानक Seattle-side network और Salt Lake City-side network के बीच एक बहुत छोटा jump बन गया, और वह बेचारा छोटा T1 line पूरी तरह saturate हो गया
दिलचस्प बात यह थी कि यह सिर्फ एक direction में हुआ। Boise ने route advertise किया, लेकिन Idaho ने नहीं, इसलिए traffic असल में सिर्फ एक direction में ही खराब हुआ
जाहिर है cable निकाल दी गई, और कुछ साल बाद जब मैं UofIdaho में काम करता था, तब भी यह सबको पता था कि दोनों networks को फिर कभी connect नहीं करना चाहिए। विडंबना यह है कि उस समय मैं दोनों universities में I2 deploy करने वाला program चला रहा था
मेरे device पर मेरे device और server के बीच के intermediate hops बिल्कुल नहीं दिख रहे। reference के लिए
अभी इसी पर काम कर रहा हूं और उम्मीद है जल्द बेहतर चलेगा। इस बीच timeout बढ़ा दिया है, इसलिए loading लंबी होगी लेकिन बेहतर काम करेगा
mtr का भी ज़िक्र बनता है। मैं इसे traceroute से कहीं ज़्यादा इस्तेमाल करता हूँ
यह रुक-रुक कर होने वाले packet loss को diagnose करने में मदद करता है, और flow को औसत रूप में समझने देता है
APNIC का यह लेख mtr और उसके results को पढ़ने का तरीका ज़्यादा विस्तार से समझाता है, और यह भी कवर करता है कि MPLS असली path को कैसे धुंधला कर सकता है
https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
UDP से trace करना भी कभी-कभी उपयोगी होता है, और यह जानना भी अच्छा है कि कई routers load में होने पर ICMP को चुनिंदा तरीके से drop करते हैं
अच्छा लेख है और अभिव्यक्ति भी शानदार है