Ich habe ein Programm, das alle 50 ms ein IPv6-Multicast-Paket (an ff12::2:0:8afb:382b:c053:85f%en1) sendet. Ich habe es in einem sehr einfachen Einzelcomputer-LAN laufen (Mac Mini <-WLAN-> Linksys-WLAN-Router <-Cat5-> DSL-Modem <-> Internet). In meinem Test sind keine Computer dieser Multicast-Gruppe beigetreten (d. h. niemand hört diese Pakete ab).
Mein Problem ist, dass die WLAN-Leistung des Macs um über 50 % sinkt, wenn dieses Programm ausgeführt wird. Das Problem besteht vermutlich darin, dass all diese Multicast-Pakete einen Großteil meiner WLAN-Bandbreite beanspruchen und zu einer Überlastung führen ... aber ich verstehe nicht, warum die Pakete überhaupt übertragen werden. Ich habe es so verstanden, dass Multicast einen Spanning-Tree-Algorithmus verwendet, um sicherzustellen, dass Multicast-Pakete nur an Hosts weitergeleitet werden, die tatsächlich daran interessiert sind, sie zu empfangen. Wenn das stimmt und vorausgesetzt, dass in meinem LAN keine anderen Computer mit dieser Multicast-Adresse verbunden sind, sollte mein Mac das dann nicht erkennen und tatsächlich keine Pakete senden, es sei denn/bis ein anderer Host der Multicast-Gruppe beitritt? Oder wird das Spanning-Tree-Culling nur am Switch und nicht von den Hosts selbst implementiert?
Antwort1
Multicast ist eine heikle Sache.Routersind diejenigen, die Multicast-Pakete vermitteln, und intelligente Switches können manchmal sicherstellen, dass die Pakete nicht dort ankommen, wo sie nicht hin sollen. Wenn sich jedoch kein Router zwischen dem Multicaster und Ihren Client-Stationen befindet (und wenn ich das richtig lese, ist das nicht der Fall), verhält sich Multicast in diesem Subnetz genau wie Broadcasts.
Antwort2
Um die Antwort von @sysadmin1138 zu ergänzen (dieser Kommentar war zu lang für das Kommentarfeld) …
Es sollte beachtet werden, dass 802.11 das Problem in diesem Fall in zweierlei Hinsicht verschärft: durch Intra-BSS-Relay und niedrige Multicast-Raten.
Bei 802.11 müssen Wireless-to-Wireless-Frames auf demselben AP vom AP drahtlos erneut übertragen werden, falls sich der ursprüngliche Absender nicht in Funkreichweite des beabsichtigten Empfängers befindet. Dieser Vorgang wird als „Intra-BSS-Relay“ bezeichnet und löst das sogenannte „Hidden Node-Problem“ – bei dem sich zwei Wireless-Knoten zwar in Reichweite des APs, aber nicht in Reichweite (voreinander verborgen) befinden können. Daher wird jeder Frame, der von einem Wireless-Client des APs kommt und möglicherweise an einen anderen Wireless-Client des APs gesendet werden muss (Hinweis: Dies umfasst alle Multicasts und Broadcasts), zweimal über denselben Kanal übertragen. ErstensZuder AP (dies wird als To the Distribution System oder „ToDS“ bezeichnet) und dann wiederausder AP („FromDS“) als Teil der Intra-BSS-Weiterleitung.
Der „ToDS“-Teil der Reise erfolgt mit der höchsten Datenrate, bei der der Client erfolgreich mit dem AP kommunizieren kann. Wenn es sich also um einen modernen 3x3 N-Client und AP handelt, der 40-MHz-Kanäle mit kurzen Schutzintervallen verwendet, kann dies 450 Mbit/s sein.
Leider muss der Frame für den „FromDS“-Teil der Reise mit einer Datenrate gesendet werden, die niedrig genug ist, damit alle Clients dieses APs ihn zuverlässig empfangen können. Das liegt daran, dass Multicasts auf der 802.11-Ebene nicht bestätigt werden, da dies als Antwort auf jeden Multicast einen Bestätigungssturm auslösen würde.
Bei einigen APs können Sie die Multicast-Rate explizit festlegen. Bei anderen können Sie Ihre „Basisrate“ oder „erforderliche Rate“ festlegen, und dann wählt der AP die Multicast-Rate aus den Basisraten aus. Bei anderen wiederum können Sie nur Ihren b/g/n- (oder a/n-)Kompatibilitätsmodus festlegen und haben eine vordefinierte Basisrate und eine darauf basierende Multicast-Rate. Viele APs verwenden standardmäßig den vollständigen Kompatibilitätsmodus bis zurück zu den DSSS-Datenraten von 1 und 2 MBit/s nach 802.11-1997 (bevor 802.11b 5,5 und 11 MBit/s hinzufügte). Das bedeutet, dass Ihre Multicast-Rate bis auf 1 MBit/s sinken könnte.
Im schlimmsten Fall könnten Ihre Multicasts 451maldie Kanal-Sendezeit, die ein gleich großer Unicast-Frame von drahtlos zu kabelgebunden (oder von kabelgebunden zu drahtlos) beanspruchen würde.
Beachten Sie auch, dass in einigen Designs die Intra-BSS-Weiterleitung durch Mikrocode in der 802.11-Netzwerkkarte des APs durchgeführt wird. In diesen Architekturen durchlaufen diese Frames also nicht den Hostprozessor des APs, bevor sie weitergeleitet werden. Selbst wenn der AP also ein „intelligenter“ Switch wäre, der das Schichtmodell verletzen und Layer-3-IGMP-Snooping durchführen könnte, um den Multicast-Baum zu beschneiden, hätte er keine Chance dazu, bevor die Funkkarte bereits die Intra-BSS-Weiterleitung des Frames durchgeführt hat.
Antwort3
Multicast verwendet standardmäßig Broadcast-Verhalten, wenn es vom lokalen Router (nicht Switch) nicht vollständig unterstützt wird. Daher verbreitet es sich tendenziell an alle bekannten Knoten innerhalb eines LAN-Segments.
SoHo-Router sind nicht gerade dafür bekannt, MultiCast vollständig oder richtig zu unterstützen. Viele sind von Upstream-Routern abhängig und erwarten nur Clients auf LAN-Ebene. Sie können versuchen, Ihre Routereinstellungen anzupassen, aber wenn Ihre Multicast-Gruppe keine Abonnenten hat, warum schalten Sie es dann nicht an der Quelle aus?