Planifiez votre réseau dans les équipes Microsoft (2019) – Partie 2

Bienvenue à nouveau! La dernière fois, nous avons discuté (à un niveau élevé) de ce que vous devrez prendre en compte pour implémenter des équipes dans votre environnement. Cette fois, nous allons nous plonger dans chacun de ces domaines afin que vous puissiez bien comprendre ce qui est nécessaire pour garantir la réussite de la mise en œuvre. En particulier, nous commencerons par apprendre ce que les équipes de Microsoft utilisent pour communiquer et comment cela se connecte à votre réseau.

Communications en temps réel?

Pour ceux d’entre vous qui n’ont jamais traité de produits tels que Lync, Skype for Business, Teams ou d’autres charges de travail multimédia en temps réel autres que Microsoft, vous n’êtes peut-être pas très au courant de ce concept. En gros, les communications en temps réel sont divisées en 3 choses différentes:

• Audio
• Vidéo
• Partage de bureau

Si vous avez eu une réunion, un appel ou un partage d'écran avec quelqu'un, vous savez quoi? Vous venez d'utiliser des communications en temps réel! Maintenant que vous savez ce que la communication en temps réel implique, parlons de ce qui est caché et de son fonctionnement. Comme vous le constaterez, tout le trafic de communication en temps réel est très sensible aux retards. Par exemple, si vous êtes en ligne et que vous parlez, mais que le son n’est reçu par l’autre extrémité que 5 secondes plus tard, cela entraînera une mauvaise expérience pour vous et le destinataire. Avez-vous déjà entendu le dicton «Mieux vaut tard que jamais»? Si tel est le cas, c’est exactement le contraire de ce que nous voulons pour les communications en temps réel. Au lieu de cela, nous préférons que ce soit «mieux vaut jamais que tard». Dans les communications en temps réel, si nous perdons certains paquets en cours de route, nous ne nous en soucions pas vraiment. L’autre extrémité peut entendre de légers problèmes audio, mais la session se poursuivra. Si nous devions inspecter chaque paquet traversant le réseau, recevoir un accusé de réception indiquant qu'il avait été remis avec succès, et soumettre à nouveau tous les paquets manquants, cela introduirait beaucoup de temps de latence, ce qui entraînerait de grandes lacunes dans l'audio perdu ayant un impact important sur l'appel. Cela dit, j’entends parler des protocoles de trafic Internet utilisés dans les équipes.

TCP vs UDP

Les équipes ont la possibilité d’utiliser le protocole Internet TCP ou UDP. Cependant, il sera très vite évident de choisir le protocole qui convient le mieux lorsqu’on utilise tout type de communication en temps réel.

TCP

TCP est un excellent protocole car il garantit que chaque paquet est envoyé et accusé réception de la receveur. Pour tous les paquets qui ne sont pas envoyés correctement, TCP renverra les paquets manquants. Ceci est une excellente option si vous envoyez n'importe quel type de fichier, mais pas si bon quand il s'agit d'envoyer n'importe quel type de communication en temps réel. Comme nous l'avons mentionné précédemment, si vous devez recevoir un accusé de réception après l'envoi de chaque paquet et renvoyer tous les paquets perdus, tous les paquets suivants seront retardés, ce qui créera une latence.

UDP

L’autre main fonctionne comme un protocole «envoyez-le et oubliez-le». UDP n'exige pas cette étape supplémentaire de recevoir un accusé de réception ni de renvoyer les paquets manquants. C’est l’option privilégiée pour tout le trafic de communication en temps réel, car nous nous soucions davantage de la vitesse à laquelle les paquets arrivent et moins de savoir s’ils sont arrivés et que le destinataire en accuse réception ou non. Si vous remarquez que le trafic utilise UDP mais que de nombreux paquets sont perdus et que le partage audio / vidéo / poste de travail est sérieusement affecté, cela signifie que vous êtes sur un réseau qui ne peut pas prendre en charge les communications en temps réel.

, Les équipes utilisent UDP pour tous les scénarios de communication / média en temps réel. S'il existe un point d'extrémité dans le pare-feu bloquant UDP, il se repliera sur TCP mais, comme indiqué précédemment, l'expérience utilisateur sera médiocre en raison du retard que cela entraînerait. Il existe toutefois une exception à cela: les participants aux événements Teams Live. Dans ce scénario, nous organisons un événement en direct avec le présentateur et le producteur en tirant parti d’une réunion d’équipes. Tous les participants utiliseront leur partage audio, vidéo et de bureau avec TCP plutôt qu’UDP. En effet, ils utiliseront toutes ces modalités comme un flux à sens unique car les participants ne font que regarder et ne sont pas en mesure de donner un retour d’audio, de vidéo ou de partage de postes de travail. Le second flux n’est donc pas nécessaire. De même, comme ils écoutent ce flux, ils le reçoivent peut-être avec un peu de retard, mais cela n’a aucune incidence sur leur expérience, car ils n’ont pas besoin de s’inquiéter de la réponse. Les producteurs et les présentateurs de cette réunion utiliseront toujours UDP, car ce sont eux qui envoient le trafic de communications en temps réel.

Ceci conclut le premier élément de la plongée dans la planification de votre réseau pour Microsoft Teams. Dans le prochain article, nous allons décomposer une session multimédia et expliquer comment le média est transféré d’un bout à l’autre. En outre, nous examinerons certaines des altérations du réseau et leur impact potentiel sur votre réseau. J'espère que vous avez trouvé cet article utile et revenez bientôt pour le prochain blog!