cours/content/reseaux_protocoles/3_couche_transport/index.md
2024-03-06 22:19:26 +01:00

6.7 KiB


title: "Réseaux et Protocole: couche transport" date: 2024-01-22 tags: ["OSI", "application"] categories: ["Réseaux et protocoles", "Cours"] mathjax: true

On parle ici des protocoles utilisé par les applications comme SMTP, HTTP, DNS, IMAP, etc. On se place au niveau application du modèle TCP ou de l'ensemble des couches 4 à 7 du modèle OSI. Ici il n;est pas question pour les dévellopeur de programmer pour le cœur de réseau, mais pour la périphérie.

Modèle client-serveur

Comme indique le titre, nous avons deux types d'acteur :

  • le serveur: il est toujours actif avec une adresse IP fixe. La plupart du temps il est dans un datacenter;
  • le client: il communique avec le serveur uniquement lorsqu'il en a besoin. Le client n'a pas besoin d'adresse IP fixe. C'est lui qui contacte le serveur qui en reponse lui répondra. Les clients n'échangent pas entre eux.

Modèle P2P

Ici les clients peuvent aussi faire office de serveurs. Les équipements terminaux sont aussi connectés entre eux. C'est une architecture distribuée et auto-scalable. La gestion des peers est complexe.

Dans ce cas il y a deux processus (un serveur et un client) sur la même machine.

Communication inter-processus

Dans le cadre de programmes qui s'exécutent sur un même équipement, on utilisera les mécanismes de communication inter-processus.

Avec des processus répartis sur des machines differentes, les messages sont acheminées via le réseau. On utiliseta alors les mécanismes de sockets.

Les sockets

C'est une passerelle entre les couches transport et applications. C'est une porte d'envoi / réception de données pour les processus.

Adressage

La couche réseaux (3) esr représentée par une adresse IP 32 bis en v4 (et 128 en v6). Mais cette adresse ne suffit pas pour identifier le processus qui demande les données. Il faut alors le numéro de port.

Ces numéros vont de 0 à 65535, les 1024 premiers sont normalement réservés pour les serveurs, le reste pour les clients.

Besoins spécifiques des applications

Les applications n'ont pas toutes les mêmes besoins en ce qui concerne les données envoyées ou reçues via un réseau informatique

La VoIP, ou encore le streaming audio / vidéopeuvent se passer des contrôles d'intégrité par exemple. mais la VoIP elle nécessite d'utiliser des communication temps réel (ou de s'en approcher) tout comme le jeu en ligne.

La couche transport

Nous avons ici deux protocoles utilisés:

TCP

C'est un protocole avec connexion qui vise avant tout la fiabilité : contrôle de flux, gestion de la congestion, réordonancement des paquets. Avant d'acheminer des données, il est nécessaire de lancer une connexion en 3 étapes (SYN, SYN-ACK, ACK). Il est aussi nécessaire de mettre fin explicitement à la connexion (FIN). Cependant il n'y a pas de gestion du timing ni de sécurité.

La sécurité dans TCP

Comme nous l'avons vu il n'y a pas de gestion de la sécurité dans TCP. Mais il
existe une couche intermédiaires entre les couches application et transport
TLS pour Transport Layer Security.

TLS se charge de l'authentification, du chiffrement, et du contrôle de l'intégrité.

UDP

Ici il n'y a pas de gestion de fiabilité (ordre, sommes de contrôle, acquittement, etc.). En contrepartie il y a peu d'overhead, il est donc adapté our la VoIP par exemple. Il est aussi plus simple à implémenter et supporte le multicast et le broadcast.

Quelques protocoles

HTTP

C'est le protocole utilisé pour le web, il se base sur TCP et les mécanismes de connexions sous-jacent. Il est de type client - serveur:

  • client: User Agent, le navigateur web;
  • serveur: serveur HTTP comme Apache ou Nginx.

Le serveur stocke des objets (fichiers HTML, images, vidéos etc.)

Il existe deux type de connexions HTTP :

  • persistente: 1 connexion pour transférer plusieurs objets;
  • non persistente: 1 connexion pour tranférer un objet.

La requête

Elle emmane du client à destination du serveur, la requête est formatée en ASCII, elle contient une requête suivi d'élément d'entête:

GET https://ent.u-bordeaux.fr HTTP/2\r\n

Ici on demande https://ent.u-bordeaux.fr en HTTP version 2. Les entêtes peuven contenir les langies acceptés par le client par exemple.

La réponse

Elle contient le code de retour, les entêtes de réponse ainsi que le contenu. La réponse peut être conditionnée à la modification de la ressource demandée via un conditionnal GET. L'entête de la demande contient le champs If-Modified-Since. Le serveur peut alors répondre avec un code 304 Not-Modified et le navigateur utilisera la version dans son cache.

Amélioration du protocole

La verion 2 de HTTP permet de découper les ressources demandées en chunk et de réaliser des envois entrelacés. Ainsi les gros fichiers ne pénalisent pas le transfert des plus petits (mécanismes de `first come first served*.

La version 3 propose d'utiliser les protocole UDP et QUIC. Il propose de gérer la réupération de paquets perdus (hé oui, il utlise UDP), il propose aussi la gestion de la congestion et plus de sécurité (QUIC).

DNS

C'est le protocole chargé de la résolution des noms de domaines (et des résolutions inverses). Il fait le lien entre les adresses IP et les noms de domaines. C'est une base de donnée distribuée our éviter le single point of failure

La base de données est hiérarchisée : Root server -> Top level domain -> authoritative server -> recursive resolver.

Deux types de requêtes:

  • itérative: le résolveur a la charge de la requête et demande les informations du root jusqu'au serveur authoritative;
  • recursive: chaque serveur est responsable de sa réponse. La requête va ainsi passer de serveur en serveur et faire le chemin inverse jusqu'à revenir au client.

Les enregistrement DNS et les messages

Il sont au format RR Ressource Record:

<nom> <valeur> <type> <TTL>

Les messages du serveur vers le client contiennent le nombre de question, le nombre de réponse et enfin les réponses.

Retour sur les sockets

Comme nous l'avons vu elle serve de point de liaisons entre les applications et la couche transport. Elle sont créees par le système.

Pour la création de socket UDP :

mysock = socket(AF_INET, SOCK_DGRAM);
mysock.rcevfrom();
mysock.sendto();
bind(mysock, &addr, sizeof(addr));

C'est relativement simple car il n'y a pas de connexion.

Pour TCP c'est un peu plus complexe:

mysock = socket(AF_INET, SOCK_STREAM);
mysock.listen();
mysock.connect(addr, port);

// Accept connection result a new one!
newsocks = mysock.accept();