1 00:00:00,630 --> 00:00:04,860 Schauen wir uns einige der Warteschlangenmechanismen für das Überlastungsmanagement an. 2 00:00:04,860 --> 00:00:06,960 Es gibt viele Warteschlangenmechanismen. 3 00:00:07,110 --> 00:00:12,990 Einige davon sind älter und / oder für moderne Rich Media-Netzwerke ineffizient. 4 00:00:12,990 --> 00:00:19,290 Mit anderen Worten, sie waren in der Vergangenheit gut, eignen sich jedoch nicht für Voice over IP und Video, die 5 00:00:19,290 --> 00:00:21,200 über ein Datennetzwerk ausgeführt werden. 6 00:00:21,210 --> 00:00:25,410 Beginnen wir also mit einer FIFO First In First Out-Warteschlange. 7 00:00:25,410 --> 00:00:32,100 Dies besteht aus einer einzelnen Warteschlange mit Paketen, die in der genauen Reihenfolge gesendet werden, in der sie angekommen sind. 8 00:00:32,100 --> 00:00:36,780 Wir haben diesen Warteschlangenmechanismus wahrscheinlich alle in der realen Welt erlebt. 9 00:00:36,840 --> 00:00:41,260 In diesem Beispiel haben wir Leute, die für ihre Einkäufe bezahlen möchten. 10 00:00:41,280 --> 00:00:44,460 Es gibt nur einen Kassierer, an dem sie bezahlen können. 11 00:00:44,460 --> 00:00:48,120 Die Leute werden in der Reihenfolge "Wer zuerst kommt, mahlt zuerst" bedient. 12 00:00:48,150 --> 00:00:49,870 Mit anderen Worten First In First Out. 13 00:00:50,010 --> 00:00:51,450 Diese Dame kam zuerst an. 14 00:00:51,480 --> 00:00:53,490 Also diente sie zuerst. 15 00:00:53,580 --> 00:00:58,690 Dieser Herr kam als Zweiter an, also diente er eine Sekunde und so weiter und so fort. 16 00:00:58,710 --> 00:01:00,080 Dies ist die Vorderseite der Warteschlange. 17 00:01:00,090 --> 00:01:03,810 Dies ist die Rückseite der Warteschlange, und die Personen werden in dieser Reihenfolge bedient. 18 00:01:05,200 --> 00:01:13,180 Auf die gleiche Weise werden in einem FIFO-Warteschlangenalgorithmus auf einem Rota-Paket Pakete in der Reihenfolge zugestellt, in der sie angekommen sind. 19 00:01:13,180 --> 00:01:14,320 Dies ist die Vorderseite der Warteschlange. 20 00:01:14,320 --> 00:01:20,440 Dies ist die Rückseite der Warteschlange. Neue Pakete befinden sich in der Warteschlange an den hinteren Paketen an der Vorderseite der Warteschlange 21 00:01:20,880 --> 00:01:24,000 oder D in der Warteschlange und werden zur Übertragung weitergeleitet. 22 00:01:24,010 --> 00:01:30,820 Das Problem bei diesem Warteschlangenmechanismus ist, dass Sprachpakete durch größere Datenpakete verzögert werden können. 23 00:01:30,820 --> 00:01:36,910 Jeder wird auf die gleiche Weise bedient, was in einigen Fällen in der realen Welt gut funktionieren kann, 24 00:01:36,910 --> 00:01:41,530 aber das wäre kein Beispiel, wenn es einen Notfall und einen Krankenwagen gäbe. 25 00:01:41,530 --> 00:01:47,620 Als Beispiel musste man an die Spitze der Warteschlange gehen und ein Lastwagen mit Zement oder 26 00:01:47,620 --> 00:01:51,160 Trockenware sollte als Beispiel auf den Krankenwagen warten. 27 00:01:51,160 --> 00:01:56,560 Sie wollen keinen langsam fahrenden LKW oder LKW vor einem Krankenwagen. 28 00:01:56,560 --> 00:02:01,690 Sie möchten, dass ein Krankenwagen an die Vorderseite der Warteschlange fährt, genauso wie Sie Sprachpakete senden möchten, um an die 29 00:02:01,690 --> 00:02:03,430 Vorderseite der Warteschlange gelangen zu können. 30 00:02:03,580 --> 00:02:10,810 FIFO ist also nicht gut für Sprache und Video. Ein anderer älterer Warteschlangenmechanismus ist ein hübscher Schlüssel. 31 00:02:10,830 --> 00:02:17,330 Dies besteht aus vollständigen Warteschlangen, die in einer strengen Prioritätsreihenfolge bedient werden, und diesem Warteschlangenalgorithmus, den wir 32 00:02:17,330 --> 00:02:20,000 für Cues eines hohen Mediums hatten. 33 00:02:20,030 --> 00:02:27,680 Normal und zurückhaltend Durch Erzwingen einer strengen Eigenschaft werden die Warteschlangen mit niedrigerer Priorität nur dann bedient, wenn 34 00:02:27,680 --> 00:02:31,740 die höheren Protein-Cues leer sind, also wenn Datenverkehr eintrifft. 35 00:02:31,770 --> 00:02:38,250 Wenn es als wichtig eingestuft wird, kann es in die Schlüsselklassifizierung mit hoher Priorität aufgenommen werden. 36 00:02:38,250 --> 00:02:42,830 Dies kann anhand des Protokolls, der Quellschnittstelle oder anderer Kriterien erfolgen. 37 00:02:42,960 --> 00:02:49,020 Der Datenverkehr in der Warteschlange mit hoher Priorität wird immer erst dann bedient, wenn die Warteschlangen mit hoher und mittlerer Priorität 38 00:02:49,020 --> 00:02:51,740 leer sind und die normale Warteschlange verarbeitet wird. 39 00:02:52,230 --> 00:02:59,010 Die Warteschlange mit niedriger Priorität wird nur verarbeitet, wenn die Warteschlangen mit hoher mittlerer und normaler Priorität leer sind. 40 00:02:59,250 --> 00:03:00,720 Das ist also das Problem. 41 00:03:00,720 --> 00:03:07,980 Die Warteschlange mit niedriger Priorität könnte verhungern, wenn in den Warteschlangen mit hoher mittlerer oder normaler Warteschlange konstanter Datenverkehr herrscht, 42 00:03:08,790 --> 00:03:13,550 sodass Warteschlangen mit niedriger Priorität durch Warteschlangen mit höherer Priorität ausgehungert werden könnten. 43 00:03:13,560 --> 00:03:19,450 Es war ein älterer Mechanismus, der in der Vergangenheit in Ordnung war, aber für moderne Netzwerke nicht gut geeignet ist. 44 00:03:19,530 --> 00:03:26,550 Ein Gewinn in einer Party-Warteschlange Wir haben volle Warteschlangen. Hohe mittlere normale und niedrige Warteschlangen mit hoher Priorität werden 45 00:03:26,550 --> 00:03:29,610 immer vor Warteschlangen mit niedriger Priorität bedient. 46 00:03:29,610 --> 00:03:34,890 Das Problem hierbei ist, dass Warteschlangen mit niedrigerer Priorität ausgehungert werden können. 47 00:03:35,190 --> 00:03:38,090 Ein dritter Warteschlangenalgorithmus ist die benutzerdefinierte Warteschlange. 48 00:03:38,100 --> 00:03:44,490 Diese besteht aus bis zu 16 Warteschlangen, die im Round-Robin-Verfahren gewartet werden, um Hunger zu vermeiden. 49 00:03:44,520 --> 00:03:46,920 Es bietet Verkehrsgarantien. 50 00:03:46,980 --> 00:03:54,020 Das Problem bei dieser Methode ist jedoch, dass sie keine strikte Priorität für den Echtzeitverkehr bietet. 51 00:03:54,020 --> 00:03:59,790 Als Beispiel haben wir eingehende Pakete, die in verschiedene Warteschlangen eingeteilt sind, von 52 00:03:59,790 --> 00:04:03,380 denen bis zu 16 unterschiedliche Größen haben können. 53 00:04:03,420 --> 00:04:08,820 So können Sie einigen Warteschlangen im Vergleich zu anderen Warteschlangen mehr Bandbreite zur Verfügung stellen. 54 00:04:08,820 --> 00:04:14,700 Das Problem bei der benutzerdefinierten Warteschlange besteht jedoch darin, dass wenn wichtiger Sprachverkehr ankommt, dieser nur 55 00:04:14,760 --> 00:04:21,810 in seiner Runde oder an seiner Reihe bedient wird, sodass ab und zu ein Beispiel für Sprache verarbeitet wird und 56 00:04:21,810 --> 00:04:26,760 die zweite Warteschlange und ein neues Sprachpaket an der Reihe sind kommt an. 57 00:04:26,760 --> 00:04:34,090 Dieses neue Sprachpaket wird erst verarbeitet, wenn Q3 Q4-Warteschlange 5 und bis zur 58 00:04:34,090 --> 00:04:41,840 Warteschlange 16 bedient werden. Anschließend wird ein Round-Robin-Warteschlangenplaner an Benutzer mit Warteschlangen für Sprachkunden zurückgegeben. 59 00:04:42,620 --> 00:04:48,950 Sobald die Sprachverarbeitung verarbeitet ist, ist der zweite Schlüssel an der Reihe. Der Scheduler kehrt erst 60 00:04:48,950 --> 00:04:54,490 dann zur ersten Warteschlange oder zur Sprachwarteschlange zurück, wenn alle anderen Warteschlangen verarbeitet wurden. 61 00:04:54,620 --> 00:04:57,700 Das Problem bei dieser Methode ist also, dass sie eine Verzögerung einführt. 62 00:04:57,870 --> 00:05:05,180 Es gibt keine Priorität für Sprache, daher wird der Sprachverkehr häufig verzögert, was zu Verzögerungen und Jetta führt 63 00:05:05,180 --> 00:05:07,130 und die Sprachqualität beeinträchtigt. 64 00:05:07,130 --> 00:05:16,190 Daher sind weder Warteschlangen für FIFO-Parteien noch benutzerdefinierte Warteschlangen für ein modernes Netzwerk ideal. Ein vierter Algorithmus wird für 65 00:05:16,190 --> 00:05:17,680 die Warteschlange gewichtet. 66 00:05:17,690 --> 00:05:25,040 Dies ist ein Algorithmus, der die Internetbandbreite durch die Anzahl der Flüsse dividiert und so versucht, 67 00:05:25,040 --> 00:05:29,280 eine ordnungsgemäße Verteilung der Bandbreite für alle Anwendungen sicherzustellen. 68 00:05:29,420 --> 00:05:36,830 Es bietet im Allgemeinen einen guten Service für Echtzeitverkehr, stellt jedoch keine Bandbreitengarantie für bestimmte Flows dar 69 00:05:37,010 --> 00:05:40,970 und einige Flows können andere Flows tatsächlich stoppen.