technique · réponse sourcée
Nouvelles tentatives avec backoff exponentiel
Les nouvelles tentatives avec backoff exponentiel sont une stratégie de gestion des erreurs dans laquelle le délai entre deux tentatives successives d’une opération échouée augmente de façon exponentielle. Au lieu de réessayer à intervalles fixes, le système attend plus longtemps après chaque échec afin de laisser au serveur destinataire le temps de se remettre d’une congestion ou d’une panne temporaire.
Fonctionnement technique
Le processus commence par un délai d’attente initial, par exemple une seconde. Si la première nouvelle tentative échoue, ce délai est multiplié par un facteur constant, généralement deux. La deuxième tentative a lieu après deux secondes, la troisième après quatre, la quatrième après huit, et ainsi de suite. Cette progression géométrique se poursuit jusqu’à ce qu’un délai maximal ou un nombre maximal de tentatives soit atteint ; le message est alors marqué comme un échec définitif.
Pourquoi c’est important pour les expéditeurs
Cette méthode évite qu’un expéditeur ne lance involontairement une attaque par déni de service contre un serveur de messagerie destinataire. Si des milliers de messages échouent en même temps et sont tous réessayés toutes les dix secondes, le pic de trafic qui en résulte peut maintenir le destinataire hors ligne. En étalant les nouvelles tentatives, les expéditeurs préservent leur réputation et augmentent les chances qu’une erreur SMTP temporaire 4xx se résolve avant que le message ne soit abandonné.
Considérations opérationnelles
Le jitter est un complément essentiel à cette stratégie : il ajoute une petite part d’aléatoire au délai. Sans jitter, plusieurs requêtes ayant échoué au même moment sont réessayées par vagues synchronisées, ce qui crée des pics de trafic. Le jitter répartit uniformément les nouvelles tentatives sur la fenêtre de temps et réduit encore la pression sur l’infrastructure.
Erreurs de mise en œuvre courantes
Les développeurs oublient souvent de fixer un nombre maximal de tentatives ou un plafond de délai. Sans limite, le délai d’attente peut atteindre des heures, voire des jours, ce qui entraîne une latence inacceptable pour les e-mails transactionnels. Autre erreur : traiter les échecs définitifs 5xx comme s’ils pouvaient être réessayés. Le backoff exponentiel ne doit s’appliquer qu’aux erreurs temporaires 4xx, comme la limitation de débit ou un greylisting temporaire.
Exemple concret
Prenons un e-mail transactionnel envoyé via une API. La tentative 1 échoue avec une erreur 421 (serveur occupé). Le système attend 2 secondes. La tentative 2 échoue ; le système attend 4 secondes. La tentative 3 échoue ; le système attend 8 secondes. Au moment de la tentative 4, le serveur destinataire a probablement vidé sa file d’attente et l’e-mail peut être accepté. SendHQ propose des outils gratuits sur https://sendhq.cc/tools pour vous aider à gérer efficacement votre infrastructure e-mail.
Les questions que posent les équipes
Quelle est la différence entre backoff fixe et backoff exponentiel ?
Le backoff fixe réessaie toutes les X secondes, quel que soit le nombre d’échecs. Le backoff exponentiel allonge l’intervalle après chaque échec pour réduire la charge sur le serveur cible.
Quand faut-il arrêter de réessayer ?
Les nouvelles tentatives doivent s’arrêter lorsqu’un échec définitif 5xx est renvoyé, que le nombre maximal de tentatives est atteint ou que le plafond de délai est atteint.
Le jitter affecte-t-il la croissance exponentielle ?
Non, le jitter ajoute un décalage aléatoire au délai exponentiel calculé afin d’éviter des pics de nouvelles tentatives synchronisées entre plusieurs requêtes simultanées.
Sources primaires
- RFC 5321 : Simple Mail Transfer Protocol — RFC Editor
- Bonnes pratiques du M3AAWG — M3AAWG