Ide Menjodohkan Layer 4 Networking dengan Layer 7 di Google Chrome

Salah satu masalah fundamental yang ingin saya pecahkan di NetMeter Web adalah bagaimana mencari solusi yang elegan agar data perhitungan bandwidth menjadi akurat, sekaligus tidak berbohong ke user.

Saya ingin angka yang akurat dan jujur sesuai apa dan data apa yang telah sistem dapatkan.

Dan berangkat dari obsesi akurasi ini, saya memutuskan mencoba melakukan hal gila: Membangun jembatan untuk “menjodohkan” data mentah dari Network OS (Layer 4) dengan metadata dari Chrome Extension (Layer 7).

Berangkat dari content-length dan banyak patcher di Main-World

Jika kalian ingin tahu sedikit tentang “core” dari NetMeter Web, sebenarnya ekstensi ini menggunakan metode hybrid dengan kombinasi penggunaan API webrequest Chrome (menghitung content-length), dan injeksi beberapa patch ke main-world (menghitung real bytes menggunakan reader.read()).

content-length adalah acuan matang yang digunakan browser saat menerima file atau request yang diinfokan oleh server tujuan. Sedangkan jika mengacu pada realita kompleksitas jaringan, misal request A punya total 50kb (di content-length), sebenarnya kita tidak boleh menghitung 50kb jika benar-benar ingin akurasi 100% seperti apa yang dihitung ISP.

Dan itulah hal yang “lupa” kita hitung disini, mulai dari TCP Handshake, TLS Negotiation, HTTP Header overhead, hingga packet retransmission. jadi total 50kb jika dihitung full sesuai bandwidth ISP, itu bisa berkisar antara 60kb-100kb, tergantung kondisi.

Jadi, apakah NetMeter Web tidak akurat? Bukan begitu, alasannya karena NetMeter memang menghitung sesuai apa yang memang bisa kita hitung dari sisi Browser, bukan jaringan langsung.

Mencoba Bermain di Level 3 dan 4

Sebuah ide agak gila, tercetuk dipikiran saya. Bagaimana kalau kita mencoba menghitung bandwidth request situs di Layer Network? Meskipun NetMeter sekarang di Layer 7 (application), tapi akurasinya hanya berkisar 80-90%. Bahkan bisa kurang, jika website yang kita akses memiliki karakteristik aneh. Seperti kasus ini.

Limitasi terbatasnya informasi dari Chrome adalah sandungan terbesar. Meskipun itu bukan salah Chrome, tapi memang spesifikasinya seperti itu.

Setelah mencoba gathering insight, akhirnya saya menemukan ramuan yang agak diluar nalar terkait ide ini. Coba kita lihat gambaran high-level arsitekturnya ini:

+----------+  (stdin/stdout)   +--------------+         IPC.      +----------------+
| Ekstensi | <---------------->|  The Bridge  | <---------------> |  The Daemon    |
|  Chrome  |     (JSON)        |     Agent    |    Unix Socket)   |  (Root/Admin)  |
+----------+                   +--------------+   (JSON/Gob/gRPC) +----------------+
                                                                          |
                                                           (pcap/ETW/eBPF)|
                                                                          v
                                                                   +-----------+
                                                                   |  Jaringan |
                                                                   +-----------+

• Ekstensi Chrome (NetMeter Web), mengirim (info request ke agent) & menerima data dari daemon (via bridge), kita menggunakan nativeMessaging untuk menghandle komunikasi ini.
• Bridge Agent adalah jembatan penghubung antara Agent Daemon utama dan Ekstensi Chrome.
• Daemon Agent adalah nyawa utama processing & matchmaking request yang melibatkan tools jaringan seperti pcap (macOS), ETW (Windows), atau eBPF (di Linux). Disini agent memiliki level root.

Agent disini bukanlah agent AI, tapi murni tools network analysis yang dibuat untuk monitoring traffic.

Untuk ukuran aplikasi yang berjalan di Browser (extension), arsitektur diatas sebenarnya lumayan over-engineering. Bagaimana tidak? kita harus membuat setidaknya 2 agent, dan satu agent yang memiliki root priviledge. Karna untuk kebutuhan monitoring jaringan, sebuah agent harus berada di root, atau simpelnya memiliki sudo access.

Sebuah Agent Yang mencoba memecahkan masalah

Daemon agent diatas, memiliki tugas sangat berat, dia memonitor interface jaringan langsung dari device, melalukan filtering traffic berdasarkan request payload dari ekstensi, melakukan matchmaking apakah traffic itu benar-benar punya request tersebut, lalu mengembalikan bytes ke ekstensi.

Hal terberat yang dilakukan agent adalah matchmaking, dimana daemon bertugas sebagai alat korelasi. Saya disini menggunakan metode Heuristic Scoring dan Time Weighting.

Inilah bagaimana skoring sebuah request itu dimatch-kan dengan beberapa traffic yang identik:

• Ketika ekstensi mengirim ke agent, dia membawa requestId, IP Address dan PORT, URL, dan info Header, sekaligus tambahan timestamp <- ini kuncinya
• dari info tersebut, agent lalu mencocokkan data dengan metode skoring. Misal, jika PORT lokal dan tujuan cukup identik (skor +40), timing timestamp identik (skor +30).
• Jika trafic memiliki skor misalnya diatas 95, maka kita bisa membungkusnya dan mengirimkan kembali info bytesIn dan bytesOut ke ekstensi.

Tentu saja, secara low level, tidak sesimpel itu 😂. Prosesnya benar-benar cukup berdarah-darah dari sisi agent, apalagi agent juga harus menangani traffic HTTP/2 Multiplexing. Ini adalah bos dari kemumetan perhitungan traffic di network.

HTTP/2 Multiplexing itu analoginya seperti saat kita sedang memantau lalu lintas jalan tol. Kalian (saat di Layer 4) bisa menghitung ada satu bus besar yang lewat, tapi tidak bisa melihat detail ada berapa jumlah penumpang yang ada di dalam bus tersebut. Satu bus ini adalah satu traffic rombongan, yang dikirimkan melalui Network, dan nantinya dipecah (demultiplexer) oleh Browser.

Masalahnya lagi adalah, bus itu kacanya gelap (karna enkripsi SSL/TLS). Saat di Layer 4, kita cuma melihat total berat bus yang bertambah. Layer 4 buta soal mana byte punya si gambar logo.png dan mana punya si script.js.

Kalau kita main pukul rata atau menghitung total flow untuk setiap request, data di NetMeter Web bakal ambyar. Angkanya bisa inflasi gila-gilaan. 😬

Tapi bagaimana memecahkan masalah bus (Multiplexing) tadi? Byte mana punya siapa?

Karena membongkar enkripsi SSL itu terlalu ribet (dan ilegal kalau salah guna), saya menerapkan algoritma statistik yang saya sebut “The Socialist Split” (Bagi Rata).

Logikanya: Karena kita tidak tahu persis byte mana milik siapa di dalam satu pipa, maka cara paling valid secara statistik adalah membagi beban bandwidth yang masuk (delta) secara rata kepada semua request yang sedang aktif di pipa tersebut.

Berikut adalah cuplikan logika “sosialis” tersebut di Golang agent saya:

// 1. Hitung berapa byte BARU yang masuk ke pipa (Delta)
totalDeltaIn := currentFlow.BytesIn - lastTotalBytes

// 2. Hitung berapa request yang sedang 'nebeng' di flow ini
activeCount := int64(len(monitors))

if activeCount > 0 {
    // 3. The Socialist Split: Bagi rata beban ke semua penumpang
    // Ini memastikan total bandwidth tetap akurat tanpa inflasi
    share := totalDeltaIn / activeCount
    
    for _, monitor := range monitors {
        // Kirim update jatah bandwidth ke masing-masing request
        updateChan <- StreamUpdate{
            RequestID:    monitor.RequestID,
            BytesInDelta: share,
        }
    }
}

Dengan metode ala-ala demultiplexer ini, kita setidaknya bisa memecahkan masalah request rombongan tersebut, meskipun tidak bisa 100% valid, dan tetap memerlukan optimasi. Intinya, jika ada overhead TLS sebesar 5KB dan ada 5 file yang sedang di-download bersamaan, masing-masing file akan “patungan” menanggung beban 1KB.

Oleh karena itu, angka yang muncul di ekstensi bukan lagi hanya “ukuran file”, tapi representasi nyata dari beban jaringan yang disebabkan oleh file tersebut.

Hal Yang Aneh Tapi Banyak Pembelajaran

Menjodohkan Layer 4 dan Layer 7 itu seperti menyatukan dua dunia yang berbeda bahasa. Chrome bicara soal Resource, Jaringan bicara soal Paket.

Dan bagi saya, itulah definisi tantangan menemukan monitoring bandwidth yang sejati: Bukan hanya angka, tapi fakta. 🚀