De ontwikkeling van technologieën op het gebied van software en hardware, de opkomst van nieuwe communicatieprotocollen hebben geleid tot de uitbreiding van het Internet of Things (IoT). Het aantal apparaten groeit met de dag en ze genereren een enorme hoeveelheid gegevens. Daarom is er behoefte aan een handige systeemarchitectuur die deze gegevens kan verwerken, opslaan en verzenden.
Nu worden clouddiensten voor deze doeleinden gebruikt. Het steeds populairder wordende fog computing-paradigma (Fog) kan cloudoplossingen echter aanvullen door de IoT-infrastructuur te schalen en te optimaliseren.
Clouds kunnen de meeste IoT-verzoeken afhandelen. Om bijvoorbeeld services te kunnen monitoren, snelle verwerking van elke hoeveelheid gegevens die door apparaten wordt gegenereerd, en de visualisatie ervan. Fog computing is effectiever bij het oplossen van realtime problemen. Ze bieden een snelle reactie op verzoeken en minimale latentie bij de gegevensverwerking. Dat wil zeggen, Fog vormt een aanvulling op de ‘wolken’ en breidt zijn mogelijkheden uit.
De hoofdvraag is echter anders: hoe moet dit alles op elkaar inwerken in de context van IoT? Welke communicatieprotocollen zijn het meest effectief bij het werken in een gecombineerd IoT-Fog-Cloud-systeem?
Ondanks de schijnbare dominantie van HTTP, wordt er een groot aantal andere oplossingen gebruikt in IoT-, Fog- en Cloud-systemen. Dit komt omdat IoT de functionaliteit van verschillende apparaatsensoren moet combineren met de beveiliging, compatibiliteit en andere vereisten van gebruikers.
Maar er bestaat eenvoudigweg 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 waarmee de IT-gemeenschap wordt geconfronteerd.
Welke protocollen worden momenteel gebruikt en wat kunnen ze bieden? Laten we het uitzoeken. Maar laten we eerst de principes bespreken van het ecosysteem waarin wolken, mist en het internet der dingen op elkaar inwerken.
IoT Fog-to-Cloud (F2C)-architectuur
U heeft waarschijnlijk gemerkt hoeveel moeite er wordt gestoken in het onderzoeken van de voordelen die gepaard gaan met slim en gecoördineerd beheer van IoT, cloud en mist. Zo niet, dan zijn hier drie standaardisatie-initiatieven: , и .
Als voorheen slechts twee niveaus werden overwogen, clouds en eindapparaten, introduceert de voorgestelde architectuur een nieuw niveau: fog computing. In dit geval kan het mistniveau worden onderverdeeld in verschillende subniveaus, afhankelijk van de specifieke kenmerken van de bronnen of een reeks beleidsregels die het gebruik van verschillende apparaten op deze subniveaus bepalen.
Hoe zou deze abstractie eruit kunnen zien? Hier is een typisch IoT-Fog-Cloud-ecosysteem. IoT-apparaten sturen gegevens naar snellere servers en computerapparatuur om problemen op te lossen die een lage latentie vereisen. In hetzelfde systeem zijn wolken verantwoordelijk voor het oplossen van problemen die een grote hoeveelheid computerbronnen of gegevensopslagruimte vereisen.
Ook smartphones, smartwatches en andere gadgets kunnen deel uitmaken van het IoT. Maar dergelijke apparaten gebruiken in de regel eigen communicatieprotocollen van grote ontwikkelaars. De gegenereerde IoT-gegevens worden via het REST HTTP-protocol naar de mistlaag overgedragen, wat flexibiliteit en interoperabiliteit biedt bij het creëren van RESTful-services. Dit is belangrijk in het licht van de noodzaak om achterwaartse compatibiliteit te garanderen met de bestaande computerinfrastructuur die op lokale computers, servers of een servercluster draait. Lokale bronnen, ‘mistknooppunten’ genoemd, filteren de ontvangen gegevens en verwerken deze lokaal of sturen deze naar de cloud voor verdere berekeningen.
Clouds ondersteunen verschillende communicatieprotocollen, waarvan AMQP en REST HTTP de meest voorkomende zijn. Omdat HTTP bekend is en op maat is gemaakt voor internet, kan de vraag rijzen: “moeten we het niet gebruiken om met IoT en mist te werken?” Dit protocol heeft echter prestatieproblemen. Hierover later meer.
Over het algemeen zijn er twee modellen communicatieprotocollen die geschikt zijn voor het systeem dat we nodig hebben. Dit zijn verzoek-antwoord en publiceren-abonneren. Het eerste model is breder bekend, vooral in de server-clientarchitectuur. De client vraagt informatie op bij de server en de server ontvangt het verzoek, verwerkt het en stuurt een antwoordbericht terug. De REST HTTP- en CoAP-protocollen werken op dit model.
Het tweede model kwam voort uit de behoefte om te zorgen voor een asynchrone, gedistribueerde, losse koppeling tussen de bronnen die gegevens genereren en de ontvangers van deze gegevens.
Het model gaat uit van drie deelnemers: een uitgever (gegevensbron), een makelaar (verzender) en een abonnee (ontvanger). Hierbij hoeft de als abonnee optredende client geen informatie op te vragen bij de server. In plaats van verzoeken te verzenden, abonneert het zich op bepaalde gebeurtenissen in het systeem via een makelaar, die verantwoordelijk is voor het filteren van alle inkomende berichten en het routeren ervan tussen uitgevers en abonnees. En de uitgever, wanneer er een gebeurtenis plaatsvindt met betrekking tot een bepaald onderwerp, publiceert deze naar de makelaar, die gegevens over het gevraagde onderwerp naar de abonnee stuurt.
In wezen is deze architectuur op gebeurtenissen gebaseerd. En dit interactiemodel is interessant voor toepassingen in IoT, cloud en mist vanwege het vermogen om schaalbaarheid te bieden en de onderlinge verbinding tussen verschillende apparaten te vereenvoudigen, dynamische veel-op-veel-communicatie en asynchrone communicatie te ondersteunen. Enkele van de meest bekende gestandaardiseerde berichtenprotocollen die een publicatie-abonneermodel gebruiken, zijn onder meer MQTT, AMQP en DDS.
Het is duidelijk dat het publiceer-abonneermodel veel voordelen heeft:
- Uitgevers en abonnees hoeven niet van elkaars bestaan af te weten;
- Eén abonnee kan informatie uit veel verschillende publicaties ontvangen, en één uitgever kan gegevens naar veel verschillende abonnees sturen (many-to-many-principe);
- De uitgever en abonnee hoeven niet tegelijkertijd actief te zijn om te communiceren, omdat de makelaar (die als wachtrijsysteem werkt) het bericht kan opslaan voor klanten die momenteel niet op het netwerk zijn aangesloten.
Het request-response-model heeft echter ook zijn sterke punten. In gevallen waarin het vermogen van de server om meerdere clientverzoeken af te handelen geen probleem is, is het zinvol om bewezen, betrouwbare oplossingen te gebruiken.
Er zijn ook protocollen die beide modellen ondersteunen. Bijvoorbeeld XMPP en HTTP 2.0, die de optie “server push” ondersteunen. De IETF heeft ook een CoAP uitgebracht. In een poging het berichtenprobleem op te lossen zijn er verschillende andere oplossingen bedacht, zoals het WebSockets-protocol of het gebruik van het HTTP-protocol via QUIC (Quick UDP Internet Connections).
In het geval van WebSockets is het, hoewel het wordt gebruikt om gegevens in realtime van een server naar een webclient over te dragen en permanente verbindingen met gelijktijdige bidirectionele communicatie biedt, niet bedoeld voor apparaten met beperkte computerbronnen. Ook QUIC verdient aandacht, omdat het nieuwe transportprotocol veel nieuwe kansen biedt. Maar aangezien QUIC nog niet gestandaardiseerd is, is het voorbarig om de mogelijke toepassing en impact ervan op IoT-oplossingen te voorspellen. We houden WebSockets en QUIC dus in gedachten met het oog op de toekomst, maar gaan daar voorlopig niet dieper op in.
Wie is de schattigste ter wereld: protocollen vergelijken
Laten we het nu hebben over de sterke en zwakke punten van protocollen. Laten we, vooruitkijkend, meteen het voorbehoud maken dat er niet één duidelijke leider is. Elk protocol heeft enkele voordelen/nadelen.
Reactietijd
Een van de belangrijkste kenmerken van communicatieprotocollen, vooral met betrekking tot het Internet of Things, is de responstijd. Maar onder de bestaande protocollen is er geen duidelijke winnaar die het minimale latentieniveau aantoont bij het werken onder verschillende omstandigheden. Maar er is een hele hoop onderzoek en vergelijkingen van protocolmogelijkheden.
Bijvoorbeeld Uit vergelijkingen van de effectiviteit van HTTP en MQTT bij het werken met IoT bleek dat de responstijd voor verzoeken voor MQTT korter is dan voor HTTP. En wanneer Uit de round trip time (RTT) van MQTT en CoAP bleek dat de gemiddelde RTT van CoAP 20% minder is dan die van MQTT.
Другой met RTT voor de MQTT- en CoAP-protocollen werd uitgevoerd in twee scenario's: lokaal netwerk en IoT-netwerk. Het bleek dat de gemiddelde RTT 2-3 keer hoger is in een IoT-netwerk. MQTT met QoS0 liet een lager resultaat zien vergeleken met CoAP, en MQTT met QoS1 liet een hogere RTT zien als gevolg van ACKs op de applicatie- en transportlagen. Voor verschillende QoS-niveaus bedroeg de netwerklatentie zonder congestie milliseconden voor MQTT, en honderden microseconden voor CoAP. Het is echter de moeite waard om te onthouden dat wanneer u op minder betrouwbare netwerken werkt, MQTT bovenop TCP een heel ander resultaat zal laten zien.
De responstijd voor de AMQP- en MQTT-protocollen door de payload te verhogen toonde aan dat bij een lichte belasting het latentieniveau vrijwel hetzelfde is. Maar bij de overdracht van grote hoeveelheden gegevens laat MQTT kortere responstijden zien. nog één CoAP werd vergeleken met HTTP in een machine-to-machine-communicatiescenario waarbij apparaten bovenop voertuigen werden geplaatst die waren uitgerust met gassensoren, weersensoren, locatiesensoren (GPS) en een mobiele netwerkinterface (GPRS). De tijd die nodig was om een CoAP-bericht via het mobiele netwerk te verzenden was bijna drie keer korter dan de tijd die nodig was om HTTP-berichten te gebruiken.
Er zijn onderzoeken uitgevoerd waarin niet twee, maar drie protocollen werden vergeleken. Bijvoorbeeld, prestaties van IoT-protocollen MQTT, DDS en CoAP in een medisch toepassingsscenario met behulp van een netwerkemulator. DDS presteerde beter dan MQTT in termen van geteste telemetrielatentie onder verschillende slechte netwerkomstandigheden. Op UDP gebaseerde CoAP werkte goed voor toepassingen die snelle responstijden vereisten, maar omdat het op UDP was gebaseerd, was er aanzienlijk onvoorspelbaar pakketverlies.
Doorvoer
MQTT en CoAP in termen van bandbreedte-efficiëntie werden uitgevoerd als een berekening van de totale hoeveelheid verzonden gegevens per bericht. CoAP heeft een lagere doorvoersnelheid laten zien dan MQTT bij het verzenden van kleine berichten. Maar als we de efficiëntie van protocollen vergelijken in termen van de verhouding tussen het aantal nuttige informatiebytes en het totale aantal overgedragen bytes, blijkt CoAP effectiever.
bij Door gebruik te maken van MQTT, DDS (met TCP als transportprotocol) en CoAP-bandbreedte, bleek dat CoAP over het algemeen een relatief lager bandbreedteverbruik vertoonde, dat niet toenam met toegenomen netwerkpakketverlies of verhoogde netwerklatentie, in tegenstelling tot MQTT en DDS, waar sprake was van een toename van het bandbreedtegebruik in de genoemde scenario's. Een ander scenario betrof een groot aantal apparaten die tegelijkertijd gegevens verzonden, wat typisch is voor IoT-omgevingen. Uit de resultaten bleek dat het voor een hogere benutting beter is om CoAP te gebruiken.
Bij lichte belasting gebruikte CoAP de minste bandbreedte, gevolgd door MQTT en REST HTTP. Toen de omvang van de payloads echter toenam, had REST HTTP de beste resultaten.
Stroomverbruik
De kwestie van het energieverbruik is altijd van groot belang, en vooral in een IoT-systeem. Als Terwijl MQTT en HTTP elektriciteit verbruiken, verbruikt HTTP veel meer. En CoAP is meer vergeleken met MQTT, waardoor energiebeheer mogelijk is. In eenvoudige scenario's is MQTT echter geschikter voor het uitwisselen van informatie in Internet of Things-netwerken, vooral als er geen stroombeperkingen zijn.
Uit een experiment waarin de mogelijkheden van AMQP en MQTT op een testbed voor mobiele of onstabiele draadloze netwerken werden vergeleken, bleek dat AMQP meer beveiligingsmogelijkheden biedt, terwijl MQTT energiezuiniger is.
veiligheid
Beveiliging is een ander cruciaal probleem dat naar voren komt bij het bestuderen van het onderwerp Internet of Things en mist/cloud computing. Het beveiligingsmechanisme is doorgaans gebaseerd op TLS in HTTP, MQTT, AMQP en XMPP, of DTLS in CoAP, en ondersteunt beide DDS-varianten.
TLS en DTLS beginnen met het proces van het tot stand brengen van communicatie tussen de client- en serverzijde om ondersteunde coderingssuites en sleutels uit te wisselen. Beide partijen onderhandelen over sets om ervoor te zorgen dat verdere communicatie via een beveiligd kanaal plaatsvindt. Het verschil tussen de twee ligt in kleine aanpassingen waardoor op UDP gebaseerde DTLS via een onbetrouwbare verbinding kan werken.
bij Uit verschillende implementaties van TLS en DTLS bleek dat TLS het beter deed. Aanvallen op DTLS waren succesvoller vanwege de fouttolerantie.
Het grootste probleem met deze protocollen is echter dat ze oorspronkelijk niet zijn ontworpen voor gebruik in IoT en niet bedoeld zijn om in de mist of in de cloud te werken. Door middel van handshaking voegen ze bij elke verbindingsopbouw extra verkeer toe, waardoor computerbronnen worden uitgeput. Gemiddeld is er een stijging van 6,5% voor TLS en 11% voor DTLS in overhead vergeleken met communicatie zonder beveiligingslaag. In omgevingen die rijk zijn aan hulpbronnen, die zich doorgaans bevinden op niveau zal dit geen probleem zijn, maar in het verband tussen IoT en mistniveau wordt dit een belangrijke beperking.
Wat te kiezen? Er is geen duidelijk antwoord. MQTT en HTTP lijken de meest veelbelovende protocollen te zijn, omdat ze worden beschouwd als relatief volwassener en stabielere IoT-oplossingen in vergelijking met andere protocollen.
Oplossingen gebaseerd op een uniform communicatieprotocol
De praktijk van een oplossing met één protocol heeft veel nadelen. Een protocol dat geschikt is voor een beperkte omgeving werkt bijvoorbeeld mogelijk niet in een domein met strenge beveiligingseisen. Met dit in gedachten moeten we bijna alle mogelijke oplossingen met één protocol in het Fog-to-Cloud-ecosysteem in IoT weggooien, behalve MQTT en REST HTTP.
REST HTTP als oplossing met één protocol
Er is een goed voorbeeld van hoe REST HTTP-verzoeken en -antwoorden op elkaar inwerken in de IoT-naar-Fog-ruimte: . De dieren zijn uitgerust met draagbare sensoren (IoT-client, C) en worden via cloud computing aangestuurd door een slim landbouwsysteem (Fog-server, S).
De header van de POST-methode specificeert de bron die moet worden gewijzigd (/farm/animals), evenals de HTTP-versie en het inhoudstype, wat in dit geval een JSON-object is dat de dierenboerderij vertegenwoordigt die het systeem moet beheren (Dulcinea/cow) . Het antwoord van de server geeft aan dat het verzoek succesvol was door het verzenden van HTTPS-statuscode 201 (bron aangemaakt). De GET-methode moet alleen de gevraagde bron in de URI specificeren (bijvoorbeeld /farm/animals/1), die een JSON-representatie van het dier met dat ID van de server retourneert.
De PUT-methode wordt gebruikt wanneer een specifiek resourcerecord moet worden bijgewerkt. In dit geval specificeert de bron de URI voor de parameter die moet worden gewijzigd en de huidige waarde (bijvoorbeeld om aan te geven dat de koe momenteel loopt, /farm/animals/1? state=walking). Ten slotte wordt de DELETE-methode op dezelfde manier gebruikt als de GET-methode, maar wordt de bron eenvoudigweg verwijderd als resultaat van de bewerking.
MQTT als oplossing met één protocol
Laten we dezelfde slimme boerderij nemen, maar in plaats van REST HTTP gebruiken we het MQTT-protocol. Een lokale server waarop de Mosquitto-bibliotheek is geïnstalleerd, fungeert als makelaar. In dit voorbeeld fungeert een eenvoudige computer (ook wel de boerderijserver genoemd) Raspberry Pi als een MQTT-client, geïmplementeerd via een installatie van de Paho MQTT-bibliotheek, die volledig compatibel is met de Mosquitto-makelaar.
Deze client komt overeen met een IoT-abstractielaag die een apparaat met detectie- en computermogelijkheden vertegenwoordigt. De bemiddelaar daarentegen komt overeen met een hoger abstractieniveau en vertegenwoordigt een mistcomputerknooppunt dat wordt gekenmerkt door een grotere verwerkings- en opslagcapaciteit.
In het voorgestelde slimme boerderijscenario maakt de Raspberry Pi verbinding met de versnellingsmeter, GPS en temperatuursensoren en publiceert gegevens van deze sensoren naar een mistknooppunt. Zoals u waarschijnlijk weet, behandelt MQTT onderwerpen als een hiërarchie. Eén enkele MQTT-uitgever kan berichten publiceren over een specifieke reeks onderwerpen. In ons geval zijn het er drie. Voor een sensor die de temperatuur in een dierenstal meet, kiest de opdrachtgever een thema (dierbedrijf/stal/temperatuur). Voor sensoren die de GPS-locatie en de beweging van dieren via de accelerometer meten, zal de klant updates publiceren voor (dierenboerderij/dier/GPS) en (dierenboerderij/dier/beweging).
Deze informatie wordt doorgegeven aan de makelaar, die deze tijdelijk kan opslaan in een lokale database voor het geval er later een andere geïnteresseerde abonnee langskomt.
Naast de lokale server, die als MQTT-broker in de mist fungeert en waarnaar Raspberry Pis als MQTT-clients sensordata stuurt, is er mogelijk nog een MQTT-makelaar op cloudniveau. In dit geval kan de informatie die naar de lokale makelaar wordt verzonden tijdelijk worden opgeslagen in een lokale database en/of naar de cloud worden verzonden. De mist-MQTT-makelaar wordt in deze situatie gebruikt om alle gegevens te koppelen aan de cloud-MQTT-makelaar. Met deze architectuur kan een gebruiker van een mobiele applicatie zich bij beide makelaars abonneren.
Als de verbinding met een van de makelaars (bijvoorbeeld cloud) uitvalt, ontvangt de eindgebruiker informatie van de ander (mist). Dit is een kenmerkend kenmerk van gecombineerde mist- en cloudcomputersystemen. Standaard kan de mobiele app worden geconfigureerd om eerst verbinding te maken met de Fog MQTT-makelaar, en als dat niet lukt, om verbinding te maken met de cloud-MQTT-makelaar. Deze oplossing is slechts een van de vele in IoT-F2C-systemen.
Multi-protocol oplossingen
Oplossingen met één protocol zijn populair vanwege hun eenvoudiger implementatie. Maar het is duidelijk dat het in IoT-F2C-systemen zinvol is om verschillende protocollen te combineren. Het idee is dat verschillende protocollen op verschillende niveaus kunnen werken. Neem bijvoorbeeld drie abstracties: de lagen van IoT, mist en cloud computing. Apparaten op IoT-niveau worden over het algemeen als beperkt beschouwd. Laten we voor dit overzicht de IoT-lagen beschouwen als de meest beperkte, de cloud als de minst beperkte, en fog computing als 'ergens in het midden'. Het blijkt dan dat tussen IoT- en mistabstracties de huidige protocoloplossingen MQTT, CoAP en XMPP omvatten. Tussen mist en cloud is AMQP daarentegen een van de belangrijkste gebruikte protocollen, samen met REST HTTP, dat vanwege zijn flexibiliteit ook wordt gebruikt tussen IoT- en mistlagen.
Het grootste probleem hier is de interoperabiliteit van protocollen en het gemak waarmee berichten van het ene protocol naar het andere kunnen worden overgebracht. Idealiter zal de architectuur van een Internet of Things-systeem met cloud- en mistbronnen in de toekomst onafhankelijk zijn van het gebruikte communicatieprotocol en een goede interoperabiliteit tussen verschillende protocollen garanderen.
Omdat dit momenteel niet het geval is, is het zinvol om protocollen te combineren die geen significante verschillen vertonen. Daartoe is een mogelijke oplossing gebaseerd op een combinatie van twee protocollen die dezelfde architectuurstijl volgen, REST HTTP en CoAP. Een andere voorgestelde oplossing is gebaseerd op een combinatie van twee protocollen die communicatie tussen publiceren en abonneren bieden, MQTT en AMQP. Het gebruik van vergelijkbare concepten (zowel MQTT als AMQP gebruiken brokers, CoAP en HTTP gebruiken REST) maakt deze combinaties eenvoudiger te implementeren en vereist minder integratie-inspanningen.
Figuur (a) toont twee op verzoeken en antwoorden gebaseerde modellen, HTTP en CoAP, en hun mogelijke plaatsing in een IoT-F2C-oplossing. Omdat HTTP een van de bekendste en meest gebruikte protocollen op moderne netwerken is, is het onwaarschijnlijk dat het volledig zal worden vervangen door andere berichtenprotocollen. Onder de knooppunten die krachtige apparaten vertegenwoordigen die zich tussen de cloud en de mist bevinden, is REST HTTP een slimme oplossing.
Aan de andere kant is het voor apparaten met beperkte computerbronnen die communiceren tussen de Fog- en IoT-lagen efficiënter om CoAP te gebruiken. Een van de grote voordelen van CoAP is eigenlijk de compatibiliteit met HTTP, aangezien beide protocollen gebaseerd zijn op REST-principes.
Figuur (b) toont twee communicatiemodellen voor publiceren en abonneren in hetzelfde scenario, inclusief MQTT en AMQP. Hoewel beide protocollen hypothetisch zouden kunnen worden gebruikt voor communicatie tussen knooppunten op elke abstractielaag, moet hun positie worden bepaald op basis van prestaties. MQTT is ontworpen als een lichtgewicht protocol voor apparaten met beperkte computerbronnen, zodat het kan worden gebruikt voor IoT-Fog-communicatie. AMQP is meer geschikt voor krachtigere apparaten, die deze idealiter tussen mist- en cloudknooppunten zouden positioneren. In plaats van MQTT kan het XMPP-protocol in IoT worden gebruikt, omdat het als lichtgewicht wordt beschouwd. Maar het wordt in dergelijke scenario's niet zo veel gebruikt.
Bevindingen
Het is onwaarschijnlijk dat een van de besproken protocollen voldoende zal zijn om alle communicatie in een systeem te dekken, van apparaten met beperkte computerbronnen tot cloudservers. Uit het onderzoek blijkt dat de twee meest veelbelovende opties die ontwikkelaars het meest gebruiken MQTT en RESTful HTTP zijn. Deze twee protocollen zijn niet alleen de meest volwassen en stabiele, maar omvatten ook veel goed gedocumenteerde en succesvolle implementaties en online bronnen.
Vanwege de stabiliteit en eenvoudige configuratie is MQTT een protocol dat zijn superieure prestaties in de loop van de tijd heeft bewezen bij gebruik op IoT-niveau met beperkte apparaten. In delen van het systeem waar beperkte communicatie en batterijverbruik geen probleem zijn, zoals sommige fog-domeinen en de meeste cloud computing, is RESTful HTTP een gemakkelijke keuze. Er moet ook rekening mee worden gehouden, omdat het ook snel evolueert als een IoT-berichtenstandaard en het waarschijnlijk is dat het in de nabije toekomst een niveau van stabiliteit en volwassenheid zal bereiken dat vergelijkbaar is met MQTT en HTTP. Maar de standaard is momenteel in ontwikkeling, wat gepaard gaat met compatibiliteitsproblemen op de korte termijn.
Wat lees je nog meer op de blog?
→
→
→
→
→
Abonneer u op onze -channel zodat je het volgende artikel niet mist! We schrijven niet vaker dan twee keer per week en alleen voor zaken.
Bron: www.habr.com