Résumé

  • Dans l’exemple borné de RFC 5390, une requête SIP pouvait engendrer jusqu’à dix-huit requêtes et autant de réponses lorsque retransmissions UDP, réponses 503 et essais sur trois serveurs saturés se combinaient.
  • Le même code pouvait aussi mettre au repos des serveurs sains, car sa portée — adresse IP, nom d’hôte ou URI — n’était pas suffisamment explicite; un arrêt binaire pouvait en outre faire osciller toute la charge entre deux nœuds.
  • Les travaux ultérieurs ont séparé mesure, décision, retour d’information et actionneur amont. Un refus valide ne prouve ni la réduction de la charge offerte, ni la fin d’une transaction, ni la réussite d’un appel.

Compter le travail après le refus

Le mécanisme hérité de RFC 3261 proposait une intuition simple. Un serveur momentanément incapable de traiter une requête renvoie 503. Il peut ajouter Retry-After. Le client ou le proxy cherche éventuellement un autre serveur et évite le premier pendant l’intervalle annoncé. Le service paraît ainsi se déplacer vers la capacité disponible.

RFC 5390 a examiné le cas où cette capacité disponible n’existe plus. Un proxy P1 répartit les requêtes entre S1, S2 et S3. Les trois sont saturés. S1 met du temps à formuler son refus, le transport UDP peut retransmettre, puis P1 recommence sur S2 et S3. Chaque destination consomme des cycles pour aboutir au même résultat négatif.

Le document calcule alors une borne pédagogique. Avec les retransmissions prévues dans cet exemple, une requête d’origine peut produire jusqu’à dix-huit requêtes et autant de réponses avant expiration. Ce chiffre n’est pas une mesure d’un réseau commercial et ne doit pas devenir une statistique générale. Il prouve néanmoins qu’un protocole peut augmenter son débit de messages tout en réduisant son débit utile.

Même sans retransmission TCP, le problème d’autorité subsiste. P1 essaie trois destinations parce qu’aucun signal ne lui dit que la contrainte est commune. Le transport peut livrer fidèlement chaque essai; il ne sait pas si cet essai a une chance différente de réussir.

Le premier reçu opérationnel doit donc compter ce qui cesse, pas seulement ce qui répond. Après un 503, combien de nouvelles tentatives sont parties? Vers quels domaines de panne? Combien de transactions utiles ont abouti? La réponse au protocole et la réduction du travail sont deux événements distincts.

La dépendance cachée annule la diversité apparente

RFC 5390 ajoute un proxy PA au-dessus de deux répartiteurs P1 et P2. P1 découvre par ses échecs que S1, S2 et S3 sont saturés. Pourtant cette connaissance ne revient pas à PA sous une forme exploitable. PA tente P2, qui visite de nouveau les trois mêmes serveurs.

Le graphe comporte davantage de chemins, mais pas davantage de ressources indépendantes. Les étiquettes P1 et P2 suggèrent une redondance; leur dépendance commune transforme la redondance en répétition. Un indicateur de disponibilité limité au prochain saut ne peut pas montrer ce partage.

La réutilisation de 503 pour d’autres pannes rendait l’inférence encore plus fragile. Une passerelle SIP peut disposer de CPU tout en échouant à cause d’un tronçon téléphonique indisponible. Deux serveurs peuvent être sains mais dépendre de la même base de données arrêtée. Dans un cas, un autre chemin pourrait aider; dans l’autre, changer de façade reconduit vers la même cause.

RFC 5390 exigeait donc qu’un signal explicite d’overload se distingue des autres échecs. La causalité n’était pas un détail destiné à l’analyste après incident. Elle déterminait l’action immédiate du proxy: réessayer, ralentir, détourner ou arrêter.

Cette séparation rejoint la discipline des couches de réalité de Lu Heng. Le code visible, la ressource saturée, la dépendance en panne, la décision du proxy et l’issue de l’appel ne sont pas une seule vérité. Un système gouvernable conserve chacun de ces objets et la liaison qui les unit.

Une portée trop large mettait la capacité saine hors service

La surcharge ne produisait pas seulement trop de travail. Elle pouvait aussi laisser du travail possible inexploité. RFC 3261 ne précisait pas assez clairement si un 503 concernait une adresse, un nom d’hôte ou une URI. Certaines implémentations appliquaient le refus au nom d’hôte.

Si ce nom se résout par DNS SRV vers plusieurs membres d’une ferme, le refus d’un seul membre peut conduire P1 à suspendre toute la ferme. Le serveur saturé exerce alors, involontairement, une autorité sur ses voisins encore disponibles. Une observation locale devient une fermeture collective.

REQ 18 demandait une portée non ambiguë. L’objet désigné doit être assez précis pour éviter deux erreurs symétriques: continuer à envoyer vers la ressource réellement saturée, ou retirer du service des ressources que le signal n’a jamais observées.

La vérification ne peut donc se limiter à « le proxy a honoré 503 ». Elle doit comparer l’objet annoncé avec la table de destinations réellement modifiée. Si le signal concerne une combinaison IP-port et que l’action désactive un domaine entier, l’actionneur a élargi l’autorité du signal.

Ce contrôle est économique autant que technique. Une capacité saine immobilisée pendant une pointe perd sa valeur au moment où elle est la plus utile. À l’inverse, un périmètre trop étroit peut continuer à alimenter une dépendance commune. Le contrat de portée doit refléter la ressource qui gouverne effectivement le succès.

Le minuteur binaire fabriquait un mouvement sans équilibre

Dans l’exemple à deux serveurs de RFC 5390, S1 et S2 sont chacun à 100%. S1 répond avec Retry-After. P1 retire tout le trafic de S1 et l’envoie à S2, qui passe à 200%. S2 se retire à son tour. Lorsque le minuteur de S1 expire, tout revient vers S1 et le cycle recommence.

Chaque minuteur peut être correct isolément. L’oscillation vient de la commande: tout ou rien. Le signal ne dit pas que S1 pourrait accepter une fraction réduite. Il ne donne pas à P1 une cible graduée qui stabilise la somme des flux.

RFC 5390 limite soigneusement cette conclusion. Un serveur recevant de très nombreux petits flux indépendants peut obtenir une réduction graduée en envoyant 503 à seulement une partie de ses clients. L’article ne transforme donc pas Retry-After en mécanisme toujours défectueux. Il constate que la stabilité dépendait d’une topologie que le contrat ne garantissait pas.

REQ 7 demandait explicitement un étranglement gradué. REQ 21 demandait que le débit utile se stabilise lorsque la charge offerte redescend sous la capacité. Ces exigences donnent une définition testable du succès: le système doit converger, pas seulement alterner des refus valides.

Un minuteur demeure une information temporelle. Il ne réserve pas la capacité future et ne promet pas que la cause aura disparu à son expiration. La reprise exige une nouvelle observation; le temps écoulé n’est pas un reçu de santé.

Le contrôle ultérieur a séparé quatre responsabilités

RFC 6357 a décrit une architecture où un processeur SIP est protégé par un moniteur, une fonction de contrôle, un retour d’information et un actionneur. Le moniteur mesure. La fonction de contrôle décide qu’une réduction est nécessaire. Le retour transporte une consigne. L’actionneur du nœud amont limite effectivement le trafic.

Cette décomposition rend les échecs attribuables. Une mesure exacte peut produire une consigne tardive. Une consigne correcte peut être ignorée. Un actionneur peut respecter un plafond global tout en choisissant mal les messages. Une baisse du trafic peut enfin ne pas restaurer le service si la véritable contrainte se trouve dans une base ou une passerelle externe.

RFC 6357 reconnaît aussi le coût du rejet local. Refuser une requête utilise des ressources; le rejet local ne suffit donc pas à prévenir l’effondrement par congestion. Il reste un dernier rempart, tandis que la réduction efficace se place avant le processeur rare.

RFC 7339 a ensuite porté le retour d’overload dans le champ Via supérieur entre deux voisins SIP. Le voisin amont annonce les algorithmes qu’il comprend; le serveur aval ajoute une valeur oc, une validité et une séquence. Le retrait du Via supérieur borne le message au saut adjacent.

Ce choix ne crée pas une autorité de bout en bout. Il installe une boucle entre deux acteurs capables de coopérer. Le déploiement partiel peut améliorer cette relation sans prouver que tous les sauts d’un appel possèdent le même contrôle.

Une réduction en pourcentage n’est pas un plafond de débit

RFC 7339 impose la prise en charge du mode fondé sur la perte. Le serveur demande à son voisin de supprimer une part des requêtes. Cette consigne est légère et s’adapte à plusieurs algorithmes locaux, mais la part acceptée augmente si la charge offerte augmente. Dix pour cent d’un flot qui double représente toujours davantage de messages.

RFC 7415 a défini un mode optionnel fondé sur le débit. Le serveur peut annoncer un maximum de requêtes par seconde pour un client, valable jusqu’à une mise à jour. Ce plafond reste constant pendant cet intervalle. En échange, le serveur doit gérer des cibles qui peuvent différer selon les clients.

Le pourcentage et le débit ne promettent pas le même objet. Aucun ne promet un nombre d’appels réussis. Deux messages SIP peuvent consommer des ressources différentes; le mélange change lorsque le proxy privilégie certaines classes. Le plafond reçu ne dispense pas l’actionneur de choisir.

RFC 5390 avait expressément conservé cette autorité locale. Il ne dictait pas l’algorithme de priorité. Un opérateur peut protéger les appels d’urgence, les transactions déjà engagées ou les messages qui libèrent de l’état. La norme rend la contrainte échangeable; elle ne choisit pas la politique commerciale ou de sécurité.

Le dossier de preuve doit donc lier oc, algorithme, durée et séquence à la cadence réellement transmise, puis aux classes sélectionnées et aux transactions achevées. Une conformité au plafond peut coexister avec une mauvaise qualité de décision.

Le débit utile est plus exigeant que le débit de réponses

REQ 1 choisit le débit utile comme mesure ultime sous surcharge. Cette formulation empêche un serveur de déclarer une victoire parce qu’il produit rapidement beaucoup de 503. Un système qui refuse tout sans s’effondrer est stable, mais il ne fournit aucun service.

Le débit utile dépend de l’état libéré et de l’objectif de l’application. Traiter la fin d’un dialogue peut restituer des ressources. Renouveler un enregistrement peut maintenir la joignabilité. Accepter un nouvel INVITE peut au contraire créer une charge longue. Compter chaque message de la même manière masque cette économie.

La métrique doit relier admission, fin de transaction, état du dialogue et résultat voulu. Elle doit aussi montrer le coût du refus lui-même. Sinon, l’optimisation peut améliorer le chiffre surveillé tout en transférant la charge au voisin ou en dégradant une classe prioritaire.

La primauté du code en fonctionnement impose une dernière prudence. La publication de RFC 7339 ou RFC 7415 ne prouve pas que la boucle s’exécute dans un produit actuel. Il faut observer les paramètres négociés, l’actionneur installé, les paquets émis, les ressources protégées et les transactions terminées.

Limite des preuves

Les sources figées établissent le texte des RFC, leur statut, les problèmes déclarés et l’architecture standardisée plus tard. Elles n’établissent pas l’usage actuel par un opérateur, l’adoption d’un constructeur, la cause d’une panne précise ou la fréquence d’un phénomène.

La borne de dix-huit doit rester attachée à la topologie et aux hypothèses du document. Le scénario d’oscillation doit rester attaché à un petit nombre de sources amont. Le 503 doit rester un événement dont la cause est à démontrer. Défaire ces attaches transformerait un article sur la provenance en nouvelle simplification.

La conclusion durable est plus étroite et plus forte. Un refus est un signal de décision locale. Le contrôle existe seulement lorsque l’acteur amont réduit effectivement le bon travail, pour la bonne ressource, pendant une durée bornée, et que le débit utile observé se rétablit.