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

[linux] Petite introduction à TCP/IP... - part 1.1



La suite de la discussion avec qqes précisions:

(au fait, ça intéresse qqn ? sinon je continue en privé... non ?)
----------------------------------------------------------------------------

Avant de t'expliquer (ça me fait un peu rigoler !!) comment j'ai
compris TCP/IP, je voudrais que tu rectifies certaines définitions :
* Protocole = Règles qui régissent les échanges en télé-communications.
Oui. Pour que les deux côtés (client et serveur) puissent se comprendre ;-)


* Implémenter = Activer quelque chose.
Hmmm... non, pas vraiment.
"Implémenter" une fonctionnalité = "programmer" une fonctionnalité


* Multiplexage = Regrouper les signaux venant de différentes sources
en 1 seul signal.
Oui.
Le mot n'était peut-être pas si bien choisi... quoique...

Voilà ce que je voulais dire, en fait:

                                          +-------------+
+------+                               /--]HTTP         |
|      |                              /---]FTP          |
|client|=========(Internet)==========<----]DNS  serveur |
|      |                              \---]SMTP         |
+------|                               \--]POP          |

                                         +-------------+


Tout passe par un seul "canal" de communication: TCP.

En fait, chaque couche ajoute des informations supplémentaires au données
proprement dites sous forme de données en entête et à la fin des données
(de la couche applicative) à véhiculer:

(je simplifie ;-))

    HTTP      [==========]    la requête HTTP
     ||
     \/
     TCP   [*][==========]    TCP ajoute son entête
     ||
     \/
     IP [+][*][==========]    IP ajoute son entête
    ...

L'en-tête IP contient notamment l'adresse IP de la destination et l'adresse
IP de la source (toi ;-)). Ce ne sont pas des données proprement dites, qui
font partie de la requête HTTP, mais des informations que la couche en
question ajoute et dont elle a besoin pour pouvoir remplir ses fonctionnalités.

Les paquets TCP/IP contiennent également dans leurs entêtes le numéro de port
de la destination, qui permet en fait d'identifier la couche applicative,
du moins sur le serveur: une requête HTTP utilise le numéro de port du protocole
http (80). Note que c'est pas obligé, mais c'est le principe ;-)

Par "multiplexage", je voulais dire que via l'adresse IP (qui ne constitue qu'une
seule information) tu peux contacter plusieurs services sur un serveur,
l'information supplémentaire (*quel* service) étant donnée par le numéro de port
à contacter sur le serveur.


* LAN = Intranet ??
Oui: Local Area Network. Un "réseau local". Bref, interconnecté par un
câblage genre RJ-45 - au contraire d'Internet.


* Extranet = Internet ??
Mmmmmmmoui, presque:
extranet est plutôt utilisé pour signifier un réseau interne mais qui
sort du "câblage normal" et qui passe par des lignes louées, etc...
- cf. ci-dessous.


* Dans une entreprise, il y a des réseaux LAN, mais imaginons une
multinationale qui a des sièges partout.  Comment communiquent-ils ?
Il y a plusieurs possibilités:
- soit par Internet, généralement via des communications sécurisées
  (p.ex. via encryption)
- soit par des lignes louées, un intranet mais via des lignes
  téléphoniques ou digitales privées
C'est presque tjs la 2ème solution qui est préconisée, vu que si ça
passe par Internet, il y a pas mal de risques de sécurité.

C'est ce genre de connexion qu'on appele plutôt "extranet".


Pour avoir accès au Net ou à ma messagerie, j'ai besoin d'un provider,
d'un browser, d'un "moyen de connexion = ADSL ... et de Linux ;)

1) Je veux me connecter à linuxbe.org via le protocole HTTP.
C'est la couche applicative qui envoie une requête au serveur du nom
de domaine.

J'avais exprès laissé de côté l'aspect résolution de noms (DNS) pour ne
pas compliquer encore plus mais c'est effectivement une composante très
importante.
Note que si dans ton browser, tu tapes

http://194.78.245.22

ça peut marcher aussi, hein ;-)
Il n'y a alors pas de résolution de noms puisqu'on donne de suite l'adresse
IP.

Mais http est un peu spécial parce que bcp de serveur web (dont linuxbe)
fait ce qu'on appelle du "virtual hosting" (ou "multi-hosting"):
On a une seule machine, une seule adresse IP, mais d'après le NOM via lequel
on accède au serveur web sur cette machine, on reçoit d'autres pages HTML
en retour.
Note que ça ne marche qu'avec quelques protocoles, dont HTTP, parce que le
browser envoit le nom de la machine utilisé dans la requête à l'intérieur
de la requête HTTP même (des données envoyées dans la requête, si tu veux),
ce qui permet au serveur web de savoir via quel nom il est contacté.

Si tu vas sur http://unixtech.be, http://opentech.be ou http://guru.unixtech.be,
ce sont des sites différents mais c'est la même machine...

Bon, je reviens à ton 1).

En fait, la résolution du nom est faite par une librairie réseau intégrée à
Linux (mais bon, ça revient au même ;-)).
Dans cette vue en couches, c'est effectivement la couche applicative qui doit
se charger de d'abord faire la résolution de noms: DNS étant lui-même dans la
couche applicative, la résolution de noms n'est pas prise en charge automatiquement
par la couche TCP ou IP (et certainement pas ethernet ;-)).


2) TCP prend en compte la gestion de la connexion et lance une requête
au serveur DNS pour obtenir l'adresse IP.

DNS est un protocole qui fonctionne via TCP ou UDP. On utilise généralement UDP,
c'est plus rapide. Mais prenons l'exemple via TCP:

Quand l'application (p.ex. un browser) demande à résoudre un nom de machine
via DNS, c'est effectivement TCP qui se charge d'ouvrir et d'assurer la
connexion au serveur de noms (qui est renseigné dans /etc/resolv.conf sous
Linux et que tu peux configurer via YaST ;-)).
Note que c'est pour cela que le ou les serveur(s) de noms doivent être
renseignés via leur adresse IP ! Forcément, c'est l'histoire de la poule
et de l'oeuf ;-).

Mais la résolution de nom proprement dite - le protocole spécifique à DNS,
quoi - est sur la couche applicative.

3) C'est IP qui reçoit l'adresse et délègue l'envoi à la couche Ethernet.
Oui.


4) Ethernet dit à IP "c'est envoyé... sans savoir si c'est arrivé"
Exact.


5) IP sait donc que l'envoi a été fait et le signale à TCP.
Tjs correct.


6) TCP assure la connexion et attend un "signal" en réponse.
C'est tout-à-fait ça. TCP attend de la part de "l'autre côté" une
confirmation de connexion.
La couche TCP du client (toi) et du serveur s'échangent comme cela
2 ou 3 messages pour bien s'assurer que la connexion est OK (c'est ce
fameux "hand-shaking", mais on va pas entrer dans les détails, ça n'a
pas bcp d'importance).

Quand ça a bien fonctionné, la couche TCP signale à la couche applicative:
OK, la connexion a marché.


7) Il peut alors dire à la couche applicative que c'est OK et que
l'échange avec linuxbe.org peut commencer.
Oui. La couche applicative (HTTP dans ce cas) peut envoyer sa requête HTTP
à linuxbe.org (sur le port spécifique à HTTP: 80).

Là, le serveur web (qui écoute sur le port 80) va recevoir la requête

HTTP et répondre en conséquence, normalement en t'envoyant le contenu du
fichier index.html qui se trouve dans le répertoire approprié.

(pour linuxbe.org, c'est du PHP, ce qui complique légèrement l'affaire,
mais on va pas parler de ça pour l'instant ;-)).


NE RIGOLE PAS COMME CA ;))
Pas du tout, t'as tout compris ;-)

Comme tu as vu juste, j'envoie une copie sur la liste ;-))


--
  -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