Il est facile de comprendre comment des unités spécialisées, comme des téléphones VoIP, peuvent étiqueter le trafic afin que les commutateurs puissent l'identifier (en effet, ce sont des unités à une seule fonction et il n'y a aucune ambiguïté quant au type de trafic qu'elles traitent).
Le logiciel entre en scène
Mais que se passe-t-il dans un système d’exploitation polyvalent, comme Unix Windows, qui peut héberger des applications différentes (parfois multiples et simultanées) ? Comment un système d’exploitation (ou une application) peut-il informer les commutateurs et les routeurs des exigences de son trafic ?
Deux modèles architecturaux sont utilisés couramment pour communiquer les exigences de trafic : InetServ et DiffServ. (Ne me demandez pas pourquoi on dit « architectures » plutôt que « standards » ou « ensembles de protocoles »). Les deux architectures permettent aux applications et/ou aux systèmes d’exploitation de communiquer leurs besoins aux commutateurs et routeurs (et elles sont aussi utilisées pour la communication entre commutateurs et routeurs).
InetServ est l’architecture la plus compliquée. Ses mécanismes de contrôle appliquent une granularité très fine ; ils peuvent aussi réserver la bande passante pour le trafic. Cette possibilité est bien sûr très importante pour la voix et la vidéo, ou un flux inégal de paquets peut être dévastateur. Cette fine granularité a pour corollaire la complexité du réseau : les commutateurs et les routeurs doivent maintenir des tables et des tables de données pour suivre les divers flux de transmission.
Les mécanismes de contrôle de DiffServ sont, quant à eux, plus rustiques et moins granulaires. Avec DiffServ, le nombre de flux de trafic est limité et les transmissions doivent être incorporées dans ces flux. Pour mieux comprendre : si ces architectures QoS étaient des constructeurs automobiles, InetServ vous permettrait de concevoir votre propre voiture à partir de zéro, tandis que DiffServ vous proposerait simplement un choix entre une poignée de modèles et d’options.
L’important, ici, est que ces fonctions QoS sont là pour permettre aux applications et aux systèmes d’exploitation de participer au contrôle des paquets de données qui empruntent les cables cuivre et fibre optique. De ce qui précède, vous pourriez conclure que la vie est belle. Tous les éléments notables de mon data Center peuvent communiquer entre eux pour transmettre de manière fiable et prévisible les principaux profils de trafic. Pas de souci donc, allons de ce pas boire un café !
Mais ne vous éloignez pas trop. Nous parlerons dans la suite du dossier de quelques complications possibles.
Téléchargez cette ressource
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Comprendre le SOC : votre bouclier essentiel en cybersécurité
- IA : le changement de paradigme des entreprises françaises se joue désormais à l’échelle humaine
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
- Pourquoi les navigateurs web sont devenus la porte d’entrée des cybercriminels pour compromettre les endpoints ?
Articles les + lus
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
Analyse Patch Tuesday Mars 2026
Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
À la une de la chaîne Tech
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
- Analyse Patch Tuesday Mars 2026
- Confiance et curiosité : les clés pour entrer (et grandir) en tant que femme dans la tech
