Ce que nous faisons · Opérations: Contrôle du trafic en edge pour crawlers et scrapers
Une partie du trafic le plus lourd que reçoit votre site est du HTTP techniquement valide, venu des moteurs de recherche, des crawlers IA, des générateurs d'aperçus de liens et des scrapers. Nous le contrôlons au load balancer, avant qu'il n'atteigne PHP ou la base de données, pour que les chemins qui coûtent du vrai travail restent rapides pour les vrais visiteurs.
De quoi il s'agit
- h2: De quoi il s'agit
Du rate limiting, de la classification et du filtrage en edge pour un trafic qui n'est pas une attaque au sens classique, mais qui se comporte comme telle sur le plan opérationnel :
- Des crawlers IA et de recherche qui parcourent d'un coup chaque page d'un sitemap paginé.
- Des bots d'aperçu de liens qui récupèrent la même URL non mise en cache des centaines de fois en parallèle.
- Des scrapers qui martèlent la navigation à facettes, où chaque combinaison de filtres est une nouvelle requête en base.
- Des crawlers qui génèrent à chaque passage des URL toujours plus longues et ré-encodées.
Ces requêtes frappent les chemins non mis en cache, les plus coûteux, et c'est là que nous plaçons les contrôles.
Comment nous le construisons
- h2: Comment nous le construisons
Des limites de débit là où est le coût. Des stick tables HAProxy suivent le débit de requêtes par client et par agent sur des chemins coûteux précis, comme les sitemaps, la recherche et les listes filtrées. Un crawler qui dépasse le débit convenu reçoit un 429, et le reste du site n'est pas affecté.
Une correspondance qui résiste au changement. L'identification des crawlers repose sur des règles par sous-chaîne qui continuent de fonctionner quand un bot change le format de sa chaîne user agent.
Les schémas malformés refusés d'emblée. Les URL doublement encodées de façon répétée, les chaînes de requête impossibles et autres formes du même genre sont rejetées en edge par une seule règle.
PHP protégé des requêtes qui passent. PHP-FPM reçoit des délais d'interruption de requête et des plafonds mémoire par worker, de sorte qu'une requête pathologique ne peut pas tourner pendant des minutes, grossir sans limite ou emporter le pool de workers avec elle.
Le cache continue de servir. Pendant tout cela, Varnish continue de servir les pages en cache, de sorte que le site public reste rapide pendant que les chemins non mis en cache sont protégés.
Déployé partout, consigné une fois. Chaque garde-fou est posé sur chaque edge de la propriété, et vous recevez un court rapport avec les chiffres de trafic, la règle et son effet.
Ce dont il vous protège
-
h2: Ce dont il vous protège
-
Un crawler IA ou un générateur d'aperçus qui tire des centaines de requêtes simultanées sur votre requête la plus lourde.
- Des scrapers qui mettent hors service la navigation à facettes d'une boutique en ligne, et avec elle la base de données, en pleine campagne.
- Des workers PHP emballés qui grossissent jusqu'à ce que le système d'exploitation doive les arrêter.
- Des règles de protection qui ont cessé de correspondre en silence il y a des mois.
- Un blocage brutal qui exclut les moteurs de recherche et vous coûte votre référencement.
En pratique
- h2: En pratique
Un élément standard de chaque edge que nous construisons. Sur les sites de presse et d'e-commerce, les chemins de sitemap, de recherche et de listes filtrées reçoivent des garde-fous de débit dès le premier jour, dimensionnés à ce que le site peut servir sans cache.
Des règles qui suivent le trafic, pas une liste de fournisseur. Nous lisons vos logs d'accès pour voir quels agents et quelles formes de requêtes coûtent le plus de temps PHP et base de données, puis nous écrivons la règle pour ce schéma, la déployons sur chaque edge de la propriété, et consignons pour vous les chiffres avant et après.
Pourquoi EuroVPS
-
h2: Pourquoi EuroVPS
-
Des contrôles au load balancer, pas un plugin dans l'application.
- Des règles ciblées sur les chemins coûteux, pour que les moteurs de recherche continuent d'indexer et les visiteurs de naviguer.
- Nous lisons les logs d'accès et mesurons, puis nous écrivons la règle.
- Les limites PHP-FPM et les règles en edge conçues ensemble.
- Des garde-fous déployés sur chaque edge d'une propriété, avec les chiffres consignés.
Questions fréquentes
- h2: Questions fréquentes
Cela va-t-il nuire à notre référencement ? Non. Nous limitons le débit sur les chemins coûteux plutôt que de bloquer les crawlers, et un 429 indique aux crawlers légitimes de revenir plus tard.
Pouvez-vous bloquer complètement les crawlers IA ? Oui, si c'est votre politique. Beaucoup de clients préfèrent les limiter en débit.
Est-ce un WAF ? Cela le complète. Un WAF cherche des attaques ; le contrôle du trafic en edge gère la charge d'un trafic légitime mais coûteux.
Devons-nous modifier notre application ? Non. Les contrôles vivent au load balancer et dans la configuration de PHP-FPM.
En combien de temps pouvez-vous réagir à un nouveau crawler ? Une règle ciblée peut généralement être écrite et déployée sur chaque edge en quelques minutes après l'identification du schéma.
Des bots qui dévorent votre capacité ? Parlez à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.