Master Spé MIAGE M1 UE Réseaux. La couche Transport. Emmanuel Hyon

Transcription

1 Master Spé MIAGE M1 UE Réseaux La couche Transport Emmanuel Hyon

2 2 Services et protocoles de transport Fournit une communication logique entre processus tournant sur des hosts Les protocoles de transport tournent dans les hôtes Services de couche transport vs réseau : Couche réseau : transfert de données entre hôtes Couche transport : transfert de données entre processus fondé sur les services (de couche) réseau application transport network data link physical network data link physical logical end-end transport network data link physical network data link physical network data link physical network data link physical application transport network data link physical

3 Rôle et défis du Transport Transformer les pptés pas tjs désirables du réseau en un service de haut niveau souhaité par les appli 3 Prendre en compte le service fourni par la couche réseau Pertes de paquets Déséquencements Duplications Erreurs MTU Temps de traversée imprévisibles Prendre en compte les besoins des applications Garantie de remise des msg Séquencement Absence de duplications Absence de messages erronés Messages de lg quelconque Synchronisation entre l'émetteur et le récepteur Contrôle de flux par le récepteur sur l'émetteur Support de +ieurs appli sur le même hôte

4 4 Protocoles de transport Internet Services de transport : Livraison fiable, séquencée et point à point (TCP) Contrôle de congestion Contrôle de flux Mode connecté Livraison non fiable ( besteffort ), non séquencée, point à point ou multicast (UDP) Services non disponibles : Temps réel Garantie de bande passante Multicast fiable application transport network data link physical network data link physical logical end-end transport network data link physical network data link physical network data link physical network data link physical application transport network data link physical

5 Multiplexage/démultiplexage un exemple introductif 5 Courrier interne dans une entreprise. Employé d'un service: remise du courrier dans une case courrier Une personne prend courrier amène au service courrier général Le service courrier trie les courriers par service L'employé chargé de la remise prend les courriers destiné à son service Les remets à leur destinataire.

6 Multiplexage démultiplexage Le but 6 Collecte des données envoyées par les différents processus et encapsulation dans des segments envoyés au medium. +sieurs applis tournent et emettent des données Il faut pouvoir les envoyer par le même canal service de multiplexage Livraison des segments reçus aux bons processus +sieurs applis tournent simultanément sur un même host Il faut pouvoir les identifier de façon non ambiguë service de demultiplexage

7 7 Multiplexage/démultiplexage Rappel : segment - unité de données échangées entre entités de couche transport = TPDU: Transport Protocol Data Unit Entête du segment segment APDU (message) H t M Hn segment P1 M application transport network P3 M récepteur M application transport network P4 M P2 application transport network

8 8 Implémentation des ports Port = référence abstraite L'implémentation diffère d'un OS à l'autre! En général, un port = une file de messages processus d'appli processus d'appli UDP processus d'appli ports files démux Insertion en queue (par UDP) Si file pleine, rejet msg Retrait en tête (par le processus) Si file vide, le processus se bloque jusqu'à ce qu'un msg soit disponible arrivée de segments

9 9 Numéros de port 3 catégories Ports well-known : de 0 à 1023 Alloués par l'iana Sur la plupart des systèmes, ne peuvent être utilisés que par des processus système (ou root) ou des programmes exécutés par des utilisateurs privilégiés Ports registered : de 1024 à Listés par l'iana Sur la plupart des systèmes, peuvent être utilisés par des processus utilisateur ordinaires ou des programmes exécutés par des utilisateurs ordinaires Ports dynamic/private : de à Alloués dynamiquement

10 Les ports quelques remarques 10 Chaque segment donne l'information sur le port local, port distant (ainsi que les adresses IP). Fermeture des ports Au niveau transport : on ne donne pas le droit à des sockets de se connecter (pas de socket d'accueil en TCP par exemple). Mais les paquets IP peuvent très bien arriver au terminal Fermeture selon le port distant Toutes les sockets dont le port distant est x ne peuvent être connectées Fermeture selon port local Aucune socket dont le port local est y ne sera acceptée

11 Serveur TCP et UDP 11 Un serveur TCP est GÉNÉRALEMENT concurrent Arrivée d une requête => le serveur l'accepte et crée un nouveau processus pour gérer le nouveau client (par ex, il fait un fork), cf le cours CAR sur le client/serveur ou le cours système. Identité du nouveau processus? Son n de port reste le même que celui du processus d'accueil (i.e. le client, n port client, n port serveur Un serveur UDP est généralement itératif les segments sont traités les uns à la suite des autres

12 Multiplexage/démultiplexage UDP 12 multiplexage/démultiplexage : Basé sur les n de ports source / destination pour N de ports source & dest dans chaque segment N de ports well-known pour des applications spécifiques Clé de démultiplexage de UDP = (#port) une fois sur le host 32 bits # port source # port dest Autres champs d entête APDU (message) Format de segment TCP/UDP

13 13 Le démultiplexage TCP TCP utilise le triplet (n de port distante, n de port distant) pour démultiplexer (identifier le processus destinataire du segment) Rappel : UDP utilise le n de port local (destinataire) pour identifier un processus POURQUOI?

14 Exercice démultiplexage 14 Pour UDP et TCP un envoi sur un même serveur B de : Plusieurs sockets provenant du même terminal A: ports locaux (sur A) x et y et distant 80 et 110 Plusieurs sockets provenant de C: port distant 80 et locaux x et y Client Web host C Source IP: A Dest IP: B source port: x dest. port: 110 Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Client Web host A Source IP: A Dest IP: B source port: x dest. port: 80 Application Web Serveur Web B

15 Le multiplexage TCP 15 Comment identifier chaque processus destinataire? Le port local sur le serveur distingue? Regarder les sockets provenants de A Le port distant sur le serveur distingue? Regarder les deux sockets provenants de B Les adresses IP sources suffisent-elles? Regarder les sockets de même port provenant de A et B Sur votre terminal tapez la commande netstat tau

16 16 UDP : User Datagram Protocol [RFC 768] Service best effort : les segments UDP peuvent être perdus ou déséquencés Pas de contrôle de congestion Service en mode non connecté Pas d établissement de connexion entre host émetteur et host récepteur => simplicité Chaque segment UDP est acheminé indépendamment des autres (pour la même communication) => déséquencement

17 Compléments sur UDP 17 Souvent utilisé pour les appli multimédia (flux) Tolérantes aux pannes Sensibles au débit Autres usages d UDP Lg en octets, du segment UDP entête incluse DNS SNMP Transfert fiable avec UDP : ajouter la fiabilité dans la couche application Recouvrement d erreurs spécifique pour l application 32 bits # port source # port dest length APDU (message) checksum Format du segment UDP

18 18 Le checksum UDP (facultatif en IPv4) But : détecter des erreurs (bits erronés) dans le segment émis Portée Le segment UDP L'en-tête UDP Le champ de données UDP Un pseudo-header (qui inclut des champs du datagramme) Champ IP protocol (8 bits cadrés à droite sur 16 bits) Champ (32 bits) Champ (32 bits)! Champ UDP length (16 bits) UDP est indissociable de IP!

19 19 Calcul du checksum UDP Émetteur : Le champ checksum est initialement mis à 0 La suite à protéger est considérée comme une suite de mots de 16 bits Calcul du Checksum Addition des mots de 16 bits (modulo ) puis Complément à 1 (inverse bit à bit) du résultat de l addition Insertion du checksum dans l entête Récepteur : Calcule le checksum du segment reçu Vérifie si le checksum calculé est NON - erreur détectée. Le segment est abandonné OUI - pas d erreur détectée Cas particulier : Le checksum dans le segment reçu est à 0 = il n a pas été calculé

20 20 Exercice : Calcul de checksum On suppose que les données à envoyer représentent x mots de 16 bits quel est le checksum? Le checksum est le complément à 1 de la somme des x mots. Exemple : Les données sont décomposées en 3 mots de 16 bits Le checksum donné sur le segment UDP est Dans quel(s) cas le segment est corrompu?

21 21 Segmentation En théorie Les segments UDP peuvent être segmentés par IP En pratique La plupart des applications utilisant UDP limitent leurs segments à 512 octets Pas de segmentation Pas de risque de message incomplet

22 TCP: Transmission Control Protocol RFCs: 793, 1122, 1323, 2018, Point à point Un émetteur, un récepteur Fiable, flux d octets ordonné Pas de délimiteurs de message Mode pipeline Les contrôles de congestion et de flux TCP fixent des tailles de fenêtres Full duplex Flux de données bidirectional sur la même connexion Mode connecté Établissement de connexion (handshaking) Contrôle de flux L émetteur n inonde pas le récepteur avec ses envois

23 23 TCP: orienté flux (Byte-oriented) TCP est orienté flux d'octets Le processus émetteur "écrit" des octets sur la connexion TCP Le processus récepteur "lit" des octets sur la connexion TCP TCP ne transmet pas d'octets individuels En émission TCP bufferise les octets jusqu'à en avoir un nombre raisonnable TCP fabrique un segment et l'envoie En réception TCP vide le contenu du segment reçu sans un buffer de réception Le processus destinataire vient y lire les octets à sa guise

24 24 TCP: orienté flux (Byte-oriented) processus émetteur écrit des octets processus récepteur lit des octets TCP buffer d'émission TCP buffer de réception transmet des segments

25 25 Construction d'un segment (envoi concret: des segments) Quand est-ce que TCP décide d'envoyer un segment? Taille du champ de données d un segment = MSS (MaximumSize Segment) octets Dépend de l implantation de TCP (1500, 536, 512 oct) Autre contrainte liée à la taille du champ de données d une trame (MTU) Le processus lui demande explicitement Fonction push Le temporisateur expire Pour éviter d'attendre trop longtemps MSS octets

26 26 Entête TCP Champ de données (message) Segment TCP (couche 4) Entête IP Champ de données (segment TCP) Datagramme IP (couche 3) Entête Champ de données (datagramme IP) Trame (couche 2) MTU MTU en-tête IP en-tête TCP

27 27 header Le segment TCP data source port destination port sequence number acknowledgment number data offset unused U R G A C K P S H R S T S Y N F I N window checksum options urgent pointer padding data

28 28 Les champs de l'en-tête TCP source port : identifie le processus source sur la machine source destination port : identifie le processus destinataire sur la machine destinataire checksum : obligatoire, calculé sur la totalité du segment et sur le pseudo en-tête data offset : lg de l'en-tête en mots de 32 bits unsused : 6 bits à 0 options : MSS, padding : alignement de l'entête sur 32 bits Fiabilité sequence n : N du 1er octet de données du segment (sauf si SYN=1 : ISN) acknowledgment n : acquitte tous les octets de données de N strictement inférieur Contrôle de flux rcvwindow : # d'octets de données que le destinataire du segment est prêt à recevoir Flags RST, SYN et FIN : pour l établissement et la fermeture de connexion ACK : 1 si le champ acknowledment number est significatif PSH : 1 si fin d'un msg logique (push) URG : 1 si données urgentes urgent pointer : pointe sur la fin (comprise) des données urgentes

29 29 TCP : fiabilité du transfert de données Fiabiliser le transfert de données sur un «canal» avec erreur et perte processus données TCP : protocole de transfert fiable de données segment processus données TCP : protocole de transfert fiable de données segment Canal non fiable TCP : Contrôle d'erreur et Contrôle de flux

30 Fiabilité Mécanismes 30 Principe de base: Dire quels sont les paquets reçus et quels sont les paquets non reçus. On identifie ceux qui ne sont pas reçus et on les réemet. Exercice Donner un exemple de protocole qui permette de mettre en place un contrôle des paquets reçu afin de n'en perdre aucun. On supposera tout d'abord qu'il n'y a pas de pertes des paquets de contrôle. Application dans un cadre plus général du contrôle d erreurs

31 31 Contrôle d'erreur Repose sur Le champ Checksum : idem à UDP Permet de savoir si un bit est erroné Le champ SequenceNumber Permet de détecter la perte de segment (si déséquencement) Des acquittements Permet de prévenir l autre extrémité des pertes (sur déséquencement) Des retransmissions Permet de remédier aux pertes de segments et aux réceptions de segments erronés Un temporisateur de retransmission

32 Sequence number (identifications des octets envoyés) 32 TCP : transport de flux d octets Numérotation des octets : Sequence number Représente le numéro du 1er octet dans le segment Exercice : donner les n de séq des deux premiers segments, du 5ème et du dernier pour Un fichier de octets émis par A MSS = 1000 octets La numérotation des octets commence à 0 Nb segments = 500, dans 1 segment : 1000 octets 1er segment : de 0 à 999-2ème segment : de 1000 à 1999 Le 5ème segment : de 4000 à 4999 Le dernier segment : de à

33 Sequence number (suite) 33 Et si le segment a un champ de données vide? 1er échange : segment d établissement de connexion SYN = 1 et sequence # = ISN Fin d échange : segment de fin de connexion Segment d accusé de réception Sequence # = sequence # +1

34 34 ACK number Numéro du prochain octet attendu A Seq # = 1999, Ack # = 10 Seq # = 10, Ack # = 2000 Acquitte (accuse réception) de tous les octets reçus jusqu à ACK # - 1 (strictement inférieur au ACK #) B A a reçu de B les octets de 0 à 9. Le prochain octet attendu par A est 10 B a reçu de A les octets de 0 à Le prochain octet attendu par B est 2000

35 35 Exercice Exemple simple d une application : echo A B A initie le dialogue : il saisit la lettre «C» B lui renvoie la lettre saisie Représenter Le séquence #, le ACK # et le champ data de chaque segment échangé entre A et B avec les hypothèses suivantes : La connexion est déjà établie La numérotation de A commence à 42, celle de B à 79 La lettre «c» = 1 octet

36 36 Corrigé A B Seq # = 42, Ack # = 79, data= c Seq # = 79, Ack # = 43, data= c Seq # = 43, Ack # = 80 Piggyback : Utiliser le même segment pour envoyer des données et acquitter des données reçues

37 37 La génération des ACK [RFC 1122, RFC 2581] Event Action Arrivée séquencée d un segment Pas de perte, Tous les octets précédents sont déjà acquittés Arrivée séquencée d un segment Pas de perte, un ACK en attente d envoi Arrivée déséquencée d un segment seq. # > à seq # attendu Perte détectée ACK retardé. Attente jusqu à 500ms d un prochain segment à émettre. S il n y en a pas, envoi du ACK Émission immédiate d un ACK cumulatif (un seul ACK accuse réception de +sieurs segments) Envoyer un ACK dupliqué, indiquant le seq. # du prochain octet attendu

38 TCP: scénarios de retransmission 38 Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92, 8 bytes data timeout X perte ACK=100 Seq=92, 8 bytes data Seq=100 timeout Seq=92 timeout Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data ACK=100 time Perte d acquittement => réemission de A B jette le segment retransmis (il l a déjà) ACK=120 time Expiration de temporisateur avant arrivée du ACK => réémission (seul le segment concerné est réémis. Le 2ème segment n a pas besoin d être réémis)

39 39 TCP: scénarios de retransmission Host A Host B Seq=92, 8 bytes data Seq=92 timeout Seq=100, 20 bytes data X perte ACK=100 ACK=120 time Perte d acquittement mais l ACK cumulatif évite la retransmission du 1er segment

40 40 Dimensionnement du temporisateur Q: Quelle doit être la valeur du temporisateur? Suffisament grand pour qu un aller-retour se produise (émission segment - retour ACK) => > RTT Attention : le RTT varie Si T trop court : expiration prématurée Retransmissions inutiles Si T trop long: manque de réactivité à la perte de segment Q: Comment estimer le RTT? SampleRTT: temps écoulé entre transmission segment jusqu à réception ACK Pb : SampleRTT varie, il diffère d un segment à l autre Temps de traversée du réseau dépend du trafic Travailler avec un échantillon de valeurs

41 Valeur du temporisateur 41 La valeur du temporisateur est une estimation du RTT à laquelle on ajoute une marge de sécurité Plus la variation de EstimatedRTT est grande, plus la marge de sécurité doit l être également La valeur vaut donc Timeout = EstimatedRTT + 4*Deviation Où Deviation estime la variation de SampleRTT par rapport à EstimatedRTT Et EstimatedRTT : moyenne pondérée entre l'estimation précédente et le dernier échantillon mesuré du RTT L influence d un échantillon donné décroit exponentiellement vite EstimatedRTT = α*estimatedrtt + (1 α)*samplertt

42 Dimensionnement du temporisateur 42 Problème un ACK n'acquitte pas une transmission, mais une réception transm. retransm. ACK SampleRTT trop grand transm. retransm. ACK SampleRTT trop petit Algorithme de Karn-Partridge ne mesurer SampleRTT que pour les segments envoyés une seule fois calcul de TimeOut à chaque retransmission, doubler la valeur de TimeOut, jusqu'à ce que la transmission réussisse pour les segments suivants, conserver la valeur du TimeOut, jusqu'à ce qu'un segment soit acquitté du 1er coup recalculer TimeOut à partir de EstimatedRTT

43 Contrôle d erreur : le pipelining 43 Mécanisme d anticipation des émissions sans acquittement : protocole Go-Back-N (GBN) base nextseqnum Taille de fenêtre N (=14) Déjà acquittés Émis, non acquittés N utilisables, encore non émis [nextseqnum, base+n-1] N non utilisables base+n Taille de N? cf. le contrôle de flux

44 44 Contrôle de flux L émetteur n inonde pas le récepteur en émettant trop, et trop vite RcvBuffer = taille des buffers de réception RcvWindow = espace libre dans les buffers Contrôle de flux récepteur: informe explicitement l émetteur de l espace disponible dans les buffers (=> nb d octets qu il est prêt à recevoir) champ rcvwindow dans le segment TCP émetteur: conserve un volume de données transmises non acquittées inférieur au RcvWindow le plus récemment reçu Buffers de réception RcvWindow : variable DYNAMIQUE! Varie au cours de la même connexion TCP

45 45 Questions Un host B alloue une taille RcvBuffer de buffer en réception pour une connexion TCP avec un host A LastByteRead = n du dernier octet lu par l application B dans le buffer LastByteRcvd = n du dernier octet arrivé par le réseau et placé dans le buffer Quelle est la relation entre ces trois variables? Soit RcvWindow la taille de la fenêtre (espace disponible dans le buffer de taille RcvBuffer). Exprimer RcvWindow en fonction des trois autres variables

46 46 Réponses Relation entre RcvBuffer, LastByteRead et LastByteRcvd LastByteRead RcvBuffer Valeur de RcvWindow LastByteRcvd RcvBuffer LastByteRead LastByteRcvd RcvWindow (Rq : à l initialisation, RcvWindow = RcvBuffer)

47 47 Relation entre RcvBuffer, LastByteRead et LastByteRcvd LastByteRead Valeur de RcvWindow Réponses LastByteRcvd - LastByteRead RcvBuffer RcvBuffer LastByteRcvd Ex : RcvBuffer = 1000 LastByteRead = 1000 LastByteRcvd = 2000 RcvWindow = RcvBuffer - (LastByteRcvd - LastByteRead) RcvBuffer LastByteRead LastByteRcvd RcvWindow (Rq : à l initialisation, RcvWindow = RcvBuffer)

48 48 Côté émetteur L host émetteur stocke Les données envoyées et en attente d'acquittement Les données passées par le processus émetteur mais non encore émises processus émetteur TCP LastByteWritten LastByteAcked LastByteSent

49 49 Questions Caractériser le volume de données envoyées non acquittées Caractériser le volume de données passées par le processus et non envoyées Quelle est la relation que A doit vérifier avant d émettre pour assurer le contrôle de flux? Soit SentBuffer : taille du buffer émission. Quelle est la relation que A doit vérifier avant d accepter une écriture de y octets par un processus? LastByteSent - LastByteAcked LastByteWritten - LastByteSent LastByteSent - LastByteAcked RcvWindow (LastByteWritten LastByteAcked) + y SentBuffer

50 Réouverture de fenêtre 50 Et si la fenêtre est fermée? RcvWindow=0 => plus de place dispo chez le récepteur L émetteur est bloqué en attente d ouverture de fenêtre Quand le processus récepteur aura lu des données Déblocage sur réception d un seg avec RcvWindow > 0 Et si le récepteur n a rien à émettre? Dans TCP, un ACK ne peut être envoyé que sur réception de données (approche smart sender/dumb receiver) Solution Lorsque l'émetteur reçoit une RcvWindow à 0, il envoie périodiquement un segment d 1 octet de données pour provoquer l'envoi d'un ACK

51 51 Le contrôle de congestion Congestion Informellement : trop de sources envoient trop de données, trop rapidement, plus que ce que le réseau peut absorber Différent du contrôle de flux! Manifestations Perte de segments (overflow des buffers aux routeurs) Long retards (temps d attente élevés dans les buffers des routeurs) Un des 10 problèmes majeurs en réseau!

52 52 Approches pour le contrôle de congestion Deux grandes approches : Contrôle de congestion de bout en bout : Pas d informations explicites de la part du réseau La congestion est supposée par le système terminal à partir de l observation de pertes et de retards Approche mise en œuvre dans TCP Contrôle de congestion assisté réseau : Les routeurs fournissent des informations aux systèmes Un bit indicateur de congestion (SNA, DECbit, ATM, une extension detcp/ip)

53 TCP : Contrôle de Congestion 53 Contrôle de bout en bout IP ne fournit aucune information sur l état du réseau Le taux de transmission des segments est limité par la taille de la fenêtre de contrôle de flux w segments, chacun de MSS octets, envoyés chaque RTT sec throughput = w * MSS RTT Bytes/sec Nouvelle donnée : la fenêtre de congestion Congwin Congwin

54 RcvWindow vs CongWin 54 AvecTCP gestion de deux fenêtres Une fenêtre pour le contrôle de flux La taille de la fenêtre a un impact sur le nombre de segments envoyés par anticipation (sans ACK) LastByteSent - LastByteAcked RcvWindow Une fenêtre pour le contrôle de congestion Pour prendre en compte ces deux fenêtres : LastByteSent - LastByteAcked min(rcvwindow,congwin)

55 TCP : Contrôle de Congestion Calcul de la fenêtre de congestion idéale» 55 recherche de la bande passante utilisable Idéalement : transmettre aussi vite que possible sans perte (Congwin aussi grand que possible) Initialiser Congwin à 1 MSS Augmenter Congwin jusqu à avoir une perte (congestion) Perte : réinitialiser Congwin, puis recommencer à augmenter Deux phases Le slow start L évitement de congestion Variables importantes Congwin threshold: définit le seuil entre les deux phases (quand finit le slow start et commence l évitement de congestion)

56 56 Phase 1 : Le Slowstart Algorithme Slowstart Host A Host B Init.: Congwin = 1 for (each segment ACKed) augmenter Congwin until (perte OR CongWin > threshold) RTT un segment deux segments quatre segments Augmentation exponentielle (par RTT) (1, puis 2, puis 4, puis 8, ) Détection de perte : expiration du temporisateur (algo TCP Tahoe) et/ou trois ACKs dupliqués (algo TCP Reno) time

57 57 Phase 2 : L évitement de Congestion Évitement de Congestion /* slowstart terminé */ /* Congwin > threshold */ Until (perte) { chaque w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 1 Recommencer le slowstart Variante si l algo Reno TCP est mis en œuvre : il lance le slowstart (fast recovery) après trois ACKs dupliqués

58 58 TCP : protocole en mode connecté Rappel: émetteur et récepteur TCP établissent une connexion avant d échanger des segments de données Initialisation de buffers et de variables TCP Buffers Numéros de séquence Variables de contrôle de flux (ex RcvWindow), de contrôle de congestion client : initiateur de connexion Socket clientsocket = new Socket("hostname","port number"); serveur : contacté par le client Socket connectionsocket = welcomesocket.accept();

59 59 Établissement : three way handshake Étape 1: le système client envoie le segment de contrôle SYN au serveur (bit SYN = 1) Spécifie l ISN Étape 2: le système serveur répond avec un segment de contrôle SYNACK Bit SYN = 1 et bit ACK = 1 Champ ACK# = client_isn +1 Champ SEQ# = son ISN Initialise buffers et variables Étape 3: le système client initialise ses buffers/variables et acquitte le segment du serveur SYN = 0 et champ ACK# = server_isn +1

60 60 Établissement : les 3 segments échangés Le client Le serveur SYN=1, SeqNum=client_isn SYN=1, ACK=1 SeqNum=server_isn, AckNum=client_isn+1 SYN=0, seqnum=client_isn+1, ACK=1, AckNum=server_isn+1 Rq : bit ACK = 1 quand le champ ACK# est significatif

61 61 Libération de connexion Fermer une connexion : Les 2 sens de transmission sont fermés séparément. Chacune des 2 extrémités peut avoir l initiative de fermer. Ex : Le client ferme la socket: clientsocket.close(); close client FIN ACK FIN server close Étape 1: le système client envoie le segment FIN au serveur (FIN=1) Étape 2: le système serveur reçoit le FIN, répond par ACK. Il ferme la connexion, et envoie FIN. timed wait closed ACK

62 62 Libération de connexion (suite) Étape 3: le client reçoit FIN et répond par ACK. client server Il entre en timed wait : femera la connexion 30 sec après réception du FIN closing FIN Étape 4: le serveur reçoit ACK. La connexion est fermée. ACK FIN closing Note: possibilité de gérer des FINs simultanés. timed wait closed ACK closed

63 SSH Le transport sécurisé (Secure Socket Layer) SSL 63 Cryptage des données par couche application. Transport en utilisant TCP non sécurisé. Cryptage des données par l'appli Aucun cryptage des données par l'appli. Mais par contre les protocoles doivent prendre en compte que les données vont être transportées cryptées. Ex: https, pops, imaps. Cryptage par la couche Transport non crypté transport (ou une couche intermédiaire).

64 Le transport sécurisé II (Secure Socket Layer) 64 Fonctions assurées Authentification de serveur (contrairement à ssh ou pgp). Authentification de clients (optionnelles) Codage (cryptage) des sessions. Au moyen d'un centre de certification (CA) accréditent signent numériquement des certificats hébergent les clefs publiques associées aux certificats présentation «similaire» ssh clef ass puis clef sym

65 Auto-évaluation (vrai-faux) Soit un serveur Web HTTP à connexions persistentes. Le serveur gère un processus par client connecté au serveur. Alors chacun de ces processus aura un numéro de port serveur distinct L host A envoie à l host B un grand fichier sur une connexion TCP. B n a pas de données à envoyer à A. B ne pourra pas envoyer d acquittement à A car il ne peut pas faire de piggyback La taille de RcvWindow ne change jamais pendant une connexion Le segment TCP a un champ dans son entête pour RcvWindow L host A envoie à B des données et B envoie à A des données (les 2 sur TCP). Deux connexions TCP séparées sont nécessaires. 65

66 66 Auto-évaluation (vrai-faux) L host A envoie à l host B un grand fichier sur une connexion TCP. Si le numéro de séquence pour un segment de cette connexion est m, alors le numéro de séquence du segment suivant sera m+1 Soit une connexion TCP avec le dernier SampleRTT égal à 1 sec. Alors Timeout pour la connexion sera nécessairement initialisé à une valeur >= 1 sec L host A envoie à l host B un segment avec un numéro de séquence égal à 38 et 4 octets de données. Alors dans ce segment, le numéro d ACK sera forcément 42 Le MSS est la taille maximum d un segment TCP, entête incluse