Modèle TCP-IP/Le modèle TCP-IP et les raisons de son succès
Les modèles TCP/IP et OSI :
[modifier | modifier le wikicode]Le modèle TCP/IP est constitué de 4 couches contrairement au modèle OSI qui en comporte 7. Pour rappel les 7 couches du modèles OSI sont les suivantes :
| 7 | Application |
| 6 | Présentation |
| 5 | Session |
| 4 | Transport |
| 3 | Réseau |
| 2 | Liaison des données |
| 1 | Physique |
Le modèle TCP/IP propose de regrouper Les couches Application, Présentation, Session, sous une couche nommée Application tout simplement. Et de regrouper les couches liaison des données et physique sous le nom Hôte-réseau. Ce modèle renomme également la couche réseau en couche Internet. On obtient donc le modèle suivant :
| 4 | Application |
| 3 | Transport |
| 2 | Internet |
| 1 | Hôte-réseau |
Un des points importants à souligner est que ce modèle a été établi après la mise en place du protocole TCP/IP et qu’il est en relation directe avec son implémentation. On peut ainsi associer à ce modèle les protocoles utilisés lors de sa création (note importante : ce ne sont pas les seuls utilisables) : T.C.P. pour la couche transport et IP pour la couche internet
Les critiques que l’on peut faire par comparaison des différents modèles sont les suivantes :
- Le modèle TCP/IP est relativement flou et ne fait pas de distinction au niveau applicatif
- Le modèle OSI est trop détaillé
Le succès de TCP/IP face à OSI :
[modifier | modifier le wikicode]Plusieurs raisons expliquent le succès de TCP/IP :
Le modèle OSI était principalement utilisé dans la recherche, alors que TCP/IP était déjà dans une phase d'investissement et déjà utilisé avec succès par de nombreuses universités qui était à l'époque les principaux utilisateurs de réseaux, historiquement les gens ont donc eu tendance à utiliser le modèle TCP/IP.
De plus la première implémentation de TCP/IP dans l'Unix de l'université de Berkeley (BSD) était gratuite et relativement efficace; les industriels et divers exploitants n'ont donc pas eu à beaucoup investir pour l'implémenter.
Le modèle OSI a finalement été jugé trop complet et trop complexe. La distance entre l’utilisation (l'implémentation) et le modèle étant parfois importante. Peu de programmes peuvent utiliser ou utilisent mal l’ensemble des 7 couches du modèle : les couches session et présentation sont fort peu utilisées et à l'inverse les couches liaison de données et réseau sont très souvent découpées en sous-couches tant elles sont complexes. Le comité rédacteur de la norme a même du laisser de côté certains points techniques, comme la sécurité et le codage, pour conserver un rôle clair à chaque couche. Ce modèle est également redondant (le contrôle de flux et le contrôle d'erreur apparaissent pratiquement dans chaque couche).
Au niveau de l'implémentation, TCP/IP est beaucoup plus optimisé et efficace.
Tout ceci explique en partie le succès du modèle TCP/IP.
Organisation des données
[modifier | modifier le wikicode]Le protocole T.C.P. a pour rôle :
- de remettre en ordre les paquets reçu
- de vérifier le flot de données afin d’éviter une saturation du réseau
- de formater les données en segments de longueur variable afin de les "remettre" au protocole IP
- de multiplexer les données, c'est-à-dire de faire circuler simultanément plusieurs informations sur une même connexion
- T.C.P. permet enfin l'initialisation et la fin d'une communication
Il fonctionne par un système d'acquittement de la manière suivante, il envoie le paquet avec un message de type SYN, le destinataire répond SYN/ACK et l'expéditeur répond par un ACK. Si une de ces étapes n’est pas respectée le paquet est réémis.
Pour finaliser ce cours nous allons observer un datagramme T.C.P. qui n'est autre que la représentation d'un paquet contenant des données TCP, en voici un, il contient plusieurs champs dont tous ne sont pas nécessairement remplis :
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Port Source
|
Port destination
| ||||||||||||||||||||||||||||||
Numéro de séquence
| |||||||||||||||||||||||||||||||
Numéro d'acquittement
| |||||||||||||||||||||||||||||||
Taille de l'en-tête
|
réservé
|
ECN
|
URG
|
ACK
|
PSH
|
RST
|
SYN
|
FIN
|
Fenêtre
| ||||||||||||||||||||||
Somme de contrôle
|
Pointeur de données urgentes
| ||||||||||||||||||||||||||||||
Options
|
Remplissage
| ||||||||||||||||||||||||||||||
Données
| |||||||||||||||||||||||||||||||
Signification des champs :
- Port source : Numéro du port source
- Port destination : Numéro du port destination
- Numéro de séquence : Numéro de séquence du premier octet de ce segment
- Numéro d'acquittement : Numéro de séquence du prochain octet attendu
- Taille de l'en-tête : Longueur de l'en-tête en mots de 32 bits (les options font partie de l'en-tête)
- Réservé : Réservé pour un usage futur
- ECN : signale la présence de congestion, voir RFC 3168
- Drapeaux
- URG : Signale la présence de données URGentes
- ACK : Signale que le paquet est un accusé de réception (ACKnowledgement)
- PSH : Données à envoyer tout de suite (PuSH)
- RST : Rupture anormale de la connexion (ReSeT)
- SYN : Demande de SYNchronisation ou établissement de connexion
- FIN : Demande la fin de la connexion
- Fenêtre : Taille de fenêtre demandée, c'est-à-dire le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception
- Checksum : Somme de contrôle calculé sur l’ensemble de l'en-tête T.C.P. et des données, mais aussi sur un pseudo en-tête (extrait de l'en-tête IP)
- Pointeur de données urgentes : Position relative des dernières données urgentes
- Options : Facultatives
- Remplissage : Zéros ajoutés pour aligner les champs suivants du paquet sur 32 bits, si nécessaire
- Données : Séquences d'octets transmis par l'application
