◈ netchecks.org

17 controles · geen account nodig · self-hosted

Test uw netwerk met één klik

17 gratis netwerkdiagnosetools in één dashboard.

Veelgestelde vragen

0 trackers · 14 talen · licht- en donkere modus · self-hosted

← Alle artikelen

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.

Kort samengevat

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.

← Alle artikelen

Mijn IP-check

Uw openbare IP-adres en netwerklocatie, automatisch gedetecteerd.

Wordt automatisch geladen bij het openen van NetChecks — geen invoer nodig. Gebruik de knop Vernieuwen na het wisselen van netwerk of VPN.

Uw browser

Alles-in-één-scan

Voert in één keer alle relevante controles uit op één IP-adres of hostnaam: DNS, whois, ping, traceroute, een scan van bekende poorten (1-1024), HTTP-headers en het SSL-certificaat.

Voer een domein of IP-adres in en voer uit om DNS, whois, ping, traceroute, veelgebruikte poorten, HTTP-headers en het SSL-certificaat in één keer te controleren.

De meeste controles worden parallel uitgevoerd - meestal binnen ongeveer 30 seconden voltooid, langer als het doel traag of onbereikbaar is.

De poortscanstap wordt alleen uitgevoerd als het toestemmingsvakje hierboven is aangevinkt - alle andere controles worden sowieso uitgevoerd.

Ping

Verzendt ICMP-echoverzoeken naar een host om bereikbaarheid en latentie te controleren.

Voer een hostnaam of IP-adres in en klik op Ping om ICMP-echoverzoeken te sturen en de retourlatentie te meten.

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

      

Meer informatie over Ping

Wat het is

Ping stuurt ICMP Echo Request-pakketten naar een host en meet hoelang het duurt voordat de ICMP Echo Reply-pakketten terugkomen. Het is de meest basale netwerkconnectiviteitstest die er is: hij beantwoordt precies één vraag, "is deze machine bereikbaar, en hoe snel?". Het ICMP-protocol (RFC 792) werd in 1981 speciaal ontworpen om controle- en diagnoseberichten over IP-netwerken te transporteren, los van elk applicatieverkeer - Ping is de bekendste en meest universeel beschikbare implementatie ervan, praktisch aanwezig op elk besturingssysteem en netwerkapparaat sinds de vroegste versies daarvan.

Hoe het werkt

Elk ICMP-pakket bevat een TTL-veld (Time To Live) dat bij elke gepasseerde router met één wordt verlaagd; komt het op nul voordat het doel is bereikt, dan wordt het pakket verworpen en wordt er een foutmelding teruggestuurd naar de afzender. De gemeten retourtijd (RTT) in milliseconden weerspiegelt de opgetelde netwerklatentie over de volledige heen-en-terugreis, niet alleen het laatste stuk vlak bij het doel - een punt dat vaak verkeerd wordt begrepen, aangezien een traag pingresultaat zijn eigenlijke oorzaak overal langs het pad kan hebben, niet noodzakelijk bij de geteste server. Een ping stuurt doorgaans meerdere pakketten achter elkaar in plaats van slechts één, waardoor je een eenmalige latentiepiek kunt onderscheiden van een terugkerend probleem en een pakketverliespercentage over de steekproef kunt berekenen.

Resultaten interpreteren

Een stabiele, lage RTT - enkele milliseconden op een lokaal netwerk, 10 tot 50 ms voor een bestemming binnen hetzelfde land, en merkbaar meer voor een intercontinentale verbinding - duidt op een gezonde verbinding. Zelfs een klein beetje pakketverlies (boven 1-2%) is bijzonder schadelijk voor latentiegevoelige toepassingen zoals VoIP of interactieve externe sessies, waar elk verloren pakket zich manifesteert als een storing of hoorbare onderbreking. Sterk wisselende latentie van pakket tot pakket (jitter) is voor diezelfde toepassingen vaak problematischer dan een hoge maar perfect stabiele latentie. "Time-out van het verzoek" betekent dat er binnen de toegestane tijd geen antwoord is binnengekomen - de host kan werkelijk offline zijn, een firewall kan ICMP stilzwijgend blokkeren, of er kan ergens langs het pad een route verbroken zijn; "Bestemming onbereikbaar" is anders en informatiever: een tussenliggende router heeft expliciet een bericht teruggestuurd dat hij het pakket niet kon doorsturen, wat helpt om af te bakenen waar het probleem zich werkelijk bevindt.

Veelgemaakte fouten

De meest voorkomende verkeerde interpretatie is concluderen dat een host "offline" is zodra een ping mislukt, terwijl heel veel servers en apparaten - vooral achter een goed geconfigureerde firewall, of gehost bij grote cloudproviders - inkomende ICMP bewust blokkeren als beleid, terwijl ze volledig operationeel en bereikbaar zijn op hun daadwerkelijke diensten (HTTP, een database, enzovoort). Het uitblijven van een pingantwoord is dus alleen betekenisvol bewijs van uitval wanneer het gecombineerd wordt met andere signalen, zoals dat de applicatie zelf ook niet reageert. Omgekeerd garandeert een geslaagde ping geenszins dat de applicatiedienst op die machine correct functioneert - dat zijn twee volledig onafhankelijke lagen van de netwerkstack.

Wanneer te gebruiken

Het eerste dat gecontroleerd moet worden voordat een ticket wordt geëscaleerd: reageert de machine überhaupt, voordat er verder wordt gezocht? Connectiviteit bevestigen na een wijziging van een firewallregel of routeringstabel, om zeker te zijn dat de wijziging de toegang niet heeft verbroken. Een latentie-baseline vaststellen vóór een VoIP-uitrol of een failover van een operatorverbinding, zodat er een objectief vergelijkingspunt is als er later klachten binnenkomen over de gesprekskwaliteit. Een lichte, periodieke statuscontrole voor een MSP die meerdere klantlocaties parallel monitort, altijd als aanvulling op - nooit als vervanging van - diepere monitoring op applicatieniveau.

Traceroute

Traceert het netwerkpad (hop voor hop) naar een doelhost.

Voer een hostnaam of IP-adres in en voer uit om elke netwerkhop tussen deze server en de bestemming te zien, met de latentie per hop.

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

      

DNS-opzoeking (Nslookup)

Vraagt DNS-records op: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA.

Voer een domein in, kies een recordtype (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV of CAA) en voer de opzoeking uit.

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

      

Whois

Zoekt registratiegegevens op voor een domein of IP-adres.

Voer een domein of IP-adres in om de registratiegegevens op te zoeken: registrar, eigenaarsorganisatie en belangrijke data.

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

      

Blacklist-controle

Controleert of een IP-adres of domein voorkomt op openbare spam-/misbruik-blacklists (DNSBL).

Voer een IPv4-adres of domein in en voer uit om 7 openbare DNSBL/RBL-blacklists tegelijk te controleren - elke lijst toont vermeld, niet vermeld of controle mislukt.

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

      

TCP-poortscan

Controleert of TCP-poorten open staan op een host of IP: veelgebruikte poorten, een aangepaste lijst, of het volledige bereik 1-65535.

Voer een host of IP in, kies veelgebruikte poorten, een aangepaste lijst of het volledige bereik, en scan om te zien welke TCP-poorten reageren.

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

        
      

HTTP-header-inspecteur

Haalt de HTTP-antwoordstatus en headers op voor een URL.

Voer een URL in om de HTTP-statuscode en alle antwoordheaders die de server terugstuurt op te halen.

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

      

SSL-/TLS-certificaatcontrole

Onderzoekt het TLS-certificaat van een host: uitgever, geldigheidsdata en resterende dagen.

Voer een hostnaam in om het TLS-certificaat te inspecteren: uitgever, geldigheidsdata en resterende dagen tot verloop.

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

      

Geo-IP-opzoeking

Zoekt de geografische locatie en netwerkinformatie op voor een IP-adres. Leeg laten om uw eigen openbare IP op te zoeken.

Voer een IP-adres in, of laat leeg om uw eigen adres op te zoeken, om de geschatte locatie en netwerk-/ISP-informatie te zien.

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

        
        
      

Subnet-/CIDR-calculator

Volledig berekend in uw browser — er worden geen gegevens naar de server verzonden.

Voer een IP-adres en CIDR-prefix in (bijv. 192.168.1.0/24) om direct het netwerkbereik, broadcastadres en aantal bruikbare hosts te berekenen.

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

      

Snelheidstest

Eenvoudige download-/uploadsnelheidstest tegen deze server (nauwkeurigheid hangt af van de eigen uplink van de server).

Klik op Start om de download- en uploadsnelheid naar deze server te meten. De nauwkeurigheid hangt af van de eigen verbinding van deze server.

You Server ↓ download ↑ upload throughput (Mbps)

      

Landcode-woordenboek

ISO 3166-1 alpha-2-landcodes — volledig doorzocht in uw browser.

Zoek of blader door de lijst met ISO 3166-1 alpha-2-landcodes, volledig doorzocht in uw browser.

LandISO-code

Netnummer-woordenboek

Internationale landnummers per land — volledig doorzocht in uw browser.

Zoek of blader door internationale landcodes voor telefoonnummers, volledig doorzocht in uw browser.

LandNetnummer

Wereldklok

Kies een tijdzone om de huidige tijd te zien - sleep de wereldbol om deze te draaien.

Kies een tijdzone uit de lijst, of sleep aan de globe, om de huidige tijd daar te zien.

Jouw tijd
--:--:--
—

—

Geselecteerde tijd
--:--:--
—
— UTC±00:00
Verschil met jou —

—

Sleep om de wereldbol te draaien.

Status van het Franse mobiele netwerk

Mobiele antennesites die uitgevallen zijn of in onderhoud zijn in Frankrijk, per operator (Orange, Free, SFR, Bouygues Telecom), op basis van openbare gegevens van ARCEP. Momentopname eenmaal per dag bijgewerkt door ARCEP - geen minuut-voor-minuut feed.

Bekijk storingsgegevens van mobiele antennes en glasvezel per Franse operator — geen invoer nodig, automatisch bijgewerkt met openbare Arcep-gegevens.

Bron: ARCEP, dataset "Sites indisponibles", gepubliceerd onder Licence Ouverte / Etalab 2.0 - commercieel hergebruik uitdrukkelijk toegestaan, in tegenstelling tot de IODA/CAIDA-gegevens die dit tabblad eerder gebruikte. Het label Normaal/Waakzaam/Alarm is een interne schatting (aantal storingen vandaag versus de mediaan van voorgaande dagen), geen officiële ARCEP-classificatie. Bronlinks hieronder.

Zwaarst getroffen departementen

Aantal sites dat momenteel is uitgevallen of in onderhoud is, per departement. Klik hierboven op een operator om te filteren.

Gegevens: Arcep — Sites indisponibles · Officiële netwerkstatuskaart


Vast netwerk (Glasvezel)

Kwaliteit van het glasvezelnetwerk (FTTH) per operator: gemeld storingspercentage en verbindingsfoutpercentage, op basis van openbare gegevens van ARCEP. Maandelijkse indicatoren, voortschrijdend gemiddelde over 6 maanden - geen live feed zoals het mobiele gedeelte.

Bron: ARCEP, dataset "Qualité des réseaux en fibre optique", gepubliceerd onder Licence Ouverte / Etalab 2.0 - commercieel hergebruik uitdrukkelijk toegestaan. Bronlinks hieronder.

Per operator (moedergroep)

Gemiddelden over de laatste 6 beschikbare maanden, per moedergroep van de infrastructuuroperator.

Gegevens: Arcep — Qualité des réseaux en fibre optique