Upcoming SlideShare
×

# 3 transport.key

1,417 views

Published on

Computer Networking : Principles, Protocols and Practice

1 Like
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

Views
Total views
1,417
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
77
0
Likes
1
Embeds 0
No embeds

No notes for slide

The slides are part of an effort to develop an open-source networking textbook. See http://inl.info.ucl.ac.be/CNP3 for the current version of the textbook and more information on how to contribute.

• To avoid overloading the slide, we assume that sequence numbers are integers. Of course, all computations must be performed modulo 2
N
.

• To avoid overloading the slide, we assume that sequence numbers are integers. Of course, all computations must be performed modulo 2
N
.

• To avoid overloading the slide, we assume that sequence numbers are integers. Of course, all computations must be performed modulo 2
N
.

• To avoid overloading the slide, we assume that sequence numbers are integers. Of course, all computations must be performed modulo 2
N
.

Other retransmission strategies are possible at the sender.

• MSL means Maximum Segment Lifetime

• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.
• In this example, the duplicate CR is likely to be a previous retransmission of the CR that was delayed in the network.

• The computation of the UDP checksum is defined in :

R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
• The computation of the UDP checksum is defined in :

R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
• The computation of the UDP checksum is defined in :

R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
• The computation of the UDP checksum is defined in :

R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988

• UDP is mainly used for applications where either short messages are exchanged or losses or not a severe problem (either because they can be supported by the application or because they are used in LAN environment where there are almost no losses)
Domain Name System, Network File System (NFS), Remote Procedure Call (RPC), jeux

Multimedia (conversational) applications such as VoIP or VideooverIP often use UDP. In this case, UDP is often combined with RTP

H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.RTP: A Transport Protocol for Real-Time Applications. RFC1889, Jan 1996

• TCP was defined in

J. Postel. Transmission control protocol. Request for Comments 793, Internet Engineering Task Force, September 1981.

It has been heavily modified since

A more detailed description of TCP may be found in

W. Stevens. TCP/IP Illustrated, volume 1 : The protocols. Addison-Wesley, 1994.

• Urgent pointer is rarely used and will not be described.

The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
• Urgent pointer is rarely used and will not be described.

The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
• Urgent pointer is rarely used and will not be described.

The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds
• MSL in IP networks : 120 seconds

• Le segment TCP avec le flag RST est &amp;#xE9;galement utilis&amp;#xE9; envoy&amp;#xE9; lorsqu&apos;une entit&amp;#xE9; TCP re&amp;#xE7;oit un segment TCP n&apos;ayant pas le bit SYN mis &amp;#xE0; vrai et qui est relatif &amp;#xE0; une connexion TCP n&apos;existant pas &amp;#xE0; ce moment sur cette entit&amp;#xE9;. Le segment RST peut &amp;#xE9;galement &amp;#xEA;tre utilis&amp;#xE9; pour informer l&apos;autre extremit&amp;#xE9; de la connexion TCP de probl&amp;#xE8;mes de syntaxe dans un segment TCP re&amp;#xE7;u. Tout envoi d&apos;un segment TCP avec le flag RST mis &amp;#xE0; vrai provoque la fin de la connexion TCP sur laquelle il est envoy&amp;#xE9;. Cependant, afin d&apos;&amp;#xE9;viter des envois permanents de segments RST, une entit&amp;#xE9; TCP n&apos;enverra jamais de segment RST en r&amp;#xE9;ponse &amp;#xE0; un segment RST.
• Le segment TCP avec le flag RST est &amp;#xE9;galement utilis&amp;#xE9; envoy&amp;#xE9; lorsqu&apos;une entit&amp;#xE9; TCP re&amp;#xE7;oit un segment TCP n&apos;ayant pas le bit SYN mis &amp;#xE0; vrai et qui est relatif &amp;#xE0; une connexion TCP n&apos;existant pas &amp;#xE0; ce moment sur cette entit&amp;#xE9;. Le segment RST peut &amp;#xE9;galement &amp;#xEA;tre utilis&amp;#xE9; pour informer l&apos;autre extremit&amp;#xE9; de la connexion TCP de probl&amp;#xE8;mes de syntaxe dans un segment TCP re&amp;#xE7;u. Tout envoi d&apos;un segment TCP avec le flag RST mis &amp;#xE0; vrai provoque la fin de la connexion TCP sur laquelle il est envoy&amp;#xE9;. Cependant, afin d&apos;&amp;#xE9;viter des envois permanents de segments RST, une entit&amp;#xE9; TCP n&apos;enverra jamais de segment RST en r&amp;#xE9;ponse &amp;#xE0; un segment RST.
• Le segment TCP avec le flag RST est &amp;#xE9;galement utilis&amp;#xE9; envoy&amp;#xE9; lorsqu&apos;une entit&amp;#xE9; TCP re&amp;#xE7;oit un segment TCP n&apos;ayant pas le bit SYN mis &amp;#xE0; vrai et qui est relatif &amp;#xE0; une connexion TCP n&apos;existant pas &amp;#xE0; ce moment sur cette entit&amp;#xE9;. Le segment RST peut &amp;#xE9;galement &amp;#xEA;tre utilis&amp;#xE9; pour informer l&apos;autre extremit&amp;#xE9; de la connexion TCP de probl&amp;#xE8;mes de syntaxe dans un segment TCP re&amp;#xE7;u. Tout envoi d&apos;un segment TCP avec le flag RST mis &amp;#xE0; vrai provoque la fin de la connexion TCP sur laquelle il est envoy&amp;#xE9;. Cependant, afin d&apos;&amp;#xE9;viter des envois permanents de segments RST, une entit&amp;#xE9; TCP n&apos;enverra jamais de segment RST en r&amp;#xE9;ponse &amp;#xE0; un segment RST.
• Le segment TCP avec le flag RST est &amp;#xE9;galement utilis&amp;#xE9; envoy&amp;#xE9; lorsqu&apos;une entit&amp;#xE9; TCP re&amp;#xE7;oit un segment TCP n&apos;ayant pas le bit SYN mis &amp;#xE0; vrai et qui est relatif &amp;#xE0; une connexion TCP n&apos;existant pas &amp;#xE0; ce moment sur cette entit&amp;#xE9;. Le segment RST peut &amp;#xE9;galement &amp;#xEA;tre utilis&amp;#xE9; pour informer l&apos;autre extremit&amp;#xE9; de la connexion TCP de probl&amp;#xE8;mes de syntaxe dans un segment TCP re&amp;#xE7;u. Tout envoi d&apos;un segment TCP avec le flag RST mis &amp;#xE0; vrai provoque la fin de la connexion TCP sur laquelle il est envoy&amp;#xE9;. Cependant, afin d&apos;&amp;#xE9;viter des envois permanents de segments RST, une entit&amp;#xE9; TCP n&apos;enverra jamais de segment RST en r&amp;#xE9;ponse &amp;#xE0; un segment RST.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• En pratique, cette ouverture simultann&amp;#xE9;e est assez rare car souvent le client choisit un num&amp;#xE9;ro de port TCP local eph&amp;#xE9;m&amp;#xE8;re pour contacter le serveur. Une ouverture simultan&amp;#xE9;e ne se produira en pratique que si le client et le serveur utilisent chacun un num&amp;#xE9;ro de port TCP &amp;#xAB;&amp;#xA0;bien connu&amp;#xA0;&amp;#xBB;.

Dans cette ouverture, le premier segment envoy&amp;#xE9; par chaque entit&amp;#xE9; est un segment dont le bit SYN est mis &amp;#xE0; vrai. Ensuite, apr&amp;#xE8;s avoir re&amp;#xE7;u le segment SYN, chaque entit&amp;#xE9; va acquiter ce segment SYN en envoyant un segment dont le bit ACK est mis &amp;#xE0; vrai et en acquittant le num&amp;#xE9;ro de s&amp;#xE9;quence annonc&amp;#xE9; dans le segment SYN re&amp;#xE7;u. Cet acquittement prouve que l&apos;entit&amp;#xE9; qui l&apos;envoie a bien re&amp;#xE7;u le segment SYN. Il faut noter que le bit SYN est mis &amp;#xE0; vrai dans le segment d&apos;acquittement car le segment SYN n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;. Lors de la r&amp;#xE9;ception de l&apos;acquit, le three-way handshake se termine pour l&apos;entit&amp;#xE9; qui le re&amp;#xE7;oit car &amp;#xE0; ce moment son SYN a &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9; et elle a acquit&amp;#xE9; le SYN envoy&amp;#xE9; par l&apos;autre entit&amp;#xE9;.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Cette machine ne prend pas en compte les retransmissions sur temporisateur.

Typiquement, un client va passer par les &amp;#xE9;tats Init, SynSent et Established. Un serveur passera lui par les &amp;#xE9;tats Init, SynRcvd et Established. Ce n&apos;est que lors d&apos;une ouverture simultan&amp;#xE9;e que le chemin suivi est Init, SynSent, SynRcvd, Established.

Dans la transition entre l&apos;&amp;#xE9;tat SYN-Sent et l&apos;&amp;#xE9;tat SYN-RCV, le bit ACK est positionn&amp;#xE9; pour acquitter le segment SYN re&amp;#xE7;u et le bit SYN est positionn&amp;#xE9; car la premi&amp;#xE8;re transmission n&apos;a pas encore &amp;#xE9;t&amp;#xE9; acquitt&amp;#xE9;e. Lors d&apos;une ouverture simultann&amp;#xE9;e, la transition entre SYN-RCVD et Established sera fera lors de la r&amp;#xE9;ception d&apos;un segment dont le bit ACK et le bit SYN seront positionn&amp;#xE9;s.
• Ces connexions doivent avoir des identificateurs diff&amp;#xE9;rents
choisie par l&apos;application serveur, en g&amp;#xE9;n&amp;#xE9;ral port fixe
en g&amp;#xE9;n&amp;#xE9;ral l&apos;application client laisse l&apos;entit&amp;#xE9; transport choisira le port source chaque fois qu&apos;elle &amp;#xE9;tabli une connexion. En pratique, l&apos;entit&amp;#xE9; de transport maintiendra une liste des connexions TCP actives et lorsqu&apos;un nouvelle connexion est demand&amp;#xE9;e elle choisira le premier num&amp;#xE9;ro de port TCP libre. Typiquement ces ports &amp;#xAB;&amp;#xA0;&amp;#xE9;ph&amp;#xE9;m&amp;#xE8;re&amp;#xA0;&amp;#xBB; auront des valeurs entre 1024 et 5000.
si il y a plusieurs connexions avec la m&amp;#xEA;me application serveur, l&apos;entit&amp;#xE9; transport du client choisira des valeurs diff&amp;#xE9;rentes pour les ports source utilis&amp;#xE9;s

Sur une machine Unix, il est possible de visualiser l&apos;&amp;#xE9;tat des connexions TCP activant en utilisant la commande netstat (man netstat)
bismarck!obo [5] netstat -n | more

TCP

-------------------- -------------------- ----- ------ ----- ------ -------
130.104.229.58.1023 130.104.229.109.2049 8760 0 8760 116 ESTABLISHED
130.104.229.58.1021 130.104.229.51.2049 49640 0 8760 0 ESTABLISHED
130.104.229.58.997 130.104.229.33.2049 33176 0 8760 0 ESTABLISHED
...

• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
• Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.

• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• La retransmission apr&amp;#xE8;s expiration du temporisateur est le seul m&amp;#xE9;canisme d&amp;#xE9;crit dans la sp&amp;#xE9;cification originale de TCP. Toutes les impl&amp;#xE9;mentations TCP actuelles le supportent. Le bon fonctionnement du m&amp;#xE9;canisme de retransmission d&amp;#xE9;pend de la bonne &amp;#xE9;valuation de la valeur &amp;#xE0; utiliser pour le temporisateur. Dans de nombreuses impl&amp;#xE9;mentations TCP, la valeur minimale du temporisateur est d&apos;une centaine de millisecondes, m&amp;#xEA;me si le d&amp;#xE9;lai entre l&apos;&amp;#xE9;metteur et le receveur n&apos;est que d&apos;une milliseconde.
• Cette figure a &amp;#xE9;t&amp;#xE9; obtenue en mesurant le d&amp;#xE9;lai aller-retour entre deux machines connect&amp;#xE9;es &amp;#xE0; Internet. Une &amp;#xE9;tait localis&amp;#xE9;e dans une universit&amp;#xE9; avec une bonne connexion et l&apos;autre &amp;#xE9;tait connect&amp;#xE9;e via un cable-modem introduisant parfois des variations importantes de d&amp;#xE9;lai.
• The computation of TCP&amp;#x2019;s retransmission timer is described in

RFC2988 Computing TCP&apos;s Retransmission Timer. V. Paxson, M. Allman. November 2000.

Usual values for alpha and beta are 1/8 and 1/4.
• See

P. Karn, C. Partridge, Improving round-trip time estimates in reliable transport protocols, Proc. ACM SIGCOMM87, August 1987
• Les timestamps TCP ont &amp;#xE9;t&amp;#xE9;s introduits dans :

RFC1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992.

L&apos;utilisation de ces timestamps est n&amp;#xE9;goci&amp;#xE9;e lors de l&apos;&amp;#xE9;tablissement de la connexion TCP. La plupart des impl&amp;#xE9;mentations TCP actuelles supportent ces extensions.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• Don&amp;#x2019;t forget that TCP&amp;#x2019;s acknowledgements are cumulative.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• See e.g.

RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
• Cette extension &amp;#xE0; TCP est d&amp;#xE9;finie dans :

RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
• Cette strat&amp;#xE9;gie dite des &amp;#xAB;&amp;#xA0;delayed acknowledgements&amp;#xA0;&amp;#xBB; est utilis&amp;#xE9;e par la plupart des impl&amp;#xE9;mentations TCP afin de r&amp;#xE9;duire le nombre de segments contenant uniquement un acquit transmis.

• Une extension &amp;#xE0; la version initiale de TCP, d&amp;#xE9;crite dans RFC1323 permet d&apos;utiliser des fen&amp;#xEA;tres dont la taille est sup&amp;#xE9;rieure &amp;#xE0; 64 Kbytes. Ces extensions commencent &amp;#xE0; &amp;#xEA;tre support&amp;#xE9;es par les impl&amp;#xE9;mentations TCP courantes.

L&apos;id&amp;#xE9;e de base de cette extension est relativement simple. Tout d&apos;abord, lors de l&apos;&amp;#xE9;tablissement de la connexion TCP, on s&apos;appuie sur le m&amp;#xE9;canisme d&apos;extension d&apos;ent&amp;#xEA;te pour transmettre de l&apos;information compl&amp;#xE9;mentaire et d&amp;#xE9;terminer si l&apos;autre entit&amp;#xE9; TCP de la connexion supporte les extensions RFC1323. Si oui, RFC1323, modifie un peu la s&amp;#xE9;mantique du champ window contenu dans l&apos;ent&amp;#xEA;te du TPDU TCP. Avant RFC1323, ce champ &amp;#xE9;tait cod&amp;#xE9; sur 16 bits. Avec RFC1323, il est maintenu sur N bits (32&gt;=N&gt;=16) dans chaque entit&amp;#xE9;, et le champ window du TPDU est utilis&amp;#xE9; pour transmettre les 16 bits de poids fort de cette fen&amp;#xEA;tre plut&amp;#xF4;t que l&apos;enti&amp;#xE8;ret&amp;#xE9; de la fen&amp;#xEA;tre.
• RFC896 Congestion control in IP/TCP internetworks. J. Nagle. Jan-06-1984.

Cet algorithme est impl&amp;#xE9;ment&amp;#xE9; dans toutes les impl&amp;#xE9;mentations de TCP ou presque, il ne n&amp;#xE9;cessite que quelques lignes de code.

Pour une description d&amp;#xE9;taill&amp;#xE9;e d&apos;une impl&amp;#xE9;mentation de TCP dans un kernel Unix, voir :

G. Wright, R. Stevens, TCP/IP Illustrated, volume 2, Addison-Wesley

Source :

http://www.nlanr.net/NA/Learn/packetsizes.html

Cette information date de quelques ann&amp;#xE9;es. Pour des statistiques plus r&amp;#xE9;centes sur les tailles des paquets, voir par exemple :

http://ipmon.sprint.com

et par exemple

http://ipmon.sprint.com/packstat/packet.php?030407

• See March/April 1995 issue of IEEE Network Magazine.

• L&apos;Internet a souffert de plusieurs &amp;#xE9;pisodes d&apos;effondrement &amp;#xE0; cause de la congestion lorsque les impl&amp;#xE9;mentations TCP ne supportaient que le contr&amp;#xF4;le de flux TCP de base d&amp;#xE9;fini dans [RFC793]. Par exemple, en 1986, le d&amp;#xE9;bit utilisable sur un chemin compos&amp;#xE9; de trois routeurs entre l&apos;universit&amp;#xE9; de Berkeley et le LBL en Californie &amp;#xE9;tait tomb&amp;#xE9; de 32 Kbps &amp;#xE0; 40 bits par seconde suite &amp;#xE0; la congestion.

Une premi&amp;#xE8;re solution au probl&amp;#xE8;me de la congestion avait &amp;#xE9;t&amp;#xE9; propos&amp;#xE9;e par Karn et Partridge sous la forme d&apos;un exponential backoff. L&apos;id&amp;#xE9;e de cette solution est que lorsqu&apos;un segment TCP retransmis est perdu, c&apos;est un signe de congestion importante et que si le m&amp;#xEA;me segment doit &amp;#xEA;tre transmis 4 fois, la congestion est plus importante que si un segment ne doit &amp;#xEA;tre retransmis qu&apos;une seule fois. La solution propos&amp;#xE9;e est la suivante :
- lorsqu&apos;un segment de donn&amp;#xE9;es qui a &amp;#xE9;t&amp;#xE9; retransmis pr&amp;#xE9;c&amp;#xE9;demment doit &amp;#xE0; nouveau &amp;#xEA;tre retransmis suite &amp;#xE0; l&apos;expiration du temporisateur de retransmission, la valeur de ce temporisateur est doubl&amp;#xE9;e.
Ainsi, il le temporisateur a initialement une valeur de 1 seconde, apr&amp;#xE8;s une premi&amp;#xE8;re expiration pour un segment donn&amp;#xE9;, il passera &amp;#xE0; 2 secondes, puis &amp;#xE0; 4, puis &amp;#xE0; 8,... En pratique, une impl&amp;#xE9;mentation de TCP fermera la connexion apr&amp;#xE8;s une dizaine d&apos;essais infructeux d&apos;envoi du m&amp;#xEA;me segment TCP

• La fen&amp;#xEA;tre de congestion est donc une variable maintenue par l&apos;&amp;#xE9;metteur et qui sert &amp;#xE0; limiter la quantit&amp;#xE9; d&apos;information que l&apos;&amp;#xE9;metteur peut envoyer sans attendre d&apos;acquits du receveur. Le receveur n&apos;est pas au courant de la valeur actuelle de la fen&amp;#xEA;tre de congestion.
• TCP congestion control was proposed in

V. Jacobson, Congestion avoidance and control, Proc. ACM SIGCOMM88, August 1988

A more detailed description may be found in :

RFC2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999.

• More detailed models can be found in the scientific literature :

M. Mathis,J. Semke, J. Mahdavi and T. Ott, The macroscopic behaviour of the TCP congestion avoidance algorithm, ACM Computer Communication Review, 1997