WiFi Lemot Otomatis Jam Kerja: Squid Delay Pools di Docker
Pengalaman membatasi bandwidth per klien terjadwal WIB pakai Squid delay_pools di Docker: satuan byte, acl time, TZ, pool kedua.
Minggu lalu saya pasang pembatas bandwidth di jaringan rumah: proxy Squid di dalam Docker, dengan jadwal: kencang malam hari, lemot pas jam kerja. Rencananya simpel, tapi eksekusi pertama saya meleset dua kali: speedtest mentok di angka yang salah, dan jadwal yang saya tulis buat malam hari malah aktif di siang bolong . Ternyata saya kejebak dua hal klasik: satuan (byte vs bit) dan timezone container.
Cara Kerja Delay Pools: Bayangin Ember
Cara paling gampang memahami delay pools Squid adalah bayangin ember berisi token bandwidth: ember diisi ulang dengan rate tertentu setiap detik, tiap data yang lewat minum dari ember, dan ember kosong berarti transfer ditahan [1]. Satu pool bisa punya beberapa tingkat ember sekaligus: agregat untuk semua klien, per-network, sampai per-host individual, dan level mana yang tidak dipakai boleh dimatikan [1]. Untuk LAN kecil seperti punya saya, class 3 adalah yang paling pas karena punya ketiga tingkat itu [1].
Pertanyaan praktisnya: angka berapa yang ditulis di ember? Di sini banyak orang (termasuk saya) pernah salah baca, karena unit delay_parameters adalah byte per detik, bukan bit [2]. Kecepatan internet biasanya disebut dalam bit, jadi cap 40 Mbps itu 5 juta byte per detik; angka 5000000 di konfigurasi bukan typo, melainkan konversi yang benar [2]. Parameternya ditulis berpasangan restore/maximum: restore = laju pengisian ember, maximum = ukuran maksimal ember, dua-duanya dalam byte [2]. Wiki resmi menyarankan maximum minimal dua kali restore supaya burst pendek tetap nyaman: halaman baru kebuka langsung penuh, bukan nunggu ember terisi per detik [1].
Dua batasan yang perlu dipegang: delay pools hanya menahan payload data (overhead TCP, query DNS, dan semacamnya lewat seperti biasa [1])dan satu koneksi besar bisa menghabiskan bucket sehingga koneksi lain ikut ngantri [1]. Konsekuensinya praktis: speedtest satu koneksi bakal mentok di cap, sedangkan tools yang membuka banyak koneksi bisa melebihi angka di atas kertas . Ini estimasi dari cara kerja ember yang saya alami sendiri.
Jadwal WIB: acl Time, TZ Container, dan Pool Kedua
Untuk jadwal, Squid punya ACL time dengan format acl aclname time [day-abbrevs] [h1:m1-h2:m2]: boleh dibatasi hari tertentu atau berlaku tiap hari [3]. Ada satu aturan kaku yang baru terasa setelah dibakar: jam awal harus lebih kecil dari jam akhir [3]. Tidak bisa wrap tengah malam. Kalau jam kerja saya 09:00–21:00, tidak ada satu ACL yang bisa menampung pelengkapnya (21:00–09:00); solusinya bukan memaksa satu pool, tapi pool kedua yang sengaja tanpa limit dengan parameter -1/-1 [1].
Konfigurasi yang akhirnya jalan di server saya:
acl klien src 192.168.x.x/24
acl jamkerja time 09:00-21:00
delay_pools 2
delay_class 1 3
delay_parameters 1 -1/-1 -1/-1 5000000/10000000
delay_access 1 allow jamkerja
delay_class 2 1
delay_parameters 2 -1/-1
delay_access 2 allow allPool 1 cuma aktif saat ACL jamkerja cocok. Karena class 3, ada tiga slot ember: aggregate dan network saya matikan, sisanya ember per-klien 5.000.000/10.000.000 byte: cap 40 Mbps dengan burst sekitar dua detik. Pool 2 menangkap sisanya (luar 09:00–21:00) sebagai class 1, tingkat paling sederhana dengan satu ember agregat tanpa limit [1]. Hasilnya kebijakan statis yang saya mau: di luar jam kerja, klien jalan kencang tanpa config tambahan.
Ada jebakan ketiga yang lebih licik: ACL time membaca jam lokal host tempat Squid berjalan, dan di container default-nya UTC, jadi jadwal 09:00 WIB bisa diterjemahkan jam 02:00 dini hari dan pembatasan aktif di waktu yang salah . Solusinya satu baris, TZ=Asia/Jakarta di environment container: ini konsekuensi isolasi container yang baru kerasa pas jadwal sudah kacau .
Sebagai pembanding, 3proxy punya bandlimin/bandlimout untuk batas statis dua arah; lebih sederhana, tapi tanpa penjadwalan berbasis waktu . Untuk pola "jam kerja lemot, malam bebas" saya tetap butuh delay pools Squid, dan di tempat saya keduanya jalan bareng: Squid buat jadwal, 3proxy buat angka statis .
Di pengukuran saya sendiri, setting 5.000.000/10.000.000 byte menghasilkan throughput sekitar 39 Mbps turun dan 42 Mbps naik per klien: di sekitar cap 40 Mbps, wajar untuk shaping yang hanya menyentuh payload. Angka ini pengalaman di jaringan saya, bukan benchmark umum; hasil Anda akan beda tergantung kondisi jaringan .
Kalau mau copy pola ini, checklist saya:
- Tulis cap dalam byte per detik: Mbps ÷ 8 × 1.000.000 [2].
- TZ container harus sama dengan timezone jadwal; cek cepat dari host dengan docker exec nama-container date .
- Jadwal pelengkap butuh pool kedua, karena time ACL tidak bisa wrap tengah malam [3].
- Pakai minus satu per minus satu untuk mematikan bucket yang tidak dipakai [1].
- Tes speedtest dua kali (di dalam dan di luar jam)sebelum percaya angkanya .
Sources
[1] https://wiki.squid-cache.org/Features/DelayPools
[2] https://www.squid-cache.org/Doc/config/delay_parameters/
[3] https://www.squid-cache.org/Doc/config/acl/