TCP / IP
9° TCP
Transport Control Protocol
Sommaire

du Site

Avant 
ARP
Après
ICMP

Principales fonctions du protocole TCP

Dans ce qui suit, mon but est seulement de vous présenter une description générale
des principes et des mécanismes qui régisssent les protocoles TCP ou UDP.

C'est intéressant pour connaître le type particulier de problèmes que pose l'implémentation d'un réseau.
Les solutions indiquées peuvent donner des idées à de futurs concepteurs...

Mais la description des moindres détails de réalisation sort du cadre de ce site.
C'est très long à décrire, fastidieux à lire, et pour tout dire totalement inutile, sauf pour les spécialistes.
Mais vous êtes ici sur un site de généralistes !
Avant d'aborder ce chapitre, il est bon de situer la couche transport TCP dans la pile TCP/IP.

Pour ceux qui n'ont pas suivi le cursus précédent, se reporter à :

Points étudiés dans la suite

Thèmes
Lien direct
TCP est responsable du fractionnement des messages.
TCP est un protocole de transport assurant la fiabilité des données transportées de bout en bout.
TCP est un protocole orienté connexion multiplexable.
TCP est doté d'un contrôle de flux.
TCP exerce un contrôle du routage.
Exemple d'analyse du trafic réseau.


Fractionnement du message

Il ne s'agit pas du tout ici de la fragmentation des paquets IP vue à la page précédente :
La fragmentation vue précédemment agit sur ces paquets lorsqu'ils empruntent une portion de ligne de transmission
physiquement incapable de les transmettre à cause de leur longueur.


Le fractionnement dont nous allons parler maintenant a pour but de faciliter et accélérer le travail
des routeurs situés aux noeuds du réseau.
Il a lieu au moment de l'émission d'un flot de données par un hôte du réseau.
Il aboutit, comme nous allons le voir, à la création de paquets.

Pourquoi fractionner ?

Dans un réseau vaste et complexe comme Internet, l'information circule de noeud en noeud .
D'expéditeur initial au destinataire final, le trajet d'un message peut avoir à traverser plusieurs noeuds.
Chaque noeud peut voir arriver des messages sur ses nombreux ports en provenance des noeuds environnants.
Il doit pouvoir également les renvoyer dans toutes les directions pour jouer son rôle de routage .
Lien à "Routage" :

Si les messages n'étaient pas découpés, des blocages pourraient se produire.
Car chaque noeud devrait traiter la totalité d'un message en cours avant de pouvoir traiter le suivant.

En fractionnant les messages, le traitement de chaque fragment par un noeud est extrêmement rapide.
Les noeuds verront alors arriver des fragments de messages divers
de toutes provenances et vers toutes les destinations,
qu'ils renverront tout aussitôt en direction de son destinataire.

Chaque noeud donne l'impression de traiter plusieurs messages à la fois.
Aucun message ne devra attendre qu'un long message le précédant soit entièrement passé.

La couche TCP est responsable du fractionnement des messages sortants.
Elle devra également raccorder convenablement ces fragments à l'arrivée.

Les fractions de message sont appelés tantôt datagrammes, tantôt paquets, tantôt trames,
suivant la couche à laquelle on se place.

Trames pour le niveau 2 liaison - datagrammes au niveau 3 réseau - paquets au niveau 4 transport.
Mais ces dénominations varient suvant le contexte : on se comprend !

Autre avantage du fractionnement : le contrôle d'erreurs pourra se faire paquet par paquet.
Si une erreur est décelée sur un paquet, il suffira de renvoyer ce paquet
et pas la totalité du message comme c'eût été le cas si une erreur eût été décelée vers la fin.
Gain de temps et moindre encombrement du réseau.


Entête TCP

Comme on s'en doute, les machines extrêmes connectés à travers le réseau dans une relation client-serveur
doivent pouvoir dialoguer
pour s'accorder sur ce que demande la machine cliente et ce que le serveur peut fournir,
et sur ce que le serveur a fait ou pas des paquets envoyées,
combien en a-t-il envoyés ? combien le serveur en a-t-il reçus ?
l'envoi est-il terminé ?
etc...etc..

Ces informations sont échangées à travers des en-têtes structurées.
Dans les paquets du serveur vers le client les entêtes précèdent les données envoyées.
Du client vers le serveur, les en-têtes servent d'acquittements et d'informations sur le déroulement de la session.

Voici l'en-tête concernant le protocole de dialogue TCP


La suite décrira chacun des champs de cet en-tête


Contrôle d'ntégrité "de bout en bout"

"Contrôle de bout en bout" est une expression fréquente pour signifier
que deux machines connectées à travers un vaste réseau
se livrent automatiquement à une vérification de l'intégrité du message envoyé par l'une et reçu par l'autre.

Il ne s'agit pas du contrôle que deux machines intermédiaires (routeurs)
exercent sur les paquets que l'une a envoie à l'autre.
Ceci concerne le contrôle de niveau 2 Liaison.

Voici pourquoi le contrôle de bout en bout est indispensable :

  1. De par le fractionnement du message (c.f. ci-dessus : ) et de par l'action du routage des paquets dans les noeuds du réseau, certains paquets peuvent emprunter des voies différentes en arriver dans le désordre.

  2. L'infrastructure du réseau ne peut pas être réputée fiable.
    Il n'est pas impossible qu'une des machines chargées de l'acheminement des messages
    et situées aux noeuds du réseau défaille momentanément.
    C.f. r Routage :
    Des paquets de données peuvent alors ne jamais parvenir à destination.

  3. Il n'est pas impossible, que dans leurs tentatives de trouver la meilleure direction d'acheminement, les routeurs dupliquent certains paquets. C.f. r Routage :
    Des doublons parviendont à destination.
    Il faudra les éliminer, sauf un, bien entendu !

Tout cela n'est pas bien grave si l'on met en place, aux deux extrémités de la connexion,
des logiciels conversationnels qui auront pour missions principales :

  1. Éliminer les doublons (bien sûr)

  2. Vérifier à l'arrivée si tous les paquets sont bien là et conformes,
    Et, dans le cas où il y auraut défaillance sur un paquet (non arrivé ou défectueux)
    de converser avec la partie émettrice afin, par exemple, de renvoyer les absents.

  3. Remettre les paquets dans l'ordre séquentiel d'envoi.

Grâce au numérotage des datagrammes et un protocole convenable établi entre expéditeur
et destinataire il sera toujours possible de rétablir la totalité du message dans le bon ordre.

Cette vérification n'est eficace que si elle se fait entre les deux extrémités de la liaison.
C'est pourquoi on appelle ce genre de logiciels des services de bout en bout.
Les noeuds intermédiaires ne sont pas concernés par ce protocole.

TCP (Transmission Transport Protocol)
est un exemple de protocole de transport rempliqqant le fonctions susdietes.
Il remplit les conditions générales de la couche transport.

C.à.d.
  • vérifier que l'ensemble des paquets de données constituant le message soient bien parvenus à destination.
  • rappeler les paquets perdus.
  • remettre en ordre les paquets dans le cas où ils arriveraient désordonnés.
  • éliminer les doublons
  • au pire, générer des messages d'erreur.

Intégrité de bout en bout ... qu'est-ce à dire ?
En somme tout doit se passer comme si les application des deux ordinateurs distants
communiquaient entre-elles par un lien fiable à 100%.

Tout ce qui est confié à la couche TCP de l'une, est intégralement livré par la couche TCP de l'autre.

C'est merveilleux les réseaux ! Non ?

Oui, mais comment parvenir à ce monde merveilleux ?

Procédons par ordre (ou dans le désordre si vous souhaites sauter des étapes) :

Etapes
Lien direct
Qu'est-ce qu'une connexion ?
Multiplexage
Vérification du séquencement des paquets
Contrôle du routage (pseudo-entête TCP)


Qu'est-ce qu'une connexion ?

Dans un réseau existent couramment de nombreux hôtes
faisant tourner des applications de type client et de type serveur
qui communiquent entre-elles.
Toutes les données se croisent dans le réseau.

1° - Problème de continuité du message transporté
On peut se poser la question de savoir comment la relation entre un client et son serveur peut perdurer
alors que les réponses des serveurs peuvent parfois être très longues et intermittentes
en raison de l'encombrement des lignes ou des serveurs eux-mêmes.
Autrement dit, comment client et serveur ne perdent-ils pas le fil de ce qui est fait et reste à faire en matière d'échange.
C'est pour résoudre ces problèmes que l'on a défini les protocoles de connexion.

Pour se rendre directement au chapitre "Séquencement", cliquez sur :

2° - Problème de multiplexage
On sait que les systèmes d'exploitation multitâches de chacun des ordinateurs hôtes
permettent de lancer plusieurs fois un même logiciel (on dit qu'on peut en créer plusieurs instances).
Un client peut donc lancer plusieurs échanges simultanés avec le même serveur ou avec des serveurs différents.

Par exemple, vous pouvez lancer plusieurs fois "Internet Explorer" pour explorer simultanément plusieurs sites Internet..
Vous verrez que les différentes pages demandées apparaissent progressivement indépendamment l'une de l'autre
sur les multiples fenêtres ouvertes et sans que les flots de données se mélangent !


D'une manière générale, établir entre deux hôtes plusieurs flots d'informations
indépendants et simultanés
empruntant le même support s'appelle "multiplexer" ces flots de données.

Comment ce client parvient-il à ne pas confondre les informations qui lui parviennent
du serveur et d'envoyer chacune d'elles à l'instance correspondante du logiciel client ?


L'aiguillage (démultiplexage) correct des réponses du serveur
est rendu possible par le mécanisme des PORTS d'entrée-sortie.


Multiplexage des applications

1° Qu'est-ce qu'un PORT ?

Observez les espaces "Port Source" & "Port Destination" de l'entête TCP.


A ce stade, les ports apparaissent comme des numéros.

Ces numéros serviront à différencier les différentes instances de connexion entretenues entre deux hôtes
en aiguillant chaque paquet à son arrivée vers le type d'application censée la traiter.

On distinguera par exemple les paquets concernant les applications http (traitement des pages web)
des transferts de fichiers quelconques (FTP), ou des courriers électroniques (SMTP), etc.

  • L’entête TCP réserve 16 bits pour les n° de ports.
  • Les n° des ports s’étendent donc de 0 à 65 535
  • Les ports 0 à 2000 réservés (dédiés) pour les serveurs d’applications notoires.
    Par exemple, à une application type serveur HTTP sera systématiquement atribué le numéro de port 80.
    Un client HTTP cherchera donc à joindre son serveur à l'aide du numéro de port 80.
  • Vous disposez des ports > 2000 pour ouvrir des sessions pour des applications clientes.

Ports dédiés

Port
Applicatif
Transport
Fonction
7
PING
TCP/UDP
Service d'écho pour inspection des adresses IP actives
20
FTP
TCP
Protocole de transfert de fichiers. Port d'échange de données
21
FTP
TCP
Protocole de transfert de fichiers. Port d'informations de contrôle
23
TELNET
TCP
Contrôle de stations à distance.
25
SMTP
TCP
Simple Mail Transport Protocole : courrier électronique (sortant)
53
DNS
TCP
Domain Name Service : service de noms
69
TFTP
UDP
Trivial File Tranfer Service. Transfert de fichiers simple.
70
GOPHER
TCP
Ancêtre du Web
80
HTTP
TCP
World Wide Web
110
POP(3)
TCP
Post Office Protocol - Relevé de courrier sur les serveurs de e-mail.
119
NNTP
TCP
Network News Transfer Protocol
161
SNMP
UDP
Simple Network Management Protocol. Maintenance.

Exemple : port N° 80 pour HTTP (serveur Web), port N° 25 pour SMTP (serveur courrier électronique sortant).
Pour une complète information sur ces ports dédiés, voir sur le site de l'IANA :

2° Utilisation des ports pour le multiplexage d'applications

Au départ de chacune des instances d'une relation client-serveur ,
l'application cliente annonce à l'application serveur :

  1. Le type de protocole de transport qui sera utilisé (TCP par exemple)
  2. Son adresse IP propre (celle de l'hôte demandeur de la relation)
  3. Un numéro de port source ( > 2000). Qu'elle ouvre en veillant qu'il soit différent de ceux qu'elle a éventuellement ouverts dans d'autres instances.
  4. L'adresse IP de l'hôte hégergeant l'application serveur.
  5. Le numéro de port correspondant à l'application serveur qu'elle souhaite solliciter.
    Par exemple : 80 pour visiter des pages Web ou 25 pour envoyer du courrier

Clent et serveur mémorisent chacun ces 5 valeurs pendant toute la durée du transfert du flot d'informations
concernant une instance particulière du logiciel client,
que nous appellerons "connexion".

Vous pouvez vérifier que les numéros des ports "source" et "destination"
sont bien représentés sur l'entête TCP en cliquant sur :


Bien entendu, les contenus de ces champs sont alternés
suivant que le paquet TCP est généré par le client ou par le serveur.

Cette identification permet à chacun des partenaires de connaître
à quelle instance de connexion le paquet qui arrive appartient.

Pour préciser davantage les choses...

Les adresses IP permettent :

  • au client, d'acheminer les appels à connexion vers l'hôte supportant le serveur choisi.
  • au serveur, d'acheminer les réponses vers l'hôte contenant le client demandeur de cette réponse.
    Mais si plusieurs instances du logiciel client sont ouvertes, cet IP ne permet pas de les distinguer à l'arrivée.

Les numéros de port destination permettent :

  • au client, de choisir dans l'hôte visé, l'application serveur souhaitée (80=HTTP plutôt que 25=SMTP)
  • au serveur, si le client a initié plusieurs connexions simultanées, de préciser à laquelle des connexions il répond.

Les numéros de port source permettent :

  • au client, dans le cas où il a ouvert plusieurs connexions simultanées,
    d'indiquer au serveur à laquelle il se réfère.
  • au serveur, de connaître à quelle connexion le client se réfère, si celui-ci en a ouvert plusieurs.


Nous verrons plus bas qu'une connexion passe par trois phases :
l'ouverture, le maintien, la clôture.

Pour dissiper tout malentendu, un client peut ouvrir simultanément plusieurs connexions avec son serveur.
L'un ou l'autre peuvent en clore certaines tout en maintenant d'autres.

Paramètres d'une connexion.

Pour désigner une connexion de manière univoque il suffit de préciser :

Protocole transport
IPsource
PORTsource
IPdestination
PORTdestination
Le protocole de transport à indiquer est : TCP ou UDP

Exemple :

TCP
192.21.25.3
2008
190.25.45.2
80

Par exemple, le port source 2008 est ouvert par le client à l'ouverture de la session.
(après négociation avec le serveur pour en déterminer la disponibilité)

On reconnaît dans cet exemple le port destination 80 immuablement destiné aux applications HTTP.
Cette connexion correspond à une relation client-serveur de pages web.

On distingue souvent les paramètres d'extrémité de connexion dans l'exemple précédent :

TCP , 192.21.25.3 ,2008
&
TCP , 190.25.45.2 , 80

Vie d'une connexion
  1. Un hôte Hb faisant tourner des applications de type serveur exploitables par d'autres hôtes du réseau dans une relation client-serveur , attribue un n° de port TCP différent à chacune de ses propres applications.

    Pour les applications les plus fréquentes (HTTP, FTP, SMTP, etc..) ce numéro de port doit être connu de tous donc résultant d'une convention internationale.

    Exemple : port N° 80 pour HTTP (serveur pages Web), port N° 25 pour SMTP (serveur courrier électronique).
    Pour une complète information sur ces ports dédiés, voir sur le site de l'IANA :

    Mais pour des applications propriétaires, on doit choisir d'autres numéros de port, ce qui donne lieu à une négociation entre client et serveur. En voici les étapes :

  2. ECOUTE
    Chacune des applications de type serveur doit rester en situation d ’écoute permanente sur ses ports.
    Prête à d'évntuelles sollicitations des clients.

  3. OUVERTURE DE LA CONNEXION :
    Pour commencer sa relation, un client "A" de l'hôte Ha fait un appel d ’ouverture de connexion à destination de
    l ’application B choisie sur l'hôte Hb.
    "A" doit donc connaître :


    1. l ’adresse IP de la station visée Hb où se trouve l'application B
    2. une indication qui désigne l'application B parmi toutes celles disponibles dans l'hôte Hb.
      Cette indication est précisément le n° de port destination rattaché, par convention, à l'application B.
      (p.ex. 80 si l'application demandée est le serveur HTTP de Hb)


    Dans cet appel d'ouverture elle lui communique ses propre coordonnées à savoir :

    1. la propre adresse IP de l'hôte Ha qui la supporte.
    2. un numéro de port (que "A" génère en vérifiant qu'elle ne l'ait pas déjà attribué à une autre connexion) ;
      C'est le port source.
      On dit que le client A "ouvre un nouveau port ", sous entendu "source" ou "de sortie"

      Le serveur visé, ici B, devra mémoriser ces coordonnées.
      Toutes les réponses unltérieures de B contiendront ce numéro de port source indiquant à quelle connexion
      (s'il y en a plusieurs d'ouvertes) la réponse se réfere.
      Ce qui permet à un client A ayant lancé plusieurs connexions simultanées de connaître à laquelle appartient chaque réponse du serveur.

      N.B. Le numéro de port source créé par un client n'est (surtout pas) le numéro de port rattaché à l'application serveur qu'elle appelle.
      Par exemple, si Internet Explorer sollicite une page Web, le port destination qu'elle indique est bien 80, mais le port source est forcément différent de 80.
      Sinon Int.Expl. ne pourrait ouvrir plusieurs connexions différentes et simultanées avec ce serveur Web.


  4. MAINTIEN DE LA CONNEXION :
    Client et serveur échangent ensuite des acquittements, des informations de séquencement et de synchronisation ainsi que l'information que le client attend du serveur.

  5. CLOTURE DE LA CONNEXION :
    Client ou serveur signalent à l'autre que c'est fini.
    Le client libère le port qu'il a utilisé, le rendant disponible pour une session ultérieure (qui ne se fera pas forcément avec le même port du serveur distant).

SEQUENCEMENT DES ECHANGES

Lorsque deux hôtes échangent de l'information à travers un réseau,
ils ne peuvent pas être sûrs à 100% qu'elle sera reçue de manière pertinente par le partenaire.

Cela tient aux défaillances possibles du réseau (coupures, retards, etc.).
Ces incidents sont dans la mesure du possible réparés par les diverses couches (liaison-réseau-transport)
que l'information traverse et que nous venons d'étudier dans ce site.

Mais il peut se produire des incidents dûs aux applications client-serveur elles-mêmes
Cela tient aussi à l'application client ou serveur elle-même (possibilité d'interruption, voulue ou non, etc.)

Le maintien d'une connexion exige donc l'échange d'un certain nombre d'informations au cours de celle-ci
pour que les deux interlocuteurs soient au fait du bon avancement.

N'oublions pas que le message est fractionné en paquets,
que ces paquets peuvent se perdre
ou parfois être dupliqués .

Il nous faut :

  • Vérifier que l'ensemble des paquets de données constituant le message soient bien parvenus à destination.
  • Rappeler les paquets perdus.
  • Remettre en ordre les paquets dans le cas où ils arriveraient désordonnés.
  • Éliminer les doublons
  • au pire, générer des messages d'erreur.

Nous allons voir comment on résout ces problèmes
grâce au principe de la connexion et la vérification du séquencement des paquets.

Dans ce qui suit, je ne détaillerai pas les cas d'exception.
C.a.d. par exemple, que faire lorsque le serveurou le client ne répondent pas ?
Que faire lorsqu'un paquet est reçu hors de séquence ?
Ou qu'un paquet manque à l'appel ?
etc.

Ce serait très long et fastidieux pour ceux qui souhaitent seulement avoir une idée du fonctionnement du protocole.
C'est d'ailleurs pour ceux-là que ce site est fait.

Néanmoins, les indications succinctes qui sont données ci-dessous
permettent d'imaginer de multiples possibilités d'action pour satisfaire les objectifs déjà énoncés de la couche TCP.

OUVERTURE DE CONNEXION

SYN SYN=1 : Demande de connexion (dite de synchronisation puisque la connexion est bi-directionnelle)
ACK Confirmation d'acceptation de connexion.
SEQ Nombre d'octets envoyés avant ceux que l'on envoie dans la présente séquence.
SEQ = 0
si l'Open actif est satisfait dès le premièr appel
.
ACQ Numéro de séquence du 1° 'octet que l'on s'attend à recevoir après ceux déjà reçus.
ACQ = nb d'octets reçus + 1


Si vous voulez vérifier les emplacements des sigles SEQ,ACQ,URG,ACK,PSH,RST,SYN,FIN
sur une entête TCP type, cliquez sur :

Il n'y a pas ici d'échange de données.

OUVERTURE PASSIVE
Dès ce type d'ouverture effectué, le serveur reste à l'écoute de tout appel arrivant sur son port d'entrée.
Ce port doit être connu du client.

OUVERTURE ACTIVE
Par ce type d'ouverture, le client demande l'ouverture d'une nouvelle connexion au serveur.
Ce dernier ne peut répondre que s'il a déjà effectué une ouverture passive.

C'est au cours de cette ouverture active que le client indique au serveur l'indentification de la connexion à savoir :

Protocole transport
IPsource
PORTsource
IPdestination
PORTdestination

La procédure d'interface correspondante est :
Open(Protocole,IPsce,PORTsce,IPdest,PORTdest);

MAINTIEN DE LA CONNEXION
Je traite ici le problème du séquencement.

Je suppose au départ:

  • que l'application cliente à gauche a déjà envoyé X octets avant ceux qu'elle s'apprête éventuellement à envoyer.
  • que l'application serveuseà droite a déjà envoyé Yoctets avant ceux qu'elle s'apprête éventuellement à envoyer.
  • Rappel des paramètres contenus dans l'entête TCP :

    SEQ Nombre d'octets envoyés avant ceux que l'on envoie dans la présente séquence.
    SEQ = 0
    si l'Open actif est satisfait dès le premièr appel
    .
    ACQ Numéro de séquence du 1° 'octet que l'on s'attend à recevoir après ceux déjà reçus.
    ACQ = nb d'octets reçus + 1

    Si vous voulez consulter une entête TCP type,
    ainsi que les emplacements des sigles SEQ,ACQ,URG,ACK,PSH,RST,SYN,FIN
    cliquez sur :


CLOTURE DE LA CONNEXION


Je n'ai représenté ici que les drapeaux ACK et FIN.
Non représenté : SYN=0 car on ne cherche évidemment pas à se connecter.

Si vous voulez consulter une entête TCP type,
ainsi que les emplacements des sigles SEQ,ACQ,URG,ACK,PSH,RST,SYN,FIN
cliquez sur :


Contrôle de routage

PSEUDO-ENTETE TCP

Cette indication est reconstituée par la couche TCP du l'hôte récepteur à l'aide
d'une partie de la couche IP.
C'est une entorse manifeste au principe d'indépendance des couches...

:
Cette entête permet au logiciel TCP d'effectuer un calcul de congruïté (checksum - total de contrôle)
étendu aux adresses IP et permettant de déceler une éventuelle erreur de routage.

Le champ "Total de contrôle" est l'un des champs de l'entête TCP.

Pour consulter une entête TCP type, cliquez sur :


Contrôle de flux

Par exemple, que faire si la machine R à la quelle une machine E envoie des données,
est momentanément ou sporadiquement, indisponible ? Cas d'une machine rapide émettant vers une lente.
Couper la communication avec rage ?

Ou lui demander à chaque fois si elle est enfin disponible ?

C'est gentil, mais celà ralentit pas mal le débit...

Ou alors ... et là l'imagination des concepteurs de réseaux est intarissable...

On nomme "Contrôle de flux" un mécanisme protocolaire entre deux stations
pour donner le maximum de chances à la station receptrice de recevoir paquets de données envoyés,
en ralentissant le moins possible le débit.

Ce contrôle de l'émission-réception d'un message
se fait par des indicateurs placés dans les en-têtes des paquets.

La station émettrice E indique dans "Numéro de séquence" le nombre d'octets du message
qu'elle a envoyés, (y compris les octets envoyés dans la présente émission).
Ce nombre d'octets s'écrit sur 32 octets (c'est grand) mais on ne risque pas ainsi qu'il se reboucle sur 0
au cours de l'émission d'un long message.
232 = 4 294 967 296 octets

A chaque trame reçue, la station réceptrice R renvoie un acquittement à E
lui indiquant le nombre effectif d'octets qu'elle a reçus sans problème depuis le début de la transaction.
Et ce dans l'emplacement "numéro d'acquittement". Avec ACK=1

Les trames que E envoie à R contiennent le nombre d'octets reçus par R sans problème
depuis le dernier acquittement de R. Il est contenu dans le champ "n° d'acquitement".
Il permet à R de savoir combien d'octets elle doit lire dans la prochaine trame.
Vous constatez en effet que le nombre d'octets de données contenus dans une trame
n'est nulle part indiqué dans aucune trame.

R fait constamment la différence enre le nombre d'octets réellement envoyés par E,
nombre contenu dans la trame dernièrement reçue,
et le nombre d'octets qu'elle a réellement reçus,
pour évaluer combien d'octets elle doit lire dans la trame suivante.

Ce processus prend fin lorsque R reçoit une trame de E avec le champ "Fin" = 1.
Ce champ se nomme en réalité "EOM" End Of Message.

Ceci se comprend bien si on suppose que le protocole d'échange est du type "Envoyer-Recevoir"
où E attendrait l'acquittement de R à chaque trame.

Mais..ce n'est pas ce qui se passe. Ce type d'échange fait perdre du temps, donc diminue le débit.

Voyons maintenant le cas réel.

Contrôle de flux par fenêtre glissante

Comme le montre la figure précédente illustrant le séquencement des octets,
une station peut envoyer plusieurs trames sans attendre un acquittement pour chacune d'entre elles.
Un acquittement peut valider plusieurs trames.

C'est avantageux en ce sens que la réduction du nombre des acquittements déleste le trafic sur le réseau.

Notez bien que la machine réceptrice peut recevoir des trames plus vite qu'elle ne les traite
grâce à des mémoires tampons ( buffers) de type FIFO (
First In First Out - Premier entré Premier sorti)
C'est un procéssus informatique facile à mettre en oeuvre et rapide d'exécution.

En revanche, il peut arriver, qu'une machine ne puisse pas absorber la totalité des données qui lui sont envoyées,
par manque de place dans ses tampons de mémoire ou/et de par sa lenteur de traitement.


Les dispositions de protocole permettant à une machine réceptrice de contrôler la quantité de données envoyées par la station émettrice s'appelle le contrôle de flux.

Parmi les nombreuses méthodes de contrôle de flux,
TCP a opté pour celle de la fenêtre glissante décrite dans la figure ci-dessous.

L'émetteur (mais dans un dialogue, chacune des parties est émettrice tour à tour)
tient à jour une séquence d'octets (appelée fenêtre).

La largeur de cette fenêtre est le nombre d'octets maximum que la station réceptrice peut recevoir en flot continu.
L'émetteur tient cette longueur du récepteur grâce à un sous-protocole adéquat en début de la relation.

Dès que le premier octet de la fenêtre est acquitté par la station réceptrice,
la fenêtre peut glisser vers la droite jusqu'à ce que l'octet se trouvant en première position s'avère non acquitté.

Le logiciel peut alors transmettre les octets compris entre le dernier octet qu'elle a transmis
et l'octet désigné par le nombre le plus à droite de la fenêtre.

Notez que ce mécanisme n'infirme pas ce qui a été dit plus haut pour le nombre d'octets à lire dans chaque trame
par la réceptrice.

Car l
e tampon d'entrée lui délivre, même si c'est en temps différé, les trames dans l'ordre d'arrivée.
Ce qui nous ramnène au cas précédent.

Remarquez que, même si ce n'était pas le cas, les champs n° de séquence & n° d'acquittement
permettraient de trouver l'ordre logique d'arrivée donc, la trame suivante à chaque pas.
Ceci exigerait un maintien en mémoire des trames.
Les tampons FIFO dispensent de ce travail.



ANALYSE DE TRAFIC RÉEL SUR LE RÉSEAU
Observons maintenant l'analyse par le logiciel 'Ethereal' de la trame 10 que nous avions commencée lors de notre étude de l'entête IP.


ANALYSE
La première séquence de l'entête IP est [ 0e 11 ]
Si vous vous reportez à l'analyse de l'entête IP, nous avions trouvé que celle-ci se terminait par l'adresse IP destination [c1 fc 7a 67]
La suite :
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
La séquence [ 0e 11 ] représente le port source.
Rappelons qu'un port est un numéro pour identifier l'un des multiples flots d'informations indépendants
qu'un ordinateur multi-tâche peut échanger avec un ou plusieurs hôtes distants du réseau.
Quelle est la valeur décimale de ce port ?
Il vous suffit de lire le rapport à la ligne "Source port : " Contrôlez !
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
Le port destination qui suit est [ 00 50 ] = 80 décimal. C'est le port dévolu au protocole HTTP
Nous pouvons en conclure que cette trame appartient à un échange sur la toile.
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
La séquence qui suit [ 35 01 d1 64 ] est le numéro de séquence .
C'est le numéro du paquet (ou datagramme).
Souvenez-vous que le message est découpé en paquets par TCP avant d'être envoyé dans le réseau
et qu'il faut bien numéroter ces paquets du fait qu'il y a risque qu'ils arrivent dans le désordre.
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
La séquence qui suit [ 00 00 00 00 ] est le numéro d'acquittement.
L 'hôte distant signale ansi le numéro du dernier paquet reçu faisant séquence avec les précédents.
Il pourrait en effet recevoir le paquet 7 après les paquets 1 2 3 4 5 .
L'acquittement aurait pour valeur 5 et pas 7.
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
Vous avez ensuite l'octet [ 70 ], en binaire : 0111 0000
Le quatre premiers bits représentent l'offset : en fait, la longueur de l'entête mesurée en ( x 4 octets)
4 x 7 = 28 octets. Je vous invite à les compter pour vérifier.
0020 7a 67 0e 11 00 50 35 01 d1 64 00 00 00 00 70 02
En binaire : 0000 0010
Les informations nommées "flags" sont des indicateurs pour le contrôle du flux entre émetteur et récepteur des trames,
nous les étudierons plus loin et un peu en détail.
URG (Pacquet à traiter d'urgence) - ACK (Acknowledgement = Paquet d'acquittement)
PSH (Push) - RST (Reset : réinitialisation) - SYN (Synchronisation : demande d'établissement de connexion)
FIN Interruption de la connexion.

Seul SYN est à 1 : cette trame est une demande d'établissement de connexion.
0030 40 00 31 4a 00 00 02 04 05 b4 01 01 04 02
Largeur de fenêtre de synchronisation. Ici 16.384 en décimal.
Nous verrons plus loin cette notion de fenêtrage.
0030 40 00 31 4a 00 00 02 04 05 b4 01 01 04 02
31 4a indique le total de contrôle d'erreur. Le rapport nous dit qu'il n'y a pas eu d'erreur
0030 40 00 31 4a 00 00 02 04 05 b4 01 01 04 02
Position d'urgence 0000
0030 40 00 31 4a 00 00 02 04 05 b4 01 01 04 02
8 octets d'options, la taille maximale d'un paquet 1460 octets [ 05 b4 ]
et un certain nombre d'autres informations que nous ne pouvons voir ici en détail.Plus tard.
Dont SACK (TCP Selective Acknowledgment Options)


Orientation

Avant 
ARP
Après
ICMP
Sommaire

du Site
Sommaire "Signaux"
Sommaire "Transmission de signaux"
Sommaire "Réseaux"