Cette config est un gros hack pas propre du tout et pas confirme au standard HTTP. C'est bien dommage que ce ne soit pas bien documenté dans le serveur de tuiles mais de toute façon la façon dont c'est fait est bogué et cette option devrait être supprimée. C'est la mauvaise façon de faire un "throttling" que de casser la compatibilité HTTP (surtout ici en s'appuyant sur un entête purement informatif et en concluant qu'on peut modifier unilatéralement le routage en ignorant le cycle de vie d'une session et en supposant qu'il n'y a pas d'autres proxies dans la chaîne de transmission et le séquencement des autres sessions en parallèle, y compris celles du même client).
En tout cas si vous supprimez cette option foiruese cela rédoudra aussi des cas fréquents qu'on constate même depuis un client avec un accès direct à Internet qui n'un coup de reçoit plus rien du tout pendant plusoeurs minutes pour les tuiles qu'il demande, comme si le serveur était surchargé. Cette option est beaucoup trop agressive (à la limite elle peut servir uniquement sur un LAN dont on connait la topologie, mais pas du tout sur des connexions issues d'adresses IP sur Internet dont on ne sait pratiquement rien des méthodes d'accès. En effet les proxies peuvent même être imposés par l'opérateur internet du client, par exemple pour les utilisateurs de réseaux mobiles qui ne fournissent pas d'adresse IP publique à leurs clients utilisateurs de smartphones sur leurs réseau d'accès; et qui limitent aussi les protocoles utilisables et limitent fortement aussi les durées de session sans "trafic visible" [les sessions ne tiennent souvent seulement pas plus de 10 à 15 secondes maxi sur les réseaux mobiles 3G — comme SFR qui est en France le plus agressif — sur un tel accès, les sessions HTTP longues DOIVENT utiliser les statuts HTTP 1xx de continuation pour les requêtes longues sinon elles échouent en cours de traitement par le serveur consulté, si le serveur ne peut pas répondre immédiatement dans les 5 secondes, et le serveur doit lui-même émettre ces statuts dans un délai raisonnable, faute de quoi il perdra son client ; SFR, quand il interrompt une session sur ses proxy d'accès mobile, ne renvoie lui-même aucun statut HTTP non plus à son client, alors même qu'il lui impose une connexion en HTTP et le tunnelage HTTP des autres protocoles qu'il veut bien transporter, et que très peu d'autres protocoles sont supportés ! Un tunnel VPN sécurisé et crypté sera interrompu si dans le tunnel de transport il n'y a pas émission régulière, hors-bande, de statuts de continuation confirmant qu'il y a encore une activité attendue et que les requêtes suivent leur cours normal même si elles sont plus lentes à répondre qu'une page web statique, qui demande peu ou pas de calcul lourd sur un serveur]. Autre suggestion: si un serveur de tuiles ne peut retourner une tuile complète car la file d'attente de rendu est pleine, il devrait retourner rapidement une ancienne version précalculée de la tuiles depuis son cache local, même s'il a enregistré la tuile comme devant être mise à jour par la demande détectée. Je crois avoir lu que c'est fait sur certains serveurs (pas tous). Cela a l'avantage de permettre de ne pas garder des sessions trop nombreuses ouvertes (et d'éviter la saturation des ports TCP disponibles et donc se prémunir aussi contre des attaques DoS faciles). Si on veut limiter le traffic mod_tile ne peut rien utiliser d'autre que l'adresse IP la plus directe et ne doit rien supposer de la topologie des clients distants qui se connectent par cette adresse IP. Tout ce qu'on peut faire c'est limiter le nombre de sessions parallèles et imposer une file d'attente en ajoutant des délais de réponse: Si la lmite est dépassée, il ne faut pas interrompre brutalement sans rien dire, il faut retourner un statut 4xx permettant au client (ou proxy client) d'être informé et ensuite pouvoir gérer ses sessions et leur cache des réponses obtenues, ainsi que les délais avant de pouvoir retenter la requête (mais vu les délais donnés dans les traces plus haut, 3 jours!!!, c'est difficilement gérable, le client ou proxy client ne dispose d'aucun moyen de réguler son trafic avec la "solution" actuelle). Si le but c'est de se prémunir contre des attaques de type DDoS, ce n'est pas sur modètile qu'il faut faire ça mais sur un parefeu frontal (qui peut aussi utiliser d'autres systèmes pour inspecter les sessions, y compris utilise ICMP ou d'autres inspections dans des couches basses d'IP ou l'inspection des routes et des flags d'option d'IP, ou encore des inspections de trafic via une analyse DNS., ou encore des options sur IPSEC ou systèmes d'authentification sur un VPN si on l'utilise. D'ailleurs les serveurs de tuiles ne devraient-ils pas être accessibles en HTTPS (voire par un tunnel end-to-end)? Oui je sais, HTTPS a un coût en performance car il va imposer un petit trafic initial supplémentaire (et un ou deux roundtrips initiaux donc un délai ajouté d'environ 50 à 120ms, selon qu'on reste en France ou qu'on change de pays ou traverse un océan, avant de commencer à dialoguer) pour l'authentification mais je ne demande pas non plus le cryptage, juste l'authentification des clients pour identifier et séparer correctement les sessions. Cela pourrait permettre à certains proxies identifiés de passer outre certaines limites basiques d'utilisation (l'autorisation pouvant être donnée si ces proxies utilisent des entêtes de traçage correct pour permettre de tracer la topologie de leurs clients et gérer les différentes sessions de leurs clients multiples dont ils assurent l'identification et l'application d'une politique amont de limitation de trafic, de façon plus détaillée que le trafic global sortant du proxy du réseau client). Sur une session authentifiée, il est alors tout à fait possible d'utiliser les infos X-Forwarded-For et Via transmises par un proxy bien identifié et qui les utilise de faon cohérente et systématique. Le 27 mai 2014 19:32, Jocelyn Jaubert <jocelyn.jaub...@gmail.com> a écrit : > Le 27/05/2014 10:07, Landry MINOZA a écrit : > > Je viens d’effectuer des tests supplémentaires avec curl, j’ai testé > toutes les > > entêtes passées par firefox et squid, toutes les combinaisons testés > renvoient > > bien la tuile demandée sauf lorsqu’il y a un entête "X-Forwarded-For". > J’ai > > essayé cet entête avec comme IP mon IP publique, 127.0.0.1 et l’IP > publique du > > serveur, la réponse est toujours vide. > > > > N’y aurait-il pas un reverse proxy apache et une vérification de > provenance sur > > l’application qui est derrière (auquel cas, apache devrait supprimer > l’entête > > X-Forw arded-For avant d’ajouter la sienne). > > Merci pour le debug, ça a été bien utile. C'est normalement corrigé > maintenant. > > La config du serveur de tuile (mod_tile) contenait cette config: > > ModTileEnableTileThrottlingXForward 1 > > D'après ce que j'ai compris, ça sert à attribuer les tuiles à l'IP du > X-Forwarded-for plutôt que l'IP du proxy, pour le méchanisme de limitation > de tuiles par IP. J'ai modifié à 0, ce qui signifie que c'est l'IP du proxy > qui est utilisé, ce qui me parait plus approprié. > > > -- > Jocelyn > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
