सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
अपने लॉग में IPv4 और IPv6 विज़िटरों को अलग पहचानें
203.0.113.42 जैसा पता और 2001:db8::1 जैसा पता साफ़ तौर पर अलग दिखते हैं, लेकिन जब पते किसी लॉग फ़ाइल या डेटाबेस कॉलम में दबे होते हैं, तो एक ही फ़ॉर्मैट मानकर चलने वाली स्क्रिप्ट दूसरे को चुपचाप गलत तरीके से संभाल लेगी।
version फ़ील्ड पढ़ना
/v1/ip एंडपॉइंट हर रिस्पॉन्स में बाकी लोकेशन डेटा के साथ एक version फ़ील्ड लौटाता है, जो 4 या 6 होता है। यह पता करने के लिए कि पता किस फ़ैमिली का है, आपको खुद पते की स्ट्रिंग पार्स करने की ज़रूरत नहीं है।
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"
}कोटे के लिए यह अंतर क्यों मायने रखता है
मुफ़्त कोटा नेटवर्क के हिसाब से गिना जाता है, और हर एड्रेस फ़ैमिली के लिए नेटवर्क की परिभाषा अलग है: एक ही /24 साझा करने वाले सभी IPv4 पते एक कोटा साझा करते हैं, और एक ही /48 साझा करने वाले सभी IPv6 पते एक कोटा साझा करते हैं। बड़े आवंटित ब्लॉक वाला एक अकेला IPv6 ग्राहक आपके लॉग में कई अलग-अलग पतों जैसा दिख सकता है, जबकि वह वास्तव में एक ही साझा कोटे के भीतर होता है, और version जानने से आप लॉग प्रविष्टियों को सही तरह की नेटवर्क सीमा के हिसाब से समूहित कर पाते हैं, बजाय हर अलग पते की स्ट्रिंग को एक-दूसरे से असंबंधित मानने के।
एक ठोस मामला जहाँ यह परेशानी देता है
दोनों एड्रेस फ़ैमिली सपोर्ट करने वाले घरेलू इंटरनेट कनेक्शन वाला विज़िटर दो विज़िट में आपके लॉग में दो असंबंधित दिखने वाले पतों के रूप में आ सकता है, एक IPv4 और एक IPv6, इस पर निर्भर करते हुए कि उस दिन उसके डिवाइस ने संयोग से कौन सा इस्तेमाल किया। बिना सोचे देखने पर यह दो अलग विज़िटर जैसा लगता है। सिर्फ़ कच्चे पते के बजाय version को सेशन कुकी जैसे किसी स्थिर पहचानकर्ता के साथ मिलाकर समूहित करने से आपकी विज़िटर गिनती बढ़ा-चढ़ाकर नहीं दिखती और एक ग्राहक का इतिहास दो प्रोफ़ाइल में नहीं बँटता।
लॉग को व्यावहारिक तरीके से संभालना
जब आप कच्चे लॉग पर अपना एनालिटिक्स या दुरुपयोग पहचान लिखते हैं, तो नेटवर्क प्रीफ़िक्स निकालने की कोशिश से पहले version फ़ील्ड के आधार पर शाखा बनाएँ, क्योंकि IPv6 पते पर /24 मास्क लगाने का कोई मतलब नहीं है और IPv4 पते पर /48 मास्क लगाने का कोई मतलब नहीं है। हर बार लॉग वापस पढ़ते समय स्ट्रिंग पार्स करके version दोबारा निकालने के बजाय उसे पते के साथ ही सहेजें।
एक गलती जिससे बचना चाहिए
IPv4 के डॉट वाले नोटेशन के लिए लिखा गया एक ही regular expression ऐसे कॉलम पर लगाना जिसमें IPv6 पते भी हैं, लॉग की पंक्तियों के छूट जाने या गलत श्रेणी में जाने का एक चुपचाप काम करने वाला स्रोत है। पते पार्स करने वाले किसी भी कोड को दोनों फ़ॉर्मैट पर स्पष्ट रूप से टेस्ट करें, जिसमें वह छोटा डबल-कोलन नोटेशन भी शामिल है जो IPv6 पतों में आम है, बजाय यह मानने के कि एक पैटर्न दोनों फ़ैमिली को कवर कर लेता है।
जाँच की लागत
इस तरह version पता करने की लागत हर जाँचे गए पते के लिए एक अनुरोध है, किसी भी दूसरे IP लुकअप जितनी ही। अगर आप किसी बड़ी लॉग फ़ाइल की जाँच कर रहे हैं, तो हर लाइन के लिए एक अनुरोध के बजाय पतों को बल्क POST से बैच में भेजें, जिससे प्रति आइटम लागत वही रहती है और कॉल बहुत कम होती हैं।
IPv4 और IPv6 को सिर्फ़ अलग लंबाई की स्ट्रिंग नहीं, बल्कि सच में अलग एड्रेस फ़ैमिली मानने से उन बग की एक पूरी श्रेणी से बचा जा सकता है जो तभी सामने आते हैं जब IPv6 ट्रैफ़िक आपके विज़िटर का एक अहम हिस्सा बन जाता है। IPv6 लुकअप दस्तावेज़ में एंडपॉइंट की पूरी जानकारी है।