Géolocalisation IP sur Cloudflare Workers : cache et démarrages à froid

La géolocalisation IP sur Cloudflare Workers consiste à lire des données de localisation sur un visiteur dans un Worker, soit à partir de l'objet intégré request.cf, soit en appelant depuis la périphérie une API externe de renseignement sur les IP. Les deux approches répondent à des questions différentes, et il vaut la peine de comprendre le comportement de chacune en matière de cache et de démarrage à froid avant de construire dessus.

Ce que Workers vous offre gratuitement

Chaque requête qui atteint un Worker porte un objet request.cf rempli par Cloudflare. Il inclut le pays, la ville, la région, les coordonnées, le fuseau horaire, l'ASN et l'organisation de l'AS du visiteur, ainsi que le champ colo qui nomme le datacenter ayant traité la requête. L'en-tête CF-IPCountry transporte également le code pays. Comme ces données sont jointes avant l'exécution de votre code, elles n'entraînent ni sous-requête supplémentaire ni latence supplémentaire.

La limite est le périmètre. request.cf décrit le client connecté pour la requête en cours, et rien d'autre. Il ne peut rien vous dire sur une adresse IP qui apparaît dans une ligne de log, un champ de formulaire, une charge utile de webhook ou une chaîne X-Forwarded-For, et il ne comporte aucun signal de réputation tel que les indicateurs VPN, Tor ou abus. Dès que vous devez enrichir une adresse quelconque, vous appelez une API, et c'est là que commencent les décisions de cache.

Mettre en cache les données d'enrichissement en périphérie

Une recherche IP depuis un Worker est une sous-requête : chaque recherche non mise en cache ajoute donc un aller-retour réseau au chemin de la requête. Cloudflare propose plusieurs emplacements pour mettre le résultat en cache : l'API Cache (par datacenter, non répliquée globalement), KV (lisible globalement mais à cohérence à terme, les écritures mettant du temps à se propager) et les Durable Objects lorsque vous avez besoin d'une copie unique et coordonnée. Aucun n'est un cache global prêt à l'emploi : choisissez selon ce que vous pouvez tolérer. L'API Cache est la plus simple et la plus rapide pour les recherches très lues, tandis que KV convient aux valeurs que vous voulez visibles depuis tous les emplacements.

La décision de conception la plus utile concerne la durée de vie par champ, car les données de renseignement sur les IP ne vieillissent pas de manière uniforme. Les attributions de pays et d'ASN changent lentement, puisque les blocs d'adresses sont réaffectés sur des mois ou des années : un TTL de plusieurs heures est donc raisonnable. Les indicateurs de réputation sont différents. Les flux VPN, Tor et abus d'ipto sont actualisés toutes les 6 heures, et ses jeux de données IP et ASN quotidiennement ; mettre en cache un indicateur comme is_tor plus de quelques heures revient à servir des réponses plus anciennes que la source elle-même. Une répartition pratique consiste à mettre en cache les faits de réseau (asn, asn_org, pays, ville) pendant environ un jour et les indicateurs (is_vpn, is_tor, is_abuser, is_datacenter) pendant au plus l'intervalle du flux.

• Indexez le cache sur l'IP normalisée (pour IPv6, envisagez d'indexer sur le /64 si votre cas d'usage porte sur le réseau plutôt que sur l'hôte).
• Mettez aussi en cache les résultats négatifs, afin que les recherches répétées d'une adresse non listée ne sollicitent pas l'API à chaque fois.
• Ne mettez jamais par erreur en cache des résultats bogon sous une clé publique : une adresse privée comme 10.0.0.1 peut être traitée localement sans aucun appel d'API.

Démarrages à froid sur Workers

Les Workers s'exécutent dans des isolats V8 plutôt que dans des conteneurs ; un démarrage à froid se compte donc généralement en millisecondes, et non en centaines de millisecondes comme avec les fonctions à base de conteneurs. Votre code paie néanmoins sa propre initialisation : un gros bundle, un traitement lourd au niveau du module d'une grande table de correspondance ou des await de niveau supérieur ont tous lieu à la première requête vers un isolat neuf. Le remède est ordinaire : gardez le bundle petit, évitez de construire de grosses structures en mémoire au démarrage et préférez un seul petit appel d'API plutôt que d'embarquer toute une base de géolocalisation dans le Worker.

Les pings de préchauffage que l'on utilise avec le serverless traditionnel sont ici surtout inutiles. Les isolats sont créés et évincés selon le calendrier de Cloudflare, un ping n'atteint qu'un seul emplacement, et le coût d'un démarrage à froid est assez faible pour que la mise en cache du résultat de recherche compte bien plus que le maintien de l'isolat en vie. Mesurez d'abord avec les analyses de Workers et avec votre propre chronométrage autour de la sous-requête avant d'optimiser quoi que ce soit.

Assembler le tout avec ipto

Un schéma raisonnable consiste à utiliser request.cf pour les faits instantanés et gratuits sur le client connecté, et à n'appeler une API d'enrichissement que lorsque vous avez besoin de plus. La documentation de l'API d'ipto montre la réponse de la recherche IP, qui renvoie le pays, la ville, l'ASN, l'org, currency_code et les indicateurs is_vpn, is_tor, is_abuser, is_datacenter et bogon/bogon_type. Elle est gratuite, sans inscription, avec 1 000 requêtes gratuites par jour, ce qui suffit pour prototyper un Worker sans étape de gestion de clé.

Lorsque la recherche vous indique que l'adresse appartient à un réseau d'hébergement, vous pouvez poursuivre dans la recherche ASN pour voir qui l'exploite et quelles plages il annonce. Pour le trafic signalé, le vérificateur VPN, Tor et proxy montre les éléments derrière is_vpn et is_tor, et le vérificateur d'abus IP montre le score corroboré. N'oubliez pas que la localisation au niveau de la ville est une estimation de l'endroit où un réseau est enregistré ou routé, et non de l'endroit où se trouve une personne, une limite expliquée dans pourquoi la précision au niveau de la ville est limitée.

La périphérie rend les recherches rapides, mais ne rend pas les données sous-jacentes plus précises. Traitez request.cf et tout résultat d'API comme une preuve de même nature, mettez chacun en cache selon sa vitesse de changement, et laissez la fraîcheur de la source, et non la vitesse de la périphérie, déterminer vos TTL.

Réponses directes