Belajar Caddy - WebSocket & Real-time Applications

#Pendahuluan

Aplikasi modern butuh komunikasi dua arah secara real-time: chat, notifikasi, collaborative editing, game. Teknologi di baliknya adalah WebSocket — koneksi persisten di mana server bisa mengirim data tanpa diminta. Episode 25 membahas bagaimana Caddy menangani WebSocket.

Kabar baiknya: WebSocket di Caddy hampir tidak butuh konfigurasi. Caddy mendeteksi header upgrade dan mem-proxy koneksi secara otomatis. Tapi ada nuansa penting — timeout, buffer, load balancer, dan aplikasi seperti Socket.io yang perlu perhatian khusus.

Setelah episode ini, kalian bisa mengekspos aplikasi real-time apa pun ke internet dengan percaya diri.

#Dukungan WebSocket di Caddy

#Deteksi Otomatis

WebSocket dimulai sebagai request HTTP biasa dengan header upgrade:

chat.example.com {
    reverse_proxy localhost:9000
}

Caddy melihat header Upgrade: websocket dan Connection: Upgrade, lalu mengangkat koneksi menjadi full-duplex. Tidak ada directive khusus — reverse_proxy sudah cukup.

#Connection Upgrade dan Keep-Alive

• Upgrade: handshake mengubah protokol dari HTTP ke WebSocket.
• Keep-alive: koneksi dijaga hidup selama sesi, bisa berjam-jam.
• Buffering: Caddy meneruskan frame dua arah tanpa mengubah isi.

Selama proxy WebSocket aktif, Caddy mempertahankan koneksi ke backend selama klien terhubung. Inilah kenapa timeout untuk koneksi panjang perlu diperhatikan.

#Konfigurasi dan Pertimbangan

#Timeout untuk Koneksi Panjang

Koneksi WebSocket bisa bertahan sangat lama. Jika ada timeout yang memutus koneksi, periksa opsi transport:

chat.example.com {
    reverse_proxy localhost:9000 {
        transport http {
            read_timeout 1h
            write_timeout 1h
        }
    }
}

read_timeout 1h dan write_timeout 1h memberi kelonggaran untuk koneksi real-time. Default Caddy sudah ramah WebSocket, tapi jika koneksi terputus tiba-tiba, pastikan timeout tidak terlalu pendek.

#Header untuk Backend

Beberapa aplikasi butuh header tertentu. Misalnya aplikasi yang mengidentifikasi klien asli:

chat.example.com {
    reverse_proxy localhost:9000 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
    }
}

header_up X-Real-IP {remote_host} memberi aplikasi IP asli klien — penting untuk rate limiting di sisi aplikasi.

#Aplikasi WebSocket Umum

#Socket.io

Socket.io memakai WebSocket dengan protokol tambahan. Untuk integrasi penuh, konfigurasinya:

chat.example.com {
    reverse_proxy localhost:3000 {
        header_up X-Real-IP {remote_host}
    }
}

Socket.io juga menggunakan HTTP untuk handshake dan fallback polling. Karena Caddy mem-proxy keduanya dengan benar, tidak ada konfigurasi khusus yang dibutuhkan — reverse_proxy menangani handshake HTTP dan upgrade WebSocket sekaligus.

#Use Case Real-time

• Real-time chat: pesan instan antar pengguna.
• Live updates: harga saham, skor pertandingan, status order.
• Collaborative editing: dokumen yang diedit bersama (Google Docs style).
• Game servers: state game yang disinkronkan ke banyak klien.

Semua ini bekerja lewat satu directive reverse_proxy yang sama.

#Troubleshooting WebSocket

#Masalah Umum

• Connection timeout: periksa read_timeout dan write_timeout di transport.
• Proxy headers: pastikan aplikasi tahu IP asli via header_up.
• Load balancer: koneksi WebSocket panjang tidak cocok dengan round_robin jika aplikasi stateful — pertimbangkan sticky session (episode 15).
• Client compatibility: beberapa klien lama memakai fallback polling; pastikan tidak diblokir.

#Log dan Debug

Saat koneksi bermasalah:

caddy run --config Caddyfile --debug
curl -i -N -H "Connection: Upgrade" \
     -H "Upgrade: websocket" \
     -H "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==" \
     -H "Sec-WebSocket-Version: 13" \
     http://localhost/chat

curl -i -N -H "Connection: Upgrade" mensimulasikan handshake WebSocket secara manual. Jika respons menunjukkan 101 Switching Protocols, proxying bekerja. --debug menampilkan detail upgrade di log.

#Load Balancer dan WebSocket

#Pertimbangan Koneksi Panjang

Koneksi WebSocket tidak seperti request HTTP biasa yang selesai dalam milidetik. Pertimbangan saat memakai load balancing:

• Satu koneksi menempel lama ke satu backend — distribusi menjadi kurang merata.
• Aplikasi stateful dengan banyak sesi WebSocket sebaiknya memakai sticky session.
• Health check tetap berjalan — backend yang down tidak menerima koneksi baru, tapi koneksi yang ada akan terputus.

Untuk aplikasi stateless real-time, round_robin tetap baik. Untuk yang menyimpan state di memori, tambahkan lb_policy cookie (episode 15).

#Scaling Vertikal vs Horizontal

WebSocket identik dengan koneksi persisten yang memakai memori. Sebelum menambah banyak instance, pastikan aplikasi mendukung distribusi state (Redis pub/sub, shared store). Kalau tidak, banyak instance justru membuat sesi terpecah.

#Penutup

Episode 25 membahas WebSocket di Caddy: deteksi otomatis upgrade, reverse_proxy yang menangani koneksi full-duplex, aplikasi seperti Socket.io dan chat real-time, troubleshooting timeout dan header, serta pertimbangan load balancer untuk koneksi panjang.

Inti yang harus dibawa pulang:

• WebSocket di-proxy otomatis oleh reverse_proxy — tidak ada config khusus.
• Perhatikan read_timeout dan write_timeout untuk koneksi panjang.
• Socket.io bekerja tanpa konfigurasi tambahan.
• Sticky session membantu aplikasi stateful dengan banyak WebSocket.
• curl dengan header upgrade bisa menguji handshake.
• Scaling membutuhkan shared state agar sesi tidak terpecah.

Di episode 26 selanjutnya kita akan membahas gRPC & modern protocols — kebutuhan HTTP/2 untuk gRPC, reverse proxy dengan transport h2c, load balancing gRPC, gRPC-Web untuk browser, serta pengaktifan HTTP/3 (QUIC) dengan konfigurasi UDP port.