Aldevar

Nouvelle QRQVB et pas des moindres, le protocole TCP (Transmission Control Protocol, Protocole de Contrôle de Transmission).  Comme son petit frère UDP, TCP se situe en couche 4 du modèle OSI.

Caractéristique de TCP

TCP est bien plus compliqué qu’UDP examiné au chapitre précédent. Il apporte en contrepartie des services beaucoup plus élaborés.

• TCP contient un mécanisme pour assurer le bon acheminement des données. Cette possibilité est absolument indispensable dès lors que les applications doivent transmettre de gros volumes de données de façon fiable. Cette fonction est assurée par un mécanisme d’acquittement (ou accusé de réception). Les paquets de données sont acquittés de bout en bout et non de point à point. C’est à dire que ce sont les machines sources et machines de destinations qui s’occupent de cela et non les routeurs qui se situent entre les 2.
• Le protocole TCP permet l’établissement d’un circuit virtuel entre les 2 machines qui échangent de l’information (Voir a ce propos le commentaire de Guizmo.7). On dit aussi que TCP  fonctionne en mode connecté (par opposition à UDP qui est en mode non connecté). En pratique, l’une des 2 machine doit effectuer un appel que l’autre doit accepter. S’en suit une discutions afin d’établir certains paramètres de communication. Une fois les préliminaires terminés, les protocoles informent les applications respectives que la connexion est établie et que le transfert peut débuter. Durant le transfert, le dialogue entre les protocoles continue, pour vérifier le bon acheminement des données.
• TCP a la capacité de mémoriser les données. Les paquets pouvant prendre chacun un chemin différent pour arriver à destination, il arrive que ceux ci n’arrivent pas dans le bon ordre. Grâce à cette capacité de mémorisation, TCP garde les paquets un certains temps et les reconstitue lorsqu’ils sont tous arrivés afin de présenter les données à l’application.
• TCP simule une connexion en « full duplex ». Pour chacune des 2 machines en connexion, l’opération qui consiste à lire des données peut s’effectuer indépendamment de celle qui consiste à en écrire.

Entête TCP

L’entête TCP est codé sur 20 octets hors options.

• Port Source (16 bits): Port utilisé par l’application sur la machine source.
• Port Destination (16 bits): Port de destination.
• Numéro d’ordre (32 bits): Correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.
• Numéro d’accusé de réception (32 bits): Acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les datagrammes <1500 ont été reçus
• Offset (4 bits): Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits dans l’entête TCP. Ce champ indique donc où les données commencent.
• Réservé (6 bits): Champ inutilisé actuellement. Il était à l’origine prévu pour l’avenir. On peut dire aujourd’hui que ce champ restera vide.
• Drapeaux (flags) (6×1 bit): Les drapeaux représentent des informations supplémentaires :
  URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.
  ACK: si ce drapeau est à 1 le paquet est un accusé de réception.
  PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode PUSH.
  RST: si ce drapeau est à 1, la connexion est réinitialisée.
  SYN: Le Flag TCP SYN indique une demande d’établissement de connexion.
  FIN: si ce drapeau est à 1 la connexion s’interrompt.
• Fenêtre (16 bits): Champ permettant de connaître le nombre d’octets que le récepteur souhaite recevoir sans envoyer d’accusé de réception.
• Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisant la somme des champs de données de l’en-tête, afin de pouvoir vérifier l’intégrité de l’en-tête
• Pointeur d’urgence (16 bits): Indique le numéro d’ordre à partir duquel l’information devient urgente.

Établissement d’une connexion

Une ouverture de connexion TCP s’effectue en 3 temps.

L’émetteur du premier paquet doit avoir connaissance du couple IP : Port de l’application de la machine réceptrice (par exemple, on contact un serveur HTTP sur le port 80 qui lui est dédié). L’émetteur de ce premier paquet est à l’origine de l’établissement du circuit virtuel. C’est une attitude qualifiée de « cliente« .

Le récepteur du premier paquet accepte l’établissement de la connexion, ce qui suppose qu’il était prêt à le faire avant que le client en prenne l’initiative. C’est une attitude de « serveur« .

Le client envoie un segment comportant le drapeau SYN à 1. Le serveur répond avec sa propre séquence (SYN = 1) mais il doit aussi acquitter le paquet précédent, ce qu’il fait avec ACK. Le client répond alors avec un acquittement de la séquence du serveur (ACK = 1).

Une fois achevée cette phase appelée « Three-way handshake », les 2 applications sont en mesure d’échanger des données.

Conclusion

Voilà pour une première partie sur TCP. La seconde partie permettra de voir comment fonctionne la clôture d’une connexion ainsi que l’acquittement des paquets durant les transferts de données.  TCP est bien plus compliquer à aborder qu’UDP et c’est pourquoi je préfère le faire en 2 parties. J’essaierai d’ajouter dans la seconde partie quelques captures de trames afin d’illustrer ceci plus clairement. N’hésitez pas à laisser des commentaires si certaines notions vous paraissent mal expliquées ou trop survolées dans ce billet.

Suite de la Question Réseau Qui Va Bien, nouveau billet purement réseau donc. Je comptais me lancer dans la description des paquets TCP, mais je pense qu’il est plus intéressant de se pencher d’abord sur UDP avant d’appréhender TCP.

UDP (Pour User Datagram Protocol) se situe dans la couche 4 du modèle OSI (couche transport). Pour rappel, au niveau de la couche 3 (IP), les datagrammes sont routés d’une machine à une autre en fonction des adresses IP (en fait, le routage se fait en fonction de l’adresse réseau, voir QRQVB : L’adresse IP). Lors de cette opération de routage, aucune distinction n’est faite entre les différents services pour lesquels ces paquets peuvent être destinés. Que ce soit pour une connexion SSH (port 22) ou HTTP (port 80) ou autre, les datagrammes IP sont tous indifféremment mélangés.

La couche 4 du modèle OSI ajoute un mécanisme qui permet l’identification du service  concerné. Plusieurs programmes de plusieurs utilisateurs pouvant simultanément circuler sur le réseau, il est indispensable de faire un tri entre les applications. Ici, l’idée est d’associer la destination du paquet à une fonction. L’identification de cette fonction ce fait à l’aide d’un chiffre nommé Port.

En tête UDP

Lors de l’étude des datagramme IP, nous avions vu le contenu de l’entête du paquet (partie verte). Ici,  nous allons observer le contenu de l’entête du message (partie jaune) lorsque l’on traite un paquet UDP.

Le paquet UDP est composé de 8 octets.

Les 2 premiers octets contiennent le port source. Codé sur 16 bits donc. C’est le numéro de port de l’émetteur du paquet. C’est aussi le numéro de port sur lequel le destinataire doit envoyer sa réponse.

Les octets 3 et 4 stockent le port de destination. C’est sur ce port que sera remis le paquet lors de sa livraison à la machine ciblée.

Le port étant un entier positif de 16 bits, on en déduit que les bornes sont 0 – 65535 (2^16). Cependant, le port 0 n’est pas exploitable.

Les octets 5 et 6 contiennent la longueur de l’entête UDP et du message. Sa longueur minimal est 8 (entête UDP avec 0 données à transporter) et sa longueur maximal 2^16 = 65535 (64ko).

Les 2 derniers octets contiennent le cheksum. C’est la somme de contrôle de l’entête UDP et des données qui suivent.

Ports réservés

Toute machine qui utilise la pile TCP/IP se doit de connaitre un certains nombre de services bien connus, aussi appelé « well known port number » pour pouvoir dialoguer avec les autres machines sur internet. Sur une machines Unix, cette liste est placée dans le fichier /etc/services et se doit d’être lisible par tous les utilisateurs et toutes les applications. Voici un extrait du contenu de ce fichier :

Nom             Port/Protocol     Commentaire

netstat		15/tcp
 qotd		17/tcp		quote
 msp		18/tcp		# message send protocol
 msp		18/udp
 chargen	19/tcp		ttytst source
 chargen	19/udp		ttytst source
 ftp-data	20/tcp
 ftp		21/tcp
 fsp		21/udp		fspd
 ssh		22/tcp		# SSH Remote Login Protocol
 ssh		22/udp
 telnet		23/tcp
 smtp		25/tcp		mail
 time		37/tcp		timserver
 time		37/udp		timserver
 rlp		39/udp		resource	# resource location
 nameserver	42/tcp		name		# IEN 116
 whois		43/tcp		nicname
 tacacs		49/tcp				# Login Host Protocol (TACACS)
 tacacs		49/udp
 re-mail-ck	50/tcp				# Remote Mail Checking Protocol
 re-mail-ck	50/udp
 domain		53/tcp				# name-domain server
 domain		53/udp
 mtp		57/tcp				# deprecated
 tacacs-ds	65/tcp				# TACACS-Database Service
 tacacs-ds	65/udp
 bootps		67/tcp				# BOOTP server
 bootps		67/udp
 bootpc		68/tcp				# BOOTP client
 bootpc		68/udp
 tftp		69/udp
 gopher		70/tcp				# Internet Gopher
 gopher		70/udp
 rje		77/tcp		netrjs
 finger		79/tcp
 www		80/tcp		http		# WorldWideWeb HTTP
 www		80/udp				# HyperText Transfer Protocol

Les ports 1 à 1023 sont réservés aux « well known ports ». Ils ne peuvent être utilisés que par des applications qui s’exécutent avec des droits privilégiés (root). Les autres ports peuvent être utilisés librement sans privilège particulier et sont en général employés par les applications clientes. Par exemple, sur ma machine, en ce moment, mon client IRC utilise le port 59175 pour communiquer avec le serveur irc holmes.freenode.net.

Mode non connecté

Contrairement à TCP, UDP est conçu pour permettre un échange de données entre 2 applications sans échange préliminaire. UDP est utilisé si les données à transmettre n’ont pas besoin d’être fragmentées en plusieurs paquet. La paquet est ainsi envoyé sans s’assurer qu’il arrive bien à destination. UDP est appelé mode de transport non connecté par opposition à TCP. Plus particulièrement, les paquets a destination d’une application UDP sont conservés dans une pile de type FIFO. Si l’application destinatrice ne les “consomme” pas assez rapidement, les plus anciens paquets risquent d’être écrasés par les plus récents… Un risque supplémentaire de perte de données.

Nous verrons comment TCP peut palier à ce problème dans la prochaine QRQVB

Je vais tenter dans cet article de décortiquer un datagramme IP et notamment son en-tête. Nous allons commencer par l’observation des encapsulations des données suivant le modèle OSI que nous avons étudié la dernière fois. Les données (couche application) sont encapsulées dans un message (couche 4, transport) qui est lui même encapsulé dans un paquet (couche 3, réseau), lui même encapsulé dans une trame (couche 2, liaison). Rien ne vaut un bon dessin pour comprendre.

Aujourd’hui, on va donc s’intéresser à ce que contient le petit carré vert lorsque le paquet est un paquet IP.

Cet en-tête est codé par défaut sur 20 octets. Nous allons donc nous appliquer à décrypter le contenu de chacun de ses octets. J’ai fait pour cela un schéma pas terrible mais qui me servira de support pour les explications :p.

• Le premier octet contient 2 informations.
  • • La première est la version du protocole utilisé, codée sur 4 bits. pour le protocole IPv4, on utilisera le code 0100 qui correspond au 4 décimal. Pour IPv6, c’est 0110 (6 décimal).
    • La seconde information, codée également sur 4 bits contient l’IHM. C’est la longueur, en mot de 32bits (4 octets), de l’en-tête du datagramme. Par défaut, ces bits sont positionnés sur 0101, ce qui correspond au 5 décimal, ce qui est logique pour un en-tête par défaut de 20 octets.

• Le deuxième octet est le TOS (type of service) et va définir la manière dont le datagramme doit être traité. Il se décompose lui aussi en 2 :
  • • 3 bits pour la priorité à donner au datagramme (0 à 7)
    • 4 bits qui définissent chacun une option activée ou pas (1 option activée, 0 option desactivée)
      • • 1er bit : D → Positionné sur 1 pour privilégier le délai d’acheminement
        • 2ème bit : T → Positionné sur 1 pour privilégier le débit
        • 3ème bit : R → Positionné sur 1 pour privilégier la fiabilité
        • 4ème bit : C → Positionné sur 1 pour privilégier le coût
    • 1 bit qui ne contient aucune information. Il est appelé MBZ pour Must Be Zero. comme son nom l’indique, ce bit doit être positionné sur 0.
• Les 3ème et 4ème octets contiennent le champ Longueur Totale (Total Lenght). Codé sur 16 bits, il contient la taille, en octet, du datagramme complet (en-tête + données). On en déduit donc que la longueur totale du paquet ne peut dépasser 65535 octets. Grâce à cette valeur, on peut calculer la taille des données :
  • • • • longueur données = Longueur totale – (IHM x 4)
• Les 5ème et 6ème octets contiennent le champ Identification. Celui ci intervient lors du ré-assemblage des paquets pour reconstituer les données lorsque celles ci sont fragmentées.

• Les 7ème et 8ème octets contiennent 2 informations.
  • • 3 bits correspondent au champ flag. Il sert a déterminer l’état de fragmentation.
      • • 1er bit : Réservé, il doit être sur 0
        • 2ème bit : Don’t Fragment. Indique si la fragmentation est autorisée.
        • 3ème bit : More Fragment. Positionné sur 1 il signifie que ce datagramme n’est pas le dernier fragment.
    • 13 bits correspondent au champ Position Fragment. Ce champ indique la position du fragment par rapport au premier datagramme et interviendra lors de la reconstitution du message.
• Le 9ème octet contient le TTL (Time to Live). ‘Durée de vie’ en français. Il indique le nombre maximal de routeurs que peut traverser le datagramme. Il est initialisé par la station émettrice et décrémenté de 1 par chaque routeur qui reçoit le datagramme et le réexpédie. Si un routeur reçoit un datagramme dont le TTL est nul, il le détruit et renvoie à l’expéditeur un message ICMP. Le but de ce champ est d’éviter les paquets fantômes qui circuleraient en boucle sur le réseau sans atteindre leur destination.

Pour la petite histoire, c’est de cette manière que fonctionne l’application traceroute. Lorsqu’on lance traceroute www.aldevar.fr, traceroute envoie un ping vers www.aldevar.fr avec un TTL de 1. Lorsque le premier routeur reçoit le paquet, il le détruit et renvoie à l’expediteur un message ICMP l’informant que le paquet a été détruit (time to live exceeded). Ce message ICMP contient dans son en-tête l’adresse IP du routeur. Suite à cela, traceroute recommence l’opération mais avec un TTL de 2 et ainsi de suite jusqu’à toucher www.aldevar.fr. Et c’est de cette manière qu’on obtient la route prise par notre paquet. Attention ceci dit car 2 paquets envoyés vers la même destination peuvent emprunter des routes différentes.

• Le 10ème octet sert à coder le protocole qui se trouve dans les données qui suivent l’en-tête. Il est codé sur 8 bits. Les protocoles les plus communs sont ICMP (0000.0001), TCP (0000.0110) et UDP (0001.0001).

• 11ème et 12ème octets : Le checksum. C’est la somme de contrôle de l’en-tête du datagramme. Chaque machine qui reçoit le paquet doit recalculer ce checksum car la modification du TTL modifie celui ci.

• Les octets 13 à 16 contiennent l’adresse IP de la machine émétrice. C’est également l’adresse de réponse.

• Et enfin les 4 derniers octets contiennent eux l’adresse IP de destination.

Capture de trame

Puisqu’il n’est pas particulièrement évident pour nous, simples mortels, de lire ces bits pour comprendre ce que contient le datagramme, on peut utiliser un logiciel de capture de trame tel que wireshark en mode graphique ou tcpdump en mode commande. Je vous laisse vous même découvrir ces applications. Je vais me contenter ici de montrer un screenshot d’une capture faite avec wireshark qui montre ce que ce logiciel peut nous dire sur le contenu de nos paquets.

Voici le type de paquet que nous avons capturé. C’est un simple ping entre 2 machines se situant sur des réseaux différents. Wireshark nous dit déjà que c’est un paquet ICMP. Voyons le détail de ce datagramme :

En dépliant le contenu de l’en-tête IP, voici ce que wireshark peut nous dire :

Nous sommes en IPv4.

Le header fait 20 octets (bytes et non bits).

La longueur total du datagramme est de 60 octets. On en conclue donc que nous avons 40 octets de données.

Le message n’est pas fragmenté.

Le TTL est de 128 ce qui signifie qu’après avoir traversé 128 routeurs, le paquet sera détruit.

Le protocole contenu dans les data est ICMP

Le checksum est correct.

Enfin, à la fin, les IP de départ et de destination.

Voilà, c’est terminé pour l’analyse de paquet de niveau 3. La prochaine fois, j’essaierai d’expliquer le contenu d’un en-tête  de niveau 4 (couche transport : UDP, TCP etc…) ou de niveau 2 (couche liaison, trame ethernet). Si vous trouvez que cet article manque de précision n’hésitez pas à m’en faire part.

Second opus de cette nouvelle catégorie d’article : QRQVB, la Question Réseau Qui Va Bien!

Arpès avoir expliqué ce qu’était une adresse IP dans la dernière QRQVB, je me suis rendu compte que plusieurs éléments étaient manquant pour une bonne compréhension de l’article. Et parmis ces éléments indispensables à la bonne compréhension des mécanismes des réseaux informatiques, il y a le modèle OSI (Open Systems Interconnexion).

Définition

Le modèle OSI est une norme définie par l’ISO pour permettre l’interconnexion des systèmes. Il propose un modèle d’architecture réseau afin de s’assurer que tous les systèmes interconnectés puissent communiquer entre eux quel que soit le constructeur du materiel. Les constructeurs informatiques ont proposé des architectures réseaux propres à leurs équipements. Par exemple, IBM a proposé SNA, DEC a proposé DNA… Ces architectures ont toutes le même défaut : du fait de leur caractère propriétaire, il n’est pas facile des les interconnecter, à moins d’un accord entre constructeurs.

Le modèle OSI ne précise pas vraiment les services et protocoles à utiliser pour chaque couches. Il décrit plutot ce que doivent faire ces couches. Je sais que ça ne parait pas très clair pour le moment, mais ça va le devenir.

Schéma du modèle

Le modèle OSI est donc représenté en 7 couches distinctes. J’ai ici représenté 2 machines (à gauche et à droite) pour bien montrer que lors de la communication de 2 hôtes, chaque couche ‘discute’ directement avec la couche équivalente de l’hôte d’en face.

1°) Couche Physique

La couche physique s’occupe de la transmission des bits de façon brute sur un canal de communication. Plus clairement, elle est typiquement représentée par votre carte réseau et sa prise ethernet (et non pas le protocole ethernet!!).

La couche phyique discute directement avec l’hôte suivant sur le réseau. C’est à dire que lors d’une communication sur internet, cette couche ne s’occupe de l’envoie des données que vers la machine suivante, en général un routeur.

La couche physique traite exclusivement avec des bits 0 et 1 et normalise l’écriture de ces bits (une tension de 5V corespond à un 1, -5V un 0).

2°) Couche Liaison

La couche de liaison (ou liaison de donnée)  est un liant entre les 2 couches physiques des hôtes en communications. Elle fractionne les données en trames et tente d’exempter la couche physique des erreurs de transmissions.  Elle doit être capable de renvoyer une trame lorsqu’il y a un problème sur la ligne et intègre également un système de gestion de flux pour éviter les engorgements. Par exemple une carte 100Mb/s relié à une carte 1Gb/S doivent pouvoir communiquer sans que la carte 100Mb/s recoive 10x trop de données.

L’unité d’information de cette couche est donc la trame qui est composé de quelques centaines d’octets.

3°) Couche Réseau

La couche réseau construit la liaison de bout en bout lors de la communication de 2 hôtes. C’est la seule couche directement concernée par la topologie du réseau. Elle va trouver la route parmis les routeurs pour atteindre l’hôte cible.

Lors d’un envoie de données, 2 paquets différents peuvent emprunter des routes différentes suivant l’architecture du réseau et ses point d’engorgement.

C’est la dernière couche supportée par TOUTES les machines du réseau (hôtes, switchs, routeurs, serveurs). Son unité d’information est le paquet.

4°) Couche Transport

Cette couche est responsable du bon acheminement des messages complets au destinataire. Le rôle principal de la couche transport est de prendre les messages de la couche session, de les découper s’il le faut en unités plus petites et de les passer à la couche réseau et inversement du coté du recepteur.

Comme on l’a vu dans la couche réseau, 2 paquets d’un même message peuvent prendre des routes différentes et donc arriver dans le désordre. Le rôle de la couche transport est donc de remettre ces paquets dans l’ordre. Elle peut aussi gérer le multiplexage lors de communications multiples entre 2 mêmes hôtes (par exemple une connexion http et ftp sur le même canal).

Son unité d’information est le message.

5°) Couche Session

Le service principale de la couche session est la synchronisation des communications. Qui veut parler? Qui parle? Elle permet aussi de prendre des ‘snapshots’ des flots de données pour pouvoir reprendre le dialogue là où il en était avant une coupure du canal de communication.

6°) Couche Présentation

La couche présentation est chargée du codage des données de la couche application. En effet, toutes les couches plus basses transportent des octets sans chercher comprendre leur signification. Ici, elle va s’occuper d’encoder du texte, des images, de la video, de la voix etc… en données transportables, c’est à dire en octet.

7°) Couche Application

Cette couche est le point de contact entre l’utilisateur et le réseau. Elle lui apporte l’interface lui permettant de communiquer avec celui ci (messagerie, http, ftp etc…).

Exemples de protocoles

1. Physique → biphase, bipolaire simple
2. Liaison → ATM, Ethernet, PPP, TokenRing, Fiber Distributed Date Interface (FDDI)
3. Réseau → IP, IPX, ICMP
4. Transport → TCP, UDP (pour les plus connus)
5. Session → SIP, Appletalk
6. Présentation → ASCII, Unicode, ASN.1, Videotex
7. Application → HTTP, SMTP, POP, FTP, DNS, SNMP

Source : Wikipedia, frameip, RFC

Dans cette nouvelle catégorie (la Question Réseau Qui Va Bien), je vous propose de (re)découvrir avec moi, quelques notions fondamentales de réseau. Ces articles s’adressent en particulier à ceux qui souhaitent comprendre les mécanismes d’Internet et/ou du routage en WAN ou en LAN. J’essaierai d’être le plus clair possible. Si vous trouvez des erreurs, non-sens dans ces articles, je suis ouvert à toutes critiques, corrections.
Et pour inaugurer cette catégorie, commençons donc par l’adresse IP.

Définition :

Une adresse IP identifie de manière unique une machine ainsi que le réseau sur lequel elle est située. Chaque adresse est une série de 4 octets dont une partie correspond à l’identificateur du réseau et l’autre partie à l’identificateur de la machine.
Exemple d’adresse IP : 172.19.174.125.

Concrètement, qu’est ce que cela signifie? En fait, puisque les machines ne savent traiter qu’avec des nombres binaires (0 ou 1) l’adresse est codée en binaire sur 4 octets. Sachant qu’un octet correspond à 8 bits, cela nous donne, pour chaque octet 256 possibilités (2^8) pour une valeur comprise en 0 et 255.

Allons un peu plus loin!

C’est bien sympa d’avoir une adresse, encore faut-il qu’on puisse m’y contacter! On vient de voir dans la définition que l’adresse IP est divisée en 2 sous parties : l’identificateur de réseau et l’identificateur d’hôte. C’est là qu’intervient le masque de réseau. Alors puisque je ne suis pas fort en blablatage, je vais plutôt vous montrer un exemple.
Voici une adresse IP : 192.168.1.15
Voici un masque de réseau : 255.255.255.0

En fait, pour être plus précis, les bits se situant dans la partie de l’identificateur réseau sont tous positionés sur 1 et les bits de la partie hôte sur 0. En procédant à une opération de ET logique entre l’adresse IP et le masque de réseau, on trouve l’adresse réseau. Les opérations de ET logique suivent cette règle :

0 ET 0 = 0
0 Et 1 = 0
1 ET 0 = 0
1 ET 1 = 1

Grâce à cette adresse réseau, un routeur pourra déterminer quel chemin doivent emprunter nos paquets IP. Pour bien comprendre ce système, nous allons jouer un peu avec le binaire, même si je sais que ça va en rebuter plus d’un :p

Ceci est important puisque c’est de cette manière qu’on va pouvoir déterminer le nombre maximal de machines qui peuvent appartenir à un réseau. Il faut également savoir que sur 1 réseau, 2 adresses sont réservées. L’adresse ‘bits hôte à 0′ car c’est elle qui va définir justement l’adresse de notre réseau, comme on vient de le voir, et l’adresse ‘bits hôte à 1′ car elle correspond à l’adresse de diffusion (broadcast). L’adresse de broadcast est nécéssaire pour diffuser un message sur tout le réseau. Le message de ce genre le plus classique est la requête ARP. Celle çi permet à une machine de trouver une autre machine sur le réseau en l’appelant.

Voici un exemple de capture de trame avec wireshark :

Le premier paquet est donc une requête ARP. La machine source envoie ce message sur tout le réseau : ‘who has 192.168.1.51?  Tell 192.168.1.25′. La machine qui a pour IP 192.168.1.51 envoie donc sa réponse directement à 192.168.1.15 et lui dit que c’est l’adresse MAC 00:0a:78:9e:8a qui possède cette IP. (Je me demande si j’aurais pas du expliquer les couches OSI avant!). Tout ça pour vous dire que l’adresse IP ‘bits hôte à 1′ est donc reservée pour ce type de message.

Dimensionnement de réseau

Puisque le masque de réseau détermine le nombre maximal de machines sur un réseau et que les adresses IP ne sont pas illimitées, on va pouvoir travailler sur le dimensionnement du réseau en modifiant le masque. En effet, il est possible d’emprunter des bits à la partie hôte pour les donner à la partie réseau. Par exemple, le masque 255.255.255.0 permet d’avoir 256-2 = 254 hôtes différents sur le même réseau. Hors, rares sont ceux qui disposent de 254 machines à interconnecter.

Admettons que mon réseau possède l’ip 192.168.1.0 (totalement au hasard!) de masque 255.255.255.0 . Je dispose de 5 machines à connecter sur ce réseau, jamais plus.

• Si je garde 1bit dans la partie hôte, je vais disposer de 2^1 = 2 hôtes possibles.  On vient de voir plus haut que 2 adresses sont reservées sur le réseau, (sisi, rapellez vous, juste au dessus!). Donc 2-2 = 0, ce qui me fait 0 hôte disponible.
• Si je garde 2 bits pour ma partie hôte, il va me rester (2^2)-2 = 2 hôtes possibles. Ce n’est toujours pas suffisant!!
• Si je garde 3 bits pour la partie hôtes, j’obtiens (3^2)-2 = 6 hôtes possibles. Ouf!! j’ai assez de place pour caser mes machines. On va donc construire notre masque de réseau en gardant ces 3 bits sur 0, ce qui nous donne :

11111111.11111111.11111111.11111    000
Partie réseau                                         Partie hôte
Ce qui, transformé en décimal nous donne un masque : 255.255.255.248.

Ce qu’on vient de faire ici, c’est de créer des sous réseaux du réseau 192.168.1.0. Plusieurs sous réseaux composé chacun de 8 adresses IP.

Sous réseau 1 : de 192.168.1.0 à 192.168.1.7 (avec 192.168.1.0 adresse de sous réseau et 192.168.1.7 adresse de broadcast)

Sous réseau 2 : de 192.168.1.8 (adresse du réseau) à 192.168.1.15 (adresse de broadcast)

Sous réseau 3 : de 192.168.1.16(adresse du réseau) à 192.168.1.23 (adresse de broadcast)

etc etc..

dernier sous réseau : de 192.168.1.248 (adresse de réseau) à 192.168.1.255 (adresse de broadcast)

Voilà donc ce qui se cache derrière les adresses IP. Plus mon sous réseau sera petit, moins j’aurais de broadcast sur ce réseau. Parce que mine de rien ça papote pas mal la dedans et ça a tendance à broadcaster dans tous les sens. Malheureusement, le broadcast n’est pas gratuit. Il coûte de la bande passante. Et quand la bande passante sature, on commence à perdre des paquets.

C’est pour ca qu’il est important, en entreprise en tout cas, de bien calculer le dimensionnement de son réseau et l’adressage IP de l’entreprise, sans oublier de prévoir que si l’entreprise s’agrandit, il va falloir rajouter des hôtes sur certains sous réseaux et en plus ajouter un nouveau sous réseau à notre entreprise pour y connecter un nouveau batiment par exemple. Ça a vite tendance à tourner cacahuète si on fait pas attention.

Voilà, j’espère que ce premier article sur les fondamentaux du réseau vous aura plus. Peut être même que certains y auront appris 2-3 trucs. Le prochain article de cette catégorie traitera a priori du modèle OSI, ou alors de TCP/IP… on verra.