Bidirectionele streaming: hoe computers eindelijk tegelijk kunnen praten én luisteren
Stel je een ouderwets walkietalkie-gesprek voor: je moet wachten tot de ander klaar is met praten en "over" zegt, voordat jij aan de beurt bent. Zo werkte internet decennialang ook: je computer (de client) stuurde een verzoek naar een server, wachtte op het antwoord, en pas daarna kon er weer iets nieuws gestuurd worden. Bidirectionele streaming doorbreekt dat om-en-om-patroon. Het is meer als een gewoon telefoongesprek: beide kanten hebben de lijn continu open en kunnen op elk moment praten én luisteren, zonder op hun beurt te wachten.
Dat klinkt misschien als een detail voor techneuten, maar het is de reden waarom je tegenwoordig een AI-spraakassistent kunt onderbreken terwijl hij nog aan het antwoorden is, waarom een videobelgesprek vloeiend aanvoelt, en waarom apps als kaartjes of navigatiesystemen realtime updates kunnen doorgeven zonder dat je steeds op "vernieuwen" hoeft te drukken. Bidirectionele streaming is de technische motor achter veel van de "levende", direct reagerende digitale ervaringen die we inmiddels gewoon vinden.
Wat is het precies?
Om te snappen wat bidirectionele streaming toevoegt, helpt het om te weten hoe het klassieke web werkt. Bij een gewone website stuurt je browser een verzoek ("geef mij deze pagina"), de server stuurt het antwoord terug, en daarna wordt de verbinding weer gesloten. Wil je nieuwe informatie? Dan begin je opnieuw met een verzoek. Dit heet request-response-verkeer: eenrichtingsverkeer per beurt, ook wel half-duplex genoemd (er kan maar in één richting tegelijk iets zinvols gebeuren).
Bidirectionele streaming, ook wel full-duplex-communicatie genoemd, werkt anders. Er wordt één verbinding geopend die openblijft, en over die ene verbinding kunnen beide kanten op elk moment stukjes data ("frames" of "berichten") sturen, onafhankelijk van elkaar. De server hoeft niet te wachten tot de client iets vraagt, en de client hoeft niet te wachten tot de server klaar is met antwoorden.
Dit wordt mogelijk gemaakt door een aantal technische protocollen. WebSocket (vastgelegd door internetstandaardenorganisatie IETF in 2011) was een van de eerste wijdverspreide manieren om dit in browsers te doen: één TCP-verbinding die openblijft en waarover beide kanten vrij berichten sturen. HTTP/2 (2015) voegde iets vergelijkbaars toe aan het gewone webprotocol, door meerdere datastromen tegelijk over één verbinding te laten lopen ("multiplexing"). Daarop bouwt gRPC, een communicatietechniek die Google in 2015 open source maakte en die nu wordt beheerd door de Cloud Native Computing Foundation (CNCF); gRPC kent expliciet een modus "bidirectional streaming", naast varianten waarbij maar één kant continu stuurt. Nog nieuwer is QUIC, de basis van HTTP/3 (IETF, 2021), dat niet op het gebruikelijke TCP maar op het snellere UDP is gebouwd om vertraging te verminderen. En voor rechtstreekse audio- en videocommunicatie tussen twee apparaten, zonder tussenkomst van een server, bestaat WebRTC, een open standaard van de W3C en IETF.
Het gemeenschappelijke idee achter al deze technieken: één langdurige verbinding, data die in kleine stukjes (streams) heen en weer blijft stromen, en geen overhead van steeds opnieuw een verzoek moeten opbouwen.
Wat wil men ermee bereiken?
Het belangrijkste doel is latency verminderen — de vertraging tussen het moment dat je iets doet en het moment dat je een reactie merkt. Bij traditioneel request-response-verkeer moet voor elke nieuwe hap informatie een nieuwe ronde worden opgebouwd, wat tijd kost. Bij een permanent open, bidirectionele verbinding verdwijnt die herhaalde opbouwtijd, en kan informatie sneller en met minder "hobbels" stromen.
Een tweede doel is natuurlijkheid van interactie. Mensen praten niet in strikte om-de-beurt-blokjes; we onderbreken elkaar, reageren halverwege een zin, en luisteren terwijl we nadenken over ons eigen antwoord. Voor spraakgestuurde AI-systemen is bidirectionele streaming daarom essentieel: zonder deze techniek moet de AI wachten tot je helemaal uitgesproken bent, je zin verwerken, en dan pas beginnen met antwoorden — met merkbare, onnatuurlijke stiltes tot gevolg.
Ten derde is er een efficiëntiedoel binnen software zelf. Grote toepassingen bestaan vaak uit tientallen of honderden kleine onderdelen ("microservices") die voortdurend met elkaar moeten communiceren. Bidirectionele streaming, zoals via gRPC, laat deze onderdelen data continu uitwisselen zonder telkens nieuwe verbindingen op te zetten, wat rekenkracht en tijd bespaart.
Voorbeelden uit de praktijk
gRPC in microservices (sinds 2015): bedrijven als Netflix, Square en talloze andere techbedrijven gebruiken gRPC om hun interne systemen met elkaar te laten praten. De bidirectionele streaming-modus wordt bijvoorbeeld gebruikt voor live dataverwerking, zoals het continu doorgeven van sensordata of gebruikersactiviteit.
WebRTC in videobellen: videobelapplicaties zoals Google Meet gebruiken WebRTC om audio en video rechtstreeks tussen deelnemers te streamen, met minimale vertraging. De standaard werd rond 2011 door Google geïnitieerd en is sindsdien via W3C en IETF verder gestandaardiseerd.
OpenAI Realtime API / GPT-4o spraakmodus (oktober 2024): tijdens OpenAI's ontwikkelaarsevenement DevDay in 2024 introduceerde het bedrijf een API waarmee ontwikkelaars apps kunnen bouwen die doorlopend spraak sturen naar en ontvangen van het GPT-4o-model, via een open WebSocket-verbinding. Gebruikers kunnen de AI midden in een zin onderbreken, iets wat zonder bidirectionele streaming vrijwel onmogelijk vlot te bouwen is.
Google Gemini Live API (2024): Google bracht een vergelijkbare functionaliteit uit voor zijn Gemini-modellen, gericht op realtime, spreekbare interactie inclusief beeld- en video-invoer, eveneens gebaseerd op een continu open, bidirectionele verbinding.
5G en "ultra-betrouwbare lage-latency communicatie" (URLLC): de telecomstandaard 5G definieert URLLC als een van de drie hoofdtoepassingen, bedoeld voor scenario's als op afstand bediende chirurgische robots en communicatie tussen zelfrijdende voertuigen, waarbij razendsnelle, tweerichtingsdata-uitwisseling cruciaal is. Praktijktoepassingen hiervan zijn vooralsnog vooral experimenteel.
Hoe ver is de techniek?
De onderliggende protocollen zelf zijn inmiddels volwassen technologie. WebSocket, HTTP/2 en WebRTC worden al jaren op grote schaal gebruikt en zijn stabiele, breed ondersteunde standaarden. gRPC is eveneens goed ingeburgerd in de softwarewereld, vooral binnen bedrijven met complexe, uit veel onderdelen opgebouwde systemen.
Wat wél nog volop in ontwikkeling is, is de toepassing ervan in realtime AI-spraak- en video-interactie. De Realtime API van OpenAI en de Live API van Google zijn pas sinds 2024 beschikbaar en worden nog regelmatig aangepast. Bekende knelpunten zijn de kosten van dit soort continue AI-verbindingen (ze zijn duurder dan losse tekstverzoeken), het risico dat een AI-systeem een gebruiker verkeerd "onderbreekt" of juist te laat reageert, en de afhankelijkheid van een stabiele, snelle internetverbinding om de beloofde vloeiendheid ook echt te ervaren.
Op telecomgebied blijft de daadwerkelijke uitrol van ultra-lage-latency 5G-toepassingen (URLLC) achter bij de aanvankelijke verwachtingen uit rond 2018-2019: grootschalige, betrouwbare toepassingen zoals telechirurgie zijn nog grotendeels in de pilot- en onderzoeksfase. De opvolger 6G bevindt zich bij de internationale telecomstandaardisatie-organisatie 3GPP nog in een vroege onderzoeksfase, met een verwachte eerste uitrol niet eerder dan rond 2030 — al is dat soort tijdlijnen in de telecomsector historisch gezien vaak optimistisch gebleken.
Wie werken eraan?
Aan de standaarden zelf werken internationale, open samenwerkingsverbanden: de IETF (Internet Engineering Task Force) beheert onder meer de standaarden achter WebSocket, HTTP/2 en QUIC/HTTP-3. Het W3C (World Wide Web Consortium) is samen met de IETF verantwoordelijk voor WebRTC. De Cloud Native Computing Foundation, met Google als initiële ontwikkelaar, beheert gRPC.
Op het vlak van realtime AI-interactie lopen OpenAI en Google (Google DeepMind) momenteel voorop met hun respectievelijke Realtime en Live API's; ook Microsoft (via Azure) biedt vergelijkbare realtime-spraakdiensten aan gebaseerd op onder meer OpenAI-technologie.
In de telecomsector wordt 5G en de toekomstige 6G-standaard ontwikkeld binnen 3GPP, een samenwerkingsverband van regionale telecomstandaardisatie-organisaties uit onder meer Europa, de Verenigde Staten, China, Japan en Zuid-Korea, met grote inbreng van netwerkfabrikanten als Ericsson, Nokia en Qualcomm en operators wereldwijd.