1. Introduction▲
Il ne sera pas question ici de décortiquer en profondeur les rouages du HTTP. Nous allons plutôt nous intéresser à certains aspects du « surf ». En effet, s'il constitue la pratique la plus courante sur le Net, (avec la messagerie), il n'en présente pas moins beaucoup de côtés qui peuvent sembler « mystérieux ».
Les créateurs de sites web rivalisent d'ingéniosité pour réaliser des pages sophistiquées, qui mettent en œuvre beaucoup de techniques périphériques au protocole lui-même. Nous ne détaillerons pas toutes ces techniques, nous essayerons simplement de les présenter et de les démystifier…
On parle beaucoup du respect de la vie privée sur le Net. Nous verrons d'un peu plus près les petites indiscrétions qui sont pratiquées par-ci par-là.
Nous verrons également comment les documents sont demandés et reçus, quelle est la part de travail du navigateur du client et celle du serveur du fournisseur d'informations.
Nous verrons également quelles techniques sont utilisées pour accélérer la navigation, aussi bien du côté du client (cache local) que de celui du fournisseur d'accès (serveurs proxy).
Le serveur proxy mérite quelque attention. En effet, c'est un peu le couteau suisse de l'interconnexion entre un réseau local et le Net, beaucoup de réseaux locaux d'entreprise n'offrent l'accès au Net qu'à travers un proxy, pour diverses raisons dont nous verrons les plus importantes.
1-1. Évitons déjà une confusion▲
- HTTP (Hyper Text Transfert Protocol) est un protocole destiné à transférer du texte (ou des fichiers quelconques, s'ils sont définis par un format MIME) depuis un serveur vers un client. Initialement, il s'agissait bien de texte, sans illustrations, avec juste quelques possibilités d'enrichissement. Ceux qui utilisent un système GNU/Linux pourront essayer un navigateur en mode texte comme Lynx ;
- HTML (Hyper Text Markup Language) est un langage de description de document. Outre les possibilités d'enrichissement du texte comme les attributs gras, italique, souligné, les différents niveaux de titre, il offre la bien connue possibilité de définir des « hyperliens » entre documents ou parties de documents.
Même s'il est clair que HTTP et HTML voient leurs destins intimement liés, il s'agit bien de deux choses différentes…
HTTP est résolument orienté « fourniture de documentation ». Entendons par là que le but recherché est clairement (du moins initialement) de permettre à un client de trouver le document qui l'intéresse parmi la multitude d'informations stockées sur des serveurs dont le rôle est de publier ces documents à l'intention de qui les cherche. HTTP génère un flux de données pratiquement exclusivement dans le sens du serveur vers le client.
Aujourd'hui, la situation est un peu moins claire. Les usagers de l'Internet prennent une part de plus en plus active dans la création de contenu. Historiquement, la mise à jour du contenu d'un serveur HTTP se fait par un autre protocole : FTP (File Transfert Protocol). Cette méthode présente deux inconvénients :
- ce n'est pas d'une très grande souplesse d'usage ;
- lorsqu'un site est maintenu par plusieurs auteurs, la gestion des mises à jour peut devenir délicate.
Microsoft a ouvert le feu avec FrontPage, outil de création de documents HTML très intuitif, permettant de mettre en ligne ses documents sur un serveur HTTP « maison », pourvu des fameuses « extensions FrontPage ». Il s'agit d'Internet Information Services, assez connu pour ses trous de sécurité, du moins à ses débuts. L'extrême simplicité d'emploi du couple FrontPage/IIS est malheureusement handicapée par ces deux points fondamentaux :
- cette solution, propriétaire, oblige à n'utiliser que les technologies Microsoft, si l'on désire profiter de tous les avantages offerts ;
- les difficultés à maitriser la sécurité de cette solution, surtout sur un serveur public.
Des alternatives libres apparaissent, qui tendent à intégrer à HTTP des fonctions de transfert de fichiers du client vers le serveur, ainsi que des mécanismes de gestion efficace des mises à jour. Ces solutions manquent toutefois encore de maturité et présentent elles aussi parfois de graves inconvénients pour la sécurité des serveurs à accès public. Aussi, nous passons d'une époque où le contenu d'une page HTML était écrit « en dur » de façon statique, avec un outil spécialisé ou non, à une époque où le HTML est généré à la volée par le serveur, de façon dynamique, à partir d'informations stockées dans des bases de données ou dans des fichiers texte, comme c'est le cas pour ce site. Dans un tel cas, les données sont mises à jour par des formulaires HTML et envoyés au serveur par la méthode « POST » que nous verrons plus loin.
Du point de vue du client, peu importe que les pages soient statiques où dynamiques, ce qu'il reçoit est toujours du HTML.
1-2. Regardons en arrière▲
Historiquement, il a existé avant l'explosion du couple HTTP/HTML un autre outil permettant de servir simplement et efficacement des documents, il s'agissait du système « Gopher » : Du nom de l'écureuil américain, aussi appelé « spermophile », vivant dans un dédale de galeries. Le logiciel permettait de se promener dans le labyrinthe de l'Internet. Gofer signifie aussi en argot américain « Go for », qui veut dire « va chercher », et désignant un garçon de courses. (© Rheingold).Que les amoureux de l'histoire du Net se reportent au « jargon français », (d'où la définition ci-dessus a été tirée, voir aussi le Wikipédia). Disons simplement que ce protocole n'a pas survécu parce qu'il était « propriétaire ». En effet il appartenait à l'université du Minnesota, qui menaçait de réclamer des royalties pour son emploi. La réplique fut immédiate… Gopher est mort(1).
1-3. Regardons en avant▲
Aujourd'hui, HTTP est certainement le protocole le plus utilisé sur le Net et probablement le plus simple. C'est aussi certainement celui à qui l'on demande le plus. N'oublions pas qu'il est initialement conçu pour transporter du texte, avec des hyperliens. Or, que ne lui faisons-nous pas transporter… Avec l'avènement du haut débit, les pages s'alourdissent et embarquent chaque jour des fioritures de plus en plus élaborées, nécessitant des « plug-ins » généralement propriétaires (Flash, Shockwave, Real, etc.).
2. Notions de base▲
2-1. Quels mécanismes sont mis en œuvre dans le surf ?▲
HTTP est donc un protocole somme toute assez simple par lui-même. Ce qui complique la compréhension de l'ensemble des processus mis en œuvre, c'est toute « l'intelligence » qui est ajoutée, tant du côté serveur que du côté client.
Au départ, un client envoie une requête à un serveur HTTP et celui-ci y répond. Toute la difficulté vient de deux aspects qui sont indépendants du protocole HTTP lui-même :
- le traitement de l'information pratiqué par le serveur avant d'envoyer le résultat de la requête ;
- le traitement de l'information pratiqué par le client avant d'afficher le résultat de la requête.
2-1-1. Côté serveur▲
Lorsqu'une requête arrive sur le serveur, elle peut concerner :
- une simple page HTML « statique » (le suffixe de la page étant alors généralement .htm ou .html). Tout son contenu est déjà défini en HTML et le serveur n'a qu'à l'envoyer tel quel, au client. Dans cette configuration, un site web est fortement ressemblant au contenu d'un livre, il est écrit une fois pour toutes. Toute modification doit faire l'objet d'une réédition ;
- une page HTML dont certains éléments sont « dynamiques », c'est-à-dire qu'ils sont construits à partir de sources d'informations diverses au moment de l'envoi au client. Ces méthodes ont pour but de produire deux fournitures d'informations typiquement impossibles à réaliser simplement avec des pages purement statiques :
- des informations qui sont le résultat d'un calcul à partir d'éléments que le client a transmis au serveur dans sa requête,
- des informations issues d'une base de données mise à jour par un moyen quelconque. Ces informations peuvent évoluer à tout instant et leur affichage via HTTP nécessite leur intégration en temps réel dans le document,
- on peut bien entendu imaginer un document dont le contenu intègre les deux exercices précédents.
Plusieurs possibilités existent pour réaliser de telles opérations :
- les exécutables CGI (Common Gateway Interface).
Ces exécutables construisent intégralement un flux HTML au moment de leur appel. Cette technique, la plus ancienne, n'est pas forcément la meilleure. Les exécutables peuvent être écrits dans un langage compilé comme C ou dans un langage interprété comme Perl, Python, Java, voire PHP (bien qu'il n'ait pas été initialement conçu pour cet usage). L'exécutable est déroulé sur le serveur lui-même (ou sur un autre, mais ce n'est qu'un détail) ; - des langages plus « spécialisés » comme PHP, JSP ou ASP.
Active Server Pages est une technologie Microsoft, alors que Personal Home Page est une technologie libre. Les deux sont sensiblement identiques au niveau des concepts, mais pas de la syntaxe.
Ces technologies sont dites « Server Side », c'est-à-dire que les traitements sur l'information sont effectués sur le serveur.
L'avantage du « server side » est que le code HTML reçu par le client est du HTML pur, ce qui veut dire qu'a priori, tout navigateur peut l'afficher correctement, sans trop de précautions particulières de la part de l'auteur du site, si ce n'est au niveau de leur compatibilité avec les standards.
L'inconvénient est que le serveur voit sa charge augmenter dans des proportions qui peuvent être considérables et qu'en cas de connexion lente, la navigation devient vite pénible, lorsqu'il y a beaucoup de traitements d'informations introduites par le client, comme des calculs exécutés à partir de données issues d'un formulaire.
2-1-2. Côté client▲
De ce côté-là aussi, des traitements d'informations peuvent être utiles :
- contrôler par exemple la validité des informations saisies dans un formulaire, avant de les envoyer au serveur. Ceci évite des allers-retours inutiles en cas de saisie erronée ;
- effectuer un traitement local de certaines informations pour afficher un résultat. Un exemple serait d'inclure une calculette dans une page web, cette calculette travaillant uniquement chez le client, sans jamais rien envoyer au serveur (nous verrons cet exemple plus loin) ;
- réaliser toutes sortes d'opérations susceptibles de rendre les pages visitées plus vivantes, en introduisant des animations, des menus déroulants et toutes sortes de « gadgets » propres à égayer (de façon plus ou moins heureuse) une page web.
Là encore, les données peuvent être traitées, de diverses manières.
- Les JavaScript.
Ces petits applicatifs, transmis dans le document HTML, sont exécutés côté client par le navigateur. Malheureusement, chaque navigateur a une notion plus ou moins personnelle de l'interprétation de JavaScript et c'est un véritable casse-tête pour le concepteur que d'écrire des scripts qui fonctionnent sur la totalité des navigateurs existants, même si un effort de standardisation a été entrepris sur les dernières versions (Internet Explorer 6 et plus, Mozilla… Mais il en existe beaucoup d'autres). - Les VBScripts.
C'est la même philosophie que pour le JavaScript, à part que c'est du Visual Basic, propriété de Microsoft, qui ne fonctionne donc que sur Internet Explorer. Si la solution peut paraitre intéressante sur un Intranet, où l'on maitrise l'installation des postes clients, elle est bien entendu à proscrire sur l'Internet. - Les composants ActiveX qui sont des exécutables compilés, qui ne peuvent s'exécuter eux aussi que dans Internet Explorer, c'est également une technologie propriétaire de Microsoft. Très intéressante sur le principe, elle n'est en pratique utilisable de façon acceptable que sur un intranet.
- Les applets Java qui sont comparables aux composants ActiveX, mais qui ont des chances de s'exécuter correctement sur tout navigateur, si une machine virtuelle Java est installée. Ces deux technologies présentent malheureusement de gros risques de sécurité.
- Les « plug-in »
Ce sont des composants enfichables qui étendent les possibilités intrinsèques des navigateurs, comme l'affichage de documents « flash » par exemple.
Les avantages sont de deux sortes :
- tout traitement de données réalisé localement est rapide et sans surcharge pour le serveur ;
- les effets d'animation, comme les menus déroulants ou les bandeaux défilants ne peuvent être que réalisés localement.
Les inconvénients viennent des incompatibilités entre navigateurs et des trous de sécurité introduits par des exécutables téléchargés sur le client, issus d'origines qui peuvent être malveillantes.
Il n'est pas forcément aisé pour un surfeur de faire précisément la part des choses dans tous ces mécanismes qui peuvent se combiner avec plus ou moins de complexité (et de bonheur) au fil des sites visités.
Pour vous aider à mieux vous y retrouver, des exemples simples sont donnés plus loin.
2-2. Quelques notions supplémentaires▲
2-2-1. Le codage MIME▲
(Multipurpose Internet Mail Extension. Format de messages de l'Internet permettant de découper un message en plusieurs parties et d'y inclure des données non ASCII, à savoir du son, des images…).
Définition empruntée au « Jargon français ».
HTTP, un peu comme SMTP, ne sait pas nativement transporter autre chose que du texte. Il est bien connu de tous que le web propose aussi autre chose, comme des images (jpg, gif, png…), des animations et des documents aux formats plus ou moins particuliers (pdf, mpg, doc, xls, odt, ods…). Client et serveur doivent se mettre d'accord sur un moyen de coder ces informations (serveur) et de les décoder (client) pour les afficher quand c'est possible, ou en proposer le téléchargement. Dans tous les cas, ces données non textuelles doivent être codées et décodées de façon cohérente.
2-2-2. Les cookies▲
Les cookies ne sont pas une mauvaise invention, c'est leur utilisation qui est parfois détournée à des fins contestables.
Contrairement à ce que l'on peut penser, il n'existe pas de mémoire dans la navigation web. Plus exactement, la notion de « session » n'existe pas (mais ça vient). Pour bien comprendre, prenons un exemple simple : vous entrez sur un site privé qui nécessite une authentification (nom d'utilisateur et mot de passe), a priori, sans l'aide des cookies, vous seriez probablement amené à vous identifier à chaque nouvelle page. Aujourd'hui d'autres techniques que le cookie sont développées pour répondre à cette question. Il n'en demeure pas moins que le cookie montre encore son utilité dans bien des cas.
Le principe est simple : une fois authentifié, le serveur va déposer chez vous un « cookie » contenant des informations qu'il peut ensuite aller relire à chaque ouverture d'une nouvelle page, pendant toute la durée de vie de ce cookie.
Normalement, il n'y a que le serveur qui a déposé un cookie qui peut aller le relire (éventuellement un autre serveur du même domaine). Malheureusement, certains ont trouvé des moyens pour extorquer aux clients des cookies dont ils ne sont pas à l'origine, ce qui constitue un risque de sécurité, suivant les informations stockées dans ce cookie.
2-2-3. Le passage par un proxy▲
Nous allons profiter de l'occasion pour tordre le cou à une confusion trop souvent répandue entre deux méthodes qui permettent toutes deux l'accès au Net pour un réseau local.
- Le routeur NAT d'un côté.
Le routeur NAT agit au niveau IP. Il fonctionne pour tous les protocoles applicatifs comme HTTP, FTP, mais aussi POP, IMAP, SMTP, etc. (voir les chapitres dédiés : Partage de connexion et NetFilter et IPtables), puisqu'il agit au niveau IP. - Le proxy de l'autre.
Le serveur proxy travaille, lui, au niveau du protocole applicatif lui-même. Un serveur proxy n'assure aucun routage au niveau IP. En français, on appelle ça un serveur mandataire.
Pour l'exemple nous mettrons en œuvre un serveur proxy libre sous Linux : le très célèbre SQUID dans le chapitre qui lui est dédié : Squid et SquidGuard.
3. Le protocole HTTP▲
3-1. Les versions du protocole▲
Les versions les plus utilisées actuellement sont les versions 1.0 et 1.1, l'évolution suivante étant le XHTML qui apporte avant tout un peu plus de rigueur dans la syntaxe et un peu plus de cohérence avec le XML, mais le principe reste exactement le même.
La version 1.1 de HTML introduit quelques commandes supplémentaires, comme nous le verrons plus bas. La version 1.0 reste toutefois utilisable dans la plupart des cas actuellement.
3-1-1. Remarque préliminaire ▲
Une page est en principe définie par un URI (Unified Ressource Identifier). On dit aussi URL (Unified Ressource Locator). Par exemple : http://www.debian.org/doc/manuals/reference/ch-preface.fr.html. Nous savons que dans cet URI, il y a trois morceaux :
- http:
qui indique quel protocole nous allons employer ; - //www.debian.org
qui est censé représenter le serveur web contenant l'information que l'on recherche ; - /doc/manuals/reference/ch-preface.fr.html
qui représente le chemin complet de la page visitée dans l'arborescence du serveur concerné.
Pourtant, si nous indiquons comme URI http://www.debian.org , il manque toute la partie correspondant au nom de la page. Cependant, nous arrivons bien à visualiser quelque chose… Tout simplement, parce que le serveur est paramétré pour ajouter /index.html s'il n'y a pas le nom de la page. Ainsi, http://www.debian.org est équivalent à http://www.debian.org/index.html.
3-2. La démonstration▲
Nous allons voir tout ceci à travers quelques manipulations très simples.
Pour réaliser cette démonstration, un serveur web Apache est installé sur mon réseau privé. L'hôte s'appelle poétiquement : linux.maison.mrs
Il contient une unique page HTML nommée index.html. C'est la page qui est servie par défaut (les manipulations datent de 2002, sur un apache 1.3 et une distribution d'époque (Mandrake), mais ici, le temps ne fait rien à l'affaire).
3-2-1. 1° On fait comme tout le monde…▲
Commençons par faire ce que tout le monde fait : utiliser son navigateur favori pour visiter cette page. Voici l'allure de cette très belle page, telle qu'on l'obtient avec Internet Explorer :
À titre indicatif, en voici le code HTML, tel qu'on peut l'obtenir en affichant le source depuis le navigateur :
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv= "Content-Type" content= "text/html; charset=iso-8859-1">
</head>
<body bgcolor= »#FFFFFF » text= »#000000 »>
<p>Hello world.</p>
<p><img src="images/tux.gif" width= "97" height= "115"></p>
</body>
</html>Les puristes constateront que ce code n'est plus du tout conforme aux recommandations du W3C, mais la philosophie reste inchangée.
3-2-2. 2° On fait avec Telnet…▲
Essayons d'aller plus loin en trouvant un moyen de faire « à la main » ce que le navigateur fait automatiquement.
Nous sommes sur un protocole applicatif basé sur TCP et, dans ce cas-là, il est généralement possible d'utiliser Telnet pour étudier un peu les commandes…
3-2-2-1. La commande GET▲
Nous ouvrons une session Telnet sur le serveur HTTP de linux.maison.mrs (un serveur web écoute par convention sur le port 80).
telnet linux.maison.mrs 80
Trying 192.168.0.253...
Connected to linux.maison.mrs (192.168.0.253)
Escape character is '^]'.La session est ouverte. Utilisons maintenant la commande GET…
GET / HTTP/1.0Nous la faisons en protocole 1.0, c'est un peu plus simple. Deux « return » pour valider… Et voici qu'arrive la réponse du serveur. Cette partie constitue l'en-tête, systématiquement envoyée par le serveur :
HTTP/1.1 200 OK
Date: Wed, 08 May 2002 14:26:57 GMT
Server: Apache-AdvancedExtranetServer/1.3.23
(Mandrake Linux/4mdk) auth_ldap/1.6.0 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
Last-Modified: Sun, 14 Apr 2002 09:29:32 GMT
ETag: "57d44-116-3cb94bfc"
Accept-Ranges: bytes
Content-Length: 278
Connection: close
Content-Type: text/htmlLe serveur sait faire du HTTP 1.1. C'est un Apache version 1.3.23. Il annonce également ce qu'il sait faire :
- authentification par annuaire LDAP ;
- Secure Socket Layer en OpenSSL version 0.9.6c ;
- interprétation de code PHP version 4.1.2.
Il indique également La date GMT de dernière modification du document demandé, qu'il mettra fin à la connexion TCP à la fin de l'envoi, et que le document fourni est au format MIME : text/html.
Et voici le document proprement dit :
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv= "Content-Type" content= "text/html; charset=iso-8859-1">
</head>
<body bgcolor= »#FFFFFF » text= »#000000 »>
<p>Hello world.</p>
<p><img src="images/tux.gif" width= "97" height= "115"></p>
</body>
</html>Le message Connection closed by foreign host., issu de Telnet, indique que, par défaut, la connexion est interrompue par le serveur à la fin de l'envoi du document. L'option Connection: Keep-Alive aurait évité cette déconnexion. Entendons-nous bien sur ce point : Nous parlons de la connexion TCP et en aucune façon d'une « session » au niveau de l'application.
Bien ! Mais l'image ? Essayons de l'avoir…
telnet linux.maison.mrs 80
Trying 192.168.0.253...
Connected to linux.maison.mrs (192.168.0.253).
Escape character is '^]'.
GET /images/tux.gif HTTP/1.0
Trying 192.168.0.253...
Connected to linux.maison.mrs (192.168.0.253).
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Wed, 08 May 2002 14:44:17 GMT
Server: Apache-AdvancedExtranetServer/1.3.23
(Mandrake Linux/4mdk) auth_ldap/1.6.0 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2
Last-Modified: Sun, 14 Apr 2002 09:29:32 GMT
ETag: « cf98a-a20-3cb94bfc »
Accept-Ranges: bytes
Content-Length: 2592
Connection: close
Content-Type: image/gif
GIF89aasæ????…/IHG£HIíÈ?Å?2›i?º…??gp©:<…f?×¥?ÄHL§v?‹ˆèèü?ˆ”©?°››¡»¹ÅØ ?ÉÈ×rI?
(''}y|]?Ë8:µ}?–y}ÁX_À•!?‰ hnÎ??N4?è×?XXZò»?W????98;ýýûhgjºx‚¹™?ôÖ?«Y^„ZXbE?
©¶ÙÙëà³L„hhÓ™?…NE?4ÜÌÀ•XYªy‚U<?ÇŒ?ã©??˜...
...
Connection closed by foreign host.Là, il ne fallait tout de même pas s'attendre à des miracles, avec une console en mode texte. On a bien reçu l'image, le type MIME (image/gif) est bien signalé, mais il n'est pas possible de la visualiser avec Telnet.
3-2-3. 3° On espionne avec le sniffeur…▲
3-2-3-1. Comment travaille le navigateur ?▲
Il a fait exactement la même chose que nous :
- il appelle la page d'accueil GET / HTTP/1.0 (éventuellement HTTP/1.1, mais alors, suivant la définition de cette version HTTP, il devra au moins envoyer aussi le nom d'hôte du serveur interrogé) ;
- une fois la page reçue, il va chercher dedans tous les URI, ici celui de l'image, et va les appeler avec un GET. Dans le cas de l'image, il devra la recomposer, ce qui lui est possible parce qu'il connaît le format d'encodage gif ;
- il affiche alors la page, dans son intégralité.
3-2-3-2. Première observation de la conversation▲
Nous appelons la page avec Internet Explorer et le sniffeur va enregistrer ce qu'il se passe. Les trames surlignées sont celles qui sont propres à HTTP. Mais n'oublions pas que HTTP s'appuie sur TCP, raison pour laquelle les autres trames existent :
No. Time Source Destination Proto Info
1 0.000000 192.168.0.10 192.168.0.253 TCP 1282 > 80 [SYN]
2 0.000163 192.168.0.253 192.168.0.10 TCP 80 > 1282 [SYN, ACK]
3 0.000565 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]
4 0.001410 192.168.0.10 192.168.0.253 HTTP GET / HTTP/1.1
5 0.001487 192.168.0.253 192.168.0.10 TCP 80 > 1282 [ACK]
6 0.068550 192.168.0.253 192.168.0.10 HTTP HTTP/1.1 200 OK
7 0.098435 192.168.0.10 192.168.0.253 HTTP GET /images/tux.gif HTTP/1.1
8 0.098593 192.168.0.253 192.168.0.10 TCP 80 > 1282 [ACK]
9 0.099450 192.168.0.253 192.168.0.10 HTTP HTTP/1.1 200 OK
10 0.099724 192.168.0.253 192.168.0.10 HTTP Continuation
11 0.102794 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]
12 0.102915 192.168.0.253 192.168.0.10 HTTP Continuation
13 0.280331 192.168.0.10 192.168.0.253 TCP 1282 > 80 [ACK]- La trame 4 représente la première requête du client.
- La trame 6 renvoie le document demandé, c'est-à-dire la page d'accueil du site.
- La trame 7 indique une requête supplémentaire pour l'image.
- Les trames 9, 10 et 12 représentent l'envoi par le serveur de l'image demandée. Les données sont trop volumineuses pour entrer dans une seule trame. Ici, il en faut trois.
3-2-3-3. La première requête HTTP▲
Pour cette première analyse, je laisse volontairement la totalité de la trame, afin de bien montrer que HTTP est un protocole « application », qui s'appuie sur TCP/IP, lui-même s'appuyant sur Ethernet dans cet exemple. Avec une connexion PPPoE, on aurait une couche supplémentaire introduite par PPP
Frame 4 (380 on wire, 380 captured)
Arrival Time: Apr 13, 2002 16:07:10.266248000
Time delta from previous packet: 0.000861000 seconds
Time relative to first packet: 0.001408000 seconds
Frame Number: 4
Packet Length: 380 bytes
Capture Length: 380 bytes
Ethernet II
Destination: 00:00:b4:bb:5d:ee (00:00:b4:bb:5d:ee)
Source: 00:20:18:b9:49:37 (00:20:18:b9:49:37)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.0.10, Dst Addr: 192.168.0.253
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 366
Identification: 0xc99c
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xad95 (correct)
Source: 192.168.0.10 (192.168.0.10)
Destination: 192.168.0.253 (192.168.0.253)
Transmission Control Protocol, Src Port: 2752, Dst Port: 80
Source port: 2752 (2752)
Destination port: 80 (80)
Sequence number: 1135843004
Next sequence number: 1135843330
Acknowledgement number: 2485285689
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 17520
Checksum: 0x6ec7 (correct)
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n La version du protocole HTTP utilisé.
Suivent les informations supplémentaires qu'envoie le client au serveur...
Accept: image/gif, Les images gif...
image/x-xbitmap, Les images bitmap (bmp par exemple)
image/jpeg, Les images jpeg...
image/pjpeg,
application/vnd.ms-powerpoint, Les trois lignes qui suivent
application/vnd.ms-excel, Représentent des informations dont l'intérêt
application/msword, peut paraitre contestable...
*/*\r\n
Accept-Language: fr\r\n Nous parlons français...
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n
Host: linux.maison.mrs\r\n Celle-ci est indispensable au protocole v1.1
Connection: Keep-Alive\r\n Notez qu'IE demande à garder la connexion
\r\nSi IE se permet d'annoncer au monde entier que les composants principaux de MS Office sont présents sur ma machine, ce n'est pas dans le but de « moucharder ». Si vous désirez télécharger des documents .doc, .xls ou .ppt, ces documents devront être transférés par le serveur au format MIME, comme une image gif ou jpg. Internet Explorer informe qu'il accepte ce type de documents. Dans la pratique, tous les navigateurs les acceptent, mais vous proposeront seulement de les enregistrer en tant que fichiers. Ici, IE indique qu'il est capable de les afficher lui-même.
3-2-3-4. La page d'accueil arrive▲
Frame 6 (710 on wire, 710 captured)
...
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Date: Sun, 14 Apr 2002 09:30:12 GMT\r\n
Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4mdk)
auth_ldap/1.6.0
mod_ssl/2.8.7
OpenSSL/0.9.6c
PHP/4.1.2\r\n
Last-Modified: Sun, 14 Apr 2002 09:29:32 GMT\r\n
ETag: « 57d44-116-3cb94bfc »\r\n
Accept-Ranges: bytes\r\n
Content-Length: 278\r\n
Keep-Alive: timeout=15, max=100\r\n
Connection: Keep-Alive\r\n
** Content-Type: text/html\r\n
** \r\n
Data (278 bytes)
0000 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 61 64 3e 0d 0a <html>..<head>..
0010 3c 74 69 74 6c 65 3e 55 6e 74 69 74 6c 65 64 20 <title>Untitled
0020 44 6f 63 75 6d 65 6e 74 3c 2f 74 69 74 6c 65 3e Document</title>
0030 0d 0a 3c 6d 65 74 61 20 68 74 74 70 2d 65 71 75 ..<meta http-equ
0040 69 76 3d 22 43 6f 6e 74 65 6e 74 2d 54 79 70 65 iv="Content-Type
0050 22 20 63 6f 6e 74 65 6e 74 3d 22 74 65 78 74 2f "content="text/
0060 68 74 6d 6c 3b 20 63 68 61 72 73 65 74 3d 69 73 html; charset=is
0070 6f 2d 38 38 35 39 2d 31 22 3e 0d 0a 3c 2f 68 65 o-8859-1">..</he
0080 61 64 3e 0d 0a 0d 0a 3c 62 6f 64 79 20 62 67 63 ad>....<body bgc
0090 6f 6c 6f 72 3d 22 23 46 46 46 46 46 46 22 20 74 olor="#FFFFFF" t
00a0 65 78 74 3d 22 23 30 30 30 30 30 30 22 3e 0d 0a ext="#000000">..
00b0 3c 70 3e 48 65 6c 6c 6f 20 77 6f 72 6c 64 2e 0d <p>Hello world..
00c0 0a 3c 2f 70 3e 0d 0a 3c 70 3e 3c 69 6d 67 20 73 .</p>..<p><img s
00d0 72 63 3d 22 69 6d 61 67 65 73 2f 74 75 78 2e 67 rc="images/tux.g
00e0 69 66 22 20 77 69 64 74 68 3d 22 39 37 22 20 68 if" width="97" h
00f0 65 69 67 68 74 3d 22 31 31 35 22 3e 0d 0a 3c 2f eight="115">..</
0100 70 3e 0d 0a 3c 2f 62 6f 64 79 3e 0d 0a 3c 2f 68 p>..</body>..</h
0110 74 6d 6c 3e 0d 0a tml>..C'est au navigateur de se débrouiller pour aller chercher les données de cette image, à partir des références fournies. Tous ceux qui pratiquent le HTML le savent bien…
Ceci justifie la présence de la requête de la trame 7 :
Frame 7 (298 on wire, 298 captured)
...
Hypertext Transfer Protocol
GET /images/tux.gif HTTP/1.1\r\n Appel d'une référence relative
Accept: */*\r\n
Referer: http://linux.maison.mrs\r\n Depuis la page indiquée, ce qui aboutit
à la référence absolue:
http://linux.maison.mrs/images/tux.gif
Accept-Language: fr\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n
Host: linux.maison.mrs\r\n
Connection: Keep-Alive\r\n
\r\nLe serveur envoie les données à partir de la trame 9 :
Frame 9 (1514 on wire, 1514 captured)
....
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Date: Sun, 14 Apr 2002 09:30:12 GMT\r\n
Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4mdk)
auth_ldap/1.6.0
mod_ssl/2.8.7
OpenSSL/0.9.6c
PHP/4.1.2\r\n
Last-Modified: Sun, 14 Apr 2002 09:29:32 GMT\r\n
ETag: « cf98a-a20-3cb94bfc »\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2592\r\n
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: image/gif\r\n
\r\n
Data (1082 bytes)
0000 47 49 46 38 39 61 61 00 73 00 e6 00 00 04 04 05 GIF89aa.s.......
0010 a4 85 2f 49 48 47 a3 48 49 ed c8 10 c5 a4 32 9b ../IHG.HI.....2.
0020 69 07 ba 85 0e be 67 70 a9 3a 3c 85 66 1d d7 a5 i.....gp.:<.f...
0030 15 c4 48 4c a7 76 0c 8b 88 8d e8 e8 fc b8 88 94 ..HL.v..........
...3-2-3-5. Conclusions▲
Nous avons vu quelques choses intéressantes :
- le navigateur, en gros, fait ce que nous avons fait avec Telnet, à quelques détails près :
- il envoie un certain nombre d'informations que nous n'avons pas envoyées avec notre Telnet. Parmi celles-ci, Host: linux.maison.mrs, c'est-à-dire le nom du serveur, qui est le seul paramètre obligatoire pour HTTP 1.1, facultatif en HTTP 1.0,
- il se débrouille tout seul pour appeler tous les documents nécessaires à l'affichage correct de cette page (ici l'image de Tux), et reconstitue correctement cette image pour l'afficher.
3-3. Le coup du cache…▲
Puisque nous y sommes, profitons-en pour observer un comportement intéressant du navigateur : la mise en cache des pages consultées.
L'internaute ferme son navigateur. Quelques instants plus tard, il l'ouvre à nouveau et réclame la même page. Que va-t-il se passer ?
No. Time Source Destination Proto Info
1 0.000000 192.168.0.10 192.168.0.253 TCP 2632 > 80 [SYN]
2 0.000144 192.168.0.253 192.168.0.10 TCP 80 > 2632 [SYN, ACK]
3 0.000540 192.168.0.10 192.168.0.253 TCP 2632 > 80 [ACK]
4 0.001342 192.168.0.10 192.168.0.253 HTTP GET / HTTP/1.1
5 0.001461 192.168.0.253 192.168.0.10 TCP 80 > 2632 [ACK]
6 0.004186 192.168.0.253 192.168.0.10 HTTP HTTP/1.1 304 Not Modified
7 0.200392 192.168.0.10 192.168.0.253 TCP 2632 > 80 [ACK]La réponse n'est pas la même que dans le cas précédent. Voyons ceci de plus près…
3-3-1. La requête▲
Frame 4 (336 on wire, 336 captured)
...
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
Accept: */*\r\n
Accept-Language: fr\r\n
Accept-Encoding: gzip, deflate\r\n
If-Modified-Since: Sat, 13 Apr 2002 13:40:06 GMT\r\n Cette ligne n'apparaissait pas dans la requête précédente...
If-None-Match: "57d44-d2-3cb83536"\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n
Host: linux.maison.mrs\r\n
Connection: Keep-Alive\r\n
\r\nInternet Exlorer demande au serveur la page, si elle a été modifiée depuis la date de son précédent chargement, tout simplement parce qu'il a conservé en cache cette page que nous avons déjà demandée il n'y a pas si longtemps.
3-3-2. La réponse▲
Frame 6 (327 on wire, 327 captured)
...
Hypertext Transfer Protocol
HTTP/1.1 304 Not Modified\r\n
Date: Sat, 13 Apr 2002 13:53:52 GMT\r\n
Server: Apache-AdvancedExtranetServer/1.3.23 (Mandrake Linux/4mdk)
auth_ldap/1.6.0 mod_ssl/2.8.7 OpenSSL/0.9.6c PHP/4.1.2\r\n
Connection: Keep-Alive\r\n
Keep-Alive: timeout=15, max=100\r\n
ETag: "57d44-d2-3cb83536"\r\n
\r\nLe serveur s'est contenté de répondre que la page n'a pas été modifiée…
Le navigateur va donc réafficher la page qu'il a conservée en cache. Cette méthode de travail présente deux particularités :
- le temps d'affichage est considérablement raccourci lorsque l'on navigue dans un site, puisque les pages déjà chargées ne le sont généralement plus si l'on revient dessus ;
- l'espace requis pour le cache gonfle considérablement et peut occuper jusqu'à plusieurs dizaines de Mo sur votre disque…
Méfiez-vous des effets de bord du cache local ! Il existe de nombreux cas où le contrôle sur la modification n'est pas efficace. Votre navigateur affichera alors une version obsolète de la page. Ceci est surtout gênant pour les développeurs de sites.
Un procédé analogue est également employé par les serveurs proxy.
3-4. Toutes les commandes de HTTP 1.0▲
La compréhension de la navigation ne nécessite pas la connaissance de toutes les commandes, loin de là. Aussi, nous ne les verrons pas en détail.
- La commande HEAD. Cette commande, qui existe également en v1.0, permet de ne demander au serveur que l'en-tête, sans le document.
- La commande GET. Nous l'avons déjà vue, ce n'est pas la peine d'y revenir, si ce n'est pour rappeler que l'option « Host: » doit impérativement figurer dans la commande, pour être acceptée par le serveur en version 1.1, mais pas en version 1.0.
- La commande POST. C'est la commande qui permet d'envoyer des données au serveur, généralement par l'intermédiaire d'un formulaire.
3-5. Et HTTP 1.1 ?▲
Il propose quelques commandes supplémentaires, comme :
- OPTIONS qui permet d'interroger le serveur sur les options disponibles ;
- TRACE qui est en quelque sorte une commande de débogage ;
- DELETE qui permet de détruire un fichier sur le serveur (généralement désactivée, vous vous en doutez…) ;
- PUT qui permet d'écrire des fichiers sur le serveur, généralement désactivée également.
Ces deux dernières commandes sont introduites pour permettre une mise à jour des sites distants via HTTP.
4. Les pages « actives »▲
Nous allons maintenant jouer un peu avec quelques possibilités qui font parfois peur…
4-1. Vous divulguez plus d'informations que vous ne croyez…▲
Voici un exemple simple de ce qu'un serveur HTTP reçoit de votre part comme informations « cachées » et qu'il est donc capable d'exploiter, comme ici par exemple juste pour vous les afficher :
| Votre Adresse IP (publique) | 3.144.9.152 |
|---|---|
| Le nom de votre machine telle qu'elle est connue sur le Net | ec2-3-144-9-152.us-east-2.compute.amazonaws.com |
| La façon dont vous vous présentez en tant que client HTTP | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) |
| La version de protocole HTTP utilisée | HTTP/1.1 |
| Les types MIME | */* |
| Le document qui vous a conduit jusqu'ici | http://caleca.developpez.com/tutoriels/navigation-web-protocole-http/ |
4-1-1. Miracle ?▲
Pas le moins du monde. Cette page est dynamique. Les informations qu'elle contient sont construites à la volée par le serveur, avant de vous l'envoyer. La technologie utilisée est ici PHP. Les informations affichées ci-dessus sont obtenues à partir des variables d'environnement que votre navigateur envoie à chaque commande GET.
PHP n'est qu'un moyen de construire une page HTML dynamique qui vous renvoie ces informations, ça aurait aussi pu être fait avec un script CGI (dans les limites de ce que permet l'hébergeur).
Si vous regardez le « source » de cette page, vous n'y trouverez que du HTML.
4-2. Les formulaires…▲
Les formulaires ont pour but de permettre au client d'envoyer des données au serveur. À charge pour lui de les traiter correctement. Leur emploi va du simple « log in » à la composition de documents très sophistiqués, et hélas aussi parfois, à l'envoi d'informations qui ont été récupérées sur votre système à votre insu.
Un formulaire peut envoyer ses données de deux manières.
4-2-1. Par la méthode « GET »▲
Avec cette méthode, les données sont envoyées dans l'URI de la page qui sera appelée lorsque vous cliquerez sur « envoyer ».
Dans le formulaire ci-dessous :
- le champ de saisie de texte s'appelle « saisie1 » ;
- Le bouton s'appelle « B1 ».
4-2-2. Par la méthode « POST »▲
À première vue, les données sont envoyées de façon « invisible ».
Dans le formulaire ci-dessus :
- le champ de saisie de texte s'appelle « saisie2 » ;
- le bouton s'appelle « B2 ».
4-2-3. Le délicat cas des « cookies »▲
Un cookie, c'est un petit fichier qu'un serveur HTTP peut écrire (et lire) sur votre machine par l'intermédiaire de votre navigateur. L'objectif initial n'est en rien malicieux et peut même vous rendre service. Nous l'avons déjà vu, HTTP ne gère pas le concept de session. Une session, c'est une période pendant laquelle un certain contexte reste constant, même si vous y faites des choses différentes. Par exemple, vous entrez dans un lieu protégé par une porte fermant à clé. Vous ouvrez cette porte au moyen de la clé. Une fois rentré dans ce lieu, vous pouvez y faire tout ce qui est autorisé et vous n'aurez plus besoin de la clé, jusqu'à ce que vous soyez sorti.
HTTP ne sait pas faire cela et ne conserve aucune mémoire du passé si ce n'est l'URI de la page d'où vous venez. C'est un peu faible, surtout si l'on doit gérer des identifications de personnes, par exemple. Dans ces cas-là, un cookie permettra de contourner le problème en permettant au serveur de retrouver à chaque page des informations écrites dans ce cookie.
4-2-3-1. Un exemple trivial▲
Le formulaire suivant vous permet de saisir une information dans un formulaire et de l'envoyer avec la méthode POST (ça aurait été pareil avec la méthode GET, d'ailleurs).
La différence par rapport aux exemples précédents, c'est que la page qui va être appelée à l'envoi des données de ce formulaire va écrire un cookie contenant cette donnée sur votre machine (sauf si vous avez interdit à votre navigateur d'accepter les cookies).
4-2-3-2. Explications▲
Comme vous en avez l'habitude, cette trace correspond à un exemple exécuté sur mon installation et non à la manipulation que vous êtes en train de faire…
Ce n'est pas la méthode POST employée dans le formulaire qui va écrire le cookie dans la mémoire de votre navigateur, mais bien la page que ce formulaire invoque, form_cookie1.php dans notre cas.
4-2-3-2-1. Commençons par un aperçu sommaire▲
No. Time Source Destination Proto Info
La page des exemples est appelée...
8 0.443083 192.168.0.10 192.168.0.251 HTTP GET /http/exemple1.php HTTP/1.1
9 0.443425 192.168.0.251 192.168.0.10 TCP 80 > 2349 [ACK]
Elle rentre...
10 0.470220 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
11 0.471471 192.168.0.251 192.168.0.10 HTTP Continuation
12 0.471874 192.168.0.10 192.168.0.251 TCP 2349 > 80 [ACK]
13 0.473661 192.168.0.251 192.168.0.10 HTTP Continuation
14 0.474914 192.168.0.251 192.168.0.10 HTTP Continuation
15 0.474943 192.168.0.10 192.168.0.251 TCP 2349 > 80 [ACK]
16 0.476205 192.168.0.251 192.168.0.10 HTTP Continuation
17 0.476246 192.168.0.251 192.168.0.10 HTTP Continuation
18 0.476730 192.168.0.10 192.168.0.251 TCP 2349 > 80 [ACK]
Le formulaire avec la valeur du cookie est envoyé...
19 8.621094 192.168.0.10 192.168.0.251 HTTP POST /http/post_cookie1.php HTTP/1.1
La première page de réponse est envoyée par le serveur (c'est elle qui écrit le cookie).
20 8.642651 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
21 8.750822 192.168.0.10 192.168.0.251 TCP 2349 > 80 [ACK]
La page de vérification du cookie est demandée par un GET "normal"...
22 11.101585 192.168.0.10 192.168.0.251 HTTP GET /http/post_cookie2.php HTTP/1.1
Elle est envoyée par le serveur.
23 11.122099 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
24 11.258788 192.168.0.10 192.168.0.251 TCP 2349 > 80 [ACK]4-2-3-2-2. Plus en détail…▲
- La trame 8 ne présente pas d'intérêt particulier, elle représente l'appel de la page d'exemples « exemple1.php ».
- Les trames 10 à 17 représentent quant à elles l'arrivée de cette page. Elle est longue et nécessite plusieurs trames.
- La trame 19 commence à nous intéresser. Elle correspond à l'envoi du formulaire relatif aux cookies :
Frame 19 (439 on wire, 439 captured)
...
Hypertext Transfer Protocol
POST /http/post_cookie1.php HTTP/1.1\r\n
Accept: */*\r\n
Referer: http://gw2.maison.mrs/http/exemple1.php\r\n
Accept-Language: fr\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n
Host: gw2.maison.mrs\r\n
Content-Length: 25\r\n
Connection: Keep-Alive\r\n
Cache-Control: no-cache\r\n
\r\n
Data (25 bytes)
0000 73 61 69 73 69 65 33 3d 63 6f 6f 6b 69 65 26 42 saisie3=cookie&B
0010 33 3d 45 6e 76 6f 79 65 72 3=Envoyer- La trame 20 est intéressante parce qu'elle met en évidence l'envoi du cookie du serveur au client :
Frame 20 (1473 on wire, 1473 captured)
...
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Date: Sun, 21 Apr 2002 13:11:11 GMT\r\n
Server: Apache-AdvancedExtranetServer/1.3.22
(Mandrake Linux/1.1mdk) PHP/4.0.6 mod_ssl/2.8.5 OpenSSL/0.9.6b\r\n
X-Powered-By: PHP/4.0.6\r\n
Set-Cookie: VotreCookie=cookie; expires=Sun, 21-Apr-02 13:13:11 GMT\r\n
Le cookie a un identificateur : VotreCookie et une valeur : cookie
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
Data (1051 bytes)
Vient ensuite le document lui-même...
0000 34 30 66 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 40f..<html>....<
0010 68 65 61 64 3e 0d 0a 3c 6d 65 74 61 20 68 74 74 head>..<meta htt
...- La trame 22 montre comment votre navigateur renvoie docilement votre cookie au serveur à chaque requête qu'il effectuera sur ce serveur.
Rappelons que la page « post_cookie1.php » ne présente aucun formulaire, aucun champ de saisie ni rien qui puisse vous laisser penser que la prochaine requête va transmettre des informations au serveur.
Frame 22 (481 on wire, 481 captured)
...
Hypertext Transfer Protocol
GET /http/post_cookie2.php HTTP/1.1\r\n
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*\r\n
Referer: http://gw2.maison.mrs/http/post_cookie1.php\r\n
Accept-Language: fr\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n
Host: gw2.maison.mrs\r\n
Connection: Keep-Alive\r\n
Cookie: VotreCookie=cookie\r\n
Voilà votre cookie qui est envoyé à votre insu.
\r\n- La trame 23 présente un intérêt tout de même, parce qu'elle montre que le cookie n'apparait pas directement.
Entendez par là que le serveur ayant reçu ce cookie va en faire ce qu'il veut. Ici, il se contente d'en afficher le contenu dans la page. C'est une page active, construite par PHP. Rappelez-vous que votre navigateur, dans ce cas, reçoit du HTML tout ce qu'il y a de plus « passif ». Pas de script si l'auteur n'en a pas décidé autrement.
Tout navigateur capable d'afficher du HTML affichera correctement cette page, même s'il ne sait absolument pas traiter les scripts.
Frame 23 (1127 on wire, 1127 captured)
...
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Date: Sun, 21 Apr 2002 13:11:14 GMT\r\n
Server: Apache-AdvancedExtranetServer/1.3.22 (Mandrake Linux/1.1mdk) PHP/4.0.6 mod_ssl/2.8.5 OpenSSL/0.9.6b\r\n
X-Powered-By: PHP/4.0.6\r\n
Keep-Alive: timeout=15, max=98\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n
Data (774 bytes)
0000 32 66 61 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 2fa..<html>....<
0010 68 65 61 64 3e 0d 0a 3c 6d 65 74 61 20 68 74 74 head>..<meta htt
0020 70 2d 65 71 75 69 76 3d 22 43 6f 6e 74 65 6e 74 p-equiv="Content
0030 2d 4c 61 6e 67 75 61 67 65 22 20 63 6f 6e 74 65 -Language" conte
0040 6e 74 3d 22 66 72 22 3e 0d 0a 3c 6d 65 74 61 20 nt="fr">..<meta
0050 68 74 74 70 2d 65 71 75 69 76 3d 22 43 6f 6e 74 http-equiv="Cont
0060 65 6e 74 2d 54 79 70 65 22 20 63 6f 6e 74 65 6e ent-Type" conten
0070 74 3d 22 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 t="text/html; ch
0080 61 72 73 65 74 3d 77 69 6e 64 6f 77 73 2d 31 32 arset=windows-12
0090 35 32 22 3e 0d 0a 3c 6d 65 74 61 20 6e 61 6d 65 52">..<meta name
00a0 3d 22 47 45 4e 45 52 41 54 4f 52 22 20 63 6f 6e ="GENERATOR" con
00b0 74 65 6e 74 3d 22 4d 69 63 72 6f 73 6f 66 74 20 tent="Microsoft
00c0 46 72 6f 6e 74 50 61 67 65 20 34 2e 30 22 3e 0d FrontPage 4.0">.
00d0 0a 3c 6d 65 74 61 20 6e 61 6d 65 3d 22 50 72 6f .<meta name="Pro
00e0 67 49 64 22 20 63 6f 6e 74 65 6e 74 3d 22 46 72 gId" content="Fr
00f0 6f 6e 74 50 61 67 65 2e 45 64 69 74 6f 72 2e 44 ontPage.Editor.D
0100 6f 63 75 6d 65 6e 74 22 3e 0d 0a 3c 74 69 74 6c ocument">..<titl
0110 65 3e 52 e9 73 75 6c 74 61 74 20 64 65 20 6c 61 e>R.sultat de la
0120 20 6d 61 6e 69 70 3c 2f 74 69 74 6c 65 3e 0d 0a manip</title>..
0130 3c 21 2d 2d 6d 73 74 68 65 6d 65 2d 2d 3e 3c 6c <!--mstheme--><l
0140 69 6e 6b 20 72 65 6c 3d 22 73 74 79 6c 65 73 68 ink rel="stylesh
0150 65 65 74 22 20 68 72 65 66 3d 22 66 69 6c 65 3a eet" href="file:
0160 2f 2f 2f 47 3a 2f 44 4f 43 55 4d 45 7e 31 2f 63 ///G:/DOCUME~1/c
0170 68 72 69 73 2f 4c 4f 43 41 4c 53 7e 31 2f 54 65 hris/LOCALS~1/Te
0180 6d 70 2f 46 72 6f 6e 74 50 61 67 65 54 65 6d 70 mp/FrontPageTemp
0190 44 69 72 2f 6d 73 74 68 65 6d 65 2f 74 61 62 73 Dir/mstheme/tabs
01a0 2f 74 61 62 73 31 31 31 31 2e 63 73 73 22 3e 0d /tabs1111.css">.
01b0 0a 3c 6d 65 74 61 20 6e 61 6d 65 3d 22 4d 69 63 .<meta name="Mic
01c0 72 6f 73 6f 66 74 20 54 68 65 6d 65 22 20 63 6f rosoft Theme" co
01d0 6e 74 65 6e 74 3d 22 74 61 62 73 20 31 31 31 31 ntent="tabs 1111
01e0 2c 20 64 65 66 61 75 6c 74 22 3e 0d 0a 3c 6d 65 , default">..<me
01f0 74 61 20 6e 61 6d 65 3d 22 4d 69 63 72 6f 73 6f ta name="Microso
0200 66 74 20 42 6f 72 64 65 72 22 20 63 6f 6e 74 65 ft Border" conte
0210 6e 74 3d 22 6e 6f 6e 65 22 3e 0d 0a 3c 2f 68 65 nt="none">..</he
0220 61 64 3e 0d 0a 0d 0a 3c 62 6f 64 79 3e 0d 0a 0d ad>....<body>...
0230 0a 3c 68 31 3e 52 e9 73 75 6c 74 61 74 20 64 65 .<h1>R.sultat de
0240 20 6c 61 20 6d 61 6e 69 70 3a 3c 2f 68 31 3e 0d la manip:</h1>.
0250 0a 3c 70 3e 0d 0a 56 6f 74 72 65 20 63 6f 6f 6b .<p>..Votre cook
0260 69 65 20 65 78 69 73 74 65 20 74 6f 75 6a 6f 75 ie existe toujou
0270 72 73 20 65 74 20 63 6f 6e 74 69 65 6e 74 20 6c rs et contient l
0280 61 20 76 61 6c 65 75 72 20 3a 20 3c 62 3e 3c 75 a valeur : <b><u
0290 3e 63 6f 6f 6b 69 65 3c 2f 75 3e 3c 2f 62 3e 0d >cookie</u></b>.
02a0 0a 3c 2f 70 3e 0d 0a 0d 0a 3c 68 32 3e 4d 61 69 .</p>....<h2>Mai
02b0 73 20 71 75 65 20 73 27 65 73 74 2d 69 6c 20 70 s que s'est-il p
02c0 61 73 73 e9 20 64 61 6e 73 20 74 6f 75 74 20 e7 ass. dans tout .
02d0 61 20 3f 3c 2f 68 32 3e 0d 0a 3c 70 3e 26 6e 62 a ?</h2>..<p>&nb
02e0 73 70 3b 3c 2f 70 3e 0d 0a 0d 0a 3c 2f 62 6f 64 sp;</p>....</bod
02f0 79 3e 0d 0a 0d 0a 3c 2f 68 74 6d 6c 3e 0d 0a 0d y>....</html>...
0300 0a 30 0d 0a 0d 0a .0....4-3. Conclusions▲
Nous avons vu quelques exemples de ce que l'on peut faire avec :
- un client qui envoie des données volontairement ou non, à un serveur ;
- un serveur qui exploite ces données au moyen de scripts, ici en PHP.
Nous n'avons pas vu ce que pourrait faire un script CGI, mais ce serait du même ordre. Toutes ces démonstrations sont donc axées sur du « server side ». Le client envoie les données et reçoit du HTML statique. C'est le serveur qui traite les données reçues et agit en fonction.
Dans tout ce que nous avons vu ici, le « dynamisme » des pages venait exclusivement du serveur, et le client se contente d'envoyer des requêtes et des données pour voir le contenu des pages se modifier. La page suivante va vous donner quelques exemples simples de JavaScript qui s'exécutent côté client, donc sur votre machine.
5. Scripts clients▲
Dans cette page, tout ce qu'il va se passer va se passer sur votre machine, il n'y aura aucun échange avec le serveur…
Comme c'est du JavaScript, malgré mes efforts pour tester sur divers navigateurs, il se peut que sur le vôtre, ces démonstrations soient un « flop »…
5-1. Les alertes▲
Il est possible de déclencher un « pop-up » d'alerte, ou de demande de confirmation, ou même encore de saisie d'un paramètre, par simple action sur une page. Voici un exemple d'alerte déclenchée par un bouton :
5-2. Ouvrir une fenêtre▲
Cet exemple ouvre une simple fenêtre au contenu statique. Il est possible d'ouvrir une fenêtre quelconque, bien sûr.
Voici l'exemple :
5-3. Faire des calculs▲
Ce dernier exemple ouvre une fenêtre contenant elle-même un script assez complet, qui permet de faire des calculs et d'en afficher le résultat de façon complètement locale, dans votre navigateur :
5-4. Conclusions▲
Bien entendu, il est possible de réaliser beaucoup de choses avec des scripts et cette page pourrait être bien plus longue.
J'espère que tout ceci vous aura permis de voir plus clairement :
- comment une page HTML est envoyée d'un serveur vers un client ;
- comment le contenu de cette page peut être construit :
- avec un contenu figé (HTML écrit une fois pour toutes, à la manière d'un livre),
- avec un contenu construit à la volée par le serveur (nous avons vu quelques exemples avec PHP),
- avec un contenu calculé localement par votre navigateur (quelques exemples de JavaScript).
Encore une fois, rien n'interdit de mélanger les deux méthodes et de construire sur le serveur des pages dynamiques en PHP, par exemple, qui contiennent du JavaScript. Cette méthode permet d'ailleurs, puisque le navigateur peut être identifié côté serveur, d'envoyer un script qui soit compatible avec le navigateur du client. La méthode est assez lourde, mais efficace.
6. Le proxy HTTP▲
6-1. Principe de base▲
Le principe de base consiste à dire :
lorsque je désire obtenir un document, je ne vais pas le demander à la source. Je vais le demander à mon serveur proxy. Celui-ci ira chercher le document à ma place et me le transmettra à sa réception. Au passage, il le gardera en mémoire « un certain temps », si bien que si un autre client redemande dans cette période le même document, le proxy n'aura pas besoin de retourner le chercher à la source. Ceci ne fonctionne correctement que pour les documents statiques, bien entendu. Pour les documents de type ASP, JSP ou PHP, la mise en tampon est beaucoup plus problématique.
Ce type de fonctionnement, où le client s'adresse systématiquement au proxy pour obtenir une page quelconque sur le web a fait traduire « proxy server » par « serveur mandataire ».
Notez que dans cette démarche, le client est au courant de l'existence du proxy, il va donc envoyer une requête adaptée à la situation, qui n'est pas tout à fait la même que dans le cas où il s'adresserait directement à la cible. Nous le verrons en détail un peu plus loin.
6-2. Les avantages▲
6-2-1. Optimisation de la bande passante▲
Imaginons un cas simple :
- nous sommes dans un lycée technique, les étudiants qui sont dans un laboratoire, disposent chacun d'un poste informatique. Tous ces postes sont en réseau local, avec un accès à l'Internet partagé par un routeur NAT ;
- tous les étudiants doivent consulter un document, disons, chez Texas Instrument ;
- il y a 14 postes, il y aura 14 requêtes identiques vers le serveur de TI et 14 envois de documents identiques vers les clients.
Nous remplaçons le routeur NAT par un serveur Proxy. Dans ce cas :
- la première requête sera transmise par le proxy vers le serveur de TI ;
- les 13 autres seront servies directement par le cache du proxy.
Un seul transfert de page depuis le serveur Texas Instruments vers le réseau local en remplace 14.
6-2-2. Surveillance et filtrage de l'accès au Net▲
Parmi nos 14 élèves, il y en aura bien un qui aura l'idée, en passant, d'aller faire un petit tour sur par exemple http://www.canalcharme.com ou pire. N'y voyez pas de puritanisme de ma part, juste un souci d'efficacité dans le travail et une obligation légale de protection des mineurs…
- Avec un routeur NAT, le filtrage va être difficile, parce que le seul moyen « simple » serait de filtrer au niveau de l'IP du serveur.
- Avec un proxy comme SQUID, qui travaille au niveau HTTP et qui voit donc passer les URI, il existera une foule de solutions qui permettront un filtrage :
- par mot-clé sur les URL ;
- par bannissement de domaines ou d'URI référencés dans une base de données.
6-2-3. Les inconvénients▲
Parce qu'il y en a tout de même…
- La durée de vie du cache et les mauvais paramétrages entraînent que les documents reçus peuvent ne plus être à jour.
- À multiplier les proxy en chaîne, on amplifie ce problème et on court aussi le risque de recevoir des documents falsifiés. En effet, s'il est intéressant de monter un proxy en tête d'un réseau local, il faut savoir que les FAI peuvent en utiliser aussi, de façon plus ou moins transparente (nous verrons ça plus loin). Un serveur proxy, ça peut être piraté et « bricolé »…
6-3. Le client doit être au courant…▲
Il faut commencer par paramétrer son navigateur Internet pour qu'il fasse appel à un proxy. Nous comprendrons mieux pourquoi en analysant le réseau.
Pour Firefox, c'est assez simple :
Menu « Édition » sous GNU/Linux ou « Outils » sous Windows, commande « Préférences… », Option « Avancé », onglet « Réseau » : Utilisez le bouton « Paramètres » de la connexion.
Ne faites pas confiance aux systèmes automatisés dans la mesure du possible et indiquez plutôt explicitement les paramètres du proxy :
- Son adresse IP (ou son URL) ;
- Le port sur lequel il travaille (3128 est le port par défaut pour SQUID).
Vous pouvez éventuellement spécifier des proxy différents suivant les protocoles et dans quelles conditions vous voulez éviter le proxy.
Voilà. Si le proxy est bien configuré, ça devrait fonctionner…
6-4. Que se passe-t-il, en fait ?▲
6-4-1. Le plus souvent…▲
Un proxy est placé entre un réseau local privé et un accès Internet. La configuration est alors la suivante :
Le proxy dispose de deux adresses :
- l'une dans le réseau privé (192.168.0.253 dans l'exemple) ;
- l'autre sur le réseau du FAI (80.8.128.5 dans l'exemple).
Le proxy isole complètement le réseau privé de l'Internet. Il ne servira que de serveur mandataire pour les requêtes HTTP (éventuellement aussi FTP). Avec la floraison de services webmail proposée par les fournisseurs de services, cette configuration peut permettre l'accès aux trois services les plus utilisés sur le Net :
- le surf (HTTP) ;
- le téléchargement de fichiers (FTP) ;
- le courrier, pris en charge par l'interface webmail du FAI.
Si l'on se contente de ces trois services, il n'est alors pas nécessaire d'installer de routeur NAT, le proxy suffit. Mais comprenons-nous bien : seuls les protocoles HTTP et FTP passeront, sauf cas de proxy plus particuliers, ce qui n'est pas l'objet de cette présentation.
6-4-2. Dans la démonstration qui suit ▲
Le montage adopté n'est pas obligatoirement le plus utile. Il n'y a d'ailleurs pas de connexion Internet mise en œuvre ici. Ce montage est juste fait pour illustrer le travail du proxy, lorsqu'il est utilisé.
Notez bien que 192.168.0.251 (qui est en fait ma passerelle NAT vers le Net, bien que cette fonction ne serve pas ici), est également mon DNS, ça va se voir dans l'exemple.
6-4-2-1. Premier cas : sans le proxy▲
Le client va demander la page d'accueil du site hébergé sur le serveur HTTP. Il va le faire directement :
No. Source Destination Protocol Info
4 192.168.0.10 192.168.0.251 HTTP GET / HTTP/1.1
6 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
7 192.168.0.10 192.168.0.251 HTTP GET /tbm.htm HTTP/1.1
8 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
9 192.168.0.251 192.168.0.10 HTTP Continuation
11 192.168.0.251 192.168.0.10 HTTP Continuation
16 192.168.0.10 192.168.0.251 HTTP GET /home.htm HTTP/1.1
18 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
19 192.168.0.251 192.168.0.10 HTTP Continuation
23 192.168.0.10 192.168.0.251 HTTP GET /banniere.htm TTP/1.1
24 192.168.0.251 192.168.0.10 HTTP HTTP/1.1 200 OK
25 192.168.0.251 192.168.0.10 HTTP Continuation
etc...J'ai volontairement fait disparaître les trames SYN, ACK de TCP, qui ne nous apportent rien dans la compréhension de l'échange. Nous voyons clairement que l'échange se fait entre le client et le serveur HTTP.
6-4-2-2. Second cas : avec le proxy▲
Nous paramétrons maintenant notre client pour qu'il utilise le proxy 192.168.0.253. Nous vidons le cache du navigateur et refaisons notre requête. Le proxy est également « tout neuf » son cache est parfaitement vide.
No. Source Destination Protocol Info
4 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/ HTTP/1.0
La requête a été faite au proxy et non pas à la cible qui est 192.168.0.251...
Le proxy, cherche alors l'IP de la cible : (192.168.0.251 est aussi DNS dans l'exemple).
Notez que le client envoie ici dans sa requête l'URI complet de la cible convoitée
6 192.168.0.253 192.168.0.251 DNS Standard query A gw2.maison.mrs
7 192.168.0.251 192.168.0.253 DNS Standard query response A 192.168.0.251
Puis transmet la requête à la cible...
11 192.168.0.253 192.168.0.251 HTTP GET / HTTP/1.0
La cible répond au proxy :
13 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK
qui retransmet au client:
15 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
et ainsi de suite...
16 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/tbm.htm HTTP/1.0
18 192.168.0.253 192.168.0.251 HTTP GET /tbm.htm HTTP/1.0
20 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK
22 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
23 192.168.0.251 192.168.0.253 HTTP Continuation
25 192.168.0.253 192.168.0.10 HTTP Continuation
26 192.168.0.251 192.168.0.253 HTTP Continuation
28 192.168.0.251 192.168.0.253 HTTP Continuation
31 192.168.0.253 192.168.0.10 HTTP Continuation
35 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/banniere.htm HTTP/1.0
37 192.168.0.253 192.168.0.251 HTTP GET /banniere.htm HTTP/1.0
41 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/home.htm HTTP/1.0
46 192.168.0.253 192.168.0.251 HTTP GET /home.htm HTTP/1.0
48 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK
49 192.168.0.251 192.168.0.253 HTTP Continuation
51 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
52 192.168.0.253 192.168.0.10 HTTP Continuation
54 192.168.0.251 192.168.0.253 HTTP HTTP/1.1 200 OK
56 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
57 192.168.0.251 192.168.0.253 HTTP Continuation
etc...Bien. Pour l'instant, c'est plutôt nettement plus compliqué et plus lourd qu'une requête directe. Notez au passage que le proxy (Squid dans ce cas), cause HTTP 1.0 et non HTTP 1.1.
Nous pouvons suivre les évènements à travers les logs du serveur SQUID :
192.168.0.10 TCP_MISS/200 1421 GET http://gw2.maison.mrs/ - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 4365 GET http://gw2.maison.mrs/tbm.htm - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 1513 GET http://gw2.maison.mrs/banniere.htm - DIRECT/192.168.0.251 text/html
192.168.0.10 TCP_MISS/200 4228 GET http://gw2.maison.mrs/home.htm - DIRECT/192.168.0.251 text/html
etc...Le TCP_MISS indique que le proxy n'a pas la réponse en cache et qu'il va donc la chercher à la source (DIRECT).
Mais maintenant, le cache du proxy n'est pas vide, il contient désormais ces documents. Nous allons le vérifier immédiatement en :
- vidant le cache local du navigateur ;
- effectuant à nouveau la même requête.
No. Source Destination Protocol Info
4 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/ HTTP/1.0
6 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
7 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/tbm.htm HTTP/1.0
8 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
9 192.168.0.253 192.168.0.10 HTTP Continuation
11 192.168.0.253 192.168.0.10 HTTP Continuation
16 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/banniere.htm HTTP/1.0
18 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
19 192.168.0.253 192.168.0.10 HTTP Continuation
24 192.168.0.10 192.168.0.253 HTTP GET http://gw2.maison.mrs/home.htm HTTP/1.0
26 192.168.0.253 192.168.0.10 HTTP HTTP/1.0 200 OK
27 192.168.0.253 192.168.0.10 HTTP Continuation
etc...Et là, nous constatons que le dialogue s'effectue uniquement entre le client et le proxy. Autrement dit, le proxy sert au client la totalité des requêtes, il n'y a plus aucun échange entre le proxy et le serveur HTTP.
Vérifions les logs :
192.168.0.10 TCP_MEM_HIT/200 1430 GET http://gw2.maison.mrs/ - NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 4374 GET http://gw2.maison.mrs/tbm.htm - NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 1522 GET http://gw2.maison.mrs/banniere.htm - **NONE/- text/html
192.168.0.10 TCP_MEM_HIT/200 4237 GET http://gw2.maison.mrs/home.htm - NONE/- text/html
etc...TCP_MEM_HIT veut dire que non seulement la réponse est en cache (HIT) mais qu'elle est en mémoire (MEM). Il n'y a donc pas d'interrogation en amont (NONE).
Notez qu'il aurait pu se passer autre chose. Ici, la requête initiale et la seconde requête du client étaient séparées par un intervalle de temps très court. Si cet intervalle avait augmenté, le document ne se serait peut-être plus trouvé dans le cache mémoire, mais dans le cache disque, et il aurait pu se faire que le proxy aille s'assurer auprès du serveur source que son contenu local était encore valide. La stratégie est assez logique :
- un document qui vient d'être téléchargé par le proxy a toutes les chances d'être toujours valide. Il est donc possible de le resservir directement, sans précautions particulières ;
- un document qui a été téléchargé il y a déjà quelque temps, risque d'avoir été modifié. Il convient donc de s'assurer d'abord auprès du serveur source que le document n'a pas été modifié depuis ;
- un document qui a été téléchargé il y a trop longtemps est détruit du cache du proxy. au prochain appel, il faudra le télécharger à nouveau.
Les notions de « vient d'être », « il y a déjà quelque temps » et « il y a trop longtemps » sont bien entendu subjectives et c'est à l'administrateur du proxy de les évaluer efficacement.
Il y a tout de même quelques exceptions à ces règles :
- les documents « actifs », nous l'avons déjà dit, tels que les pages PHP, ASP, JSP… ou qui viennent de scripts CGI ;
- les documents « passifs », mais qui contiennent un champ « expire » dans leur en-tête. Ce champ, assez peu utilisé, permet au concepteur d'une page de forcer l'attitude d'un proxy à son égard.
6-5. Finalement…▲
Lorsque la connexion entre le réseau local et le Net se fait par un lien facturé à la durée ou au volume transmis, le gain financier peut être appréciable.
Lorsque la connexion au Net se fait par un lien à faible débit, le gain en temps peut également être très appréciable.
Nous ne le verrons pas ici dans le détail, mais les possibilités de contrôle d'accès au Net sont plus grandes et plus simples à mettre en œuvre avec un proxy qu'avec un routeur. De même, la sécurité du réseau local est plus facilement assurée, si le serveur proxy n'est vraiment qu'un proxy. La solution du proxy n'est cependant pas la panacée et il convient de bien analyser toutes les solutions possibles à un problème donné avant d'en choisir une.
6-6. Le proxy « transparent »▲
Dans ce que nous avons vu, la présence du proxy est connue des utilisateurs du réseau, ils doivent configurer leur navigateur pour pouvoir l'utiliser.
Il est possible de forcer les utilisateurs à passer par le proxy en bloquant le port 80 sur la passerelle par défaut. L'expérience montre qu'il n'est pas toujours simple de l'expliquer aux utilisateurs, surtout lorsqu'ils sont visiteurs occasionnels.
Techniquement, nous l'avons vu dans les analyses des trames, le client HTTP s'adresse explicitement au proxy et place dans sa requête GET l'URI complet de la cible visée. C'est pour forcer ce type de comportement qu'il faut paramétrer correctement le client HTTP.
L'autre méthode, c'est de laisser le client HTTP dans l'ignorance de l'existence du proxy. Il va alors exécuter un GET « normal » sur l'adresse IP de la cible visée. Pour forcer le passage par le proxy, la passerelle devra alors rediriger cette requête sur le serveur proxy et ce dernier devra savoir retrouver l'adresse de la cible, ailleurs que dans la commande GET, surtout si le client parle HTTP 1.0. La configuration du proxy doit donc tenir compte de ce mode de fonctionnement.
Squid sait fonctionner en mode « transparent », il suffit de le lui demander poliment.
6-6-1. Avantages▲
Plus de configuration du client HTTP, donc plus rien de technique à expliquer aux utilisateurs.
L'utilisateur occasionnel (visiteur par exemple) n'aura pas à « bricoler » son client HTTP en entrant et en sortant de votre réseau. Même si pour lui, cette opération est triviale, elle reste tout de même contraignante.
6-6-2. Inconvénients▲
La tentation est grande alors d'oublier de prévenir les utilisateurs qu'ils passent par un proxy et que donc, outre les éventuels décalages entre les pages servies et les pages à jour, toute leur activité se trouve enregistrée dans les logs.
Un proxy transparent ne peut fonctionner que sur un seul port et uniquement pour HTTP :
- les clients qui visent des serveurs sur le port 81 par exemple, passeront directement (ou ne pourront pas passer du tout si votre firewall le leur interdit) ;
- pas de proxy transparent pour FTP ;
- pas de proxy HTTPS (encore que l'on peut s'interroger sur son utilité dans ce cas).
6-7. Conclusion▲
Le serveur proxy peut être une très bonne solution pour partager un accès Internet au niveau application, ce qui permet d'effectuer un filtrage au niveau du protocole lui-même. Indispensable lorsque l'on doit donner l'accès à des mineurs, dans le cadre scolaire par exemple.
Une mise en pratique est analysée dans le chapitre « Squid et SquidGuard » dans ce but.
7. Remerciements Developpez▲
Vous pouvez retrouver l'article original ici : L'Internet Rapide et Permanent. Christian Caleca a aimablement autorisé l'équipe « Réseaux » de Developpez.com à reprendre son article. Retrouvez tous les articles de Christian Caleca sur cette page.
Nos remerciements à Torgar et sevyc64 pour leur participation technique ainsi qu'à ClaudeLeloup pour sa relecture orthographique.
N'hésitez pas à commenter cet article ! 1 commentaire 