Was ist RED?

Veröffentlicht am 13. August 2026

← Alle Begriffe im Glossar Weiter zu R

Random Early Drop (RED), auch als „Random Early Detection“ bezeichnet, ist ein Verfahren zur Vermeidung von Überlastungen, bei dem die durchschnittliche Warteschlangenlänge an einer Netzwerkschnittstelle überwacht wird und Pakete mit einer bestimmten Wahrscheinlichkeit verworfen werden, bevor die Warteschlange vollständig gefüllt ist. Dadurch werden die Absender dazu veranlasst, ihre Übertragungsrate frühzeitig zu drosseln, anstatt auf einen abrupten, pauschalen „Tail Drop“ zu warten.

Die wichtigsten Erkenntnisse

  • RED verwirft Pakete stichprobenartig, bevor sich eine Warteschlange füllt, und nicht alle auf einmal.
  • Es verhindert den sprunghaften, synchronisierten Datenverlust, der bei einer einfachen Tail-Drop-Warteschlange auftritt.
  • Die Ausfallwahrscheinlichkeit steigt mit zunehmender durchschnittlicher Warteschlangenlänge zwischen zwei Schwellenwerten.
  • In den DoS-/Flood-Profilen von „ Versa “ ist RED eine Maßnahme zwischen „Allow“ und „Hard Drop“.
  • Weighted RED (WRED) wendet je nach Verkehrsklasse unterschiedliche Drop-Schwellenwerte an.

Auf dieser Seite: Warum das wichtig istSo funktioniert esArtenROT & VersaHäufig gestellte Fragen

Warum ist RED wichtig?

Ohne eine Technik wie RED wartet eine überlastete Schnittstelle, die mit einfachem Tail-Drop-Queuing arbeitet, so lange, bis ihr Puffer voll ist, und verwirft dann jedes eintreffende Paket, bis wieder Platz frei wird. Viele TCP-Datenströme, die sich diese Verbindung teilen, verlieren gleichzeitig Pakete und werden gleichzeitig langsamer, um dann gemeinsam wieder an Geschwindigkeit zu gewinnen – eine globale Synchronisation, ein Muster, das zu Schwankungen im Durchsatz führt und Kapazität verschwendet.

RED ist wichtig, weil es früher und gerechter eingreift. Das Verwerfen einer kleinen, zufälligen Stichprobe von Paketen, sobald die Warteschlange zu wachsen beginnt – lange bevor sie voll ist –, bedeutet, dass nur die Datenströme beeinträchtigt werden, und zwar zu unterschiedlichen Zeitpunkten und nicht alle gleichzeitig. Dadurch bleiben die durchschnittliche Warteschlangentiefe und die Latenz niedrig, während Spitzenlasten dennoch aufgefangen werden, was den Betreibern ein frühzeitiges Signal liefert, anstatt einer abrupten „Alles-oder-Nichts“-Unterbrechung.

Was ist RED?

RED arbeitet mit zwei konfigurierten Schwellenwerten und einer Berechnung der durchschnittlichen Warteschlangenlänge – in der Regel handelt es sich dabei um einen exponentiell gewichteten gleitenden Durchschnitt und nicht um die momentane Länge der Warteschlange, sodass ein kurzer Datenansturm an sich noch keine Reaktion auslöst. Unterhalb des Mindestschwellenwerts wird nichts verworfen. Zwischen dem Mindest- und dem Höchstschwellenwert steigt die Verwerfungswahrscheinlichkeit in Richtung des Höchstwerts: Eine kleine Anzahl von Paketen wird frühzeitig geopfert, um TCP-Absendern ein Signal zu geben, die daraufhin ihre Übertragungsrate drosseln, bevor die Warteschlange überläuft. Sobald der Durchschnittswert den Höchstwert erreicht, verwirft RED jedes ankommende Paket und verhält sich wie ein gewöhnlicher Tail-Drop – und da die früheren Verwerfungen praktisch zufällig ausgewählt werden, verteilt sich das Signal auf viele Verbindungen, anstatt sich auf den Datenfluss zu konzentrieren, der gerade dann eintrifft, wenn der Puffer bereits voll ist.

Arten von RED

Mehrere Varianten erweitern den Basisalgorithmus. Weighted RED (WRED) wendet je nach Verkehrsklasse unterschiedliche Schwellenwerte und Verwerfungswahrscheinlichkeiten an – in der Regel in Abhängigkeit von einer DSCP- oder IP-Prioritätskennzeichnung –, sodass Verkehr mit niedrigerer Priorität früher verworfen wird als latenz- oder verlustempfindliche Klassen, die sich dieselbe Warteschlange teilen. RED mit In/Out (RIO) ist eine DiffServ-orientierte Variante, die getrennte Verwerfungskurven für Pakete innerhalb und außerhalb des Profils führt. Adaptives RED passt die maximale Verwerfungswahrscheinlichkeit automatisch so an, dass die durchschnittliche Warteschlangenlänge nahe einem Sollwert gehalten wird, wodurch die Notwendigkeit einer manuellen Feinabstimmung der Parameter für eine bestimmte Verbindung verringert wird.

Alle diese Varianten behalten den Kernmechanismus von RED bei – das probabilistische, durch Schwellenwerte begrenzte Weglassen basierend auf der durchschnittlichen Warteschlangenlänge – und unterscheiden sich hauptsächlich darin, wie viele Weglasskurven sie verwalten.

ROT & Versa

Auf von Versa Titan verwalteten SASE -Gateways ist RED eine konfigurierbare Aktion innerhalb von DoS-Schutzprofilen, auf die aus einer DoS-Schutzrichtlinie verwiesen wird, die den Datenverkehr nach Zone, Adresse und Protokoll filtert. Jedes Profil legt Flood-Schwellenwerte pro Protokoll fest – ICMP, ICMPv6, TCP, UDP, SCTP und anderer IP-Datenverkehr –, einschließlich einer Alarmrate, einer Aktivierungsrate und einer festen Maximalrate in Paketen pro Sekunde.

Sobald die Aktivierungsrate überschritten wird, kann ein Administrator im Feld „Aktion“ zwischen „Zufällige vorzeitige Abbruch“ und „SYN-Cookies“ wählen – einer TCP-spezifischen Abwehrmaßnahme, bei der Verbindungen bestätigt werden, ohne den Sitzungsstatus festzulegen; „SYN-Cookies“ ist die Standardeinstellung. Datenverkehr, der die maximale Rate überschreitet, wird unabhängig von der gewählten Aktion sofort verworfen – RED regelt nur den Bereich dazwischen. Administratoren erstellen diese Profile über die Registerkarte „Sicherheit“ im „Titan -Portal“, der Konsole von Versafür Geräte der SASE -Gateway-Reihe.

Ein verwandter, aber eigenständiger Mechanismus ist die NPU-basierte QoS-Verkehrskontrolle von Versa, bei der Policer Pakete anhand von CIR-/CBS-/PIR-/PBS-Schwellenwerten mit den Farben Grün, Gelb oder Rot kennzeichnen – eine deterministische Kennzeichnung, nicht der probabilistische Verwerfungsmechanismus von RED.

Häufig gestellte Fragen

Was ist der Unterschied zwischen RED und Tail Drop?

Beim „Tail Drop“ wird die Warteschlange vollständig gefüllt, anschließend werden alle Pakete verworfen, bis wieder Platz frei wird – ein plötzlicher, synchronisierter Verlust für jeden Datenfluss auf der Verbindung. Beim RED-Verfahren wird ein zufälliger Anteil bereits früher verworfen, wodurch das Signal verteilt wird, anstatt in einem einzigen abrupten Ausbruch zu erfolgen.

Warum verwirft RED Pakete nach dem Zufallsprinzip und nicht nach einer festen Regel?

Durch eine zufällige Auswahl wird vermieden, dass ein einzelner Datenstrom unverhältnismäßig stark benachteiligt wird. Eine feste Regel könnte dazu führen, dass ein einzelner Datenstrom mit hohem Datenaufkommen den größten Teil des Verlusts abbekommt, während andere unberührt bleiben. Durch die Zufallsauswahl verteilt sich die Auswirkung in etwa proportional zum Verkehrsanteil der einzelnen Datenströme.

Ersetzt RED die TCP-eigene Überlastungskontrolle?

Nein. RED arbeitet mit TCP zusammen. Das vorzeitige Verwerfen eines Pakets löst die bestehende Überlastungskontrollreaktion von TCP aus – der Absender interpretiert den Verlust als Signal, die Übertragungsrate zu drosseln. Dies ist dieselbe Reaktion, die auch ein später „Tail-Drop“-Verlust auslöst, nur dass sie hier früher und sanfter erfolgt.

Ist RED in modernen Hochgeschwindigkeitsnetzwerken noch relevant?

Ja, allerdings haben spätere IETF-Leitlinien die Empfehlung von RED speziell auf das Active Queue Management (AQM) im Allgemeinen ausgeweitet, da sich die festen Parameter von RED bei unterschiedlichen Verbindungsgeschwindigkeiten nur schwer anpassen lassen. Das zugrunde liegende Prinzip – frühzeitiges und probabilistisches Verwerfen – bleibt jedoch der Standard.

Wann verwendet „ Versa “ „Random Early Drops“ anstelle von SYN-Cookies?

Beides sind alternative Maßnahmen in den Flood-Einstellungen eines DoS-Profils, die zum Tragen kommen, sobald die Aktivierungsrate eines Protokolls überschritten wird. „SYN Cookies“ schützt speziell vor TCP-SYN-Floods und ist die Standardeinstellung; „Random Early Drops“ gilt bei Auswahl allgemeiner für alle vor Floods geschützten Protokolle.

Mehr zu RED

Wenn Sie mehr erfahren möchten, finden Sie hier Quellen, denen wir vertrauen.

IETF RFC 2309: Empfehlungen zum Warteschlangenmanagement IETF RFC 7567: Aktives Warteschlangenmanagement
Die IETF-Empfehlung aus dem Jahr 1998, durch die RED als Standardmechanismus für das aktive Warteschlangenmanagement bei überlasteten Internet-Routern bekannt wurde. Die Aktualisierung von 2015, mit der die IETF-Leitlinien von RED unter Verweis auf die Schwierigkeiten bei der Feinabstimmung von RED speziell auf das aktive Warteschlangenmanagement im Allgemeinen ausgeweitet wurden.

Wenn Sie sich gerade über RED informieren, sollten Sie sich als Nächstes diese Artikel ansehen.

Zone SD-WAN Zweigstelle
Ein Sicherheitskonstrukt von „ Versa “, das Schnittstellen und Netzwerke gruppiert und als Übereinstimmungskriterium in den DoS- und Flood-Schutzrichtlinien dient, in denen RED zum Einsatz kommt. Die verkehrsgesteuerte Überlagerung über Zweigstellen-, Cloud- und Rechenzentrumsverbindungen, bei der Hochwasserschutz und RED-basiertes Dropping die gemeinsam genutzte Kapazität schützen. Ein Standort, an dem ein VOS-Gerät im Einsatz ist, auf dem zonenbasierte DoS-Schutzprofile – und die darin enthaltene RED-Maßnahme – vor Flood-Angriffen schützen.