Cloudflare runt het snelste netwerk ter wereld. Vandaag hebben we een update gegeven over de manier waarop we onze softwaretechnologie transformeren om elk van onze servers te versnellen en zo de snelheid wereldwijd te verbeteren.
Maar we doen nog zoveel meer. We willen de snelheid nog verder verbeteren, en daarom moeten we ervoor zorgen dat ons netwerk de dagelijkse drukte op het internet goed aankan en het verkeer naar onze steeds snellere servers doorstuurt.
Wij investeren al jaren in een goede beheersing van de verkeersdrukte. Vandaag delen we hoe we de superkracht van ons netwerk, namelijk onze vele Free Plan-gebruikers, voor al onze klanten wereldwijd inzetten om de prestaties te optimaliseren en de beste manier te vinden om het verkeer via ons netwerk te routeren.
Uit de eerste resultaten blijkt dat de prestaties gemiddeld 10% sneller zijn verbeterd vergeleken met de vorige basislijn. We hebben dit gerealiseerd door verschillende algoritmische methoden voor prestatieverbetering toe te passen op basis van de gegevens die we dagelijks over het internet verzamelen. We zullen deze verbeteringen naar alle klanten uitrollen.
Hoe komt het verkeer in ons netwerk terecht?
Het internet is een enorme verzameling van onderling verbonden netwerken die elk uit vele machines ('knooppunten') bestaan. De gegevens worden verzonden door ze op te delen in kleine pakketjes en deze van de ene machine naar de andere te sturen (via een 'verbinding'). Elk van deze machines is met vele andere verbonden, en elke verbinding heeft een beperkte capaciteit.
Wanneer we een pakket via internet versturen, reist het via een reeks zogenaamde 'hops' over de verbindingen van A naar B. Op elk willekeurig moment zal er één verbinding (één 'hop') zijn met de minste beschikbare capaciteit voor die route. Het maakt niet uit waar in de verbinding deze hop zich bevindt: dat is de bottleneck.
En er is een uitdaging: als je gegevens via internet verstuurt, weet je van tevoren niet welke route zal worden afgelegd. Eigenlijk bepaalt elk knooppunt zelf via welke route het verkeer zal worden geleid. Twee pakketten die van A naar B gaan, kunnen bovendien langs twee compleet verschillende routes worden geleid. Het dynamische en gedecentraliseerde karakter van het systeem maakt het internet zo effectief. Het zorgt er echter ook voor dat het lastig is om te bepalen hoeveel data er verzonden kan worden. Hoe kan een verzender weten waar de knelpunten zitten en hoe snel de gegevens verzonden kunnen worden?
Tussen de knooppunten van Cloudflare maakt ons Argo Smart Routing-product gebruik van ons inzicht in het wereldwijde netwerk om de communicatie te versnellen. Wanneer we verbindingen met klantbronnen tot stand brengen, kunnen we ook Argo en andere inzichten gebruiken om die verbindingen te optimaliseren. De snelheid van een verbinding van jouw telefoon of laptop (die hieronder de 'client' wordt genoemd) naar het dichtstbijzijnde Cloudflare-datacenter is echter afhankelijk van de capaciteit van de bottleneck-hop in de keten van jouw apparaat naar Cloudflare, die buiten ons netwerk plaatsvindt.
Wat gebeurt er als er teveel gegevens tegelijk binnenkomen?
Als er op een knooppunt in een netwerk op de route van een verwerkte aanvraag te veel gegevens binnenkomen, ervaart de aanvrager vertragingen vanwege deze verkeersdrukte. De gegevens worden dan ofwel een tijdje in de wachtrij gezet (met het risico op bufferbloat), ofwel worden sommige gegevens gewoonweg verwijderd. Protocollen als TCP en QUIC reageren op gedropte pakketten door de gegevens opnieuw te verzenden. Dit veroorzaakt echter een vertraging en kan het probleem zelfs verergeren doordat de beperkte capaciteit verder wordt overbelast.
Als aanbieders van cloudinfrastructuur, zoals Cloudflare, de verkeersdrukte niet zorgvuldig aanpakken, bestaat het risico dat het systeem overbelast raakt en de snelheid waarmee gegevens worden doorgestuurd, afneemt. Dit gebeurde in de begindagen van het internet. Om dit te voorkomen, heeft de internetinfrastructuur-gemeenschap systemen ontwikkeld om de verkeersdrukte te beheersen. Hierdoor krijgt iedereen de kans om gegevens te versturen, zonder dat het netwerk overbelast raakt. Dit is een continue uitdaging, omdat het netwerk steeds complexer wordt. Er wordt daarom voortdurend gezocht naar de beste methode om de verkeersdrukte goed aan te sturen. Er zijn veel verschillende algoritmes ontwikkeld die gebruikmaken van verschillende informatie- en signaalbronnen, deze op een specifieke manier optimaliseren en dus op verschillende manieren op de verkeersdrukte reageren.
De algoritmen voor het beheersen van de verkeersdrukte gebruiken een aantal signalen om de juiste verkeerssnelheid in te schatten, zonder dat hierbij bekend is hoe het netwerk is opgezet. Een belangrijk signaal was altijd het verlies. Wanneer een pakket wordt ontvangen, stuurt de ontvanger een 'ACK', waarmee de verzender wordt geïnformeerd dat het pakket is ontvangen. Als het pakket ergens onderweg is verdwenen, krijgt de verzender geen ontvangstbevestiging en wordt het pakket na een time-out als verloren beschouwd.
Recentere algoritmen maken gebruik van aanvullende gegevens. Een populair algoritme, BBR (Bottleneck Bandwidth & Round-trip propagatietijd), dat we al een tijd voor een groot deel van ons verkeer hebben gebruikt, probeert tijdens elke verbinding een model te bouwen van de maximale hoeveelheid data die in een bepaalde tijdsperiode kan worden verzonden. Hierbij worden schattingen van de rondetijd en verliesinformatie gebruikt.
Welk algoritme het beste werkt, hangt vaak van de werklast af. Bij interactief verkeer, zoals een videogesprek, kan een algoritme dat te veel verkeer stuurt, bijvoorbeeld wachtrijen veroorzaken. Dit leidt tot een hoge latentie en een slechte video-ervaring. Als dit ene gebruiksgeval geoptimaliseerd zou worden door minder verkeer te versturen, dan maakt het netwerk niet optimaal gebruik van de verbinding voor clients die grote datahoeveelheden downloaden. Het resultaat van prestatie-optimalisatie varieert en is afhankelijk van veel verschillende factoren. Maar – we hebben inzicht in veel van deze factoren!
BBR was een interessante ontwikkeling in de aanpak van verkeerstdruktebeheersing, waarbij de overstap werd gemaakt van reactieve, op verlies gebaseerde benaderingen naar proactieve, op modellen gebaseerde optimalisatie. Dit resulteerde in aanzienlijk betere prestaties voor moderne netwerken. Met de gegevens die wij verzamelen, kunnen we nog verder gaan en verschillende algoritmische methoden toepassen om de prestaties te verbeteren.
Alle bestaande algoritmen kunnen alleen de informatie gebruiken die wordt verzameld tijdens de levensduur van de actuele verbinding. Gelukkig beschikken we op elk gegeven moment over veel meer internetinformatie! Dankzij Cloudflare's algehele overzicht van het internetverkeer kunnen wij te allen tijde veel meer zien dan een individuele klant of internetprovider.
Elke dag ontvangen wij het verkeer van vrijwel alle grote netwerken ter wereld. Wanneer ons systeem een verzoek ontvangt, weten we met welk clientapparaat we communiceren, welk type netwerk de verbinding mogelijk maakt en of we communiceren met consumenten-internetproviders of aanbieders van cloudinfrastructuur.
Wij kennen de belastingpatronen van het wereldwijde internet en de locaties waar de systemen volgens ons overbelast zijn, zowel binnen ons netwerk als daarbuiten. We kennen de stabiele netwerken met een hoog pakketverlies vanwege mobiele dataverbindingen, en de netwerken die lage satellietverbindingen gebruiken en hun routes om de 15 seconden totaal wijzigen.
Hoe gaat dat in zijn werk?
We zijn bezig met het migreren van onze netwerktechnologiestack om een nieuw platform te gebruiken, aangestuurd door Rust. Dit platform biedt meer flexibiliteit om te experimenteren met het variëren van de parameters van de algoritmen die voor verkeersdruktebeheer worden gebruikt. Het enige dat we daarvoor nodig hebben is data.
De gegevens die voor deze experimenten worden gebruikt, moeten een weerspiegeling zijn van de maatstaf die we willen optimaliseren: de gebruikerservaring. Het is niet voldoende dat we gegevens naar bijna alle netwerken ter wereld sturen; we moeten ook kunnen zien welke ervaring de klanten hebben. Hoe doen we dat dan, op deze grote schaal?
Ten eerste beschikken we over uitgebreide 'passieve' logboeken van de snelheid waarmee gegevens via ons netwerk kunnen worden verzonden en hoe lang het duurt voordat de bestemming de ontvangst bevestigt. Dit geldt voor al ons verkeer en geeft ons inzicht in hoe snel de gegevens door de klant zijn ontvangen. Het geeft echter geen garantie dat we iets over de gebruikerservaring te weten komen.
Vervolgens hebben we een systeem voor het verzamelen van Real User Measurement (RUM)-gegevens, waarmee informatie over statistieken zoals Page Load Time (PLT) in ondersteunde webbrowsers wordt vastgelegd. Elke Cloudflare-klant kan dit inschakelen en ontvangt een gedetailleerd overzicht op zijn dashboard. Daarnaast gebruiken we al deze metadata voor al onze klanten en netwerken, om beter te begrijpen wat klanten daadwerkelijk ervaren.
RUM-gegevens zijn echter alleen beschikbaar voor een klein deel van de verbindingen op ons netwerk. Daarom hebben we een manier gezocht om de RUM-metingen te voorspellen door ze te deduceren op basis van de gegevens die we alleen in de passieve logboeken zien. Hier zijn bijvoorbeeld de resultaten van een experiment dat we hebben uitgevoerd waarbij we twee verschillende algoritmen met de kubieke basislijn hebben vergeleken.
Hier is dezelfde tijdschaal, waargenomen via de voorspelling op basis van onze passieve logboeken. De curven lijken erg op elkaar. Maar belangrijker nog: de verhouding tussen de curven lijkt erg op elkaar. Dat is erg belangrijk! We kunnen een relatief kleine hoeveelheid RUM-gegevens gebruiken om onze bevindingen te valideren, maar we kunnen ons netwerk op een veel betere manier optimaliseren door al onze passieve logboeken te benutten.
Als we dit te ver doortrekken, wordt de informatie echter onbetrouwbaar. Daarom werken we ook met een aantal van onze grootste klanten samen om ons inzicht in het gedrag van het netwerk vanuit het perspectief van hun klanten te verbeteren. Zo kunnen we dit voorspellende model nog verder uitbreiden. In ruil daarvoor kunnen wij onze klanten inzicht geven in de daadwerkelijke ervaring van hun klanten, op een wijze waar geen enkel ander platform aan kan tippen.
Momenteel voeren we experimenten uit en verbeteren we de algoritmes voor de beheersing van al ons gratis QUIC-verkeer. Naarmate we meer leren, onze gegevens bij complexere klanten verifiëren en uitbreiden naar TCP-verkeer, zullen we dit geleidelijk in de loop van 2026 en daarna naar al onze klanten en voor al het verkeer uitrollen. De resultaten vertonen een verbetering van maar liefst 10% ten opzichte van de basislijn!
We werken met specifieke ondernemingen samen om dit te testen in een 'early access'-programma. Als je hier meer over wilt weten, neem dan contact met ons op!