|
Ni HTTP ni HTTPS ne garantissent intrinsèquement la livraison. Ce sont des protocoles de « meilleurs efforts ». Bien qu'ils disposent de mécanismes pour demander la retransmission des paquets perdus (HTTP utilise des connexions persistantes et un pipeline, tandis que HTTPS s'appuie sur cela avec TLS), il n'y a aucune garantie absolue qu'un message finira par atteindre sa destination. Des problèmes de réseau, des pannes de serveur ou d'autres problèmes imprévus peuvent toujours empêcher une livraison réussie.
Par conséquent, aucun protocole utilisé par les navigateurs Web et les serveurs Web ne garantit la livraison de la même manière qu'un protocole tel que TCP le ferait dans une communication point à point (bien que TCP soit le protocole de transport sous-jacent pour HTTP et HTTPS). Pour garantir la livraison, vous avez besoin de mécanismes supplémentaires en dehors du cadre de HTTP ou HTTPS, tels que :
* Files d'attente de messages (par exemple, RabbitMQ, Kafka) : Ces systèmes offrent une livraison garantie par la persistance des messages et l'accusé de réception.
* Accusés personnalisés au niveau de l'application : L'application elle-même peut mettre en œuvre un système pour confirmer la réception.
* Redondance et tentatives : L'application peut envoyer plusieurs tentatives et implémenter des mécanismes pour gérer les échecs.
En bref, HTTP et HTTPS sont conçus pour un transfert de données efficace et non pour une livraison garantie. Cette responsabilité est transférée aux protocoles de niveau supérieur ou aux stratégies au niveau des applications.
|
