Anda menjalankan parser atau memanaskan akun melalui proxy, memperkirakan pengeluaran berdasarkan ukuran halaman — dan menerima tagihan 2-3 kali lebih besar dari yang diharapkan. Ini bukan karena penipuan penyedia: semua yang benar-benar melewati saluran dihitung dalam lalu lintas — header permintaan, handshake TLS, percobaan koneksi ulang, dan paket layanan. Mari kita bahas dari mana "tagihan" untuk lalu lintas berasal dan bagaimana mengurangi pengeluaran tanpa mengorbankan kualitas kerja.
Apa yang sebenarnya dihitung penyedia sebagai lalu lintas
Ketika Anda memperkirakan pengeluaran "secara kasat mata", biasanya ada rumus di kepala: ukuran halaman HTML ditambah gambar. Namun penyedia proxy menghitung total volume data yang melewati kedua arah saluran — keluar (permintaan) dan masuk (jawaban). Volume ini tidak hanya mencakup muatan berguna, tetapi juga semua lalu lintas layanan: header protokol, metadata TLS, paket ACK TCP, dan percobaan koneksi ulang saat terjadi timeout.
Untuk satu permintaan ke halaman biasa, rasio "data berguna" terhadap "data layanan" bisa 80/20. Tetapi jika Anda bekerja dengan API, di mana jawaban kecil (beberapa kilobyte JSON), dan banyak header serta handshake — rasio ini dengan mudah terbalik. Itulah sebabnya para arbiter yang mengirimkan puluhan ribu permintaan kecil ke API iklan atau marketplace sering terkejut dengan tagihan: setiap permintaan membawa "pajak" tetap terlepas dari ukuran muatan berguna.
Satu hal penting lainnya: penyedia menghitung lalu lintas di tingkat server proxy, yaitu semua lalu lintas yang benar-benar melewati IP — termasuk percobaan yang gagal, pengalihan, dan pemuatan ulang sumber daya di halaman (gaya, skrip, pelacak) yang secara otomatis diminta oleh skrip atau browser Anda, bahkan jika Anda hanya membutuhkan teks.
Header HTTP/HTTPS: berat tersembunyi dari setiap permintaan
Setiap permintaan HTTP dan setiap jawaban membawa sekumpulan header: User-Agent, Cookie, Accept-Language, Referer, Content-Type, dan puluhan lainnya. Di browser modern dan alat anti-deteksi (Dolphin Anty, AdsPower, Multilogin), kumpulan header bisa memakan dari 500 byte hingga 2-3 KB untuk satu permintaan — terutama jika di cookie telah terakumulasi sesi dengan puluhan nilai.
Contoh: jika Anda membuat 10.000 permintaan ke API marketplace dengan cookie sesi sebesar 1.5 KB, hanya untuk header akan menghabiskan sekitar 15 MB lalu lintas — dan ini tanpa memperhitungkan isi jawaban. Saat diskalakan ke beberapa akun dan profil, angka ini meningkat secara linier.
| Jenis Header | Ukuran Rata-rata | Dampak pada Lalu Lintas |
|---|---|---|
| User-Agent | 100-150 byte | Rendah, tetapi terakumulasi saat diskalakan |
| Cookie (sesi) | 500-2000 byte | Tinggi pada sesi yang panjang |
| Referer / Origin | 50-200 byte | Rendah |
| Header Accept-* | 150-300 byte | Rendah |
| Header jawaban server | 300-800 byte | Sedang, tidak tergantung pada Anda |
Kesimpulan praktis: jika Anda menulis skrip untuk memantau harga di Wildberries atau Ozon, bersihkan cookie dari nilai yang tidak digunakan dan jangan bawa header yang tidak perlu yang disalin "hanya untuk berjaga-jaga" dari DevTools browser.
Handshake TLS: berapa banyak lalu lintas yang dimakan oleh enkripsi
Hampir seluruh web modern beroperasi melalui HTTPS, yang berarti setiap koneksi baru dimulai dengan handshake TLS — pertukaran sertifikat, kunci enkripsi, dan parameter protokol. Satu handshake TLS penuh (TLS 1.2 atau 1.3) memiliki berat antara 4 hingga 8 KB tergantung pada ukuran sertifikat situs dan ekstensi protokol yang digunakan.
Jika Anda membuka koneksi baru untuk setiap permintaan (dan tidak menggunakan koneksi tetap), handshake TLS diulang setiap kali. Dengan 10.000 permintaan tanpa penggunaan kembali koneksi, Anda akan mendapatkan tambahan 40-80 MB lalu lintas hanya untuk enkripsi — ini bisa lebih banyak daripada konten berguna itu sendiri.
TLS 1.3 sedikit lebih ringan daripada TLS 1.2 karena jumlah round-trip yang lebih sedikit, tetapi perbedaannya terasa hanya pada jumlah koneksi yang besar. Untuk proxy seluler, di mana jaringan operator itu sendiri menambah latensi dan pemulihan sesi, overhead TLS terasa sangat signifikan — ini harus dipertimbangkan saat memilih proxy seluler untuk tugas dengan permintaan pendek yang sering.
Retry: bagaimana permintaan ulang menggandakan pengeluaran
Retry adalah item pengeluaran lalu lintas yang paling tidak terlihat dan paling mahal. Jika parser atau skrip Anda diatur untuk mengulangi secara otomatis saat terjadi timeout atau kesalahan 429/503, setiap permintaan yang gagal sudah menghabiskan lalu lintas untuk membangun koneksi, handshake TLS, dan header — dan kemudian seluruh proses ini diulang kembali.
Kesalahan umum dalam otomatisasi SMM dan pengambilan data dari marketplace adalah kebijakan retry yang agresif tanpa penundaan eksponensial: skrip melakukan 5 percobaan berturut-turut dengan interval satu detik pada tanda pertama pemblokiran IP. Akibatnya, untuk satu jawaban "berguna", lalu lintas dari lima percobaan yang gagal ditambah permintaan yang berhasil terakhir digunakan.
Ini sangat kritis saat bekerja dengan proxy pusat data di situs dengan perlindungan agresif (misalnya, Avito atau marketplace besar), yang dapat mengembalikan captcha atau memblokir sebagian besar permintaan dari IP "panas". Dalam hal ini, ada baiknya mempertimbangkan proxy residensial — mereka jarang terblokir pada permintaan pertama, yang mengurangi jumlah retry dan, dengan demikian, pengeluaran lalu lintas yang sebenarnya.
Keep-Alive vs koneksi baru
HTTP Keep-Alive memungkinkan penggunaan kembali satu koneksi TCP/TLS untuk beberapa permintaan berturut-turut, menghindari handshake ulang. Ini adalah salah satu optimasi lalu lintas yang paling efektif, tersedia di hampir semua klien HTTP dan browser anti-deteksi.
Jika Anda menggunakan pustaka untuk pengambilan data (requests, httpx, axios) tanpa secara eksplisit menentukan sesi dengan koneksi tetap, setiap permintaan secara default dapat membuka koneksi TCP baru. Dalam kombinasi dengan proxy, ini berarti: koneksi baru ke server proxy, TLS baru ke situs target, dan seluruh overhead diulang pada setiap panggilan.
| Mode Koneksi | Overhead untuk 1000 permintaan |
|---|---|
| Koneksi baru untuk setiap permintaan | 4-8 MB (hanya TLS) |
| Keep-Alive, satu sesi untuk 50 permintaan | 0.1-0.2 MB (satu handshake untuk grup) |
Perbedaannya sangat besar — dan ini adalah penghematan lalu lintas murni tanpa mengubah muatan berguna dari permintaan.
Bagaimana berbagai jenis proxy menghitung lalu lintas
Model penagihan lalu lintas tergantung pada jenis proxy. Proxy pusat data sering kali menggunakan tarif berdasarkan volume lalu lintas atau jumlah IP/port — infrastruktur itu sendiri lebih cepat dan menambah overhead minimal untuk routing. Untuk proxy residensial dan seluler, lalu lintas biasanya dikenakan tarif yang lebih ketat, karena IP pengguna yang sebenarnya adalah sumber daya yang lebih mahal dan terbatas, dan rute melalui operator atau penyedia rumah menambah hop tambahan dan, dengan demikian, sedikit lebih banyak data layanan.
Proxy seluler dalam hal ini adalah yang paling "mahal" dalam lalu lintas: jaringan seluler menambahkan mekanisme pemulihan sesi, translasi NAT, dan kadang-kadang kompresi/dekompresi lalu lintas di tingkat operator, yang meningkatkan penghitung data yang lewat dibandingkan dengan permintaan yang sama melalui jaringan tetap.
Jika tugasnya adalah volume permintaan yang tinggi dan stabil dengan overhead minimal (misalnya, pengambilan harga massal di Wildberries atau Ozon), maka proxy pusat data adalah pilihan yang lebih baik — mereka lebih cepat dan lebih dapat diprediksi dalam pengeluaran lalu lintas untuk tugas yang serupa.
Cara mengurangi pengeluaran lalu lintas dalam praktik
Mari kita bahas langkah-langkah konkret yang mengurangi pengeluaran lalu lintas yang sebenarnya tanpa mengorbankan fungsionalitas parser, otomatisasi, atau multi-akuntansi.
1. Matikan pemuatan sumber daya yang tidak perlu. Jika Anda hanya membutuhkan teks halaman atau jawaban JSON dari API, matikan pemuatan gambar, font, skrip analitik, dan pelacak iklan dalam pengaturan browser anti-deteksi atau alat headless. Ini sering mengurangi pengeluaran lalu lintas hingga 60-80% untuk tugas pengambilan data.
2. Gunakan Keep-Alive dan pool koneksi. Atur klien HTTP untuk menggunakan kembali sesi untuk kelompok permintaan ke satu host — ini secara drastis mengurangi jumlah handshake TLS.
3. Atur kebijakan retry yang masuk akal. Penundaan eksponensial (1 detik → 2 detik → 4 detik) dengan batasan 3 percobaan alih-alih 5-10 percobaan berturut-turut yang agresif mengurangi lalu lintas yang tidak berguna dari permintaan yang gagal dan sekaligus mengurangi risiko pemblokiran IP tambahan.
4. Bersihkan cookie dan header sesi. Secara berkala hapus nilai cookie yang terakumulasi yang tidak digunakan oleh situs target — ini sangat relevan untuk sesi panjang pemanasan akun di Instagram atau TikTok melalui browser anti-deteksi.
5. Cache jawaban statis. Jika data (misalnya, katalog produk) tidak berubah setiap menit, cache jawaban secara lokal alih-alih mengajukan permintaan ulang melalui proxy pada setiap siklus pemantauan.
6. Gunakan kompresi. Pastikan header Accept-Encoding: gzip dikirim dan server benar-benar memberikan jawaban yang terkompresi — ini mengurangi volume lalu lintas masuk pada halaman dengan banyak teks atau JSON.
Alat untuk memantau lalu lintas
Untuk memahami ke mana lalu lintas benar-benar pergi, berguna untuk melihat tidak hanya pada penghitung penyedia, tetapi juga pada rincian permintaan. Alat yang cocok untuk ini adalah:
- Charles Proxy / Fiddler — menunjukkan ukuran setiap permintaan dan jawaban, termasuk header, yang membantu menemukan cookie "berat" atau sumber daya yang tidak perlu.
- Wireshark — untuk analisis mendalam tentang overhead TCP/TLS di tingkat paket, jika perlu menilai berat sebenarnya dari handshake.
- Penghitung lalu lintas bawaan di browser anti-deteksi (Dolphin Anty, AdsPower, GoLogin) — banyak yang menunjukkan pengeluaran untuk setiap profil secara terpisah, yang nyaman untuk distribusi anggaran antar akun.
- Logging di tingkat klien HTTP — saat menulis skrip pengambilan data sendiri, berguna untuk mencatat ukuran permintaan/jawaban untuk setiap panggilan, untuk menemukan anomali.
Perbandingan pembacaan alat Anda dengan penghitung penyedia proxy membantu dengan cepat memahami di mana lalu lintas hilang — pada retry, TLS, atau pemuatan sumber daya yang tidak perlu.
Checklist optimasi sebelum peluncuran
Sebelum meluncurkan parser, otomatisasi SMM, atau pemanasan akun iklan secara besar-besaran, periksa daftar singkat berikut:
- Pemuatan gambar, font, dan analitik dinonaktifkan di tempat yang tidak diperlukan;
- Keep-Alive / penggunaan kembali sesi diatur untuk serangkaian permintaan ke satu host;
- Kebijakan retry dibatasi pada 2-3 percobaan dengan penundaan, bukan pengulangan tanpa batas;
- Cookie sesi secara berkala dibersihkan dari nilai yang tidak digunakan;
- Kompresi jawaban diaktifkan (gzip/deflate/br);
- Ada caching lokal untuk permintaan statis yang berulang;
- Jenis proxy dipilih sesuai dengan tugas: pusat data untuk kecepatan dan volume, residensial untuk menghindari pemblokiran, seluler untuk media sosial dan platform iklan.
Kesimpulan
Pengeluaran lalu lintas melalui proxy bukan hanya data berguna dari halaman, tetapi juga seluruh overhead layanan: header, handshake TLS, dan percobaan ulang saat terjadi kesalahan. Memahami mekanisme ini memungkinkan perencanaan anggaran untuk proxy yang lebih tepat dan menghindari kejutan yang tidak menyenangkan dalam tagihan, terutama saat memperbesar pengambilan data dari marketplace, otomatisasi SMM, atau pemanasan akun iklan.
Jika tugas Anda adalah pengambilan data yang stabil dengan pengeluaran lalu lintas yang dapat diprediksi, perhatikan proxy pusat data. Untuk bekerja dengan media sosial dan platform iklan, di mana frekuensi pemblokiran yang rendah sangat penting, proxy seluler lebih cocok. Dan jika Anda membutuhkan keseimbangan antara anonimitas dan stabilitas untuk menghindari perlindungan situs — pertimbangkan proxy residensial, yang mengurangi jumlah retry karena pemblokiran yang lebih jarang.