INFO 3020 Introduction aux réseaux d’ordinateurs Philippe Fournier-Viger Département d’informatique, U.de M. Bureau D216, Automne 2014

Introduction La semaine passée ◦ Chapitre 3 – couche application ◦ Quiz Chapitre 2 Cette semaine ◦ Chapitre 4 – couche transport  Mercredi  Quiz Chapitre 2 (fin)  Introduction à la couche transport  TCP  Vendredi  UDP  La détection d’erreurs dans TCP et UDP  Quiz chapitre 4

CHAPITRE 4 LA COUCHE TRANSPORT (MODÈLE OSI)

Introduction Nous sautons la couche « présentation » qui s’occupe du format des données présentées à l’utilisateur (PNG, etc.), chiffrement, compression. Nous sautons la couche « session », qui est principalement implémentée par la couche transport et qui n’existe pas dans le modèle TCP/IP. 4

La couche « transport » Elle est globalement responsable du transfert de bout en bout des données entre applications ( erreurs, retransmissions, plusieurs applications, etc.). Les processus de la couche transport ◦ acceptent des données provenant de la couche application, ◦ les préparent pour la couche réseau.

La couche « transport » (suite) Rôles: permettre à de nombreuses applications de communiquer sur le réseau, ◦ au même moment, ◦ sur un même périphérique (multiplexage des conversations); optionnel: s’assurer que toutes les données sont reçues ◦ de façon fiable, ◦ dans l’ordre, et par l’application voulue. mécanismes de gestion des erreurs (détection, retransmission).

La couche « transport » (suite) Elle accepte les données provenant de plusieurs conversations. Elle les fait descendre vers les couches inférieures en morceaux (segmentation) qui peuvent faire l’objet d’un multiplexage sur le support. les couches inférieures ignorent que plusieurs applications envoient des données sur le réseau.

La couche « transport » (suite) la couche transport ignore ◦ sur quel support les conversations seront transmises, ◦ par quel chemin elles seront transmises. la couche transport identifie les applications grâce à des numéros de port (une adresse logique),

La couche « transport » (suite) la couche transport peut effectuer le contrôle des conversations: ◦ établissement d’une session, ◦ acheminement fiable, ◦ livraison des données dans un ordre défini, ◦ reconstitution des données segmentées, ◦ contrôle de flux.

Illustration

Besoins variés Un développeur choisi un protocole en fonction de la nature d’une application.

Besoins variés Un développeur choisi un protocole en fonction de la nature d’une application.

Besoins variés (suite) Exemples d’applications nécessitant une connexion fiable: ◦ courriels, ◦ pages Web, ◦ transfert de fichiers, ◦ bases de données,… Exemples d’applications pouvant tolérer la perte d’information: ◦ lecture vidéo, ◦ jeux vidéos en ligne, ◦ téléphonie, ◦ la synchronisation de l’heure, …

Prise en charge des communications fiables Périphériques émetteur et/ou receveur Le receveur: ◦ effectue le suivi des données reçues ◦ accuse réception des données reçues. L’émetteur ◦ effectuer le suivi des données transmises, ◦ retransmettre toute donnée n’ayant pas fait l’objet d’un reçu. Donc, le suivi se fait au niveau ◦ de l’hôte qui émet, ◦ de celui qui reçoit les données.

Cela demande l’utilisation de données de contrôle stockées dans les entêtes de chaque segment. Constitue une charge supplémentaire sur le réseau, Cela est un compromis acceptable (charge/fiabilité) pour certaines applications. Prise en charge des communications fiables (suite)

Les deux principaux protocoles de la suite TCP-IP UDP (User Datagram Protocol) ◦ RFC 768 ◦ Les données encapsulées sont appelées des datagrammes. ◦ connexion « au mieux » ◦ Ex.: DNS, VoIP, vidéo ◦ en-tête de 8 octets par datagramme TCP (Tranmission Control Protocol) ◦ RFC 793 ◦ Les données encapsulées sont appelées des segments TCP. ◦ connexion fiable ◦ Ex.: FTP, HTTP, courriels ◦ en-tête de 20 octets par segment

Identification des conversations L’entête de chaque segment ou datagramme contient ◦ un numéro de port source: identifie l’application qui émet les données. ◦ un numéro de port de destination: identifie l’application qui reçoit les données. Pour une application serveur, les ports sont statiques. Pour une application client, les ports sont généralement attribués dynamiquement.

Identification des conversations (suite) Comment les ports sont choisis sur le client? en général générés aléatoirement, il ne faut pas choisir un port déjà utilisé par une autre application.

Identification des conversations (suite) Comment savoir le numéro de port sur le serveur? Plusieurs ports sont définis par défaut. Par exemple: HTTP port 80 SNTP port 123 FTPport 21 Telnet port 23 …

Attribution des numéros de ports un port est représenté par 16 bits ils sont attribués par l’Internet Assigned Numbers Authority (IANA).IANA ◦ 0 à ports réservés: ports réservés à des services ou applications courantes. Ex.: FTP, HTTP, TELNET, SSH, … ◦ 1024 à ports inscrits: ports réservés à des processus ou applications particulières qu’un utilisateur installe. ◦ Ex.: MSN (1863), … ◦ à ports dynamiques ou privés: généralement utilisés par des applications clientes et affectés de façon dynamique, mais il y a des exceptions. L’IANA est aussi responsable des serveurs DNS racine 

Adresses des serveurs DNS racines

Attribution des numéros de ports (suite) Le processus d’inscription auprès de l’IANA est décrit dans le RFC Liste de ports utilisés par des applications ou protocoles: ◦ numbers/service-names-port-numbers.xml numbers/service-names-port-numbers.xml ◦ numbers numbers Parfois, il y a des utilisations non officielles de ports. Utiliser un port réservé est un risque de sécurité. ◦ Il peut être utile de choisir un port non standard ◦ ou d’utiliser un pare-feu. ◦ ex.: pour un serveur de fichier privé

Exemple – Attaque Netbios Sur Windows 98/Me, une faille dans le protocole Netbios permettait de découvrir le mot de passe des systèmes de fichiers partagés sur un hôte à l’aide d’un logiciel simple d’utilisation. Avec un logiciel balayeur de ports (scanner), un individu malintentionné pouvait découvrir rapidement des victimes parmi des plages d’adresses IP. ports ouverts, ports fermés, ports furtifs 24

Interface de connexion Interface de connexion (socket): l’ensemble formé de l’adresse IP et du numéro de port. Identifie de façon précise un processus s’exécutant sur un périphérique hôte précis. Ex.: Serveur Web avec une adresse IP L’interface de connexion est: :80 Adresse IP Port HTTP

Pour voir les connexions TCP actives Sous Windows, taper netstat dans la console, affiche les connexions TCP. port de destination état de la connexion protocole port source adresse destination

netstat -b affiche le nom des programmes utilisant les connexions TCP.

netstat -a affiche les connexions TCP et les ports UDP sur lequels il y a écoute.

Segmentation et reconstitution Pourquoi la segmentation? ◦ le multiplexage des applications, ◦ s’assurer que les données respectent les limites du support (mémoire tampons limités des périphériques réseau…). En utilisant TCP: ◦ chaque segment est numéroté et l’ordre d’arrivé est garanti. ◦ retransmission en cas d’erreur… En utilisant UDP: ◦ les datagrammes ne sont pas numérotés, ◦ l’application qui reçoit doit tenir compte que l’ordre d’arrivé n’est pas garanti.

LE PROTOCOLE TCP (TRANSMISSION CONTROL PROTOCOL)

TCP Un des protocoles les plus importants d’Internet (dans la suite « TCP-IP »). article publié en 1974 par Vinton Cerf & Robert Khan TCP pour IPv4 TCP pour IPv6 31

Communication TCP Établissement d’une connexion dans les deux directions. La source envoie des données. La destination envoie des reçus pour les données qu’elle reçoit. La source retransmet les données pour lesquelles elle n’a pas reçu de reçu. La connexion est éventuellement fermée.

TCP Le protocole TCP créé une charge plus importante que UDP sur le réseau, car connexions, retransmissions, messages plus volumineux… supporte la communication bidirectionnelle (« full-duplex »). supporte l’envoi de flux d’octets.

TCP – le format Format des segments TCP:

TCP – le format (suite) Port source: le port du processus qui a émis le message. (16 bits) Port de destination: le port du processus qui recevra le message. Numéro d’ordre: indique le numéro du premier octet de ce segment (32 bits). Exception si SYN=1. Numéro de reçu: prochain octet que le destinataire s’attend à recevoir.

TCP – le format (suite) Longueur d’E-T: la taille de l’en-tête en terme de nombre de mots de 32 bits (4 bits). Réservé: pour un usage futur (6 bits) Bits de contrôle: pour la gestion de la session et le traitement des segments (6 bits). ◦ URG: Urgent Pointer field significant ACK: Acknowledgment field significant PSH: Push Function RST: Reset the connection SYN: Synchronize sequence numbers FIN: No more data from sender

TCP – le format (suite) Taille de la fenêtre: Ce champs spécifie le numéro de l’octet jusqu’à lequel l’émetteur peut recevoir des données (16 bits). La taille de la fenêtre est dynamique. Somme de contrôle: un code de détection d’erreurs (16 bits)

TCP – le format (suite) Pointeur d’urgence: seulement utilisé avec l’indicateur URG. (16 bits) Options (taille variable): information facultatives. Données: données de la couche application.

Processus serveur TCP Les ports des services sont choisis par l’administrateur. On ne peut pas utiliser le même port pour deux services. Un port « ouvert »: la couche transport accepte et traite les segments adressé à ce port. Pour améliorer la sécurité d’un serveur, autoriser seulement les ports nécessaires.

Illustration Serveur Web et courriel Client 1Client 2

Établissement d’une connexion TCP Trois opérations à effectuer: ◦ vérifier que le périphérique est présent sur le réseau, ◦ s’assurer que le périphérique est actif sur le réseau et accepte les requêtes sur le port voulu par le client, ◦ informe le périphérique de destination de l’intention d’établir une connexion Les bits de contrôles sont utilisés pour indiquer l’état de l’établissement de la connexion.

Établissement d’une connexion TCP (suite) Trois étapes (« Three-way handshake »): 1. Le client envoie au serveur un segment contenant ◦ un numéro d’ordre initial aléatoire ◦ le bit SYN à 1 2. Le serveur répond par un segment contenant: ◦ numéro de reçu = numéro d’ordre reçu + 1, ◦ son propre numéro d’ordre de synchronisation ◦ le bit SYN à 1 ◦ let bit ACK à 1 3. Le client répond par: ◦ numéro de reçu = numéro d’ordre reçu + 1, ◦ let bit ACK à 1 42

Illustration ACK: accusé de réception SYN: synchronisation des numéros de séquences 43

Établissement d’une connexion TCP (suite) ACK: Acknowledgment field significant SYN: Synchronize sequence numbers

Établissement d’une connexion TCP (suite) ACK: Acknowledgment field significant SYN: Synchronize sequence numbers

Établissement d’une connexion TCP (suite) ACK: Acknowledgment field significant SYN: Synchronize sequence numbers

Capture avec Wireshark – étape 1 47

Capture avec Wireshark – étape 2 48

Capture avec Wireshark – étape 3 49

Connexion TCP - sécurité Pour plus de sécurité: ◦ refuser l’établissement de sessions TCP; ◦ autoriser uniquement l’établissement de sessions pour des services spécifiques; ◦ autoriser uniquement le trafic faisant déjà partie de sessions établies.

Fermeture d’une connexion TCP Une connexion peut être fermée par le client ou le serveur. 2 étapes: « Two-way handshake » Processus pour une communication dans les 2 sens: 1. L’hôte A envoie un segment avec l’indicateur FIN. 2. L’hôte B envoie un segment avec l’indicateur ACK. 3. L’hôte B envoie un segment avec l’indicateur FIN. 4. L’hôte A envoie un segment avec l’indicateur ACK. La connexion est fermée!

Fermeture d’une connexion TCP (suite) Une variante: 1. L’hôte A envoie un segment avec l’indicateur FIN. 2. L’hôte B envoie un segment avec les indicateurs ACK et FIN. 3. L’hôte A envoie un segment avec l’indicateur ACK.

Fermeture d’une connexion TCP

54

55

Réassemblage des segments chaque segment TCP a un numéro de séquence (appelé aussi numéro d’ordre). si les segments n’arrivent pas dans le bon ordre, ils sont gardés en mémoire dans un tampon en attendant que les autres segments arrivent, puis réordonnés. Illustration 

Réassemblage des segments Les segment TCP peuvent prendre différents chemins Les segment TCP sont réordonnés à la destination Les données sont divisés en segments Les segments arrivent désordonnés car ils ont pris différents chemins Les segments sont réordonnés selon l’ordre original

Confirmation des segments reçus – fenêtre de taille 1 segment 1 ACK 2 segment 2 ACK 3 segment 3 ACK 4 Le numéro d’ordre est un nombre d’octets Les accusés de réceptions dans TCP sont des reçus prévisionnels. Ils indique le numéro du prochain segment attendu AB

Confirmation des segments reçus – fenêtre de taille 3 segment 1 segment 2 segment 3 ACK 4 segment 4 segment 5 segment 6 ACK 7 AB

Retransmission des segments perdus segment 1 segment 2 segment 3 ACK 4 segment 4 segment 5 segment 6 ACK 4 Le segment numéro 4 est perdu! Dépendant du protocole utilisé, l’ordinateur A va seulement renvoyer 4 ou bien renvoyer 4, 5 et 6 après avoir reçu ACK4. En général, la deuxième façon est employée. AB Reçu sélectif…

Retransmission des segments perdus Le processus de retransmission n’est pas spécifié dans le RFC. Typiquement l’émetteur va conserver les segments envoyés pour un certain temps et va les retransmettre si aucune confirmation n’est reçue. Lorsqu’une confirmation est reçue, les segments correspondant sont effacés de la mémoire. 61 Cas d’une confirmation perdue Cas d’une confirmation reçue

Gestion de flux Le champs Taille de fenêtre dans l’en-tête TCP précise la quantité de données pouvant être transmise avant qu’il ne soit nécessaire de recevoir un reçu. TCP s’efforce de gérer le taux de retransmission de façon à ce que toutes les données soient reçues et que les retransmissions soient limitées au maximum. Un hôte réduira la taille de fenêtre s’il y a perte à cause d’un encombrement. Si un certains temps s’écoule sans problème, alors la fenêtre pourra être agrandie à nouveau. Plus de détails dans le RFC 2581.

Communication sur un même port Un serveur peut recevoir plusieurs conversations sur un même port si elles sont destinées au même logiciel. Comment le serveur détermine à quelle conversation les segments TCP appartiennent t-il ?

Quelle est la taille maximale d’un segment TCP? Taille du segment = entête TCP + données La taille maximale dépend de: ◦ Le protocole de couche inférieure IPv4 demande aux périphériques de pouvoir traiter au minimum 536 octets, mais il faut soustraire la taille de l’entête IP (20 octets). ◦ Le maximum est négocié optionnellement lors de la connexion TCP en échangeant un MSS qui indique le maximum qu’un périphérique veut recevoir. ◦ Le MSS est soit fixé manuellement ou bien est basé sur le MTU. ◦ Le MTU est le maximum transmissible sur le support sur lequel le segment circule (ex.: Ethernet = 1500 octets)…. aussi MTU path discovery… Un texte qui explique bien ceci: 65

EXEMPLE TCP EN JAVA tcp-server-and-tcp-client/ 66

import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream() )); DataOutputStream outToClient = new DataOutputStream(connectionSocket.get OutputStream()); clientSentence = inFromClient.readLine(); System.out.println("Received: " + clientSentence); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } }} 67 Serveur TCP

Client TCP import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader( new InputStreamReader(System.in)); Socket clientSocket = new Socket("localhost", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStrea m()); BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSoc ket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } 68

Références Chapitre 4 de CCNA Exploration 1 Autres références (RFCs…) 69

Références Chapitre 4 de CCNA Exploration 1