Apa itu rate limiting berdasarkan IP?

Rate limiting berdasarkan IP adalah mekanisme yang membatasi jumlah permintaan yang dapat dikirim alamat IP ke server dalam periode waktu tertentu. Jika Anda melebihi batas, server sementara menolak permintaan Anda, biasanya dengan error HTTP 429 ("Too Many Requests"). Ini salah satu alat paling umum untuk melindungi server dari penyalahgunaan, serangan denial-of-service, dan scraping otomatis.

Anda mungkin sudah pernah mengalaminya tanpa sadar. Ketika situs menampilkan "Terlalu banyak percobaan, coba lagi dalam 5 menit" setelah beberapa kali login gagal, itu rate limiting. Ketika API mengembalikan error setelah jumlah panggilan tertentu per menit, itu rate limiting. Ketika mesin pencari sementara memblokir kueri Anda karena Anda mencari terlalu cepat, itu juga rate limiting.

Mengapa diperlukan

Server web memiliki sumber daya terbatas: CPU, memori, bandwidth, koneksi database. Setiap permintaan mengonsumsi sebagian sumber daya tersebut. Tanpa batasan apa pun, satu pengguna (atau skrip otomatis) bisa memonopoli server dengan mengirim ribuan permintaan per detik, membuat layanan tidak dapat diakses semua orang lain.

Rate limiting melindungi terhadap beberapa jenis ancaman:

Serangan DDoS dan brute force. Serangan distributed denial-of-service (DDoS) membanjiri server dengan permintaan agar tidak tersedia. Rate limiting saja tidak cukup untuk memblokir DDoS masif (yang datang dari ribuan IP berbeda), tapi membatasi kerusakan yang bisa ditimbulkan satu IP. Untuk serangan brute force (mencoba ribuan kata sandi), rate limiting adalah garis pertahanan pertama: membatasi 5-10 percobaan login per menit membuat serangan tidak praktis.

Scraping dan crawling yang disalahgunakan. Bot yang mengekstrak konten situs (harga, artikel, data) mengirim ratusan permintaan per detik. Rate limiting memperlambat bot ini hingga ekstraksi massal menjadi tidak layak secara ekonomi (terlalu lambat, terlalu banyak waktu server).

Penyalahgunaan API. API publik (cuaca, geolokasi, AI, pembayaran) memiliki biaya per permintaan bagi penyedia. Tanpa rate limiting, pengguna bisa mengonsumsi sumber daya tidak proporsional, baik karena kesalahan (loop dalam kode) maupun sengaja. Sebagian besar API menetapkan batas per kunci API dan per alamat IP.

Keadilan antar pengguna. Bahkan tanpa niat jahat, pengguna "rakus" (yang me-refresh halaman 50 kali per menit, atau skrip yang ditulis buruk) dapat menurunkan pengalaman bagi yang lain. Rate limiting menjamin pembagian sumber daya yang adil.

Cara kerja teknisnya

Prinsipnya sederhana: server mengasosiasikan setiap permintaan dengan alamat IP, menghitung jumlah permintaan yang diterima dari IP tersebut dalam jendela waktu, dan menolak permintaan yang melebihi ambang batas yang ditentukan. Tapi implementasi konkret bervariasi tergantung algoritma yang digunakan.

Jendela Tetap (Fixed Window). Waktu dibagi menjadi interval tetap (misalnya, jendela satu menit). Server menghitung permintaan per IP di setiap jendela. Jika Anda mencapai 100 permintaan di jendela saat ini, permintaan berikutnya ditolak hingga jendela berikutnya dimulai. Algoritma paling sederhana, tapi memiliki kelemahan: jika mengirim 100 permintaan di akhir satu jendela dan 100 di awal berikutnya, Anda mengirim 200 permintaan dalam beberapa detik, dua kali lipat batas yang dimaksud.

Jendela Geser (Sliding Window). Alih-alih jendela tetap, server melihat N detik terakhir kapan saja. Setiap permintaan dihitung selama periode geser. Ini meratakan distribusi dan menghilangkan masalah jendela tetap, tapi membutuhkan lebih banyak memori dan komputasi di sisi server.

Token Bucket (ember token). Setiap IP memiliki "ember" berisi sejumlah tetap token. Setiap permintaan mengonsumsi satu token. Token diregenerasi dengan kecepatan konstan (misalnya, 10 per detik). Jika ember kosong, permintaan ditolak. Model ini mengizinkan burst singkat: Anda bisa mengirim banyak permintaan sekaligus jika ember penuh, lalu harus menunggu regenerasi. Algoritma paling banyak digunakan di produksi karena fleksibel dan dapat diprediksi.

Leaky Bucket (ember bocor). Permintaan masuk ke antrean (ember) dan diproses dengan kecepatan konstan (kecepatan bocor). Jika ember penuh, permintaan baru ditolak. Berbeda dari Token Bucket, Leaky Bucket memaksakan kecepatan output konstan ketat tanpa burst. Berguna ketika Anda menginginkan aliran pemrosesan yang sempurna rata.

Di mana rate limiting diterapkan

Rate limiting dapat diterapkan di berbagai level infrastruktur jaringan, dan dalam praktik sering demikian: beberapa lapisan bertumpuk.

Di level server web. Nginx, Apache, dan sebagian besar server web menyertakan modul rate limiting. Nginx misalnya menggunakan algoritma Leaky Bucket dengan direktif limit_req. Anda mendefinisikan jumlah permintaan per detik per IP, dan Nginx menangani sisanya. Efektif untuk perlindungan dasar, tapi server tetap harus menerima dan memproses sebagian setiap permintaan sebelum menolaknya.

Di level reverse proxy atau load balancer. Menempatkan rate limiting di depan server aplikasi (pada reverse proxy seperti Nginx atau HAProxy, atau load balancer) memungkinkan pemblokiran permintaan sebelum mencapai aplikasi. Lebih efisien dari sisi sumber daya.

Di level CDN atau WAF. Layanan seperti Cloudflare, AWS WAF, atau Akamai menerapkan rate limiting di tepi jaringan (edge), sebelum permintaan bahkan mencapai infrastruktur Anda. Lapisan paling efektif melawan serangan volumetrik karena permintaan diblokir sedekat mungkin dengan sumbernya.

Di level aplikasi. Aplikasi itu sendiri dapat mengimplementasikan rate limiting, sering dengan granularitas lebih: per pengguna yang login, per endpoint, per jenis operasi. Misalnya, API bisa mengizinkan 1.000 permintaan GET per menit tapi hanya 10 permintaan POST di endpoint pembuatan akun, karena percobaan pembuatan akun yang disalahgunakan adalah vektor serangan umum.

Header HTTP terkait rate limiting

Ketika server menerapkan rate limiting, biasanya mengomunikasikan informasi batas melalui header HTTP dalam respons. Tidak ada standar universal, tapi konvensi paling umum adalah:

X-RateLimit-Limit: jumlah maksimum permintaan yang diizinkan dalam jendela waktu saat ini. X-RateLimit-Remaining: jumlah permintaan tersisa sebelum mencapai batas. X-RateLimit-Reset: waktu (sebagai Unix timestamp atau detik tersisa) ketika jendela di-reset dan penghitung dimulai ulang. Retry-After: header HTTP standar yang menunjukkan berapa lama menunggu sebelum mencoba lagi, dikembalikan bersama respons 429.

Draft IETF (RFC 6585 untuk kode status 429 dan proposal lebih baru) mencoba menstandardisasi header ini, tapi dalam praktik setiap API menggunakan konvensinya sendiri. Jika Anda membangun aplikasi yang mengonsumsi API, selalu baca dokumentasi API untuk memahami cara mengomunikasikan batasnya.

Mengapa IP saja tidak selalu cukup

Rate limiting berbasis IP memiliki masalah mendasar: alamat IP tidak selalu sesuai dengan satu pengguna.

CGNAT. Banyak operator seluler dan beberapa ISP menggunakan CGNAT (Carrier-Grade NAT), yang membuat ratusan bahkan ribuan pengguna berbagi satu alamat IPv4 publik. Jika Anda membatasi IP ke 100 permintaan per menit, Anda sebenarnya membatasi semua pengguna di balik CGNAT tersebut ke total gabungan 100 permintaan. Satu pengguna normal bisa menghabiskan kuota untuk semua orang lain.

Jaringan perusahaan dan universitas. Ribuan karyawan atau mahasiswa mungkin mengakses internet melalui satu alamat IP publik (atau sedikit alamat). Rate limiting berbasis IP menghukum mereka secara kolektif.

VPN dan proxy. Pengguna VPN sering berbagi alamat IP dengan ratusan orang lain. Rate limiting ketat berbasis IP bisa memblokir pengguna sah hanya karena mereka menggunakan server VPN yang sama dengan bot.

Alamat IP dinamis. Sebaliknya, penyerang bisa dengan mudah mengganti alamat IP (menggunakan pool proxy, botnet, atau sekadar mengaktifkan mode pesawat di ponsel) dan melewati rate limiting berbasis IP. Jika batas per IP dan penyerang memiliki akses ke 10.000 alamat, batas efektif dikalikan 10.000.

Karena itu sistem rate limiting modern umumnya menggabungkan IP dengan identifikator lain: kunci API, token autentikasi, fingerprint browser, session cookie. IP tetap menjadi kriteria berguna tapi jarang cukup sendiri.

Apa yang terjadi saat Anda dibatasi

Respons paling umum adalah kode status HTTP 429 (Too Many Requests). Server juga bisa mengembalikan 503 (Service Unavailable) jika pembatasan disebabkan kelebihan beban umum bukan pelampauan individual.

Beberapa layanan tidak memblokir akses sepenuhnya tapi menurunkan kualitas layanan: memperlambat respons (throttling), menurunkan kualitas hasil, atau menambahkan CAPTCHA untuk memverifikasi Anda manusia.

Layanan lain memblokir secara diam-diam tanpa mengembalikan error eksplisit. Terus merespons dengan kode 200 (OK) tapi mengembalikan data kosong atau hasil terdegradasi. "Rate limiting diam-diam" (shadow banning) ini umum di media sosial dan beberapa mesin pencari, dan dirancang agar sulit dideteksi bot.

Bagaimana developer menangani rate limiting

Jika Anda membangun aplikasi yang mengonsumsi API, Anda harus menangani rate limiting dengan benar. Metode standar adalah "exponential backoff": saat menerima respons 429, Anda menunggu waktu tertentu sebelum mencoba lagi, dan menggandakan waktu tersebut setiap kegagalan berturut-turut. Contoh: percobaan pertama setelah 1 detik, kedua setelah 2 detik, ketiga setelah 4 detik, dst.

Praktik terbaik meliputi:

Membaca header Retry-After dan X-RateLimit-Reset untuk mengetahui persis kapan mencoba lagi, bukan menebak. Mengimplementasikan cache untuk menghindari pengulangan permintaan yang sama. Mengelompokkan permintaan (batching) saat API mengizinkan. Menyebarkan permintaan sepanjang waktu alih-alih mengirim sekaligus. Menyediakan circuit breaker yang menghentikan panggilan API untuk sementara jika error 429 menumpuk, agar tidak memperburuk situasi.

Rate limiting dan privasi

Rate limiting berbasis IP berarti server mengidentifikasi dan melacak permintaan berdasarkan alamat IP. Ini bentuk pemrosesan data pribadi (alamat IP dianggap data pribadi di banyak yurisdiksi, khususnya di bawah GDPR di Eropa dan UU PDP di Indonesia). Perusahaan yang mengimplementasikan rate limiting secara teori harus menyebutkan pemrosesan ini dalam kebijakan privasi mereka.

Dari perspektif pengguna, rate limiting berbasis IP juga berarti aktivitas Anda sedang dihitung. Jika menggunakan VPN atau proxy untuk alasan privasi, rate limiting secara paradoks bisa merugikan Anda: berbagi IP dengan pengguna lain dan kuota bersama habis lebih cepat.

Melewati rate limiting

Mengganti alamat IP (via VPN, proxy berputar, atau mode pesawat di ponsel) memungkinkan melewati rate limiting yang hanya berdasarkan IP. Layanan scraping komersial menggunakan pool ribuan alamat IP residensial untuk mendistribusikan permintaan dan tetap di bawah ambang per IP.

Tapi sistem perlindungan modern tidak terbatas pada IP. Mereka menggabungkan analisis fingerprint browser, perilaku browsing (ritme klik, gerakan mouse, waktu di halaman), CAPTCHA, dan analisis pola permintaan untuk membedakan manusia dari bot, bahkan ketika IP berubah setiap permintaan.

Perlombaan antara sistem rate limiting dan teknik melewatinya bersifat permanen. Metode yang berhasil hari ini mungkin terdeteksi besok. Jika Anda di sisi server, strategi terbaik adalah menggabungkan beberapa lapisan perlindungan daripada mengandalkan IP saja.

Contoh batas umum

Batas ini sangat bervariasi tergantung layanan, paket harga, dan konteks. API berbayar umumnya menawarkan batas jauh lebih tinggi dari paket gratis. Endpoint sensitif (login, pembayaran, pembuatan akun) memiliki batas jauh lebih rendah dari endpoint pembacaan data.

Rate limiting berdasarkan IP adalah perlindungan esensial untuk setiap server yang terpapar internet. Mencegah penyalahgunaan, melindungi sumber daya, dan menjamin akses yang adil. Tapi alamat IP sendiri adalah pengenal yang semakin tidak bisa diandalkan dengan CGNAT, VPN, dan proxy. Sistem modern menggabungkan IP dengan sinyal lain untuk membedakan lalu lintas sah dari penyalahgunaan, dan kombinasi itulah yang membuat perbedaan antara perlindungan efektif dan filter sederhana yang mudah dilewati.