Wi-Fi'da Canlı Yayın veya Multicast Donuyor: Airtime ve Ağ Yolunu İnceleme

Neden normal web çalışırken yayın donar?

Web sayfası tek istemciye yönelen unicast trafiği kullanır; kablosuz canlı yayın çoğu ortamda multicast veya broadcast ile dağıtılır. Multicast çerçevelerinin kablosuz taraftaki gönderim biçimi, unicast akışındaki ACK ve yeniden iletim davranışından farklıdır. Bir kayıp görüntü karesini uygulama düzeltmezse kullanıcı pikselleşme veya donma görürken web sayfası normal açılabilir. Bu nedenle ilk sorular ‘SSID var mı’ değil ‘yayın adresi, alıcı grubu, kablolu VLAN ve AP üzerinden geçen gerçek trafik nedir’ olmalıdır. Önce aynı yayını Ethernet'teki bir alıcıda deneyerek kaynağın sağlıklı olduğunu kanıtlayın.

Multicast bir AP'nin tüm istemcilerine gereksiz yere yayılıyorsa airtime hızla dolar. Buna karşılık IGMP snooping yanlış yapılandırılmışsa yayın hiç gereken porta ulaşmayabilir. Sorun her AP'de görülüyorsa kaynak veya switch katmanı; yalnız belirli AP'de görülüyorsa VLAN, radyo profili ya da o AP'nin istemci grubu incelenir. Kullanıcı cihazlarının yayına gerçekten üye olup olmadığını IGMP üyelik kayıtlarıyla doğrulayın. ‘Multicast ayarını açtık’ demek yeterli değildir: AP'nin kablolu portundan giren paket sayısıyla havadan çıkan paket sayısını karşılaştırın.

Kablosuz multicast'in airtime maliyeti

Bazı WLAN'larda multicast/broadcast, çok sayıda istemcinin alabilmesi için düşük temel hızda iletilir. Aynı video verisi 6 Mbps'de taşındığında 54 Mbps'deki iletime kıyasla havayı çok daha uzun süre işgal eder; gerçek süre başlıklar, çekişme ve koruma aralıkları nedeniyle bu basit oranla tam hesaplanmaz. Yine de düşük temel hızların yüksek yayın hacmiyle birleşmesi diğer istemcileri etkiler. Kanal kullanım oranını, multicast paket sayısını ve yayın için seçilen temel hızı birlikte inceleyin. Temel hızı yükseltmek yayın süresini azaltabilir ama hücre kenarındaki alıcıları dışarıda bırakabilir; önce gerçek kapsama ölçümü gerekir.

Multicast-to-unicast dönüşümü, AP'nin her alıcıya ayrı doğrulamalı çerçeve göndermesini sağlar. Az sayıda alıcıda güvenilirliği artırabilir; çok sayıda alıcıda aynı içeriği tekrar tekrar göndererek havayı daha çok tüketebilir. Tek çözüm diye her SSID'ye açmayın. Alıcı sayısını, akış bit hızını, AP kapasitesini ve üreticinin dönüşüm algoritmasını pilotta ölçün. Canlı yayın için yönetilebilir bir uygulama protokolü seçimi de önemlidir; uyarlamalı unicast akışlar bazı ortamlarda kablosuz multicast'ten daha öngörülebilir olabilir. Nihai karar iş yüküne ve alıcı sayısına göre verilir.

IGMP, VLAN ve izolasyon tuzakları

Switch üzerindeki IGMP snooping üyelik bilgisini izler; querier yoksa veya yanlış VLAN'daysa üyelikler zamanla silinebilir. İlk açılışta çalışan yayının birkaç dakika sonra kesilmesi bu paterne uyar. Ancak her zaman aynı nedenden kaynaklanmaz: kablolu yakalama ile IGMP query, report ve yayın paketlerinin zamanını karşılaştırın. Yayın kaynağı ile istemci farklı VLAN'daysa multicast routing veya uygun proxy gerekir; yalnız SSID'ye VLAN etiketlemek iki ağı kendiliğinden birleştirmez. Güvenlik politikası da gruba katılımı veya dağıtımı engelleyebilir.

Misafir ağındaki client isolation, Chromecast benzeri keşif veya yerel yayın senaryolarını kasıtlı olarak engelleyebilir. İzolasyonu tüm ağda kapatmak yerine hangi akışın gerekli olduğunu ve yalnız ilgili cihaz grubuna nasıl izin verileceğini tanımlayın. mDNS keşfi ile gerçek video taşınması farklı protokollerdir; cihazı keşfedememek ile akışın donmasını ayrı teşhis edin. Yayın uygulamasının hangi multicast adresini ve portunu kullandığını belgelemeden geniş güvenlik duvarı kuralı açmayın. Uygun erişim kuralını uyguladıktan sonra hem yetkili hem yetkisiz VLAN'dan testi tekrarlayın.

Doğrulamayı yayın süresi boyunca yapın

Bir dakikalık demo, uzun süreli IGMP üyelik kaybını veya akşam yoğunluğunu yakalamaz. Gerçek akış bit hızı ve gerçek istemci sayısıyla yayın boyunca kayıp, oynatma tamponu ve AP kanal kullanımını izleyin. Kaynak ile alıcı saatlerini eşitleyerek donma anını paket kaybıyla ilişkilendirin. Aynı yayını AP'ye yakın ve hücre kenarında karşılaştırın. Yakında iyi, uzakta kötü ise RF kapsaması; her yerde aynı anda kötü ise kablolu yol veya kaynağın kendisi daha olasıdır. Değişiklik öncesi ve sonrası aynı yayın içeriğini, aynı alıcı grubunda test edin.

F2 yaklaşımında kablosuz multicast tasarımı uygulama gereksiniminden başlar. Yayın tek kişiye mi, on kişiye mi, yüzlerce ekrana mı gidecek; gecikme ve kayıp toleransı nedir? Bu sorular yanıtlanmadan temel hızı yükseltmek veya multicast-to-unicast açmak rastgele müdahaledir. Ölçüm sonunda kaynak, switch, AP, radyo ve istemci katmanlarından hangisinin sınır olduğunu raporlayın. Böylece toplantı ekranı, otel IPTV'si veya hastane anonsu gibi farklı iş yükleri için ayrı güvenilirlik ve güvenlik kararları verilebilir.

• Aynı akışı önce kablolu bir alıcıda deneyin, sonra AP'nin kablolu girişini ve havadaki çıkışını ölçün.
• IGMP querier, üyelikler ve VLAN yolunu yayın süresi boyunca kontrol edin.
• Temel hız ve multicast-to-unicast ayarını alıcı sayısıyla birlikte değerlendirin.
• mDNS keşfi ile gerçek video akışını ve client isolation etkisini ayrı test edin.
• Değişikliği yoğun saatte, gerçek yayın bit hızıyla uzun süre doğrulayın.

Kayıp nerede başlıyor?

Aynı yayın akışının üç noktada kaydını karşılaştırın: kaynak çıkışı, AP'nin kablolu girişi ve kablosuz alıcı. Kaynaktan zaten bozuk gelen içerik için Wi-Fi değişikliği yapmayın. Kaynak düzgün, AP girişi düzensizse switch veya yönlendirme yoluna odaklanın. AP girişinde paketler düzenli ama havada seyrekse radyo politikası, multicast kuyrukları ve kanal kullanımını ölçün. Havadaki çerçeveler yerli yerinde olmasına rağmen uygulama donuyorsa istemci çözücü, güç tasarrufu veya uygulama tamponu da araştırılmalıdır. Tüm yakalamalarda ortak zaman kaynağı ve akış adresi kullanmak, aynı paketi izlemeyi kolaylaştırır. Kaybolan bir RTP sıra numarası veya uygulamanın akış belirteci olayları daha somut kılar. Multicast altyapısında IGMP sürümü, kaynak filtreleme ve switch'in üyelik zamanlayıcısı da etkili olabilir; ‘IGMP açık’ ifadesi hangi querier'ın hangi VLAN'da çalıştığını anlatmaz. Switch yeniden başladığında grubun yeniden oluşma süresi ve yayın davranışını ayrıca test edin. Özellikle tek bir katta görülen kesintide tüm kampüs için genel ayar değiştirmek yerine o katın uplink ve AP profilini başka katla kıyaslayın. AP üzerinde multicast-to-unicast dönüşümü açıksa alıcı sayısı artarken unicast tekrarlarının toplam radyo yükünü nasıl değiştirdiğini grafiğe dökün. Çok sayıda ekran için farklı dağıtım mimarisi gerekebilir; bir konferans odası ile yüzlerce odalı otel aynı varsayılanla yönetilmemelidir. IPTV alıcısının kablosuz sürücüsü de grup paketlerini güç tasarrufu aralığında geç alabilir. Aynı alıcıyı sabit güçte ve tasarruf modunda karşılaştırın. Son test, yalnız yayının başlamasını değil kaynak değişimi, kanal değişimi ve yoğun izleme saatinde kesintisiz oynatmayı içermelidir. Doğrulama raporuna kayıp oranı, donma sayısı, alıcı sayısı ve yayın bit hızını birlikte yazın. Her alıcı aynı donma anını bildiriyorsa ortak dağıtım yolunu, yalnız biri bildiriyorsa o istemcinin radyo ve uygulama durumunu inceleyin. Sürekli yayın ile aralıklı yayın aynı IGMP davranışını göstermeyebilir; her ikisini de gerçek kullanım sırasında test edin.