Hoe werkt het internet?

Dit artikel volgt één HTTP-verzoek van je toetsenbord tot de server en terug. Je leert welke lagen er langskomen, welke commando's je zelf kunt draaien om dat te zien, en waar het misgaat als er iets stuk is.

Vereisten

Je hebt een Linux-systeem nodig met een paar standaardtools. Op Debian 12 of Ubuntu 24.04 staan de meeste al aanwezig; op een minimale installatie mis je er een paar.

```bash sudo apt update sudo apt install -y curl dig traceroute tcpdump iproute2 ```

• `curl` (versie 8.x) — HTTP-verzoeken vanaf de command line
• `dig` (onderdeel van bind9-dnsutils) — DNS-queries
• `traceroute` — de route naar een bestemming volgen
• `tcpdump` (versie 4.99) — pakketten op de wire bekijken
• `iproute2` — `ip route`, `ip addr`, `ss`

Je hebt geen root nodig voor `dig`, `curl` of `traceroute`. Voor `tcpdump` wel, of je zet er capabilities op.

```bash sudo setcap cap_net_raw,cap_net_admin=eip $(which tcpdump) ```

Dat is eenmalig. Daarna kun je `tcpdump` als gewone gebruiker draaien zonder `sudo` — handig, maar het betekent ook dat elk proces op je account pakketten kan meelezen. Op een machine met meerdere gebruikers is dat een afweging.

De stapel in het kort

Voordat je iets typt, moet je weten welke laag wat doet. Anders weet je bij een storing niet waar je moet kijken.

Onderaan zit het fysieke netwerk: kabels, switches, wifi. Daarboven IP, dat pakketten van adres naar adres brengt zonder garantie. Daarboven TCP (of UDP), dat een betrouwbare stroom van maakt. Daarboven HTTP, DNS, TLS — de protocollen waar je als gebruiker mee te maken krijgt.

Elke laag vertrouwt op de laag eronder en weet niets van de laag erboven. Dat is precies waarom het internet schaalbaar is, en precies waarom foutzoeken vervelend is: een kapotte kabel en een verkeerd TLS-certificaat zien er voor de gebruiker hetzelfde uit.

Stappen

1. Zoek het IP-adres op met DNS

Voordat je browser ook maar iets kan versturen, moet hij weten naar welk IP-adres. Dat doet DNS.

```bash dig +short pixzo.nl A ```

Je krijgt één of meer IPv4-adressen terug. Wil je het hele antwoord zien, laat dan `+short` weg — dan zie je ook de TTL, de authoritative nameserver en of het antwoord uit de cache kwam.

DNS is hiërarchisch: je resolver vraagt het aan een root-server, die verwijst naar de `.nl`-server, die verwijst naar de nameserver van het domein. Dat gebeurt allemaal binnen milliseconden, en het resultaat wordt gecached op basis van de TTL.

Een lage TTL betekent snelle propagatie bij wijzigingen, maar ook meer DNS-verkeer. Een hoge TTL is efficiënt, maar een fout adres blijft dan uren hangen. Kies bewust.

2. Controleer de route naar de server

Nu je het IP-adres hebt, kun je zien welke routers je verkeer onderweg tegenkomt.

```bash traceroute -n 1.1.1.1 ```

De `-n` slaat reverse DNS op elke hop over. Zonder die flag duurt het veel langer, omdat elke router zijn naam moet opzoeken.

Elke regel is een hop. De tijden zijn round-trip in milliseconden. Zie je ` *`, dan filtert die router ICMP of is hij onbereikbaar — dat betekent niet automatisch dat het verkeer stopt, want routers sturen data vaak wel door maar weigeren te antwoorden.

BGP bepaalde welke route je verkeer kiest. Dat protocol is gebaseerd op vertrouwen tussen autonome systemen; een verkeerde route-aankondiging kan het verkeer van een heel land omleiden. Dat is geen theorie.

3. Doe een HTTP-verzoek met curl

Nu ga je echt met de server praten.

```bash curl -v --http1.1 https://pixzo.nl/ -o /dev/null ```

De `-v` laat de volledige uitwisseling zien: de TLS-handshake, de request headers, de response headers. `-o /dev/null` gooit de body weg zodat je terminal niet volloopt met HTML.

In de output zie je drie blokken. Eerst `* Connected to ...`, dan de TLS-negotiatie, dan `> GET / HTTP/1.1` gevolgd door je request headers, en tenslotte `< HTTP/1.1 200 OK` met de response headers.

Let op de `server`-header en de `content-type`. Als de response geen `200` is maar een `301`, volgt curl die niet automatisch — voeg `-L` toe.

4. Kijk hoe TLS de verbinding beveiligt

HTTPS is HTTP over TLS. Zonder TLS zou elke router tussen jou en de server de inhoud kunnen lezen en aanpassen.

```bash openssl s_client -connect pixzo.nl:443 -servername pixzo.nl /dev/null | openssl x509 -noout -subject -issuer -dates ```

Je krijgt het subject, de issuer en de geldigheidsdatums van het certificaat. De `-servername` is belangrijk: zonder SNI weet de server niet welk certificaat hij moet sturen en krijg je het verkeerde of helemaal niets.

TLS doet twee dingen: het versleutelt de verbinding, en het bewijst dat je met de juiste server praat. Dat tweede is afhankelijk van de certificaatautoriteiten in je trust store. Vertrouw je die niet, dan is de hele keten zo sterk als de zwakste CA.

5. Bekijk de pakketten op de wire

Soms wil je zien wat er echt over de kabel gaat. Dat kan met tcpdump.

```bash sudo tcpdump -i any -n 'tcp port 443 and host pixzo.nl' ```

Laat dit draaien in het ene terminalvenster en doe een `curl https://pixzo.nl/` in een ander. Je ziet de TCP-handshake (`SYN`, `SYN-ACK`, `ACK`), dan de TLS ClientHello, dan versleutelde data.

Je kunt de inhoud niet lezen — dat is het punt van TLS. Maar je ziet wel hoe de verbinding tot stand komt, en of er retransmissies zijn. Veel `retransmission`-regels betekenen packet loss, en dat is bijna altijd een netwerkprobleem, niet een serverprobleem.

6. Test de connectie op TCP-niveau

Als `curl` traag is of hangt, wil je weten of de TCP-verbinding zelf tot stand komt.

```bash ss -tn state established '( dport = :443 )' ```

Dit laat alle openstaande TCP-verbindingen naar poort 443 zien. Zie je je verbinding niet, dan is hij nooit opgezet — dan zit het probleem in de route of in een firewall.

Voor een gerichte test kun je `nc` gebruiken:

```bash nc -vz pixzo.nl 443 ```

Dat probeert alleen de TCP-handshake, niets meer. Slaagt die maar `curl` faalt, dan zit het probleem in TLS of in de HTTP-laag.

7. Volg het verzoek aan de serverkant

Als je zelf een server beheert, wil je zien wat er aan de andere kant gebeurt. Op een Linux-server met systemd kun je de logs live volgen.

```bash sudo journalctl -u nginx -f ```

Doe tegelijk een verzoek vanaf je laptop. Je ziet de access log-regel verschijnen met het IP-adres van de client, het pad, de statuscode en de user agent.

Staat er niets, dan bereikt het verkeer je server niet. Dat betekent bijna altijd: firewall, verkeerde poort, of de server luistert niet op het juiste interface. Controleer met `ss -tlnp` waar je proces daadwerkelijk naar luistert — `0.0.0.0:80` is niet hetzelfde als `127.0.0.1:80`.

8. Begrijp waar de client-serverarchitectuur ophoudt

Niet alles op het internet is client-server. Peer-to-peer netwerken zoals BitTorrent en protocols als WireGuard laten apparaten direct met elkaar praten, zonder centrale server in het midden.

Het voordeel is dat er geen centraal punt is dat kan uitvallen of meekijken. Het nadeel is dat je zelf verantwoordelijk bent voor bereikbaarheid — NAT en firewalls maken directe verbindingen lastig, en je hebt vaak een relay of hole-punching nodig.

Voor de meeste toepassingen is client-server simpeler en voorspelbaarder. Voor privacy-gevoelige of gedecentraliseerde toepassingen weegt het gebrek aan een centraal punt zwaarder dan het gemak.

Verificatie

Draai een volledige keten in één commando en kijk of alles klopt.

```bash dig +short pixzo.nl A && curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s ip=%{remote_ip}\n" https://pixzo.nl/ ```

Je krijgt het IP-adres, de HTTP-statuscode, de totale tijd en het IP waarmee curl daadwerkelijk verbonden was. Als het IP uit `dig` en het IP uit `curl` hetzelfde zijn, en de status is `200`, dan werkt de hele keten: DNS, routing, TCP, TLS en HTTP.

Wijkt het IP af, dan zit er een CDN of load balancer tussen. Dat is niet fout, maar je moet het weten voordat je gaat debuggen.

Veelgestelde problemen

DNS geeft een ander IP dan verwacht. Vaak caching. Check met `dig +trace pixzo.nl` waar het antwoord vandaan komt, en kijk of je lokale resolver (`/etc/resolv.conf`) niet een andere server gebruikt dan je dacht. `systemd-resolved` op Ubuntu 24.04 luistert op `127.0.0.53` en cachet agressief.

`curl` hangt zonder foutmelding. Meestal een firewall die pakketten dropt in plaats van weigert. Een `DROP` betekent dat je client blijft wachten; een `REJECT` geeft direct een fout. Test met `nc -vz -w 5 pixzo.nl 443` — de `-w 5` zorgt dat je niet eindeloos wacht.

TLS-fout `certificate verify failed`. Je systeemklok staat verkeerd, of het CA-certificaat ontbreekt. Check met `date -u` en update je CA-bundel met `sudo apt install --reinstall ca-certificates`.

Wat je hiermee kunt

De keten DNS → routing → TCP → TLS → HTTP is de basis van bijna alles wat je op het internet doet. Zodra je weet welke laag faalt, weet je ook welk commando je moet draaien.

Het lastige is niet de theorie. Het lastige is dat elke laag zijn eigen foutmelding heeft, en dat de browser ze allemaal onder één "deze site is niet bereikbaar" plakt. Zelf de lagen aflopen is de enige manier om te zien waar het echt misgaat.

En dat is ook precies waarom je als beheerder je eigen `dig`, `curl` en `tcpdump` draait in plaats van te vertrouwen op wat een dashboard zegt. Het dashboard ziet alleen wat het dashboard meet.