أنت تقوم بتشغيل محلل أو تسخين حسابات عبر البروكسي، وتحسب الاستهلاك بناءً على حجم الصفحات - وتحصل على فاتورة أكبر بـ 2-3 مرات مما كنت تتوقع. الأمر ليس خداعًا من المزود: يتم تضمين كل ما مر فعليًا عبر القناة في حركة المرور - رؤوس الطلبات، مصافحة TLS، إعادة المحاولات، وحزم الخدمة. نحلل مما يتكون "الفاتورة" لحركة المرور وكيفية تقليل الاستهلاك دون فقدان جودة العمل.
ما الذي يعتبره المزود حركة مرور في الواقع
عندما تقوم بتقدير الاستهلاك "بالعين"، عادة ما يكون في ذهنك صيغة: حجم صفحة HTML بالإضافة إلى الصور. لكن مزود البروكسي يحسب الحجم الإجمالي للبيانات التي مرت عبر كلا الاتجاهين للقناة - الصادر (الطلب) والوارِد (الاستجابة). يتضمن هذا الحجم ليس فقط الحمولة المفيدة، ولكن أيضًا كل حركة المرور الخدمية: رؤوس البروتوكول، بيانات التعريف TLS، حزم ACK TCP، وإعادة المحاولات عند انتهاء المهلة.
بالنسبة لطلب واحد إلى صفحة عادية، يمكن أن يكون نسبة "البيانات المفيدة" إلى "الخدمية" 80/20. ولكن إذا كنت تعمل مع API، حيث تكون الاستجابات صغيرة (بضع كيلوبايت من JSON)، والكثير من الرؤوس والمصافحات - فإن النسبة يمكن أن تنقلب بسهولة. لهذا السبب، غالبًا ما يتفاجأ الوسطاء الذين يقومون بإرسال عشرات الآلاف من الطلبات الصغيرة إلى APIs الإعلانات أو الأسواق بفواتيرهم: كل طلب يحمل "ضريبة" ثابتة بغض النظر عن حجم الحمولة المفيدة.
نقطة مهمة أخرى: يعتبر المزود حركة المرور على مستوى خادم البروكسي، أي أن كل حركة المرور التي مرت فعليًا عبر IP - بما في ذلك المحاولات الفاشلة، وإعادة التوجيه، وإعادة تحميل الموارد على الصفحة (الأنماط، السكربتات، المتعقبين) التي طلبها سكربتك أو متصفحك تلقائيًا، حتى لو كنت بحاجة فقط إلى النص.
رؤوس HTTP/HTTPS: الوزن الخفي لكل طلب
كل طلب HTTP وكل استجابة تحمل مجموعة من الرؤوس: User-Agent، Cookie، Accept-Language، Referer، Content-Type وعشرات أخرى. في المتصفحات الحديثة وأدوات مكافحة الكشف (Dolphin Anty، AdsPower، Multilogin) يمكن أن تشغل مجموعة الرؤوس من 500 بايت إلى 2-3 كيلوبايت لكل طلب - خاصة إذا كانت الكوكيز تحتوي على جلسة مع عشرات القيم.
مثال: إذا قمت بعمل 10,000 طلب إلى API سوق مع كوكيز جلسة بحجم 1.5 كيلوبايت، فإن حوالي 15 ميغابايت من حركة المرور ستذهب فقط إلى الرؤوس - وهذا دون احتساب جسم الاستجابة. عند التوسع على عدة حسابات وملفات تعريف، يرتفع هذا الرقم بشكل خطي.
| نوع الرأس | الحجم المتوسط | التأثير على حركة المرور |
|---|---|---|
| User-Agent | 100-150 بايت | منخفض، لكنه يتراكم عند التوسع |
| Cookie (جلسة) | 500-2000 بايت | مرتفع في الجلسات الطويلة |
| Referer / Origin | 50-200 بايت | منخفض |
| رؤوس Accept-* | 150-300 بايت | منخفض |
| رؤوس استجابة الخادم | 300-800 بايت | متوسط، لا يعتمد عليك |
الاستنتاج العملي: إذا كنت تكتب سكربت لمراقبة الأسعار على Wildberries أو Ozon، قم بتنظيف الكوكيز من القيم غير المستخدمة ولا تسحب في الطلب رؤوسًا زائدة تم نسخها "لأي طارئ" من أدوات المطور في المتصفح.
مصافحة TLS: كم من حركة المرور تستهلكها التشفير
يعمل معظم الويب الحديث عبر HTTPS، مما يعني أن كل اتصال جديد يبدأ بمصافحة TLS - تبادل الشهادات، مفاتيح التشفير، ومعلمات البروتوكول. تزن مصافحة TLS كاملة واحدة (TLS 1.2 أو 1.3) من 4 إلى 8 كيلوبايت اعتمادًا على حجم شهادة الموقع والامتدادات المستخدمة في البروتوكول.
إذا كنت تفتح اتصالًا جديدًا لكل طلب (ولم تستخدم اتصالًا دائمًا)، تتكرر مصافحة TLS في كل مرة. عند إجراء 10,000 طلب دون إعادة استخدام الاتصال، ستحصل على 40-80 ميغابايت إضافية من حركة المرور فقط للتشفير - قد يكون هذا أكثر من المحتوى المفيد نفسه.
TLS 1.3 أخف قليلاً من TLS 1.2 بسبب تقليل عدد الرحلات، لكن الفرق ملحوظ فقط عند وجود عدد كبير من الاتصالات. بالنسبة للبروكسيات المحمولة، حيث تضيف الشبكة الخاصة بالمشغل تأخيرها الخاص وإعادة تثبيت الجلسات، فإن عبء TLS يكون ملحوظًا بشكل خاص - يجب أخذ ذلك في الاعتبار عند اختيار بروكسيات محمولة للمهام ذات الطلبات القصيرة المتكررة.
إعادة المحاولات: كيف تضاعف الطلبات المتكررة الاستهلاك
إعادة المحاولات هي أكثر فئات استهلاك حركة المرور خفية والأكثر تكلفة. إذا كان محللك أو سكربتك معدًا على إعادة المحاولة تلقائيًا عند انتهاء المهلة أو خطأ 429/503، فإن كل طلب فاشل قد استهلك بالفعل حركة المرور لإقامة الاتصال، مصافحة TLS، والرؤوس - ثم يتكرر كل هذا العملية مرة أخرى.
خطأ شائع في أتمتة SMM وتحليل الأسواق هو سياسة إعادة المحاولات العدوانية دون تأخير أسي: يقوم السكربت بعمل 5 محاولات متتالية بفاصل زمني قدره ثانية واحدة عند أول علامة على حظر IP. ونتيجة لذلك، يتم استهلاك حركة المرور لرد واحد "مفيد" من خمس محاولات فاشلة بالإضافة إلى الطلب الناجح النهائي.
هذا الأمر حرج بشكل خاص عند العمل مع بروكسيات مراكز البيانات على مواقع الويب ذات الحماية العدوانية (مثل Avito أو الأسواق الكبيرة)، التي قد تعيد CAPTCHA أو حظر معظم الطلبات من IP "ساخن". في هذه الحالة، من المنطقي النظر إلى بروكسيات سكنية - فهي نادرًا ما تتعرض للحظر من الطلب الأول، مما يقلل من عدد إعادة المحاولات وبالتالي الاستهلاك الفعلي لحركة المرور.
Keep-Alive مقابل الاتصالات الجديدة
يسمح HTTP Keep-Alive بإعادة استخدام اتصال TCP/TLS واحد لعدة طلبات متتالية، مما يتجنب إعادة المصافحة. هذه واحدة من أكثر تحسينات حركة المرور فعالية المتاحة تقريبًا في جميع عملاء HTTP ومتصفحات مكافحة الكشف.
إذا كنت تستخدم مكتبات للتحليل (requests، httpx، axios) دون تحديد صريح لجلسة مع اتصال دائم، فإن كل طلب بشكل افتراضي يمكن أن يفتح اتصال TCP جديد. في حالة استخدام البروكسي، يعني ذلك: اتصال جديد إلى خادم البروكسي، وTLS جديدة إلى الموقع المستهدف، ويتكرر كل العبء في كل استدعاء.
| وضع الاتصال | العبء على 1000 طلب |
|---|---|
| اتصال جديد لكل طلب | 4-8 ميغابايت (فقط TLS) |
| Keep-Alive، جلسة واحدة لـ 50 طلبًا | 0.1-0.2 ميغابايت (مصافحة واحدة لمجموعة) |
الفرق كبير - وهذه هي توفير حركة المرور النقي دون أي تغيير في الحمولة المفيدة للطلبات.
كيف تحسب حركة المرور أنواع البروكسي المختلفة
تعتمد نموذج فواتير حركة المرور على نوع البروكسي. غالبًا ما يتم العثور على تسعير حركة المرور في بروكسيات مراكز البيانات بناءً على حجم حركة المرور أو عدد IP/المنافذ - البنية التحتية نفسها أسرع وتضيف عبءًا ضئيلًا على التوجيه. بالنسبة للبروكسيات السكنية والمحمولة، عادةً ما يتم تسعير حركة المرور بشكل أكثر صرامة، لأن IPs الحقيقية للمستخدمين هي مورد أكثر تكلفة ومحدود، بينما يضيف المسار عبر المشغل أو مزود الخدمة المنزلية إضافات إضافية، وبالتالي المزيد من البيانات الخدمية.
تعتبر البروكسيات المحمولة في هذا الصدد "الأغلى" من حيث حركة المرور: تضيف الشبكات الخلوية آلياتها الخاصة لإعادة تثبيت الجلسة، وترجمة NAT، وأحيانًا ضغط/فك ضغط حركة المرور على مستوى المشغل، مما يزيد من عداد البيانات المارة مقارنةً بنفس الطلب عبر شبكة ثابتة.
إذا كانت المهمة هي حجم ثابت من الطلبات العالية مع الحد الأدنى من العبء (مثل تحليل أسعار Wildberries أو Ozon بشكل جماعي)، فإن بروكسيات مراكز البيانات هي الأنسب - فهي أسرع وأكثر توقعًا من حيث استهلاك حركة المرور في المهام المماثلة.
كيف تقلل استهلاك حركة المرور في الممارسة العملية
دعونا نستعرض خطوات محددة تقلل من الاستهلاك الفعلي لحركة المرور دون فقدان وظائف المحلل، الأتمتة، أو تعدد الحسابات.
1. قم بإيقاف تحميل الموارد غير الضرورية. إذا كنت بحاجة فقط إلى نص الصفحة أو استجابة JSON من API، قم بإيقاف تحميل الصور، الخطوط، السكربتات التحليلية، والمتعقبين الإعلانيين في إعدادات متصفح مكافحة الكشف أو الأداة غير المرئية. غالبًا ما يقلل هذا من استهلاك حركة المرور بنسبة 60-80% لمهام التحليل.
2. استخدم Keep-Alive ومجموعة الاتصالات. قم بإعداد عميل HTTP لإعادة استخدام الجلسة لمجموعة من الطلبات إلى مضيف واحد - هذا يقلل بشكل حاد من عدد مصافحات TLS.
3. قم بإعداد سياسة معقولة لإعادة المحاولات. تأخير أسي (1 ثانية → 2 ثانية → 4 ثوانٍ) مع حد أقصى من 3 محاولات بدلاً من 5-10 محاولات متتالية العدوانية يقلل من حركة المرور غير المفيدة الناتجة عن الطلبات الفاشلة ويقلل في الوقت نفسه من خطر حظر IP إضافي.
4. قم بتنظيف الكوكيز والرؤوس الخاصة بالجلسة. قم بإزالة القيم المتراكمة للكوكيز التي لا تستخدمها الصفحة المستهدفة بشكل دوري - وهذا مهم بشكل خاص للجلسات الطويلة لتسخين الحسابات على Instagram أو TikTok عبر متصفحات مكافحة الكشف.
5. قم بتخزين الاستجابات الثابتة في الذاكرة المؤقتة. إذا كانت البيانات (مثل كتالوج المنتجات) لا تتغير كل دقيقة، قم بتخزين الاستجابة محليًا بدلاً من إعادة الطلب عبر البروكسي في كل دورة مراقبة.
6. استخدم الضغط. تحقق من أن رأس Accept-Encoding: gzip يتم تمريره وأن الخادم يقدم استجابة مضغوطة بالفعل - هذا يقلل من حجم حركة المرور الواردة على الصفحات التي تحتوي على الكثير من النصوص أو JSON.
أدوات لمراقبة حركة المرور
لفهم أين تذهب حركة المرور فعليًا، من المفيد النظر ليس فقط إلى عداد المزود، ولكن أيضًا إلى تحليل تفصيلي للطلبات. الأدوات المناسبة لذلك تشمل:
- Charles Proxy / Fiddler - يظهران حجم كل طلب واستجابة، بما في ذلك الرؤوس، مما يساعد على العثور على الكوكيز "الثقيلة" أو الموارد الزائدة.
- Wireshark - لتحليل عميق لعبء TCP/TLS على مستوى الحزم، إذا كنت بحاجة إلى تقييم الوزن الفعلي للمصافحة.
- عدادات حركة المرور المدمجة في متصفحات مكافحة الكشف (Dolphin Anty، AdsPower، GoLogin) - العديد منها يظهر الاستهلاك لكل ملف تعريف على حدة، مما يسهل توزيع الميزانية بين الحسابات.
- تسجيل على مستوى عميل HTTP - عند كتابة سكربتات التحليل الخاصة بك، من المفيد تسجيل حجم الطلب/الاستجابة لكل استدعاء، للعثور على الشذوذات.
يساعد مقارنة قراءات أدواتك مع عداد مزود البروكسي على فهم سريع لمكان فقدان حركة المرور - في إعادة المحاولات، TLS، أو تحميل الموارد الزائدة.
قائمة التحقق من التحسين قبل التشغيل
قبل بدء تشغيل محلل بشكل كبير، أو أتمتة SMM، أو تسخين حسابات الإعلانات، مر عبر قائمة قصيرة:
- تم إيقاف تحميل الصور، الخطوط، التحليلات حيث لا تكون ضرورية؛
- تم إعداد Keep-Alive / إعادة استخدام الجلسة لمجموعة من الطلبات إلى مضيف واحد؛
- تم تحديد سياسة إعادة المحاولات بحد أقصى 2-3 محاولات مع تأخير، وليس تكرارًا لا نهائيًا؛
- يتم تنظيف الكوكيز الخاصة بالجلسة بشكل دوري من القيم غير المستخدمة؛
- تم تفعيل ضغط الاستجابات (gzip/deflate/br)؛
- يوجد تخزين مؤقت محلي للطلبات الثابتة المتكررة؛
- تم اختيار نوع البروكسي وفقًا للمهمة: مركز البيانات للسرعة والحجم، السكنية لتجاوز الحظر، المحمولة لوسائل التواصل الاجتماعي ومنصات الإعلانات.
الخاتمة
استهلاك حركة المرور عبر البروكسي ليس فقط البيانات المفيدة للصفحة، ولكن أيضًا كل العبء الخدمي: الرؤوس، مصافحات TLS، وإعادة المحاولات عند الأخطاء. فهم هذه الآلية يسمح بالتخطيط بشكل أكثر دقة للميزانية على البروكسي وتجنب المفاجآت غير السارة في الفاتورة، خاصة عند توسيع تحليل الأسواق، أتمتة SMM، أو تسخين حسابات الإعلانات.
إذا كانت مهمتك هي تحليل ثابت مع استهلاك حركة مرور متوقع، فانتبه إلى بروكسيات مراكز البيانات. للعمل مع وسائل التواصل الاجتماعي ومنصات الإعلانات، حيث تكون تكرار الحظر منخفضًا، فإن البروكسيات المحمولة هي الأنسب. وإذا كنت بحاجة إلى توازن بين الخصوصية والاستقرار لتجاوز حماية المواقع - فكر في البروكسيات السكنية، التي تقلل من عدد إعادة المحاولات بسبب الحظر الأقل تكرارًا.