Vous êtes sur la page 1sur 11

1. Historique.

1957 : lié à la guerre froide entre l’URSS et les US, le président américain Eisenhower décide
la création de l’ARPA (Advanced Research Projects Agency) au sein de la défense nationale
américaine. Un des enjeux de départ de l’ARPA est la mise en place d’un réseau informatique
basé notamment sur les lignes téléphoniques existantes.

1962 : le projet ARPA net est lancé et en 1968, le premier protocole IMP (Interface Message
Protocole) est lancé. En 1968, deux ordinateurs étaient interconnectés entre les campus des
universités de l’UCLA et Stanford.

1972 : Sortie du premier protocole permettant l’échange de courriers électroniques et


présentation d’ARPANET au grand public.

1973 : chaque ordinateur sur le réseau se voit attribuer une adresse unique appelée adresse IP.
Le protocole TCP/IP était né.

1975 : fondation de la société Microsoft.

1981 : la société IBM sort son premier ordinateur personnel ( PC ) avec comme système
d’exploitation le DOS

1983 : Unix intègre le protocole TCP/IP dans sa version Berkeley 4.2. ARPANET adopte
également ce protocole.

1984 : le protocole DNS émerge.

1985 : Introduction de TCP/IP au CERN. Sortie de la version Windows 1.0

1986 : NSF (National Foundation Science) adopte TCP/IP pour son réseau NFSNET.

1990 : Sortie de Windows 3.1. NFS et ARPANET fusionnent, ce qui va donner naissance à
Internet.

1992 : Le CERN propose le projet World Wide Web. Microsoft sort sa version 3.11
comprenant des fonctionnalités réseau (netbeui). On pouvait également installer en option le
protocole TCP/IP.

1993 : NCSA sort Mosaïc.

1994 : Netscape 1.0.

1995 : Internet Explorer 2.0.

2. Les protocoles TCP/IP.

2.1. Introduction
TCP/IP désigne habituellement une suite de protocoles utilisés dans une architecture
réseau. TCP/IP est au niveau du nom l’association entre les deux protocoles que sont IP
(Internet Protocol) et TCP qui est un protocole de transport correspondant à l’abréviation
de Transmission Control Protocol.
TCP/IP se présente sous la forme d’une architecture réseau en couches.

Chaque couche a l’impression de communiquer avec la couche de même niveau de


l’ordinateur distant. Lorsque vous utiliser votre navigateur pour accéder à un site web, votre
navigateur se soucie très peu de savoir le type de support physique avec lequel vous travaillez
et la façon dont les signaux vont être représentés électriquement. Chaque couche travaillera
uniquement avec la couche qui lui est juste inférieure ou supérieure.
Dans le cadre de cette introduction à TCP/IP, nous aborderons la couche IP, quelques notions
pour la couche transport ainsi qu’un descriptif de quelques protocoles applicatifs entre autres
DNS.
2.2. Le protocole IP (IP v4)

Chaque adresse IP est codée sur 32 bits, ce qui nous permet d’envisager 4294967296
possibilités. Vue l’extension d’internet et du nombre d’ordinateurs connectés le protocole
IP a évolué et chaque adresse est maintenant codée sur 128 bits dans sa version appelée
IPV6. Nous nous limiterons à une approche succincte d’IPv4, une étude plus approfondie
étant réalisée en deuxième année.

L’adresse IP constituée de 32 bits est représentée sur une forme décimale pointée :
192.168.13.20. Chacun des quatre chiffres peut prendre une valeur comprise entre 0 et 255
(4 x 8bits). Il est maintenant important de déterminer la partie de l’adresse IP qui
renseigne l’adresse du réseau et la partie renseignant l’adresse de l’hôte dans ce réseau.
Ceci est possible en utilisant le masque de sous réseau. Le masque de sous réseau est fort
analogue à l’adresse IP dans le sens où elle est composée de 32 bits présentés sous la
même forme.

Exemple : Adresse IP 192.168.13.20 Masque de sous réseau 255.255.255.0

Les bits à ‘1’ dans le masque de sous réseau mettent en évidence les bits correspondants
de l’adresse IP étant utilisés pour identifier l’adresse du réseau. Une première approche fut
d’associer automatiquement le masque à l’adresse IP en fonction de la classe à laquelle
appartient l’adresse IP.

Dans la classe A, le masque de sous réseau est 255.0.0.0. Les adresses IP peuvent varier
de 1.0.0.0 à 127.255.255.255. Dans une telle classe, nous pouvons avoir 127 réseaux et
dans chacun des réseaux 16777216-2 hôtes

Dans la classe B, le masque de sous réseau est 255.255.0.0. Les adresses IP peuvent varier
de 128.0.0.0 à 191.255.255.255. Dans une telle classe, nous pouvons avoir 16384 réseaux
et dans chacun des réseaux 65536-2 hôtes

Dans la classe C, le masque de sous réseau est 255.255.255.0. Les adresses IP peuvent
varier de l’adresse 192.0.0.0 à 223.255.255.255. Dans une telle classe, nous pouvons avoir
2097152 réseaux et dans chacun des réseaux 256-2 hôtes.

Si nous considérons l’adresse 192.168.13.20, elle fait partie de la classe C et de ce fait,


son masque de sous réseau par défaut est donc 255.255.255.0.

Un des aspects négatifs de cette classification des adresses est que l’on va certainement
retrouver un gaspillage des adresses dans le sens que certaines sociétés disposent
d’adresses de classe B sans nécessairement avoir 65534 hôtes dans leur réseau. C’est la
raison pour laquelle, afin de pouvoir servir tout le monde, l’on a abandonné ce lien
systématique entre classe d’adresse et masque de sous réseau pour se retrouver en
classless. La notion de ‘classless’ est de pouvoir travailler avec des masques plus
restrictifs que le masque associée à la classe d’adresse.
Exemple : l’adresse 10.0.0.0 qui est une adresse de classe A ayant comme masque par
défaut 255.0.0.0 peut très bien être utilisée avec le masque 255.255.255.0.

Soit l’adresse du réseau 193.191.131.0. Cette adresse est de classe C et est donc associée
au masque de sous réseau 255.255.255.0.
Le masque réel utilisé avec cette adresse est 255.255.255.224. Elle correspond à
l’information binaire suivante : 11111111.11111111.11111111.11100000

Jusqu’à présent il était facile de déterminer le nombre d’hôtes présents dans un sous
réseau du fait que les masques étaient constitués de chiffres valant soit 0 soit 255.
Comment va-t-on pouvoir effectuer cette même démarche avec le masque renseigné ci
avant ?

Si l’adresse de réseau est 193.191.131.0, elle correspond à l’information binaire suivante :

11000001.10111111.10000011.00000000
193 . 191 . 131 . 0

En gras, nous retrouvons le numéro du réseau. De ce fait, nous pouvons facilement obtenir
le numéro le plus grand pour l’hôte.

11000001.10111111.10000011.00011111
193 . 191 . 131 . 31

Pour le sous réseau associé à ce masque, nous retrouvons donc 32 adresses IP dont la
première est l’adresse du réseau et la dernière l’adresse de broadcast de domaine qui
permet d’envoyer le même paquet à l’ensemble des hôtes du même réseau. Cette dernière
adresse ne peut pas être attribuée à un hôte particulier. Si nous poussons un peu plus loin
notre démarche, nous pourrions pour la classe d’adresse donnée, calculer les différents
sous réseaux que l’on pourrait constituer sur base du masque plus restrictif. Il est
facilement calculable que si le masque natif permet d’obtenir 256 adresses différentes,
nous retrouverons 8 sous réseaux dont le masque serait 255.255.255.224.

11000001.10111111.10000011.00000000 --- 11000001.10111111.10000011.00011111


193 . 191 . 131 . 0 --- 193 . 191 . 131 . 31

11000001.10111111.10000011.00100000 --- 11000001.10111111.10000011.00111111


193 . 191 . 131 . 32 --- 193 . 191 . 131 . 63

11000001.10111111.10000011.01000000 --- 11000001.10111111.10000011.01011111


193 . 191 . 131 . 64 --- 193 . 191 . 131 . 95

11000001.10111111.10000011.01100000 --- 11000001.10111111.10000011.01111111


193 . 191 . 131 . 96 --- 193 . 191 . 131 . 127

11000001.10111111.10000011.10000000 --- 11000001.10111111.10000011.10011111


193 . 191 . 131 . 128 --- 193 . 191 . 131 . 159

11000001.10111111.10000011.10100000 --- 11000001.10111111.10000011.10111111


193 . 191 . 131 . 160 --- 193 . 191 . 131 . 191

11000001.10111111.10000011.11000000 --- 11000001.10111111.10000011.11011111


193 . 191 . 131 . 192 --- 193 . 191 . 131 . 223
11000001.10111111.10000011.11100000 --- 11000001.10111111.10000011.11111111
193 . 191 . 131 . 224 --- 193 . 191 . 131 . 255

Une autre façon de représenter les adresses IP est d’indiquer le nombre de bits successifs à
1 que l’on retrouve dans le masque de sous réseau. Si nous reprenons les différentes
classes d’adresses :

En classe A, avec le masque 255.0.0.0, nous retrouverons le préfixe /8


En classe B, avec le masque 255.255.0.0, nous retrouverons le préfixe /16
En classe C, avec le masque 255.255.255.0, nous retrouverons le préfixe /24

Si, en ‘classless’, nous reprenons notre exemple 193.191.131.0 255.255.255.224, l’adresse


préfixée correspondante sera alors 193.191.131.0/27.

Un aspect important pour un réseau IP est que deux ordinateurs sur un même segment
physique ne seront capables de dialoguer ensemble que si ils appartiennent au même sous
réseau. De ce fait, si nous voulons interconnecter deux sous réseaux différents ensemble,
il nous faudra utiliser un équipement intermédiaire assurant la liaison entre les deux.

Un autre aspect est la distinction que l’on peut faire entre une adresse publique et une
adresse privée. Nous retrouvons en effet une gamme d’adresses dites privées que
monsieur tout le monde peut utiliser dans son réseau domestique pour autant que ces
adresses ne soient pas utilisées directement pour accéder sur Internet.

10.0.0.0 à 10.255.255.255
172.16.0.0 à 172.31.255.255
192.168.0.0 à 192.168.255.255

Et qu’en est il des adresses IP publiques. A partir du moment où vous désirez avoir une
présence sur Internet, il est impératif de disposer d’une adresse IP publique. Si vous vous
connectez sur Internet au moyen d’une connexion ADSL, c’est votre modem ADSL qui
reçoit de façon dynamique une adresse IP publique de votre fournisseur d’accès. Cette
attribution d’adresse étant dynamique, vous risquez de ne pas avoir tout le temps la même
adresse. Si vous souhaitez héberger vos serveurs, le solution consiste à obtenir des
adresses IP fixes.
La gestion des adresses IP est de la responsabilité de l’IANA (Internet Assigned Numbers
Authority) qui va attribuer des plages d’adresses à gérer à des RIR (Regional Internet
Registry) correspondant à chaque continent. Ces RIR désignent ensuite des LIR (Local
Internet Registry) pour gérer localement certaines plages d’adresses. En tant qu’utilisateur
final, c’est à ces LIR que vous devez vous adresser. Un LIR est en général un fournisseur
d’accès internet.

Nous retrouvons cinq RIR :

• American Registry for Internet Numbers (ARIN) for North America


• RIPE Network Coordination Centre (RIPE NCC) for Europe, the Middle East and
Central Asia
• Asia-Pacific Network Information Centre (APNIC) for Asia and the Pacific region
• Latin American and Caribbean Internet Address Registry (LACNIC) for Latin
America and the Caribbean region
• African Network Information Centre (AfriNIC) for Africa

Nous terminerons ce paragraphe en citant une dernière plage d’adresses particulières qu’il
n’est pas envisageable d’utiliser directement, ce sont les adresses de loopback qui
correspondent à 127.0.0.0/8. Ces adresses permettent de tester la bonne implémentation de
la pile TCP/IP au niveau de votre système d’exploitation.

2.3. Le routage IP (IP v4)

Dans notre exemple, nous avons interconnecté deux sous réseaux différents au moyen de
ce que l’on appelle un routeur. Il faudra maintenant indiquer aux ordinateurs du sous
réseau 192.168.13.0 que l’accès au sous réseau 10.0.0.0 devra se faire en empruntant ce
passage obligé qu’est le routeur. Pour y parvenir, nous sommes donc obligé de donner une
adresse IP de part et d’autre du routeur en correspondance au sous réseau sur lequel est
relié notre routeur. Comme nous avons deux points de connexion, nous retrouverons deux
adresses IP.

Si nous considérons les ordinateurs du réseau 192.168.13.0, il faudra leur renseigner que
tous les paquets à destination du sous réseau 10.0.0.0 devront passer par la « porte »
d’accès 192.168.13.1. Cette opération peut se réaliser en définissant des tables de routage.
La syntaxe à utiliser est fort semblable d’un système d’exploitation à l’autre et nous nous
limiterons à parler de celle utilisée sous Windows.
Route ADD 10.0.0.0 MASK 255.0.0.0 192.168.13.1 METRIC 2

Si un ordinateur sur le segment 10.0.0.0 reçoit un paquet en provenance d’un ordinateur


du sous réseau 192.168.13.0, il doit être capable de lui répondre et de ce fait, il doit savoir
que tout paquet à destination de ce sous réseau doit passer par la « porte » d’accès
10.0.0.1. Nous devrons donc définir sur les ordinateurs du sous réseau 10.0.0.0 le routage
suivant :

Route ADD 192.168.13.0 MASK 255.255.255.0 10.0.0.1 METRIC 2

Il se peut que vous deviez envoyer tout le trafic étranger à votre sous réseau vers une
« porte » d’accès particulière. C’est ce que l’on appelle la passerelle par défaut.
Particulièrement utile lorsque vous voulez accéder à de nombreuses ressources qui se
situent dans des sous réseaux différents. Ce cas concret est rencontré lorsque vous surfez
sur Internet. On appelle cette passerelle la passerelle par défaut. Reprenons notre exemple
En y ajoutant un routeur supplémentaire.

En utilisant la commande déjà renseignée au préalable, nous aurons alors la syntaxe


suivante :

Route ADD 0.0.0.0 MASK 0.0.0.0 192.168.123.2 METRIC 2

Dans notre exemple, il est interdit de faire sortir des paquets vers internet en ayant comme
adresse source une adresse IP privée. Or cette situation est assez fréquente dans les
sociétés disposant d’une seule adresse IP fixe mais d’un réseau d’ordinateurs derrière le
routeur désirant accéder à internet. Nous utiliserons dans ce cas précis ce que l’on appelle
de la translation d’adresses connue sous l’abréviation NAT. Dans cette situation, le
routeur remplace dans les paquets sortant l’adresse IP source par l’adresse IP que celui-ci
a sur son interface de sortie. Pour bien comprendre le mécanisme, il est nécessaire
d’aborder les protocoles de la couche de transport.

2.4. Couche de transport TCP/UDP.


Reprenons l’exemple repris dans l’introduction d’un ordinateur A voulant communiquer
avec un ordinateur B. Nous pouvons être plus précis et dire que sur l’ordinateur A, un
client http (navigateur WEB) veut accéder sur l’ordinateur B à un serveur http (serveur
WEB).
Si nous envisageons que ces seules applications doivent communiquer entre elles, il n’y
aura pas trop de problèmes. Et qu’en est il si plusieurs applications clientes sur
l’ordinateurs A veulent accéder à des applications serveurs différentes sur l’ordinateur B.
C’est à ce niveau que la couche transport va veiller à ce que les paquets de données de la
couche applicative du client A arrive bien sur la bonne application du client B.
Nous retrouverons au niveau de la couche transport la notion de port. Le port n’est rien
d’autre qu’une valeur numérique codée sur 16bits et pouvant prendre une valeur comprise
entre 0 et 65535. L’émission d’un message se fait sur base d’un port source et d’un port de
destination. Si l’ordinateur B offre un service, il doit avoir un numéro de port fixe connu
par les clients potentiels, le numéro de port source étant attribué par l’ordinateur A.
Pour bien mettre en évidence cette notion de port, il suffit d’accéder à un site web avec
votre navigateur local et ensuite d’exécuter la commande netstat.
Si notre ordinateur vient d’accédé au site www.helho.be, nous retrouverons les
informations suivantes :

Connexions actives
Proto Adresse locale Adresse distante Etat
TCP ORDIA:2265 mail.helho.be:http ESTABLISHED

Le client http de l’ordinateur A va donc passer au travers de la couche transport et le client


sera référencé par cette couche sous le port 2265. Ce client va communiquer avec
l’application serveur de l’ordinateur mail.helho.be qui sera référencée par la couche
transport par le numéro de port 80 (représenté ici par l’abréviation http).
Cette abréviation signifie bien que pour les applications serveur courantes, un numéro de
port fixe lui a été associé, ceci pour facilité les échanges de données. Nous retrouverons ci
après une liste des applications serveur sous la forme du protocole de la couche
applicative utilisée et le numéro du port de la couche transport.

20 FTP-DATA File Transfer [DefaultData]


21 FTP File Transfer [Control]
22 SSH Secure Shell
23 TELNET Telnet
25 SMTP Simple Mail Transfer
53 DOMAIN Domain Name System(DNS)
80 HTTP WWW
110 POP3 PostOffice Protocol–V3
111 SUNRPC SUN RemoteProcedureCall
119 NNTP USENET News TransferProtocol
123 NTP Network TimeProtocol

La couche transport contient deux protocoles permettant à deux applications d' échanger
des données indépendamment du type de réseau emprunté (c' est-à-dire indépendamment
des couches inférieures...), il s'
agit des protocoles suivants :

Le protocole UDP (User Datagram Protocol) qui correspond à un mode de transport non
connecté et TCP qui lui est de type connecté.
UDP ne garantit ni la livraison des messages ni l’ordonnancement des différents paquets.
TCP garantit la livraison des paquets puisqu’en cas de perte, l’émetteur et le récepteur
seront au courant de cette perte, ainsi que l’ordonnancement des différents paquets.
La garanti de la livraison est rendue possible par l’utilisation d’un acquittement. Ce
concept repose sur les techniques d’acquittement de message : lorsqu' une source S émet
un message Mi vers une destination D, S attend un acquittement Ai de D avant d' émettre
le message suivant Mi+1. Si l’acquittement Ai ne parvient pas à S, S considère au bout
d'un certain temps que le message est perdu et réémet Mi.

Nous retrouvons également ce principe de connexion qui existe en TCP et pas en UDP.
Une connexion TCP est établie en trois étapes suivant le schéma de principe suivant :

2.5. La translation d’adresse (NAT).

Le mécanisme de translation d' adresses a été mis au point afin de répondre à la pénurie
d'adresses IP avec le protocole IPv4. Comme nous l’avons renseigné dans un paragraphe
précédent, les adresses IP privées ne peuvent être utilisées pour sortir sur Internet. Il ne
vous est pas toujours possible non plus d’obtenir un nombre d’adresses IP publiques
correspondant aux nombres d’hôtes présents sur votre réseau. Reprenons le schéma de
principe suivant :
L’ensemble des ordinateurs sur le réseau doivent être configurés de sorte que la passerelle
par défaut soit 192.168.13.1. Si nous considérons les différents paquets qui vont transiter
pour parvenir de l’ordinateur 192.168.13.20 vers le serveur www.helho.be.

Adresse source Port source Adresse destination Port Destination


192.168.13.20 1166 193.191.131.9 80

Ce paquet arrive sur l’adresse 192.168.13.1 de notre routeur NAT. Celui-ci est configuré
de sorte que tous les paquets qui arrivent sur son port LAN soient redirigés vers le port
WAN avec la mise en place de la transaction d’adresse. Le paquet en sortie du routeur
aura la structure suivante :

Adresse source Port source Adresse destination Port Destination


193.191.131.2 2873 193.191.131.9 80

En interne, notre routeur devra mémoriser l’information de translation.

Adresse source Port source Port translaté


192.168.13.20 1166 2873

Lorsque le serveur va recevoir la requête, il va pouvoir y répondre en renvoyant le paquet


suivant :

Adresse source Port source Adresse destination Port Destination


193.191.131.9 80 193.191.131.2 2873

Lorsque le routeur NAT va recevoir ce paquet sur son port 2873, il sait que ce port est
associé à l’adresse 192.168.13.20 et aussi au port 1166. Il suffira alors de rediriger le
paquet de réponse vers l’hôte correspondant.

Adresse source Port source Adresse destination Port Destination


193.191.131.9 80 192.168.13.20 1166