Belajar Remote Desktop - Sejarah, Latar Belakang & Mengapa Membutuhkannya
Episode 1 of 23

Belajar Remote Desktop - Sejarah, Latar Belakang & Mengapa Membutuhkannya

Episode ini menelusuri asal-usul remote desktop: dari era mainframe, X11 forwarding, kelahiran protokol RFB oleh AT&T pada 1990-an yang menjadi fondasi VNC, hingga RDP dari Microsoft. Diakhiri dengan perbandingan VNC vs RDP dan panduan memilih tool berdasarkan kebutuhan.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Pendahuluan

Semua teknologi lahir dari masalah nyata, dan remote desktop tidak terkecuali. Di episode 1 ini kita berhenti sejenak dari perintah terminal untuk memahami mengapa remote desktop ada, siapa yang menciptakannya, dan kapan teknologi yang kita pakai hari ini dilahirkan. Pemahaman sejarah ini bukan sekadar trivia — ia menjelaskan kenapa VNC berperilaku seperti sekarang, kenapa RDP lebih efisien di bandwidth rendah, dan kapan kalian harus memilih yang mana.

Perjalanan dimulai dari era mainframe di mana terminal hanya berupa layar hijau tanpa GUI, berlanjut ke konsep X11 forwarding yang membuka jalan pengiriman GUI lewat jaringan, lalu pecah menjadi dua arus besar: VNC yang lahir dari protokol RFB (Remote Framebuffer) karya AT&T, dan RDP yang diciptakan Microsoft untuk Windows. Di akhir episode, kalian akan punya kerangka berpikir untuk memilih tool yang tepat.

Sejarah dan Evolusi Remote Desktop

Dari Mainframe ke X11 Forwarding

Konsep mengendalikan komputer dari jauh sebenarnya sudah ada sejak era mainframe pada 1960-1970-an. Saat itu terminal tidak punya GUI — yang dikirim lewat jaringan hanyalah teks. Masalah mulai muncul ketika komputer pribadi dan workstation memperkenalkan antarmuka grafis: bagaimana cara menampilkan dan mengendalikan GUI dari mesin lain?

X11 (X Window System) menjawabnya dengan network transparency. Sebuah program X11 bisa menampilkan dirinya di display mesin lain lewat forwarding. Model ini memisahkan client aplikasi dari display server, dan menjadi cikal bakal semua teknologi remote GUI yang kita kenal sekarang.

Kelahiran RFB dan VNC pada 1990-an

Pada pertengahan 1990-an, para peneliti di AT&T mengembangkan konsep yang lebih radikal: mengirim framebuffer itu sendiri — gambaran piksel dari seluruh layar — ke mesin lain. Dari sinilah lahir protokol RFB (Remote Framebuffer Protocol) dan implementasi aslinya yang disebut VNC (Virtual Network Computing).

VNC asli dari AT&T kemudian terpecah menjadi banyak implementasi yang masih hidup sampai hari ini:

  • RealVNC — kelanjutan komersial dari kode asli.
  • TightVNC — berfokus pada efisiensi bandwidth via Tight encoding.
  • TigerVNC — hasil kolaborasi komunitas, berfokus pada performa dan modernisasi.
  • x11vnc — implementasi yang men-share display X11 yang sedang berjalan.

Konsep kunci VNC: server mengirim framebuffer (kumpulan piksel layar) ke viewer, dan viewer mengirimkan event keyboard serta mouse kembali. Sederhana, lintas platform, dan bekerja di sistem apa pun yang bisa merender piksel.

RDP: Jawaban Microsoft

Sementara komunitas open source mempopulerkan VNC, Microsoft membangun protokolnya sendiri: RDP (Remote Desktop Protocol), diperkenalkan pada akhir 1990-an dengan Windows NT. RDP dirancang bukan untuk mengirim gambaran piksel mentah, melainkan sebagai protokol bidirectional yang memisahkan layer presentasi dan transfer data secara lebih canggih.

RDP membawa konsep NLA (Network Level Authentication) — autentikasi dilakukan sebelum sesi desktop penuh dibuat, sehingga lebih aman dan lebih hemat resource. Karena dirancang untuk jaringan WAN, RDP jauh lebih efisien di bandwidth rendah dibanding VNC generasi awal.

VNC vs RDP: Perbandingan Arsitektur

Perbedaan Filosofi Desain

Sekarang mari bandingkan dua raksasa remote desktop ini secara berdampingan:

AspekVNC (RFB)RDP
OrientasiFramebuffer, one-wayPresentation, bidirectional
Port default5900 + display3389
AutentikasiPassword sederhanaNLA berbasis kredensial
Efisiensi bandwidthTergantung encodingDirancang untuk WAN
PlatformHampir semua OSWindows asli, xrdp untuk Linux
ExtensibilityRFB spec terbukaProprietary Microsoft

Perbedaan paling mendasar ada di dua hal: cara mengirim layar dan filosofi keamanan. VNC mengirim piksel dan menyerahkan efisiensi pada mekanisme encoding; RDP membangun protokol berlapis dengan kompresi bawaan yang jauh lebih agresif.

Port default yang harus kalian hafal
ss -tulpn | grep -E ":(5900|3389)"

Perintah ss -tulpn | grep -E ":(5900|3389)" menampilkan service yang sedang mendengarkan di kedua port kunci remote desktop. Hafalkan dua port ini — keduanya akan muncul di hampir setiap episode series ini.

Mengapa Membutuhkan Remote Desktop

Kasus Penggunaan Nyata

Ada beberapa skenario di mana remote desktop bukan sekadar kenyamanan, melainkan kebutuhan:

  • Helpdesk dan IT support: membantu pengguna lain memecahkan masalah GUI dari jarak jauh.
  • Administrasi workstation: mengelola banyak workstation Linux/Windows tanpa harus duduk di depannya.
  • Headless server: mengakses desktop server yang tidak punya monitor fisik terpasang.
  • Troubleshooting: melihat langsung apa yang tampil di layar saat aplikasi bermasalah.
  • Otomasi environment desktop: menjalankan dan menguji aplikasi GUI secara remote.

Memilih Tool Berdasarkan Kebutuhan

Tidak ada tool yang unggul di semua situasi. Kerangka pemilihannya:

  • Bandwidth terbatas dan client-nya Windows → pilih RDP.
  • Cross-platform dan open source murni → pilih VNC.
  • Akses dari luar NAT tanpa setup → pertimbangkan solusi komersial (episode 22).
  • Desktop GNOME/Wayland modern → pertimbangkan GNOME Remote Desktop (episode 18).
Pemilihan tool dalam satu baris
linux-cli  +  x11  ->  x11vnc / TigerVNC
windows    +  wan  ->  RDP / mstsc
gNOME      +  wayland ->  GNOME Remote Desktop

Perkembangan VNC Modern

Dari Satu Protokol, Banyak Implementasi

Satu hal yang membuat sejarah remote desktop menarik: protokol RFB yang lahir dari AT&T tidak berkembang sebagai satu jalan lurus, melainkan terpecah menjadi banyak implementasi yang saling melengkapi. Setiap percabangan membawa fokus berbeda — RealVNC mengejar pasar enterprise, TightVNC mengoptimalkan bandwidth, TigerVNC mengutamakan performa dan modernisasi, dan x11vnc mengkhususkan diri pada sharing display X11 yang sedang berjalan.

Evolusi VNC dalam satu garis
RFB (1990-an)  ->  RealVNC, TightVNC, TigerVNC, x11vnc  ->  w0vncserver, GNOME Remote Desktop

Jembatan ke Era Wayland

Perkembangan tidak berhenti di generasi pertama. Seiring Linux bertransisi dari X11 ke Wayland — yang akan kalian bedah di episode 17 — muncul turunan modern seperti w0vncserver dari TigerVNC dan GNOME Remote Desktop yang menyesuaikan diri dengan arsitektur baru. Ini bukti bahwa meskipun protokolnya berumur tiga dekade, ekosistemnya tetap hidup dan berkembang mengikuti arah platform.

Mengingat sejarah ini penting untuk pola pikir kalian: ketika menghadapi masalah remote desktop, jangan berpikir "tool mana yang paling terkenal", tapi "tool mana yang lahir dari kebutuhan yang sama dengan yang saya hadapi". Kerangka itulah yang akan kalian pakai di sepanjang series ini.

Penutup

Episode 1 memperlihatkan bahwa remote desktop adalah jawaban evolusioner atas pertanyaan lama: bagaimana manusia mengendalikan antarmuka grafis dari jarak jauh. Dari mainframe teks, X11 forwarding, kelahiran RFB/VNC oleh AT&T pada 1990-an, sampai RDP besutan Microsoft — masing-masing membawa filosofi desain yang menentukan perilakunya hari ini.

Inti yang harus dibawa pulang:

  • VNC lahir dari protokol RFB ciptaan AT&T; RDP lahir dari Microsoft.
  • VNC mengirim framebuffer piksel; RDP adalah protokol presentation bidirectional.
  • Port VNC dihitung dari display (5900 + nomor display); RDP di port 3389.
  • RDP lebih efisien di bandwidth rendah, VNC lebih cross-platform dan terbuka.
  • Pilih tool berdasarkan kebutuhan: bandwidth, fitur, dan platform client.

Di episode 2 selanjutnya kita akan membedah arsitektur dan cara kerja VNC/RDP secara mendalam — model server-to-client pada RFB, peran vncpasswd, mekanisme encoding seperti Tight, Hextile, dan ZRLE yang menentukan kualitas dan latensi, hingga cara kerja NLA pada RDP. Sampai jumpa di episode berikutnya!