Arsitektur Remote GUI via SSH: Trade-off DOM Stream vs Framebuffer

Menjalankan Graphical User Interface (GUI) dari server jarak jauh melalui secure shell (SSH) secara historis bergantung pada X11 forwarding. Namun, model X11 rentan terhadap latency round-trip tinggi dan kebocoran bandwidth karena sifat protokol sinkronnya. Dua alternatif modern untuk merender UI remote melalui SSH channel adalah: Raster Framebuffer Streaming (mengirim piksel terkompresi) dan Semantic DOM Streaming (mengirim representasi struktur UI secara deklaratif). Memilih pendekatan yang tepat menuntut evaluasi ketat terhadap trade-off siklus CPU server, biaya egress jaringan, latensi persepsi lokal, dan kompleksitas protokol.

Arsitektur 1: Raster Framebuffer Streaming

Arsitektur framebuffer memperlakukan aplikasi remote sebagai black box visual. Aplikasi berjalan di server menggunakan headless display server (seperti Xvfb atau Wayland headless compositor). Server menangkap buffer memori grafis (VRAM atau RAM), mengompresinya menggunakan codec video (seperti H.264, VP9, atau algoritma berbasis tile seperti TightVNC), lalu menyalurkan bitstream tersebut melalui SSH channel multiplex.

Karakteristik Arsitektur:

• Agnostik Aplikasi: Mampu merender aplikasi legacy berbasis C++, GTK, Qt, hingga OpenGL tanpa modifikasi kode sumber.
• Beban CPU/GPU Server: Server harus mengalokasikan siklus komputasi untuk rendering 2D/3D sekaligus kompresi frame raster berkelanjutan. Ketiadaan akselerasi hardware video encoder (NVENC/VAAPI) pada server virtual akan membebani CPU secara masif.
• Egress Jaringan: Konsumsi bandwidth proporsional terhadap resolusi tampilan dan refresh rate (FPS), bukan kompleksitas semantik aplikasi. Tampilan statis 1080p memerlukan bandwidth minimal, namun scroll terus-menerus memicu transmisi delta piksel bernilai megabit per detik.

Arsitektur 2: Semantic DOM / Component Streaming

Arsitektur ini memisahkan logika backend dari rendering layer. Server tidak merender piksel sama sekali. Aplikasi di server mengeksekusi state machine dan memancarkan patch data struktur visual (misalnya skema DOM berbasis JSON, Protocol Buffers, atau FlatBuffers) melalui SSH subsystem. Klien lokal bertindak sebagai rendering engine (menggunakan WebView, Flutter engine, atau native platform widget) yang membaca patch tersebut dan menyusun tree visual di memori klien.

Karakteristik Arsitektur:

• Efisiensi Komputasi Server: Penggunaan CPU di server mendekati nol untuk kebutuhan visualisasi karena komputasi layouting, rasterizing, dan painting sepenuhnya didelegasikan ke GPU klien.
• Egress Bandwidth Minimal: SSH channel hanya mentransmisikan perubahan state dan nodus data visual berukuran biner kecil (sering kali di bawah 10 KB per mutasi state).
• Toleransi Latensi Input: Interaksi lokal seperti rendering kursor, scrolling, text-caret, dan animasi hover ditangani langsung pada klien dengan frame rate 60-120 FPS tanpa menunggu network round-trip time (RTT).

Matriks Trade-off Teknis

Implementasi Protokol: Binary Framing pada SSH Subsystem

Saat menggunakan SSH channel atau SSH subsystem khusus (melalui directive Subsystem pada sshd_config), data dialirkan sebagai continuous byte stream tanpa batas pesan (message boundary). Berbeda dengan HTTP/2 atau WebSocket, implementasi kustom harus mengelola paket framing sendiri agar tidak terjadi data corruption saat parsing DOM patch berkecepatan tinggi.

Format framing paling efisien adalah Length-Prefixed Framing dengan Type-Length-Value (TLV):

+-----------------------+-------------------+------------------------+
| 4 Bytes: Payload Size | 1 Byte: Msg Type  | N Bytes: Binary Payload|
| (Big-Endian uint32)   | (0x01=DOM, etc.)  | (FlatBuffers / JSON)   |
+-----------------------+-------------------+------------------------+

Contoh Pseudo-Code Encoder & Decoder (Framing Parser):

// Definisi Tipe Pesan
const (
    MsgTypeDOMPatch   byte = 0x01
    MsgTypeInputEvent byte = 0x02
    MsgTypeHeartbeat  byte = 0x03
)

// Writer: Membungkus payload semantik sebelum dikirim ke SSH Stdout
func WriteFrame(writer io.Writer, msgType byte, payload []byte) error {
    payloadSize := uint32(len(payload))
    header := make([]byte, 5)
    
    // Tulis ukuran payload (4 byte Big-Endian)
    binary.BigEndian.PutUint32(header[0:4], payloadSize)
    // Tulis identitas tipe pesan (1 byte)
    header[4] = msgType

    if _, err := writer.Write(header); err != nil {
        return err
    }
    _, err := writer.Write(payload)
    return err
}

// Reader: Membaca byte stream dari SSH Stdin dan mendekode batas pesan
func ReadFrame(reader io.Reader) (byte, []byte, error) {
    header := make([]byte, 5)
    if _, err := io.ReadFull(reader, header); err != nil {
        return 0, nil, err
    }

    payloadSize := binary.BigEndian.Uint32(header[0:4])
    msgType := header[4]

    // Batasi buffer untuk mitigasi serangan memory allocation Denial of Service
    const MaxPayload = 16 * 1024 * 1024 // 16 MB limit
    if payloadSize > MaxPayload {
        return 0, nil, fmt.Errorf("payload size %d melebihi batas aman", payloadSize)
    }

    payload := make([]byte, payloadSize)
    if _, err := io.ReadFull(reader, payload); err != nil {
        return 0, nil, err
    }

    return msgType, payload, nil
}

Catatan Keamanan: Jangan mendeserialisasi payload biner dinamis tanpa validasi alokasi ukuran buffer (payloadSize). Klien atau server berbahaya dapat mengirim nilai uint32 buatan (misalnya 4GB) yang dapat menyebabkan Out-Of-Memory (OOM) panic seketika.

Panduan Pemilihan Arsitektur Berdasarkan Use-Case

Gunakan Semantic DOM Streaming Jika:

• Membangun admin dashboard internal, sistem monitoring metrik, atau operational tools yang memerlukan interaktivitas input responsif.
• Aplikasi di-deploy pada arsitektur multi-tenant atau cloud compute berbiaya tinggi di mana CPU overhead dan egress bandwith harus ditekan seminimal mungkin.
• Infrastruktur jaringan memiliki latensi tinggi (> 100ms) atau bandwidth tidak stabil (misalnya koneksi seluler remote edge device).

Gunakan Framebuffer Streaming Jika:

• Perlu me-remote sistem legacy (seperti CAD, software audio/video workstation, atau IDE C++) tanpa rekayasa ulang basis kode.
• Beban visual didominasi oleh grafis piksel berkelanjutan dengan frame-to-frame entropy yang tinggi (misalnya rendering simulasi 3D, canvas manipulasi foto, atau data visualisasi seismik), di mana merepresentasikan scene tree melalui DOM justru memicu serialization bottleneck.
• Hardware server memiliki dedicated GPU dengan encoder ASIC (misalnya Intel QuickSync atau Nvidia NVENC) yang mengizinkan encoding frame raster tanpa memotong alokasi CPU sistem.