आप प्रॉक्सी के माध्यम से पार्सर या अकाउंट्स को गर्म कर रहे हैं, पृष्ठों के आकार के अनुसार खर्च का अनुमान लगा रहे हैं - और आपको 2-3 गुना अधिक बिल मिलता है। यह प्रदाता के धोखे की बात नहीं है: ट्रैफ़िक में सब कुछ शामिल होता है जो वास्तव में चैनल के माध्यम से गुजरा है - अनुरोध हेडर, TLS हैंडशेक, कनेक्शन के पुनः प्रयास और सर्विस पैकेट। हम समझते हैं कि ट्रैफ़िक के लिए "चेक" किससे बनता है और बिना गुणवत्ता खोए खर्च को कैसे कम करें।
प्रदाता वास्तव में ट्रैफ़िक को क्या मानता है
जब आप "आंख से" खर्च का आकलन करते हैं, तो आमतौर पर आपके दिमाग में यह सूत्र होता है: HTML पृष्ठ का आकार प्लस चित्र। लेकिन प्रॉक्सी प्रदाता कुल डेटा मात्रा को मानता है, जो चैनल के दोनों दिशाओं के माध्यम से गुजरा है - आउटगोइंग (अनुरोध) और इनकमिंग (उत्तर)। इस मात्रा में न केवल उपयोगी लोड शामिल होता है, बल्कि सभी सर्विस ट्रैफ़िक भी शामिल होता है: प्रोटोकॉल हेडर, TLS मेटाडेटा, TCP ACK पैकेट, टाइमआउट पर कनेक्शन के पुनः प्रयास।
एक सामान्य पृष्ठ के लिए एक अनुरोध के लिए "उपयोगी डेटा" और "सर्विस" का अनुपात 80/20 हो सकता है। लेकिन अगर आप API के साथ काम कर रहे हैं, जहां उत्तर छोटे होते हैं (कुछ किलोबाइट JSON), और हेडर और हैंडशेक बहुत होते हैं - अनुपात आसानी से उलट जाता है। यही कारण है कि आर्बिट्राजर्स, जो विज्ञापन API या मार्केटप्लेस के लिए हजारों छोटे अनुरोध भेजते हैं, अक्सर बिल देखकर आश्चर्यचकित होते हैं: प्रत्येक अनुरोध एक निश्चित "कर" ले जाता है, चाहे उपयोगी लोड का आकार कुछ भी हो।
एक और महत्वपूर्ण बिंदु: प्रदाता ट्रैफ़िक को प्रॉक्सी सर्वर के स्तर पर मानता है, यानी सभी ट्रैफ़िक जो वास्तव में IP के माध्यम से गुजरा है - असफल प्रयास, रीडायरेक्ट, पृष्ठ पर संसाधनों (शैली, स्क्रिप्ट, ट्रैकर्स) के पुनः लोडिंग को शामिल करता है, जिसे आपका स्क्रिप्ट या ब्राउज़र स्वचालित रूप से अनुरोध करता है, भले ही आपको केवल पाठ चाहिए था।
HTTP/HTTPS हेडर: प्रत्येक अनुरोध का छिपा हुआ वजन
प्रत्येक HTTP अनुरोध और प्रत्येक उत्तर एक सेट हेडर ले जाता है: User-Agent, Cookie, Accept-Language, Referer, Content-Type और दर्जनों अन्य। आधुनिक ब्राउज़रों और एंटी-डिटेक्ट उपकरणों (Dolphin Anty, AdsPower, Multilogin) में, हेडर का सेट एक अनुरोध पर 500 बाइट से 2-3 KB तक हो सकता है - विशेष रूप से यदि कुकीज़ में कई मानों के साथ एक सत्र जमा हो गया है।
उदाहरण: यदि आप मार्केटप्लेस API पर 10,000 अनुरोध करते हैं, जिसमें 1.5 KB के सत्र कुकीज़ हैं, तो केवल हेडर पर लगभग 15 MB ट्रैफ़िक खर्च होगा - और यह उत्तर के शरीर को ध्यान में रखे बिना। कई खातों और प्रोफाइल पर स्केलिंग करते समय यह संख्या रैखिक रूप से बढ़ती है।
| हेडर का प्रकार | औसत आकार | ट्रैफ़िक पर प्रभाव |
|---|---|---|
| User-Agent | 100-150 बाइट | कम, लेकिन स्केल पर जमा होता है |
| Cookie (सत्र) | 500-2000 बाइट | लंबे सत्रों में उच्च |
| Referer / Origin | 50-200 बाइट | कम |
| Accept-* हेडर | 150-300 बाइट | कम |
| सर्वर के उत्तर के हेडर | 300-800 बाइट | मध्यम, आप पर निर्भर नहीं है |
व्यावहारिक निष्कर्ष: यदि आप Wildberries या Ozon पर कीमतों की निगरानी के लिए स्क्रिप्ट लिख रहे हैं, तो कुकीज़ को अनुपयोगी मानों से साफ करें और अनुरोध में "सुरक्षित" DevTools से कॉपी किए गए अतिरिक्त हेडर न लाएं।
TLS हैंडशेक: एन्क्रिप्शन कितना ट्रैफ़िक खा जाता है
लगभग सभी आधुनिक वेब HTTPS के माध्यम से काम करता है, जिसका अर्थ है कि प्रत्येक नया कनेक्शन TLS हैंडशेक के साथ शुरू होता है - प्रमाणपत्रों, एन्क्रिप्शन कुंजियों और प्रोटोकॉल पैरामीटर का आदान-प्रदान। एक पूर्ण TLS हैंडशेक (TLS 1.2 या 1.3) साइट के प्रमाणपत्र के आकार और प्रोटोकॉल के उपयोग किए गए एक्सटेंशन के आधार पर 4 से 8 KB के बीच होता है।
यदि आप प्रत्येक अनुरोध पर एक नया कनेक्शन खोलते हैं (और स्थायी कनेक्शन का उपयोग नहीं करते हैं), तो TLS हैंडशेक हर बार दोहराया जाता है। 10,000 अनुरोधों के बिना कनेक्शन का पुनः उपयोग करने पर, आपको केवल एन्क्रिप्शन के लिए अतिरिक्त 40-80 MB ट्रैफ़िक मिलेगा - यह स्वयं उपयोगी सामग्री से अधिक हो सकता है।
TLS 1.3 TLS 1.2 की तुलना में थोड़ी हल्की होती है, क्योंकि इसमें राउंड-ट्रिप की संख्या कम होती है, लेकिन अंतर केवल कई कनेक्शनों की स्थिति में महसूस होता है। मोबाइल प्रॉक्सी के लिए, जहां ऑपरेटर का नेटवर्क अपनी लेटेंसी और सत्रों के पुनः स्थापित करने को जोड़ता है, TLS ओवरहेड विशेष रूप से ध्यान देने योग्य होता है - इसे मोबाइल प्रॉक्सी चुनते समय ध्यान में रखना चाहिए, जब बार-बार छोटे अनुरोधों के साथ काम करना हो।
रिट्राई: कैसे पुनः अनुरोध खर्च को दोगुना करते हैं
रिट्राई - ट्रैफ़िक खर्च का सबसे अदृश्य और सबसे महंगा खंड है। यदि आपका पार्सर या स्क्रिप्ट टाइमआउट या 429/503 त्रुटि पर स्वचालित पुनः प्रयास के लिए सेट है, तो प्रत्येक असफल अनुरोध पहले से ही कनेक्शन स्थापित करने, TLS हैंडशेक और हेडर पर ट्रैफ़िक खर्च कर चुका है - और फिर यह प्रक्रिया फिर से दोहराई जाती है।
SMM और मार्केटप्लेस पार्सिंग में स्वचालन में एक सामान्य गलती - बिना एक्सपोनेंशियल डिले के आक्रामक रिट्राई नीति: स्क्रिप्ट पहले ही आईपी ब्लॉक के पहले संकेत पर एक सेकंड के अंतराल के साथ 5 प्रयास करती है। परिणामस्वरूप, एक "उपयोगी" उत्तर के लिए पांच असफल प्रयासों का ट्रैफ़िक और अंतिम सफल अनुरोध का ट्रैफ़िक खर्च होता है।
यह विशेष रूप से डेटा सेंटर-प्रॉक्सी के साथ उन साइटों पर महत्वपूर्ण है जिनकी सुरक्षा आक्रामक होती है (जैसे, Avito या बड़े मार्केटप्लेस), जो "गर्म" IP से अधिकांश अनुरोधों पर कैप्चा या ब्लॉक वापस कर सकते हैं। इस मामले में, रिसिडेंशियल प्रॉक्सी पर विचार करना समझदारी है - वे पहले अनुरोध से ब्लॉक होने की संभावना कम होती है, जिससे रिट्राई की संख्या कम होती है और, तदनुसार, वास्तविक ट्रैफ़िक खर्च कम होता है।
कीप-एलाइव बनाम नए कनेक्शन
HTTP कीप-एलाइव कई अनुरोधों के लिए एक ही TCP/TLS कनेक्शन का पुनः उपयोग करने की अनुमति देता है, जिससे पुनः हैंडशेक से बचा जा सकता है। यह ट्रैफ़िक की सबसे प्रभावी अनुकूलन विधियों में से एक है, जो लगभग सभी HTTP क्लाइंट और एंटी-डिटेक्ट ब्राउज़रों में उपलब्ध है।
यदि आप पार्सिंग के लिए पुस्तकालयों का उपयोग कर रहे हैं (requests, httpx, axios) बिना स्थायी कनेक्शन के साथ सत्र को स्पष्ट रूप से निर्दिष्ट किए, तो प्रत्येक अनुरोध डिफ़ॉल्ट रूप से एक नया TCP कनेक्शन खोल सकता है। प्रॉक्सी के साथ यह मतलब है: प्रॉक्सी सर्वर तक नया कनेक्शन, लक्षित साइट तक नया TLS, और सभी ओवरहेड प्रत्येक कॉल पर दोहराया जाता है।
| कनेक्शन मोड | 1000 अनुरोधों पर ओवरहेड |
|---|---|
| प्रत्येक अनुरोध के लिए नया कनेक्शन | 4-8 MB (केवल TLS) |
| कीप-एलाइव, 50 अनुरोधों के लिए एक सत्र | 0.1-0.2 MB (एक समूह पर एक हैंडशेक) |
अंतर कई गुना है - और यह किसी भी उपयोगी लोड के बिना ट्रैफ़िक की शुद्ध बचत है।
विभिन्न प्रकार के प्रॉक्सी ट्रैफ़िक को कैसे मानते हैं
ट्रैफ़िक बिलिंग का मॉडल प्रॉक्सी के प्रकार पर निर्भर करता है। डेटा सेंटर प्रॉक्सी में अक्सर ट्रैफ़िक के आकार या IP/पोर्ट की संख्या के अनुसार टैरिफ होता है - स्वयं बुनियादी ढांचा तेज होता है और रूटिंग पर न्यूनतम ओवरहेड जोड़ता है। रेजिडेंशियल और मोबाइल प्रॉक्सी में ट्रैफ़िक आमतौर पर अधिक सख्ती से टैरिफ किया जाता है, क्योंकि उपयोगकर्ताओं के वास्तविक IP अधिक महंगे और सीमित संसाधन होते हैं, और ऑपरेटर या घरेलू प्रदाता के माध्यम से मार्ग में अतिरिक्त हॉप और, तदनुसार, थोड़े अधिक सर्विस डेटा शामिल होते हैं।
इस संदर्भ में, मोबाइल प्रॉक्सी ट्रैफ़िक के लिए सबसे "महंगे" होते हैं: सेलुलर नेटवर्क अपने सत्रों के पुनः स्थापित करने, NAT ट्रांसलेशन और कभी-कभी ऑपरेटर स्तर पर ट्रैफ़िक को संकुचित/अनपैक करने के अपने तंत्र जोड़ते हैं, जो एक ही अनुरोध के मुकाबले डेटा की मात्रा को बढ़ाते हैं।
यदि कार्य - न्यूनतम ओवरहेड के साथ स्थिर उच्च मात्रा में अनुरोध (जैसे, Wildberries या Ozon पर कीमतों का बड़े पैमाने पर पार्सिंग) है, तो इसके लिए डेटा सेंटर प्रॉक्सी सबसे उपयुक्त हैं - वे तेज और समान कार्यों पर ट्रैफ़िक खर्च के लिए अधिक पूर्वानुमानित होते हैं।
व्यवहार में ट्रैफ़िक खर्च को कैसे कम करें
हम विशिष्ट कदमों की जांच करेंगे, जो पार्सर, स्वचालन या मल्टी-एकाउंटिंग की कार्यक्षमता खोए बिना वास्तविक ट्रैफ़िक खर्च को कम करते हैं।
1. अनावश्यक संसाधनों को लोड करना बंद करें। यदि आपको केवल पृष्ठ का पाठ या API का JSON उत्तर चाहिए, तो एंटी-डिटेक्ट ब्राउज़र या हेडलेस उपकरण की सेटिंग्स में चित्रों, फ़ॉन्ट्स, विश्लेषणात्मक स्क्रिप्टों और विज्ञापन ट्रैकर्स को लोड करना बंद करें। यह अक्सर पार्सिंग कार्यों के लिए ट्रैफ़िक खर्च को 60-80% तक कम करता है।
2. कीप-एलाइव और कनेक्शन पूल का उपयोग करें। एक होस्ट के लिए समूह अनुरोधों के लिए सत्र के पुनः उपयोग के लिए HTTP क्लाइंट को सेट करें - यह TLS हैंडशेक की संख्या को तेजी से कम करता है।
3. रिट्राई की एक समझदारी नीति सेट करें। एक्सपोनेंशियल डिले (1 सेकंड → 2 सेकंड → 4 सेकंड) के साथ 3 प्रयासों की सीमा, आक्रामक 5-10 प्रयासों के बजाय, असफल अनुरोधों से बेकार ट्रैफ़िक को कम करती है और एक साथ आईपी के अतिरिक्त ब्लॉक होने के जोखिम को भी कम करती है।
4. कुकीज़ और सत्र हेडर को साफ करें। समय-समय पर उन कुकीज़ के जमा मानों को हटा दें, जो लक्षित साइट द्वारा उपयोग नहीं की जाती हैं - विशेष रूप से Instagram या TikTok पर अकाउंट्स को गर्म करने के लिए लंबे सत्रों के लिए प्रासंगिक है, एंटी-डिटेक्ट ब्राउज़रों के माध्यम से।
5. स्थिर उत्तरों को कैश करें। यदि डेटा (जैसे, उत्पादों की सूची) हर मिनट नहीं बदलता है, तो प्रत्येक निगरानी चक्र में प्रॉक्सी के माध्यम से पुनः अनुरोध करने के बजाय उत्तर को स्थानीय रूप से कैश करें।
6. संकुचन का उपयोग करें। सुनिश्चित करें कि Accept-Encoding: gzip हेडर भेजा जाता है और सर्वर वास्तव में संकुचित उत्तर देता है - यह उन पृष्ठों पर आने वाले ट्रैफ़िक की मात्रा को कम करता है जिनमें बहुत अधिक पाठ या JSON होता है।
ट्रैफ़िक की निगरानी के लिए उपकरण
यह समझने के लिए कि ट्रैफ़िक वास्तव में कहाँ जा रहा है, प्रदाता के काउंटर पर ही नहीं, बल्कि अनुरोधों के विस्तृत विभाजन पर भी ध्यान देना उपयोगी है। इसके लिए उपयुक्त हैं:
- चार्ल्स प्रॉक्सी / फिडलर - प्रत्येक अनुरोध और उत्तर का आकार दिखाते हैं, जिसमें हेडर शामिल हैं, जो "भारी" कुकीज़ या अनावश्यक संसाधनों को खोजने में मदद करते हैं।
- वायरशार्क - यदि आपको हैंडशेक का वास्तविक वजन आकलन करने की आवश्यकता है, तो पैकेट स्तर पर TCP/TLS ओवरहेड का गहरा विश्लेषण करने के लिए।
- एंटी-डिटेक्ट ब्राउज़रों में अंतर्निहित ट्रैफ़िक काउंटर (Dolphin Anty, AdsPower, GoLogin) - कई प्रत्येक प्रोफाइल के लिए अलग-अलग खर्च दिखाते हैं, जो खातों के बीच बजट वितरित करने के लिए सुविधाजनक है।
- HTTP क्लाइंट स्तर पर लॉगिंग - अपने स्वयं के पार्सिंग स्क्रिप्ट लिखते समय, प्रत्येक कॉल के लिए अनुरोध/उत्तर का आकार लॉग करना उपयोगी होता है, ताकि विसंगतियों को खोजा जा सके।
आपके उपकरणों के मापों की तुलना प्रॉक्सी प्रदाता के काउंटर से यह जल्दी समझने में मदद करती है कि ट्रैफ़िक कहाँ खो रहा है - रिट्राई, TLS या अनावश्यक संसाधनों के लोड में।
शुरू करने से पहले अनुकूलन की चेकलिस्ट
पार्सर, SMM स्वचालन या विज्ञापन खातों को गर्म करने के बड़े पैमाने पर लॉन्च से पहले, एक संक्षिप्त सूची पर जाएं:
- जहां आवश्यक नहीं है, वहां चित्रों, फ़ॉन्ट्स, विश्लेषण को लोड करना बंद किया गया है;
- एक होस्ट के लिए श्रृंखला अनुरोधों के लिए कीप-एलाइव / सत्र पुनः उपयोग सेट किया गया है;
- रिट्राई नीति 2-3 प्रयासों के साथ सीमित है, न कि अनंत पुनरावृत्ति;
- सत्र कुकीज़ समय-समय पर अनुपयोगी मानों से साफ की जाती हैं;
- उत्तर (gzip/deflate/br) के लिए संकुचन सक्षम है;
- दोहराए जाने वाले स्थिर अनुरोधों के लिए स्थानीय कैशिंग है;
- कार्य के लिए प्रॉक्सी का प्रकार चुना गया है: गति और मात्रा के लिए डेटा सेंटर, ब्लॉकों को बायपास करने के लिए रेजिडेंशियल, सोशल मीडिया और विज्ञापन प्लेटफार्मों के लिए मोबाइल।
निष्कर्ष
प्रॉक्सी के माध्यम से ट्रैफ़िक खर्च केवल पृष्ठ के उपयोगी डेटा नहीं होते हैं, बल्कि सभी सर्विस ओवरहेड भी होते हैं: हेडर, TLS हैंडशेक, त्रुटियों पर पुनः प्रयास। इस तंत्र को समझना आपको प्रॉक्सी पर बजट की योजना बनाने में अधिक सटीकता से मदद करता है और विशेष रूप से मार्केटप्लेस पार्सिंग, SMM स्वचालन या विज्ञापन खातों को गर्म करने के दौरान अप्रिय आश्चर्य से बचने में मदद करता है।
यदि आपका कार्य स्थिर पार्सिंग के साथ पूर्वानुमानित ट्रैफ़िक खर्च है, तो डेटा सेंटर प्रॉक्सी पर ध्यान दें। सोशल मीडिया और विज्ञापन प्लेटफार्मों के साथ काम करने के लिए, जहां ब्लॉकों की कम आवृत्ति महत्वपूर्ण है, मोबाइल प्रॉक्सी अधिक उपयुक्त हैं। और यदि साइटों की सुरक्षा को बायपास करने के लिए गुमनामी और स्थिरता के बीच संतुलन की आवश्यकता है - रेसिडेंशियल प्रॉक्सी पर विचार करें, जो अधिक दुर्लभ ब्लॉकों के कारण रिट्राई की संख्या को कम करते हैं।