Qu'est-ce que RED ?

Publié le 13 août 2026

← Tous les termes du glossaire Aller à la lettre R

Le « Random Early Drop » (RED), également appelé « Random Early Detection », est une technique de prévention de la congestion qui surveille la longueur moyenne de la file d'attente sur une interface réseau et commence à rejeter des paquets de manière aléatoire avant que la file d'attente ne soit complètement remplie, ce qui incite les expéditeurs à ralentir leur débit dès le début plutôt que d'attendre un rejet brutal et massif en fin de file.

Points clés à retenir

  • RED rejette les paquets de manière aléatoire avant que la file d'attente ne soit pleine, et non pas tous en même temps.
  • Cela permet d'éviter les pertes synchronisées et en rafales provoquées par la mise en file d'attente classique avec suppression en fin de file.
  • La probabilité de perte augmente lorsque la longueur moyenne de la file d'attente se situe entre deux seuils.
  • Dans les profils DoS/flood d'Versa , RED est une action intermédiaire entre « Allow » (Autoriser) et « Hard Drop » (Rejet catégorique).
  • Le RED pondéré (WRED) applique des seuils de suppression différents selon chaque classe de trafic.

Sur cette page : Pourquoi est-ce important ?Comment ça marcheTypesROUGE & VersaFAQ

Pourquoi le rouge est-il important ?

Sans une technique telle que RED, une interface encombrée utilisant une file d'attente simple avec suppression des paquets (tail-drop) attend que sa mémoire tampon soit pleine, puis rejette tous les paquets entrants jusqu'à ce qu'un espace se libère. De nombreux flux TCP partageant cette liaison perdent des paquets simultanément et subissent un ralentissement simultané, avant de reprendre ensemble leur rythme normal : il s'agit d'une synchronisation globale, un phénomène qui entraîne un débit oscillant et un gaspillage de capacité.

Le protocole RED est important car il intervient plus tôt et de manière plus équitable. Le fait de rejeter un petit échantillon aléatoire de paquets dès que la file d’attente commence à s’allonger – bien avant qu’elle ne soit pleine – signifie que seuls les flux sont affectés, à des moments différents plutôt qu’en même temps. Cela permet de maintenir la profondeur moyenne de la file d’attente et la latence à un faible niveau tout en absorbant les pics de trafic, offrant ainsi aux opérateurs un signal précoce plutôt qu’une coupure brutale et radicale.

Qu'est-ce que RED ?

RED fonctionne selon deux seuils configurés et un calcul de la longueur moyenne de la file d’attente – généralement une moyenne mobile pondérée de manière exponentielle, et non la profondeur instantanée –, de sorte qu’un pic de trafic de courte durée ne déclenche pas en soi de réaction. En dessous du seuil minimal, aucun paquet n’est rejeté. Entre le seuil minimal et le seuil maximal, la probabilité de rejet augmente progressivement jusqu’au seuil maximal : un petit nombre de paquets est sacrifié dès le début pour signaler aux expéditeurs TCP qu’ils doivent ralentir leur envoi avant que la file d’attente ne déborde. Une fois que la moyenne atteint le seuil maximal, RED rejette tous les paquets entrants, se comportant alors comme un rejet de queue classique ; et comme les rejets initiaux sont choisis de manière pratiquement aléatoire, le signal se répartit sur de nombreuses connexions au lieu de se concentrer sur le flux qui arrive au moment où le tampon est déjà plein.

Types de RED

Plusieurs variantes viennent étendre l’algorithme de base. Le RED pondéré (WRED) applique des seuils et des probabilités de rejet différents selon la classe de trafic – généralement en fonction d’un marquage DSCP ou de priorité IP –, de sorte que le trafic de moindre priorité soit rejeté plus tôt que les classes sensibles à la latence ou aux pertes partageant la même file d’attente. Le RED avec entrée/sortie (RIO) est une variante orientée DiffServ qui maintient des courbes de rejet distinctes pour les paquets conformes au profil et ceux hors profil. Le RED adaptatif ajuste automatiquement la probabilité maximale de rejet afin de maintenir la longueur moyenne de la file d’attente proche d’une valeur cible, ce qui réduit la nécessité de régler manuellement les paramètres pour une liaison donnée.

Toutes ces méthodes conservent le mécanisme central de RED – un rejet probabiliste limité par un seuil, basé sur la longueur moyenne de la file d’attente – et se distinguent principalement par le nombre de courbes de rejet qu’elles utilisent.

ROUGE & Versa

Sur les passerelles Versa Titan -managed SASE , RED est une action configurable au sein des profils de protection contre les attaques DoS, référencée à partir d’une politique de protection contre les attaques DoS qui filtre le trafic en fonction de la zone, de l’adresse et du protocole. Chaque profil définit des seuils de saturation par protocole (ICMP, ICMPv6, TCP, UDP, SCTP et autre trafic IP), notamment un « taux d’alarme », un « taux d’activation » et un « taux maximal absolu », exprimés en paquets par seconde.

Dès que le seuil d’activation est dépassé, le champ « Action » permet à l’administrateur de choisir entre « Random Early Drops » (rejets aléatoires anticipés) ou « SYN Cookies », une défense spécifique au protocole TCP qui accuse réception des connexions sans enregistrer l’état de la session ; l’option « SYN Cookies » est sélectionnée par défaut. Le trafic dépassant le débit maximal est purement et simplement rejeté, quelle que soit l’action choisie – RED ne régit que la plage intermédiaire. Les administrateurs configurent ces profils à partir de l’onglet « Sécurité » du portailTitan , la console de Versadédiée aux périphériques de la gamme de passerelles SASE .

Un mécanisme connexe mais distinct est le contrôle du trafic QoS basé sur la NPU d'Versa, dans lequel les contrôleurs marquent les paquets en vert, jaune ou rouge en fonction des seuils CIR/CBS/PIR/PBS – il s'agit d'un marquage déterministe, et non d'un rejet probabiliste comme dans le protocole RED.

Questions fréquentes

Quelle est la différence entre « RED » et « tail drop » ?

Le « tail drop » laisse la file d'attente se remplir entièrement, puis rejette tous les paquets jusqu'à ce qu'un espace se libère – ce qui entraîne une perte soudaine et synchronisée pour tous les flux sur la liaison. Le protocole RED rejette une fraction aléatoire de paquets plus tôt, répartissant ainsi le signal au lieu de provoquer une rafale brutale.

Pourquoi RED rejette-t-il des paquets de manière aléatoire plutôt que selon une règle fixe ?

La sélection aléatoire permet d'éviter de pénaliser un flux de manière disproportionnée. Une règle fixe pourrait conduire un seul flux à fort débit à absorber la majeure partie de la perte, tandis que les autres passeraient sans être affectés. La sélection aléatoire répartit la réponse de manière à peu près proportionnelle à la part de trafic de chaque flux.

Le protocole RED remplace-t-il le mécanisme de contrôle de congestion propre au protocole TCP ?

Non. Le protocole RED fonctionne en parallèle avec le protocole TCP. Le rejet précoce d’un paquet déclenche la réponse de contrôle de congestion prévue par le protocole TCP : l’expéditeur interprète cette perte comme un signal lui indiquant de ralentir, ce qui correspond à la même réaction que celle provoquée par une perte tardive due au « tail-drop », mais de manière plus précoce et plus progressive.

Le protocole RED est-il toujours d'actualité sur les réseaux modernes à haut débit ?

Oui, même si les recommandations ultérieures de l’IETF ont élargi leur champ d’application, passant du protocole RED en particulier à la gestion active des files d’attente (AQM) en général, car les paramètres fixes du RED sont difficiles à ajuster en fonction des variations de débit des liaisons. Le principe sous-jacent – le rejet précoce et probabiliste – reste toutefois la norme.

Dans quels cas le protocole « Versa » utilise-t-il les « Random Early Drops » à la place des « SYN Cookies » ?

Ces deux options constituent des mesures alternatives dans les paramètres de protection contre les attaques par saturation d’un profil DoS ; elles sont activées dès que le seuil de « Activate Rate » d’un protocole est dépassé. L’option « SYN Cookies » protège spécifiquement contre les attaques par saturation TCP SYN et est sélectionnée par défaut ; l’option « Random Early Drops », quant à elle, s’applique de manière plus générale à tous les protocoles protégés contre les attaques par saturation lorsqu’elle est sélectionnée.

En savoir plus sur RED

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

RFC 2309 de l'IETF : Recommandations relatives à la gestion des files d'attente IETF RFC 7567 : Gestion active des files d'attente
La recommandation de l'IETF de 1998 qui a popularisé le protocole RED en tant que mécanisme par défaut de gestion active des files d'attente pour les routeurs Internet saturés. La mise à jour de 2015 élargissant les recommandations de l'IETF relatives au RED pour les étendre plus spécifiquement à la gestion active des files d'attente en général, en invoquant les difficultés de réglage du RED.

Si vous vous intéressez à RED, voici quelques liens qui pourraient vous intéresser.

Zone SD-WAN Agence
Une entité de sécurité « Versa » regroupant des interfaces et des réseaux, utilisée comme critère de correspondance dans les politiques de protection contre les attaques par déni de service (DoS) et les attaques par inondation de paquets, lorsque le protocole RED s'applique. La couche de gestion du trafic mise en place sur les liaisons entre les succursales, le cloud et les centres de données, où la protection contre le débordement et le filtrage basé sur le protocole RED préservent la capacité partagée. Un site équipé d'un dispositif VOS, où des profils de protection contre les attaques par déni de service (DoS) basés sur les zones – et l'action RED qu'ils contiennent – protègent contre les attaques par inondation de paquets.