02 apr 2025·8 min
Bob Kahn en TCP/IP: de onzichtbare laag die apps aandrijft
Lees hoe Bob Kahn hielp TCP/IP vorm te geven, waarom betrouwbaar pakketverkeer belangrijk is en hoe het ontwerp nog steeds apps, API's en clouddiensten ondersteunt.
Lees hoe Bob Kahn hielp TCP/IP vorm te geven, waarom betrouwbaar pakketverkeer belangrijk is en hoe het ontwerp nog steeds apps, API's en clouddiensten ondersteunt.
De meeste apps voelen "instant" aan: je tikt op een knop, een feed ververst, een betaling gaat door, een video start. Wat je niet ziet is het werk dat eronder gebeurt om kleine datapakketjes over Wi‑Fi, mobiele netwerken, thuisrouters en datacenters te verplaatsen—vaak over meerdere landen—zonder dat jij hoeft na te denken over de rommelige delen daartussen.
Die onzichtbaarheid is precies wat TCP/IP levert. Het is geen enkel product of cloudfunctie. Het is een set gedeelde regels die apparaten en servers laat praten op een manier die meestal soepel en betrouwbaar aanvoelt, zelfs als het netwerk luidruchtig, vol of deels defect is.
Bob Kahn was een van de sleutelfiguren die dat mogelijk maakte. Samen met medewerkers zoals Vint Cerf hielp Kahn de kernideeën te vormen die TCP/IP werden: een gemeenschappelijke “taal” voor netwerken en een methode om data te bezorgen op een manier waarop applicaties kunnen vertrouwen. Geen hype—dit werk was belangrijk omdat het onbetrouwbare verbindingen veranderde in iets waar software betrouwbaar op kon bouwen.
In plaats van een heel bericht als één continue stroom te sturen, deelt pakketnetwerken het op in kleine stukjes genaamd pakketten. Elk pakket kan zijn eigen pad naar de bestemming nemen, als afzonderlijke enveloppen die door verschillende postkantoren gaan.
We leggen uit hoe TCP het gevoel van betrouwbaarheid creëert, waarom IP opzettelijk geen perfectie belooft en hoe het gelaagde ontwerp het systeem begrijpelijk houdt. Aan het einde kun je je voorstellen wat er gebeurt wanneer een app een API aanroept—en waarom deze decennialange ideeën nog steeds moderne clouddiensten aandrijven.
Vroege computernetwerken werden niet geboren als "het Internet." Ze waren gebouwd voor specifieke groepen met specifieke doelen: een universiteitsnetwerk hier, een militair netwerk daar, een onderzoeksnetwerk ergens anders. Elk kon intern goed werken, maar ze gebruikten vaak verschillende hardware, berichtformaten en regels voor hoe data moest reizen.
Dat zorgde voor een frustrerende werkelijkheid: zelfs als twee computers beiden "geconnect" waren, konden ze soms nog steeds geen informatie uitwisselen. Het is een beetje alsof je veel spoorwegsystemen hebt met verschillende spoorbreedtes en signalen die verschillend betekenen. Je kunt treinen binnen één systeem verplaatsen, maar oversteken naar een ander systeem is rommelig, duur of onmogelijk.
Kahn’s belangrijkste uitdaging was niet simpelweg "computer A met computer B verbinden." Het was: hoe verbind je netwerken met elkaar zodat verkeer door meerdere onafhankelijke systemen kan gaan alsof het één groter systeem is?
Dat is wat “internetworking” betekent—een methode bouwen zodat data van het ene netwerk naar het andere kan springen, zelfs wanneer die netwerken anders ontworpen zijn en door verschillende organisaties beheerd worden.
Om internetworking op schaal te laten werken, had iedereen een gemeenschappelijke set regels—protocollen—nodig die niet afhankelijk waren van het interne ontwerp van een enkel netwerk. Die regels moesten ook rekening houden met echte beperkingen:
TCP/IP werd het praktische antwoord: een gedeelde “overeenkomst” die onafhankelijke netwerken liet interconnecten en toch data betrouwbaar genoeg kon verplaatsen voor echte applicaties.
Bob Kahn staat vooral bekend als een van de hoofdarchitecten van de verkeersregels van het internet. In de jaren 70, terwijl hij bij DARPA werkte, hielp hij netwerktechniek te verschuiven van een slim onderzoeksexperiment naar iets dat veel verschillende soorten netwerken kon verbinden—zonder ze allemaal te dwingen dezelfde hardware, bedrading of interne opzet te gebruiken.
ARPANET toonde aan dat computers konden communiceren over pakketgeschakelde verbindingen. Maar andere netwerken ontstonden ook—radio-netwerken, satellietverbindingen en extra experimentele netwerken—elk met hun eigen eigenaardigheden. Kahn richtte zich op interoperabiliteit: een bericht laten reizen over meerdere netwerken alsof het één enkel netwerk was.
In plaats van één “perfect” netwerk te bouwen, bepleitte hij een aanpak waarbij:
Samen met Vint Cerf ontwierp Kahn wat TCP/IP werd. Een blijvend resultaat was de duidelijke scheiding van verantwoordelijkheden: IP regelt adressering en forwarding tussen netwerken, terwijl TCP betrouwbare levering verzorgt voor applicaties die dat nodig hebben.
Als je ooit een API hebt aangeroepen, een webpagina hebt geladen of logs van een container naar een monitoringdienst hebt gestuurd, vertrouw je op het internetworking-model dat Kahn verdedigde. Je hoeft je niet bezig te houden of pakketten over Wi‑Fi, fiber, LTE of een cloud-backbone gaan. TCP/IP laat dat allemaal lijken op één doorlopend systeem—zodat software zich op functies kan richten, niet op bedrading.
Een van de slimste ideeën achter TCP/IP is layering: in plaats van één gigantisch "doe-alles" netwerk, stapel je kleinere lagen waarbij elke laag één taak goed doet.
Dit is belangrijk omdat netwerken niet allemaal hetzelfde zijn. Verschillende kabels, radio’s, routers en providers kunnen toch samenwerken als ze het eens zijn over een paar duidelijke verantwoordelijkheden.
Zie IP (Internet Protocol) als het deel dat antwoordt op: Waar moet deze data heen, en hoe brengen we het dichter bij die plek?
IP levert adressen (zodat machines geïdentificeerd kunnen worden) en basis routering (zodat pakketten van netwerk naar netwerk kunnen hoppen). Belangrijk: IP probeert niet perfect te zijn. Het richt zich op het vooruitbrengen van pakketten, stap voor stap, zelfs als het pad verandert.
Daarboven ligt TCP (Transmission Control Protocol) en dat beantwoordt: Hoe laten we dit aanvoelen als een betrouwbare verbinding?
TCP regelt het betrouwbaarheidsgedeelte dat applicaties meestal willen: data in de juiste volgorde afleveren, ontbrekende stukken ontdekken, indien nodig opnieuw verzenden en de levering doseren zodat de zender de ontvanger of het netwerk niet overbelast.
Een nuttige manier om de scheiding te visualiseren is een postsysteem:
Je vraagt het afleveradres niet om te garanderen dat het pakket aankomt; die zekerheid bouw je erbovenop.
Omdat verantwoordelijkheden gescheiden zijn, kun je één laag verbeteren zonder alles te herontwerpen. Nieuwe fysieke netwerken kunnen IP dragen, en applicaties kunnen op TCP vertrouwen zonder te moeten begrijpen hoe routering werkt. Die duidelijke scheiding is een grote reden dat TCP/IP de onzichtbare, gedeelde basis onder vrijwel elke app en API werd.
Pakketgeschakeling is het idee dat grote netwerken praktisch maakte: in plaats van een gewijd circuit te reserveren voor je hele bericht, hak je het bericht in kleine stukken en stuur je elk stukje onafhankelijk.
Een pakket is een klein bundeltje data met een header (wie het stuurt, wie het ontvangt en andere routeringsinfo) plus een deel van de inhoud.
Data in stukjes verdelen helpt omdat het netwerk kan:
Hier begint de “chaos.” Pakketten van dezelfde download of API-aanroep kunnen via verschillende routes door het netwerk gaan, afhankelijk van wat op dat moment druk of beschikbaar is. Dat betekent dat ze uit volgorde kunnen aankomen—pakket #12 kan eerder arriveren dan pakket #5.
Pakketgeschakeling probeert dat niet te voorkomen. Het geeft voorrang aan het snel doorkrijgen van pakketten, ook al is de aankomstvolgorde rommelig.
Pakketverlies is niet zeldzaam en niet altijd iemands fout. Veelvoorkomende oorzaken:
De kernontwerpkeuze is dat het netwerk imperfect mag zijn. IP richt zich op zo goed mogelijk pakketten doorsturen, zonder levering of volgorde te beloven. Die vrijheid maakt schaalvergroting mogelijk—en daarom bestaan er hogere lagen (zoals TCP) om de chaos op te ruimen.
IP levert pakketten op een "best effort"-basis: sommige kunnen laat, uit volgorde, gedupliceerd of helemaal niet aankomen. TCP zit daarboven en creëert iets waar applicaties op kunnen vertrouwen: een enkele, geordende, complete stroom bytes—het soort verbinding dat je verwacht bij een bestand uploaden, een webpagina laden of een API aanroepen.
Als men zegt dat TCP “betrouwbaar” is, bedoelt men meestal:
TCP deelt je data op in stukjes en voorziet ze van volgnummers. De ontvanger stuurt acknowledgments (ACKs) terug om te bevestigen wat hij kreeg.
Als de zender geen ACK op tijd ziet, gaat hij ervan uit dat iets verloren is en doet een hertransmissie. Dit is de kern van de “illusie”: hoewel het netwerk pakketten kan laten vallen, blijft TCP proberen totdat de ontvanger bevestigt.
Ze klinken vergelijkbaar maar lossen verschillende problemen op:
Samen helpen ze TCP snel te blijven zonder roekeloos te zijn.
Een vaste timeout faalt op zowel trage als snelle netwerken. TCP past continu zijn timeout aan op basis van gemeten round-trip time. Als de omstandigheden verslechteren, wacht het langer voordat het opnieuw verstuurt; als het sneller wordt, reageert het vlotter. Die aanpassing is waarom TCP blijft werken over Wi‑Fi, mobiele netwerken en lange-afstandspaden.
Een van de belangrijkste ideeën achter TCP/IP is het end-to-endprincipe: leg de “slimme” logica aan de randen van het netwerk (de endpoints) en houd het midden van het netwerk relatief simpel.
In gewone woorden: de endpoints zijn de apparaten en programma’s die echt om de data geven: je telefoon, laptop, een server en de besturingssystemen en applicaties die erop draaien. De netwerkcore—routers en links ertussen—focusseert vooral op het verplaatsen van pakketten.
In plaats van te proberen elke router “perfect” te maken, accepteert TCP/IP dat het midden imperfect zal zijn en laat het de endpoints de delen afhandelen die context vereisen.
De kern simpeler houden maakte het makkelijker het Internet uit te breiden. Nieuwe netwerken konden meedoen zonder dat elk tussenliggend apparaat elke applicatie moest begrijpen. Routers hoeven niet te weten of een pakket bij een videogesprek, een bestandsoverdracht of een API-oproep hoort—ze forwarden het gewoon.
Bij de endpoints behandel je meestal:
In het netwerk behandel je meestal:
End-to-end denken schaalt goed, maar duwt complexiteit naar buiten. Besturingssystemen, libraries en applicaties worden verantwoordelijk voor “het laten werken” over rommelige netwerken. Dat is geweldig voor flexibiliteit, maar het betekent ook dat bugs, verkeerd ingestelde timeouts of te agressieve retries echte gebruikersproblemen kunnen veroorzaken.
IP (Internet Protocol) doet een eenvoudige belofte: het zal proberen je pakketten naar hun bestemming te sturen. Dat is alles. Geen garanties dat een pakket aankomt, maar één keer aankomt, in volgorde aankomt of binnen een bepaalde tijd aankomt.
Dat klinkt misschien als een tekortkoming—tot je kijkt naar wat het Internet moest worden: een wereldwijd netwerk samengesteld uit veel kleinere netwerken, eigendom van verschillende organisaties en constant in verandering.
Routers zijn de “verkeersregelaars” van IP. Hun hoofdtaken zijn forwarding: wanneer een pakket binnenkomt, kijkt de router naar het bestemmingadres en kiest de volgende hop die op dat moment het beste lijkt.
Routers volgen geen gesprek zoals een telefooncentrale dat doet. Ze reserveren doorgaans geen capaciteit voor jou en wachten niet om te bevestigen dat een pakket is aangekomen. Door routers te laten focussen op forwarding blijft de netwerkcore simpel—en kan hij op enorme schaal werken.
Garantie bieden is duur. Als IP elk pakket wilde garanderen in levering, volgorde en timing, zou elk netwerk op aarde strak moeten coördineren, veel staat moeten bewaren en op dezelfde manier van fouten herstellen. Die coördinatie zou groei vertragen en storingen erger maken.
In plaats daarvan tolereert IP rommeligheid. Als een link faalt, kan een router pakketten via een andere route sturen. Als een pad vol raakt, kunnen pakketten vertraagd worden of gedropt, maar verkeer kan vaak via alternatieve routes doorgaan.
Het resultaat is veerkracht: het Internet kan blijven werken zelfs als delen ervan breken of veranderen—omdat het netwerk niet perfect hoeft te zijn om nuttig te zijn.
Wanneer je fetch() een API aanroept, op “Opslaan” klikt of een websocket opent, “praat” je niet met de server in één vloeiende stroom. Je app geeft data aan het besturingssysteem, dat het in pakketten hakt en over vele afzonderlijke netwerken stuurt—elke hop maakt zijn eigen beslissingen.
Een veelvoorkomende verrassing: je kunt goede throughput hebben en toch een trage UI omdat elk verzoek wacht op round trips.
TCP herprobeert verloren pakketten, maar het kan niet weten wat “te lang” betekent voor de gebruikerservaring. Daarom voegen applicaties toe:
Pakketten kunnen vertraagd, uit volgorde, gedupliceerd of gedropt worden. Congestie kan latency laten pieken. Een server kan antwoorden maar het antwoord bereikt je nooit. Dit komt terug als flapperende tests, willekeurige 504s of “het werkt op mijn machine.” Vaak is de code prima—het pad tussen machines niet.
Cloudplatforms kunnen voelen als een compleet nieuw soort computing—managed databases, serverless functies, “onbegrensde” schaal. Onder de motorkap rijden je requests nog steeds over dezelfde TCP/IP- fundamenten die Bob Kahn hielp mogelijk maken: IP transporteert pakketten tussen netwerken, en TCP (of soms UDP) bepaalt hoe applicaties dat netwerk ervaren.
Virtualisatie en containers veranderen waar software draait en hoe het verpakt is:
Maar dat zijn implementatiedetails. De pakketten gebruiken nog steeds IP-adressering en routering, en veel verbindingen vertrouwen nog op TCP voor geordende, betrouwbare levering.
Veelvoorkomende cloudarchitecturen zijn opgebouwd uit vertrouwde netwerkbouwstenen:
Zelfs als je nooit een IP-adres ziet, wijst het platform ze toe, routeert pakketten en volgt verbindingen achter de schermen.
TCP kan herstellen van verloren pakketten, ordering herstellen en zich aanpassen aan congestie—maar het kan het onmogelijke niet beloven. In cloudsystemen is betrouwbaarheid teamwork:
Dit is ook waarom platforms die snel volledige apps genereren en deployen nog steeds op dezelfde fundamenten vertrouwen. Bijvoorbeeld, Koder.ai kan je helpen snel een React-webapp met een Go-backend en PostgreSQL op te zetten, maar zodra die app met een API, database of mobiele client praat, zit je weer in TCP/IP-territorium—verbindingen, timeouts, retries en alles wat daarbij hoort.
Als ontwikkelaars het over "het netwerk" hebben, kiezen ze vaak tussen twee transports: TCP en UDP. Beide draaien bovenop IP, maar maken heel verschillende afwegingen.
TCP is geschikt als je data in volgorde en zonder gaten moet aankomen en je liever wacht dan gokken. Denk aan: webpagina’s, API-calls, bestandsoverdrachten, databaseverbindingen.
Daarom draait veel van het dagelijkse internet erop—HTTPS loopt over TCP (via TLS) en veel request/response-software verwacht TCP-gedrag.
Kanttekening: TCP-betrouwbaarheid kan latentie toevoegen. Als één pakket ontbreekt, kunnen latere pakketten worden vastgehouden totdat de kloof gevuld is (“head-of-line blocking”). Voor interactieve ervaringen kan dat wachten erger aanvoelen dan een occasionele glitch.
UDP is meer van “stuur een bericht en hoop dat het aankomt.” Er is geen ingebouwde ordering, retransmissie of congestiebeheer op UDP-niveau.
Ontwikkelaars kiezen UDP wanneer timing belangrijker is dan perfectie, zoals live audio/video, gaming of realtime telemetrie. Veel van deze apps bouwen hun eigen lichte betrouwbaarheid (of geen) op basis van wat gebruikers daadwerkelijk merken.
Een modern voorbeeld: QUIC draait over UDP, waardoor applicaties sneller verbindingen kunnen opzetten en sommige TCP-knelpunten kunnen vermijden—zonder veranderingen aan het onderliggende IP-netwerk.
Kies op basis van:
TCP/IP is een gedeelde set netwerknormen die verschillende netwerken met elkaar laat communiceren en toch data voorspelbaar laat verplaatsen.
Het is belangrijk omdat het onbetrouwbare, heterogene verbindingen (Wi‑Fi, LTE, glasvezel, satelliet) bruikbaar maakt voor software—zodat apps ervan uit kunnen gaan dat ze bytes kunnen versturen en responsen kunnen ontvangen zonder de fysieke netwerkdetails te hoeven kennen.
Bob Kahn stimuleerde het idee van “internetworking”: verbind netwerken met elkaar zonder ze te dwingen dezelfde hardware of interne opzet te gebruiken.
Samen met medewerkers (met name Vint Cerf) hielp hij het ontwerp te vormen waarin IP adressering en routering tussen netwerken regelt en TCP betrouwbaarheid voor applicaties erboven verzorgt.
Pakketgeschakeling breekt een bericht op in kleine pakketten die onafhankelijk kunnen reizen.
Voordelen:
IP heeft één taak: pakketten richting een bestemmingsadres sturen. Het garandeert geen levering, volgorde of timing.
Dit “best effort”-model schaalt omdat routers simpel en snel blijven, en het netwerk kan blijven functioneren terwijl links falen, routes veranderen en nieuwe netwerken meedoen.
TCP verandert IP’s best-effort pakketten in een applicatievriendelijke geordende byte-stream.
Het doet dit met:
Ze lossen verschillende problemen op:
Goede prestaties vereisen beide: een snelle zender moet zowel de ontvanger als het netwerk respecteren.
Layering scheidt verantwoordelijkheden zodat elk onderdeel onafhankelijk kan evolueren.
Voor ontwikkelaars betekent dit dat je API’s kunt bouwen zonder je applicatie voor elk netwerktype opnieuw uit te vinden.
Het end-to-endprincipe houdt de netwerk-kern (routers) relatief simpel en legt ‘slimme’ logica bij de endpoints.
Praktisch gevolg: apps en besturingssystemen regelen betrouwbaarheid, timeouts, retries en encryptie (vaak via TLS), omdat het netwerk gedrag niet per applicatie kan afstemmen.
Latentie is roundtrip-tijd; het schaadt chatty patronen (veel kleine verzoeken, redirects, herhaalde oproepen).
Throughput is bytes per seconde; het beïnvloedt grote overdrachten (uploads, afbeeldingen, backups).
Praktische tips:
Kies op basis van je behoeften:
Vuistregel: als je app request/response is en correctheid voorop staat, begin met TCP (of QUIC via HTTP/3).