Partager via


Résolution des problèmes de faible efficacité de peering

Dans cet article, nous listons les causes courantes de la faible efficacité du peering et la façon de les traiter.

Petit événement en direct

Généralement, plus l’événement est populaire, plus les performances de déchargement sont fortes. Gardez à l’esprit qu’au moins une visionneuse dans un groupe de peering doit télécharger les données à partir de la source d’origine. Ainsi, s’il n’y a que deux téléspectateurs dans un groupe, l’efficacité/déchargement maximale du peering est de 50 %, 3 téléspectateurs => 67 %, 4 => 75 %, et ainsi de suite.

À l’exception des cas de périphérie, le SDK Microsoft eCDN crée jusqu’à 30 connexions de peering. Seuls les téléspectateurs qui regardent le même contenu de résolution s’associent les uns aux autres. En augmentant le nombre de téléspectateurs dans un groupe, les pools d’homologues disponibles sont étendus, ce qui améliore efficacement le potentiel d’efficacité du peering.

Accès client non optimal

Pour l’événement en direct Teams et l’expérience d’assemblée générale les plus optimisés, tous les téléspectateurs doivent participer via l’application de bureau Teams. Avec le client Teams, Microsoft eCDN obtient automatiquement les adresses IP locales des utilisateurs finaux et les associe efficacement les uns aux autres.

Si les utilisateurs rejoignent via le navigateur, assurez-vous qu’ils accordent un accès microphone ou caméra au site web Teams, ou que le masquage IP mDNS est désactivé. Ainsi, l’adresse IP locale requise pour le peering est exposée. Pour plus d’informations, consultez la documentation sur la désactivation du masquage d’adresses IP mDNS .

Absence de mappage de sous-réseau

Avec Microsoft eCDN, les administrateurs peuvent incorporer leur propre mappage de sous-réseau afin de créer des groupes/restrictions de peering basés sur l’adresse IP locale. Les avantages sont :

  • Seules les visionneuses qui se trouvent sur le même homologue réseau les unes avec les autres

  • Le peering intersites peut être évité

  • L’analytique enrichie montre le peering et les performances basés sur le site

  • Les sous-réseaux VPN (et les autres sous-réseaux pour lesquels les administrateurs souhaitent désactiver le peering) peuvent être explicitement exclus

Les sous-réseaux peuvent être chargés directement sur la page Mappage des sous-réseaux du portail Microsoft eCDN. Le format de mappage de sous-réseau requis est un fichier CSV avec la structure suivante.

Table CSV avec trois colonnes intitulées « nom du site », « network / C. I. D. R.s » et « config » remplies avec des exemples de données.

Reportez-vous à la documentation sur le mappage de sous-réseau pour obtenir des conseils et d’autres options sur la façon de préparer votre fichier CSV pour le chargement.

Sans mappage de sous-réseau, tous les clients (qui exposent correctement leur adresse IP locale au Kit de développement logiciel (SDK) eCDN) sont libres d’appairer les uns avec les autres. Ce scénario est idéal pour optimiser le nombre d’homologues potentiels, mais il peut permettre la formation de connexions de peering indésirables, par exemple via des canaux VPN ou sur des sites distants, ce qui entraîne une dégradation des performances.

Regroupement de sous-réseaux hyper subdivisé

Similaire dans la nature au cas de petit événement en direct mentionné ci-dessus. Si les sous-réseaux sont subdivisé de manière excessive, le potentiel de déchargement correspondant est réduit proportionnellement.

Latence élevée entre deux clients

Effectuez un test de latence. Pour une expérience optimale, la latence entre deux clients doit être inférieure à 30 ms. Pour protéger l’expérience utilisateur, les clients n’utilisent pas de connexions de peering médiocres avec une latence élevée. Une des causes potentielles d’une latence élevée peut être due au trop grand nombre de personnes connectées à un seul appareil réseau, comme un point d’accès ou un commutateur.

Utilisation d’un VPN (applicable uniquement aux tests)

Ce scénario s’applique uniquement à la personne qui administre un test à domicile et qui utilise d’autres appareils personnels. Vérifiez que le VPN est désactivé sur les appareils de test.

Si vous êtes au bureau, il n’est pas recommandé d’accéder au contenu vidéo via un VPN.

Identification d’adresse IP locale incorrecte

Appuyez sur Alt+Maj+P dans une fenêtre vidéo prise en charge par Microsoft eCDN pour ouvrir la superposition des statistiques. Une adresse IP différente de l’adresse IP locale attendue peut être observée. Dans ce scénario, la visionneuse est affectée au groupe de sous-réseaux incorrect, potentiellement au groupe Ungrouped (aucun peering). Pour obtenir une solution, consultez votre responsable de compte de réussite client (CSAM) Microsoft.