De ontwikkeling van technologieƫn op het gebied van software en hardware, de opkomst van nieuwe communicatieprotocollen heeft geleid tot een uitbreiding van het Internet of Things (IoT). Het aantal apparaten groeit elke dag, en zij genereren enorme hoeveelheden gegevens. Daarom is er behoefte aan een handige systeemarchitectuur die deze gegevens kan verwerken, opslaan en verzenden.
Op dit moment worden cloudservices hiervoor gebruikt. De steeds populairder wordende paradigmata van fog computing (mistcomputing) kan echter cloudoplossingen aanvullen, waardoor de IoT-infrastructuur geschaald en geoptimaliseerd kan worden.
āCloudsā kunnen de meeste behoeften van IoT dekken. Bijvoorbeeld, ze kunnen de monitoring van services verzorgen, snelle verwerking van elke hoeveelheid gegevens die door apparaten worden gegenereerd, evenals hun visualisatie. Fog computing is echter efficiĆ«nter bij het oplossen van real-time taken. Het zorgt voor een snelle respons op verzoeken en minimale vertraging bij de verwerking van gegevens. Dit betekent dat fog de ācloudā aanvult en zijn mogelijkheden uitbreidt.
De belangrijkste vraag is echter: hoe moet dit alles interageren in de context van IoT? Welke communicatieprotocollen zullen het effectiefst zijn in de werkomgeving van het gecombineerde systeem IoT-Fog-Cloud?
Ondanks het ogenschijnlijke domineren van HTTP, worden er in IoT-, Fog- en Cloud-systemen veel andere oplossingen gebruikt. Dit komt doordat IoT functionele mogelijkheden van verschillende sensoren van apparaten moet combineren met beveiliging, compatibiliteit en andere eisen die door gebruikers worden gesteld.
Er is alleen geen eenduidig idee over de referentiearchitectuur en communicatiestandaard. Daarom is het creƫren van een nieuw protocol of het aanpassen van een bestaand protocol voor specifieke IoT-taken een van de belangrijkste taken van de IT-gemeenschap.
Welke protocollen worden momenteel gebruikt en wat kunnen ze bieden? Laten we het uitzoeken. Maar laten we eerst de principes van het ecosysteem bespreken waarin clouds, mist en het Internet of Things samenwerken.
Architectuur IoT Fog-to-Cloud (F2C)
U heeft ongetwijfeld opgemerkt hoeveel aanzienlijke inspanningen worden geleverd om de voordelen en voordelen van rationeel en gecoƶrdineerd beheer van IoT, clouds en mist te bestuderen. Als dat niet zo is, hier zijn drie initiatieven voor standaardisatie: , en .
Als eerder alleen 2 niveaus werden overwogen, namelijk cloud en eindapparaten, introduceert de voorgestelde architectuur een nieuw niveau ā fog computing. Dit fog-niveau kan worden verdeeld in verschillende subniveaus, afhankelijk van de specificiteit van de resources of de set van beleidsregels die het gebruik van verschillende apparaten in deze subniveaus bepalen.
Hoe kan deze abstractie eruit zien? Hier is een typische IoT-Fog-Cloud-ecosysteem. IoT-apparaten sturen gegevens naar meer krachtige servers en rekeneenheden om taken op te lossen die een laag niveau van vertraging vereisen. In dit systeem zijn cloud-diensten verantwoordelijk voor taken die veel rekenkracht of opslagruimte vereisen.
Smartphones, smartwatches en andere gadgets kunnen ook deel uitmaken van het IoT. Maar deze apparaten gebruiken doorgaans propriƫtaire communicatieve protocollen van grote ontwikkelaars. Genereerde IoT-gegevens worden via het REST HTTP-protocol naar het fog-niveau verzonden, wat flexibiliteit en functionele compatibiliteit garandeert bij het creƫren van RESTful-diensten. Dit is belangrijk in het licht van de noodzaak om compatibiliteit te waarborgen met de bestaande computinfrastructuur die op lokale computers, servers of serverclusters werkt. Lokale resources, aangeduid als "fog-nodes", filteren de ontvangen gegevens en verwerken deze lokaal, of sturen ze door naar de cloud voor verdere berekeningen.
Cloud-diensten ondersteunen verschillende communicatieve protocollen, waarbij AMQP en REST HTTP het meest voorkomende zijn. Aangezien HTTP algemeen bekend is en is geoptimaliseerd voor het internet, kan de vraag rijzen: "Waarom niet gebruiken voor IoT en fog?" Echter, dit protocol heeft prestatieproblemen. Dit later meer.
Over het algemeen zijn er 2 modellen van communicatieve protocollen die geschikt zijn voor ons systeem. Dit zijn request-response en publish-subscribe. Het eerste model is breder bekend, vooral in de client-serverarchitectuur. De client vraagt informatie van de server aan, en de server ontvangt het verzoek, verwerkt het en retourneert een antwoord. Protocols zoals REST HTTP en CoAP werken volgens dit model.
Het tweede model ontstond uit de noodzaak om asynchrone, gedistribueerde, zwakke verbindingen te waarborgen tussen gegevensbronnen die gegevens genereren en de ontvangers van deze gegevens.
Het model omvat drie deelnemers: de uitgever (gegevensbron), de broker (dispatcher) en de abonnee (ontvanger). Hier hoeft de klant, die fungeert als abonnee, geen informatie van de server aan te vragen. In plaats van verzoeken te versturen, abonneert hij zich op specifieke gebeurtenissen in het systeem via de broker, die verantwoordelijk is voor het filteren van alle binnenkomende berichten en het routeren ervan tussen uitgevers en abonnees. Wanneer er een gebeurtenis plaatsvindt die betrekking heeft op een specifiek onderwerp, publiceert de uitgever deze aan de broker, die de gegevens naar de abonnee verzendt over het gevraagde onderwerp.
In wezen is deze architectuur gebaseerd op gebeurtenissen. Dit soort interactiemodel is interessant voor applicaties in IoT, cloud en fog vanwege het vermogen om schaalbaarheid te bieden en de verbinding tussen verschillende apparaten te vereenvoudigen, evenals het ondersteunen van dynamische āveel-naar-veelā en asynchrone communicatie. Onder de meest bekende gestandaardiseerde berichtenprotocollen die het āpublicatie-abonnementā model gebruiken, zijn MQTT, AMQP en DDS te noemen.
Het is duidelijk dat het model āpublicatie-abonnementā veel voordelen heeft:
- Uitgevers en abonnees hoeven elkaar niet te kennen;
- Een abonnee kan informatie van vele verschillende publicaties ontvangen, en een uitgever kan gegevens naar vele verschillende abonnees verzenden (het āveel-naar-veelā principe);
- De uitgever en de abonnee hoeven niet tegelijkertijd actief te zijn om gegevens uit te wisselen, omdat de broker (die als een queuesysteem functioneert) het bericht kan opslaan voor klanten die op dat moment niet met het netwerk zijn verbonden.
Toch heeft ook het āverzoek-antwoordā model zijn sterke punten. In gevallen waarin de servercapaciteit voor het verwerken van verzoeken van meerdere klanten geen probleem is, is het logisch om gebruik te maken van al bewezen betrouwbare oplossingen.
Er zijn ook protocollen die beide modellen ondersteunen. Bijvoorbeeld, XMPP en HTTP 2.0, die de optie 'server push' ondersteunen. De IETF heeft ook CoAP uitgebracht. In een poging om het probleem van berichtenuitwisseling op te lossen, zijn er verschillende andere oplossingen ontwikkeld, zoals het WebSockets-protocol of het gebruik van het HTTP-protocol via QUIC (Quick UDP Internet Connections).
Wat WebSockets betreft, hoewel het wordt gebruikt voor het verzenden van gegevens in real-time van server naar webclient en constante verbindingen met gelijktijdige bidirectionele communicatie biedt, is het niet bedoeld voor apparaten met beperkte rekenkracht. QUIC verdient ook aandacht, aangezien het nieuwe transportprotocol veel nieuwe mogelijkheden biedt. Maar omdat QUIC nog niet is gestandaardiseerd, is het prematuur om de mogelijke toepassingen en impact op oplossingen in het IoT te voorspellen. Dus laten we WebSockets en QUIC in gedachten houden voor de toekomst, maar voorlopig niet verder onderzoeken.
Wie is de liefste ter wereld: we vergelijken protocollen
Laten we nu de sterke en zwakke punten van de protocollen bespreken. Om vooruit te lopen op de zaak, laten we meteen opmerken dat er geen duidelijke leider is. Elk protocol heeft zijn eigen voor- en nadelen.
Reactietijd
Een van de belangrijkste kenmerken van communicatieve protocollen, vooral in verband met het internet der dingen, is de reactietijd. Maar onder de bestaande protocollen is er geen onbetwiste winnaar die het minimale niveau van vertraging onder verschillende omstandigheden demonstreert. Er zijn echter een heleboel onderzoeken en vergelijkingen van de mogelijkheden van de protocollen.
Bijvoorbeeld, vergelijking van de prestaties van HTTP en MQTT in de context van IoT toonde aan dat de reactietijd voor verzoeken bij MQTT lager is dan bij HTTP. En bij de round trip time (RTT) van MQTT en CoAP bleek dat de gemiddelde RTT van CoAP 20% lager is dan die van MQTT.
Andere De RTT van de MQTT- en CoAP-protocols werd getest in twee scenario's: een lokaal netwerk en een IoT-netwerk. Het bleek dat de gemiddelde RTT 2 tot 3 keer hoger was in het IoT-netwerk. MQTT met QoS0 had een lagere score dan CoAP, terwijl MQTT met QoS1 een hogere RTT toonde door ACK op zowel de applicatie- als transportniveau. Voor verschillende QoS-niveaus waren de vertragingen in het netwerk zonder congestie voor MQTT milliseconden, en voor CoAP honderden microseconden. Toch moet worden opgemerkt dat in minder betrouwbare netwerken MQTT, dat over TCP werkt, een heel ander resultaat laat zien.
van de responstijd van de AMQP- en MQTT-protocollen door het verhogen van de payload toonde aan dat de vertraging bij lage belasting bijna hetzelfde was. Maar bij het verzenden van grote hoeveelheden gegevens toont MQTT een kortere responstijd. In een ander werd CoAP vergeleken met HTTP in een scenario voor machine-tot-machine communicatie met apparaten die zijn geĆÆnstalleerd op voertuigen en zijn uitgerust met gassensoren, weerstations, locatie (GPS) en een mobiele netwerkinterface (GPRS). De tijd die nodig was om een CoAP-bericht via een mobiel netwerk te verzenden, was bijna drie keer korter dan de tijd die nodig was voor het gebruik van HTTP-berichten.
Er zijn onderzoeken uitgevoerd waarin niet twee, maar drie protocollen werden vergeleken. Bijvoorbeeld, de prestaties van IoT-protocollen MQTT, DDS en CoAP in een medische toepassing met behulp van een netwerksimulator. DDS overtrof MQTT op het gebied van ervaren telemetrievertraging onder verschillende slechte netwerkomstandigheden. CoAP, gebaseerd op UDP, werkte goed voor toepassingen die snelle reacties vereisten, maar vanwege het feit dat het op UDP is gebaseerd, was er een aanzienlijke onvoorspelbare pakketverlies.
Doorvoersnelheid
MQTT en CoAP werden vergeleken op basis van de efficiƫntie van het gebruik van de bandbreedte, wat werd berekend als het totale aantal gegevens dat per bericht werd verzonden. CoAP toonde een lagere bandbreedte dan MQTT bij het verzenden van kleine berichten. Maar wanneer de efficiƫntie van de protocollen werd vergeleken op basis van de verhouding van het aantal nuttige informaties viaile bytes tot het totale aantal verzonden bytes, bleek CoAP efficiƫnter.
Bij Bij het gebruik van de MQTT-, DDS (met TCP als transportprotocol) en CoAP-bandbreedte bleek dat CoAP over het algemeen een relatief lager bandbreedteverbruik vertoonde, wat niet toenam bij grotere netwerkverliezen of verhoogde netwerklatentie, in tegenstelling tot MQTT en DDS, waarbij een toename van de bandbreedte werd waargenomen in de genoemde scenario's. In een ander scenario was er een groot aantal apparaten dat simultaan gegevens verzond, wat een typisch geval is in IoT-omgevingen. De resultaten toonden aan dat CoAP het beste kon worden gebruikt bij hogere belasting.
Bij een lage belasting gebruikte CoAP de minste bandbreedte, gevolgd door MQTT en REST HTTP. Echter, wanneer de payloads toenamen, had REST HTTP de beste resultaten.
Energieverbruik
De kwestie van energieverbruik is altijd een belangrijk punt, vooral in IoT-systemen. Als het energieverbruik van MQTT en HTTP, dan 'verbruikt' HTTP veel meer. CoAP is energie-efficiƫnter Een experiment, waarin de mogelijkheden van AMQP en MQTT werden vergeleken in een testopstelling met een mobiele of onbetrouwbare draadloze netwerk, toonde aan dat AMQP meer mogelijkheden biedt op het gebied van beveiliging, terwijl MQTT energie-efficiƫnter is.
Beveiliging is een andere belangrijke kwestie die aan de orde komt bij het verkennen van het Internet der Dingen en fog/cloud computing. Het beveiligingsmechanisme is doorgaans gebaseerd op TLS voor HTTP, MQTT, AMQP en XMPP, of DTLS in CoAP, en ondersteunt ook beide varianten van DDS.
Beveiliging
TLS en DTLS beginnen met een proces van het tot stand brengen van verbinding tussen de client- en serverzijde voor de uitwisseling van ondersteunde cipher suites en sleutels. Beide partijen stemmen overeen om ervoor te zorgen dat verdere communicatie plaatsvindt via een veilige verbinding. Het verschil tussen hen ligt in de kleine aanpassingen die DTLS op basis van UDP in staat stellen om via een onbetrouwbare verbinding te werken.
testaanvallen
Bij Bij verschillende implementaties van TLS en DTLS bleek dat TLS beter presteerde. Aanvallen op DTLS waren succesvoller vanwege zijn fouttolerantie.
Toch ligt het grootste probleem van deze protocollen in het feit dat ze aanvankelijk niet zijn ontworpen voor gebruik in IoT en geen rekening hielden met operaties in de mist of de cloud. Via handshaking voegen ze extra verkeer toe bij elke verbinding, wat de rekenkracht uitput. Gemiddeld is er een toename van 6,5% voor TLS en 11% voor DTLS in overhead vergeleken met verbindingen zonder beveiligingslaag. In omgevingen met rijke middelen, die vaak zijn gevestigd op , is dit geen probleem, maar in de verbinding tussen IoT en de mistlaag wordt dit een belangrijke beperking.
Wat moet je kiezen? Er is geen eenduidig antwoord. MQTT en HTTP lijken de meest veelbelovende protocollen, aangezien ze relatief volwassen en stabiele oplossingen voor IoT zijn in vergelijking met andere protocollen.
Oplossingen op basis van Ć©Ć©n communicat ŠæŃŠ¾ŃŠ¾ŠŗŠ¾Š»
De praktijk van Ć©Ć©n-protocol oplossingen heeft veel nadelen. Een protocol dat geschikt is voor een beperkte omgeving, werkt mogelijk niet in een domein met strikte veiligheidsvereisten. Met dit in gedachten moeten we bijna alle mogelijke oplossingen op basis van Ć©Ć©n protocol in het Fog-to-Cloud-ecosysteem in IoT terzijde schuiven, behalve MQTT en REST HTTP.
REST HTTP als Ć©Ć©n-protocol oplossing
Er is een goed voorbeeld van verzoek- en antwoordinteractie van REST HTTP in het IoT-to-Fog gebied: . Dieren zijn uitgerust met draagbare sensoren (IoT-client, C) en worden beheerd via cloud computing door een slim landbouwsysteem (Fog-server, S).
In de header van de POST-methode staat de resource die moet worden gewijzigd (\farm\animals) vermeld, evenals de versie van HTTP en het type inhoud, dat in dit geval een JSON-object is dat de veehouderij vertegenwoordigt die door het systeem moet worden beheerd (Dulcinea\koe). Het antwoord van de server geeft aan dat het verzoek succesvol was door een HTTPS-statuscode 201 (resource gemaakt) te sturen. De GET-methode moet alleen de opgevraagde resource in de URI opgeven (bijvoorbeeld \farm\animals\1), die een JSON-presentatie van het dier met deze identificatie van de server retourneert.
De PUT-methode wordt gebruikt wanneer het nodig is om een specifieke record van een bron bij te werken. In dit geval wordt de URI voor de parameter die moet worden gewijzigd en de huidige waarde (bijvoorbeeld die aangeeft dat de koe momenteel aan het grazen is, /farm/animals/1?status=grazen) in de bron opgegeven. Ten slotte wordt de DELETE-methode op dezelfde wijze gebruikt als de GET-methode, maar verwijdert eenvoudigweg de bron als resultaat van de operatie.
MQTT als een enkelprotocoloplossing
Laten we dezelfde slimme boerderij nemen, maar in plaats van REST HTTP gebruiken we het MQTT-protocol. Een lokale server met de Mosquitto-bibliotheek geĆÆnstalleerd fungeert als broker. In dit voorbeeld dient een eenvoudige computer (aangeduid als de boerderijserver) Raspberry Pi als de MQTT-client, gerealiseerd via de installatie van de MQTT Paho-bibliotheek, die volledig compatibel is met de Mosquitto-broker.
Deze client komt overeen met een abstractieniveau van IoT dat een apparaat met detectie- en rekenmogelijkheden vertegenwoordigt. De broker daarentegen komt overeen met een hoger abstractieniveau dat een rekeneenheid in de mist vertegenwoordigt, gekenmerkt door grotere verwerkings- en opslagscapaciteiten.
In het voorgestelde scenario van de 'slimme boerderij' wordt de Raspberry Pi verbonden met een versnellingsmeter, GPS en temperatuursensoren en publiceert deze de gegevens van deze sensoren in een mistknoop. Zoals u waarschijnlijk weet, beschouwt MQTT onderwerpen als een hiƫrarchie. Een MQTT-uitgever kan berichten publiceren in een bepaalde set onderwerpen. In ons geval zijn dat er drie. Voor de sensor die de temperatuur in de dierenhut meet, kiest de client het onderwerp (animalfarm/shed/temperature). Voor de sensoren die de GPS-locatie en beweging van dieren via de versnellingsmeter meten, publiceert de client updates (animalfarm/animal/GPS) en (animalfarm/animal/movement).
Deze informatie zal aan de broker worden doorgegeven, die het tijdelijk kan opslaan in een lokale database voor het geval er later een andere geĆÆnteresseerde abonnee verschijnt.
Naast de lokale server die fungeert als MQTT-broker in de mist, waar Raspberry Pi's als MQTT-clients gegevens van sensoren naar verzenden, kan er op cloudniveau nog een andere MQTT-broker zijn. In dit geval kunnen de gegevens die naar de lokale broker worden verzonden tijdelijk worden opgeslagen in een lokale database en/of naar de cloud worden gestuurd. De mistige MQTT-broker wordt in deze situatie gebruikt om alle gegevens te verbinden met de cloud MQTT-broker. Met deze architectuur kan de gebruiker van de mobiele applicatie zich op beide brokers abonneren.
In het geval van een verbindingseffect met een van de brokers (bijvoorbeeld de cloud), ontvangt de eindgebruiker informatie van de andere (mistige). Dit is een kenmerk van hybride systemen van mist- en cloudcomputing. Standaard kan de mobiele applicatie worden ingesteld om een eerste verbinding te maken met de mistige MQTT-broker, en in geval van mislukking met de MQTT-broker in de cloud. Deze oplossing is slechts een van de vele in IoT-F2C-systemen.
Multiprotocol-oplossingen
Oplossingen met Ć©Ć©n protocol zijn populair vanwege hun eenvoudiger implementatie. Maar het is duidelijk dat het zinvol is om verschillende protocollen te combineren in IoT-F2C-systemen. Het idee is dat verschillende protocollen op verschillende niveaus kunnen werken. Neem bijvoorbeeld drie abstracties: de IoT-, mist- en cloudcomputingniveaus. Apparaten op IoT-niveau worden meestal als beperkt beschouwd. Voor dit overzicht beschouwen we de IoT-niveaus als de meest beperkte, de cloud als het minst beperkte en de mistcomputing als 'ergens daartussenin'. Het blijkt dat de huidige protocoloplossingen tussen IoT en mistabstracties MQTT, CoAP en XMPP omvatten. Tussen de mist en de cloud is AMQP een van de belangrijkste gebruikte protocollen, samen met REST HTTP, dat vanwege zijn flexibiliteit ook wordt gebruikt tussen IoT en de lagen van de mist.
Het belangrijkste probleem hier is de functionele compatibiliteit van protocollen en de eenvoud van het vertalen van berichten van het ene protocol naar het andere. Idealiter zal de architectuur van het IoT-systeem met cloud- en mistbronnen in de toekomst onafhankelijk zijn van het gebruikte communicatietype en een goede interactie tussen verschillende protocollen waarborgen.
Aangezien dit momenteel niet het geval is, is het zinvol om protocollen samen te voegen die geen significante verschillen vertonen. In dit verband is een potentiƫle oplossing gebaseerd op een combinatie van twee protocollen die dezelfde architecturale stijl volgen, REST HTTP en CoAP. Een andere voorgestelde oplossing is gebaseerd op een combinatie van twee protocollen die interactie bieden volgens het 'publicatie-abonnement' model, MQTT en AMQP. Het gebruik van vergelijkbare concepten (zowel MQTT als AMQP maken gebruik van brokers, CoAP en HTTP gebruiken REST) vereenvoudigt de implementatie van deze combinaties en vereist minder inspanning voor integratie.
In figuur (a) zijn twee modellen op basis van verzoek-en-antwoord te zien, HTTP en CoAP, en hun mogelijke plaatsing in de IoT-F2C oplossing. Aangezien HTTP een van de meest bekende en aangepaste protocollen in moderne netwerken is, is het onwaarschijnlijk dat het volledig vervangen zal worden door andere berichtenprotocollen. Onder de knooppunten die krachtige apparaten vertegenwoordigen, die zich tussen de cloud en de mist bevinden, is REST HTTP een redelijk oplossing.
Aan de andere kant is het voor apparaten met beperkte rekenkracht die communiceren tussen de mist- en IoT-niveaus efficiƫnter om CoAP te gebruiken. Een van de grote voordelen van CoAP is eigenlijk de compatibiliteit met HTTP, aangezien beide protocollen zijn gebaseerd op de principes van REST.
In figuur (b) zijn twee 'publicatie-abonnement' interactiemodellen in Ć©Ć©n scenario te zien, inclusief MQTT en AMQP. Hoewel hypothetisch beide protocollen kunnen worden gebruikt voor communicatie tussen knooppunten op elk abstractieniveau, moet hun positie worden bepaald op basis van prestaties. MQTT is ontwikkeld als een vereenvoudigd protocol voor apparaten met beperkte rekenkracht, waardoor het kan worden gebruikt voor communicatie tussen IoT en mist. AMQP is beter geschikt voor krachtigere apparaten, die het perfect tussen de mist- en cloudknooppunten zouden plaatsen. In plaats van MQTT kan in IoT het XMPP-protocol worden gebruikt, aangezien dit als lichtgewicht wordt beschouwd. Maar het wordt niet zo breed toegepast in dergelijke scenario's.
Conclusies
Het is onwaarschijnlijk dat een van de besproken protocollen voldoende zal zijn om de volledige communicatie in het systeem te dekken, beginnend bij apparaten met beperkte rekencapaciteit en eindigend bij cloudservers. Onderzoek heeft aangetoond dat de twee meest veelbelovende opties die door ontwikkelaars worden gebruikt, MQTT en RESTful HTTP zijn. Deze twee protocollen zijn niet alleen de meest volwassen en stabiele, maar bevatten ook tal van goed gedocumenteerde en succesvolle implementaties en online bronnen.
Dankzij de stabiliteit en eenvoudige configuratie is MQTT een protocol dat in de loop der tijd zijn superieure prestaties heeft bewezen bij gebruik op IoT-niveau met beperkte apparaten. In delen van het systeem waar beperkte connectiviteit en batterijverbruik geen probleem zijn, zoals in sommige fog-gebieden en de meeste cloudcomputing, is RESTful HTTP een gemakkelijke keuze. CoAP moet ook in overweging worden genomen, aangezien het zich ook snel ontwikkelt als een standaard voor IoT-berichtenuitwisseling, en het is zeer waarschijnlijk dat het in de nabije toekomst een niveau van stabiliteit en volwassenheid zal bereiken dat vergelijkbaar is met dat van MQTT en HTTP. Maar de standaard is momenteel in ontwikkeling, wat gepaard gaat met kortetermijncompatibiliteitsproblemen.
What else useful can you read in the blog
ā
ā
ā
ā
ā
Subscribe to our -kanaal, zodat je het volgende artikel niet mist! We schrijven niet vaker dan twee keer per week en alleen als het nodig is.
Bron: habr.com
