IFT3820/IFT6833
Gestion de Réseaux et Protocoles

Département d'informatique
et de recherche opérationnelle

Été 2002


Accueil

Professeurs et
Démonstrateurs

Horaires et locaux

Notes de cours

Démonstrations
et devoirs

Examens

Liens utiles

Au sujet du
livre de cours

Consultez vos notes

Foire aux questions
(FAQ)

Sessions antérieures
(A01, H02)

Démonstration #7, exercice #2


Source: collectifs Univ. Pierre & Marie Curie (UPMC-6), d'Architecture de réseaux.

- Exercice -2- (Solution)

  • 1/ Représenter le diagramme d'établissement de connexion de TCP.

    Réponse:

    Le diagramme est comme suit:

    image d'une connexion TCP

  • 2/ Pourquoi procéder à un échange en trois phases ?

    Réponse:

    Un échange en deux phases comme au niveau liaison (figure ci-dessous) ne fonctionne que si le réseau est fiable avec sequencement garanti.

    image d'un échange

    Le service réseau fourni par IP ne correspond pas à ce modèle. L'établissement des connexions TCP doit prendre en compte :

  • - le déséquencement des paquets introduit par leur errance à l'intérieur du réseau. Les paquets suivent des chemins différents dans le réseau et peuvent connaître des temps de traversée très aléatoires (problèmes d'algorithme de routage ou de congestion). Le réseau "stocke" des datagrammes pendant un temps (de transit) indéfini.
    Une TPDU de données émise par A peut parvenir à B avant que la connexion soit formellement établie. La TPDU est soit stockée alors que la connexion n'est pas établie ou elle est rejetée. Il faut interdire à l'appelé d'émettre avent d'avoir reçu l'autorisation. ceci est fait par la procédure d'initialisation en trois étapes (three-way handshake). La connexion est établie pour l'entité appelante que lorsqu'elle reçoit la confirmation de connexion, alors qu'elle n'est établie pour l'appelée que lorsqu'elle a reçu un acquittement.
    image d'un three-way handshake
  • - la résurrection de datagrammes contenant une demande ou une confirmation de connexion (paquets survivants d'une connexion libérée)
    La résurrection
  • - les erreurs de transmission, pertes et duplications affectant les unité de protocoles d'établissement de connexion.

    En cas de perte de l'acquittement, la reprise est faite par temporisateur. La procédure d'initialisation en trois étapes sert à résoudre ces problèmes en fournissant une synchronisation minimum entre les deux extrémités d'une connexion.

  • 3/ Pourquoi ne pas commencer la numérotation de séquence à 0 ?

    Réponse:

    Une connexion est définie par une paire de sockets. Si la connexion est répétitivement ouverte et fermée, ou si la connexion est rompue puis réétablie. Un problème se pose à TCP: Comment identifier les segments appartenant aux connexions précédentes ? Si ces segments sont compris comme appartenant à la connexion, ils entrainent des pertes et des duplications de segments qui ne seront pas détéctées par TCP. Le transfert n'est alors plus fiable.
    Pour éviter toute confusion, le numéro de séquence initiale est diffèrent pour chaque connexion. Cela sert à différencier les connexions. Pour plus de sécurité, quand la connexion est fermée, TCP reste dans un état de purge pendant la durée de vie maximale d'un paquet (120 s). Ceci pour garantir que des segments appartenant à des connexions précédentes ne puissent ressurgir.
    Lorsqu'une connexion est créée, une valeur de ISN sur 32 bits est déterminée. En simplifiant, ceci est fait en utilisant un compteur, incrémenté de 1 toutes les 4 µs : la séquence de numérotation reboucle alors approximativement toutes les 4.55 heures, ce qui est largement supérieur à la durée de vie maximum d'un segment dans le réseau.

  • 4/ Pourquoi TCP structure les échanges de données en segment alors qu'il rend un service de flux d'octets ?

    Réponse: Le segment est l'unité de contrôle. Les contrôles de fiabilité sont faits sur le segment.

  • 5/ Quelle est l'appellation OSI du segment TCP ?

    Réponse: TPDU ou message

  • 6/ Comment sont différenciés les rôles du segment de TCP?

    Réponse:

    par les drapeaux (flags) de l'en-tête TCP.

[top]


Dernière mise à jour : Fri Jul 12 14:43:37 EDT 2002
dift3820@iro.umontreal.ca
dift6833@iro.umontreal.ca