Vous êtes sur la page 1sur 5

!

Chapitre!2:#Le"modle"TCP/IP,'TCP'et'UDP!

normalis! par! lIETF.! Il! est! constitu! de! quatres! couches:! La! couche! hoteYrseau!
regroupe!les!fonctionnalits!des!couches!liaison!de!donnes!et!physique!du!modle!OSI!
et!o!les!couches!transport!et!application!sont!des!couches!de!bout!en!bout.!Une!couche!
est! dite! de! bout! en! bout! si! elle! est! implante! sur! les! entits! terminales! de!
communication!mais!pas!sur!les!entits!intermediares!(routeur,!switchs).!
Pile TCP/IP
+-------------------------------+
|
Applications
|
+-------------------------------+
|
TCP/UDP
|
+-------------------------------+
|
IP
|
+-------------------------------+
|
Hote-rseau
|
+-------------------------------+!

1 Gnralits!
1.1 Protocoles!de!transport!OSI!!

OSI$a$dfini$5$classes$de$TP$(Transport$Protocol)!:!
TP0!:!Pas!de!multiplexage,!Pas!de!reprise!sur!erreurs!
TP1$:$Pas$de$multiplexage,$Reprise$sur$erreurs$signales$par$le$niveau$Rseau$!
TP2$:$Multiplexage,$Avec$ou$sans$contrle$de$congestion,$Pas$de$reprise$sur$
erreurs!!
TP3$:$Multiplexage,$Avec$ou$sans$contrle$de$congestion,!Reprise!sur!erreurs!
signales!
TP4$:$Multiplexage,$Avec$ou$sans$contrle$de$congestion,$Reprise$sur$erreurs$
signales)et)non)signales)!
TP#classe#0#:#adapt#aux#rseaux#fiables!
TP#classe#4#:#adapt#aux#rseaux non fiables (ex. IP) !

1.2 Protocoles!de!transport!TCP/IP!!
UDP$(User&Datagram&Protocol)&~"TP"classe"0"
Dfini&en&1980&(RFC&768)!
Trs%simple%:%aucun%contrle%derreurs%ou%de%congestion!
Adapt'aux'rseaux'fiables'ou'bien'si'la'fiabilit'nest'pas'requise'!
Agressif(pour(le(rseau((peu(recommand(en(gnral)(!
TCP$(Transmission&Control&Protocol)&~"TP"classe"4"
Dfini&en&1981&(RFC&793)!
Complexe(:(connexions(fiables,(contrle(de(flux,(contrle(de(congestion!
Adapt'aux'rseaux'non'fiables!
Trs%adaptatif%(trs%recommand%en%gnral)%!
DCCP$(Datagram&Congestion&Protocol)&~"TP"classe"2"
Dfini&en&2006&(RFC&4336)!
Complexit+moyenne+:+connexions+non+fiables,+avec+contrle+de+congestion+
Corrige'le'principal'dfaut'de'UDP'(lagressivit)'!

1.3 Origines!de!lInternet!
En! 1962:! DARPA! a! initi! un! projet! de! recherches! sur! un! rseau! qui! permettra!
linterconnexion! dordinateurs! appartenant! ! des! structures! diffrentes! du!
gouvernement!(il!y!a!l!un!besoin!douverture!de!ces!structures!sur!leur!envionnement).!
En! 1969! :! Quatre! ordinateurs! hbrgs! au! MIT,! lUCLA,! Stanford,! Santa! Barbara! et!
lUTAH!sont!connects!dans!le!premier!rseau!de!donnes!informatique!:lARPANET!
Entre! 1972Y1990:! le! NCP! (Network! Control! Protocol)! est! remplac! par! le! TCP/IP.! Des!
applications!apparaissent!(la!mssagerie!en!1972,!le!DNS!en!1982,!le!WWW!en!1989).!
1990Y!Aujourdhui!:!Le!rseau!qui!transportaient!des!fichiers!de!donnes,!des!messages!
et!des!documents!transportent!aujourdhui!des!chantillons!de!voix!!sur!IP!(VoIP)!grace!
! des! protocols! adapts,! suivi! du! dveloppement! des! applications! de! tlvision/radio!
(streaming).!
Les! protocoles! IP,! TCP! et! UDP! ainsi! que! tous! les! protocoles! applicatifs! qui! ont! t!
dvelopps!font!partie!de!ce!qui!a!t!convenu!dappel!le!modle!TCP/IP.!CeluiYci!a!t!
!

1!

2 Protocole!UDP!(User!Datagram!Protocol)!

UDP!(RFC!768)!est!un!protocole!non!fiable!et!sans!connexion.!Il!permet!!une!application!
denvoyer!un!message!!une!autre!avec!un!minimum!de!fonctionnalits!(pas!de!
garnantie!darrivee,!pas!de!controle!de!flux,!de!nongestion.!Il!est!par!les!applications!
telles!que!les!requites!de!configuration!dynamique!DHCP,!les!requites!DNS,!les!chnages!
RIP.!Dans!les!application!audio!et!video.!
Le!champs!protocole!du!paquet!IP!transportant!un!datagramme!UDP!contient!la!valeur!
17.!
Port!Source!
Port!Destination!
Longueur!
Checksum!
Donnes!
!
!
!
!

3 TCP!
Le protocole TCP est dfini dans le but de fournir un service de transfert de donnes de haute
fiabilit entre deux ordinateurs "matres" raccords sur un rseau de type "paquets
commuts", et sur tout systme rsultant de l'interconnexion de ce type de rseaux.!Le!
champs!protocole!du!paquet!IP!transportant!un!segment!TCP!contient!la!valeur!06.!

3.1 Motivations!
TCP prtend fournir un service de communication de processus processus, dans un
environnement rseau complexe. TCP est dfini comme un protocole de communication "host
to host", c'est dire de matre matre (par opposition "central terminal").
La communication entre systmes d'information joue un rle croissant dans les domaines
militaires, institutionnels, scientifiques et commerciaux. TCP prend en compte en tout premier
lieu les exigences du secteur militaire, en particulier les exigences de fonctionnement avec des

2!

communications peu fiables et dans une situation de congestion du rseau. La plupart de ces
problmes sont rencontrs aussi dans les domaines non militaires.
Au fur et mesure que les rseaux de communication informatiques caractre stratgiques
ou tactiques sont dploys, il devient essentiel de trouver un moyen d'interconnexion de ces
rseaux, et des standards de transmission de donnes permettant de supporter une vaste
gamme d'applications. Anticipant le besoin de tels standards, le dput et sous-secrtaire
d'tat la recherche de la Dfense Amricaine a officialis le protocole dcrit ici en tant que
base pour la standardisation des processus d'intercommunication de donnes du Dpartement
de la Dfense Amricaine (DoD).
TCP est un protocole scuris orient connexion conu pour s'implanter dans un ensemble de
protocoles multicouches, supportant le fonctionnement de rseaux htrognes. TCP fournit
un moyen d'tablir une communication fiable entre deux tches excutes sur deux
ordinateurs autonomes raccords un rseau de donnes. Le protocole TCP s'affranchit le
plus possible de la fiabilit intrinsque des couches infrieures de communication sur
lesquelles il s'appuie. TCP suppose donc uniquement que les couches de communication qui
lui sont infrieures lui procurent un service de transmission de paquet simple, dont la qualit
n'est pas garantie. En principe, TCP doit pouvoir supporter la transmission de donnes sur une
large gamme d'implmentations de rseaux, depuis les liaisons filaires cbles, jusqu'aux
rseaux commuts, ou asynchrones.
TCP s'intgre dans une architecture multicouche des protocoles, juste au-dessus du protocole
Internet IP. Ce dernier permet TCP l'envoi et la rception de segments de longueur variable,
encapsuls dans un paquet Internet appel aussi "datagramme". Le datagramme Internet
dispose des mcanismes permettant l'adressage d'un service TCP source et un destinataire,
quelles que soient leur position dans le rseau. Le protocole IP s'occupe aussi de la
fragmentation et du rassemblage des paquets TCP lors de la traverse de rseaux de plus
faibles caractristiques. Le protocole IP transporte aussi les informations de priorit,
compartimentation et classification en termes de scurit relatives aux segments TCP. Ces
informations se retrouvent alors transmises de bout en bout de la communication.

complte de donnes jusqu' un point spcifi, l'utilisateur activera la fonction "push" de TCP.
Cette fonction oblige TCP transmettre rapidement les donnes situes avant le point spcifi
vers le destinataire. Il n'est nul besoin de fournir un marqueur spcifique pour ce point, dans
la mesure o le destinataire accepte ces donnes comme un transmission normale.

3.2 Fonctionnement!TCP!
Comme notifi ci-avant, TCP est conu pour fournir un service de transmission de donnes
scuris entre deux machines raccords sur un rseau de paquets comme IP. Pour pouvoir
assurer ce service mme au dessus d'une couche de protocole moins fiable, les fonctionnalits
suivantes sont ncessaires:
Transfert de donnes de base
Correction d'erreur
Contrle de flux
Multiplexage
Gestion de connexions
Priorit et Scurit
Ces fonctionnalits sont dcrites en grandes lignes dans les paragraphes qui suivent.
3.2.1 Transfert!de!donnes!de!base!
TCP est capable de transfrer un flux continu de donnes entre deux ordinateurs, en
dcoupant ce flux en paquets ou datagrammes. En gnral, TCP dcide de lui-mme l o le
flux de donnes doit tre coup.
Parfois les utilisateurs ont besoin de savoir que toutes les donnes soumises TCP ont bien
t mises. La fonction "push" a t prvue a cet effet. Pour s'assurer de la transmission

3!

3.2.2 Contrle!d'erreur!
TCP doit considrer et traiter les cas de donnes perdues, errones, dupliques, ou arrives
dans le dsordre l'autre bout de la liaison Internet. Ceci est ralis par l'insertion d'un
numro de squence, et par l'obligation d'mission d'un "accus de rception" (ACK) par le
TCP destinataire. Si l'accus de rception n'est pas reu au bout d'un temps prdfini, le
paquet sera rmis. Ct rcepteur, les numros de squence sont utiliss pour reconstituer
dans le bon ordre le flux original, et liminer les paquets dupliqus. L'limination des erreurs
physiques de transmission se fait par encodage d'un Checksum l'mission, recalcul de ce
Checksum par le destinataire, et limination des paquets pour les quels les deux valeurs ne
correspondent pas.
Tant que TCP fonctionne correctement, et que le rseau Internet n'est pas satur, aucune faute
de transmission ne devrait transparatre dans la communication. TCP est donc sens rcuprer
les erreurs de la transmission Internet.
3.2.3 Contrle!de!flux!
TCP fournit un moyen au destinataire pour contrler le dbit de donnes envoy par
l'metteur. Ceci est obtenu en retournant une information de "fentre" avec chaque accus de
rception indiquant la capacit de rception instantane en termes de numros de squence.
Ce paramtre not "window" indique le nombre d'octets que l'metteur peut envoyer avant
une autorisation d'mettre ultrieure.
3.2.4 Multiplexage!
Pour permettre plusieurs tches d'une mme machine de communiquer simultanment via
TCP, le protocole dfinit un ensemble d'adresses et de ports pour la machine. Un "socket" est
dfini par l'association dune adresse Internet avec un port sur la mme machine (le champs
port). Une connexion ncessite la mise en place de deux sockets lune sur celui qui reoit la
demande de connexion et lautre sur celui qui linitie. Une socket peut tre utilise par
plusieurs connexions distinctes sur la mme machine.
L'affectation des ports aux processus est tabli par chaque ordinateur. Cependant, il semble
judicieux de rserver certains numros de ports pour des services caractriss et souvent
utiliss. Ces services standard pourront alors tre atteints via ces ports "rservs".
L'affectation, l'utilisation et l'apprentissage des ports associs d'autres services moins
courants ou propritaires ncessiteront l'utilisation de mcanismes plus dynamiques.
3.2.5 Connexions!
Les mcanismes de fiabilisation et de contrle de flux dcrits ci-dessus imposent TCP
l'initialisation et la maintenance de certaines informations pour chaque communication. La
combinaison de ces informations, dont les sockets, les fentres, et les numros de squence
formeront ce que nous appelons une connexion. Chaque connexion est identifie de manire
unique par sa paire de sockets, dfinissant chacun des deux sens de la communication.
Lorsque deux processus dsirent communiquer, leur TCP respectifs doivent tout d'abord
ngocier et tablir une connexion (initialiser ces informations d'tat de part et d'autre).
Lorsque la communication s'achve, elle sera ferme, en librant ses ressources d'autres
usages.
Dans la mesure o l'on considre que les ordinateurs, ainsi que le rseau Internet n'est pas
d'une fiabilit absolue, on utilise une mthode d'initialisation par ngociation bilatrale base
!

4!

sur une horloge pour les numros de squence initiaux et tous les calculs seffectuent ensuite
en modulo 32.

Notez qu'une case reprsente une position bit.


Port source: 16 bits
Le numro de port de la source.
Port Destinataire: 16 bits
Le numro de port du destinataire.
Numro de squence: 32 bits
Le numro du premier octet de donnes par rapport au dbut de la transmission (sauf si SYN
est marqu). Si SYN est marqu, le numro de squence est le numro de squence initial
(ISN) et le premier octet pour numro ISN+1.
Accus de rception: 32 bits
Si ACK est marqu ce champ contient le numro de squence du prochain octet que le
rcepteur s'attend recevoir. Une fois la connexion tablie, ce champ est toujours renseign.
Data Offset: 4 bits
La taille de l'en-tte TCP en nombre de mots de 32 bits. Il indique l ou commence les
donnes. L'en-tte TCP, dans tous les cas une taille correspondant un nombre entier de
mots de 32 bits.
Rserv: 6 bits
Rservs pour usage futur. Doivent ncessairement tre 0.
Bits de contrle: 6 bits (de gauche droite):
URG: Pointeur de donnes urgentes significatif
ACK: Accus de rception significatif
PSH: Fonction Push
RST: Rinitialisation de la connexion
SYN: Synchronisation des numros de squence
FIN: Fin de transmission

Fentre: 16 bits
Le nombre d'octets partir de la position marque dans l'accus de rception que le rcepteur
est capable de recevoir.
Checksum: 16 bits
Le Checksum est constitu en calculant le complment 1 sur 16 bits de la somme des
complments 1 des octets de l'en-tte et des donnes pris deux par deux (mots de 16 bits). Si
le message entier contient un nombre impair d'octets, un 0 est ajout la fin du message pour
terminer le calcul du Checksum. Cet octet supplmentaire n'est pas transmis. Lors du calcul
du Checksum, les positions des bits attribus celui-ci sont marques 0.
Le Checksum couvre de plus une pseudo en-tte de 96 bits prfixe l'en-tte TCP. Cette
pseudo en-tte comporte les adresses Internet source et destinataires, le type de protocole et la
longueur du message TCP. Ceci protge TCP contre les erreurs de routage. Cette information
sera vhicule par IP, et est donne comme argument par l'interface TCP/Rseau lors des
appels d'IP par TCP.
+--------+--------+--------+--------+
|
Adresse source
|
+--------+--------+--------+--------+
|
Adresse destinataire
|
+--------+--------+--------+--------+
| zro | PTCL | Longueur TCP|
+--------+--------+--------+--------+
La longueur TCP compte le nombre d'octets de l'en-tte TCP et des donnes du message, en
excluant les 12 octets de la pseudo en-tte.
Pointeur de donnes urgentes: 16 bits
Communique la position d'une donne urgente en donnant son dcalage par rapport au
numro de squence. Le pointeur doit pointer sur l'octet suivant la donne urgente. Ce champs
n'est interprt que lorsque URG est marqu.
Options: variable
Les champs d'option peuvent occuper un espace de taille variable la fin de l'en-tte TCP. Ils
formeront toujours un multiple de 8 bits. Toutes les options sont prises en compte par le
Checksum. Un paramtre d'option commence toujours sur un nouvel octet. Il est dfini deux
formats types pour les options:
Cas 1: Option mono-octet.
Cas 2: Octet de type d'option, octet de longueur d'option, octets de valeurs d'option.
La longueur d'option prend en compte l'octet de type, l'octet de longueur lui-mme et tous les
octets de valeur et est exprime en octets.
Notez que la liste d'option peut tre plus courte que ce que l'offset de donnes pourrait le faire
supposer. Un octet de remplissage (padding) devra tre dans ce cas rajout aprs le code de
fin d'options. Ce octet est ncessairement 0.
Voici quelques options dfinies et leur longueur (type indiqu en octal):
Type Longueur Description
0
Fin de liste d'option
1
Nop
2
4
Taille de segment maximale (MSS: Maximum Segment Size)
Dfinition des options spcifiques
Fin de liste d'options
+--------+
|00000000|
+--------+
Type=0

3.2.6 Priorit!et!Scurit!
Les exploitants de TCP peuvent indiquer le degr de scurit et la priorit de la
communication tablie. TCP permet cependant de ne pas traiter ce besoin.

3.3 Format!de!l'enNtte!
Les paquets TCP sont envoys sous forme de datagrammes Internet. L'en-tte IP transmet un
certain nombre de paramtres, tels que les adresses Internet source et destinataires. L'en-tte
TCP est plac la suite, contenant les informations spcifiques au protocole TCP. Cette
division permet l'utilisation de protocoles autres que TCP, au dessus de la couche IP.

5!

6!

Ce code indique la fin du champ d'options. Sa position peut ne pas concider avec l'indication
du dbut du champ de donnes marqu dans l'Offset de donnes. Il doit tre plac aprs toutes
les options, et non aprs chaque option. Il ne doit tre utilis que dans le cas ou la fin des
options ne concide pas avec le dbut du champ de donnes.
No-Operation
+--------+
|00000001|
+--------+
Type=1
Cette option peut tre utilise entre deux options, par exemple pour aligner le dbut d'une
option sur un dbut de mot de 16 bits. L'utilisation de ce sparateur n'est pas une obligation.
L'implmentation doit donc prvoir de pouvoir prendre en compte une option mme au milieu
d'un mot.
Taille maximale de segment
+--------+--------+---------+--------+
|00000010|00000100| Taille max. seg |
+--------+--------+---------+--------+
Type=2 Longueur=4

chaque ACK reu portant sur une valeur plus grande que les ACK prcdemment
reus : cwnd = cwnd + 1/cwnd
on transmet la fentre de taille min(awin, cwnd)
Notons qu' chaque RTT, la taille de cwnd augmente au maximum de 1 segment. !Le passage
d'un algorithme l'autre est guid par une valeur seuil : l'entier slow start threshold (ssthresh)

Donne d'option : Taille maximale de segment: 16 bits


Si cette option est prsente, elle communique l'metteur la taille maximale des segments
qu'il pourra envoyer. Ce champ doit tre envoy dans la requte de connexion initiale (avec
SYN marqu). Si cette option est absente, le segment pourra tre pris de n'importe quelle
taille.
Bourrage (padding): variable
Les octets de bourrage terminent l'en-tte TCP:
de sorte que le nombre d'octet de celle-ci soit toujours multiple de 4 (32 bits)
de sorte que l'offset de donnes marqu dans l'en-tte corresponde bien au dbut des
donnes applicatives.

initialisation : ssthresh = 65535


if (cwnd < = ssthresh) cwnd += 1; else cwnd += 1/cwnd; !
Ce que fait TCP en cas de perte
!Si expiration d'un timeout : !ssthresh = max(cwnd/2, 2); cwnd = 1; !
! Le principe utilis est : croissance additive, dcroissance multiplicative.
!Si 3 ACK identiques sont reus, TCP n'attend pas l'expiration du timer et remet les trames
(Fast Retransmission).
Selon les versions de TCP, le comportement diffre :
TCP tahoe : redmarrage slow start (=> cwnd = 1)
TCP Reno : ssthresh = max(cwin/2, 2), cwnd = ssthresh, entre en mode fast
recovery
TCP New Reno : voir plus bas
!Mode fast recovery : remission du 1er paquet non acquitt (perdu) puis attente d'un ACK,
si non rception, mode slow start. !
TCP New-Reno modifie le comportement de TCP Reno lorsqu'on reoit un ACK "partiel"
c'est--dire un ACK qui acquitte au moins le segment perdu (celui qui nous a fait
entrer en Fast Recovery) mais pas tous les segments envoys. Lors de la rception d'un
tel ACK, TCP Reno quitte le mode de Fast Recovery ce qui pose un problme de
performance lorsque plusieurs segments d'une mme fentre sont perdus (les trames
sont souvent perdues en rafale). TCP New-Reno ne quitte le mode de Fast Recovery
que si l'ACK reu acquitte tous les segments envoys. A la rception d'un ACK
partiel, New- Reno retransmet immdiatement le paquet suivant le dernier paquet
acquitt dans cet ACK, diminue la taille de la fentre du nombre de paquets acquitts
par cet ACK partiel et retransmet un paquet si c'est permis par la taille de cwnd.

3.4 Contrle de congestion

3.5 Ouverture!et!Fermeture!de!connexion!TCP!

Avec TCP, chaque partie utilise une fentre en mission. La taille de cette fentre est
min(awin, cwnd) o awin (advertised window) est la taille de la fentre que propose
l'metteur et cwnd (congestion window) est un entier qui volue en fonction des pertes de
paquets constats. cwnd permet de traiter les problmes de congestion (i.e. de surcharge) du
rseau.

Louverture!de!connexion!se!fait!avant!de!pouvoir!envoyer!les!donnes.!Louverture!se!
base! sur! les! flags! SYN! et! ACK! et! se! droule! en! trois! tapes! (ThreeYway! Handshake)!
comme!dcrit!dans!la!figure!suivante:!
Le!client!commence!par!crer!le!contexte!de!communication!appel!TCB!(Transmission!
Control!Bloc)!relatif!!la!connexion!en!cours!douverture.!Ensuite,!il!envoie!un!segment!
o!le!drapeau!SYN!est!mis!!1,!le!champs!numro!de!sequence!gnr!de!faon!alatoire!
et!une!ou!plusieurs!options!dans!le!champs!options!(voir!options!ciYdessus).!Le!serveur!a!
dj!ouvert!passivement!une!connexion!(la!fonction!listen).!Ceci!lui!permet!de!recevoir!
sur! le! port! indiqu! par! lui,! le! segement! envoy! par! le! client.! A! son! tour! il! cre! un! PCB!
pour!cette!connexion,!gnre!un!champus!numro!de!sequence!initial,!remplit!le!champs!
Accus!de!rception!avec!numro!de!sequence!reu!+1!,!met!les!bits!ACK!et!SYN!!1,!
insre! ses! propres! options! TCP! et! calculi! enfin! le! champs! Checksum.! Le! segement!
rsultat! est! renvoy! au! client.! Le! client,! ! la! reception! de! ce! segment,! renvoie! un!
nouveau! segment! ayant! le! champs! ACK! ! 1,! les! options! acceptes,! un! numro! de!
sequence! augment! de! 1,! et! un! Accus! de! reception! calcul! comme! par! le! serveur! et!
considre! dsormais! la! connexion! tablie.! A! la! reception! de! ce! segment,! le! serveur! de!

3.4.1 Fonctionnement!du!contrle!de!congestion!TCP!!!
TCP utilise alternativement deux algorithmes
Slow start
au dmarrage : cwnd = 1 segment
chaque ACK reu portant sur une valeur plus grande que les ACK prcdemment
reus : cwnd = cwnd +1
on transmet la fentre de taille min(awin, cwnd)
Notons qu' chaque RTT (Round Time Trip), la taille de cwnd double (RTT 1 : 1
paquet + 1 ACK ; RTT 2 : 2 paquets + 2 ACK; RTT 3 : 4 paquets + 4 ACK; ...). Cette
croissance dite additive est donc exponentielle.
!Congestion avoidance

7!

8!

son! ct! considra! la! reception! tablie.! Lenvoi! des! donnes! peut! maintenant!
commencer.!
!

!
!
!
Aprs!que!toutes!les!donnes!aient!t!changes,!le!client!ou!le!serveur!peuvent!initier!
la!fermeture!de!la!connexion.!CelleYci!se!droule!en!quatre!phases.!
Lapplication!sur!le!client!demande!la!fermeture!de!la!connexion!!lentit!TCP.!Lentit!
sassure!!denvoyer!toutes!les!donnes!dans!le!buffer!ddi!!lapplication!puis!met!un!
segment!ayant!le!flag!FIN!mis!!1.!Le!rcepteur!du!segment!FIN,!renvoie!un!segment!ACK!
et!indique!!son!application!la!demande!de!fermeture.!Lorsque!lapplication!est!prte!!
la!fermeture,!elle!lindique!!son!entit!TCP!qui!envoie!un!segment!FIN!!son!tour!et!
attend!le!segment!ACK!correpsondant.!A!sa!reception!considre!la!connexion!ferme!et!
libre!toutes!les!ressources!qui!lui!taient!alloues.!Le!client!lui!attend!le!double!du!MSL!
(Maximum!Segment!Life,!environs!2!minutes!sur!IP)!avant!de!librer!les!ressources.!

9!

4 Conclusion!

TCP! et! UDP! deux! protocoles! normaliss! par! lIETF,! rpondent! ! des! besoins! diffrents!
des! applications! sexcutant! sur! un! rseau! de! donnes.! Dans! ce! chapitre,! nous! avons!
examin!les!foncions!les!importantes!de!TCP.!Dautres!details!concernant!par!exemple!le!
calcul! de! la! fentre! glissante! (sliding! window),! lestimation! correcte! du! RTT! sont! tout!
aussi! importants! et! illustrent! les! dveloppements! continus! apports! ! TCP! afin!
dameliorer!ses!perfromances!ou!de!rpondre!!de!nouveaux!besoins!comme!la!scurit!
ou!la!qualit!de!service.!

10!