Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
IPv4- und IPv6-Besucher in Ihren Logs unterscheiden
Eine Adresse wie 203.0.113.42 und eine wie 2001:db8::1 sehen offensichtlich unterschiedlich aus, doch sobald Adressen in einer Logdatei oder einer Datenbankspalte vergraben sind, behandelt ein Skript, das ein bestimmtes Format voraussetzt, das andere unbemerkt falsch.
Das version-Feld auslesen
Der Endpunkt /v1/ip gibt in jeder Antwort ein version-Feld zurück, entweder 4 oder 6, zusammen mit den übrigen Standortdaten. Sie müssen die Adresszeichenkette nicht selbst parsen, um herauszufinden, zu welcher Adressfamilie sie gehört.
GET /v1/ip?ip=2001:db8::1{
"status": "ok",
"ip": "2001:db8::1",
"version": 6,
"found": true,
"country": "Canada",
"country_code": "CA",
"region": "Ontario",
"city": "Toronto",
"postcode": "M5H",
"lat": 43.6511,
"lon": -79.3808,
"timezone": "America/Toronto",
"asn": 4321,
"org": "Example ISP"
}Warum die Unterscheidung für das Kontingent wichtig ist
Das kostenlose Kontingent wird pro Netzwerk gezählt, und dieses Netzwerk ist für jede Adressfamilie anders definiert: Alle IPv4-Adressen innerhalb desselben /24 teilen sich ein Kontingent, und alle IPv6-Adressen innerhalb desselben /48 teilen sich ein Kontingent. Ein einzelner IPv6-Kunde mit einem großen zugewiesenen Block kann in Ihren Logs wie viele verschiedene Adressen aussehen, obwohl er tatsächlich innerhalb eines einzigen gemeinsamen Kontingents liegt. Wenn Sie die Version kennen, können Sie Logeinträge nach der richtigen Art von Netzwerkgrenze gruppieren, statt jede unterschiedliche Adresszeichenkette als unabhängig zu behandeln.
Ein konkreter Fall, in dem das zum Problem wird
Ein Besucher, dessen Internetanschluss zu Hause beide Adressfamilien unterstützt, kann bei zwei Besuchen als zwei scheinbar unabhängige Adressen in Ihren Logs auftauchen, eine IPv4 und eine IPv6, je nachdem, welche sein Gerät an diesem Tag gerade verwendet hat. Naiv betrachtet sieht das wie zwei verschiedene Besucher aus. Wenn Sie nach Version zusammen mit einer stabilen Kennung wie einem Sitzungscookie gruppieren statt allein nach der rohen Adresse, vermeiden Sie aufgeblähte Besucherzahlen und eine Aufteilung der Historie eines Kunden auf zwei Profile.
Praktischer Umgang mit Logs
Wenn Sie eigene Analysen oder Missbrauchserkennung auf Basis roher Logs schreiben, verzweigen Sie anhand des version-Felds, bevor Sie versuchen, ein Netzwerkpräfix zu berechnen, denn eine /24-Maske ergibt auf eine IPv6-Adresse angewendet keinen Sinn, und eine /48-Maske ergibt auf eine IPv4-Adresse angewendet keinen Sinn. Speichern Sie die Version zusammen mit der Adresse selbst, statt sie bei jedem Lesen des Logs erneut durch String-Parsing abzuleiten.
Ein Fehler, den Sie vermeiden sollten
Einen einzigen regulären Ausdruck, der für die IPv4-Punktnotation geschrieben wurde, auf eine Spalte anzuwenden, die auch IPv6-Adressen enthält, ist eine unauffällige Quelle für verworfene oder falsch kategorisierte Logzeilen. Testen Sie jeden Code zum Parsen von Adressen ausdrücklich mit beiden Formaten, einschließlich der verkürzten Notation mit doppeltem Doppelpunkt, die IPv6-Adressen häufig verwenden, statt anzunehmen, dass ein Muster beide Familien abdeckt.
Kosten der Prüfung
Die Version auf diese Weise abzufragen kostet eine Anfrage pro geprüfter Adresse, genau wie jede andere IP-Abfrage. Wenn Sie eine große Logdatei prüfen, senden Sie die Adressen gebündelt per Bulk-POST statt einer Anfrage pro Zeile, bei gleichen Kosten pro Element, aber mit weit weniger Aufrufen.
IPv4 und IPv6 als wirklich getrennte Adressfamilien zu behandeln, nicht nur als unterschiedlich lange Zeichenketten, vermeidet eine ganze Klasse von Fehlern, die erst auftritt, wenn IPv6-Traffic einen nennenswerten Anteil Ihrer Besucher ausmacht. Die Dokumentation zur IPv6-Abfrage beschreibt den Endpunkt vollständig.