
---
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*:

```
<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 :

```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();
```
