S1C7b - HTTP et l'archi applicative

SIO > S1_Commun > . > S1C7_Presence > S1C7b_DeveloppementWeb.md

Le protocole HTTP

La petite histoire : le client et le serveur

http Un serveur, sur son cloud perché, tenait en son disque une page.
Le serveur, par la requête alléché, lui tint à peu près ce langage :
Eh bonjour, Monsieur du Serveur,
Que votre site est joli ! que vos données semblent belles.
Sans doute répondrez vous à ma requête HTTP.
Le serveur, par le service honoré, lui envoya le texte HTML de la page demandée.
Le client, recevant la prose, fut bien marri de voir qu'il y manquait de nombreuses ressources.
Qu'a cela ne tienne, il utilisa un moteur d'analyse du code à la rescousse.
Il obtint alors les liens de tous les fichiers nécessaires et les quémanda auprès du serveur.
Bien obligeant, ce dernier lui servi toutes les données pour son bonheur.
À ce présent, le navigateur client, plein d'aise et de joie,
Put alors reconstituer la page et sans attendre, l'afficha.

HTTP

Effectivement, c'est bien ainsi que fonctionne le protocole HTTP :

  • le client forme une requête contenant l'adresse de la ressource demandée (URL) et l'envoie au serveur sur le port de destination 80.
  • Le serveur, construit la page et retourne celle-ci en une ou plusieurs fois vers le client avec le port TCP demandé
  • le client refait une nouvelle requête pour chaque adresse (URL) de ressource à afficher trouvée dans le texte de la page
    Il obtient donc tous les documents nécessaires à la page : images, animations, scripts, feuilles de style, etc. ...
  • Après avoir tout reçu, le client (le navigateur) reconstitue la page comme elle doit être affichée.

la communication http

Durant les échanges entre le client et le serveur, le client joint le serveur sur le port 80 mais il se produit une "négociation" pour que le port 80 du serveur ne soit pas encombré par chaque client.
On a donc une progression de ce type, en admettant que le client possède l'adresse IP IPCli et le serveur IPSrv :

Qui Quoi requête http ou contenu en retour source destination Observation
client Requête : URL = "http://123.0.0.1/page.ext?pam=val" IPCli :12345 IPSrv :80 Première requête vers le port 80 du serveur
serveur Retour : texte = "<html><body>...</body></html>" IPSrv :67890 IPCli :12345 Retour des données, le port 80, maintenant source, est changé
client Requête : URL = "http://123.0.0.1/image1.png" IPCli :12345 IPSrv :67890 Le nouveau port source sert pour les requêtes suivantes.
serveur Retour : texte = "*‰PNG...* contenu image *...IEND®B`‚*" IPSrv :67890 IPCli :12345

Les Codes erreur HTTP

Allo Client ? On a un problème.
Si le serveur ne peut répondre à la demande, il retourne un code erreur dans l'entête du message. les plus connus sont :

Code Description Observation
102 Connexion refusée Ou alors, le service http est down
200 ok Page trouvée et envoyée
302 Redirection temporaire La page renvoie vers une autre url /!\ Alerte bloc 3 ?
404 Page non trouvée La page a été supprimée ou a changé de nom
500 erreur interne au serveur erreur non identifiée, pbm technique, bug du développeur, etc.

codes Erreur http
Petit clin d'oeil, ancienne version de github ...

Architecture logicielle des serveurs

Architecture du serveur

Archi du serveur
Petits clins d'oeil divers | Les logos sont déposés par les marque respectives : navigateurs, Mozilla, Apache, NGINX, etc ... | Infographie : icons8

Côté client

  • Le navigateur du client se connecte au serveur http.
  • Le serveur http cherche les pages sur son disque et les interprête éventuellement avec PHP.
    • PHP produit le code HTML en retour, éventuellement en faisant appel à un serveur de base de données.
  • Le serveur HTTP renvoie les pages et fichiers au client à travers le réseau.

Côté développeur

  • Le développeur crée le site et les pages qu'il contient, généralement sur son poste.
  • Ensuite, il envoie les page avec le protocole FTP de son poste sur le serveur FTP.
  • Le serveur FTP place les documents reçus dans le disque du serveur HTTP.

Architecture n-tiers

Les services sont souvent représentés de façon independants.
S'ils sont indépendants, il est alors possible de les installer sur des serveurs différents.

3-tiers, le plus simple

En général, on divise l'architecture des services Web en trois tiers (trois parties) :

  1. Le client et son navigateur ou une application plus lourde chargée de représenter les données,
  2. L'application chargée de traiter les données (CIMS : Consulter, Insérer, Modifier, Supprimer) et les mettre en forme pour le client
  3. Le SGBD, système de gestion de base de données, chargé de stocker l'information.

n-tiers, le plus courant

Parfois, la partie centrale est divisée en sous-couches. On parle alors d'architecture n-tiers.
Exemple : Archi 3 tiers

  1. Client et son navigateur ou une application plus lourde chargée de représenter les données ;
    chargé de la présentation au client et de contrôles de cohérence basique (vérification de formats de données),
  2. front ware (applicatif) chargé de la communication avec le client, du traitement et de la présentation des données (vues) ;
    lit du XML ou JSON structuré et produit du HTML
  3. middle ware ("modèle") chargé de la communication avec la base de données et la mise en forme des données brutes ;
    lit les données brutes avec SQL et produit des données structurées en XML ou JSON
  4. Le SGBD, système de gestion de base de données, chargé de stocker l'information ;
    Le SGBD peut effectuer certains contrôles de bas niveau (modifications en cascade, triggers, procédures).

Conclusion

Dans ce cours, on rejoint le TP sur les accès à distance avec le cours Cloud, Shell et FTP. Revoir ce cours.
En pratique, vous êtes maintenant à même de comprendre le fonctionnement d'un serveur web.

C'est pourquoi il est temps pour vous d'en installer un sur votre poste.
En TP, vous allez donc créer un serveur web avec wampserver, uwamp, xampp ou encore lamp ou mamp, soit en local sur votre poste, soit sur une machine virtuelle vide.