RFC793

Coïncidence, j'étais justement en train de lire le RFC793 quand je suis tombé sur ce journal.

La section 3.3 explique pourquoi synchroniser les numéros de séquence:

 Initial Sequence Number Selection
 The protocol places no restriction on a particular connection being
 used over and over again. A connection is defined by a pair of
 sockets. New instances of a connection will be referred to as
 incarnations of the connection. The problem that arises from this is
 -- "how does the TCP identify duplicate segments from previous
 incarnations of the connection?" This problem becomes apparent if the
 connection is being opened and closed in quick succession, or if the
 connection breaks with loss of memory and is then reestablished.
 To avoid confusion we must prevent segments from one incarnation of a
 connection from being used while the same sequence numbers may still
 be present in the network from an earlier incarnation. We want to
 assure this, even if a TCP crashes and loses all knowledge of the
 sequence numbers it has been using. When new connections are created,
 an initial sequence number (ISN) generator is employed which selects a
 new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
 bit clock whose low order bit is incremented roughly every 4
 microseconds. Thus, the ISN cycles approximately every 4.55 hours.
 Since we assume that segments will stay in the network no more than
 the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
 hours we can reasonably assume that ISN's will be unique.
 For each connection there is a send sequence number and a receive
 sequence number. The initial send sequence number (ISS) is chosen by
 the data sending TCP, and the initial receive sequence number (IRS) is
 learned during the connection establishing procedure.
 For a connection to be established or initialized, the two TCPs must
 synchronize on each other's initial sequence numbers. This is done in
 an exchange of connection establishing segments carrying a control bit
 called "SYN" (for synchronize) and the initial sequence numbers. As a
 shorthand, segments carrying the SYN bit are also called "SYNs".
 Hence, the solution requires a suitable mechanism for picking an
 initial sequence number and a slightly involved handshake to exchange
 the ISN's.
 The synchronization requires each side to send it's own initial
 sequence number and to receive a confirmation of it in acknowledgment
 from the other side. Each side must also receive the other side's
 initial sequence number and send a confirming acknowledgment.
 1) A --> B SYN my sequence number is X
 2) A <-- B ACK your sequence number is X
 3) A <-- B SYN my sequence number is Y
 4) A --> B ACK your sequence number is Y

La section 3.4 parle de la connexion simultanée (puis détaille un échange):

3.4. Establishing a connection
 The "three-way handshake" is the procedure used to establish a
 connection. This procedure normally is initiated by one TCP and
 responded to by another TCP. The procedure also works if two TCP
 simultaneously initiate the procedure. When simultaneous attempt
 occurs, each TCP receives a "SYN" segment which carries no
 acknowledgment after it has sent a "SYN". Of course, the arrival of
 an old duplicate "SYN" segment can potentially make it appear, to the
 recipient, that a simultaneous connection initiation is in progress.
 Proper use of "reset" segments can disambiguate these cases.

C'est rigolo, j'ai justement demandé par mail hier à Stéphane Bortzmeyer si ce cas de connexion simultanée existait en réalité. Je colle sa réponse (je pense qu'il ne m'en voudra pas, même si un mail est censé être privé), qui indique justement que ça peut se produire avec un port source fixe:

Two processes which issue active OPENs to each other at the same
time will be correctly connected.

Existe-t-il quelque chose qui ressemble à ce que dit cette dernière
phrase dans le monde actuel?

Oui. Évidemment, en mode client-serveur moderne (le serveur a un port
destination fixe bien connu, le client un port source aléatoire), cela
n'arrive jamais. Mais si les deux utilisent un port source fixe (ce
que faisait le DNS au début, et que BGP a fait pendant encore plus
longtemps), cela peut arriver que deux machines commencent la session
presque en même temps (BGP est un bon exemple car il n'est pas
client-serveur).

Et tu donnes dans ce billet un exemple concret. Merci, ça tombe très bien :)

blog.rom1v.com