شما یک پارسر را راهاندازی میکنید یا حسابها را از طریق پروکسی گرم میکنید، مصرف را بر اساس اندازه صفحات محاسبه میکنید — و صورتحسابی ۲-۳ برابر بیشتر از انتظار دریافت میکنید. مشکل از فریب ارائهدهنده نیست: در ترافیک همه چیزهایی که واقعاً از طریق کانال عبور کرده است، شامل میشود — هدرهای درخواست، handshake TLS، تلاشهای مجدد برای اتصال و بستههای کنترلی. بررسی میکنیم که «صورتحساب» ترافیک چگونه تشکیل میشود و چگونه مصرف را بدون کاهش کیفیت کار کاهش دهیم.
آنچه ارائهدهنده واقعاً به عنوان ترافیک محاسبه میکند
وقتی شما مصرف را «به چشم» ارزیابی میکنید، معمولاً فرمولی در ذهن دارید: اندازه صفحه HTML به علاوه تصاویر. اما ارائهدهنده پروکسی حجم کل دادههایی که از هر دو سمت کانال عبور کرده است — خروجی (درخواست) و ورودی (پاسخ) — را محاسبه میکند. این حجم شامل تنها بار مفید نیست، بلکه تمام ترافیک کنترلی نیز شامل میشود: هدرهای پروتکل، متادادههای TLS، بستههای ACK TCP، تلاشهای مجدد برای اتصال در صورت تایماوتها.
برای یک درخواست به یک صفحه عادی نسبت «دادههای مفید» به «کنترلی» میتواند ۸۰/۲۰ باشد. اما اگر شما با API کار میکنید که پاسخهای کوچکی (چند کیلوبایت JSON) دارد و هدرها و handshakeهای زیادی وجود دارد — نسبت به راحتی معکوس میشود. به همین دلیل است که آربیتراژکنندگان که دهها هزار درخواست کوچک به APIهای تبلیغاتی یا بازارها ارسال میکنند، اغلب از صورتحساب شگفتزده میشوند: هر درخواست یک «مالیات» ثابت را به همراه دارد، صرف نظر از اندازه بار مفید.
نکته مهم دیگر: ارائهدهنده ترافیک را در سطح سرور پروکسی محاسبه میکند، یعنی تمام ترافیکی که واقعاً از طریق IP عبور کرده است — شامل تلاشهای ناموفق، ریدایرکتها، بارگذاری مجدد منابع در صفحه (استایلها، اسکریپتها، ردیابها) که اسکریپت یا مرورگر شما به طور خودکار درخواست کرده است، حتی اگر شما فقط به متن نیاز داشته باشید.
هدرهای HTTP/HTTPS: وزن پنهان هر درخواست
هر درخواست HTTP و هر پاسخ شامل مجموعهای از هدرها است: User-Agent، Cookie، Accept-Language، Referer، Content-Type و دهها مورد دیگر. در مرورگرهای مدرن و ابزارهای ضد شناسایی (Dolphin Anty، AdsPower، Multilogin) مجموعه هدرها میتواند از ۵۰۰ بایت تا ۲-۳ کیلوبایت برای هر درخواست باشد — به ویژه اگر در کوکیها یک جلسه با دهها مقدار انباشته شده باشد.
مثال: اگر شما ۱۰,۰۰۰ درخواست به API یک بازار با کوکیهای جلسه به اندازه ۱.۵ کیلوبایت ارسال کنید، تنها برای هدرها حدود ۱۵ مگابایت ترافیک مصرف میشود — و این بدون احتساب بدنه پاسخ. با مقیاسگذاری به چند حساب و پروفایل، این عدد به صورت خطی افزایش مییابد.
| نوع هدر | اندازه متوسط | تأثیر بر ترافیک |
|---|---|---|
| User-Agent | ۱۰۰-۱۵۰ بایت | کم، اما در مقیاس انباشته میشود |
| Cookie (جلسه) | ۵۰۰-۲۰۰۰ بایت | بالا در جلسات طولانی |
| Referer / Origin | ۵۰-۲۰۰ بایت | کم |
| Accept-* هدرها | ۱۵۰-۳۰۰ بایت | کم |
| هدرهای پاسخ سرور | ۳۰۰-۸۰۰ بایت | متوسط، به شما وابسته نیست |
نتیجه عملی: اگر شما اسکریپتی برای نظارت بر قیمتها در Wildberries یا Ozon مینویسید، کوکیها را از مقادیر غیرقابل استفاده پاک کنید و هدرهای اضافی که «به هر دلیلی» از DevTools مرورگر کپی شدهاند، در درخواستها نیاورید.
TLS handshake: چقدر ترافیک توسط رمزگذاری مصرف میشود
تقریباً تمام وب مدرن از طریق HTTPS کار میکند، به این معنی که هر اتصال جدید با TLS handshake شروع میشود — تبادل گواهیها، کلیدهای رمزگذاری و پارامترهای پروتکل. یک TLS handshake کامل (TLS 1.2 یا 1.3) از ۴ تا ۸ کیلوبایت وزن دارد که به اندازه گواهی سایت و افزونههای پروتکل بستگی دارد.
اگر شما برای هر درخواست یک اتصال جدید باز کنید (و از اتصال دائمی استفاده نکنید)، TLS handshake هر بار تکرار میشود. با ۱۰,۰۰۰ درخواست بدون استفاده مجدد از اتصال، شما ۴۰-۸۰ مگابایت ترافیک اضافی فقط برای رمزگذاری دریافت میکنید — این ممکن است بیشتر از محتوای مفید خود باشد.
TLS 1.3 کمی سبکتر از TLS 1.2 است به دلیل کاهش تعداد round-trip، اما تفاوت فقط در تعداد زیاد اتصالات قابل توجه است. برای پروکسیهای موبایل، جایی که خود شبکه اپراتور تأخیر و بازنشانی جلسات را اضافه میکند، overhead TLS به ویژه قابل توجه است — این نکته را هنگام انتخاب پروکسیهای موبایل برای وظایف با درخواستهای کوتاه و مکرر در نظر داشته باشید.
Retries: چگونه درخواستهای تکراری مصرف را دو برابر میکنند
Retries — پرهزینهترین و نامحسوسترین بخش مصرف ترافیک است. اگر پارسر یا اسکریپت شما برای تکرار خودکار در صورت تایماوت یا خطای ۴۲۹/۵۰۳ تنظیم شده باشد، هر درخواست ناموفق قبلاً ترافیک را برای برقراری اتصال، TLS handshake و هدرها مصرف کرده است — و سپس تمام این فرآیند دوباره تکرار میشود.
یک خطای رایج در اتوماسیون SMM و پارس کردن بازارها — سیاست تکرار تهاجمی بدون تأخیر نمایی: اسکریپت ۵ تلاش متوالی با فاصله یک ثانیه در اولین نشانهای از مسدود شدن IP انجام میدهد. در نتیجه، برای یک پاسخ «مفید» ترافیک پنج تلاش ناموفق و همچنین درخواست موفق نهایی مصرف میشود.
این موضوع به ویژه در کار با پروکسیهای دیتاسنتر در سایتهای با حفاظت تهاجمی (مانند Avito یا بازارهای بزرگ) که ممکن است CAPTCHA یا مسدودیت را برای اکثر درخواستها با IP «داغ» برگردانند، بحرانی است. در این مورد، منطقی است که به پروکسیهای مسکونی نگاه کنید — آنها کمتر تحت مسدودیت قرار میگیرند و به همین دلیل تعداد retries را کاهش میدهند و در نتیجه مصرف واقعی ترافیک را کاهش میدهند.
Keep-Alive در مقابل اتصالات جدید
HTTP Keep-Alive اجازه میدهد تا یک اتصال TCP/TLS برای چندین درخواست متوالی دوباره استفاده شود و از handshake مجدد جلوگیری کند. این یکی از مؤثرترین بهینهسازیهای ترافیک است که تقریباً در تمام کلاینتهای HTTP و مرورگرهای ضد شناسایی در دسترس است.
اگر شما از کتابخانهها برای پارس کردن (requests، httpx، axios) بدون مشخص کردن صریح جلسه با اتصال دائمی استفاده کنید، هر درخواست به طور پیشفرض ممکن است یک اتصال TCP جدید باز کند. در ارتباط با پروکسی، این به این معنی است: یک اتصال جدید به سرور پروکسی، یک TLS جدید به سایت هدف، و تمام overhead برای هر فراخوانی تکرار میشود.
| حالت اتصال | Overhead برای ۱۰۰۰ درخواست |
|---|---|
| اتصال جدید برای هر درخواست | ۴-۸ مگابایت (فقط TLS) |
| Keep-Alive، یک جلسه برای ۵۰ درخواست | ۰.۱-۰.۲ مگابایت (یک handshake برای گروه) |
تفاوت به شدت زیاد است — و این صرفهجویی خالص در ترافیک بدون هیچگونه تغییری در بار مفید درخواستها است.
چگونه انواع مختلف پروکسی ترافیک را محاسبه میکنند
مدل صورتحساب ترافیک به نوع پروکسی بستگی دارد. در پروکسیهای دیتاسنتر، معمولاً تعرفهگذاری بر اساس حجم ترافیک یا تعداد IP/پورتها وجود دارد — زیرساخت خود سریعتر است و حداقل overhead را برای مسیریابی اضافه میکند. در پروکسیهای مسکونی و موبایل، ترافیک معمولاً به طور دقیقتری تعرفهگذاری میشود، زیرا IPهای واقعی کاربران — منبعی گرانتر و محدودتر هستند و مسیر از طریق اپراتور یا ارائهدهنده خانگی، هپهای اضافی را اضافه میکند و در نتیجه دادههای کنترلی بیشتری را به همراه دارد.
پروکسیهای موبایل از این نظر «گرانترین» از نظر ترافیک هستند: شبکههای سلولی مکانیزمهای خود را برای بازنشانی جلسات، NAT translation و گاهی اوقات فشردهسازی/باز کردن ترافیک در سطح اپراتور اضافه میکنند، که شمارش دادههای عبوری را نسبت به همان درخواست از طریق شبکه ثابت افزایش میدهد.
اگر هدف — حجم بالای پایدار درخواستها با حداقل overhead (برای مثال، پارس کردن انبوه قیمتها در Wildberries یا Ozon) باشد، پروکسیهای دیتاسنتر بهترین گزینه هستند — آنها سریعتر و پیشبینیپذیرتر از نظر مصرف ترافیک برای وظایف مشابه هستند.
چگونه مصرف ترافیک را در عمل کاهش دهیم
مراحل خاصی را بررسی میکنیم که مصرف واقعی ترافیک را بدون از دست دادن کارایی پارسر، اتوماسیون یا چندحسابی کاهش میدهند.
۱. بارگذاری منابع غیرضروری را غیرفعال کنید. اگر شما فقط به متن صفحه یا پاسخ JSON API نیاز دارید، بارگذاری تصاویر، فونتها، اسکریپتهای تحلیلی و ردیابهای تبلیغاتی را در تنظیمات مرورگر ضد شناسایی یا ابزار headless غیرفعال کنید. این اغلب مصرف ترافیک را برای وظایف پارس کردن ۶۰-۸۰٪ کاهش میدهد.
۲. از Keep-Alive و استخر اتصالات استفاده کنید. کلاینت HTTP را برای استفاده مجدد از جلسه برای گروهی از درخواستها به یک هاست تنظیم کنید — این به شدت تعداد TLS handshakeها را کاهش میدهد.
۳. سیاست معقولی برای retries تنظیم کنید. تأخیر نمایی (۱ ثانیه → ۲ ثانیه → ۴ ثانیه) با محدودیت ۳ تلاش به جای تکرار تهاجمی ۵-۱۰ تلاش متوالی، ترافیک بیفایده ناشی از درخواستهای ناموفق را کاهش میدهد و همزمان خطر مسدودیت اضافی IP را کاهش میدهد.
۴. کوکیها و هدرهای جلسه را پاک کنید. به طور دورهای مقادیر انباشته شده کوکی را که توسط سایت هدف استفاده نمیشود، پاک کنید — این موضوع به ویژه برای جلسات طولانی گرم کردن حسابها در Instagram یا TikTok از طریق مرورگرهای ضد شناسایی حائز اهمیت است.
۵. پاسخهای استاتیک را کش کنید. اگر دادهها (برای مثال، کاتالوگ محصولات) هر دقیقه تغییر نمیکنند، پاسخ را به صورت محلی کش کنید به جای اینکه در هر چرخه نظارت دوباره از پروکسی درخواست کنید.
۶. از فشردهسازی استفاده کنید. بررسی کنید که آیا هدر Accept-Encoding: gzip ارسال میشود و آیا سرور واقعاً پاسخ فشرده را ارائه میدهد — این حجم ترافیک ورودی را در صفحات با محتوای متنی یا JSON زیاد کاهش میدهد.
ابزارهای نظارت بر ترافیک
برای درک اینکه ترافیک واقعاً کجا میرود، مفید است که نه تنها به شمارنده ارائهدهنده، بلکه به تجزیه و تحلیل دقیق درخواستها نگاه کنید. برای این کار مناسب هستند:
- Charles Proxy / Fiddler — اندازه هر درخواست و پاسخ، از جمله هدرها را نشان میدهند، که به شما کمک میکند «کوکیهای سنگین» یا منابع اضافی را پیدا کنید.
- Wireshark — برای تجزیه و تحلیل عمیق overhead TCP/TLS در سطح بسته، اگر نیاز به ارزیابی وزن واقعی handshake دارید.
- شمارندههای داخلی ترافیک در مرورگرهای ضد شناسایی (Dolphin Anty، AdsPower، GoLogin) — بسیاری از آنها مصرف را برای هر پروفایل به طور جداگانه نشان میدهند، که برای توزیع بودجه بین حسابها مناسب است.
- لاگگیری در سطح کلاینت HTTP — هنگام نوشتن اسکریپتهای پارسینگ خود، مفید است که اندازه درخواست/پاسخ را برای هر فراخوانی لاگ کنید تا ناهنجاریها را پیدا کنید.
مقایسه اندازهگیریهای ابزارهای شما با شمارنده ارائهدهنده پروکسی به شما کمک میکند تا سریعاً بفهمید که ترافیک کجا از دست میرود — در retries، TLS یا بارگذاری منابع اضافی.
چکلیست بهینهسازی قبل از راهاندازی
قبل از راهاندازی مقیاسپذیر پارسر، اتوماسیون SMM یا گرم کردن حسابهای تبلیغاتی، از طریق لیست کوتاهی عبور کنید:
- بارگذاری تصاویر، فونتها، تحلیلها در جاهایی که نیاز نیست، غیرفعال شده است؛
- Keep-Alive / استفاده مجدد از جلسه برای سری درخواستها به یک هاست تنظیم شده است؛
- سیاست retries محدود به ۲-۳ تلاش با تأخیر است، نه تکرار بیپایان؛
- کوکیهای جلسه به طور دورهای از مقادیر غیرقابل استفاده پاک میشوند؛
- فشردهسازی پاسخها (gzip/deflate/br) فعال شده است؛
- کش محلی برای درخواستهای استاتیک تکراری وجود دارد؛
- نوع پروکسی بر اساس وظیفه انتخاب شده است: دیتاسنتر برای سرعت و حجم، مسکونی برای دور زدن مسدودیتها، موبایل برای شبکههای اجتماعی و پلتفرمهای تبلیغاتی.
نتیجهگیری
مصرف ترافیک از طریق پروکسی — تنها دادههای مفید صفحه نیست، بلکه تمام overhead کنترلی نیز شامل میشود: هدرها، TLS-handshake، تلاشهای مجدد در صورت بروز خطا. درک این مکانیک به شما امکان میدهد تا بودجه پروکسی را به دقت برنامهریزی کنید و از سورپرایزهای ناخوشایند در صورتحساب، به ویژه در هنگام مقیاسگذاری پارس کردن بازارها، اتوماسیون SMM یا گرم کردن حسابهای تبلیغاتی، جلوگیری کنید.
اگر هدف شما — پارس پایدار با مصرف ترافیک پیشبینیپذیر است، به پروکسیهای دیتاسنتر توجه کنید. برای کار با شبکههای اجتماعی و پلتفرمهای تبلیغاتی، جایی که فرکانس پایین مسدودیتها مهم است، پروکسیهای موبایل بهتر هستند. و اگر به تعادل بین ناشناسی و پایداری برای دور زدن حفاظت سایتها نیاز دارید — به پروکسیهای مسکونی نگاه کنید که تعداد retries را به دلیل مسدودیتهای کمتر کاهش میدهند.