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
- L’IA amplifie les risques sur les API
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Nomios accélère sur la cybersécurité industrielle avec un SOC renforcé et une Factory OT immersive
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
