[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux] Petite introduction à TCP/IP... (part 1)



Petite introduction à TCP/IP, pour ceux que ça intéresse...

(j'ai SIMPLIFIE, hein, commencez pas 50 mails en réponse sur les
petits détails qui n'intéressent pas nécessairement un débutant ;-)))
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> Grand merci, mais ...*hyper pas à pas* ;))

Oui, il faut vraiment passer d'une notion à l'autre, une à la fois.
Pas possible de comprendre p.ex. DNS ou NFS si on ne comprend pas TCP/IP.

> Exact ... et je suis déjà bloqué :
> 1) TCP/IP ==> si tu sais me rappeler en quelques phrases simples.

en quelques phrases simples ? :-)

euuuh... non, pas en qqes phrases simples ;-))

TCP/IP est un protocole réseau en couches:

  +-------------------+
4 | applicatif        |  DNS, FTP, HTTP, NFS, ...
  +-------------------+
3 | TCP ou UDP        |
  +-------------------+
2 | IP                |
  +-------------------+
1 | hardware          |  ethernet, token ring, wireless
  +-------------------+

Ce modèle en couches est aussi appelé "modèle UNIX": il en existe un
en 7 couches (le modèle "OSI" = Open Systems Interconnect) qui est
bcp plus complexe et qui n'est pas vraiment d'application.

Bon, en vitesse:

1) le niveau "hardware", c'est le niveau "électrique": pour ethernet,
    les signaux électriques envoyés par le cable - c'est implémenté
    dans la carte réseau

2) IP (Internet Protocol): c'est le niveau le plus intéressant car
    il définit la notion d'adresse IP (on s'en serait douté ;-)),
    d'adresses de réseaux IP (masque de sous-réseau), classes de
    réseaux IP (A/B/C/D), etc...

3) TCP ou UDP: ajoutent une couche de fonctionnalités sur la couche IP:
    - TCP permet d'assurer une communication: si j'envoie qqe chose par
      TCP/IP et que je reçois un "OK" de Linux, c'est que c'est bien arrivé
      = comparable à une communication téléphonique
    - UDP est plus rapide que TCP mais n'offre aucune garantie que ce que
      j'envoie est bien arrivé; c'est parfois intéressant pour certains
      types de protocoles non critiques
      = comparable à une lettre par la poste: je la mets dans la boîte,
        mais je ne sais pas si elle arrivera ou pas

4) niveau applicatif:
    Il existe une multitude de protocoles réseaux qui définissent des
    fonctions spécifiques - p.ex. POP ou IMAP pour lire des mails,
    SMTP pour envoyer des mails, FTP pour le transfert de fichiers,
    HTTP pour surfer sur le web, etc...

Dis-moi si il y a un truc pas clair là-dedans, c'est ESSENTIEL de comprendre ça.

Bon, il faut bien comprendre l'idée de couches:
lorsque dans mon browser (Galeon ;-)) je tape "http://unixtech.be/machin.php";,
voici ce qui se passe (très simplifié, hein ;-))):

browser -> envoit une requête via le protocole HTTP (qui est basé sur TCP/IP)
            au serveur dont le nom est "unixtech.be"

HTTP: - dans la requête HTTP il fait mis un truc comme "GET /machin.php"
         (entre autres ;-))
       - la couche HTTP "délègue" la gestion de la connexion et l'envoi de la
         requête à la couche TCP (note que c'est programmé dans le browser, qui va
         utiliser des fonctions pour faire du TCP (en C) mis à dispositions par
         Linux - ce sont les fameuses "sockets")
       - D'abord, on va voir l'ouverture de la connexion:

TCP: - la couche TCP (qui se trouve dans Linux) va tenter d'ouvrir une connexion vers
        le serveur (avant ça, il y aura eu une requête DNS qui a permis de récupérer
        l'adresse IP à partir du nom "unixtech.be" - je laisse cette étape-là de côté
        pour simplifier ;-)) - pour cela, TCP utilise la couche IP pour envoyer un
        message d'ouverture de connexion (propre au protocole TCP) à "unixtech.be"

IP:  - la couche IP (qui est également implémentée dans le kernel Linux) reçoit une
        adresse IP destination (celle de "unixtech.be") est des données à envoyer
        (la couche IP ne sait pas ce qu'est une ouverture de connexion TCP: elle est
        juste responsable pour envoyer les données à bon port), ce qu'elle fait.
        Pour cela, elle passe par la carte réseau et le protocole Ethernet

Ethernet: - je passe pour simplifier ;-)) -
           Retenons juste que la couche Ethernet va dire à la couche IP: "OK, c'est
           envoyé !" (elle ne dit pas si c'est arrivé, hein, juste que ça a été envoyé ;-))

IP: on remonte vers la couche IP qui sait que le signal électrique a bien pu être envoyé.
     Elle signale à la couche qui l'a appelé (TCP) que c'est OK.

TCP: TCP reçoit donc un "OK" de la couche IP.
      Maintenant, spécifique à la couche TCP car sa plus-value est d'assurer la connexion
      au sens vu ci-dessus: assurer que c'est arrivé à destination !
      Le seul moyen d'assurer que ce soit bien arrivé, c'est d'attendre que la machine-
      destination (unixtech.be) réponde à la demande de connexion qui vient d'être envoyée.
      Une fois qu'elle arrive, la couche TCP dit "OK" à la couche applicative (le protocole
      HTTP dans le browser).

      Ici, encore une fois, je simplifie, parce que l'établissement de la connexion via
      TCP est un peu plus compliquée et se fait en 3 phases. On appelle ça le "hand-shaking"
      (= "se serrer la main" ;-)) et permet de s'assurer que la connexion est *vraiment*
      établie et que les deux côtés sont prêts pour communiquer.

HTTP: OK, la connexion est ouverte. Maintenant, on va envoyer la requête proprement dite
       (le "GET /machin.php" et tout le reste).
       Pour cela, on passe de nouveau via TCP -> IP -> Ethernet -> IP -> TCP

C'est donc un système de délégation: chaque couche a sa responsabilité, ses capacités
et ses limitations... et donc sa plus-value par rapport à la couche qui se trouve
en-dessous.
Et chaque couche hérite des capacités de la couche se trouvant en-dessous.

> 2) Adresses IP ==> là, j'ai déjà de fausses notions.

Aïe ;-)


> Par ex. :
> * J'ai lu que chaque machine était répertoriée par une adresse de 4
> nombres (pourquoi 4 ?) *mais aussi* que chaque carte Ethernet
> avait son adresse, alors quoi et qui décide ?


Ben zut, j'espérais pouvoir simplifier et ne pas parler de la couche Ethernet ;-))

Bon: le protocole IP s'appelle en fait "IPv4" (IP version 4) et effectivement, les
adresses IP sont stoquées sur 4 nombres allant chacun de 0 à 255. Ce sont en fait
4 bytes (1 byte = 8 bits et peut avoir une valeur allant de 0 à 255, là je ne
t'apprends rien ;-)). Pq ? C'est comme ça, c'est tout ;-))
Il y a un nouveau protocole IP qui s'appelle "IPv6" (IP version 6) et qui utilise
6 bytes pour définir une adresse IP (donc 6 chiffres allant chacun de 0 à 255),
cela pour éviter qu'on se retrouve un jour avec une pénurie d'adresses IP (ce qui
est quasiment déjà le cas aujourd'hui).
Mais on va laisser IPv6 de côté, c'est encore plus compliqué ;-))
(note que Linux supporte déjà très bien l'IPv6 depuis belle lurette)

C'est pour cela qu'on note une adresse IP en 4 chiffres (0-255), que l'on sépare
par des points, p.ex.: 192.168.10.3 ou 10.10.1.7
C'est juste une notation/convention et ça permet directement de reconnaître
qu'il s'agit d'une adresse IP ;-)

Alors, pour le niveau éthernet:

effectivement, chaque carte réseau ethernet a sa propre adresse, qui n'est pas une
adresse IP (puisque c'est de l'ethernet ;-)) mais une adresse "ethernet", qu'on appelle
en fait la "MAC addresse" (me demande plus ce que c'est "MAC", y a trop longtemps ;-)).

Cette adresse est censée être unique au monde (donc chaque carte réseau a une adresse
MAC unique au monde - pas chaque modèle, chaque carte, hein ;-)).

Sous Linux, tu peux la voir en faisant "ifconfig" - c'est la valeur en hexa derrière
"HWaddr" (Hardware address), p.ex.:
HWaddr 00:50:DA:6E:B8:57

Ces adresses sont utilisées sur un réseau local (seul IP est capable de "router" et donc
d'interconnecter plusieurs réseaux physiques, p.ex. sur Internet) et sont donc totalement
inutilisables sur Internet - c'est pour ça qu'il y a IP ;-))

Sans vouloir entrer trop dans les détails, voici comment ça fonctionne entre la couche
IP et les adresses MAC - disons que tu fais un "telnet 192.168.0.1" (qui est une
machine dans ton LAN):

1) TCP: connexion sur l'IP 192.168.0.1 le port 23 (telnet):
   TCP va s'occuper de la gestion de la connexion, mais demande d'abord à IP d'envoyer
   un paquet de données de connexion (TCP) à la machine 192.168.0.1

2) IP: bon, lui il doit maintenant se débrouiller pour envoyer les données à la machine
   192.168.0.1. Pour ce faire, il va demander à la couche hardware (ethernet) d'envoyer
   les données... mais à qui ?

   Il y a un protocole qui se trouve entre IP et ethernet: ARP (Address Resolution
   Protocol) et qui sert justement à cela: la couche IP va faire envoyer une requête
   ARP sur le réseau, qui est un "broadcast" (càd qu'il est envoyé à TOUTES les machines
   se trouvant sur le réseau). Chaque machine sur le réseau reçoit donc cette requête
   ARP, qui dit (en gros): "qui a l'adresse IP 192.168.0.1 ?".
   La machine qui a effectivement cette adresse IP va envoyer une réponse en disant
   "c'est moi, ma MAC-adresse est 00:50:DA:6E:B8:57 !".
   Les autres machines vont voir que ce n'est pas leur adresse IP et simplement
   ignorer la demande.

3) Maintenant que la MAC-adresse de destination a été déterminée, on peut communiquer
   des données via la couche ethernet... :-)

Juste une dernière info complémentaire: le kernel Linux garde dans une mémoire-cache
les adresses MAC qui ont déjà été résolues via ARP, ce qui évite de devoir redemander
à chaque fois.
Tu peux voir ce qu'il y a dans le cache avec la commande suivante:

  cat /proc/net/arp

ce qui donne p.ex.:

IP address       HW type     Flags       HW address            Mask     Device
192.168.41.42    0x1         0x2         00:02:B3:2D:3B:64     *        eth0
192.168.41.151   0x1         0x2         00:D0:B7:18:3B:E5     *        eth0
192.168.41.27    0x1         0x2         00:50:8B:5F:12:38     *        eth0
192.168.41.85    0x1         0x2         00:D0:B7:5A:BD:7D     *        eth0

Mais je le répète: les adresses MAC, ça n'a d'importance que sur un réseau local.
Sur Internet, on se fout complètement des adresses MAC...
C'est IP qui joue...

> * J'ai lu aussi qu'il y avait 4 classes de réseau.
> Pourquoi + réservé à qui + qui décide ?

Celui-là, je te répondrai plus tard ;-)

> 3) Masques réseau : J'ai remarqué que c'était une "série" de 255 avec
> un 0 quelque part, mais je n'ai *aucune idée de ce que c'est* !!

Pas nécessairement des 255 et des 0, mais généralement.
C'est un masque de bits appliqué pour déterminer l'adresse du réseau IP.
C'est essentiel pour le routage...

Celui-là aussi, pour une prochaine fois ;-)

> 4) Les ports : aucune idée !!

Oui, ça c'est assez simple.

Bon, une machine est déterminée de manière unique par une adresse IP, ça on est
d'accord. Mais une machine offre aussi plusieurs "services" réseau: HTTP, FTP,
NFS, DNS, POP, IMAP, SMTP, telnet, SSH, ...

Il nous faut donc un système de multiplexage pour pouvoir dire:
"le service telnet sur la machine 192.168.0.1"

Et bien ce sont justement les ports: ce sont des numéros qui ont un nom symbolique
(p.ex. "telnet", "smtp") - tu trouves la table d'équivalence des noms vers les
numéros dans le fichier (texte) /etc/services - et qui déterminent le service
à contacter sur la machine.

Ces numéros sont standardisés et bien définis.

> 5) Le routage : je sais *vaguement* que c'est une sorte d'aiguillage,
> mais à part ça = ?????

Ouaip, c'est exactement ça en fait ;-))

Je te l'expliquerai en détail une prochaine fois, faudra d'abord se farcir
les masques de réseau pour bien comprendre...

> Je crois que c'est assez pour bien assimiler le début ... et d'abord
> pour toi de me l'expliquer ;))

PS: je l'envoie en copie sur la liste, ça pourrait être intéressant pour d'autres
    personnes...

Je crois que je vais encore un peu le perfectionner et le mettre sur mon site ;-))

--
   -o) Pascal Bleser   ATOS Origin/Aachen(DE) |
   /\\         <pascal.bleser@atosorigin.com> |
  _\_v <guru@linuxbe.org>                     |
----------------------------------------------|
Jesus saves,Buddha makes incremental backups  :
----------------------------------------------'


_______________________________________________
Linux Mailing List
Archives: http://unixtech.be/mailman/listinfo/linux