De applicatielaag

Een netwerkapplicatie bestaat uit programma's die draaien op eindsystemen: telefoons, laptops en servers. Hun processen wisselen berichten uit via het netwerk. Routers en switches sturen de pakketten door; er hoeft geen nieuw applicatieprogramma op te worden geïnstalleerd wanneer iemand een nieuwe dienst maakt.

Twee manieren om het werk te verdelen

Een applicatiearchitectuur beschrijft hoe de applicatie het werk over hosts verdeelt. Die staat los van de gelaagde architectuur van het netwerk. De ontwikkelaar kiest waar programma's draaien en vertrouwt op het bestaande netwerk om ze te verbinden.

In een client-serverontwerp nemen clients contact op met een server die altijd aanstaat op een bekend adres. Een browser vraagt een document op bij een webserver, die het document terugstuurt. Andere browsers hoeven niet online te zijn om die uitwisseling te laten werken. Een populaire dienst kan de serverrol over duizenden machines in datacenters verdelen; één openbare naam kan die groep vertegenwoordigen. Apparatuur, stroom, koeling en internetverbindingen kosten allemaal geld.

Een peer-to-peerontwerp, of P2P-ontwerp, laat apparaten van gebruikers rechtstreeks gegevens uitwisselen. Een peer kan een bestandsdeel opvragen en ook delen uploaden die die al heeft. Peers kunnen de verbinding verbreken of van adres veranderen, dus moet de applicatie beschikbare peers vinden en blijven werken als de samenstelling verandert.

Volg één uitwisseling

Stel dat een onderzoeksgroep een grote dataset distribueert. In een client-serverontwerp downloadt elke onderzoeker een kopie van de server van de groep. Tien nieuwe onderzoekers betekenen tien extra kopieën die die server moet uploaden. In een P2P-ontwerp sturen onderzoekers die al enkele delen hebben, die delen naar nieuwkomers. Elke deelnemende onderzoeker kan naast vraag ook capaciteit toevoegen. Dit is zelfschaling: de middelen van de applicatie groeien mee met de deelname.

Zelfschaling blijft afhankelijk van nuttige bijdragen. Een peer met een trage uploadverbinding voegt minder capaciteit toe dan een peer met een snelle verbinding. Veel verbindingen bij huishoudens zijn asymmetrisch: downloaden gaat sneller dan uploaden. Een peer die de verbinding verbreekt, draagt niets bij zolang die offline is. P2P-software moet deelnemers ook beschermen tegen niet-vertrouwde peers en gebruikers aanmoedigen om te uploaden in plaats van alleen gegevens af te nemen.

Centrale coördinatie en rechtstreekse overdracht

Een hybride ontwerp combineert coördinatie door een server met P2P-gegevensoverdracht. Een BitTorrent-tracker vertelt een peer over andere peers; de tracker hoeft het bestand zelf niet te verzenden. Op dezelfde manier kan een beldienst deelnemers via een server vinden, hun apparaten rechtstreeks media laten uitwisselen en een tussenstation gebruiken wanneer een rechtstreeks pad niet beschikbaar is. Deel het pad waarover de gegevens gaan afzonderlijk in van het pad dat de verbinding opzet.

De woorden client en server beschrijven ook rollen in een afzonderlijke uitwisseling. Als peer Mira een verzoek aan peer Leo initieert, is Mira de client en Leo de server voor die uitwisseling. Even later kunnen ze de rollen omkeren. P2P neemt de afhankelijkheid van specifieke contentservers weg; de initiërende en antwoordende rollen blijven bestaan.

Een draaiend applicatieprogramma is een proces. Processen op verschillende hosts wisselen berichten uit via sockets, de software-interfaces tussen de applicatielaag en de transportlaag. De applicatiecode bepaalt wat het bericht betekent; de transportdienst vervoert de bytes of datagrammen.

Vind het ontvangende proces

Een IP-adres identificeert een host, maar op die host kunnen veel diensten draaien. Een poortnummer identificeert een transporteindpunt op de host. Om contact te maken met een HTTPS-dienst op 203.0.113.10, richt een client zich normaal op poort 443. Het eigen besturingssysteem wijst meestal een tijdelijke bronpoort toe.

Poorten zijn 16-bitswaarden, van 0 tot en met 65.535. Systeempoorten omvatten 0–1023, geregistreerde poorten 1024–49.151 en dynamische poorten 49.152–65.535. Gebruikelijke dienstpoorten zijn HTTP 80, HTTPS 443, SMTP-overdracht 25 en DNS 53. Een poort maakt deel uit van de adressering en zegt niet of het verkeer versleuteld of betrouwbaar is.

Spreek de berichten af

Een applicatielaagprotocol definieert berichttypen, syntaxis, semantiek en uitwisselingsregels. Typen onderscheiden een verzoek van een antwoord. Syntaxis beschrijft velden en scheidingstekens. Semantiek vertelt elke deelnemer wat die velden betekenen. Uitwisselingsregels bepalen wanneer een proces een bericht verzendt en hoe de ontvanger reageert. Openbare specificaties, vaak RFC's, laten programma's van verschillende ontwikkelaars communiceren.

Een protocol is één onderdeel van een applicatie. Het web heeft ook browsers, servers en documenten nodig. Alleen HTTP definiëren bouwt geen browser en bepaalt niet hoe de interface eruitziet.

Stem de dienst af op de behoefte

Bekijk vier behoeften: correcte aflevering, voldoende doorvoersnelheid, aanvaardbare vertraging en beveiliging. Voor een e-mailbijlage is elke byte nodig. Een spraakgesprek kan enig verlies van media verdragen, maar ondervindt hinder als oude audio te laat aankomt. Opgeslagen video heeft een aanhoudende doorvoersnelheid nodig die dicht bij de gecodeerde bitsnelheid ligt, terwijl een elastische download de beschikbare snelheid kan gebruiken.

TCP omvat stroomregeling om de ontvanger te beschermen en congestiebeheersing om overbelasting in het netwerk te verminderen. Het biedt geen minimale bandbreedte of uiterste aflevertijd. UDP zelf voegt geen betrouwbaarheid en geen congestiebeheersing toe. Door UDP te kiezen verdwijnt congestie niet van het pad.

Een spel dat 30 keer per seconde posities verzendt, produceert bijvoorbeeld ongeveer elke 33 ms een nieuwe update. Het kan UDP gebruiken zodat een verloren update door een nieuwere kan worden vervangen zonder op hertransmissie van die update te wachten. De chat van het spel heeft nog steeds betrouwbare aflevering nodig, via TCP of via betrouwbaarheid die het eigen protocol toevoegt.

Voeg beveiliging toe aan de stack

TCP en UDP zonder extra beveiliging versleutelen geen applicatiegegevens. HTTP/1.1 en HTTP/2 gebruiken voor HTTPS meestal TLS over TCP. TLS voegt vertrouwelijkheid, integriteit en serverauthenticatie toe. HTTP/3 gebruikt QUIC over UDP; QUIC biedt betrouwbaarheid, congestiebeheersing en ingebouwde TLS 1.3. Opgeslagen video die via HTTP wordt geleverd, gebruikt daarom TCP of QUIC, terwijl interactieve gesprekken media vaak via UDP vervoeren.

Een webpagina bestaat meestal uit meerdere objecten, elk met een eigen URL. De basis-HTML verwijst naar afbeeldingen, scripts en andere bestanden. In https://www.example.org/docs/intro.html is https het schema, www.example.org de host en /docs/intro.html het pad.

Lees een verzoek en antwoord

HTTP werkt met verzoek-antwoorduitwisselingen. Een HTTP/1.1-verzoek begint met een methode, pad en versie:

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

De verzoekregel en headerregels eindigen met CRLF. Een lege regel sluit de headers af, eventueel gevolgd door een berichtinhoud. Host is verplicht in HTTP/1.1 omdat meerdere sites één serveradres kunnen delen. Connection: close vraagt om sluiting na het antwoord.

GET haalt een object op. HEAD vraagt de antwoordheaders op zonder de berichtinhoud. POST verzendt gegevens in de inhoud van een verzoek; een GET kan ook formulierwaarden in de querystring van de URL meenemen. PUT slaat een object op een opgegeven URL op en DELETE verwijdert een object.

Het antwoord begint met een statusregel zoals HTTP/1.1 200 OK, gevolgd door headers, een lege regel en de berichtinhoud. Content-Type geeft de representatie aan; Content-Length geeft de lengte in bytes. Statusklassen zijn 1xx informatie, 2xx geslaagd, 3xx omleiding, 4xx clientfout en 5xx serverfout. Een 301 verwijst in Location naar een nieuwe URL; 304 staat hergebruik van een kopie uit de cache toe. Een 404 betekent dat de server heeft geantwoord dat het opgevraagde object niet is gevonden, niet dat de server onbereikbaar was. Andere nuttige codes zijn 400, 500 en 505.

HTTP is toestandsloos: elk verzoek kan zonder eerdere verzoeken worden begrepen. Een website kan boven op HTTP toch een inlogstatus of winkelwagentje bijhouden. Een gewoon herhaald GET-verzoek kan het object opnieuw teruggeven, terwijl een voorwaardelijk verzoek een opgeslagen kopie kan valideren.

Tel de rondlooptijden

Reken voor één object over een nieuwe TCP-verbinding één RTT voor de verbindingsopbouw en één voor het verzoek en het begin van het antwoord. Tel daar vervolgens de transmissietijd van het object bij op. Met RTT 30 ms, grootte 500 kB en snelheid 50 Mbps:

Het totaal is 60 ms plus 80 ms, ofwel 140 ms. Dit model laat DNS, TLS en verwerkingstijd buiten beschouwing. Een volledige TLS 1.3-handshake over de nieuwe TCP-verbinding voegt nog een RTT toe.

Hergebruik of heropen de verbinding

Een niet-persistente verbinding vervoert één object. Een persistente verbinding kan latere verzoeken vervoeren zonder opnieuw een TCP-verbinding op te zetten. Persistentie is de standaard in HTTP/1.1, al worden ongebruikte verbindingen uiteindelijk gesloten.

Voor één HTML-object en acht kleine afbeeldingen, RTT 20 ms en verwaarloosbare transmissietijden:

De afbeeldingsverzoeken zijn afhankelijk van de ontvangst van de HTML. Zelfs bij parallel ophalen kunnen ze niet beginnen voordat hun URL's bekend zijn. Tel die afhankelijke fasen voordat je handshakes telt. HTTP/1.1-browsers gebruiken meestal meerdere verbindingen per host; pipelining is een tijdmodel, geen vereiste voor persistentie.

HTTP-verzoeken staan op zichzelf, maar een winkel kan een winkelwagentje onthouden. Een browser kan ook een afbeelding hergebruiken in plaats van die opnieuw te downloaden. Cookies ondersteunen herkenning over meerdere verzoeken; caches ondersteunen hergebruik van antwoorden.

Volg een cookie

Bij een eerste bezoek maakt shop.example.com een databasevermelding voor een bezoeker en geeft Set-Cookie: id=1678 terug. De browser slaat die waarde op. Latere overeenkomende verzoeken bevatten Cookie: id=1678, zodat de server het winkelwagentje kan opzoeken. De cookie bestaat uit gegevens, niet uit uitvoerbare code, en het winkelwagentje zelf kan in de database van de server blijven staan.

Cookieattributen regelen het gebruik. Expires of Max-Age stelt een levensduur in; een cookie zonder een van beide is een sessiecookie. Domain en Path beperken welke verzoeken overeenkomen. Secure beperkt verzending tot HTTPS, HttpOnly verhindert toegang via paginascripts en SameSite regelt verzending in situaties met verschillende sites. Bij sessieherstel kunnen sessiecookies behouden blijven wanneer een browser een eerdere sessie herstelt.

Directe cookies behoren bij de bezochte site. Een ingebouwde dienst van derden kan cookies op verschillende sites gebruiken om een browser te herkennen. Safari blokkeert cookies van derden standaard; Firefox houdt ze per site gescheiden; Chrome biedt gebruikers instellingen en blokkeert ze in de incognitomodus. Regels van de Europese Unie vereisen toestemming voor cookies die niet strikt noodzakelijk zijn om een gevraagde dienst te leveren.

Volg een verzoek via de cache

Een webcache bewaart HTTP-antwoorden. Een browser heeft een eigen cache. Een cacheproxy staat tussen clients en oorsprongservers: die levert een cachetreffer direct of haalt bij een misser een antwoord op, slaat het op en stuurt het door. De proxy treedt op als server voor de browser en als client voor de oorsprongserver. Een proxy kan ook bestaan zonder te cachen.

Een treffer dichtbij vermindert de vertraging, de belasting van de oorsprongserver en het verkeer op de toegangsverbinding. Bij 90 verzoeken per seconde van gemiddeld 1 Mbit per stuk is het aangeboden verkeer 90 Mbps. Op een toegangsverbinding van 100 Mbps is de verkeersintensiteit 0,9, waarbij wachtrijen groot kunnen worden. Bij een trefferpercentage van 40% gaat nog 60% over de verbinding: 54 Mbps en een intensiteit van 0,54. Als treffers 10 ms en missers 200 ms kosten, is de gemiddelde responstijd:

Deze verkeersberekening gaat uit van dezelfde gemiddelde objectgrootte voor de groep treffers en de groep missers. Een trefferpercentage dat alleen op basis van het aantal verzoeken wordt gemeten, hoeft niet gelijk te zijn aan de fractie bespaarde bytes wanneer objectgroottes verschillen.

Controleer de actualiteit vóór hergebruik

Een voorwaardelijk GET-verzoek stuurt If-Modified-Since met een opgeslagen wijzigingsdatum, of If-None-Match met een opgeslagen ETag. Een ongewijzigd object geeft 304 Not Modified zonder objectinhoud. De cache hergebruikt de kopie. Een gewijzigd object geeft 200 OK met het vervangende object. Validatie bespaart de transmissie van de inhoud, maar vereist nog steeds een rondgang naar de oorsprongserver.

Een gedeelde proxy kan normaal de inhoud van een HTTPS-verbinding die erdoorheen loopt niet inspecteren. Browsercaches en CDN-servers die namens een site leveren, kunnen cachen bij de eindpunten waar die antwoorden in leesbare vorm beschikbaar zijn.

HTTP-versies behouden de betekenis van methoden, statuscodes, velden en URL's. Een 404 betekent nog steeds dat de opgevraagde resource niet is gevonden. Wat verandert, is hoe verzoeken en antwoorden worden vervoerd: HTTP/1.1 gebruikt tekstberichten, terwijl HTTP/2 en HTTP/3 binaire frames gebruiken.

Laat kleine antwoorden voortgang boeken

Op een HTTP/1.1-verbinding kunnen geordende antwoorden een klein object achter een groot object laten wachten. Dit is blokkering door het eerste element op applicatieniveau. Meerdere TCP-verbindingen openen vermindert die wachttijd, maar kost extra verbindingsopbouw en geeft de pagina meerdere concurrerende verbindingen met congestiebeheersing.

HTTP/2 verdeelt berichten in frames en wijst aan elke verzoek-antwoorduitwisseling een stream toe. De zender verzendt frames van verschillende streams door elkaar op één TCP-verbinding. Headercompressie, HPACK genoemd, vermindert herhaalde veldgegevens. Prioriteiten kunnen aangeven welke antwoorden het eerst aandacht krijgen.

Voor een vereenvoudigde vergelijking heeft één groot antwoord 1.000 frames en hebben acht kleine antwoorden elk twee frames. Verzend één frame per tijdslot. Als het grote antwoord eerst wordt verzonden, zijn de kleine antwoorden klaar in tijdslot 1.002 tot en met 1.016, met een gemiddelde van 1.009. Als om beurten één frame van elke onvoltooide stream wordt verzonden, zijn de kleine antwoorden klaar in tijdslot 11 tot en met 18, met een gemiddelde van 14,5. Het grote antwoord is klaar in tijdslot 1.016. Het door elkaar verzenden verandert de voltooiingstijden zonder de transmissiesnelheid van de verbinding te verhogen.

HTTP/2 specificeerde ook server push, waarmee content vóór een verzoek wordt verzonden. Grote browsers hebben dit uitgeschakeld. Een antwoord 103 Early Hints wijst in plaats daarvan op resources zodat de browser die alvast kan opvragen.

Vind het resterende blokkeringspunt

TCP levert één geordende bytestroom. Als bytes ontbreken, wachten latere bytes op herstel, ook als ze frames van een andere HTTP/2-stream bevatten. HTTP/2 neemt blokkering door de antwoordvolgorde weg, maar behoudt deze blokkering op transportniveau.

HTTP/3 zet HTTP over op QUIC, een transportprotocol dat over UDP werkt, en comprimeert headers met QPACK. QUIC biedt betrouwbare streams, stroomregeling, congestiebeheersing en beveiliging met TLS 1.3. Elke stream heeft een eigen aflevervolgorde. Ontbrekende gegevens op één stream verhinderen op zichzelf niet dat al ontvangen gegevens op een andere stream worden afgeleverd. Gedeelde congestiebeheersing en afhankelijkheden binnen de applicatie kunnen nog steeds meerdere streams beïnvloeden.

QUIC gebruikt verbindingsidentificaties zodat een verbinding een wijziging van IP-adres kan overleven, zoals bij de overgang van wifi naar een mobiel netwerk. De implementatie kan met een applicatiebibliotheek worden bijgewerkt, waardoor het trage uitrolproces van wijzigingen aan TCP in besturingssystemen en middleboxes wordt vermeden.

Vergelijk een nieuwe verbinding

Bij RTT 50 ms en zonder tijd voor DNS of verwerking kost TCP plus TLS 1.3 twee RTT's voordat het eerste HTTP/2-verzoek vertrekt. Een eerste antwoord begint na ongeveer 150 ms. QUIC combineert de opbouw van transport en beveiliging in één RTT, zodat een HTTP/3-antwoord na ongeveer 100 ms kan beginnen. Hervatte QUIC-verbindingen kunnen 0-RTT-gegevens gebruiken, maar het risico op herhaling beperkt welke verzoeken veilig vroeg kunnen worden verzonden.

Browsers kunnen HTTP/3 ontdekken via Alt-Svc of DNS-HTTPS-records. Als UDP is geblokkeerd, kunnen ze terugvallen op HTTP over TCP. HTTP/3 blijft betrouwbaar omdat QUIC boven op UDP betrouwbaarheid biedt.

Een naam zoals www.example.org is handig voor mensen. Een verbinding heeft een IP-adres nodig. Het Domain Name System, of DNS, is zowel de gedistribueerde database met naamrecords als het applicatieprotocol waarmee die wordt bevraagd. Het gebruikt normaal poort 53 en werkt afzonderlijk van HTTP.

Verdeel het werk voor naamopzoekingen

Lees www.example.org. van rechts naar links: root, org, example en dan www. De laatste punt staat voor de root en wordt in dagelijks gebruik meestal weggelaten. Een centrale server voor alle namen zou een storingspunt, een verkeersknelpunt en lange paden voor ver verwijderde clients opleveren.

Rootservers verwijzen resolvers naar topleveldomeinservers. TLD-servers verwijzen ze naar de autoritatieve servers voor domeinen onder het TLD. Autoritatieve servers publiceren de eigenlijke records voor een domein. De 13 benoemde serveridentiteiten van de root zijn gerepliceerd over veel fysieke instanties; 13 is niet het aantal machines dat DNS wereldwijd ondersteunt.

De host stuurt zijn vraag normaal naar een lokale resolver, aangeboden door de organisatie, internetprovider of een openbare dienst. Die resolver werkt namens de host. De resolver is geen extra niveau tussen de root en het TLD in de naamhiërarchie.

Volg een naamopzoeking met lege cache

Een laptop op een campus heeft het IPv4-adres van www.example.org nodig:

1. De laptop vraagt de lokale resolver om het definitieve antwoord.
2. De resolver vraagt het aan een rootserver en ontvangt een verwijzing naar .org-servers.
3. De resolver vraagt het aan een .org-server en ontvangt een verwijzing naar de autoritatieve servers voor example.org.
4. De resolver vraagt het aan een autoritatieve server en ontvangt 203.0.113.25.
5. De resolver geeft het adres terug aan de laptop.

Er zijn vier aanvraag-antwoordparen, ofwel acht berichten. Het verzoek van de host is recursief: verkrijg het antwoord voor mij. De aanvragen van de resolver zijn iteratief: elke geraadpleegde server antwoordt vanuit eigen kennis of verwijst de resolver verder. De root haalt het adres van de webserver niet namens de laptop op.

Hergebruik antwoorden totdat hun TTL eindigt

Een DNS-record heeft een levensduur, of TTL, gemeten in seconden. Resolvers bewaren herbruikbare records in caches totdat hun toegestane levensduur eindigt. Ze kunnen zowel verwijzingen als definitieve adressen cachen. Dankzij een opgeslagen TLD- of domeindelegatie kan een latere naamopzoeking eerdere stappen overslaan. Besturingssystemen en browsers kunnen ook caches hebben.

Met een RTT van 2 ms tussen host en resolver en een RTT van 30 ms voor elk van drie opeenvolgende aanvragen in de hiërarchie duurt de naamopzoeking met lege cache ongeveer 92 ms. Een adres in de cache van de resolver kost ongeveer 2 ms. De wachttijden worden opgeteld omdat elke verwijzing informatie levert die nodig is voor de volgende aanvraag.

Caching vertraagt ook wijzigingen. Als een resolver vlak voor een update een adres met een TTL van één uur heeft gecachet, kan die het oude adres gedurende de resterende levensduur blijven teruggeven. Door een TTL voorafgaand aan een geplande wijziging te verlagen, beperk je deze overlap; alleen het autoritatieve record wijzigen vervangt niet elke kopie in een cache.

DNS doet meer dan namen omzetten in adressen. Het ondersteunt aliassen, vindt mailservers en verdeelt de belasting door meerdere adressen voor een dienst terug te geven. Die rollen verklaren waarom ook e-mailaflevering en CDN-selectie afhankelijk zijn van DNS.

DNS slaat DNS-records op met een naam, waarde, type en TTL. Een type vertelt de resolver hoe die de waarde moet interpreteren. Een adresrecord, een alias en een mailserverrecord beantwoorden verschillende vragen over hetzelfde domein.

Lees het recordtype

Zo geeft www.example.org. 3600 IN A 203.0.113.25 de eigenaarnaam, TTL, internetklasse, het type en het adres. Een NS-waarde is een naam, geen adres. Een verwijzing kan een afzonderlijk A-record bevatten dat het adres van de naamserver levert, vaak een glue-record genoemd wanneer het nodig is om de delegatie op te lossen.

Een CNAME zoals media.example.org die naar edge.cdn.example.net verwijst, laat de resolver het adres van het doel opzoeken. Een MX-record stuurt daarentegen de e-mailaflevering. Probeer bij voorkeursnummers 10 en 20 eerst de mailserver met voorkeursnummer 10; een groter nummer betekent geen hogere prioriteit.

Lees het bericht rond de records

Aanvragen en antwoorden delen één formaat. De header van 12 bytes bevat een identificatienummer, vlaggen en aantallen vermeldingen in vier gedeelten. Het antwoord neemt de ID van de aanvraag over zodat de aanvrager de uitwisseling kan koppelen.

Het gedeelte vraag vermeldt wat is opgevraagd. Het gedeelte antwoord bevat overeenkomende records. Het gedeelte autoriteit kan NS-verwijzingen bevatten, terwijl aanvullend nuttige records zoals naamserveradressen levert. In de getoonde uitvoer van dig markeert qr een antwoord, betekent rd dat recursie is gevraagd en betekent ra dat recursie beschikbaar is. NOERROR meldt dat er geen DNS-fout is; NXDOMAIN meldt dat de opgevraagde naam niet bestaat. Een antwoord zonder fout kan nog steeds een record van het gevraagde type missen.

Om een nieuw domein te publiceren, registreert een eigenaar het en geeft informatie over de autoritatieve servers door. De delegatie vanuit het bovenliggende domein leidt aanvragen naar die servers, die de eigen host- en e-mailrecords van het domein publiceren. De naam registreren maakt de registrar niet tot de server die elk record bevat.

Aflevering en bescherming

De meeste kleine DNS-uitwisselingen gebruiken UDP-poort 53. Bij een afgekapt UDP-antwoord is de TC-vlag gezet; de resolver kan het opnieuw proberen via TCP-poort 53. TCP ondersteunt ook zoneoverdrachten. DNS is dus niet beperkt tot UDP.

Klassiek DNS-verkeer laat opgevraagde namen zien aan waarnemers op het pad. DNS over TLS of DNS over HTTPS versleutelt de uitwisseling tussen client en resolver, meestal op respectievelijk poort 853 en 443. Versleuteling van die uitwisseling en authenticiteit van een record zijn afzonderlijke eigenschappen.

Bij cachevergiftiging accepteert een resolver een vervalst antwoord en stuurt die gebruikers later naar het verkeerde adres. Onvoorspelbare ID's en bronpoorten maken het moeilijker om vervalste antwoorden te laten overeenkomen. DNSSEC voegt handtekeningen toe die verificatie van de authenticiteit van records ondersteunen; het verbergt de aanvraag niet. Overstromingsaanvallen kunnen DNS-servers ook onbereikbaar maken. Replicatie en verwijzingen in caches verminderen de afhankelijkheid van de root voor elk verzoek, maar storingen bij een veelgebruikte autoritatieve provider kunnen nog steeds veel sites verstoren.

Bij e-mail staan het opstellen en het afleveren van een bericht los van elkaar. Een gebruikersagent is de app of webpagina waarmee je e-mail leest en schrijft. Een mailserver slaat inkomende e-mail op in mailboxen en houdt uitgaande berichten in een wachtrij. SMTP draagt berichten over tussen systemen.

Volg de aflevering na aanbieding

Alice biedt een bericht voor Bob aan haar eigen server aan. Die server zoekt de MX-records voor Bobs domein op, zoekt het adres van de gekozen server op en opent een TCP-verbinding met poort 25. De server stuurt het bericht actief naar Bobs server, die het in Bobs mailbox opslaat. De server van Alice is tijdens die overdracht de SMTP-client, ook al bedient die in een andere uitwisseling de gebruikersagent van Alice.

Als de bestemming tijdelijk niet beschikbaar is, bewaart de uitgaande wachtrij het bericht voor nieuwe pogingen. Het apparaat van Alice kan offline gaan terwijl haar server blijft werken. Na herhaaldelijk mislukken kan een melding van niet-aflevering teruggaan naar de afzender in de envelop.

Lees de dialoog

SMTP gebruikt tekstopdrachten en numerieke antwoorden. Hieronder staat een verkorte afleveringsuitwisseling; C: en S: geven de twee gesprekspartners aan en worden niet als onderdeel van elke opdracht verzonden.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

Met EHLO stelt de verzendende host zich voor. MAIL FROM stelt de afzender in de envelop in; elke RCPT TO noemt een ontvanger in de envelop. DATA begint het bericht en een regel met alleen een punt sluit het af. Eén verbinding kan meer dan één bericht vervoeren. Antwoordklassen onderscheiden geslaagd (2xx), een verzoek om verdere invoer (3xx), een tijdelijke fout (4xx) en een blijvende fout (5xx). Een 4xx-antwoord vraagt om een nieuwe poging later; een 5xx-fout vraagt om een andere afhandeling, vaak een melding van niet-aflevering.

Houd afleveradressen gescheiden van getoonde velden

De SMTP-envelop regelt de routering. De velden From: en To: binnen het bericht worden aan de lezer getoond. Ze kunnen verschillen van de envelop. Een Bcc-ontvanger kan in RCPT TO staan zonder in de zichtbare berichtheaders te verschijnen. Voor een antwoord op een bericht en een melding van mislukte aflevering hoeft niet hetzelfde adres te worden gebruikt.

Een gebruiker biedt e-mail normaal aan via geauthenticeerde SMTP op poort 587 met STARTTLS, of poort 465 met TLS vanaf het begin. Overdracht tussen servers gebruikt normaal poort 25 en kan STARTTLS overeenkomen. Aanbieding en overdracht hebben verschillende rollen, ook wanneer beide SMTP gebruiken. HTTP haalt doorgaans gevraagde objecten op; SMTP stuurt een voorbereid bericht actief door.

Controleer het domein van de afzender

Een zichtbaar veld From: is eenvoudig te vervalsen. SPF controleert of de verzendende host bevoegd is voor het envelopdomein. DKIM verifieert een berichtondertekening met een publieke sleutel die in DNS is gepubliceerd. DMARC koppelt een geslaagd SPF- of DKIM-resultaat via domeinovereenstemming aan het zichtbare From-domein en publiceert een beleid voor mislukte controles. Een geslaagde SPF-controle voor een niet-gerelateerd envelopdomein alleen valideert de zichtbare afzender niet.

E-mailoverdracht, berichtinhoud en mailboxtoegang zijn afzonderlijke onderdelen van e-mail. SMTP brengt een bericht naar een mailserver. Het bericht heeft een eigen formaat met headers en berichtinhoud en een ontvanger krijgt later via een ander protocol toegang tot de opgeslagen mailbox.

Lees het bericht zelf

Een bericht begint met velden zoals From:, To:, Date:, Subject: en Message-ID:. Een lege regel scheidt deze headers van de berichtinhoud. Ze blijven deel uitmaken van het opgeslagen bericht; de SMTP-opdrachten MAIL FROM en RCPT TO worden geen berichtheaders.

Het basisformaat gebruikt tekstregels. MIME, Multipurpose Internet Mail Extensions, beschrijft rijkere inhoud met extra velden. Content-Type: text/plain; charset=UTF-8 beschrijft gewone tekst en de tekencodering. image/jpeg duidt een afbeelding aan. multipart/mixed beschrijft meerdere delen, gescheiden door een grenstekenreeks, zoals een tekstbericht gevolgd door een bijlage. Elk deel kan een eigen inhoudstype en overdrachtscodering hebben.

Content-Transfer-Encoding beschrijft hoe een deel voor overdracht wordt weergegeven. Base64 zet elke groep van drie bytes om in vier ASCII-tekens. Voor een bijlage van 3 MB worden 3.000.000 bytes 4.000.000 tekens, vóór regelafbrekingen en berichtheaders. De codering vergroot de omvang met ongeveer een derde. De totale berichtgroottelimiet van een server kan daarom niet alleen met de ruwe bijlagegrootte worden vergeleken. Quoted-printable is een andere codering die geschikt is voor grotendeels leesbare tekst.

Kies een protocol voor e-mailtoegang

De server van de ontvanger kan e-mail ontvangen terwijl de apparaten van de ontvanger offline zijn. Wanneer de ontvanger terugkomt, kan een client met een protocol voor e-mailtoegang opgeslagen berichten ophalen.

IMAP kan de headers of geselecteerde delen van een bericht ophalen zonder elke bijlage te downloaden. Het gebruikt meestal poort 143 met STARTTLS of poort 993 met TLS vanaf het begin. POP3 gebruikt meestal poort 110 of TLS op 995. De verwijderingsmarkeringen worden van kracht wanneer de sessie normaal wordt beëindigd. Downloaden en bewaren laat kopieën op de server staan, maar POP3 biedt niet de servermappen en gedeelde vlaggen van IMAP.

Stel dat Bob zijn e-mail op een laptop bekijkt voordat hij van huis vertrekt en daarna op een telefoon. Als de laptop POP3 met downloaden en verwijderen gebruikt, kan de telefoon een lege servermailbox aantreffen. Als Bob met IMAP een bericht op de laptop als gelezen markeert, verandert de serverstatus die de telefoon ook kan zien. Het verschil zit in de synchronisatie van de mailbox, niet in de SMTP-aflevering.

Volg een webmailbericht voorbij de browser

Een browser biedt e-mail aan of leest die via HTTPS. De webmailprovider gebruikt nog steeds SMTP om e-mail naar de server van een ander domein te brengen. Een volledig pad kan daarom bestaan uit HTTPS van afzender naar provider, SMTP tussen providers en vervolgens IMAP of HTTPS aan de ontvangende kant. De naam webmail beschrijft de gebruikersinterface en browserverbinding van een dienst, niet elk protocol op de route van het bericht.

Een bestand distribueren betekent dat elke ontvanger een volledige kopie moet verkrijgen. Het knelpunt is niet altijd de server: een trage downloader of onvoldoende totale uploadcapaciteit kan de minimale tijd bepalen. Het standaardmodel gaat ervan uit dat de toegangsverbindingen de knelpunten zijn en de kern voldoende capaciteit heeft.

Vergelijk de ondergrenzen

Laat het bestand $F$ bits bevatten, met $N$ ontvangers. De server uploadt met $u_s$; peer $i$ uploadt met $u_i$ en downloadt met $d_i$. De laagste downloadsnelheid van de peers is $d_{min}$. Gebruik bij elkaar passende eenheden, zoals Mbit en Mbps, zodat de deling seconden oplevert.

Bij client-serverdistributie moet de server $NF$ bits verzenden en de langzaamste peer $F$ bits ontvangen:

Bij P2P moet de server elke bit minstens één keer inbrengen. Peers moeten het bestand nog steeds downloaden en het hele systeem moet voldoende gegevens uploaden voor alle kopieën:

Neem het maximum, omdat tijdens de distributie aan alle vereisten moet worden voldaan. De termen optellen zou ten onrechte aannemen dat die upload- en downloadactiviteiten na elkaar plaatsvinden. Dit zijn ondergrenzen; protocoloverhead, onbeschikbare peers en andere knelpunten kunnen werkelijke overdrachten vertragen.

Werk een vergelijking uit

Gebruik voor een bestand van 2 Gbit 2.000 Mbit. Stel dat de serverupload 100 Mbps is, de langzaamste download 20 Mbps en elk van 100 peers uploadt met 5 Mbps.

De serverterm voor client-server is 200.000 Mbit gedeeld door 100 Mbps, ofwel 2.000 s. De term voor de langzaamste download is 100 s. De ondergrens is daarom 2.000 s.

Bij P2P duurt het inbrengen van het bestand minstens 20 s. De langzaamste download duurt nog steeds 100 s. De totale uploadcapaciteit is 100 plus 500, ofwel 600 Mbps; het distribueren van 200.000 Mbit duurt minstens ongeveer 333 s. De P2P-ondergrens is ongeveer 333 s. Bij 1.000 peers stijgt de client-serverondergrens naar 20.000 s, terwijl de P2P-ondergrens ongeveer 392 s is. Bij gelijke uploadsnelheden van peers nadert de term voor de totale capaciteit tot de bestandsgrootte gedeeld door de uploadsnelheid van één peer naarmate het aantal peers groot wordt.

Wissel delen uit in BitTorrent

Een torrent is een groep die één bestand deelt. Peers wisselen delen uit, ontdekken buren via een tracker of gedistribueerde hashtabel en kunnen uploaden voordat de download klaar is. Een seeder heeft het volledige bestand en blijft het delen.

Zeldzaamste eerst kiest een benodigd deel dat bij de minste buren aanwezig is en helpt zo delen te bewaren die anders zouden kunnen verdwijnen wanneer een peer vertrekt. Het bepaalt wat wordt opgevraagd. Wederkerigheid stimuleert nuttige uitwisseling door buren te bevoordelen die snel gegevens leveren; het bepaalt naar wie wordt geüpload.

In het oorspronkelijke ontwerp wordt voor vier geïnteresseerde buren tegelijk uploadcapaciteit vrijgegeven, waaronder één keer optimistisch. De gewone keuze wordt ongeveer elke 10 s herzien en de optimistisch gekozen peer ongeveer elke 30 s. Die verkennende plaats geeft nieuwkomers een manier om eerste delen te verkrijgen en helpt betere partners te ontdekken. De tracker coördineert het vinden van peers; die is niet de gegevensbron voor elk deel.

Een video bestaat uit frames die na elkaar worden weergegeven. Compressie verwijdert herhaalde informatie binnen een frame (ruimtelijke redundantie) en tussen frames (temporele redundantie). Het gecodeerde resultaat heeft een bitsnelheid: de hoeveelheid videogegevens die per seconde afspelen nodig is.

Leg het verband tussen snelheid, grootte en afspeeltijd

Een video van twee uur met 5 Mbps bevat 36.000 Mbit, ofwel 4,5 GB. Vermenigvuldig de snelheid met de duur om het aantal bits te verkrijgen en deel daarna door acht voor het aantal bytes. Als de gemiddelde doorvoersnelheid van het pad onder de gekozen videosnelheid ligt, raakt elke eindige buffer bij voortgezet afspelen uiteindelijk leeg.

Een speler kan beginnen voordat de hele video is gedownload. Die slaat komende gegevens op in een buffer, hier gemeten in seconden afspeelbare video. Tijdens het afspelen wordt de buffer verbruikt, terwijl downloads die aanvullen. Een grotere beginbuffer beschermt tegen dalingen in de doorvoersnelheid, maar vergroot de opstartvertraging.

Vraag telkens één segment op

DASH, Dynamic Adaptive Streaming over HTTP, slaat meerdere gecodeerde versies met verschillende snelheden op en verdeelt elke versie in segmenten. Een manifestbestand vermeldt de beschikbare versies en segment-URL's. De client vraagt een segment op met HTTP GET en kiest bij de volgende segmentgrens opnieuw een versie. HLS gebruikt een vergelijkbare aanpak met afspeellijsten.

De speler neemt de aanpassingsbeslissing op basis van de gemeten doorvoersnelheid en de buffervulling. Een hoge recente schatting van de doorvoersnelheid pleit voor een hogere snelheid; een bijna lege buffer vraagt om voorzichtigheid. Als de speler de hoogste snelheid kiest die eenmaal is gemeten, kan een onderbreking ontstaan als de volgende download trager verloopt. Spelers proberen ook afleidende, frequente kwaliteitswisselingen te vermijden.

Bereken een segmentdownload

Bekijk segmenten van 4 s die zijn gecodeerd met 1, 2,5, 5 en 8 Mbps. Bij een gemeten doorvoersnelheid van 6 Mbps bevat het segment van 5 Mbps 20 Mbit. Het downloaden duurt ongeveer 3,33 s en voegt 4 s afspeelbare content toe, terwijl het afspelen ongeveer 3,33 s verbruikt. Als het afspelen doorgaat, groeit de buffer met ongeveer 0,67 s.

Een segment van 8 Mbps bevat 32 Mbit en kost ongeveer 5,33 s, zodat de buffer met ongeveer 1,33 s krimpt. De 6 Mbps van het pad is een overdrachtssnelheid; die verandert een codering van 8 Mbps niet in een codering van 6 Mbps.

Als de doorvoersnelheid daalt naar 3 Mbps, kost hetzelfde segment van 5 Mbps ongeveer 6,67 s. De buffer verliest ongeveer 2,67 s per segment. Overschakelen naar de versie van 2,5 Mbps levert een segment van 10 Mbit op dat ongeveer 3,33 s kost, waardoor de buffer weer kan groeien. Om tijdens een download ononderbroken af te spelen, moet de beginbuffer ook meegaan totdat nieuwe afspeelbare gegevens beschikbaar zijn.

Opgeslagen streams en interactieve gesprekken

Streaming van opgeslagen video gebruikt gewone HTTP-objecten, die browsercaches en CDN-servers kunnen leveren. Die streaming werkt daarom, afhankelijk van de HTTP-versie, over TCP of QUIC. Interactieve gesprekken gebruiken vaak mediatransport op basis van UDP, omdat wachten op oudere media erger kan zijn dan ze verliezen.

Een live-evenement kan ook HTTP-streaming met segmenten gebruiken, maar de speler wacht tot elk segment is geproduceerd en houdt een buffer aan die achterloopt op de livegebeurtenissen. Kortere segmenten kunnen die vertraging verminderen, terwijl het aantal verzoeken toeneemt. Als je naar een niet-gebufferde plek gaat, moet de speler de buffer ook opnieuw vullen, wat de kwaliteit kort kan verlagen.

Een contentdistributienetwerk, of CDN, levert kopieën van content vanaf veel locaties. Zo hoeft niet elke kijker naar één ver verwijderd datacenter en zijn er minder herhaalde overdrachten over lange afstanden nodig. Het spreiden van de dienstcapaciteit vermindert ook de afhankelijkheid van één locatie.

Plaats content dicht bij gebruikers

Een privé-CDN behoort toe aan één aanbieder; een CDN van derden bedient veel klanten. Beide kunnen naast video ook afbeeldingen, scripts, software en webpagina's leveren. De oorspronkelijke bron van de content is de oorsprongserver. CDN-clusters bewaren kopieën zodat de oorsprongserver niet elk verzoek hoeft af te handelen.

Er zijn twee nuttige plaatsingsstrategieën:

De plaatsing en het vullen met content zijn afzonderlijke keuzes. Bij plaatsing op aanvraag haalt een cluster dat een object mist het op bij de oorsprongserver of een ander cluster, slaat het op en levert het. Bij voorafgaande plaatsing stuurt de aanbieder objecten van tevoren, vaak tijdens rustige perioden. Het eerste verzoek om een object dat niet in de cache staat, kan bij een CDN met plaatsing op aanvraag nog steeds afhankelijk zijn van de oorsprongserver.

Volg een overdracht via DNS

Een gebruiker vraagt https://video.stream.example.com/v/6Y7B23V op:

1. De resolver van de gebruiker vraagt naar video.stream.example.com.
2. De autoritatieve server van de aanbieder geeft een CNAME terug naar de naamruimte van het CDN, zoals a1105.cdn.example.net.
3. De resolver volgt die naam naar de autoritatieve DNS-dienst van het CDN.
4. Het CDN kiest een cluster en geeft een adres terug zoals 198.51.100.17.
5. De client maakt via HTTPS verbinding met die server en vraagt de content op.

De CNAME verandert waar de naamomzetting verdergaat. DNS geeft naaminformatie terug; de bytes van de video komen daarna via HTTP aan. Als de content is gesegmenteerd, volgen veel gewone segmentverzoeken hetzelfde basispad naar een geselecteerde server.

Kies een bruikbare locatie

Het dichtstbijzijnde cluster op de kaart kan een slecht netwerkpad hebben of overbelast zijn. Een beslissing op basis van DNS kan de locatie van de resolver zien, die ver van de gebruiker kan zijn. Een betere selectie kan gemeten vertraging en verlies, de huidige belasting en soms informatie over het netwerk van de client gebruiken.

IP-anycast biedt een andere route naar een dienst in de buurt: meerdere locaties kondigen hetzelfde IP-adres aan en internetroutering kiest een pad naar een daarvan. De resulterende locatie hangt af van routering, niet alleen van fysieke afstand. Een server dicht bij de kijker kan nog steeds slechte video leveren als de eigen toegangsverbinding van de kijker het knelpunt is.

Open Connect van Netflix plaatst apparaten binnen netwerken van internetproviders en sluit aan op knooppuntlocaties. Content wordt vooraf geplaatst, waardoor tijdens piekuren minder verkeer over de verbindingen naar buiten gaat. De applicatiediensten en de levering van gecodeerde video hoeven niet op dezelfde infrastructuur te draaien. Andere privé-CDN-ontwerpen kunnen caches op aanvraag vullen. In elk geval regelt adaptieve streaming welke snelheid de speler opvraagt, terwijl het CDN helpt bepalen via welk pad en vanaf welke server die verzoeken worden bediend.

Python-sockets verzenden bytes. Codeer een string voordat je die verzendt en decodeer de ontvangen bytes daarna; de standaardtekencodering is UTF-8. AF_INET selecteert IPv4 en SOCK_DGRAM selecteert UDP. Begin met een lokale dienst zodat beide processen loopbackadres 127.0.0.1 kunnen gebruiken.

Start eerst de ontvanger

Deze server verwerkt korte tekstdatagrammen en antwoordt in hoofdletters:

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind geeft de socket het ontvangstadres en de ontvangstpoort. Binden aan 127.0.0.1 accepteert alleen lokaal verkeer. De lege adresstring "" bindt daarentegen aan alle IPv4-interfaces, waardoor de dienst vanaf andere hosts bereikbaar is als het netwerk dat toestaat. Stop de draaiende server voordat je een ander exemplaar op hetzelfde eindpunt start.

recvfrom blokkeert totdat een datagram aankomt. De aanroep geeft de gegevens en het adres van de zender terug, inclusief de poort van de zender. De server gebruikt dat teruggegeven paar als bestemming van sendto, zodat die kan antwoorden aan clients waarvan de tijdelijke poorten vooraf niet bekend waren.

Verstuur een verzoek en begrens de wachttijd

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

Het voorvoegsel b maakt een bytesliteral; "hello network".encode() levert dezelfde bytes op. Het besturingssysteem wijst zo nodig de lokale poort van de client toe. Het verwachte antwoord is HELLO NETWORK. Geen van beide programma's roept listen of accept aan, omdat UDP geen transportverbinding opzet.

Een ontbrekend antwoord vertelt de client niet precies wat er misging. Het verzoek of antwoord kan verloren zijn gegaan, of er luistert geen server. Dankzij de time-out krijgt de applicatie de controle terug. Sommige systemen kunnen een gesloten bestemmingspoort als fout melden; Windows kan tijdens de ontvangst ConnectionResetError geven.

Respecteer datagramgrenzen

Elke ontvangst verwerkt één datagram. Twee datagrammen worden niet tot één bericht samengevoegd. Als de ontvangstbuffer te klein is, wordt het overtollige deel van dat datagram op gebruikelijke Unix-systemen weggegooid; Windows kan in plaats daarvan een fout melden. Een volgende ontvangst haalt het ontbrekende laatste deel niet terug. Kies een buffer die groot genoeg is voor de verwachte berichten van de applicatie.

De limiet voor de nettolading van UDP over IPv4 is 65.507 bytes bij een IPv4-header van minimale grootte. Dat is een protocolmaximum, geen bruikbare streefwaarde voor de gebruikelijke datagramgrootte. Een programma dat verlies moet detecteren, kan berichten nummeren, verzendtijden met time.perf_counter() vastleggen en time-outs tellen. Twee time-outs op tien verzoeken geven een gemeten verliespercentage van 20%. Een verzoek opnieuw proberen kan dubbele verwerking veroorzaken, dus een ontwerp met time-outs en nieuwe pogingen heeft mogelijk ook een manier nodig om herhaalde berichtnummers te herkennen.

TCP geeft het programma een geordende bytestroom. Het bewaart de grenzen van sendall-aanroepen niet. Een volledige korte test kan in één recv aankomen, maar een correct programma moet ook een verzoek kunnen verwerken dat over meerdere ontvangsten is verdeeld.

Baken één tekstverzoek af

Kies een nieuweregelteken als scheidingsteken. De client verzendt één UTF-8-regel en de server geeft één regel in hoofdletters terug. Deze server leest totdat die het scheidingsteken vindt en decodeert daarna:

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen maakt een luistersocket. accept geeft een nieuwe verbindingssocket en het adres van de client terug. Gebruik conn voor de bytes van deze client; de oorspronkelijke socket blijft beschikbaar om meer verbindingen te accepteren. Hier worden clients één voor één bediend. De wachtrijlimiet van vijf betreft wachtende verbindingen, geen vijf actieve werkthreads.

Voltooi de clientkant

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

Het verwachte resultaat is HELLO NETWORK. sendall blijft verzenden totdat alle aangeboden bytes zijn overgedragen of een fout optreedt. Eén send kan slechts een deel verzenden en meldt hoeveel bytes zijn geaccepteerd. Geen van beide aanroepen geeft de ontvanger applicatieberichtgrenzen.

Deze dienst accepteert één regel per verbinding. Een persistente dienst met meerdere berichten zou bytes na het eerste nieuweregelteken bewaren voor het volgende bericht. Een lengte voorop plaatsen en de verzendrichting sluiten zijn andere keuzes voor berichtafbakening. Ontvangst van b"" betekent dat de peer de verzendkant heeft beëindigd; het is geen leeg deel waarvoor je moet blijven proberen.

Verbind de code met echte protocollen

Een HTTP/1.1-verzoek is ook een reeks bytes:

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

Dit toont het begin van het ruwe antwoord, inclusief de status en headers. Een server kan een fout of omleiding teruggeven; de code gaat niet uit van een specifieke antwoordinhoud. HTTPS op poort 443 vereist een TLS-omhulling met verificatie van certificaat en hostnaam, niet alleen een gewijzigd poortnummer. Zo omhult ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") na import ssl een verbonden socket. Een geweigerde verbinding betekent vaak dat niemand luistert; stilzwijgend verworpen verkeer kan een time-out veroorzaken. Om een server op Unix snel te herstarten, kan SO_REUSEADDR vóór bind instellen hergebruik toestaan terwijl een oude verbinding wordt gesloten; het laat niet toe dat twee actieve luisterprocessen hetzelfde eindpunt bezitten. Servers die gelijktijdig werken gebruiken threads of gebeurtenislussen en onderscheiden verbindingen aan de hand van beide eindpuntparen van adres en poort.