Pare-feu.
Garantir la sécurité d'un domaine réseau, à savoir :
Un pare-feu (firewall) est une architecture réseau (et non forcément une seule machine comme on le pense souvent).
Il peut fournir divers services :
Les pare-feux situés entre deux parties communiquant via RMI (une applet et son serveur par exemple)
interdisent généralement l'accès au port RMI par
défaut (1099), ce qui amène automatiquement (si la propriété http.proxyHost est spécifiée, voir plus
bas) le client RMI à tenter un tunneling HTTP. Si cette tentative de tunnelling n'est pas souhaitée, on
fixera la propriété java.rmi.server.disableHttp=true.
Parce les requêtes HTTP ne peuvent être émises que dans une direction au travers d'un pare-feu, un client ne peut exporter ses propres objets au-delà du pare-feu, parce qu'une machine au-delà de ce pare-feu ne peut invoquer une méthode en retour vers le client (à vérifier si le pare-feu autorise les requêtes entrantes sur le port HTTP).
Il arrive également que le pare-feu d'un utilisateur empêche ce dernier de se connecter à un serveur DNS externe, et donc de résoudre des noms symboliques (www.javarome.org par
exemple) en adresses physique (195.102.32.38 par exemple). Une applet sera par exemple incapable de charger une de
ses ressources, parce qu'utilisant son codebase exprimé sous forme de nom symbolique pour récupérer cette
ressource.
Il existe plusieurs solutions pour résoudre ce problème :
L'utilisation du protocole HTTP est donc une règle quasi-générale pour franchir les pare-feux. Ce protocole possède cependant de nombreux désavantages, qu'il peut être nécessaire de contourner afin que le support des pare-feux n'handicape pas fonctionnellement notre application.
HTTP n'est en effet pas un protocole dit "connecté", ce qui signifie que la connection établie par le client est censée être fermée une fois la réponse envoyée à ce premier.
Ce n'est heureusement pas toujours vrai.
De nombreuses implémentations de HTTP ont introduit une optimisation de ce principe, au travers des "connexions persistantes".
Le principe des Connexions Persistantes consiste à réutiliser une connexion établie au lieu de la fermer et d'en réouvrir une autre.
Ce mécanisme est fourni dans de nombreuses implémentations de HTTP, au travers de l'option Keep-Alive. Elle devait
cependant être négotiée avec le serveur (qui devait la comprendre) et ne constituait pas le comportement par
défaut de HTTP 1.0. Ceci pouvait en outre poser des problèmes lorsqu'un
client souhaitait se connecter à un tel serveur via un proxy HTTP qui ne comprenait pas cette option, et se bornait à la
transmettre au serveur final. Ce dernier, qui comprenait l'option, ne fermait pas sa connexion, ce qui bloquait
le proxy qui, lui, attendait une fermeture.
HTTP 1.1 a apporté de nombreuses optimisations, dont
l'utilisation par défaut des connexions persistantes, où l'exception consiste donc à fermer une connexion (la
partie effectuant cette fermeture devant en informer l'autre via l'option Connection: close).
L'utilisation de connexions persistantes par défaut permit par la suite diverses autres optimisations, comme
l'envoi de plusieurs requêtes HTTPà la suite (les réponses sont
renvoyées dans l'ordre).
Un client HTTP (navigateur Web typiquement), tentera donc d'envoyer des requêtes HTTP sur une connexion existante (pour peu que le même serveur soit visé) tant que cette connexion n'a pas été fermée. Le nombre de requêtes acceptées sur une même connexion peut être paramétrable côté serveur (dans la configuration d'un serveur Web par exemple), ainsi que le délai d'inactivité accepté avant la fermeture d'une connexion (timeout).
Ou Pending Connections.
Certains besoins fonctionnels, tels qu'une connexion full-duplex peuvent être incompatibles avec un mode déconnecté ou déconnectable (un serveur désirant envoyer des événements à un client par exemple - le fameux server push ou push).
Une technique existe cependant pour contourner ce problème, consistant pour le client à se connecter au serveur en lui indiquant qu'il souhaite recevoir un événement. Le serveur enregistre le fait qu'il s'agit d'une connexion pour notification d'événement et ne déconnecte pas le client. Lorsque l'événement surviendra, le serveur utilisera cette connexion pour en avertir le client.
Ce procédé sous-entend cependant un accord de principe entre le client et le serveur.
Un serveur mandataire (ou proxy, serveur de délégation) est une machine mandatée pour effectuer les requêtes réseau de machines du réseau interne à la place de celles-ci.
Ceci permet :
Il existe deux grandes catégories de serveurs mandataires :