Les Forums

Les Forums

Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

Poser le problème et tenter de la structurer

Bonjour,

je poursuis un mythe qui est le suivant :

1 Je comprendrais comment est traité un message de bout en bout, par exemple :
Un email du logiciel d'émission au logiciel de réception
une page HTML depuis le serveur jusqu'à l'écran du visiteur
un fichier depuis son émission par mon PC jusqu'à sa réception par le PC de l'interlocuteur

2 je mettrais cela en forme et je tenterais de l'expliquer à des zozos comme moi, des amateurs qui ont envie de ne pas naviguer idiots


Mais il faut commencer par poser des questions obligatoirement idiotes et je commence par la première :

quand j'envoie un email, mon Firefox découpe ce message (on n'entre pas dans la conversion MIME, ) en tranches
Dimension de la tranche ?

La tranche de données est encadrée par un en-tête qui contient au minimum l'adresse de l'émetteur (le port de Firefox ?) et l'adresse du destinataire (sous forme XXXX@YYYY.fr ?) et un en-queue qui contient la checksum
Puis, cette tranche passe dans la carte réseau, où une petite addition est faite en rajoutant l'adresse MAC (la carte réseau Ethernet n'en sais pas plus, je suppose)

Puis la tranche passe dans le routeur (la NAT) et l'adresse passe d'adresse locale en adresse Internet (ou bien l'adresse Internet est rajoutée par-dessus l'adresse locale ?)
Tout cela en protocole SMTP (qui intervient sur quel élement de la tranche ?)

Puis la tranche arrive dans le serveur SMTP du FAI, puis dans le serveur POP de l'autre FAI... (serveur-serveur, c'est pas notre truc.... on laisse tomber)

A partir du serveur POP destinataire on est en protocole POP... ça a changé quoi et qui a changé ça ?
Il semble évident que les données contenues dans la tranche n'ont pas changées, elles

Et la tranche continue sa route dans le PC destinataire, routeur, carte-réseau (pas obligatoirement Ethernet)
Maintenant, il va falloir "recoller les tranches" qui fait cela, le logiciel destinataire ? (on vient d'oublier le port du destinataire...) vérifier que TOUTES les tranches sont là (donc elles sont numérotées et quelque part on dit combien il y en a...)

Ca semble confus aux pointures de FrameIP ?
Mais c'est encore plus confus dans nos cerveaux embrumés de nous, les nullos.

Comme d'habitude, plus on en est au début, plus c'est difficile de débroussailler, quand ça a démarré, ça devient plus limpide

C'est ça mon mythe, aider les nullos à démarrer (il y a plus d'un an que je rame et je n'ai toujours pas démarré... je ne dois pas être le seul, si on tient compte des timides qui viennent sur le forum pour tenter d'apprendre quelque chose, mais qui ne se manifestent pas...ma grande gueule m'aura au moins permit de poser le problème)


Pas simple

Les rudiments de démarrage ci-dessus vont nécessiter 20 messages, et va falloir trier.... on n'est pas couchés...

Conclusion : ce message est uniquement destiné à poser le problème et non à poser des questions techniques, qui, à mon sens, doivent rester simples et le fil de discussion aussi bref que possible, et les fils de discussion se succéder


Merci
[code:1:26aa9a6296]quand j'envoie un email, mon Firefox découpe ce message (on n'entre pas dans la conversion MIME, restons ELEMENTAIRES) en tranches
Dimension de la tranche ? [/code:1:26aa9a6296]

Un envoi de mail n'est pas le plus simple à expliquer, prenons plutôt l'envoi d'une requête pour consulter un serveur web.

Pour comprendre il faut décomposer les mécanismes.

Firefox n'envoie pas de mail, c'est un navigateur web, un logiciel «client web». Firefox envoie des requêtes HTTP pour consulter des pages web stockées sur un serveur web utilisant un logiciel serveur, exemple Apache. Un serveur web écoute les requêtes sur le port TCP 80 (par défaut).

Lorsque tu saisis l'url www.test.maison dans ton navigateur web, cela sous-entend http://www.test.maison/index.html , il va en découler une succession d'actions avant que la page ne s'affiche sur ton navigateur.

Chaque étape doit être détaillée dans l'ordre si possible pour bien comprendre. Ce n'est pas facile à rédiger, le mieux est de décomposer le tout sur un réseau simple (sans routeur, sans nat) pour commencer.
Et bien sûr, avec des schémas (sinon ce ne sera pas plus clair).

Ensuite, en rajoutant des éléments (routeur, puis nat) cela sera plus facile à comprendre. Viendra après l'explication des autres services, par exemple le mail... mais ce sera pour plus tard 😉

Restons simple. Un même réseau IP (10.0.0.0 /8) pour les 3 machines sur un réseau ethernet.
- Un serveur DNS (logiciel «bind») écoute les requêtes sur le port 53 de UDP.
- Un serveur Web (logiciel «apache») écoute les requêtes sur le port 80 de TCP.
- Une station souhaitant consulter le serveur Web avec son navigateur Firefox.

Au préalable, il faudrait connaître l'empilement TCP/IP. Voici les encapsulations protocolaires possible pour le schéma :

HTTP repose sur TCP qui repose sur IP qui repose sur Ethernet
DNS repose sur UDP qui repose sur IP qui repose sur Ethernet
ARP repose sur Ethernet

En s'appuyant sur ce schéma :
http://zenith.noel.free.fr/frameip/echange-frameip.png


étape 0: l'utilisateur de la station ouvre Firefox et saisit l'url http://www.test.maison

la station1 doit récupérer l'adresse IP associée à ce nom pour formater le paquet IP. Elle va donc contacter le serveur DNS.
Pour contacter le DNS, il faut pouvoir lui envoyer la requête DNS dans une trame qui lui sera adressée (adresse MAC). Encore faut-il connaître cette adresse MAC.
Les équipements réseaux utilisent un cache arp dans lequel figurent ces valeurs, mais ce cache est dynamique et se vide régulièrement. Je partirais du principe que les caches sont vides pour retracer toutes les étapes.

étape 1: Récupérer l'adresse mac du DNS par l'émission d'une requête ARP. Cette requête est encapsulées dans une trame ethenet et est adressée à tous les hôtes du LAN. (adresse mac destination FF-FF-FF-FF-FF-FF). C'est un broadcast. Seul l'intéressé répondra. Le contenu de la trame ARP est le suivant :

Quelle est l'adresse mac de 10.0.0.10 ? Je suis 10.0.0.11 d'adresse mac B.


étape 2: Tous les hôtes reçoivent cette requête mais seul celui d'adresse 10.0.0.10 répond. Les autres se disent «cela ne me concerne pas». Du coup, le serveur répond à B en unicast (adresse mac destination B) en disant :

C'est moi 10.0.0.10, j'ai l'adresse mac A. Je m'adresse à 10.0.0.11 d'adresse mac B.


étape 3: La station 1 est contente, elle a l'adresse mac A associée à 10.0.0.1 dans son cache ARP. Elle peut maintenant adresser la requête DNS au serveur en disant :

Peux-tu me dire quelle est l'adresse IP de www.test.maison ?

Cette requête est encapsulée dans UDP avec le port destination 53 et un port source non occupé à l'instant T et ce, alloué dynamiquement. Ce port source aura une valeur supérieure à 1023, disons 1030 pour l'exemple.

Ce datagramme UDP est également encapsulé dans IP, avec l'adresse IP destination 10.0.0.10 et l'adresse IP source 10.0.0.11.

Ce datagramme IP est finalement dans Ethernet, avec l'adresse mac destination A et l'adresse Mac Source B.

la trame est émise.

étape 4: Le serveur DNS traite la requête et répond à la station à en disant :

C'est l'adresse 10.0.0.12 qui correspond à www.test.maison.

Ce mesage DNS est encapsulé dans UDP avec port destination 1030 et port source 53. C'est inversé par rapport à la requête.

Idem, UDP est encapsulé dans IP (adresse destination 10.0.0.11, adresse source 10.0.0.10)
Idem, IP est encapsué dans Ethernet (mac destination B, mac Source A)

Maintenant que la station1 connaît l'adresse IP de www.test.maison , elle va pouvoir envoyer la requête HTTP au serveur Web.

étape 5: Pour envoyer la requête HTTP, il faut formater une trame et l'adresser au serveur. Encore faut-il connaître l'adresse mac du serveur. Même principe qu'à l'étape 1, une requête arp est émise en broadcast sur le réseau:

Quelle est l'adresse mac de 10.0.0.12 ? Je suis 10.0.0.11 d'adresse mac B.

étape 6: Le serveur répond en unicast :

C'est moi 10.0.0.12 qui a l'adresse mac C en réponse à 10.0.0.11 d'adresse mac B.

B remplit son cache arp avec cette information et peut maintenant émettre la requête HTTP.

Il faut savoir que si on utilise un protocole qui repose sur TCP, c'est le cas de HTTP, les échanges passeront forcément par 3 phases. Connexion TCP, Transfert (ici, HTTP), Déconnexion TCP.
À noter que pendant la phase de connexion et de déconnexion, il n'y a pas de message HTTP encapsulé dans TCP.

étape 7: Demande de connexion TCP au serveur
La demande de connexion TCP se fait avec l'activation d'un bit marqué à 1, le bit SYN.
Le segment de connexion TCP (bit syn=1) est émis :
Port destination 80
Port source (au delà de 1023), admettons 1031
et est encapsulé dans IP :
adresse destination 10.0.0.12
adresse source 10.0.0.11
puis encapsulé dans Ethernet :
adresse mac destination C
adresse mac source B

étape 8: Acquittement de connexion TCP du serveur et demande de connexion TCP à la station 1
le bit ack et syn sont tous les deux à 1
Pour les ports et les adresses, les valeurs sont inversées par rapport à la requête.

étape 9: Acquittement de la demande de connexion TCP du serveur
le bit ack est à 1
Pour les ports et les adresses, les valeurs sont identiques à l'étape 7.

étape 10: Émission de la requête HTTP
message HTTP de demande de la page web index.html
Pour les ports et les adresses, les valeurs sont identiques à l'étape 7.

étape 11: Émission de la page web HTTP
message HTTP envoie de la page web index.html
Pour les ports et les adresses, les valeurs sont inversées par rapport l'étape 7.

étape 12: Acquittement HTTP
Segment TCP pour acquitter
Pour les ports et les adresses, les valeurs sont identiques à l'étape 7

étape 13: Demande de déconnexion TCP au serveur
Pour les ports et les adresses, les valeurs sont identiques à l'étape 7

étape 14: Acquittement de la demande de déconnexion TCP du serveur
Pour les ports et les adresses, les valeurs sont inversées par rapport l'étape 7.

étape 15: Demande de déconnexion TCP à station 1
Pour les ports et les adresses, les valeurs sont inversées par rapport l'étape 7.

étape 16: Acquittement de la demande de déconnexion TCP de station 1
Pour les ports et les adresses, les valeurs sont identiques à l'étape 7


C'est fini, à chaque consultation de page web sur ce serveur, les phases de connexion, transfert, déconnexion TCP se dérouleront.

La suite via un routeur, une autre fois 😉

nono[url][code:1:26aa9a6296][/code:1:26aa9a6296][/url]
Encore des erreurs 😈

Correctif:

Lire :
Restons simple. Un même réseau IP pour les 3 machines sur un réseau ethernet.

étape 3, lire:

étape 3: La station 1 est contente, elle a l'adresse mac A associée à dans son cache ARP. Elle peut maintenant adresser la requête DNS au serveur en disant :

Peux-tu me dire quelle est l'adresse IP de www.test.maison ?

... et corriger les quelques coquilles orthographiques sur le reste du texte. J'en ai trouvé en me relisant 😳

nono

Houla houla, quand tu envoies cette requête, tu envoies un GET / sans préciser ce qui va derrière. C'est le serveur avec son directoryindex qui va interprêter cela en index.html, index.php ou autre.

Chaque étape doit être détaillée dans l'ordre si possible pour bien comprendre. Ce n'est pas facile à rédiger, le mieux est de décomposer le tout sur un réseau simple (sans routeur, sans nat) pour commencer.
Et bien sûr, avec des schémas (sinon ce ne sera pas plus clair).
C'est une bonne idée, un schéma est souvent plus parlant qu'un long discours. Attention quand même, il y a beaucoup beaucoup de boulot je pense !

la station1 doit récupérer l'adresse IP associée à ce nom pour formater le paquet IP. Elle va donc contacter le serveur DNS.
Pour contacter le DNS, il faut pouvoir lui envoyer la requête DNS dans une trame qui lui sera adressée (adresse MAC). Encore faut-il connaître cette adresse MAC.
Houla encore 🙂
Ca va bien vite, pour ce genre d'exercice il faut je pense en permanence se poser les questions "comment ? et pourquoi ?"
Ici notamment, pourquoi veut-on résoudre le nom ? comment connais-je l'adresse des serveurs DNS ? pourquoi fais-je une requête ARP ?
C'est en étant confronté à ces questions posées par les élèves que j'ai appris au fur et à mesure à mieux comprendre les mécanismes que je croyais connaître, et à essayer de les expliquer plus en profondeur.

C'est là où l'exercice peut être intéressant, socaanayo pose ses questions en essayant de tout comprendre dans le moindre détail, et tu lui apportes les réponses au fur et à mesure.

J'ai pas trop le temps de tout lire, mais une fois le document avancé je pourrai le relire et y apporter mes questions si vous le souhaitez.
Bonjour
Eric écrit

Cela résume ce que sont mes intentions
Qu'il y ait un boulot considérable, ce n'est pas ce qui m'effraie
Ce qui m'effraie c'est le temps qui me reste pour le faire (75 berges aux dernieres prunes)


, c'est ma question permanente
: non, sonder les intentions des RFC c'est au-dela de mon but


: je pose les questions au fur et on me répond (peut-être) à mesure 😀
Je comprend les choses (assez peu important) et je le met en forme pour que les nullos comme moi comprennent (essentiel)

Merci à vous tous