Un relais est un point de regroupement de flux réseau, généralement associé à plusieurs clients. C'est ainsi que l'on trouve des relais HTTP, souvent associés à des caches. Ces relais se substituent aux outils des utilisateurs (par exemple les navigateurs des collaborateurs d'une entreprise, ou les abonnés d'un FAI) afin d'émettre les requêtes vers les serveurs HTTP, et renvoient aux utilisateurs les informations obtenues.

L'avantage d'un relais est de canaliser les échanges (point de passage obligé, sous réserve d'avoir mis en place les filtres réseaux appropriés), avec les possibilités que cela offre du point de vue des contrôles que l'on peut y faire. Dans la majorité des cas, le relais HTTP est un point de regroupement et d'éclatement des flux : N clients contactent 1 relais qui peut contacter M serveurs HTTP.

Certains relais peuvent n'avoir pour vocation que de canaliser les échanges vers un seul serveur. Typiquement, le relais de messagerie entrant joue ce rôle. M systèmes peuvent le contacter (émission de messages à destination de l'entreprise), et ce relais ne dialogue qu'avec le serveur de messagerie interne (lequel peut aussi relayer les messages vers des serveurs départementaux, mais c'est une autre histoire).

Relais inverse HTTP

Le système de relayage a pour but de canaliser les flux HTTP à destination d'un serveur réel, lequel n'est alors plus joignable directement depuis Internet (ou depuis une zone considérée à risques de votre réseau).

Ce mode de fonctionnement, dans sa configuration la plus élémentaire, permet de protéger un serveur HTTP derrière un relais, ce dernier étant configuré au plus strict. On occulte complèment le serveur réel au profit d'un relais plus réduit et plus léger.

L'intérêt est évident :

• Les utilisateurs contactent un serveur HTTP dont les fonctionnalités ont été réduites au strict minimum.
• On crée un canal restreint par lequel tous les échanges avec le "véritable" serveur Web doivent passer.

La restriction des fonctionnalités du relais permet de minimiser les risques applicatifs ou de mauvaise configuration. S'il est bien installé et configuré, le relais ne sait pas faire autre chose que relayer vers d'autres systèmes. Par exemple, si l'on utilise un serveur Apache en tant que relais inverse, il est suffisant de n'activer que quelques-uns des modules standard. Les fonctions évoluées (CGI, négociation de la langue, suivi des utilisateurs, etc.) sont inutiles et donc non-intégrées au relais. Leur absence totale du système permet d'éviter qu'elles ne soient accidentellement activées ultérieurement.

Le relais inverse est le seul système autorisé à dialoguer avec les véritables serveurs. Cela permet de configurer ces derniers afin qu'ils n'acceptent de requêtes que si elles viennent du relais inverse. Ainsi, il devient difficile de contourner les contrôles mis en place par le relais (s'il y en a). Si les fonctionnalités du service Web ont été réparties sur plusieurs serveurs (le relais inverse jouant le rôle d'aiguilleur), la surveillance des systèmes opérationnels les plus sensibles en est facilitée :

• Inutile de surveiller finement les flux vers le serveur d'images, qui ne fournit que du contenu statique.
• Le serveur de pages est plus surveillé car il traite des informations issues des utilisateurs (cookies, paramètres de certaines URLs, etc.).
• Les flux avec le serveur de programmes sont contrôlés très finement (volumes transmis, contenus, etc.)

Outre ces premiers avantages, il est possible :

• De mettre en place un filtrage des URLs demandées, selon des critères plus ou moins élaborés.
• De diriger les requêtes vers des serveurs différents, selon les situations (serveur d'images, de programmes, etc.).
• De filtrer les paramètres transmis aux programmes.

Toutes ces opérations sont transparentes pour l'internaute, qui n'a jamais l'impression de dialoguer avec des systèmes différents. Pour lui, il est en train de discuter avec "le" serveur HTTP, même lorsque ses requêtes sont réacheminées vers plusieurs systèmes différents.