◈ netchecks.org

17 जाँच · बिना खाते के · सेल्फ-होस्टेड

एक क्लिक में अपने नेटवर्क की जांच करें

एक ही डैशबोर्ड में 17 मुफ़्त नेटवर्क डायग्नोस्टिक टूल्स।

सामान्य प्रश्न

0 ट्रैकर · 14 भाषाएँ · डार्क और लाइट मोड · सेल्फ-होस्टेड

← सभी लेख

Network history

From LAN to the Internet: Token Ring, Ethernet, and the Protocols That Won

Every network diagnostic in this toolkit — a ping, a traceroute, a DNS lookup — quietly depends on decisions made in engineering rooms half a century ago. Before any of it was possible, engineers first had to solve a much more basic problem: how do you get more than two computers talking on the same wire without every conversation turning into noise?

That problem produced two competing philosophies for the local area network, a standards process that still governs the Internet today, and a decade-long transition from proprietary hardware to the open, layered protocol stack every device now runs. This is that story.

  1. 1969

    ARPANET goes live

    The first four nodes (UCLA, Stanford Research Institute, UC Santa Barbara, University of Utah) are connected, the direct ancestor of the modern Internet.

  2. 1973

    Ethernet is invented

    Bob Metcalfe and David Boggs at Xerox PARC design a packet-based network over shared coaxial cable, named after the 19th-century 'luminiferous ether'.

  3. 1974

    TCP is described

    Vint Cerf and Bob Kahn publish 'A Protocol for Packet Network Intercommunication', laying out the ideas that become TCP/IP.

  4. 1980

    DIX Ethernet standard

    DEC, Intel, and Xerox jointly publish the first commercial Ethernet standard: 10 Mbps over thick coaxial cable.

  5. 1981

    IP and TCP formalized

    RFC 791 (Internet Protocol) and RFC 793 (Transmission Control Protocol) are published, still the foundation of Internet addressing and reliable delivery today.

  6. 1983

    The ARPANET flag day

    On January 1, every host on ARPANET switches from the old NCP protocol to TCP/IP overnight - the moment the modern Internet's protocol stack becomes mandatory.

  7. 1985

    IEEE 802.5 Token Ring

    IBM's deterministic, token-passing ring topology is formally standardized at 4 Mbps, later extended to 16 Mbps.

  8. 1990

    10BASE-T arrives

    IEEE 802.3i brings Ethernet onto twisted-pair cabling and RJ45 connectors, enabling cheap star-topology wiring through a central hub.

  9. 1995

    Fast Ethernet (100 Mbps)

    IEEE 802.3u standardizes 100 Mbps Ethernet, six times faster than Token Ring's ceiling - the tipping point in enterprise LAN purchasing decisions.

  10. 1999

    Gigabit Ethernet over copper

    IEEE 802.3ab delivers 1000 Mbps over the same twisted-pair cabling already installed everywhere, cementing Ethernet as the unchallenged LAN standard.

Before the LAN: one cable, one conversation

Early computer networking was built around point-to-point or multidrop links between a mainframe and its terminals - reliable, but expensive to wire and impossible to scale past a handful of devices. As offices filled with independent minicomputers and, later, personal computers, the real problem shifted: how do dozens of machines share one physical cable without their signals colliding into unreadable noise?

Two very different answers emerged in the 1970s and 1980s, and for over a decade neither one was the obvious winner.

Two philosophies: token passing vs. listen-and-retry

IBM's Token Ring, standardized as IEEE 802.5, solved the collision problem by removing the possibility of collision entirely. A single small 'token' frame circulates continuously around a logical ring; a station may only transmit when it is holding the token, guaranteeing that exactly one device speaks at a time. It is deterministic and predictable under heavy load - properties IBM's mainframe-oriented enterprise customers valued highly.

Ethernet took the opposite bet. Its CSMA/CD access method (Carrier Sense Multiple Access with Collision Detection) simply lets any station transmit whenever it believes the wire is idle, and listens for a collision; if one occurs, both senders back off for a random interval and retry. It is probabilistic rather than guaranteed, but radically simpler and cheaper to implement in hardware - and under the light-to-moderate traffic loads of a typical office, it performed just as well in practice as the more elaborate token scheme.

Token Ring's logical ring (left) passes a single token station-to-station; Ethernet's shared bus or hub-based star (right) lets any station transmit and resolves collisions after the fact.

The protocols that made packets talk

A shared cable only solves how frames move between two adjacent machines. Getting a message from a computer in Los Angeles to one in Boston, across networks owned by entirely different organizations, needed a second, independent layer of addressing and routing - which is exactly what the ARPANET research program was built to solve. Vint Cerf and Bob Kahn's 1974 paper introduced the idea of splitting that job into two protocols: IP, responsible for addressing packets and getting them from network to network, and TCP, responsible for reassembling them reliably and in order at the far end.

Both were formalized as RFC 791 and RFC 793 in September 1981, and on January 1, 1983 - a date engineers still refer to as 'flag day' - every host still connected to ARPANET was cut over from the older NCP protocol to TCP/IP simultaneously, essentially overnight. It is one of the largest coordinated protocol migrations in computing history, and it is the direct reason IP addressing and TCP's three-way handshake are still exactly how this toolkit's Ping, Traceroute, and every other tool talk to the network today.

The RFC (Request for Comments) process itself, still run by the IETF, deserves credit here too: unlike Token Ring's IBM-controlled standardization, RFCs are open documents anyone can propose, argue about in public, and implement - the process's own famous motto is 'rough consensus and running code'. That openness is a large part of why TCP/IP, rather than any of several competing proprietary networking stacks of the era (including IBM's own SNA), became the protocol every vendor eventually converged on.

The layered model that came out of this era: each layer only talks to the one directly above and below it, which is why a tool like Ping (ICMP, network layer) works identically regardless of what application layer protocol - HTTP, DNS, SMTP - runs on top of it.

Why Ethernet ultimately won

Through the mid-1980s, Token Ring and Ethernet coexisted as genuinely competing enterprise choices, with Token Ring often preferred in IBM-centric shops for its predictable behavior under load. The balance tipped decisively over the following decade for reasons that had less to do with raw technical merit and more to do with economics and pace of innovation: Ethernet's move to twisted-pair cabling with 10BASE-T in 1990 made wiring dramatically cheaper and easier than Token Ring's shielded cabling and specialized connectors, and the arrival of switching (replacing shared hubs with a dedicated point-to-point link per port, eliminating collisions altogether) removed CSMA/CD's biggest theoretical weakness.

The final blow was speed. Fast Ethernet's 100 Mbps in 1995 was already six times Token Ring's 16 Mbps ceiling, and by the time Gigabit Ethernet arrived in 1999 running over the exact same cabling already installed everywhere, there was no remaining reason to choose the more expensive, proprietary alternative. IBM itself quietly shifted its own recommendations to Ethernet during the 1990s; Token Ring survives today mostly in legacy industrial control systems, not new deployments.

सार में

The specific hardware debate is settled, but the pattern it set is still the one modern networking follows: an open, community-driven standard (Ethernet's IEEE process, TCP/IP's RFCs) tends to out-innovate a closed, vendor-controlled one over a long enough timeline, because more organizations can build on it, extend it, and drive its cost down. Every device on a modern LAN, from a laptop to an IoT sensor, still speaks the same Ethernet frame format standardized in the 1980s carrying the same IP packets standardized in 1981 - which is exactly why a tool as simple as Ping still works the same way it did forty years ago.

← सभी लेख

मेरी IP जाँच

आपका सार्वजनिक IP पता और नेटवर्क स्थान, स्वचालित रूप से पता लगाया गया।

NetChecks खोलते ही यह स्वतः लोड हो जाता है — किसी इनपुट की आवश्यकता नहीं। नेटवर्क या VPN बदलने के बाद रीफ़्रेश बटन का उपयोग करें।

आपका ब्राउज़र

ऑल-इन-वन स्कैन

एक ही पास में एक IP या होस्टनेम पर सभी प्रासंगिक जांच चलाता है: DNS, whois, ping, traceroute, सुविज्ञात पोर्ट स्कैन (1-1024), HTTP हेडर और SSL प्रमाणपत्र।

एक डोमेन या IP पता दर्ज करें और चलाएँ ताकि DNS, whois, ping, traceroute, सामान्य पोर्ट, HTTP हेडर और SSL प्रमाणपत्र एक साथ जांचे जा सकें।

अधिकांश जांचें समानांतर में चलती हैं - आमतौर पर लगभग 30 सेकंड में पूरी हो जाती हैं, यदि लक्ष्य धीमा या अनुपलब्ध है तो अधिक समय लग सकता है।

पोर्ट स्कैन चरण तभी चलता है जब ऊपर दिया गया सहमति चेकबॉक्स चेक किया गया हो - बाकी सभी जांचें वैसे भी चलती हैं।

पिंग (Ping)

किसी होस्ट की पहुंच और विलंबता जांचने के लिए ICMP echo अनुरोध भेजें।

एक होस्टनाम या IP पता दर्ज करें और ICMP इको अनुरोध भेजकर राउंड-ट्रिप विलंबता मापने के लिए Ping दबाएँ।

You Host ICMP Echo Request (type 8) ICMP Echo Reply (type 0) measures: RTT · TTL · packet loss

      

अधिक जानें: पिंग (Ping)

परिभाषा

Ping किसी होस्ट को ICMP Echo Request पैकेट भेजता है और मापता है कि ICMP Echo Reply वापस आने में कितना समय लगता है। यह सबसे बुनियादी नेटवर्क कनेक्टिविटी टेस्ट है: यह सिर्फ एक सवाल का जवाब देता है, "क्या यह मशीन पहुंच योग्य है, और कितनी जल्दी?" ICMP प्रोटोकॉल (RFC 792) को 1981 में खासतौर पर IP नेटवर्क पर कंट्रोल और डायग्नोस्टिक मैसेज ले जाने के लिए डिज़ाइन किया गया था, किसी भी एप्लिकेशन ट्रैफिक से अलग - Ping इसका सबसे जाना-पहचाना और सबसे ज़्यादा उपलब्ध implementation है, जो लगभग हर ऑपरेटिंग सिस्टम और नेटवर्क डिवाइस में शुरुआत से ही मौजूद है।

यह कैसे काम करता है

हर ICMP पैकेट में एक TTL (Time To Live) फ़ील्ड होता है जो हर राउटर से गुज़रने पर एक-एक करके घटता है; अगर टारगेट तक पहुंचने से पहले यह शून्य पर पहुंच जाए, तो पैकेट ड्रॉप कर दिया जाता है और भेजने वाले को एक एरर वापस भेजा जाता है। मिलीसेकंड में मापा गया राउंड-ट्रिप टाइम (RTT) पूरे राउंड-ट्रिप में जमा हुई कुल नेटवर्क लेटेंसी दर्शाता है, न कि सिर्फ टारगेट के पास वाले आखिरी हिस्से की - यह बात अक्सर गलत समझी जाती है, क्योंकि धीमे ping नतीजों की असली वजह रास्ते में कहीं भी हो सकती है, ज़रूरी नहीं कि टेस्ट किए जा रहे सर्वर के पास ही हो। Ping आमतौर पर एक की बजाय लगातार कई पैकेट भेजता है, जिससे एक बार की लेटेंसी स्पाइक और बार-बार होने वाली समस्या के बीच फर्क किया जा सकता है, और उस सैंपल पर पैकेट लॉस रेट भी निकाला जा सकता है।

नतीजों को समझें

एक स्थिर, कम RTT - लोकल नेटवर्क पर कुछ मिलीसेकंड, एक ही देश के भीतर किसी डेस्टिनेशन के लिए 10 से 50 मिलीसेकंड, और इंटरकॉन्टिनेंटल लिंक के लिए काफी ज़्यादा - एक स्वस्थ कनेक्शन दिखाता है। थोड़ा सा भी पैकेट लॉस (1-2% से ऊपर) VoIP या इंटरैक्टिव रिमोट सेशन जैसे लेटेंसी-सेंसिटिव इस्तेमाल के लिए खासतौर पर नुकसानदेह होता है, जहां हर ड्रॉप हुआ पैकेट किसी गड़बड़ी या सुनाई देने वाले कट के रूप में सामने आता है। एक पैकेट से दूसरे पैकेट के बीच बहुत ज़्यादा बदलती लेटेंसी (jitter) अक्सर इन्हीं इस्तेमालों के लिए ऊंची लेकिन बिल्कुल स्थिर लेटेंसी से भी बड़ी समस्या होती है। "Request timed out" का मतलब है कि तय समय में कोई जवाब नहीं आया - हो सकता है होस्ट सच में डाउन हो, फायरवॉल चुपचाप ICMP ब्लॉक कर रहा हो, या रास्ते में कहीं कोई रूट टूटा हो; "Destination unreachable" इससे अलग और ज़्यादा जानकारी देने वाला है: इसका मतलब है कि रास्ते के बीच के किसी राउटर ने साफ तौर पर बता दिया कि वह पैकेट को आगे नहीं भेज सका, जिससे समस्या की जगह पहचानने में मदद मिलती है।

आम गलतियां

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

कब उपयोग करें

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

Traceroute

किसी गंतव्य होस्ट तक नेटवर्क पथ (हॉप दर हॉप) का पता लगाएं।

एक होस्टनाम या IP पता दर्ज करें और चलाएँ ताकि इस सर्वर और गंतव्य के बीच हर नेटवर्क हॉप, प्रत्येक हॉप की विलंबता के साथ, देखा जा सके।

You TTL=1 TTL=2 TTL=3 Host each hop replies "ICMP Time Exceeded" until TTL reaches the host

      

DNS लुकअप (Nslookup)

DNS रिकॉर्ड क्वेरी करें: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA।

एक डोमेन दर्ज करें, एक रिकॉर्ड प्रकार चुनें (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, या CAA), फिर खोजें।

You Root .com Auth NS ① query root ② referral → TLD ③ referral → auth NS ④ answer

      

Whois

किसी डोमेन या IP पते की पंजीकरण जानकारी देखें।

किसी डोमेन या IP पते की पंजीकरण जानकारी देखने के लिए उसे दर्ज करें — रजिस्ट्रार, स्वामी संगठन और महत्वपूर्ण तिथियाँ।

You Registry RDAP / :43 query: domain / IP reply: registrar, dates, name servers

      

ब्लैकलिस्ट जांच

जांचें कि कोई IP पता या डोमेन सार्वजनिक स्पैम/दुरुपयोग ब्लैकलिस्ट (DNSBL) में सूचीबद्ध है या नहीं।

एक IPv4 पता या डोमेन दर्ज करें और चलाएं ताकि एक साथ 7 सार्वजनिक DNSBL/RBL ब्लैकलिस्ट जांची जा सकें - प्रत्येक को सूचीबद्ध, असूचीबद्ध या जांच विफल के रूप में दिखाया जाता है।

You zen.spamhaus.org spamcop.net sorbs.net +4 more reverse-IP DNS query to each DNSBL zone, in parallel

      

TCP पोर्ट स्कैन

जांचें कि किसी होस्ट या IP पर TCP पोर्ट खुले हैं: सामान्य पोर्ट, कस्टम सूची, या पूरी 1-65535 रेंज।

एक होस्ट या IP दर्ज करें, सामान्य पोर्ट, कस्टम सूची, या पूरी रेंज चुनें, फिर स्कैन करें कि कौन से TCP पोर्ट प्रतिक्रिया देते हैं।

You 22 open 443 open 3389 closed 8080 closed SYN → SYN-ACK = open · SYN → RST = closed

        
      

HTTP हेडर इंस्पेक्टर

किसी URL के लिए HTTP प्रतिक्रिया स्थिति और हेडर प्राप्त करें।

किसी URL की HTTP प्रतिक्रिया स्थिति कोड और सर्वर द्वारा भेजे गए सभी प्रतिक्रिया हेडर प्राप्त करने के लिए उसे दर्ज करें।

You Server GET / HTTP/1.1 200 OK + headers Content-Type · Strict-Transport-Security · X-Frame-Options …

      

SSL / TLS प्रमाणपत्र जांचकर्ता

किसी होस्ट के TLS प्रमाणपत्र की जांच करें: जारीकर्ता, वैधता तिथियां और शेष दिन।

किसी होस्टनाम का TLS प्रमाणपत्र जांचने के लिए उसे दर्ज करें — जारीकर्ता, वैधता तिथियाँ, और समाप्ति तक शेष दिन।

You Host ClientHello → ← ServerHello + Certificate + Finished Root CA Intermediate Leaf (site) certificate chain of trust · validity dates checked

      

Geo-IP लुकअप

किसी IP पते का भौगोलिक स्थान और नेटवर्क जानकारी देखें। अपना सार्वजनिक IP देखने के लिए खाली छोड़ें।

कोई भी IP पता दर्ज करें, या अपना खुद का पता देखने के लिए खाली छोड़ें, ताकि उसका अनुमानित स्थान और नेटवर्क/ISP जानकारी देखी जा सके।

IP address Geo / RIR database City · Country ASN · Org

        
        
      

सबनेट / CIDR कैलकुलेटर

पूरी तरह से आपके ब्राउज़र में गणना की जाती है — सर्वर को कोई डेटा नहीं भेजा जाता।

तुरंत नेटवर्क रेंज, ब्रॉडकास्ट पता, और उपयोग योग्य होस्ट संख्या की गणना करने के लिए एक IP पता और CIDR प्रीफ़िक्स (जैसे 192.168.1.0/24) दर्ज करें।

network bits (prefix) host bits /24 example — split moves with your prefix

      

स्पीड टेस्ट

इस सर्वर के साथ बुनियादी डाउनलोड/अपलोड थ्रूपुट परीक्षण (सटीकता सर्वर के अपने कनेक्शन पर निर्भर करती है)।

इस सर्वर के विरुद्ध डाउनलोड और अपलोड गति मापने के लिए स्टार्ट दबाएँ। सटीकता इस सर्वर के अपने कनेक्शन पर निर्भर करती है।

You Server ↓ download ↑ upload throughput (Mbps)

      

देश कोड शब्दकोश

ISO 3166-1 alpha-2 देश कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।

ISO 3166-1 alpha-2 देश कोड की सूची खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजी जाती है।

देशISO कोड

फ़ोन डायलिंग कोड शब्दकोश

देश के अनुसार अंतरराष्ट्रीय कॉलिंग कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।

देश के अनुसार अंतरराष्ट्रीय डायलिंग कोड खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।

देशडायलिंग कोड

विश्व घड़ी

वर्तमान समय देखने के लिए एक टाइम ज़ोन चुनें — ग्लोब को घुमाने के लिए खींचें।

सूची से एक समय क्षेत्र चुनें, या ग्लोब को घुमाएँ, ताकि वहाँ का वर्तमान समय देखा जा सके।

आपका समय
--:--:--
—

—

चयनित समय
--:--:--
—
— UTC±00:00
आपसे समय का अंतर —

—

ग्लोब घुमाने के लिए खींचें।

फ्रांस मोबाइल नेटवर्क स्थिति

फ्रांस में ऑपरेटर (Orange, Free, SFR, Bouygues Telecom) के अनुसार खराब या रखरखाव में मोबाइल एंटीना साइटें, Arcep के सार्वजनिक डेटा से। दिन में एक बार अपडेट होने वाला स्नैपशॉट - मिनट-दर-मिनट फीड नहीं।

फ्रांसीसी ऑपरेटर के अनुसार मोबाइल एंटीना और फाइबर आउटेज डेटा ब्राउज़ करें — किसी इनपुट की आवश्यकता नहीं, ARCEP के सार्वजनिक डेटा से स्वतः अपडेट होता है।

स्रोत: Arcep, "Sites indisponibles" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है, पहले इस्तेमाल किए गए IODA/CAIDA डेटा के विपरीत। Normal/Watch/Alert बैज एक अनुमानित संकेतक है (आज की गड़बड़ियों की संख्या बनाम पिछले दिनों का औसत), Arcep का आधिकारिक वर्गीकरण नहीं। स्रोत लिंक नीचे।

सबसे अधिक प्रभावित विभाग

वर्तमान में खराब या रखरखाव में साइटों की संख्या, विभाग अनुसार। फ़िल्टर के लिए ऐपर किसी ऑपरेटर पर क्लिक करें।

डेटा: Arcep — Sites indisponibles · आधिकारिक नेटवर्क स्थिति मानचित्र


फ़िक्स्ड नेटवर्क (फ़ाइबर)

ऑपरेटर अनुसार फ़ाइबर (FTTH) नेटवर्क गुणवत्ता: रिपोर्ट की गई खराबी दर और कनेक्शन विफलता दर, Arcep के सार्वजनिक डेटा से। मासिक संकेतक, 6 महीने का औसत - मोबाइल सेक्शन की तरह लाइव फीड नहीं।

स्रोत: Arcep, "Qualité des réseaux en fibre optique" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है। स्रोत लिंक नीचे।

ऑपरेटर अनुसार (मूल कंपनी)

पिछले 6 उपलब्ध महीनों का औसत, इन्फ्रास्ट्रक्चर ऑपरेटर की मूल कंपनी अनुसार।

डेटा: Arcep — Qualité des réseaux en fibre optique