Client, server & protocol

Bijna alle netwerkcommunicatie die je als ontwikkelaar tegenkomt, volgt hetzelfde patroon: één partij vraagt, de andere antwoordt. Dat patroon heet het client-servermodel, en de afspraken waarmee die twee elkaar begrijpen heten een protocol.

Het client-servermodel

Rol	Wie het is	Wat die doet
Client	Browser, mobiele app, curl, Postman, je eigen code	Neemt het initiatief en stuurt een request
Server	Webserver, API, databank, mailserver	Wacht op requests en stuurt een response terug

Twee eigenschappen zijn essentieel:

1. De client begint altijd. Een server stuurt uit zichzelf niets naar jouw laptop. Hij draait, luistert op een poort, en reageert pas als er iets binnenkomt.
2. Op elk request volgt precies één response. Nooit meer, nooit minder. Ook een foutmelding is een response.

Server is een rol, geen machine

Dit is het punt waar de meeste verwarring ontstaat. "Server" klinkt als een zwarte kast in een datacenter, maar het is gewoon een programma dat wacht op verzoeken.

Enkele voorbeelden uit je eigen praktijk:

Situatie	Client	Server
Je bekijkt een website	Je browser	De webserver van die site
npm run dev en dan localhost:5173 openen	Je browser	Vite, op je eigen laptop
Je app haalt data op met fetch()	Je JavaScript-code	De API
git push naar GitHub	De git-client	GitHub
Spotify speelt een nummer af	De Spotify-app	De streamingservers van Spotify
Een online game	De game op je pc	De gameserver

Merk het tweede voorbeeld op: als je een dev server draait, is jouw laptop tegelijk client en server. De browser (client) vraagt een pagina aan Vite (server), en beide draaien op hetzelfde toestel. Dat is geen uitzondering, dat is de normale situatie tijdens ontwikkeling.

En het alternatief: peer-to-peer

Niet alles is client-server. In een peer-to-peer-netwerk (BitTorrent, sommige videogesprekken, blockchainnetwerken) is elk toestel tegelijk client én server voor de anderen: iedereen vraagt én levert. Er is geen centraal punt dat alles bedient.

Het client-servermodel blijft dominant omdat het eenvoudig te beheren en te beveiligen is: er is één plek waar de data staat en waar je regels afdwingt.

Wat is een protocol?

Een protocol is een verzameling afspraken die bepaalt hoe twee partijen communiceren. Precies zoals menselijke communicatie afspraken kent: bij een telefoongesprek zeg je "hallo", wacht je tot de ander uitgesproken is, en beëindig je met "dag". Wijk je daarvan af, dan valt het gesprek stil.

Een netwerkprotocol legt drie dingen vast:

Aspect	Vraag die het beantwoordt	Voorbeeld in HTTP
Syntax	Hoe ziet een bericht eruit?	GET /index.html HTTP/1.1, gevolgd door headers
Semantiek	Wat betekent elk onderdeel?	404 betekent "niet gevonden"
Timing	Wie zegt wat, en in welke volgorde?	Eerst request, dan response, nooit omgekeerd

Zonder die afspraken is data betekenisloos. De ontvanger krijgt bits binnen, maar weet niet waar een bericht begint, wat het wil, of het compleet is.

Waarom protocollen open standaarden zijn

Omdat een browser van Google moet kunnen praten met een server van Mozilla, die op Linux draait, via een router van Cisco. Dat werkt alleen als iedereen zich aan dezelfde publiek beschreven afspraak houdt. Die afspraken staan in RFC's (Request for Comments), vrij te lezen documenten. HTTP/1.1 is bijvoorbeeld RFC 9112.

Protocollen die je regelmatig tegenkomt

Protocol	Waarvoor	Waar je het ziet
HTTP / HTTPS	Webpagina's en API's opvragen	Adresbalk, Network tab, fetch()
DNS	Domeinnamen omzetten naar IP-adressen	Bij elke eerste keer dat je een site bezoekt
TCP	Betrouwbare, geordende verbinding	Onder vrijwel al je verkeer
UDP	Snelle verzending zonder garanties	Videogesprekken, games, streaming
IP	Adressering en routering van pakketten	Elk pakket, altijd
SMTP / IMAP	Mail versturen en ophalen	Je mailclient
SSH	Beveiligd inloggen op een server op afstand	ssh gebruiker@server, git push
TLS	Versleuteling bovenop TCP	Het slotje bij https://

Protocollen werken samen in lagen

Eén protocol volstaat niet. Als je een pagina opvraagt, zijn er tegelijk verschillende actief, elk met een eigen taak:

HTTP    "geef mij /index.html"          ← wat je wil
TLS     "en versleutel het onderweg"    ← hoe het beveiligd wordt
TCP     "in de juiste volgorde, volledig" ← hoe het betrouwbaar aankomt
IP      "naar 193.190.253.10"           ← waar het heen moet
Ethernet / Wi-Fi  "via deze kabel"      ← hoe het fysiek vertrekt

Elk protocol vertrouwt op het protocol eronder en hoeft zich niets aan te trekken van de details daarvan. HTTP weet niet of je via wifi of via 5G verbonden bent, en dat hoeft ook niet. Die opdeling in lagen is precies wat het OSI-model beschrijft.

Test jezelf

1. Je start met `npm run dev` een lokale server op poort 5173 en opent die in je browser. Wie is hier de server?

2. Welke uitspraak over het client-servermodel klopt?

3. Wat legt een protocol NIET vast?

Onthoud

• De client vraagt en neemt het initiatief, de server wacht en antwoordt. Eén request, één response.
• Server is een rol, geen machine: je eigen laptop is er tijdens ontwikkeling vaak zelf een.
• Een protocol legt syntax, semantiek en timing vast; zonder die afspraken zijn bits betekenisloos.
• Protocollen zijn gelaagd: HTTP steunt op TLS, dat op TCP, dat op IP, dat op Ethernet of Wi-Fi.