Rappelle : protocole IP

Transcription

1 Couche transport

2 Introduction

3 Rappelle : protocole IP Fonctionnalités d IP Adressage Routage Fragmentation/Ré-assemblage Mode non-connecté Limitations IP n est pas fiable : il ne fait pas Séquencement Détection des duplications Détection de perte et retransmission Contrôle de flux IP est un protocole Best effort

4 Couche transport : rôle Pallier les imperfections des couches basses pertes, erreurs, paquets en désordre Ajuster les vitesses d'envoi et de réception contrôle de flux Traiter les congestions dans le réseau Contrôle de gestion Optimiser les performances du transfert

5 Couche transport Deux entités connectés par la couche réseau ressemblance avec la couche liaison Transfert de données entre deux processus selon une qualité de service demandée Distinguent les applications au sein d'un même hôte Garantissent l'indépendance des communications

6 Couche Transport Transporter les messages de bout en bout Unité d information : T-PDU ou Segments Application Application Présentation Présentation Session Transport Protocole de transport Session Transport Réseau Réseau Liaison Liaison Physique Physique

7 Couche transport : fonctions Adressage station, port Multiplexage plusieurs connexions transport utilisant la même adresse réseau Service sans connexion (UDP) avec connexion (TCP) qualité de service fiabilité, délai, gigue, débit

8 Adressage des applications Plusieurs applications peuvent s'exécuter en parallèle sur un ordinateur Problème : comment préciser à quelle application est adressé un datagramme? Solution : les ports 16 bits Pour contacter une application (@ IP, numéro de port)

9 Démultiplexage des ports

10 Protocoles de transport de l Internet Service en mode non connecté : protocole UDP UDP : User Data Protocol transport rapide, non connecté, permettant la multicast Service en mode connecté : protocole TCP TCP : Transmission Control Protocol transport fiable en mode connecté point-a-point DCCP (Datagram Congestion Control Protocol) Contrôle de congestion sur UDP SCTP (Stream Control Transmission Protocol) Protocole versatile et configurable

11 Mise en oeuvre du transfert fiable

12 Transfert fiable en mode connecté Besoin d échanger de données de manière fiable Ex. : FTP, SMTP, HTTP, Possible d'offrir ce service en s'appuyant sur un service non fiable non connecté comme IP ou UDP Éléments essentiels : les accusés de réception (ACKownledgement) des temporisateurs (timer) : alarmes qui expirent (timeout) la numérotation des paquets (ou données)

13 Accusés de réception (ACK) L émetteur attend une confirmation de réception du récepteur avant d'envoyer un autre paquet Le récepteur accuse réception d'un paquet en envoyant un ACK

14 Temporisateurs (timer) Des paquets peuvent être perdus dans le réseau Si paquet "perdu", pas d'ack Blocage! Utilisation d'un timer lors de l émission du paquet : si expire, renvoie le paquet si réception ACK avant expiration, désactivation du timer

15 Temporisateurs : problème de réglage Scénario du timer trop court et mise en cause fiabilité : Le paquet 1 est accepté deux fois par le récepteur! Le deuxième ACK est pris pour celui du paquet 2! Mais si timer trop long, on perd en efficacité

16 Fenêtre glissante (ou à anticipation) Principe : émettre n paquets sans attendre d'ack (n est la taille de la fenêtre) un temporisateur par paquet émis la réception de l ACK du premier paquet de la fenêtre la fait glisser

17 Efficacité de la fenêtre glissante La fenêtre glissante permet d'exploiter au mieux le réseau :

18 Fenêtre glissante et gestion des acquittements Si un paquet est perdu, deux solutions rejet total (ou global) rejet sélectif

19 Fenêtre glissante et gestion des acquittements Rejet total : aucun paquet suivant celui perdu n'est acquitté

20 Fenêtre glissante et gestion des acquittements : rejet sélectif

21 Transmission bidirectionnelle Équiper les deux côtes de fenêtres d émission et de réception pas forcement de même taille! Piggybacking Les paquets peut contenir un ACK

22 Transmission Control Protocol (TCP)

23 TCP Transmission Control Protocol Transfert de flots d octets fiable Orienté connexion Entre processus applicatifs Services rendus par TCP Fiabilité Contrôle de flux Contrôle de congestion Multiplexage/démultiplexage Phases Connexion Transfert Fermeture

24 Encapsulation user data application data server FTP TCP TCP header application data Segment TCP IP IP header TCP header application data Ethernet header 14 IP header 20 TCP header 20 Paquet IP application data Ethernet trailer 4 Ethernet driver Ethernet Trame Ethernet

25 Un flot TCP

26 Service TCP Obtenu par la création de «sockets» Adresse IP (32 bits) + Port (16 bits) numéro de port : identifiant numérique d'application Paire (port, hôte) : «socket» Pour accéder au service TCP, il faut donner explicitement les 2 «sockets» Une connexion est identifiée par deux extrémités Plusieurs connexions peuvent fonctionner simultanément

27 Les ports TCP (1) : Certains numéros de ports sont standardisés par l'iana (well known port numbers) cf. fichier /etc/services sur une machine Unix Port Nom Signification 20, 21 ftp Transfert de fichiers 23 telnet Connection à distance 25 smtp Courrier electronique 53 domain Serveur de noms

28 Les ports TCP (2) : Parfois, on n'utilise pas le port standard Plusieurs applications sur le même serveur ex : plusieurs serveurs web, plusieurs transferts FTP Pas de port associé "Sécurité" : cacher l'info Dans ce cas, il est nécessaire de se mettre d'accord sur le numéro de port à utiliser Par des échanges explicites applicatifs exemple : mode passif FTP Explicitement, en programmant / configurant une application En communiquant ce numéro au correspondant

29 Format d un segment TCP

30 Format d un segment TCP

31 Numéros de port Numéro de port source (16 bits) Identifier l application source Numéro de port destinataire (16 bits) Identifier l application destinataire N de port et IP = socket (socket de source, socket de dest.) : identifier une connexion Port : fixes et réservés Port : distribués dynamiquement

32 Numéros de séquence

33 Numéros d acquittement Identifie des octets reçus Numéro d acquittement = prochain numéro de séquence que le récepteur attend = numéro de séquence du dernier octet reçu + 1 = numéro de séquence du dernier segment reçu + la taille du segment

34 Numéro d acquittements : exemple Exemple d'une communication bidirectionnelle L'émetteur commence à un numéro de séquence de 432 et le récepteur de 1030 Si l'on vient à dépasser 2 32, on repart à 0

35 Champ longueur de l en-tête

36 Champ Fenêtre Nombre d octets que le récepteur peut accepter Utilisé pour le contrôle de flux

37 Les flags URG (URGent) Données urgentes Urgent pointer Valide si URG=1 Numéro de séquence du dernier octet de donnée urgente ACK (ACKnowledgement) ACK = 1 : le segment contient un ACK ACK = 0 : ne pas en tenir compte PSH (PuSH) restituer les données à l utilisateur immédiatement même si le buffer n est pas plein RST Reset Signifie qu'il a y eu un problème grave Connexion libérée immédiatement SYN (SYNchronisation) mise en place de la connexion SYN=1, ACK=0, demande ; SYN=1, ACK=1, acceptation FIN fin de connexion

38 Checksum Porte sur TCP header + data + pseudo header pseudo header (12 bits) IP src dest + ToP (type of protocol) + longueur du segment TCP permet de vérifier que les données sont correctes que les ports sont corrects que les adresses IP sont correctes (erreur de routeurs)

39 Options Longueur variable Fait partie de l en-tête TCP Exemple de l option MSS : maximum segment size Facteur d échelle de la fenêtre

40 MSS (Maximum Segment Size) La taille max des données dans un segment souvent MTU-40 (pourquoi?) dépend de la taille des buffers de réception par défaut 536 (576 octets pour le pkt IP) Difficile a choisir pour l'internet si trop petit, perte d'efficacité si trop grand, risque de fragmentation L'idéal est le plus grand tel qu'aucun datagramme n'est fragmenté

41 Session TCP

42 Notion de session TCP Un échange TCP est plus qu'une suite de messages Ordre des messages préservé Possède un début et une fin Initialisation de la connexion : échange de messages pour se mettre d'accord sur les numéros de séquence Termination de la connexion : transmission des segments non acquittés avant de finir effectivement la communication

43 Ouverture d une connexion Mode client/serveur Établir les numéros de séquence initinaux et la taille de MSS (Maximum Segment Size)

44 Ouverture d une connexion : three way handshake L'ouverture d'une connexion s'effectue en 3 messages SYN : envoi du numéro de séquence initial de l'émetteur SYN ACK : acceptation de la connexion et envoi du numéro de séquence du récepteur ACK : acquittement du la bonne réception du numéro de séquence

45 Diagramme d'états : ouverture de connexion

46 Problème : confusion entre incarnations SYN 0 : 0 (0) <MSS 1024> SYN_SENT SYN_RCVD SYN 0 : 0 (0) ack 1, <MSS 1024> ESTABLISHED 0 : 1024 (1024) ack 1 ESTABLISHED 1 ère incarnation ack 1 2 ème incarnation SYN 0 : 0 (0) <MSS 1024> SYN_SENT SYN_RCVD SYN 0 : 0 (0) ack 1, <MSS 1024> ack 1 ESTABLISHED 0 : 1024 (1024) ack 1

47 Solution Le numéro de séquence initial ne commence pas à 0 afin de distinguer des connexions courtes successives

48 Fermeture d une connexion La fermeture d'une connexion s'effectue au moyen de deux messages FIN : indication que l'on n'a plus de données à transmettre ACK : acquittement de la fin de la communication et de la bonne réception de l'intégralité des données Connexion libérée lorsque chaque côté a indiqué qu'il n'avait plus de données à émettre

49 Fermeture de connexion TCP Client FIN (ack=2345, seq=10123 Serveur ACK (ack=10124) FIN (seq=3456) LAST_ACK Attendre 2MSL ACK (ack=3457) CLOSED Le client doit attendre 2MSL (Maximum Segment Life) avant de fermer la connexion permet à TCP au client de retransmettre le dernier ACK si perdu (timeout du serveur et retransmission du dernier FIN ) Une connexion TCP ne peut utiliser les adresses IP et numéros de port d une connexion dans l état 2MSL

50 Fermeture de connexion TCP FIN (ack=2345, seq=10123 Client Serveur CLOSED ACK (ack=10124) FIN (seq=3456) ACK (ack=3457) Attendre 2MSL RTO FIN (seq=3456) ACK (ack=3457)

51 Diagramme d'états : fermeture de connexion

52 TCP : transfert de données

53 Transfert de données : résumé Contrôle des erreurs ACK retransmission Contrôle de flux envois des segments par anticipation le récepteur régule la taille de fenêtre Contrôle de congestion si le réseau est trop encombré, réduire le débit d'envoi

54 Contrôle de flux (1) Contrôle de flux et de congestion par le mécanisme de fenêtre glissante TCP n'acquitte pas les segments mais les octets reçus Le segment ACK=j, W=k autorise théoriquement l émetteur à envoyer des octets jusqu au j + k - 1 Fenêtre d'émission dépend de la fenêtre annoncée par la destination rwnd la fenêtre de congestion (cwnd) discutée plus loin F = min (cwnd, rwnd)

55 Contrôle de flux (2) Fenêtre glissante se referme à chaque envoie avance à la réception de ACK

56 Contrôle de flux (3) Émetteur rapide, récepteur lent envoie de 4K fenêtre de 0, attente

57 En cas de perte (1) Détection des pertes Réception de trois acquittements dupliqués Non réception d un ACK avant certain délai RTO (round trip timeout)

58 ack 6145 ack 5889 ack 6401 Trois ACKs dupliqués : 256o de données passées à l appli rupture de séquence 256o en attente 256o en attente 256o en attente 256o en attente 256o en attente 256o en attente 256o en attente 256o en attente 2504o à l appli ack 6657 ack 6657 ack 6657 ack 6657 ack :6657 (256) ack :6913 (256) ack 1 (perdu) 6913:7169 (256) ack :7425 (256) ack :7681 (256) ack :7937 (256) ack :8193 (256) ack :8449 (256) ack :8705 (256) ack :8961 (256) ack 1 3 e ACK dupliqué 6657:6913 (256) ack 1 (retransmission)

59 Timeout

60 Politiques de retransmission Go-back-to-N : en cas de perte, la source retransmet tous les segments non-acquittés Retransmission sélective : en cas de perte, la source retransmet uniquement le segment non-acquitté

61 Contrôle de congestion : motivations Octobre 1986 : écroulement de l Internet due à la congestion L'émission de segments inutiles surcharge le réseau Les pertes sont souvent dues à des congestions (surcharge d'un équipement du réseau), Réduire le débit d'émission peut aider à résoudre le problème L'émetteur doit adapter le débit d'émission en fonction de sa perception de l'état du réseau

62 Contrôle de congestion : TCP TCP s appuie sur IP (sans connexion) TCP opère de bout-en-bout détection de la congestion peu fiable et indirecte Chaque source TCP agit «seule» pas de coopération entre sources Pertes de paquets interprétées comme un signal de la congestion L'émetteur n'a qu'une seule possibilité pour connaître l'état du réseau : les acquittements de segments L'absence de réception d'un acquittement (dans un délai raisonnable) indique que le segment correspondant a sans doute été perdu Possibilités alternatives : délai excessif, perte de l'acquittement

63 Fenêtre d'émission F - le nombre d'octets non acquittés que la source peut envoyer débit = F/RTT (formule de Little) RTT : round trip time Si congestion RTT augmente, réduction automatique du débit de la source mécanisme de contrôle : diminuer F

64 Fenêtre d'émission Fenêtre d'émission - nombre d'octets nonacquittés F = min (cwnd, rwnd) cwnd - variable maintenu par la source rwnd - fixé par la destination (en fonction du buffer), champs fenêtre annoncée

65 Phases de contrôle de congestion démarrage lent (slow start), au démarrage ou après une perte détectée par une temporisation récupération (fast recovery), après une perte détectée par retransmission rapide (fast retransmit) évitement (congestion avoidance), tous les autres cas

66 Slow start : principe Problème du démarrage (ou redémarrage) La transmission des données commence sans aucune connaissance de l état du réseau Objectifs du Slow Start Éviter d'envoyer une rafale après une période d'inactivité Atteindre rapidement le point d'équilibre Détection rapide d'une surestimation du point d'équilibre

67 Slow start: fonctionnement Utilisé au début d un transfert (cwnd < ssthresh) ou après la réparation d une perte détectée par timeout Slow Start Threshold (ssthresh) : détermine quel algorithme utilisé (slow start ou congestion avoidance) Valeur initiale de cwnd 2*MSS TCP sonde le réseau en augmentant cwnd pour en déterminer la capacité disponible Pendant le slow start, la cwnd est augmentée de MSS octets pour chaque ACK reçu acquittant de nouvelles données (cwnd * 2 par RTT) cwnd = cwnd + MSS Croissance exponentielle (multiplicative) Jusqu à ce que cwnd=ssthresh ou qu il y ait des pertes

68 Slow start : exemple A t= 0, cwnd =1 Augmentation exponentielle cwnd augmente de 1 MSS par ACK (double la cwnd par RTT) Arrêt de cette croissance quand Cwnd >= ss_thresh

69 Congestion avoidance Motivations Le point d'équilibre est considéré atteint Sonder le réseau pour obtenir de la bande passante supplémentaire Pendant le congestion avoidance, cwnd est augmentée d un segment par RTT Augmentation linéaire de la fenêtre "Additive increase" Congestion avoidance jusqu à ce qu il y ait des pertes

70 Congestion avoidance : exemple Quand cwnd >= SS_threshold Incrémente cwnd de 1 segment par RTT ou de 1/cwnd par ACK

71 Retransmission Timeout (RTO) Lorsqu un émetteur détecte une perte (i.e. de la congestion) par épuisement du timer Diminution multiplicative du ss_thresh (facteur 0.5) ssthresh = max (FlightSize/2, 2*MSS) cwnd = 1 MSS Passe à la phase slow sart Décroissement multiplicatif (Multiplicative Decrease)

72 Exemple

73 Évolution de cwnd

74 Fast Retransmit Principe Retransmission anticipée Au delà de 3 ACK dupliqués reçus, une perte s'est produite Fonctionnement A la réception du 3e ACK dupliqué retransmettre le segment perdu

75 Fast Recovery Après une phase fast retransmit, TCP repart en mode collision avoidance (croissance linéaire), sans passer par la phase de slow start (croissance exponentielle) présence d'une congestion modérée puisque les segments suivants ont été reçus En cas d'expiration d'un timer, TCP repart en phase de slow start une congestion plus importante Autorise un débit élevé en présence de congestion modérée

76 Contrôle de congestion : synthèse Principe : AIMD Augmentation de la taille de sa fenêtre tant qu'il y a aucune perte : additive increase (AI) Diminution de la taille de sa fenêtre à chaque événement de pertes: multiplicative decrease (MD) Slow Start Traite du démarrage ou de la reprise: Éviter une congestion par une rafale Atteindre rapidement le point d'équilibre Incrément de cwnd: 1 MSS par nouvel ACK Arrêt: cwnd >= ss_thresh Congestion Avoidance Sonder le réseau pour obtenir de la bande passante supplémentaire AI: Incrément de cwnd: (1/cwnd) MSS par nouvel ACK Fast Recovery Maintenir l'auto-synchronisation pendant la reprise Retransmission du segment perdu sur 3 ACK dupliqués

77 Évolution d une connexion TCP window size in KB Slow Start AIMD time in RTT Fast Recovery ssthresh cwnd connection establishment connection tear-down

78 Evolution de TCP RFC 793 (1981) aucun contrôle de congestion Unix BSD 4.2 (1983) 1ère souche TCP/IP largement disponible TCP Tahoe (1988), slow start, congestion avoidance, fast retransmit TCP Reno (1990), tahoe+ fast recovery TCP New reno (1996), fast retransmit pour pertes multiples Le plus largement utilisé de nos jours TCP Vegas (1994), Utilisation d'un historique pour réduire la fenêtre avant perte TCP SACK (SelectiveACK, 1996), acquittements sélectifs

79 Compatibilité à TCP TCP est majoritaire dans l'internet (80-90 % des paquets) Tous les flots sont supposés se comporter comme ayant le contrôle de congestion de TCP TCP-friendly ou TCP-compatible Contrôle de congestion de TCP défini un standard Nouveaux algorithmes doivent être TCP-friendly Un flot "insociable" peut obtenir de la bande passante au détriment d'un flot TCP

80 User Datagram Protocol (UDP)

81 UDP Objectifs Service IP étendu à la remise de processus à processus Mode non connecté Service simple et protocole léger Pas d'état à gérer Pas de délai de connexion Efficacité de transmission (en-tête petit) Pas de contrôle du débit Pas de contrôle de flux Pas de contrôle de congestion Risque de causer des congestions dans le réseau Risque de perturber les flots TCP Non-fiable Service best effort

82 UDP: utilisation Besoin d'échange rapide et bref Pas d'établissement de connexion Ex. DNS Besoin de garder le contrôle au niveau de l'application Contraintes temporelles Retransmission inadaptée ou conditionnelle Ex : applications temps réel, visio et audio conférences Besoin de nouvelles fonctionnalités Ex : multicast

83 Format d un datagramme UDP Port source et dest. Identique à TCP Longueur Taille l entête + données Redondant avec IP Checksum Facultatif Identique à TCP Entête + données +pseudo-entête

84 Résumé : TCP et UDP Deux protocoles de transport principaux UDP : minimaliste fournit simplement des numéros de port TCP : fiabilité (acquittement), notion de connexion (ouverture, fermeture de session), contrôle de congestion (contrôle de la fenêtre d'émission) Lorsqu'une congestion survient TCP adapte son débit UDP subit des pertes Co-existence à priori non-équitable vis-à-vis du débit de TCP Aujourd'hui une majorité des flux dans Internet sont des flux TCP D'autres améliorations existent (ECN,...) et d'autres protocoles sont proposés (DCCP, SCTP,...)