Les réseaux informatiques/La couche application : le web et ses protocoles

Nous arrivons à la fin de ce cours. Il ne nous reste plus qu'à voir la couche application, celle qui contient la plupart des protocoles liés aux sites web. Et pour bien introduire ce chapitre, commençons par voir quelques notions de base sur les sites web. Rappelons que la majorité des sites web fonctionnent sur le principe du client-serveur, vu dans le premier chapitre sur cours. Un site web n'est ni plus ni moins qu'un ensemble de fichiers stockés sur un serveur web. Chaque page correspond à un ou plusieurs fichiers : une page en pur texte est d'un seul tenant, alors que les pages avec des vidéos ou des images ont un fichier supplémentaire par image/vidéo. Les ordinateurs qui veulent consulter un site web vont se connecter au serveur : ce sont les clients web. Les navigateurs web sont des applications qui permettent à un client web de consulter le contenu des serveurs web, pour les consulter pages, télécharger des fichiers, ou toute autre action du même genre.

Au tout début d'internet, les pages web étaient ce qu'on appelle des pages web statiques. L'ensemble de la page est stocké dans un fichier, qui est interprété tel quel par un navigateur web. Ce fichier n'est cependant pas un fichier image ou un fichier texte habituel, mais est codé dans un langage de description de documents particulier : le HTML, très souvent couplé avec du CSS. Le premier définit une syntaxe particulière pour afficher différents widgets, listes, tableaux texte, et autres. Le second définit diverses options d'apparence, qui permettent de modifier l'allure et les graphismes des widgets. Dans tous les cas, les pages statiques ont un contenu immuable, déterminé lors de leur conception, incapable de s'adapter aux circonstances. Par exemple, elles ne permettent pas de créer des comptes clients, pour se connecter à un site, ou des fioritures similaires.

De nos jours, le HTML et le CSS sont complétés par d'autres langages de programmation, qui permettent d'obtenir des sites plus évolués. Ces sites ont des pages web dynamiques, qui peuvent s'adapter au client. Ces pages web sont calculées à la volée par le serveur, ce qui est utile dans divers scénarios. Par exemple, un site web sur lequel on peut s'inscrire ou avec un forum sera systématiquement une page web dynamique. Le langage de programmation utilisé par sur ces pages est souvent le PHP, éventuellement du Javascript. Le PHP est un langage qui s’exécute sur le serveur, ce qui permet notamment l'accès à une BDD quelconque. La page web est alors construite, calculée à la volée par le serveur. En comparaison, le Javascript est un langage qui s’exécute sur le client, dans son navigateur web. Il faut noter que le HTML et le CSS sont cependant utilisés de concert avec PHP/Javascript sur les pages dynamiques.

Les adresses web (URL)

Toute page web a une adresse appelée adresse URL, qui est utilisée pour y accéder ou pour créer des liens vers celui-ci. Les adresses URL ressemblent plus ou moins à ceci : http://www.example.com.

Prenons une adresse URL, https://www.fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal par exemple. Il faut savoir que seule une partie de l'adresse URL est utile pour identifier l'adresse IP du serveur. Le reste de l'adresse sert à indiquer quel est le fichier demandé, mais ne sert pas à spécifier le serveur. La partie de l'URL qui détermine l'IP est ce qu'on appelle le nom de domaine. Généralement, le nom de domaine est situé après www. et avant le symbole "/" qui suit. En reprenant l'adresse suivante, le nom de domaine est www.fr.wikipedia.org et le reste de l'adresse, /wiki/Wikip%C3%A9dia:Accueil_principal, sert à indiquer où on doit aller chercher le fichier.

L'organisation hiérarchique des domaines

Un nom de domaine est composé de plusieurs noms, séparés par des points. Chaque nom fait référence à ce qu'on appelle un domaine internet, quelque chose qui regroupe plusieurs sites ou pages web qui ont un lien.

L'ensemble des domaines est organisée de manière hiérarchique, avec des domaines de 1er niveau, de 2nd niveau, de 3ème niveau, etc.

Organisation hiérarchique des domaines internet.

Les domaines principaux, appelés domaines de premier niveau, sont les fameux domaines .fr, .uk, .com, .org, et ainsi de suite. Ils sont gérés par l'ICANN (Internet Corporation for Assigned Names and Numbers), un organisme américain, depuis 1998. L'ICANN distingue deux types de noms de domaines : les domaines géographiques (.fr, par exemple) sont liés à un pays, tandis que les autres sont liés à des organisations (.gov pour les gouvernements, .edu pour les établissements scolaires, .mil pour les organismes militaires, et quelques autres).

En dessous de ces domaines, on trouve des domaines de second et de troisième niveau, qui sont subordonnées aux domaines de niveau inférieur. Par exemple, le .gouv est un domaine de second niveau (un sous-domaine) : tous les sites en .gouv seront des sites en .fr. Ces sous-domaines sont des sortes de subdivisions d'un domaine de premier niveau. Même chose pour les domaines de troisième niveau, qui sont des subdivisions d'un domaine de second niveau.

Enfin, les domaines de plus bas niveau regroupent les pages web d'un même site. En effet, dans le cas général, toutes les pages d'un site web font partie du même domaine. Par exemple, dans le nom de domaine www.fr.wikipedia.org, c'est le cas du domaine wikipedia.

Chaque domaine de second niveau appartient à un domaine de 1er niveau, de même que les domaines de 3ème niveau appartiennent à un domaine de 2nd niveau et ainsi de suite. On peut relier les domaines en fonction de leurs relations d'inclusion, ce qui donne un arbre qui organise les domaines de manière hiérarchique. Cet arbre est ce qu'on appelle la hiérarchie des noms de domaine. Une partie de cet arbre est illustrée ci-dessous.

Les domaines les plus courants

Liste de quelques domaines géographiques européens.

Les noms de domaines peuvent être lié à la localisation géographique ou la langue du site : c'est par exemple le cas du domaine .fr ou .uk. De tels domaines sont appelés des domaines géographiques. La plupart de ces domaines sont liés à des pays, comme le .fr pour la France, l’Angleterre pour le .uk, l’Espagne pour le .es, etc. Ce sont des domaines dits nationaux. En tout, il existe près de 206 noms de domaines nationaux. Il existe aussi quelques pays liés à des régions à l'intérieur d'un pays, voire à des villes, comme le .paris ou le .alsace en France. Les domaines liés à des pays sont tous des domaines de 1er niveau, alors que ceux des régions/villes sont des domaines de 2nd niveau.

D'autres domaines ne sont pas liés à un pays, mais ont une utilisation plus large. En voici quelques-uns :

Le .com a été conçu pour être le nom de domaine pour les sites commerciaux. D'ailleurs, .com est l'abréviation de .commercial. Mais son rôle a changé depuis et il est depuis ouvert à tous. Il regroupe donc des sites très différents, sans règles particulières.
Le .org a été conçu pour être utilisé pour les organisations privées à but non-commercial. Comme pour le .com, il est depuis ouvert à tous les sites qui en font la demande. À ce propos, les sites de la wikifondation (wikipédia, wikilivres, wikicommons), sont dans le domaine.org.
Le .gov est utilisé pour les organismes gouvernementaux américains. Les autres pays ont bien un domaine pour leurs organismes gouvernementaux, mais il s'agit d'un domaine de second niveau. Par exemple, en France, le domaine pour les organismes gouvernementaux est le .gouv, qui est un sous-domaine du .fr.
Le .edu est utilisé pour les organismes d'enseignement de grande ampleur, comme les universités ou les grandes écoles. Il est surtout utilisé par les organismes américains, mais quelques organismes non-américains ont un domaine en .edu.
Et il y en a bien d'autres, comme le .info, le .net, le .arpa, le .int, le .mail, etc.

La conversion des noms de domaine en adresses IP

Comme dit plus haut, un nom de domaine identifie un ordinateur/serveur bien précis sur le net. Mais l'accès à un fichier sur ce dit serveur doit se faire par des communications basées sur le réseau IP, les noms de domaine ne pouvant pas servir directement pour communiquer. Pour lire une page web, le navigateur web doit découvrir l'adresse IP du serveur, à partir de son nom de domaine. Cette traduction d'un nom de domaine en IP peut se faire de plusieurs manières différentes : soit avec un fichier pré-configuré, soit avec un protocole dédié (le protocole DNS).

Notons que distinguer les adresses IP et les noms de domaine est plus simple pour les être humains (une suite de mots est plus facile à retenir qu'une suite de nombres), mais a aussi d'autres avantages. Par exemple, cela permet de changer plus facilement un serveur pour un autre, tout en gardant le même nom de domaine. Pour en donner un exemple, cela permet d'utiliser un serveur de sauvegarde en complément du serveur principal. Si le serveur principal tombe en panne, la mise à jour des correspondances ip <-> nom de domaine suffit pour faire le remplacement.

Le fichier HOST

Au tout début d'internet, les correspondances entre IP et URL étaient mémorisées dans des fichiers HOSTS.TXT, qui existe toujours sur certains systèmes d'exploitation.

Exemple d'entrée dans le fichier Host.txt.

Ce fichier était accessible sur un serveur dédié, maintenu par le Network Information Center. Mais cette méthode a rapidement montré ses limites avec l'augmentation du nombre de sites. Vu le nombre actuel de sites web, on ne peut pas en garder un gros annuaire dans un seul et unique fichier sur chaque ordinateur.

Cependant, le fichier host.txt est toujours utilisé par les systèmes d'exploitation modernes et les navigateurs web peuvent l'utiliser comme bon leur semble. Modifier le fichier host.txt permet de bloquer des sites web : il suffit de leur attribuer une adresse IP invalide. Cette technique est une des techniques utilisée par certains logiciels de contrôle parental. Elle est aussi utilisée par des antispywares comme Spybot : celui-ci bloque des sites web conçus pour propager des spywares, en les bloquant via le fichier Host.txt.

Le protocole DNS

De nos jours, le navigateur ne connait pas l'IP qui correspond à l'URL, et il doit la récupérer sur le net. Des serveurs naissent et meurent tous les jours, et l'IP associée à une URL peut ainsi changer. Pour récupérer cette IP, le navigateur va devoir utiliser un protocole (oui, encore un) : le protocole Domain Name System (DNS). Ce protocole mémorise les correspondances IP - URL sur plusieurs serveurs DNS. L'ensemble de ces serveurs DNS contient en quelque sorte l'annuaire d'internet. Le protocole DNS est utilisé avant toute communication avec un serveur web. D'abord, le navigateur web communique avec des serveurs DNS pour récupérer l'IP du serveur, et ensuite il utilise cette IP pour télécharger la page web demandée. Le protocole DNS indique comment on doit interroger les serveurs DNS et comment ceux-ci doivent répondre aux demandes qui leur sont envoyées. C'est un simple standard de communication, du moins pour simplifier.

Les serveurs racine

Si les noms de domaines sont structurés de manière hiérarchique, il est évident que cette organisation se retrouve pour la traduction en adresses IP. Quand un navigateur veut traduire un nom de domaine en IP, il va interroger un serveur racine.

Au début d'Internet, les serveurs principaux étaient au nombre strict de 13 et étaient nommés serveurs A, B, C, D, E, F, G, H, I, J, K, L, et M.

De nos jours, les serveurs racine principaux sont complétés par des serveurs relais, ainsi que par des serveurs de rechange, qui s'activent quand un serveur tombe en panne ou est surchargé.

Le parcours récursif de la hiérarchie des domaines

Prenons un client DNS qui veut consulter le site fr.wikipedia.org, mais qui ne connait pas l'IP qui correspond. Le navigateur connait les adresses IP des serveurs racine, qui sont des adresses fixes et réservées. Il peut donc interroger le serveur racine et lui demander quel est l'IP du site. Il lui envoie une requête DNS, qui transmet le nom de domaine et auquel le serveur doit répondre. Le serveur DNS peut répondre de deux manières : soit le serveur connait l'IP qui correspond au nom de domaine, soit il peut donner l'IP d'un serveur qui devrait connaitre cette adresse. Dans le premier cas, l'IP est renvoyée par le serveur et la recherche s’arrête. Dans le second cas, le serveur racine renvoyer l'IP d'un autre serveur DNS, qui peut correspondre au nom de domaine associé. Le processus de recherche continue tant qu'on lui fournit une adresse de serveur DNS qui peut contenir l'IP voulue.

Dans le détail, tout commence par une question envoyée au serveur racine. Le serveur racine ne connait pas l'IP du site web demandé, quel qu’il soit. Par contre, il sait quels sont les serveurs associés à chaque domaine de premier niveau, et peut renvoyer leur adresse IP. Le client reçoit la réponse et renvoie sa requête à l'IP envoyée, au serveur de premier niveau. Le serveur DNS de premier niveau renvoie alors l'adresse d'un serveur chargé du domaine de second niveau. Et ainsi de suite : le processus se poursuit jusqu'à ce qu'on tombe sur l'IP recherchée.

La plupart des nœuds réseaux mémorise les réponses aux demandes les plus courantes dans une portion de RAM : le cache DNS. Par exemple, tout ordinateur dispose d'un cache DNS dans sa mémoire, qui permet de mémoriser les IP des sites récemment visités. Quand un site est visité la première fois, on conserve son IP, afin de la réutiliser lors des prochains accès. Pas besoin de demander l'IP du site à chaque fois, seul le premier accès entraine une requête DNS. Ainsi, les réponses aux requêtes les plus fréquentes peuvent être lues depuis ce cache, ce qui est plus rapide. Cependant, les résultats sont effacés du cache après un certain temps, au cas où l'IP associée à un nom de domaine change.

Les requêtes et réponses DNS

Les requêtes envoyées aux serveurs DNS ont le même format que les réponses de ces serveurs. Le paquet DNS est composé d'un en-tête suivi par une ou plusieurs requêtes/réponses de taille fixe.

L'en-tête DNS est structuré comme suit :
- Il commence par un champ d'identification qui contient le numéro à la transaction DNS. Ce numéro permet de savoir quelle réponse est associée à quelle requête : par exemple, la réponse numéro 15 contient les IP demandées par la requête numéro 15.
- Il est suivi par quelques flags, des bits qui précisent quelques options déterminées.
- Le reste donne le nombre de requêtes et de réponses DNS dans le paquet DNS. Le nombre de requêtes est variable dans le paquet, et il n'est pas rare qu'il y en ait plusieurs dans le même paquet, mais elles sont toutes placées les unes à la suite des autres. Il en est de même avec le nombre de réponses : le serveur peut rassembler plusieurs réponses dans un seul paquet.
L'en-tête est suivi par les requêtes et les réponses DNS, qui forment le contenu du paquet DNS.
- Chaque requête contient l'adresse URL à traduire, ainsi que quelques informations annexes.
- Les requêtes sont ensuite suivies par les réponses de la part du serveur.
- D'autres informations additionnelles sont placées à la fin du paquet.

Pour ceux qui veulent en savoir plus, je conseille la lecture du wikilivre sur le DNS, disponible à cette adresse :

Système de noms de domaine

Le protocole HTTP

Une fois que le DNS a permis d'obtenir l'IP du serveur web, il est temps d'échanger des informations avec le serveur. Pour les communications entre serveur et client web, il existe un protocole dédié : l'HyperText Transfert Protocol, aussi appelé HTTP. Le HTTP est pris en charge par les navigateurs web et par les serveurs web. Les navigateurs web sont installés sur l'ordinateur client, les serveurs étant installés...sur les serveurs. Les échanges client-serveur se basent sur le protocole TCP : on dit que HTTP est basé sur le TCP. Il a existé plusieurs versions du protocole HTTP, la toute première étant la version 0.9 et la dernière la 1.1 (à l'heure où j'écris ces lignes, janvier 2016). Il peut paraitre bizarre que la première version soit la 0.9 et non la 1.0. Mais il faut savoir que la 0.9 n'avait pas de numéro de version à la base, l'introduction des numéros de version s'étant fait en catastrophe à partir de la version 1.0. L'ancienne version sans numéro a alors été renommée en HTTP 0.9.

Le HTTPS est une version chiffrée du HTTP, où les commandes sont transmises après avoir étés cryptées. Cette version du HTTP existe pour une raison simple : avec le HTTP normal, un attaquant peut parfaitement intercepter les paquets et avoir accès à leur contenu. Et si ce contenu est votre code de carte bleu, que vous avez saisi pour faire des achats en ligne, cela peut donner une belle catastrophe. Pour éviter cela, le HTTP utilise un système de chiffrement dit asymétrique, qui empêche toute attaque de ce genre. Ce système de chiffrement est basé sur le protocole Transport Layer Security aussi appelé TLS.

Les connexions HTTP

Comme on l'a dit plus haut, HTTP est un protocole en mode connecté : le client doit se connecter au serveur avant de pouvoir lui envoyer des commandes HTTP. C’est pour cette raison qu'HTTP est basé sur le protocole TCP, qui a un mode connecté, et non sur UDP, protocole sans connexion. Il arrive que le client et le serveur doivent faire plusieurs échanges successifs et communiquer sur une période de temps assez longue. On se retrouve alors avec un choix à faire : est-ce que chaque échange ouvre et ferme une connexion dédiée, ou est-ce que ces échanges sont pris en charge par une seule connexion ?

Dans le premier cas, chaque échange a sa propre connexion. Tout envoi de commande HTTP ouvre une connexion, qui sera fermée lors de la réponse du serveur. C'est ce qu'on appelle des connexions non-persistantes.

Dans le second cas, le client ouvre une connexion avec le serveur, effectue autant d'échanges qu'il souhaite avec cette connexion et ne la ferme qu'une fois l'ensemble des échanges terminés. C'est ce qu'on appelle des connexions persistantes. Avec elles, les connexions TCP ne sont pas fermées après que le serveur a répondu à une commande : elles peuvent servir pour plusieurs commandes successives. Cela permet d'économiser des connexions TCP, chose qui améliore quelque peu les performances. Les termes persistants et non-persistants caractérisent bien la nature de ces connexions. Avec les versions 0.9 et 1.0 du HTTP, les connexions sont non-persistantes. Les versions suivantes du HTTP utilisent les connexions persistantes.

Une autre optimisation permise par le HTTP 1.1 est le pipelining HTTP. Avec cette technique, un client HTTP peut envoyer une nouvelle commande, sans attendre que le serveur réponde à la précédente. Au lieu d'envoyer les commandes unes par unes, on peut les envoyer en rafales.

Le tout est résumé dans ce tableau :

Les commandes HTTP

Chaque échange du client vers le serveur, ou inversement, prend la forme d'un message HTTP. Les messages envoyés du client vers le serveur sont des requêtes HTTP, alors que ceux allant dans l'autre sens sont des réponses HTTP. Ces messages HTTP sont de simples fichiers texte encodés en ASCII, lisibles par tout être humain avec un cerveau en état de marche.

Les requêtes HTTP

Le protocole HTTP normalise différentes requêtes HTTP, comme GET, HEAD ou POST, qui agissent chacune sur une URL. Ces commandes sont envoyées dans des paquets TCP, le contenu de la commande étant placé dans les données du paquet. Ces commandes sont envoyées par le client, et le serveur doit obligatoirement répondre à celles-ci : ces commandes sont des ordres envoyés au serveur.

Ces commandes sont les suivantes :

GET : obtenir la page web demandée ;
HEAD : obtenir des informations sur la page, sans la consulter ;
POST : envoyer une ressource sur le serveur (un message sur un forum, par exemple) ;
PUT : remplace ou ajoute une ressource sur le serveur ;
DELETE : supprime une ressource sur le serveur ;
OPTIONS : obtenir les options de communications utilisées par le serveur ;
CONNECT : commande spécialisée pour les proxys ;
TRACE : permet de tester la liaison entre serveur et client.

Le message HTTP envoyé au serveur est un fichier texte formaté d'une certaine manière. Voici un exemple de requête HTTP :

   GET /somedir/page.html HTTP/1.1
   Host: www.someschool.edu
   Connection: close
   User-agent: Mozilla/5.0
   Accept-language: fr

On voit que la première ligne donne toutes les informations pour traiter la requête. Elle est appelée la ligne de requête. Elle commence par le nom de la commande, suivi de l'adresse URL demandée, elle-même suivie par la version de HTTP utilisée. La ligne de requête est suivie par une ou plusieurs ligne d'en-tête, qui fournissent des informations diverses. La ligne Host donne le nom de domaine qui doit répondre à la requête. La ligne Connection précise s'il faut utiliser des connexions persistantes ou non : close signifie que les connexions ne doivent pas être persistantes, alors que open les autorise. La ligne User-agent donne des informations sur le navigateur web à l'origine de la requête. La ligne Accept-language précise la langue préférée pour la réponse.

Les réponses HTTP

Le serveur répond à ces commandes en envoyant un paquet au contenu standardisé. Celui-ci peut contenir la page web demandée, pour répondre aux commandes GET ou HEAD, par exemple. Mais dans tous les cas, le serveur web indique si tout s'est bien passé ou si une erreur a eu lieu. Pour cela, il renvoie un code de statut HTTP, qui indique si tout s'est bien passé et quelles sont les erreurs qui ont eu lieu1. Par exemple, il va renvoyer une 404 si la ressource demandée n'a pas été trouvée sur le serveur. Les plus courants sont :

200 : tout s'est bien passé ;
301 et 302 : redirection vers une autre page ;
403 : accès refusé ;
404 : page non trouvée ;
500 : erreur interne au serveur.

Le format des messages de réponse est assez simple à comprendre. Comme pour les requêtes, on trouve une ligne de requête, suivie d'une ligne d'en-tête, et de la page demandée. La première ligne indique la version de HTTP utilisée, suivie du code de statut et d'une phrase. Les lignes d'en-tête fournissent d'autres informations, comme le statut des connexions, la date d'envoi, le type de serveur, etc.

   HTTP/1.1 200 OK
   Connection: close
   Date: Tue, 09 Aug 2011 15:44:04 GMT
   Server: Apache/2.2.3 (CentOS)
   Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
   Content-Length: 6821
   Content-Type: text/html
   Données de la page

Les cookies HTTP

HTTP est ce qu'on appelle un protocole sans état, à savoir que le serveur ne mémorise aucune information sur le client. En conséquence, quand le serveur reçoit une requête, il la traite toujours de la même manière. Un client peut ainsi envoyer plusieurs fois de suite la même requête et recevoir la même réponse : le serveur ne va refuser les requêtes suivantes sous prétexte qu'elles ont déjà été servies. Cette particularité permet de fortement simplifier le protocole, sans compter qu'elle permet un gain de performance non-négligeable par rapport à un protocole avec état. Le traitement d'une requête ne demande pas l'accès à une liste d'informations client ou à un historique de connexions, n'a pas besoin de gaspiller de la RAM pour stocker des informations client, etc. C'est pour cela qu'il existe de nos jours des serveurs capables de traiter plusieurs millions, voire milliards, de connexions simultanées.

Cependant, certaines applications ont besoin de stocker des informations spécifiques à chaque client. Pour cela, HTTP déporte le stockage de ces informations sur le client, au lieu de le mettre sur le serveur. Dans le détail, HTTP permet le stockage sur le client de fichiers utiles pour le serveur, qui sont nommés cookies. Ceux-ci sont des fichiers que le serveur envoie au client et que ce dernier conserve dans sa mémoire. Dit autrement, les cookies sont des fichiers enregistrés sur votre ordinateur, par les sites web. Leur utilité est de mémoriser des informations sur votre ordinateur, et non sur le serveur lui-même. Ils peuvent contenir absolument tout et n’importe quoi, tant que le site aura jugé utile d'enregistrer ces informations dans le cookie. Par exemple, ils peuvent y enregistrer vos MDP et login, ce qui vous permet de ne pas avoir à les saisir à chaque connexion, de vous maintenir connecté. Les sites d'e-commerce sauvegardent aussi les paniers de produits réservés/sélectionnés avant qu'on passe commande. Ce sont des fichiers texte, et ne sont donc pas des programmes exécutables (ce ne sont donc pas des virus).

À chaque fois que vous envoyez une requête à un serveur, celui-ci lira les cookies qu'il a déposés sur votre ordinateur et peut les mettre à jour. La seule exception est pour la première requête, vu que le serveur n'a pas pût déposer de cookie sur le client. Pour résumer, tout se déroule comme suit : le client envoie une première requête au serveur, puis le serveur renvoie le fichier demandé (une page web, par exemple), ainsi que le cookie. On dit que le serveur dépose le cookie sur votre ordinateur. Les requêtes suivantes renvoient le cookie en plus de la requête proprement dite.

Les cookies peuvent être conservés dans la mémoire RAM ou sur le disque dur, ce qui permet de distinguer deux types de cookies : les temporaires et les persistants. Les cookies temporaires (aussi appelés cookies de session) sont maintenus dans la mémoire RAM de l'ordinateur et ne sont pas sauvegardés sur le disque dur. Lors de la fermeture du navigateur, ils sont effacés ou perdus. Ce n'est pas le cas des cookies persistants, qui sont sauvegardés sur le disque dur et ne s'effacent pas quand on ferme le navigateur. Le seul moyen de les supprimer est d'utiliser les options du navigateur, qui contiennent systématiquement de quoi les effacer. On peut aussi utiliser des utilitaires de nettoyage de disque, mais c'est quelque chose de déconseillé, pour diverses raisons.

Il est demandé aux navigateurs de supporter a minima :

300 cookies simultanés ;
4096 octets par cookie ;
20 cookies par « serveur » (hôte/domaine).

Les cookies traceurs

L'utilisation des cookies n'est pas forcément bienveillante, ni dans l'intérêt de l'utilisateur. Par exemple, certains services de publicité en ligne suivent les internautes sur plusieurs sites et collectent des informations grâce à un cookie de traçage enregistré sur l'ordinateur. Ces cookies permettent de tracer un utilisateur sur plusieurs sites qui partagent des éléments communs. Il suffit qu'une bannière publicitaire ou tout autre forme de publicité soit utilisée sur plusieurs sites. La visite du premier site dépose un cookie, que les autres sites consultés peuvent consulter. Le serveur de publicité sait, grâce à l'analyse du cookie de traçage, quels sont les sites visités par l'utilisateur.

Quelques extensions de navigateur web permettent de supprimer ou de bloquer ces cookies traceurs. On pourrait notamment citer les extensions Privacy Badger ou Ghostery, pour Firefox et Chrome. Les navigateurs internet récents ont commencé à prendre le problème au sérieux, en ajoutant une option qui empêche les sites de vous suivre à la trace avec de tels cookies. Cette option, appelée Do Not Track (ne me suivez pas), a cependant été mal implémentée : via cette option, on peut indiquer aux sites que l'on ne souhaite pas être pisté, mais ceux-ci font ce qu'ils veulent de cette information et peuvent parfaitement décider de la passer outre. En effet, il n'y a pas de contraintes légales quant à l'utilisation de cette option. De plus, cette option doit être activée dans les options du navigateur : elle est désactivée par défaut.

Le protocole FTP (File Transfert Protocol)

Le protocole FTP (File Transfert Protocol) est un protocole qui permet à un client de gérer les fichiers sur un serveur. Le protocole FTP permet au client de télécharger des fichiers sur un client (l'utilisation principale de FTP), mais aussi de modifier, remplacer ou supprimer des fichiers sur le serveur. FTP est un protocole de type client-serveur, dans le sens où il faut intervenir deux programmes : un logiciel sur le serveur, appelé serveur FTP, ainsi qu'un logiciel sur le client qui est appelé un client FTP. À l'instar d'HTTP, il existe des versions sécurisées de FTP, qui utilisent des systèmes de cryptage comme le SSL ou le TLS, qui sont appelées le FTPS.

Les connexions FTP : commande et données

La communication entre les deux utilise des connexions TCP, deux en tout :

Une connexion pour le transfert des données entre client et serveur, qui peut fonctionner pour transférer des fichiers dans les deux sens (du client vers le serveur, ou inversement).
Une connexion de commande, par laquelle le client envoie des ordres au serveur (requête de téléchargement, de suppression ou de modification de fichier, autre).

L'établissement des deux connexions se fait en deux étapes. Le processus est illustré ci-contre.

En premier lieu, le client envoie une commande FTP au serveur FTP. Elle prend la forme d'un paquet FTP spécial, nommé PASV ou ACTV selon le mode de connexion.
Le serveur envoie alors une réponse au client FTP, qui dit si la connexion est acceptée et sur quelle port. Elle prend la forme d'un message composé : d'un code réponse de trois chiffres codés en ASCII, parfois suivie d'un message texte optionnel. Par exemple, la réponse 200 OK signifie que la connexion est acceptée.
À la suite de cette réponse, la connexion est établie.

La liste des codes réponses des serveurs FTP et des commandes FTP est disponible via ce lien wikipédia :

* List of FTP commands.

* List of FTP server return code.

Le mode actif et le mode passif

Les deux connexions utilisent des ports distincts au niveau du serveur : le port 21 pour la réception des commandes et le port 20 pour le transfert des données. Cependant, il arrive que le port de transfert des données soit différent. Il faut dire qu'il peut faire l'objet d'une négociation entre client et serveur. Cela permet de distinguer deux types d'usage du FTP : le mode actif et le mode passif. Dans le mode actif, c'est le client FTP qui décide du port à utiliser pour le transfert de données. En mode passif, c'est le serveur qui décide sur quel port il émet les données. Le mode passif est surtout utilisé quand le client est protégé par un pare-feu, car il est le seul mode possible, le mode actif posant quelques problèmes avec les pare-feu.

◄ Retour vers « La couche présentation »

Sommaire du livre