Cours Tcp
Upcoming SlideShare
Loading in...5
×
 
  • 2,415 views

Services et protocoles de la couche Transport

Services et protocoles de la couche Transport

Statistics

Views

Total Views
2,415
Views on SlideShare
2,415
Embed Views
0

Actions

Likes
0
Downloads
65
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cours Tcp Cours Tcp Document Transcript

  • Services et protocoles de la couche Transport ? Crée un circuit de communication logique entre des applis application transport s’exécutant sur des hôtes network data link distants physical network data link network physical log ? Les protocoles de la couche data link ica physical transport ne s’ exécutent qu’ au l network en data link d extrémités -e physical network nd data link ? Services transport vs réseau : physical tr an network Couche réseau : Transfert de sp ? data link or données entre machines physical t ? Couche transport : Transfert de application transport données entre applis network data link • Se fonde sur les services de la physical couche réseau et les améliore 2: Application Layer 1 Protocoles de couche de transport Services de transport dans application Internet : transport network data link network ? Fiable, réception dans physical data link network physical l’ ordre des paquets (TCP) log data link ica physical Contrôle de congestion l network en ? data link d Contrôle de flot -e ? physical network nd data link Mise en place de connection physical tr ? an network ? Non fiable (“Au mieux ”), sp data link or physical t sans garantie d’ ordre (UDP) ? Peut s’ étendre au multicast application transport ? Services non disponibles: network data link physical ? Temps-réel, garantie de délai ? Garantie de bande passante ? Multicast fiable 2: Application Layer 2 1
  • Multiplexage/demultiplexage segment – unité de données Demultiplexage: Distribution échangée entre deux de chaque segment à couches transport l’ application à laquelle il est ? TPDU: transport destiné protocol data unit Récepteur P3 P4 Données M M applicative application Entête de P1 transport P2 segment M M network application application segment Ht M transport transport network Hn segment network 2: Application Layer 3 Multiplexage/demultiplexage Multiplexage: Encapsuler les données de 32 bits plusieurs applis dans un segment avec une entête qui permettra le # port source # port dest Démultiplexage Autres champs d’ entête multiplexage/demultiplexage: ? Fondé sur le port de réception, le port d’ émission et les adresses IP Données ? Les ports source et applicative destination sont répetés (message) dans chaque segment ? Certaines applications utilisent des ports spécifiques format de segment TCP/UDP 2: Application Layer 4 2
  • Multiplexage/demultiplexage: exemples source port: x Web client host A dest. port: 23 server B host C source port:23 dest. port: x Source IP: C Source IP: C Dest IP: B Dest IP: B source port: y source port: x App telnet simple dest. port: 80 dest. port: 80 Source IP: A Dest IP: B Web Web client source port: x server B host A dest. port: 80 Serveur Web 2: Application Layer 5 UDP: User Datagram Protocol [RFC 768] ? Protocole de transport le plus simple Pourquoi UDP? ? Service “au mieux”, les ? sans délai de connexion segments UDP peuvent être: ? simple: sans nécessité d’ un ? Perdus état dans l’ émetteur et le ? Delivré dans le désordre récepteur ? Sans connexion: ? Petit entête ? Sans handshaking entre ? Sans contrôle de congestion: l’ émetteur et le UDP peut émettre aussi récepteur rapidement qu’ le souhaite il ? Chaque segment UDP est traité indépendamment des autres 2: Application Layer 6 3
  • UDP: suite ? Souvent utilisé pour les applications multimédias Taille en octet 32 bits (streaming multimedia) du segment # port source # dest source ? Tolérance aux pertes UDP incluant ? Sensible au débit l’ entête taille checksum ? Autre utilisation d’ UDP: DNS? SNMP ? ? Transfert fiable sur UDP: Données Applicative ajouter des mécanismes de (message) compensation de pertes à niveau applicatif ? Compensation de pertes adaptée à chaque format appplication de segment UDP 2: Application Layer 7 TCP: Survol RFCs: 793, 1122, 1323, 2018, 2581 ? point-à-point: ? Transfert bidirectionnel ? Un émetteur, un récepteur des données: ? Transfert bi-directionel de ? Fiable, réception dans données sur une connexion l’ ordre du flot d’octet: ? MSS: maximum segment ? Pas de « frontières de size message » ? Orienté connexion: ? Fenêtre d’ émission: ? handshaking (échange de msgs de control) initialise ? Les mécanismes de l’ état de l ’ émetteur et du contrôle de flot et de récepteur avant l’émission congestion règlent la taille de données de la fenêtre ? Contrôle de flot : ? Tampons de réception et ? L’ émetteur ne submerge d’ émission pas le récepteur application application writes data reads data socket socket door door TCP TCP send buffer receive buffer segment 2: Application Layer 8 4
  • Structure du segment TCP 32 bits URG: données Countage en octet urgentes source port # dest port # des données Numéro sequence ACK: ACK # valide Numéro d’ ack head not PSH: push data now len used U A P R S F Taille de fenêtre rcvr # d’octets checksum ptr urgent que le rcvr RST, SYN, FIN: Peut accepter Options (variable) Pour la connexion application Internet data checksum (variable length) (comme UDP) 2: Application Layer 9 # de seqTCP et ACKs #’Seq.: Hote A Hote B ? « Numéro » du premier octet dans L’ utilisateur Seq =42, A le segment tape CK=7 9, data ‘C’ =‘ ’ C ACKs: ACK la réception ? # de seq du du ‘ , en C’ prochain octet =43, data =‘ ’ C envoyant attendu Seq =79 , ACK un echo ? ACK cumulé Q: Comment traiter les ACKs la segments arrivé en reception de Seq =4 l’ écho 3, désordre ACK= 80 ? R: La spec TCP ne le dit pas- laissé au concepteur time scenario simple telnet 2: Application Layer 10 5
  • TCP: Transfert fiable de données Émetteur simplifié evenement: réception de données de l’ application Créer un segment •Transmission dans un sens •Pas de contrôle de flot et de congestion wait evenement: temp de garde fini wait for pour le segment avec seq # y for event event Retransmet le segment evenementt: ACK reçu, avec ACK # y Traitement du ACK 2: Application Layer 11 Generation des ACKTCP [RFC 1122,2581] Evenement Action du récepteur Arrivée d’ segment dans un ACK mis en attente. Attendre jusqu’ 500ms à l’ ordre, sans trou, pour le segment suivant. Sinon envoyer l’ ACK Tout le reste a été ACKé Arrivée d’ segment dans un Envoyer immédiatement un ACK cumulé l’ ordre, sans trou, Un ACK en attente Arrivée d’ segment dans un Envoyer un ACK dupliqué, indiquant le seq. # le désordre avec un seq. # Du prochain octet attendu supérieur à l’ attente Arrivée d’ segment qui un Envoyer immédiatement un ACK si le segment remplit partiellement ou rempli un trou complètement le trou 2: Application Layer 12 6
  • TCP: Scénario de retransmission Host A Host B Host A Host B Seq=9 Seq=9 2, 2, 8 b 8 byte ytes d s data ata Seq=92 timeout Seq = 100, 20 by tes da timeout Seq=100 timeout ta =100 ACK 0 10 X K= AC ACK= 120 loss Seq=9 Seq=9 2, 2, 8 byte 8 byte s data s data 20 K=1 =100 AC ACK time time Timeout prematuré, ACK perdu ACK cumulé 2: Application Layer 13 Contrôle de Flot TCP Contrôle de flot Recepteur: informe L’ émetteur ne submerge explicitement l’émetteur pas le récepteur en de l’ espace vide (qui émettant trop rapidement change dynamiquement) ? champs RcvWindow RcvBuffer = Taille du tampon de réception TCP dans l’éntête TCP RcvWindow = espace vide dans le tampon émetteur: borne la taille des données transmise et non acquittées à RcvWindow Tampon de reception 2: Application Layer 14 7
  • TCP: Temps aller-retour (RTT) et temps de garde Q: Comment définir la Q: Comment estimer le RTT? valeur du temps de ? SampleRTT: temps mesuré garde dans TCP? depuis l’ émission du segment jusqu’ la réception de son ACK à ? Supérieur au RTT ? Ignorer les retransmissions ? note: RTT varie multiple, et les ACKs cumulés ? Trop petit : timeout ? SampleRTT varie: un RTT plus prematuré régulier est nécessaire ? Retransmissions ? Moyenner sur plusieurs redondante mesure récente du ? Trop long: lenteur de la SampleRTT réaction à la perte d’ un segment 2: Application Layer 15 TCP: Temps aller-retour (RTT) et temps de garde EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT ? Calcul de moyenne par pondération exponentielle ? L’ influence d’ échantillon est réduit un exponentiellement ? Valeur typique de x: 0.1 Le timeout ? EstimtedRTT plus une “marge de sécurité” ? Grande variation de EstimatedRTT -> plus grande marge de sécurité Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT| 2: Application Layer 16 8
  • TCP: Gestion de la Connexion ? L’ émetteur et le réception Poignée de main doivent initier une « connexion TCP » avant tripartite: d’échanger des données ? Initialiser les variables TCP: ? 1: le client envoit un segment ? seq. #s de contrôle TCP SYN ? Tanpons, information de ? Défini le seq # initial contrôle de flot (e.g. RcvWindow) ? 2: le serveur reçoit le SYN, et ? client: initiateur de la répond par un segment de connexion contrôle SYNACK Socket clientSocket = new Socket("hostname","port ? ACKs le SYN reçu number"); ? alloue des tampons ? server: contacté par le client Socket connectionSocket = ? specifie le seq.# initial du welcomeSocket.accept(); serveur-> récepteur 2: Application Layer 17 TCP: Gestion de Connexion (cont.) Fermer une connexion: client server close Le client ferme la socket: FIN clientSocket.close(); 1: le client envoit un segment ACK close TCP FIN au serveur FIN 2: le serveur reçoit le FIN, timed wait repond par un ACK. Ferme la ACK connexion et envoi un FIN. closed 2: Application Layer 18 9
  • TCP: Gestion de Connexion (cont.) 3: le client reçoit un FIN, et client server répond par un ACK. closing FIN ? Passe en attente et acquitte to les FINs qu’ reçoit il ACK closing 4: le serveur, reçoit l’ACK. FIN La connexion est fermé. timed wait ACK closed closed 2: Application Layer 19 TCP: Gestion de Connexion (cont.) Cycle de vie du serveur TCP Cycle de vie du client TCP 2: Application Layer 20 10
  • Principes du contrôle de Congestion Congestion: ? “trop de sources envoient trop de données trop rapidement dans le réseau” ? Différent du contrôle de flot! ? manifestations: ? Pertes de paquets (débordement des routeurs) ? delais important (file d’ attente dans les routeurs ) 2: Application Layer 21 Causes/coûts de la congestion: scenario 1 ? Deux émetteurs, deux récepteurs ? un routeur, mémoire infinie ? Pas de retransmission 2: Application Layer 22 11
  • Causes/coûts de la congestion: scenario 2 ? Un routeur, mémoire finie ? L’ émetteur retransmet les paquets perdus 2: Application Layer 23 Causes/coûts de la congestion: scenario 2 ? ? = ? (goodput) in out ? Si la retransmission est parfaite : ? > ? out in ? La retransmission de paquet non perdu rend ? que dans le cas in parfait “coûts” de la congestion: ? Plus de travail (retrans) pour un même débit utile (“goodput”) ? Retransmissions redondantes 2: Application Layer 24 12
  • Approches du contrôle de congestion Deux approches principales : Contrôle de congestion Contrôle de congestion de Bout-en-bout : assisté par le réseau: ? Pas de feedback explicite ? Les routeurs fournissent un du réseau feedback aux émetteurs ? La congestion est estimé ? Un bit d’annonce de grace à l’ observation des congestion (SNA, pertes et des délais de DECbit, TCP/IP ECN, bout en bout. ATM) ? approche suivi par TCP ? Débit d’émission explicite 2: Application Layer 25 Contrôle de Congestion TCP ? Contrôle de bout-en-bout ? Le débit est limité par la taille de la fenêtre de contrôle de congestion Congwin Congwin ? w segments, chacun avec MSS octets transmis durant un RTT: w * MSS throughput = Bytes/sec RTT 2: Application Layer 26 13
  • Contrôle de Congestion TCP ? “probing” pour la bande ? Deux “phases” passante disponible: ? slow start ? idealement: émettre le plus ? congestion avoidance rapidement possible ? Variables importante: (Congwin aussi grand que ? possible) sans pertes Congwin ? augmenter Congwin jusqu’ à ? threshold: defini le une perte (congestion) seuil entre les deux phases ? perte: réduire Congwin, et recommencer 2: Application Layer 27 TCP Slowstart Host A Host B algorithme Slowstart one segm ent RTT initialiser: Congwin = 1 for (each segment ACKed) two segm ents Congwin++ until (loss event OR four segm CongWin > threshold) ents ? Augmentation exponentielle (par RTT) de la taille de la fenêtre time ? perte? : timeout (Tahoe TCP) ou or trois ACKs dupliqués (Reno TCP) 2: Application Layer 28 14
  • TCP Congestion Avoidance Congestion avoidance /* slowstart est fini */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 2: Application Layer 29 AIMD TCP et justice TCP congestion avoidance: Justice: Si N sessions ? AIMD: additive TCP partage un même increase, lien chacune doit multiplicative obtenir 1/N de la decrease capacité du lien ? Augmente la fenêtre TCP connection 1 de 1 par RTT ? Réduit la fenêtre d’ facteur 2 en cas un de pertes bottleneck TCP router connection 2 capacity R 2: Application Layer 30 15
  • TCP est il juste? Deux sessions en parallele ? Incrément additif génére une pente de 1, ? La réduction multiplicative réduit le débit proportionnellement R Connection 2 throughput Partage égal Connection 1 throughput R 2: Application Layer 31 16