| Noch HTTP, noch HTTPS garanderen inherent de levering. Het zijn best-effort-protocollen. Hoewel ze mechanismen hebben om de hertransmissie van verloren pakketten aan te vragen (HTTP maakt gebruik van persistente verbindingen en pipelining, terwijl HTTPS daarop voortbouwt met TLS), is er geen absolute garantie dat een bericht uiteindelijk zijn bestemming zal bereiken. Netwerkproblemen, serverstoringen of andere onvoorziene problemen kunnen een succesvolle levering nog steeds in de weg staan.
Daarom is er geen protocol dat wordt gebruikt door webbrowsers en webservers dat levering garandeert op de manier waarop een protocol als TCP dat zou doen bij een point-to-point-communicatie (hoewel TCP het onderliggende transportprotocol is voor zowel HTTP als HTTPS). Om de levering te garanderen, heeft u aanvullende mechanismen nodig die buiten het bereik van alleen HTTP of HTTPS vallen, zoals:
* Berichtenwachtrijen (bijvoorbeeld RabbitMQ, Kafka): Deze systemen bieden een gegarandeerde bezorging door berichten aan te houden en de ontvangst te bevestigen.
* Aangepaste bevestigingen op applicatieniveau: De applicatie zelf kan een systeem implementeren om de ontvangst te bevestigen.
* Redundantie en nieuwe pogingen: De applicatie kan meerdere pogingen verzenden en mechanismen implementeren om fouten af te handelen.
Kortom, HTTP en HTTPS zijn ontworpen voor efficiënte gegevensoverdracht en niet voor gegarandeerde levering. Die verantwoordelijkheid wordt verschoven naar protocollen op een hoger niveau of strategieën op applicatieniveau. |
