From 78ded52610ab70e1c4474234eee0cd9c859941cb Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Mon, 5 Feb 2024 23:23:29 +0100 Subject: [PATCH] Add Application article --- .../2_couche_applicative/index.md | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 content/reseaux_protocoles/2_couche_applicative/index.md diff --git a/content/reseaux_protocoles/2_couche_applicative/index.md b/content/reseaux_protocoles/2_couche_applicative/index.md new file mode 100644 index 0000000..fb70e6c --- /dev/null +++ b/content/reseaux_protocoles/2_couche_applicative/index.md @@ -0,0 +1,195 @@ + +--- +title: "Réseaux et Protocole: couche applicative" +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*: + +``` + +``` + +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 : + +```c +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: + +```c +mysock = socket(AF_INET, SOCK_STREAM); +mysock.listen(); +mysock.connect(addr, port); + +// Accept connection result a new one! +newsocks = mysock.accept(); +```