FAQ pour le projet Qroxy

Nous souhaitons pour gérer la qualité de service limiter le débit d'une connexion TCP vers un serveur web afin qu'elle ne monopolise pas la bande-passante. Nous contrôlons le débit d'émission vers ce serveur ; comment gérer le débit de réception ? Il y a deux possibilités :

• Demander gentiment au serveur HTTP de ne pas dépasser un certain débit d'émission. Le serveur va alors pour chaque quantum de temps réaliser une boucle d'écritures sur la socket reliée au client ; dès que la quantité limite pour le quantum de temps est dépassée, le serveur attend le prochain quantum pour écrire. Il est nécessaire d'adopter une convention pour indiquer au serveur le débit d'émission que l'on souhaite qu'il adopte : d'où la mini-RFC demandée où l'on indiquera l'en-tête utilisé. On n'est pas obligé d'implanter un serveur HTTP supportant cette possibilité (si vous avez du temps, c'est possible).
• Dans le cas général, on ne peut imposer directement un débit d'émission à un serveur qui se contente d'implanter le protocole HTTP/1.1 sans la mini-RFC que nous devons écrire. On impose donc un débit d'émission indirectement en contrôlant le débit de lecture : si l'on lit lentement, le buffer TCP de l'OS sature avec les données en attente de lecture : le contrôle de flux TCP entre en oeuvre et permet indirectement de limiter le débit d'émission du serveur. C'est le mécanisme principal sur lequel repose la qualité de service gérée par Qroxy (l'utilisation de l'en-tête de débit reste utopique ;).

Le proxy doit pouvoir garantir la confidentialité de ressources récupérées. Un serveur peut fournir des indications sur la politique de cache à adopter en spécifiant qu'une ressource fournie peut être mise en cache, qu'elle peut être cachée uniquement pour un usage privé ou alors que la mise en cache ne doit pas être réalisée dans tous les cas. Le sujet spécifie que le proxy peut être configurable en mode partagé ou non-partagé. En mode partagé, les données déclarées privées ne doivent pas être mises en cache alors que ceci est souhaitable en mode non-partagé. En mode non-partagé le proxy peut toujours coopérer avec d'autres proxys du réseau local en leur envoyant des ressources dont ils auraient fait la demande sauf bien sûr s'il s'agit de données déclarées privées.

Pour chaque requête envoyée vers un serveur, il est nécessaire de choisir les règles de QoS qui s'appliquent. Nous pouvons définir des catégories de ressource, chacune étant associée à une règle de QoS. Une catégorie de ressource est définie par la validation d'un ensemble d'expressions régulières sur l'URL de la ressource ainsi que sur les champs d'en-tête de requête et de réponse. Par exemple nous pouvons définir une catégorie validant l'URL http://igm.univ-mlv.fr/ens/IR/IR2/201(0|1)-201(1|2)/.* et un champ d'en-tête de réponse Content-Type: text/.*. Une autre catégorie pourrait être définie par la validation de l'URL .* (n'importe quelle URL) et de l'en-tête Content-Type: text/html pour s'appliquer à tous les documents HTML. Une requête peut donc très bien appartenir à plusieurs catégories et ainsi être liée à plusieurs règles de QoS. Il faut réfléchir au comportement à adopter dans cette situation : appliquer la règle la plus permissive ? ou alors la plus restrictive ? Le sujet laisse une liberté sur cette question.

A priori, la configuration doit être réalisée de telle sorte que la somme des débits minimaux pour toutes les ressources traitées à un instant T ne dépasse pas le débit de la connexion. Si ce débit est dépassé, on pourra par exemple utiliser le poids de priorité afin de partager le débit lacunaire entre les différentes ressources. Notons R->(min, w) une ressource associée à son débit minimal et son poids de priorité. Prenons pour exemple R1->(100,2) et R2->(200,1) sur une connexion de débit 240. Le débit lacunaire est de 240-200-100 = -60 ; nous enlevons 2 fois moins de débit à R1 que R2, soit 1/3 * 60 pour R1 et 2/3 * 60 pour R2. Ainsi R1 utilise un débit de 80 et R2 de 160. En cas de surplus de débit, nous aurions attribué les 2/3 du surplus à R1 et le tiers restant à R2 ; dans tous les cas le débit maximal ne doit pas être dépassé.

On peut supposer que les différents proxys s'échangent des données sur un réseau local. L'utilisation d'un protocole utilisant des paquets UDP en multicast pour la découverte des ressources disponibles est donc possible. L'envoi d'une ressource d'un proxy à un autre est réalisée en TCP unicast. Pour simplifier on pourra considérer que l'on n'intervient pas pour limiter le débit de l'échange de ressources inter-proxy.

L'interface web d'administration ne doit pas requérir ni application, ni bibliothèque externe pour son fonctionnement. Il faut donc incorporer un mini-serveur web au proxy qui est accédé lorsque le client demande une URL spécifique.