D'après certains, cela correspondrait à un connect après un bind!!!

Et le diagramme de Ivan Griffin sur les etats TCP est top (disponible sous la licence LaTeX Project Public License 1.3).

AMHA ton schéma n'est pas un bon support pour expliquer TCP.

Ce schéma n'est-il est pas mieux?

active open  ---> +---------------+  ---> active close   
                  |  ESTABLISHED  |
passive open ---> +---------------+  ---> passive close

Dans le monde réel, la transition provoquée par Send de LISTEN à SYN_SENT n'existe pour ainsi dire jamais. (Je ne sais même pas à quel appel système ça correspond d'ailleurs.)

C'est plus simple, mais ce que j'apprécie sur le schéma, c'est de voir les messages envoyés sur le réseau.

Oui mais je le trouve assez illisible.

Je vais essayer de l'améliorer.

Enfin les machines à états, bof... moi j'aime pas.

L'important avec TCP est de comprendre que de chaque coté on a la progression :


et que toute information reçue sur la progression entraîne un ACK

Le SYN transmet un numéro initial, qui correspond au 0 de la transmission de l'information. Le ACK correspondant est un 1 (donc le numéro initial + 1).

Le numéros tournent comme l'aiguille d'une montre. Il n'y pas de fin à ce manège, en regardant une seule aiguille de ta montre au moins deux fois par tour tu ne perds jamais l'heure et la date.

En fait TCP est un système qui cherche à synchroniser les informations sur 2 machines. On peut dire que c'est un double système de réplication de l'information (comme un système de sauvegarde distante).

Les informations sont réémises jusqu'à un ACK (donc la perte d'un segment ou d'un ACK correspond est géré de la même façon). La confirmation d'un ACK vient du fait que le segment n'est pas réémis et qu'un segment ayant progressé est reçu (c'est donc un système de confirmation positif puis négatif).

On voit facilement que la destruction de l'association entre les machines est nécessairement un cas particulier, puisque dans une discussion il faut une personne qui parle en dernier, et elle ne peut pas savoir si l'autre a reçu le message puisqu'il n'y a pas de réponse par définition : le ACK du dernier FIN est le seul ACK qui ne sera pas confirmé négativement, parce que rien ne vient après par définition.

ESTABLISHED:La socket a une connexion établie.
SYN_SENT: La socket attend activement d'établir une connexion.
SYN_RECV: Une requête de connexion a été reçue du réseau.
FIN_WAIT1: La socket est fermée, et la connexion est en cours de terminaison.
FIN_WAIT2: La connexion est fermée, et la socket attend une terminaison du distant.
TIME_WAIT: La socket attend le traitement de tous les paquets encore sur le réseau avant d'entreprendre la fermeture.
CLOSED: La socket n'est pas utilisée.
CLOSE_WAIT: Le distant a arrêté, attendant la fermeture de la socket.
LAST_ACK: Le distant termine, et la socket est fermée. Attente d'acquittement.
LISTEN: La socket est à l'écoute de connexions entrantes. Ces sockets ne sont affichées que si le paramètre -a,--listening est fourni.
CLOSING: Les deux prises sont arrêtées mais toutes les données locales n'ont pas encore été envoyées.
UNKNOWN: L'état de la prise est inconnu.

AMTHA c'est très moyen : d'une tu traduis "socket" par "socket" ou par "prise", mais pas par l'un ou l'autre selon l'humeur, de deux les descriptions sont incompréhensibles.

Quand un signal est envoyé et reçu, je les distingue : SYN vs. SYN'

CLOSED = peut signifier une absence de socket ou une socket qui n'est sur le réseau du tout (ne reçoit rien, n'èmet rien)

phase d'ouverture :

CLOSED = socket crée (fonction socket) et éventuellement liée à un port (fonction bind)
LISTEN (ou LISTENING) = ouverture de socket passive (fonction listen) , a réservé un port local, peut recevoir des demande d'ouverture active : attente SYN
SYN_SENT = tentative d'ouverture active (fonction connect) : SYN envoyé, attente ACK(SYN)
SYN_RECV = reçu demande d'ouverture active, essai d'établir la connexion bidirectionnelle : SYN reçu, SYN'+ACK(SYN) envoyé, attente ACK(SYN')

ESTABLISHED = ACK(SYN') reçu, connexion bidirectionnelle fonctionnelle, échange de données en cours : envoi de ACK pour les segments de données reçus

états suite à fermeture initiée localement :

FIN_WAIT1 = annonce l'arrêt de l'envoi de données : FIN envoyé, attente ACK(FIN), réception de données seulement (envoi de ACK pour les segments de données reçus)
FIN_WAIT2 = confirmation de l'arrêt de l'envoi de données : ACK(FIN) reçu, réception de données seulement (envoi de ACK pour les segments de données reçus)
CLOSING = le partenaire a annoncé l'arrêt de l'envoi de données sans avoir vu l'arrêt d'envoi de données de l'hôte local, plus aucun segment de données ne sera plus échangé : FIN' reçu, ACK(FIN') envoyé, attente ACK(FIN)
TIME_WAIT = le partenaire sait que aucun segment de données ne sera plus échangé (mais ne sait pas forcèment que l'hôte local le sait) : FIN' et ACK(FIN) reçus (séparèment ou en même temps), ACK(FIN') envoyé

états suite à fermeture initiée par le partenaire :

CLOSE_WAIT = le partenaire a annoncé l'arrêt de l'envoi de données, connexion en émission seulement : FIN reçu, ACK(FIN) envoyé
LAST_ACK = confirmation de l'arrêt de l'envoi de données, plus aucun segment de données ne sera échangé : ACK(FIN) reçu, FIN' envoyé, attente ACK(FIN')
CLOSED après LAST_ACK : ACK(FIN') reçu

C'est quoi "srv certificats SSL"?

On le devine mais ce n'est pas clair au premier abord!

Plutôt que [SYN,ACK] je préfère [SYN(ACK),ACK] ou bien [SYN of ACK,ACK].