Schauen wir uns einige der Warteschlangenmechanismen für das Überlastungsmanagement an.
Es gibt viele Warteschlangenmechanismen.
Einige davon sind älter und / oder für moderne Rich Media-Netzwerke ineffizient.
Mit anderen Worten, sie waren in der Vergangenheit gut, eignen sich jedoch nicht für Voice over IP und Video, die
über ein Datennetzwerk ausgeführt werden.
Beginnen wir also mit einer FIFO First In First Out-Warteschlange.
Dies besteht aus einer einzelnen Warteschlange mit Paketen, die in der genauen Reihenfolge gesendet werden, in der sie angekommen sind.
Wir haben diesen Warteschlangenmechanismus wahrscheinlich alle in der realen Welt erlebt.
In diesem Beispiel haben wir Leute, die für ihre Einkäufe bezahlen möchten.
Es gibt nur einen Kassierer, an dem sie bezahlen können.
Die Leute werden in der Reihenfolge "Wer zuerst kommt, mahlt zuerst" bedient.
Mit anderen Worten First In First Out.
Diese Dame kam zuerst an.
Also diente sie zuerst.
Dieser Herr kam als Zweiter an, also diente er eine Sekunde und so weiter und so fort.
Dies ist die Vorderseite der Warteschlange.
Dies ist die Rückseite der Warteschlange, und die Personen werden in dieser Reihenfolge bedient.
Auf die gleiche Weise werden in einem FIFO-Warteschlangenalgorithmus auf einem Rota-Paket Pakete in der Reihenfolge zugestellt, in der sie angekommen sind.
Dies ist die Vorderseite der Warteschlange.
Dies ist die Rückseite der Warteschlange. Neue Pakete befinden sich in der Warteschlange an den hinteren Paketen an der Vorderseite der Warteschlange
oder D in der Warteschlange und werden zur Übertragung weitergeleitet.
Das Problem bei diesem Warteschlangenmechanismus ist, dass Sprachpakete durch größere Datenpakete verzögert werden können.
Jeder wird auf die gleiche Weise bedient, was in einigen Fällen in der realen Welt gut funktionieren kann,
aber das wäre kein Beispiel, wenn es einen Notfall und einen Krankenwagen gäbe.
Als Beispiel musste man an die Spitze der Warteschlange gehen und ein Lastwagen mit Zement oder
Trockenware sollte als Beispiel auf den Krankenwagen warten.
Sie wollen keinen langsam fahrenden LKW oder LKW vor einem Krankenwagen.
Sie möchten, dass ein Krankenwagen an die Vorderseite der Warteschlange fährt, genauso wie Sie Sprachpakete senden möchten, um an die
Vorderseite der Warteschlange gelangen zu können.
FIFO ist also nicht gut für Sprache und Video. Ein anderer älterer Warteschlangenmechanismus ist ein hübscher Schlüssel.
Dies besteht aus vollständigen Warteschlangen, die in einer strengen Prioritätsreihenfolge bedient werden, und diesem Warteschlangenalgorithmus, den wir
für Cues eines hohen Mediums hatten.
Normal und zurückhaltend Durch Erzwingen einer strengen Eigenschaft werden die Warteschlangen mit niedrigerer Priorität nur dann bedient, wenn
die höheren Protein-Cues leer sind, also wenn Datenverkehr eintrifft.
Wenn es als wichtig eingestuft wird, kann es in die Schlüsselklassifizierung mit hoher Priorität aufgenommen werden.
Dies kann anhand des Protokolls, der Quellschnittstelle oder anderer Kriterien erfolgen.
Der Datenverkehr in der Warteschlange mit hoher Priorität wird immer erst dann bedient, wenn die Warteschlangen mit hoher und mittlerer Priorität
leer sind und die normale Warteschlange verarbeitet wird.
Die Warteschlange mit niedriger Priorität wird nur verarbeitet, wenn die Warteschlangen mit hoher mittlerer und normaler Priorität leer sind.
Das ist also das Problem.
Die Warteschlange mit niedriger Priorität könnte verhungern, wenn in den Warteschlangen mit hoher mittlerer oder normaler Warteschlange konstanter Datenverkehr herrscht,
sodass Warteschlangen mit niedriger Priorität durch Warteschlangen mit höherer Priorität ausgehungert werden könnten.
Es war ein älterer Mechanismus, der in der Vergangenheit in Ordnung war, aber für moderne Netzwerke nicht gut geeignet ist.
Ein Gewinn in einer Party-Warteschlange Wir haben volle Warteschlangen. Hohe mittlere normale und niedrige Warteschlangen mit hoher Priorität werden
immer vor Warteschlangen mit niedriger Priorität bedient.
Das Problem hierbei ist, dass Warteschlangen mit niedrigerer Priorität ausgehungert werden können.
Ein dritter Warteschlangenalgorithmus ist die benutzerdefinierte Warteschlange.
Diese besteht aus bis zu 16 Warteschlangen, die im Round-Robin-Verfahren gewartet werden, um Hunger zu vermeiden.
Es bietet Verkehrsgarantien.
Das Problem bei dieser Methode ist jedoch, dass sie keine strikte Priorität für den Echtzeitverkehr bietet.
Als Beispiel haben wir eingehende Pakete, die in verschiedene Warteschlangen eingeteilt sind, von
denen bis zu 16 unterschiedliche Größen haben können.
So können Sie einigen Warteschlangen im Vergleich zu anderen Warteschlangen mehr Bandbreite zur Verfügung stellen.
Das Problem bei der benutzerdefinierten Warteschlange besteht jedoch darin, dass wenn wichtiger Sprachverkehr ankommt, dieser nur
in seiner Runde oder an seiner Reihe bedient wird, sodass ab und zu ein Beispiel für Sprache verarbeitet wird und
die zweite Warteschlange und ein neues Sprachpaket an der Reihe sind kommt an.
Dieses neue Sprachpaket wird erst verarbeitet, wenn Q3 Q4-Warteschlange 5 und bis zur
Warteschlange 16 bedient werden. Anschließend wird ein Round-Robin-Warteschlangenplaner an Benutzer mit Warteschlangen für Sprachkunden zurückgegeben.
Sobald die Sprachverarbeitung verarbeitet ist, ist der zweite Schlüssel an der Reihe. Der Scheduler kehrt erst
dann zur ersten Warteschlange oder zur Sprachwarteschlange zurück, wenn alle anderen Warteschlangen verarbeitet wurden.
Das Problem bei dieser Methode ist also, dass sie eine Verzögerung einführt.
Es gibt keine Priorität für Sprache, daher wird der Sprachverkehr häufig verzögert, was zu Verzögerungen und Jetta führt
und die Sprachqualität beeinträchtigt.
Daher sind weder Warteschlangen für FIFO-Parteien noch benutzerdefinierte Warteschlangen für ein modernes Netzwerk ideal. Ein vierter Algorithmus wird für
die Warteschlange gewichtet.
Dies ist ein Algorithmus, der die Internetbandbreite durch die Anzahl der Flüsse dividiert und so versucht,
eine ordnungsgemäße Verteilung der Bandbreite für alle Anwendungen sicherzustellen.
Es bietet im Allgemeinen einen guten Service für Echtzeitverkehr, stellt jedoch keine Bandbreitengarantie für bestimmte Flows dar
und einige Flows können andere Flows tatsächlich stoppen.