Informations détaillées concernant l'implémentation de Microsoft Windows 2000 TCP/IP
Sur cette page
Syndrome SWS (Silly Window Syndrome)
Le syndrome SWS est décrit de la façon suivante dans la RFC 1122 :
"Brièvement, le syndrome SWS est causé par le récepteur qui devance le bord droit de la fenêtre chaque fois qu'il dispose d'un nouvel espace tampon pour recevoir des données et par l'expéditeur qui utilise une fenêtre incrémentielle quelconque, quelle que soit sa taille, pour envoyer une plus grande quantité de données [TCP:5]. Le résultat est que la transmission se stabilise sur l'envoi de segments minuscules, même si tant l'envoyeur que le receveur disposent d'un grand espace tampon pour la connexion."
Windows 2000 TCP/IP évite le syndrome SWS, comme cela est spécifié dans la RFC 1122, en n'envoyant pas plus de données tant que le récepteur n'a pas annoncé que la taille de la fenêtre est suffisante pour recevoir un segment TCP complet. De même, à l'extrémité de réception de la connexion, la fenêtre de réception n'est pas ouverte en incréments inférieurs à un segment TCP.
Algorithme de Nagle
Windows NT et Windows 2000 TCP/IP implémentent l'algorithme de Nagle décrit dans la RFC 896. L'objectif de cet algorithme est de réduire le nombre des segments de très petite taille, spécialement sur les liaisons (distantes) à retard élevé. L'algorithme de Nagle ne permet qu'à un seul petit segment à la fois d'être mis en instance sans accusé de réception. Si plusieurs petits segments sont générés durant l'attente d'un ACK du premier, ces segments sont fusionnés en un segment plus grand. Tout segment de taille pleine est toujours aussitôt transmis, en supposant qu'une fenêtre de réception de taille suffisante soit disponible. L'algorithme de Nagle est efficace, car il réduit le nombre de paquets envoyés par les applications interactives, telles que Telnet, en particulier sur les liaisons lentes.
Il est possible de l'observer dans la trace suivante, capturée par le Moniteur réseau Microsoft. L'analyse a été capturée en utilisant PPP pour accéder à distance à un fournisseur Internet à 9600 bps. Une session Telnet (mode caractère) a été établie, puis la clé Y a été maintenue enfoncée sur la station de travail Windows NT. Toutes les fois, un segment a été envoyé et d'autres caractères Y ont été conservés dans la pile jusqu'à la réception d'un accusé de réception relatif au segment précédent. Dans cet exemple, de trois à quatre caractères Y ont été mis chaque fois dans la mémoire tampon et envoyés ensemble dans un segment. L'algorithme de Nagle a permis d'éviter l'envoi d'un grand nombre de paquets, lequel a été réduit par un facteur d'environ trois.
Time Source IP Dest IP Prot Description
0.644 204.182.66.83 199.181.164.4 TELNET To Server Port =
1901
0.144 199.181.164.4 204.182.66.83 TELNET To Client Port =
1901
0.000 204.182.66.83 199.181.164.4 TELNET To Server Port =
1901
0.145 199.181.164.4 204.182.66.83 TELNET To Client Port =
1901
0.000 204.182.66.83 199.181.164.4 TELNET To Server Port =
1901
0.144 199.181.164.4 204.182.66.83 TELNET To Client Port =
1901
. . .
Chaque segment contenait plusieurs caractères Y. Voici le premier, analysé de façon plus complète ; la partie des données figure dans l'afficheur hexadécimal en bas.
***********************************************************************
Time Source IP Dest IP Prot Description
0.644 204.182.66.83 199.181.164.4 TELNET To Server Port =
1901
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
Protocol
+ IP: ID = 0xEA83; Proto = TCP; Len: 43
+ TCP: .AP..., len: 3, seq:1032660278, ack: 353339017, win:
7766,
src: 1901 dst: 23 (TELNET)
TELNET: To Server From Port = 1901
TELNET: Telnet Data
D2 41 53 48 00 00 52 41 53 48 00 00 08 00 45 00
.ASH..RASH....E.
00 2B EA 83 40 00 20 06 F5 85 CC B6 42 53 C7 B5 .+..@.
.....BS..
A4 04 07 6D 00 17 3D 8D 25 36 15 0F 86 89 50 18
...m..=.%6....P.
1E 56 1E 56 00 00 79 79 79 .V.V..yyy
^^^
data
Les applications Windows Sockets peuvent désactiver l'algorithme de Nagle pour leurs connexions en configurant l'option socket TCP_NODELAY. Cependant, cette méthode doit être évitée à moins qu'elle ne soit absolument nécessaire, car elle accroît l'utilisation du réseau. Il se peut que certaines applications réseau ne présentent pas de bonnes performances si leur conception ne prend pas en compte les effets de la transmission d'un grand nombre de petits paquets et l'algorithme de Nagle. Ce dernier ne s'applique pas aux connexions TCP avec bouclage pour des raisons liées aux performances. Windows 2000 Netbt désactive l'algorithme de Nagle pour les connexions NetBIOS sur TCP ainsi que pour les connexions redirecteur/serveur à hébergement direct, qui sont à même d'améliorer les performances pour les applications qui exécutent un grand nombre de commandes de manipulation de petits fichiers. Il peut s'agir par exemple d'une application qui fait fréquemment appel au verrouillage/déverrouillage de fichiers.
Retard TCP TIME-WAIT
Lorsqu'une connexion TCP est fermée, la paire de sockets est placée dans un état connu sous le nom de TIME-WAIT, ce qui permet de s'assurer qu'une nouvelle connexion n'utilise pas les mêmes protocole, adresse IP source, adresse IP de destination, port source et port de destination, jusqu'à ce qu'un intervalle de temps suffisant s'écoule pour garantir que tout segment qui pourrait avoir été mal routé ou retardé ne soit pas délivré inopinément. La durée de l'intervalle pendant lequel la paire de sockets ne doit pas être réutilisée est spécifiée dans la RFC 793 comme étant égale à 2 MSL (deux fois la durée de vie maximale d'un segment), soit quatre minutes. Ceci représente le réglage par défaut de Windows NT et Windows 2000. Toutefois, ce réglage permet l'utilisation de tous les ports disponibles par certaines applications réseau qui effectuent un grand nombre de connexions sortantes en un temps limité, avant que ces ports puissent être recyclés.
Windows NT et Windows 2000 disposent de deux méthodes pour surveiller ce comportement. La première est l'utilisation du paramètre de registre TcpTimedWaitDelay pour modifier cette valeur. Windows NT et Windows 2000 permettent le réglage de ce paramètre à un minimum de 30 secondes, ce qui ne pose aucun problème dans la plupart des environnements. La deuxième est la configuration du nombre de ports éphémères accessibles à l'utilisateur susceptibles d'établir des connexions sortantes par l'intermédiaire du paramètre de registre MaxUserPorts. Par défaut, quand une application demande un socket au système afin de l'utiliser pour générer un appel sortant, un port avec des valeurs comprises entre 1024 et 5000 est rendu disponible. Grâce au paramètre MaxUserPorts, il est possible de configurer la valeur du port le plus haut que l'administrateur choisit pour activer les connexions sortantes. Par exemple, en définissant cette valeur sur 10 000 (décimal), environ 9000 ports utilisateur seraient rendus disponibles pour les connexions sortantes. Pour en savoir plus sur ce sujet, consultez la RFC 793. Reportez-vous également aux paramètres de registre MaxFreeTcbs et MaxHashTableSize.
Connexions TCP vers et à partir d'ordinateurs multi-hôtes
Lorsque des connexions TCP sont établies vers un ordinateur multi-hôtes, le client WINS et le DNR (Domain Name Resolver) essaient de déterminer si une des adresses IP de destination fournie par le serveur de nom se trouve sur le même sous-réseau que n'importe laquelle des interfaces de l'ordinateur local. Dans ce cas, ces adresses sont triées vers le haut de la liste de manière à permettre à l'application de commencer par ces adresses avant d'essayer celles qui ne sont pas sur le même sous-réseau. Si aucune des adresses ne se trouve sur un sous-réseau commun avec l'ordinateur local, le comportement dépendra de l'espace de nom. Le paramètre de registre TCP/IP PrioritizeRecordData peut être utilisé pour empêcher le composant DNR de trier les adresses de sous-réseau local vers le haut de la liste.
Dans l'espace de nom WINS, le client est responsable du calcul aléatoire ou de l'équilibrage de charge entre les adresses fournies. Le serveur WINS renvoie toujours la liste d'adresses dans le même ordre et le client WINS en choisit une d'entre elles de façon aléatoire pour chaque connexion.
Dans l'espace de nom DNS, le serveur DNS est généralement configuré de manière à fournir les adresses à tour de rôle. Le DNR ne tente pas de calculer ultérieurement les adresses. Dans certains cas, il est souhaitable de connecter une interface spécifique sur un ordinateur multi-hôtes. La meilleure procédure à suivre pour y parvenir est de fournir à l'interface sa propre entrée DNS. Par exemple, un ordinateur dénommé raincity peut avoir une entrée DNS qui répertorie les deux adresses IP (en fait, deux enregistrements séparés dans le DNS avec le même nom), et également des enregistrements dans le DNS pour raincity1 et raincity2, chacun étant associé à une seule des adresses IP assignées à l'ordinateur.
Lorsque les connexions TCP sont établies à partir d'un ordinateur multi-hôtes, la situation se complique. Si la connexion correspond à une connexion Winsock utilisant l'espace de nom DNS, une fois que l'adresse IP de destination de la connexion est connue, TCP tente de se connecter à partir de la meilleure adresse IP source disponible. Une fois encore, la table d'itinéraires est utilisée afin d'effectuer cette détermination. En présence d'une interface dans l'ordinateur local située sur le même sous-réseau que l'adresse IP de destination, son adresse IP est utilisée comme source dans la requête de connexion. En l'absence d'adresse IP source optimale à utiliser, le système en choisit une de façon aléatoire.
Si la connexion correspond à une connexion basée sur NetBIOS utilisant le redirecteur, peu d'informations de routage sont disponibles au niveau de l'application. L'interface NetBIOS prend en charge les connexions sur de nombreux protocoles et ne possède aucune information sur le protocole IP. En revanche, le redirecteur établit les appels sur tous les transports qui lui sont associés. En présence de deux interfaces dans l'ordinateur et d'un protocole installé, le redirecteur dispose de deux transports. Les appels sont placés sur tous les deux et NetBT envoie les requêtes de connexion à la pile, en utilisant une adresse IP à partir de chaque interface. Il est possible que les deux appels aboutissent. Dans ce cas, le redirecteur annule l'un d'eux. Le choix de l'appel à annuler dépend de la valeur de registre ObeyBindingOrder du redirecteur5. S'il est configuré sur 0 (la valeur par défaut), le transport primaire (déterminer par l'ordre de liaison) est le préféré et le redirecteur attend l'expiration du transport primaire avant d'accepter la connexion sur le transport secondaire. Si cette valeur est configurée sur 1, l'ordre de liaison est ignoré et le redirecteur accepte la première connexion qui aboutit et annule les autres.
Considérations sur le débit
TCP a été conçu pour offrir des performances optimales en présence de conditions de liaison variées et Windows 2000 comporte des améliorations telles que celles prenant en charge la RFC 1323. Le débit réel d'une liaison dépend d'un certain nombre de variables, mais les facteurs les plus importants sont les suivants :
| • | Vitesse de la liaison (bits par seconde pouvant être transmis) |
| • | Retard de propagation |
| • | Dimension de la fenêtre (quantité de données n'ayant pas fait l'objet d'un accusé de réception et qui peuvent être en attente sur une connexion TCP) |
| • | Fiabilité de la liaison |
| • | Encombrement du réseau et des périphériques intermédiaires |
| • | MTU du parcours |
Le calcul du débit TCP est traité en détail dans les chapitres 20 à 24 de l'ouvrage en anglais TCP/IP Illustrated, de W. Richard Stevens6. Quelques considérations fondamentales sont répertoriées ci-dessous :
| • | La capacité d'un canal de communication est égale à la bande passante multipliée par le temps de transmission aller-retour. Elle est connue sous le nom de produit bande passante-retard. Si la liaison est fiable, pour obtenir des performances optimales, la dimension de la fenêtre doit être supérieure ou égale à la capacité du canal de communication, de manière à permettre à la pile d'envoi de le remplir. La plus grande dimension de fenêtre pouvant être spécifiée, en raison du champ de 16 bits de l'en-tête TCP, est de 65535. Des fenêtres plus larges peuvent toutefois être négociées grâce au redimensionnement des fenêtres, comme cela a été expliqué plus haut dans ce document. Voir TcpWindowSize dans l'annexe A. |
| • | Le débit ne peut jamais excéder la taille de la fenêtre divisée par le temps de transmission aller-retour. |
| • | Si la liaison n'est pas fiable ou est encombrée et que des paquets sont perdus, l'utilisation fenêtre de taille supérieure ne garantit pas nécessairement un meilleur débit. Windows 2000 prend en charge non seulement le dimensionnement des fenêtres, mais également les accusés de réception sélectifs (SACK, décrits dans la RFC 2018) pour améliorer les performances au sein d'environnements qui présentent des pertes de paquets. Il prend également en charge l'horodatage (décrit dans la RFC 1323) pour une meilleure évaluation RTT. |
| • | Le retard de propagation dépend de la vitesse de la lumière, des latences de l'équipement de transmission, etc. |
| • | Le retard de transmission dépend de la vitesse du support. |
| • | Pour un parcours spécifique, le retard de propagation est fixe, mais le retard de transmission dépend de la taille du paquet. |
| • | À des vitesses réduites, le retard de transmission constitue un facteur limitatif. À des vitesses élevées, le retard de propagation peut devenir un facteur de limitation. |
En résumé, Windows NT et Windows 2000 TCP/IP peuvent s'adapter à la plupart des conditions de réseau et fournir dynamiquement le meilleur débit et la meilleure fiabilité possibles pour chaque connexion. Les essais de mise au point manuelle sont souvent contre-productifs, sauf lorsqu'un ingénieur réseau qualifié procède préalablement à une étude précise du flux de données.
UDP (User Datagram Protocol)
UDP offre un service de transport peu fiable et sans connexion. Il est souvent utilisé en présence d'un trop grand nombre de communications qui utilisent des datagrammes IP de multidiffusion ou de diffusion. Étant donné que la remise des datagrammes UDP n'est pas garantie, les applications utilisant UDP doivent fournir leurs propres mécanismes pour la fiabilité, si nécessaire. La gestion réseau Microsoft utilise UDP pour l'ouverture de session, la navigation et la résolution de noms. Le protocole UDP peut également être utilisé pour porter les flux de multidiffusion IP.
UDP et résolution de noms
UDP est utilisé pour la résolution de noms NetBIOS par un flux monodiffusion vers un serveur de noms NetBIOS ou des diffusions de sous-réseau, ainsi que pour la résolution du nom d'hôte DNS en une adresse IP. La résolution de noms NetBIOS est exécutée sur le port UDP 137. Les requêtes DNS utilisent le port UDP 53. Etant donné que l'UDP lui-même ne peut garantir la remise des datagrammes, ces services utilisent leurs propres schémas de transmission s'ils ne reçoivent aucune réponse à leur requête. Les datagrammes UDP diffusés ne sont habituellement pas transmis par le biais des routeurs IP ; ainsi la résolution de noms NetBIOS dans un environnement acheminé requiert un serveur de noms d'un certain type, ou l'utilisation de fichiers statiques de base de données.
Mailslots sur UDP
De nombreuses applications NetBIOS utilisent la messagerie mailslot. Un mailslot de deuxième classe est un simple mécanisme d'envoi d'un message d'un nom NetBIOS à un autre sur UDP. Des messages mailslot peuvent être diffusés sur un sous-réseau ou dirigés vers l'hôte distant. Pour diriger un message mailslot vers un autre hôte, une méthode de résolution de noms NetBIOS doit être disponible. Microsoft offre un serveur WINS (Windows Internet Name Server) à cet effet.
NetBIOS sur TCP/IP
L'implémentation Windows NT et Windows 2000 de NetBIOS sur TCP/IP est connue sous le nom NetBT. NetBT utilise les ports UDP et TCP suivants :
| • | Port UDP 137 (services de nom) |
| • | Port UDP 138 (services de datagramme) |
| • | Port TCP 139 (services de session) |
NetBIOS sur TCP/IP est spécifié par les RFC 1001 et RFC 1002. Le pilote NetBT.sys est un composant en mode noyau qui prend en charge l'interface TDI (Transport Driver Interface). Les services tels que Station de travail et Serveur utilisent directement l'interface TDI, mais les appels des applications NetBIOS traditionnelles sont mappés vers des appels TDI par le pilote Netbios.sys. L'utilisation de TDI pour effectuer des appels vers NetBT constitue une tâche de programmation plus complexe, mais peut toutefois offrir des performances et une liberté supérieures par rapport aux limitations historiques de NetBIOS. Les concepts NetBIOS sont abordés dans la section intitulée "Interfaces d'application réseau" de ce document.
TDI (Transport Driver Interface)
Microsoft a développé l'interface TDI (Transport Driver Interface) afin d'offrir des fonctionnalités et une flexibilité supérieures à celles des interfaces existantes, telles que NetBIOS et Windows Sockets. Tous les fournisseurs de transport Windows utilisent l'interface TDI. La spécification TDI décrit l'ensemble des fonctions primitives utilisées par l'intermédiaire desquelles les pilotes de transport et les clients TDI communiquent, ainsi que les mécanismes d'appel utilisés pour y accéder. L'interface TDI fonctionne actuellement en mode noyau uniquement.
Le serveur et le redirecteur Windows 2000 utilisent chacun directement l'interface TDI, plutôt que de faire appel à la couche de routage NetBIOS. De cette manière, ils ne sont pas sujets aux nombreuses restrictions imposées par NetBIOS, telles que la limite historique de 254 sessions.
Fonctionnalités de l'interface TDI
L'interface TDI est peut être l'API réseau Windows la plus difficile à utiliser. Il s'agit d'un simple canal de communication et le programmeur doit par conséquent déterminer le format et la signification des messages.
L'interface TDI comporte les fonctions suivantes :
| • | prise en charge de TDI par la plupart des transports Windows NT ou Windows 2000 (à l'exception toutefois de DLC) ; |
| • | schéma d'adressage et de dénomination ouvert ; |
| • | transfert de messages et de données en mode continu ; |
| • | fonctionnement asynchrone ; |
| • | prise en charge de l'indication spontanée d'événements ; |
| • | extensibilité : les clients peuvent envoyer des requêtes privées à un pilote de transport qui est en mesure de les comprendre ; |
| • | prise en charge de l'utilisation limitée des fonctions E/S standard en mode noyau pour envoyer et recevoir des données ; |
| • | adressage et valeurs 32 bits ; |
| • | prise en charge des listes de contrôle d'accès (ACL, utilisées pour la sécurité) sur les objets d'adresse TDI. |
De plus amples informations relatives à l'interface TDI sont disponibles dans le Device Driver Kit (DDK) de Windows 2000.
Considérations relatives à la sécurité
La sécurité du réseau est un thème important pour les administrateurs lorsque les ordinateurs sont utilisés dans des réseaux publics. La pile TCP/IP de Microsoft a été renforcée contre de nombreux types d'attaque et son état par défaut gère la plupart des attaques communes. Des protections supplémentaires contre les attaques classiques d'interruption de service peuvent être ajoutées en activant la clé SynAttackProtect dans le registre. Cette clé permet à l'administrateur de choisir plusieurs niveaux de protection contre les attaques SYN.
Voici quelques instructions générales qui peuvent réduire votre vulnérabilité face aux attaques :
| • | Désactivez les services facultatifs ou non nécessaires (par exemple, le client pour réseaux Microsoft sur un serveur IIS). |
| • | Activez le filtrage TCP/IP et limitez l'accès aux seuls ports qui sont nécessaires au fonctionnement du serveur. |
| • | Supprimez la liaison NetBIOS sur TCP/IP lorsqu'elle n'est pas nécessaire. |
| • | Configurez les paramètres et les adresses IP statiques pour les cartes publiques. |
| • | Configurez les paramètres de registre pour une protection maximale (voir Annexe D). |
Consultez régulièrement les informations de TechNet concernant la sécurité pour prendre connaissance des bulletins de sécurité.
Les interfaces d'application réseau
Les applications réseau peuvent communiquer de plusieurs façons à l'aide de la pile de protocole TCP/IP. Certaines d'entre elles, telles que les canaux nommés, passent par le redirecteur réseau, lequel appartient au service Station de travail. De nombreuses applications plus anciennes étaient écrites vers l'interface NetBIOS, prise en charge par NetBIOS sur TCP/IP.
L'interface Windows Sockets est actuellement populaire. Un rapide aperçu de l'interface Windows Sockets et de l'interface NetBIOS est présenté ici.
Windows Sockets
Le terme de Windows Sockets désigne une interface de programmation basée sur l'interface socket ordinaire, développée par l'University of California de Berkeley. Elle comporte un ensemble d'extensions conçues pour tirer parti de la nature à base de messages de Microsoft Windows. La version 1.1 de la spécification a été lancée en janvier 1993 et la version 2.2.0 a été publiée en mai 1996.7 Windows 2000 prend en charge la version 2.2, souvent appelée Winsock2.
Applications
De nombreuses applications Windows Sockets sont disponibles. Un certain nombre d'utilitaires livrés avec Windows 2000 sont basés sur Windows Sockets, notamment les clients et serveurs FTP et DHCP, le client Telnet, etc. Il existe également des interfaces de programmation de niveau supérieur basées sur Winsock, telles que l'API Windows Internet (WinInet) utilisée par Internet Explorer.
Résolution d'adresses et de noms
Les applications Windows Sockets utilisent généralement la fonction gethostbyname() pour résoudre un nom d'hôte en une adresse IP. La fonction gethostbyname() utilise la séquence de recherche de nom suivante (par défaut) :
1. | elle vérifie le nom de l'hôte local pour trouver un nom correspondant ; |
2. | elle vérifie le fichier des hôtes pour trouver une entrée de nom correspondante ;. |
3. | si un serveur de nom de domaine (DNS) est configuré, elle l'interroge ; |
4. | si aucune correspondance n'est identifiée, elle tente la résolution de noms NetBIOS jusqu'à une tentative de résolution DNS. |
Certaines applications utilisent la fonction gethostbyname() pour résoudre une adresse IP en un nom d'hôte. L'appel gethostbyaddr() utilise la séquence (par défaut) suivante :
1. | elle vérifie le fichier de l'hôte pour identifier une entrée d'adresse correspondante ; |
2. | si un serveur de nom de domaine (DNS) est configuré, elle l'interroge. |
3. | elle envoie une requête d'état de la carte NetBIOS à l'adresse IP interrogée. Si celle-ci répond avec une liste de noms NetBIOS enregistrés pour la carte, elle l'analyse pour identifier le nom de l'ordinateur. |
Prise en charge de la multidiffusion IP
Winsock2 prend en charge la multidiffusion IP. La multidiffusion est décrite dans la spécification Windows Sockets 2.0 et dans la section IGMP de ce document. La multidiffusion IP est actuellement prise en charge uniquement sur les sockets AF_INET des types SOCK_DGRAM et SOCK_RAW.
Paramètre de journal
Les applications serveur Windows Sockets créent généralement un socket et utilisent ensuite la fonction listen() pour écouter les requêtes de connexion. Un des paramètres entrés lors de l'appel de la fonction listen() est le journal des requêtes de connexion que l'application voudrait que Windows Sockets mette en file d'attente. Cette valeur spécifie le nombre de connexions non acceptées qui peuvent être mises en file d'attente. Dès qu'une application accepte une connexion, elle est sortie du journal de requêtes de connexion et ne compte plus. La spécification de Windows Sockets 1.1 indique que la valeur maximale possible pour un journal est de 5 ; Windows NT 3.51 accepte cependant un journal allant jusqu'à 100, Windows NT 4.0 et le Serveur Windows 2000 acceptent un journal de 200, le poste de travail Windows NT 4.0 et Windows 2000 Professional acceptent un journal de 5 (ce qui réduit les demandes de mémoire).
Interprétation du bit Push
Par défaut, Windows 2000 TCP/IP effectue un appel de la fonction recv() en présence d'une des conditions suivantes :
| • | Si les données arrivent avec le bit PUSH configuré. |
| • | Si la mémoire tampon recv utilisateur est pleine. |
| • | Si 0,5 secondes se sont écoulées depuis l'arrivée de données. |
Si une application cliente est exécutée sur un ordinateur avec une implémentation TCP/IP qui ne configure pas le bit push sur les opérations d'envoi, des retards de réponse peuvent se présenter. Il convient de corriger cela sur le client ; un paramètre de configuration (IgnorePushBitOnReceives) a toutefois été ajouté à Afd.sys pour le forcer à traiter tous les paquets entrants comme si le bit push était configuré. Ce paramètre était nouveau dans Windows NT 4.0 et est pris en charge dans Windows 2000.
NetBIOS sur TCP/IP
NetBIOS définit une interface logicielle et une convention de dénomination, pas un protocole. Les versions précédentes des produits de gestion réseau Microsoft offraient uniquement le protocole de gestion de réseau local NetBEUI avec une interface de programmation d'applications NetBIOS. NetBEUI est un petit protocole rapide et sans couche de gestion réseau ; il n'est par conséquent pas routable et n'est souvent pas adapté aux implémentations WAN. NetBEUI fait appel aux diffusions pour la résolution de noms et la localisation des services. NetBIOS sur TCP/IP offre l'interface de programmation NetBIOS sur le protocole TCP/IP, en élargissant la portée des programmes serveur et client NetBIOS au WAN et en offrant une interopérabilité avec de nombreux autres systèmes d'exploitation.
Les services Station de travail, Serveur, Explorateur d'ordinateur, Messagerie et NetLogon sont tous des clients (directs) NetBT. Ils utilisent TDI (décrit plus haut dans ce livre blanc) pour communiquer avec NetBT. Windows NT et Windows 2000 possèdent également un émulateur NetBIOS. L'émulateur prend en charge les requêtes NetBIOS standard à partir des applications NetBIOS et les convertit en primitives TDI équivalentes.
Windows 2000 utilise encore NetBIOS sur TCP/IP pour communiquer avec les versions précédentes de Windows NT et d'autres clients, tels que Windows 95. Cependant, les composants du serveur et du redirecteur de Windows 2000 prennent à présent également en charge l'hébergement direct pour communiquer avec d'autres ordinateurs sous Windows 2000. L'hébergement direct utilise le DNS pour la résolution de noms. Aucune résolution de noms NetBIOS (WINS ou diffusion) n'est utilisée et le protocole est plus simple. Direct Host TCP utilise le port 445 plutôt que le port 139 NetBIOS TCP.
Par défaut, NetBIOS et l'hébergement direct sont tous deux activés et font l'objet d'une tentative en parallèle lors de l'établissement d'une nouvelle connexion. Le premier qui aboutit à une connexion est utilisé pour toute tentative. Le prise en charge de NetBIOS peut être désactivée pour forcer tout le trafic à utiliser l'hébergement direct.
Pour désactiver le support NetBIOS
1. | Dans le menu Démarrer, pointez sur Paramètres, puis cliquez sur Connexion réseau et accès à distance. Cliquez avec le bouton droit de la souris sur Connexion au réseau local, puis sur Propriétés. |
2. | Sélectionnez Protocole Internet (TCP/IP), puis cliquez sur Propriétés. |
3. | Cliquez sur Avancé. |
4. | Sélectionnez l'onglet WINS et cliquez sur Désactiver NetBIOS avec TCP/IP. |
Après cette procédure, les applications et services qui dépendent de NetBIOS ne fonctionnent plus et il est par conséquent important de vérifier que les clients et applications n'ont plus besoin du support NetBIOS avant de procéder à la désactivation. Par exemple, les ordinateurs antérieurs à Windows 2000 ne pourront parcourir, localiser ou créer des connexions de partage de fichiers et d'impression vers un ordinateur Windows 2000 si NetBIOS est désactivé.
Noms NetBIOS
L'espace de noms NetBIOS est plat, ce qui signifie que tous les noms au sein de l'espace de noms doivent être uniques. Les noms NetBIOS ont une longueur de 16 caractères. Les ressources sont identifiées par des noms NetBIOS, qui sont enregistrés dynamiquement lors de l'amorçage des ordinateurs, du démarrage des applications ou des services, ou encore lorsque des utilisateurs ouvrent une session. Les noms peuvent être enregistrés comme nom unique (un seul propriétaire) ou comme noms de groupe (propriétaires multiples). Une requête de nom NetBIOS est utilisée pour localiser une ressource en résolvant le nom en une adresse IP.
Les composants de gestion réseau Microsoft, tels que les services Station de travail et Serveur, permettent à l'utilisateur ou à l'administrateur de spécifier les 15 premiers caractères d'un nom NetBIOS, mais ils réservent le seizième caractère du nom NetBIOS pour indiquer un type de ressource (00-FF hex). De nombreux logiciels populaires d'éditeurs tiers utilisent également ce caractère pour identifier et enregistrer leurs services spécifiques. Le tableau 3 répertorie des exemples de noms NetBIOS utilisés par les composants Microsoft.
Tableau 3 : exemples de noms NetBIOS utilisés par les composants Microsoft
|
Pour connaître les noms enregistrés par un ordinateur sur NetBT, tapez la séquence suivante à partir de l'invite de commande :
nbtstat -n
Après le démarrage d'un ordinateur, Windows 2000 vous permet d'enregistrer à nouveau les noms avec le serveur de noms. Pour ce faire, tapez la séquence suivante à partir de l'invite de commande :
nbtstat –RR
Enregistrement et résolution de noms NetBIOS
Les systèmes TCP/IP Windows utilisent plusieurs méthodes pour localiser les ressources NetBIOS :
| • | Cache de nom NetBIOS |
| • | Serveur de noms NetBIOS |
| • | Diffusion de sous-réseaux IP |
| • | Fichier Lmhosts statique |
| • | Nom de l'hôte local (facultatif, dépend du paramètre de registre EnableDns) |
| • | Fichier des hôtes statiques (facultatif, dépend du paramètre de registre EnableDns) |
| • | Serveurs DNS (facultatif, dépend du paramètre de registre EnableDns) |
L'ordre de résolution des noms NetBIOS dépend du type de nœud et de la configuration du système. Les types de nœuds suivants sont pris en charge :
| • | Nœud-B : utilise les diffusions pour la résolution et l'enregistrement de noms. |
| • | Nœud-P : utilise un serveur de noms NetBIOS (tel que WINS) pour l'enregistrement et la résolution de noms. |
| • | Nœud-M : utilise des diffusions pour l'enregistrement de noms. Pour la résolution des noms, il tente d'abord les diffusions, mais il bascule vers le nœud-p s'il ne reçoit aucune réponse. |
| • | Nœud-H : utilise un serveur de noms NetBIOS aussi bien pour l'enregistrement que pour la résolution. Cependant, si aucun serveur de noms ne peut être localisé, il bascule vers le nœud-b. Il poursuit l'interrogation afin d'identifier un serveur de noms et bascule de nouveau vers le nœud-p lorsqu'un serveur devient disponible. |
| • | Microsoft-enhanced : utilise le fichier local Lmhosts ou les proxy WINS plus les appels de la fonction Windows Sockets gethostbyname (en utilisant les fichiers d'hôtes locaux et/ou DNS standard), en plus des types de nœuds standard. |
Microsoft livre un serveur de noms NetBIOS connu sous le nom de WINS (Windows Internet Name Service). La plupart des clients WINS sont configurés en tant que nœuds-h ; en d'autres termes, ils tentent d'abord d'enregistrer et de résoudre les noms en utilisant WINS et, en cas d'échec, ils essaient les diffusions sur le sous-réseau local. L'utilisation d'un serveur de noms pour localiser les ressources est généralement préférable à la diffusion, et ce pour deux raisons :
| • | Les diffusions ne sont pas habituellement transmises par les routeurs. |
| • | Les diffusions sont reçues par tous les ordinateurs d'un sous-réseau et requièrent un temps de traitement sur chaque ordinateur. |
Enregistrement et résolution de noms NetBIOS pour les ordinateurs multi-hôtes
Comme cela a été indiqué, NetBT se lie à une seule adresse IP par interface réseau physique. Du point de vue de NetBT, un ordinateur est de type multi-hôtes uniquement s'il possède plusieurs cartes réseau. Lorsqu'un paquet d'enregistrement de nom est envoyé à partir d'une machine multi-hôtes, il est signalé comme un enregistrement de nom multi-hôtes, de manière à l'empêcher d'entrer en conflit avec le même nom enregistré par une autre interface dans le même ordinateur.
Si un ordinateur multi-hôtes reçoit une requête de nom de diffusion, toutes les liaisons NetBT/interface recevant la requête répondent avec leurs adresses et le client choisit par défaut la première réponse pour se connecter à l'adresse fournie. Ce comportement peut être contrôlé par le paramètre de registre RandomAdapter décrit à l'Annexe B.
Lorsqu'une requête de nom dirigée est envoyée à un serveur WINS, le serveur WINS répond avec une liste de toutes les adresses IP qui étaient enregistrées avec WINS par l'ordinateur multi-hôtes.
Le choix de la meilleure adresse IP pour se connecter sur un ordinateur multi-hôtes est une fonction client. L'algorithme suivant est actuellement utilisé dans l'ordre indiqué :
1. | Si une des adresses IP de la liste de réponses à la requête de nom se trouve sur le même sous-réseau logique que la liaison d'appel de NetBT sur l'ordinateur local, cette adresse est sélectionnée. Si plusieurs adresses répondent aux critères, l'une d'entre elles est choisie de façon aléatoire. |
2. | Si une des adresses IP de la liste se trouve sur le même réseau (classless) que la liaison d'appel de NetBT sur l'ordinateur local, cette adresse est sélectionnée. Si plusieurs adresses répondent aux critères, l'une d'entre elles est choisie de façon aléatoire. |
3. | Si une des adresses IP de la liste se trouve sur le même sous-réseau logique que la liaison d'appel de NetBT sur l'ordinateur local, cette adresse est sélectionnée. Si plusieurs adresses répondent aux critères, l'une d'entre elles est choisie de façon aléatoire. |
4. | Si aucune des adresses IP de la liste ne se trouve sur le même sous-réseau qu'une liaison quelconque de NetBT sur l'ordinateur local, une adresse est sélectionnée de façon aléatoire dans la liste. |
Cet algorithme fournit une procédure plutôt appropriée pour équilibrer les connexions vers un serveur à travers plusieurs cartes réseau tout en favorisant les connexions directes (même sous-réseau) lorsqu'elles sont disponibles. Lorsqu'une liste d'adresses IP est renvoyée, ces adresses sont triées selon l'ordre le plus approprié et NetBT procède à des tentatives de connexion sur chaque adresse de la liste jusqu'à ce que l'une d'elles réponde. NetBT tente ensuite de se connecter à cette adresse. Si aucune adresse ne répond, une tentative de connexion est quand même effectuée à la première adresse da la liste. Cette tentative est opérée en présence d'un pare-feu ou d'autres périphériques de filtrage du trafic ICMP. Windows 2000 prend en charge la mise en cache NetBT du nom par interface et nbtstat -c affiche le cache de nom par interface.
Améliorations de NetBT Internet/DNS et périphérique SMB
Il a toujours été possible de se connecter d'un ordinateur Windows à un autre à l'aide de NetBT sur Internet. Il a par conséquent fallu fournir plusieurs procédures de résolution de noms. Deux méthodes communes nécessitent l'utilisation du fichier Lmhosts ou d'un serveur WINS. Plusieurs améliorations ont été introduites dans Windows NT 4.0 et conservées dans Windows 2000 pour éliminer ces exigences de configuration particulières.
Il est à présent possible de se connecter à une ressource NetBIOS sur TCP/IP au moyen de deux nouvelles procédures :
| • | Utiliser la commande net use \\adresse ip\nom_partage. De cette manière, la configuration de la résolution de noms NetBIOS n'est plus nécessaire. |
| • | Utiliser la commande net use \\FDQN\nom_partage. De cette manière, il est possible d'utiliser un DNS pour se connecter à un ordinateur en utilisant son nom de domaine complet (FDQN). |
Des exemples de l'utilisation de cette nouvelle fonctionnalité pour mapper un lecteur vers ftp.microsoft.com sont présentés ci-dessous. L'adresse IP indiquée ci-dessous peut être modifiée.
| • | net use f: \\ftp.microsoft.com\data |
| • | net use \\198.105.232.1\data |
| • | net view \\198.105.232.1 |
| • | dir \\ftp.microsoft.com\bussys\winnt |
En outre, de nombreuses applications, telles que la boîte de dialogue Sélectionner un ordinateur de l'Observateur d'événements, vous permettent d'entrer directement un nom de domaine complet ou une adresse IP. Dans Windows 2000, il est également possible d'utiliser l'hébergement direct pour établir des connexions serveur ou redirecteur entre des ordinateurs Windows 2000, sans utilisation de l'espace de noms NetBIOS ni du mappage de couche. Par défaut, Windows tente d'établir des connexions en utilisant ces deux procédures afin de pouvoir prendre en charge les connexions vers des ordinateurs de niveau inférieur. Toutefois, dans les environnements fonctionnant uniquement sous Windows 2000, vous pouvez désactiver complètement NetBIOS du dossier Connexions réseau.
La nouvelle interface de Windows 2000 qui permet les opérations sans NetBIOS est dénommée périphérique SMB. Elle sera considérée par le redirecteur et le serveur comme une autre interface, plus ou moins comme dans le cas d'une combinaison individuelle de pile de protocole/carte réseau. Cependant, au niveau de la pile TCP/IP, le périphérique SMB est lié à ADDR_ANY et il utilise l'espace de noms d'origine, comme une application Windows Sockets. Les appels effectués sur le périphérique SMB aboutiront à une recherche DNS standard destinée à résoudre le nom (DNS) en une adresse IP, suivie d'une requête de connexion sortante unique (même sur un ordinateur multi-hôtes) à l'aide de la meilleure interface et adresse IP source, selon la table d'itinéraires. En outre, il n'existe aucune configuration de session NetBIOS au sommet de la connexion TCP, contrairement au NetBIOS traditionnel sur TCP/IP. Par défaut, le redirecteur place les appels à la fois sur le(s) périphérique(s) NetBIOS et sur le périphérique SMB, et le serveur de fichiers reçoit les appels sur chacun d'eux. Le périphérique SMB du serveur de fichiers est à l'écoute sur le port TCP 445 plutôt que sur le port NetBIOS sur TCP 139 traditionnel.
Sessions NetBIOS sur TCP
Les sessions NetBIOS sont établies entre deux noms. Lorsqu'un poste de travail Windows 2000 Professionnel exécute par exemple une connexion de partage de fichiers vers un serveur en utilisant NetBIOS sur TCP/IP, la séquence d'événements indiquée ci-dessous se produit :
1. | Le nom NetBIOS du serveur est résolu en une adresse IP. |
2. | L'adresse IP est résolue en une adresse MAC (contrôle d'accès au support). |
3. | Une connexion TCP est établie à partir du poste
de travail vers le serveur, en utilisant le |
4. | Le poste de travail envoie une requête de session NetBIOS au nom de serveur sur la connexion TCP. Si le serveur est à l'écoute sur ce nom, il répond par l'affirmative et une session est établie. |
Dès que la session NetBIOS a été établie, le poste de travail et le serveur négocient le niveau de protocole SMB à utiliser. La gestion réseau Microsoft n'utilise qu'une seule session NetBIOS simultanément entre deux noms. Toute connexion supplémentaire de partage de fichiers ou d'impression est multiplexée au cours de la même session NetBIOS en utilisant des identificateurs dans l'en-tête SMB.
Les messages de maintien d'activité NetBIOS sont utilisés sur chaque connexion pour vérifier que le serveur et le poste de travail sont toujours en mesure de maintenir leur session. Par conséquent, si une station de travail est arrêtée de façon incorrecte, le serveur supprime éventuellement la connexion et les ressources associées, et inversement. Les maintiens d'activité NetBIOS sont contrôlés par le paramètre de registre SessionKeepAlive et sont établis par défaut à une fois par heure.
Si des fichiers Lmhosts sont utilisés et qu'une entrée est mal orthographiée, il est possible d'essayer de se connecter à un serveur à l'aide de l'adresse IP correcte, mais avec un nom incorrect. Dans ce cas, une connexion TCP est encore établie vers le serveur. Toutefois, la requête de session NetBIOS (utilisant le nom mal orthographié) est rejetée par le serveur, car il n'y a aucune écoute postée sur ce nom. Une erreur 51, "Remote computer not listening", est générée.
Services de datagramme NetBIOS
Les datagrammes sont envoyés d'un nom NetBIOS à un autre par le biais du port UDP 138. Le service de datagramme permet d'envoyer un message à un nom unique ou à un nom de groupe. Les noms de groupe peuvent résoudre une liste d'adresses IP ou une diffusion. Par exemple, la commande net send /d:domainetest envoie un datagramme contenant le texte "test" au nom de groupe domaine [03]. Le nom domaine [03] est résolu en une diffusion de sous-réseau IP et le datagramme est ainsi envoyé avec les caractéristiques suivantes :
| • | Adresse MAC de destination : diffusion (FFFFFFFFFFFF). |
| • | Adresse MAC source : l'adresse de la carte réseau de l'ordinateur local. |
| • | Adresse IP de destination : l'adresse de diffusion du sous-réseau local. |
| • | Adresse IP source : l'adresse IP de l'ordinateur local. |
| • | Nom de destination : domaine [03] (le service Messagerie sur les ordinateurs distants). |
| • | Nom source : nom_utilisateur [03] (le service Messagerie sur l'ordinateur local). |
Tous les hôtes du sous-réseau prélèvent le datagramme et le traitent, au moins jusqu'au protocole UDP. Sur les hôtes qui exécutent un service de datagramme NetBIOS, UDP transmet le datagramme à NetBT sur le port 138. NetBT contrôle le nom de destination pour savoir si une application a posté une réception de datagramme ; si tel est le cas, il transmet le datagramme au niveau supérieur. Si aucune réception n'est postée, le datagramme est éliminé.
Si la prise en charge de NetBIOS est désactivée dans Windows 2000 (comme cela a été décrit plus haut dans cette section), les services de datagramme NetBIOS ne sont pas disponibles.
|
Dernière mise à jour le mardi 28 novembre 2000