Archi Couche Application

Identification

Infoforall

4 - Protocole HTTP


Nous allons aujourd'hui voir un peu plus dans le détail le principe d'une communication Web et son passage sur le réseau Internet.

Cette activité spécifique se concentre sur la communication entre votre navigateur (attention au choix, ce n'est pas innocent) et un serveur Web distant.

Cette activité intégre pas mal de choses à lire et à comprendre. Ces choses sont des rappels ou des prolongements du cours de SNT sur Internet.

Evaluation ✎ : questions 03-04-05-06-15-16-18-19-20-.

Documents de cours : open document ou pdf

1 - Couche Application

Commençons par une opération basique à priori : la communication entre deux programmes.

Prenons l'exemple de la communication Web basée sur le protocole HTTP :

  1. votre navigateur Web (un programme-client HTTP) envoie une requête HTTP à
  2. un site Web (un programme-serveur HTTP) qui traite la requête HTTP (valide, pas valide...) et finalement
  3. ce programme-serveur HTTP renvoie une réponse HTTP
1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Quel est le type de données envoyées par votre navigateur lorsqu'il fait une requête HTTP ? Du texte. Ou plutôt une suite d'octets encodant une chaîne de caractères en ASCII.
Pour transmettre un A, l'octet vaut 6510 ou 4116.
Pour transmettre un B, l'octet vaut 6610 ou 4216...

...ASCII...

Table ASCII en version hexadécimale
_0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
0_ NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI _0
1_ DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 1_
2_ ! " # $ % & ' ( ) * + , - . / 2_
3_ 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 3_
4_ @ A B C D E F G H I J K L M N O 4_
5_ P Q R S T U V W X Y Z [ \ ] ^ _ 5_
6_ ` a b c d e f g h i j k l m n o 6_
7_ p q r s t u v w x y z { | } ~ DEL 7_
_0_1_2_3_4_5_6_7_8_9_A_B_C_D_E_F
Couche APPLICATION (1) : notion de protocole de communication

Qu'est-ce qu'une couche ?

Les couches réseaux dont on parle sont des programmes chargés d'effectuer une tâche particulière lors des communications. Elles fournissent des fonctionnalités plutôt que de demander à chaque programme de réinventer la roue.

La couche APPLICATION est chargée de structurer la communication entre deux programmes utilisant un même protocole. Pour cela, elle doit être capable :

  • de formuler correctement la communication qu'un programme veut envoyer : "comment parler à l'autre".
  • d'extraire correctement les informations contenues dans une communication qu'un autre programme lui envoie : "comment comprendre ce que l'autre me dit"
  • de transférer le message

La couche APPLICATION contient donc un ensemble de règles de communication partagées par tous les ordinateurs : des protocoles. Les protocoles de cette couche APPLICATION caractérisent donc chacun une façon particulière de placer les informations dans les messages.

Pourquoi pas un seul et unique protocole ?

Simplement car selon le type de l'application, on aura besoin d'optimiser certains aspects, de parler beaucoup ou pas, de transmettre certaines informations de l'ordinateur ou pas... D'où un grand choix.

  • Protocole HTTP pour le Web (entre le programme-navigateur et le programme-serveur par exemple)
  • Protocole FTP pour les téléchargements et les téléversements (entre votre programme et le programme-serveur qui stocke les fichiers)
  • Protocole POP pour lire ou envoyer les emails (entre le programme d'emails et le programme-serveur email)
  • Protocole IMAP pour lire ou envoyer les emails (un peu plus fourni que POP)
  • ...

L'intérêt ?

Lorsqu'on crée une nouvelle application communicante, vous n'avez pas besoin à chaque fois de recoder toute la gestion des communications. Il vous suffit de choisir un protocole, et d'utiliser la couche APPLICATION qui se charge de tout ensuite.

2 - Protocole HTTP de la couche Application

Nous allons maintenant analyser l'un des protocoles de cette couche : le protocole HTTP.

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Lorsque vous avez lancé cette page, la demande suivante étant présente dans votre barre de navigation :

https://www.infoforall.fr/act/archi/communication-tcp-ip/

Votre programme-navigateur a alors compris où vous vouliez aller et à codifier votre demande en utilisant la couche APPLICATION selon le protocole HTTP. Vous allez voir ci-dessous le texte que votre navigateur a réellement envoyé lorsque vous avez lancé votre requête le sam 12 Jui 2021 à 11:46 (heure serveur) pour afficher cette page.

Texte réel de la requête envoyée par le navigateur, conçu à partir de la barre d'adresses :

.............................DEBUT DE LA REQUETE HTTP

GET /act/archi/protocole-http-couche-application/ HTTP/1.1
Host: www.infoforall.fr

User-Agent: CCBot/2.0 (https://commoncrawl.org/faq/)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: br,gzip
Connection: Keep-Alive
X-Real-Ip: 34.239.157.140
Via: 1.1 alproxy
X-Forwarded-Proto: https

MESSAGE VIDE

.............................FIN DE LA REQUETE HTTP

J'ai rajouté un visuel pour les passages à la ligne (line feed) car il s'agit d'un vrai octet (code ASCII 1010 ou 0A16). Normalement le caractère n'est pas visible car il n'est pas un caractère d'imprimerie mais un caractère de contrôle : il provoque...le passage à la ligne. Il s'agit du caractère encodé par \n dans un string Python.

Comme vous le voyez, la requête HTTP est donc un texte codifié, les informations sont placées à certains endroits précis pour que le programme-serveur puisse les retrouver.

01 Dans cette requête HTTP, quelles sont les informations transmises

  • Sur la première ligne (3 informations différentes)?
  • Sur la deuxième ligne ? (une information)
  • Sur la troisième ligne ? (une information)

...CORRECTION...

  • Sur la première ligne ? Méthode utilisée espace ressource demandée espace version de HTTP utilisée.
  • Sur la deuxième ligne ? Le nom de domaine du serveur qu'on veut joindre
  • Sur la troisième ligne ? Ca dépend des systèmes. Par exemple, c'est parfois la longueur en octet du message interne transmis avec la requête : ici 0 car c'est un GET : toutes les informations sont transmises via l'URL, il n'y a pas de message sous l'en-tête fournissant différentes informations.

Un exemple de réponse HTTP possible, envoyée par le programme-serveur après qu'il ai traité la requête HTTP :

.............................DEBUT DE LA REPONSE HTTP

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 36435
Vary: Cookie
Via: 1.1 alproxy
Date: Thu, 19 Mar 2020 12:54:47 GMT


<!DOCTYPE html>
<html lang="fr">
<head>
...
: la suite, c'est donc le reste du fichier html !
...
</html lang="fr">

.............................FIN DE LA REPONSE HTTP

Encore une fois, il s'agit d'un texte codifié par le serveur de façon à ce que le navigateur puisse facilement retrouver les informations dont il a besoin.

02 Dans cette réponse HTTP, quelles sont les informations transmises

  • Sur la première ligne (3 informations différentes)?
  • Sur la deuxième ligne ? (une information principale et ici une info complémentaire)
  • Sur la troisième ligne ? (une information)

...CORRECTION...

  • Sur la première ligne ? version de HTTP utilisée pour répondre espace code de la réponse espace texte complémentaire liée au traitement de la requête initiale
  • Sur la deuxième ligne ? Le type des données contenu dans le message sous l'en-tête : ici les octets d'un code HTML qu'il faudra décoder en utilisant UTF-8.
  • Sur la troisième ligne ? La longueur en octet du message interne transmis avec la requête : ici 36435 octets, soit 36ko environ.
Protocole HTTP de la couche Application (2) : la Communication HTTP

Le protocole HTTP est l'un des protocoles de la couche APPLICATION. HTTP est basé sur le principe client-serveur.

HTTP veut dire Hyper Text Transfert Protocol.

Le programme-client fait une requête HTTP composée de plusieurs parties :

  1. Une première ligne d'informations (méthode - ressource demandée - protocole utilisé)
  2. Les lignes de l'en-tête sous la forme clé: valeur
  3. Une ligne vide
  4. Le contenu du message lui-même

Le programme-serveur reçoit la requête, la traite et renvoie une réponse HTTP composée de plusieurs parties :

  1. Une première ligne d'informations (protocole utilisé - code réponse - texte descriptif complémentaire)
  2. Les lignes de l'en-tête sous la forme clé: valeur
  3. Une ligne vide
  4. Le contenu du message lui-même

Sous l'en-tête de la réponse HTTP, le message du serveur contient donc soit :

  • le code HTML de la page à afficher si le client demande un fichier HTML (une suite d'octets donc)
  • le code CSS si le client demande un fichier CSS (une suite d'octets donc)
  • le code JS si le client demande un fichier JS (une suite d'octets donc)
  • le code de l'image à afficher si le client demande une image (une suite d'octets donc)
  • ...

Notez bien la présence d'une ligne vide entre l'en-tête et le message transporté par la communication : imposée par le protocole HTTP, elle permet à celui qui reçoit la communication de détecter facilement la fin de l'en-tête et le début du message en lui-même : il suffit de détecter deux octets 10 (passages à la ligne) successifs.

Protocole HTTP de la couche Application (3) : les méthodes GET et POST

La requête HTTP peut se faire de plusieurs façons. En voici deux :

  1. La méthode GET :
    • on transmet les informations supplémentaires dans l'URL : le message de la requête est donc vide.
    • utile pour transmettre un nombre limité de données
    • jamais pour transmettre un mot de passe : l'url étant visible dans la barre de navigation, en regardant l'écran de quelqu'un on pourrait facilement voir le mot de passe !
  2. la méthode POST :
    • on transmet les informations supplémentaires dans le message : c'est que vous faites lorsque vous envoyez vos copies numériques : votre texte n'apparait pas dans l'URL.
    • utile pour transmettre un nombre important de données
    • utile pour transmettre des données sensibles : elles n'apparaissent pas dans l'URL affichée.

Culture générale : sachez qu'il existe aussi des requêtes :

  • HEAD : permet de ne recevoir que l'en-tête d'une page, pas le corps du message en lui-même : ça permet de savoir si une page existe, a été mise à jour ...
  • DELETE : permet de supprimer une ressource sur le serveur
  • PUT : permet de placer une ressource sur le serveur

✎ 03 QCM : La requête que vous avez effectué pour visualiser cette page est-elle une requête 

  • A : GET
  • B : POST
  • C : HEAD
  • D : PUT

✎ 04 QCM : Sur la fin de la première ligne de la requête se trouve la version du protocole HTTP utilisé pour formaliser la requête. Quelle version HTTP le serveur distant devra-t-il utiliser pour décoder correctement votre requête ?

  • A : 0.9
  • B : 1.0
  • C : 1.1
  • D : 2.0

✎ 05 Quel est le nom du serveur distant (Host) qu'on tente de joindre ?

✎ 06 En regardant les lignes sous la ligne du GET, on trouve l'ensemble des en-têtes que votre navigateur a envoyé au serveur ou que le serveur a récupéré d'une manière ou d'une autre. Est-ce une communication utilisant http ou https ? Trouvez la ligne comportant une indication sur la nature HTTP ou HTTPS dans la demande. Fournir la ligne et le protocole utilisé.

On notera que le serveur récupère également des informations qui seront rajoutées ensuite. Notamment votre adresse IP : ce que j'affiche sur cette page est une partie de l'en-tête reçu par le serveur. On y trouve surtout X-Real-Ip qui contient l'IP ayant à priori fait la requête HTTP initiale.

Regardons maintenant la vraie réponse que vous a fourni le serveur du site.

3 - Voir HTTP avec Firefox

Cette partie vous montrera comment utiliser certains menus de Firefox pour visualiser une partie de HTTP.

07° Dans Firefox, activer le menu, choisir Développement Web puis réseau :

Accès à l'outil Réseau

08° Actualiser la page https://www.infoforall.fr/act/archi/communication-tcp-ip/ sur laquelle vous êtes actuellement.

Remonter en haut des fichiers que vous venez de télécharger : vous devriez tomber sur un fichier HTML : il s'agit du code HTML de la page. C'est bien la première chose que vous transmet le serveur.

Quel est le code obtenu sur la plupart des fichiers ?

  • 200 pour dire que la réponse s'est bien passée
  • 304 pour signaler que le fichier demandé n'a pas été modifié depuis la dernière demande et que vous pouvez donc juste utiliser celui que vous avez en mémoire cache.
  • 404 pour signaler que la requête n'a pas pu aboutir : le serveur fonctionne bien mais il ne sait pas quoi vous répondre.
  • 500 pour signaler que le serveur rencontre un problème : la demande a créé un problème bloquant l'exécution

Parvenez-vous à reconnaitre d'autres types de fichiers parmi les fichiers affichés ?

...CORRECTION...

Sur le visuel ci-dessous, on voit que le premier document est un document de type HTML.

Le code 200 permet d'indiquer que la requête et la réponse se sont bien déroulées. Tout est ok.

On voit que le navigateur a fait plusieurs demandes :

  • D'abord le fichier HTML et ensuite
  • des fichiers CSS
  • des fichiers images
  • des fichiers JS

Voici un visuel des choses qu'on peut obtenir avec https://www.infoforall.fr :

Résultats d'une requête
Pourquoi cet ordre dans les demandes ?

Comment le client sait-il quels fichiers demandés en plus du code HTML reçu ? C'est simple : Firefox reçoit le code HTML, il le lit !

Si vous voulez savoir dans quel ordre vous devriez recevoir les fichiers, vous pouvez faire un clic-droit et utiliser AFFICHER CODE SOURCE. On part de la ligne 1 et on descend séquentiellement.. Si la ligne 13 contient la référence d'un fichier CSS, il le demande en envoyant une nouvelle requête HTTP.

Votre navigateur lit donc le HTML séquentiellement et fait les demandes de fichiers annexes au fur et à mesure qu'il détecte qu'il va en avoir besoin : CSS. JS, images apparaissent lors de la lecture du HTML.

09° Cliquer sur la première ligne : celle du fichier HTML. Vous devriez obtenir un affichage proche de celui présenté ci-dessous.

Détails d'une requête

10° En regardant le détail de la demande, répondre aux questions suivantes :

  • Avez-vous effectué une requête de type GET ou de type POST ?
  • Quelle est l'adresse IP (adresse numérique internet) du site joignable par le nom www.infoforall.fr ?
  • Le port 443 est-il bien compatible avec une liaison à un serveur HTTPS ou un serveur HTTP ?

...CORRECTION...

Nous avons fait une requête de type GET : on veut juste recevoir des informations (et au pire en fournir quelques unes peu nombreuses)

L'adresse IP du site est notée [2a00:b6e0:1:20:2::1]:443 sur l'image.

Vous avez peut-être déjà vu que le port 80 est le port des serveurs HTTP et 443 le port des serveurs HTTPS. Plus de détails dans la partie suivante.

11° Cliquer sur le bouton En-têtes brutes de la REPONSE de façon à voir le contenu de l'en-tête telle que le navigateur l'a reçu avant de vous le remettre en forme. Vous devriez constater qu'il s'agit bien d'un simple contenu texte.

ATTENTION : il s'agit juste de l'en-tête. On n'affiche pas le message interne qui se trouve normalement après l'en-tête HTTP. Mais il y a un onglet REPONSE si vous voulez le voir, et on y trouve un bouton code brut.

Un exemple de réception possible (j'ai rajouté l'endroit où se trouve le message interne renvoyé) :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 36435
Vary: Cookie
Via: 1.1 alproxy
Date: Thu, 19 Mar 2020 12:54:47 GMT


<!DOCTYPE html>... : la suite, c'est le fichier html au complet !

12° Descendre encore un peu plus bas : activer également En-têtes brutes mais cette fois sur l'en-tête de la REQUETE que votre navigateur a réellement envoyé. Comme vous pourrez le voir, nulle trace à ce moment de votre adresse IP : elle apparaît sur l'en-tête reçu par le site, c'est bien qu'on a rajouté l'information à un moment.

13° Faire cette demande inconnue https://www.infoforall.fr/ast/snt/historique-du-webeeux/. Comment le navigateur va-t-il savoir que quelque chose s'est mal passé ? Quelle est le numéro de la réponse cette fois ?

Erreur 404

...CORRECTION...

Il s'agit de la fameuse erreur 404 !

Lorsque le navigateur reçoit une réponse http de ce type du serveur, il sait que le serveur lui dit que sa requête n'a pas pu aboutir pour une raison simple : la ressource demandée n'existe pas ! La plupart du temps, il s'agit d'une ressource qui a existé mais qu'on a supprimé du serveur.

La plupart des sites proposent des pages 404 personnalisées.

14° Faire la requête inconnue suivante sur le site de blizzard (bloqué au lycée):

https://www.blizzard.com/fr-fr/testrate/.

Répondre ensuite aux questions suivantes :

  • Quel protocole a été utilisé ?
  • Quel est le nom du serveur à contacter ?

...CORRECTION...

  • Quel protocole a été utilisé ? https
  • Quel est le nom du serveur a contacté ? www.blizzard.com
  • Quelle est la requête demandée à ce serveur ? /fr-fr/testrate/
  • Quel est son IP ? 34.253.25.0:443 au moment où moi j'ai fait le test
  • Quel est le numéro de sa réponse ? 404 !

✎ 15° Choisir et fournir une URL. A l'aide de code source de la page, donner les 3 premières requêtes qui vont être demandées après lecture de la première réponse HTTP contenant le code HTML de la page.

4 - Transférer des données : méthodes GET et POST

Nous avons vu que le HTTP était basé sur un modèle client-serveur.

1 Requête - 2 - Traitement - 3 - Réponse
Requête - Traitement - Réponse

Un programme-serveur tourne sur un ordinateur distant qu'on nomme machine-serveur ou juste serveur par simplification.

Les étapes de la communication :

  • Etape 1 : un programme-client (un navigateur, un robot-explorateur, ...), va envoyer une requête http au serveur.
  • Etape 2 : le programme-serveur reçoit la requête http et va la traiter. C'est cette étape que nous allons voir aujourd'hui.
  • Etape 3 : le programme-serveur répond en envoyant sa réponse http au client.

Pour transmettre des informations au serveur, nous avons vu que le client pouvait utiliser les méthodes GET et POST :

  • Avec GET, on transmet toutes les informations pour le serveur directement via l'URL.
  • Avec POST, on transmet une partie des informations pour le serveur dans le corps du message.

La différence est donc liée à l'endroit où on place les paramètres qu'on peut envoyer à la page.

✎ 16° Restez sur la page où vous êtes mais tapez ceci dans la barre de navigation qui va permettre de faire une requête GET :

https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234

  1. regardez la requête ci-dessous
  2. relancez la page pour appliquer cette URL puis
  3. revenez à cette question et
  4. regardez ce qui a changé dans la requête ci-dessous reçue par le serveur.

Question : dans une requête de type GET, les paramètres sont-ils transmis dans l'URL ou sont-ils intégrés au corps (BODY) de la requête ?

GET /act/archi/protocole-http-couche-application/ HTTP/1.1
Host: www.infoforall.fr

User-Agent: CCBot/2.0 (https://commoncrawl.org/faq/)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: br,gzip
Connection: Keep-Alive
X-Real-Ip: 34.239.157.140
Via: 1.1 alproxy
X-Forwarded-Proto: https

BODY VIDE !

FIN DE LA REQUETE
Méthode GET : paramètres dans l'URL

La méthode GET permet de discuter très facilement avec le serveur : les paramètres qu'on veut lui transmettre sont directement dans l'URL.

Derrière la ressource demandée, vous allez trouver un caractère ? pour indiquer qu'il y a des paramètres à récupérer derrière.

Exemple : ?user=toto&password=1234

Voici la codification du passage en GET :

  • Présence de /? après la ressource demandée
  • Présence d'un premier couple user=toto
  • Présence optionnelle d'un & pour signaler qu'il y a un autre paramètre à la suite : &password=1234
  • Tant qu'il y a des &, on continue...

Sur cet exemple, on voit donc qu'on transfère deux paramètres au serveur :

  1. user valant toto
  2. password valant 1234

Petit rappel sur la lecture d'une URL 

https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234

  • En première position, on trouve le protocole utilisé
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
  • Ensuite le nom ou l'adresse IP de la machine serveur à joindre :
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
      • Sous-domaine à gauche : www
      • Domaine à droite : infoforall.fr
  • L'adresse absolue de la ressource sur le serveur : elle commence par un slash / pour indiquer qu'on part de la racine du service :
    • https://www.infoforall.fr/act/archi/communication-client-serveur/?user=toto&password=1234
  • Derrière, ce sont les paramètres éventuels.

17° La boîte ci-dessus vous permet de voir la valeur des paramètres éventuels question et numero envoyés sur cette page. Avez-vous transféré de tels paramètres ou sont-ils inexistants dans votre URL pour l'instant ?

Valeur du paramètre question :

Valeur du paramètre numero :

Ce ne sont pas les bonnes valeurs de paramètres !

✎ 18° Restez sur la page où vous êtes et :

  1. transférez (via l'URL de la barre d'adresses) le paramètre question à la valeur corrige et le paramètre numero à la valeur 2.
  2. appuyez sur Entrée dans la barre d'adresses puis revenez ici.
  3. label
  4. Vous devriez voir un affichage BRAVO ! juste au dessus.

Magie !

Noter sur la copie numérique l'URL que vous avez dû taper pour obtenir BRAVO.

SI VOUS BLOQUEZ : voir le bout de cours juste au dessus, celui nommé Méthode GET : paramètres dans l'URL.

✎ 19° Un serveur reçoit une requête GET de ce type :

www.infoforall.fr/question_trop_difficile/?difficulte=outch&note=4

A-t-on transmis des paramètres ? Lesquels ? Quelles sont leurs valeurs ?

Voyons maintenant la méthode POST. Cette fois, le client va transmettre les données fournies dans le corps de la requête HTTP.

✎ 20° Utiliser le formulaire ci-dessous en choisissant des valeurs pour les paramètres question et numero. En appuyant sur SUBMIT, vous allez envoyer les données vers une page acceptant la requête en POST. On y affiche le contenu de la requête.

Deux réponses à fournir sur la copie :

  1. En lisant la requête, où voit-on qu'il s'agit d'une requête POST ?
  2. Où se trouvent cette fois les informations liées aux paramètres envoyés : dans le corps (body) de la requête ou dans l'URL ?

Attention, il a donc deux façons de modifier une page en fonction des données fournies par le client :

Script côté CLIENT

Vous avez appliqué cette méthode lors de votre découverte de Javascript.

On peut utiliser un code côté client : un code Javascript a été envoyé par le serveur.

Le code tourne actuellement sur l'ordinateur-client.

C'est ce que vous avez fait lorsque vous avez découvert JS. On utilise donc les ressources du client pour réaliser le traitement des données : on peut lire le contenu dans le formulaire et modifier les balises en cherchant les références à l'aide des attributs. Le code HTML est donc modifié sur la machine client APRES l'envoi par le serveur.

JS modifiant le HTML côté CLIENT
Modification côté CLIENT
  • Langage de script usuel : Javascript.
  • Avantage : on utilise les ressources du client et on peut réagir à ses actions en temps réel.
  • Désavantage : un client sachant lire le code source peut lire votre code très facilement. Ce n'est pas utilisable pour gérer un mot de passe.
Programme côté SERVEUR

Cela, vous ne savez pas encore le faire.

On a utilisé un code côté serveur : le programme tourne sur l'ordinateur-serveur.

Ce programme analyse la requête GET ou POST pour récupérer les paramètres. Le serveur envoie alors un code HTML en fonction du résultat du test : bonne correspondance alias - mot de passe ou pas.

JS modifiant le HTML côté SERVEUR
Modification côté SERVEUR

Ca, vous ne l'avez pas encore fait. Nous allons le faire aujourd'hui.

  • Plein de langages disponibles :
    • PHP est certainement le plus connu car le premier a avoir permis de faire cela facilement. Wordpress fonctionne en PHP.
    • on peut utiliser Python
    • on peut utiliser Javascript (mais côté serveur attention !)
    • ... et plein d'autres encore.
  • Avantage : le client ne peut aucunement avoir accès à ce code. Et ça, c'est fondamental dès que vous voulez gérer des mots de passe.
  • Désavantage : c'est l'ordinateur-serveur qui travaille. Il doit donc être assez puissant pour gérer toutes les demandes des clients.
Couche TRANSPORT Protocole : TCP (et +) Adresse : PORT Message : SEGMENT DATA d'un programme SEGMENT TCP Port SRC 443 Port DST 2050 Seq 4 Suiv 2 Flags : ACK CS : 15241 PAQUET IP IP DST 25.25.25.5 IP SRC 45.45.45.2 TRAME (Ethernet ou Wifi) SEQUENCE INTIALE MAC DST MAC SRC CheckSum selon le type de trame Couche RESEAU Protocole : IP (et +) Adresse : IP Message : PAQUET Couche LIAISON Protocole : WLAN ... Adresse : MAC Message : TRAME Couche Application HTTP pour Firefox Couche Application IMAP pour Thunderbird Couche Application Serveur HTTP Communication prog A Comm. prog B A B Rq TCP Rp1 TCP Rp2 TCP vide TCP ? A TCP IP Trame B TCP IP Trame data SRC 2050 DST 443 Seq data SRC 24945 DST 443 Seq data SRC DST CS data Seq Suiv F vide Seq Suiv F SRC 2050 DST 443 F ACK Suiv 0 Seq 1 CS XXXXX

Nous avons donc vu comment deux programmes parviennent à communiquer, ici en se transférant un simple texte codifié respectant un protocole et possèdant des informations supplémentaires en plus du message en lui-même.

La couche APPLICATION est chargée de structurer la communication entre deux programmes utilisant un même protocole. Pour cela, elle doit pouvoir

  1. structurer correctement la communication qu'un programme envoie ou reçoit : elle sait faire
  2. transmettre la communication à l'autre programme : elle ne sait pas faire cela...

Du coup, comment fait-elle ?

La couche APPLICATION va faire appel à une amie qui pourra transmettre le message : la couche TRANSPORT.

On retrouve bien l'idée que pour faire une chose complexe, on décompose en plusieurs tâches plus simples.

Le détail dans l'activité suivante.

5 - FAQ

Rien pour le moment

6 - QCM de fin de 1er

En cours de réalisation

La prochaine activité traitera donc du transfert du message à l'aide de la couche TRANSPORT qui peut utiliser notamment le protocole TCP.

Activité publiée le 15 05 2021
Dernière modification : 27 05 2021
Auteur : ows. h.