WebSocket, pipa dua arah yang bisa didorong server.

HTTP polos punya satu bentuk: klien bertanya, server menjawab (model request-response bab HTTP). Server tidak pernah bisa bicara duluan, ia tidak punya cara mendorong data ke klien yang belum baru saja meminta. Itu baik untuk mengambil halaman atau memanggil API, tapi hancur begitu Anda butuh server memberi tahu klien saat hal terjadi: pesan chat baru, tick harga langsung, notifikasi, kursor kolaborator bergerak, kecocokan ditemukan. Server punya pembaruannya; HTTP tidak memberinya kanal untuk mengirimkannya.

Sebelum WebSocket, Anda memalsukan server push dengan menyuruh klien bertanya berulang-polling. Setiap beberapa detik klien mengirim "ada yang baru?" dan biasanya mendengar "tidak." Ini boros di setiap sumbu: banjir request yang kebanyakan tidak mengembalikan apa pun, overhead penuh header HTTP dan setup koneksi di tiap request, dan latensi dibatasi interval polling Anda (poll tiap 5 detik dan event bisa duduk tak terkirim hampir 5 detik). WebSocket ada untuk mengganti hack itu dengan koneksi persisten dua arah yang nyata tempat kedua sisi bisa mengirim kapan saja.

WebSocket bukan satu-satunya cara mendapat pembaruan server-ke-klien, dan meraihnya secara refleks kesalahan umum. Ada spektrum teknik, masing-masing titik berbeda pada kompromi antara kesederhanaan dan kemampuan. Mengetahui keempatnya membuat Anda memilih hal paling sederhana yang memenuhi kebutuhan (panduan keputusan penuh di bagian 18).

WebSocket kanal komunikasi persisten, dua arah, full-duplex di atas satu koneksi TCP, dibangun lewat request HTTP lalu dipegang terbuka. Urai tiap kata: persistent, dibuka sekali dan dipegang untuk sesi, bukan per pesan; bidirectional / full-duplex, kedua sisi bisa mengirim serentak dan independen, bukan bergiliran; single TCP connection, satu socket membawa segalanya, di port yang sama dengan HTTP (80/443), jadi ia melewati firewall yang mengizinkan lalu lintas web.

Pilihan desain yang cerdas: WebSocket memulai hidup sebagai request HTTP lalu meng-upgrade (bagian 4). Ini bukan kebetulan, inilah yang membuat WebSocket memakai ulang infrastruktur web yang ada (port, TLS, proxy, origin yang sama) alih-alih butuh port atau protokol baru yang akan diblokir firewall. Setelah di-upgrade, koneksi berhenti bicara HTTP dan mulai bicara protokol framing WebSocket (bagian 5). Skema URL mencerminkan ini: ws:// (seperti http://) dan wss:// (TLS, seperti https://).

Setiap WebSocket dimulai dengan satu request HTTP khusus, upgrade handshake (bab HTTP bagian 19, lengkap). Klien mengirim GET yang tampak normal dengan header yang berbunyi "aku ingin mengalihkan koneksi ini ke protokol WebSocket." Jika server setuju, ia membalas dengan status 101 Switching Protocols: bukan 200, dan sejak instan itu koneksi bukan lagi HTTP; ia WebSocket mentah yang membawa frame (bagian 5).

GET /ws/chat HTTP/1.1
Host: api.example.com
Upgrade: websocket                              <- "switch this connection"
Connection: Upgrade                             <- the Upgrade header is meaningful
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==     <- a random client nonce (base64)
Sec-WebSocket-Version: 13                        <- the protocol version
Sec-WebSocket-Protocol: chat.v1                  <- optional subprotocol(s) offered
Origin: https://app.example.com                  <- the browser sends this; SERVER must check (sec 14)

HTTP/1.1 101 Switching Protocols                <- NOT 200, the upgrade succeeded
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  <- proves the server spoke WebSocket
Sec-WebSocket-Protocol: chat.v1                  <- the subprotocol the server picked

# After 101, both sides stop speaking HTTP and start exchanging WebSocket frames.

Apa yang dibuktikan Sec-WebSocket-Accept

Server menghitung Accept dengan menggabungkan Sec-WebSocket-Key klien dengan GUID ajaib tetap yang didefinisikan spesifikasi, meng-hash SHA-1, dan meng-encode base64 hasilnya. Ini bukan keamanan, GUID-nya publik, ia bukti pemahaman protokol: mengonfirmasi penjawabnya server WebSocket asli dan bukan cache atau proxy yang membuta menggema 101. Klien memverifikasi nilainya cocok sebelum memperlakukan koneksi sebagai WebSocket yang bekerja. Library melakukan ini untuk Anda; Anda hampir tidak pernah menghitungnya manual.

Setelah handshake, data tidak mengalir sebagai aliran byte mentah, ia dipotong menjadi frame, unit terstruktur kecil dengan header ringkas. Framing yang membuat satu koneksi bisa membawa pesan diskret (jadi penerima tahu di mana satu berakhir dan berikutnya mulai), membedakan teks dari biner, mengirim sinyal kontrol seperti close dan ping, dan memecah pesan besar lintas beberapa frame. Anda jarang menyentuh frame langsung, library mengekspos "kirim pesan / terima pesan", tapi memahami strukturnya menjelaskan masking, tipe pesan, dan frame kontrol.

Teks vs biner, dan kenapa frame klien di-mask

• Dua tipe data. Sebuah frame entah text (UTF-8, JSON biasanya menumpang di sini) atau binary (byte mentah, Protobuf, gambar, format kustom). Library menyerahkan string atau byte sesuai.
• Masking wajib klien->server, dilarang server->klien. Browser XOR-mask setiap frame yang mereka kirim dengan kunci acak. Ini bukan enkripsi (pakai wss:// untuk itu, bagian 14); itu mitigasi keamanan supaya halaman jahat tidak bisa meracik byte yang membingungkan proxy perantara lama menjadi salah mem-parse aliran sebagai hal lain (cache poisoning). Frame server tidak pernah di-mask.
• Fragmentasi. Pesan besar bisa dipecah menjadi urutan frame (FIN=0 di semua kecuali yang terakhir, opcode 0x0 continuation di yang tengah), membuat pengirim bisa men-stream tanpa mem-buffer semuanya dulu.

WebSocket punya hidup yang jelas: buka -> tukar pesan -> tutup, dengan event di tiap tahap yang di-hook kode Anda. Open selesai setelah handshake (bagian 4). Lalu pesan mengalir bebas. Menutup sendiri handshake kecil: satu sisi mengirim close frame (opcode 0x8) yang membawa status code dan alasan opsional, sisi lain menggema close frame, lalu keduanya mematikan koneksi TCP. Close yang bersih membuat tiap sisi tahu kenapa koneksi berakhir.

Karena koneksi mati sering tampak identik dengan yang idle (tanpa byte di keduanya), Anda butuh cara aktif membedakan "masih hidup" dari "pergi diam-diam." Protokol menyediakan frame kontrol ping dan pong persis untuk ini: satu sisi mengirim ping, yang lain harus menjawab pong. Heartbeat pola mengirim ping pada timer dan memperlakukan pong yang terlewat (dalam batas waktu) sebagai koneksi mati yang harus ditutup dan dibersihkan. Ini masalah liveness yang sama dengan probe Kubernetes (containerization bagian 17) dan keepalive consumer Kafka, dipecahkan dengan gagasan yang sama: jangan asumsikan sehat, verifikasi.

Endpoint server melakukan tiga hal: menerima upgrade (bagian 4), lalu menjalankan loop membaca pesan dan cara menulisnya. Di Go library standar tidak mengirim implementasi WebSocket, jadi Anda memakai library, gorilla/websocket (standar lama) atau coder/websocket (nhooyr). Di Python, framework seperti FastAPI/Starlette mengekspos WebSocket langsung, dan library websockets standar mandirinya. Ini server echo minimal, "hello world"-nya WebSocket.

// github.com/gorilla/websocket
var upgrader = websocket.Upgrader{
    // CheckOrigin guards against cross-site hijacking, DO NOT leave it open (sec 14).
    CheckOrigin: func(r *http.Request) bool {
        return r.Header.Get("Origin") == "https://app.example.com"
    },
}

func wsHandler(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil) // performs the 101 handshake (sec 4)
    if err != nil {
        return // upgrader already wrote an HTTP error
    }
    defer conn.Close() // always close -> frees the socket (sec 19)

    for { // the READ LOOP, one per connection
        mt, msg, err := conn.ReadMessage()
        if err != nil {
            break // client closed or connection died (sec 6) -> exit, cleanup via defer
        }
        // echo it straight back
        if err := conn.WriteMessage(mt, msg); err != nil {
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", wsHandler) // a normal HTTP route that upgrades
    http.ListenAndServe(":8080", nil)
}

# FastAPI / Starlette expose WebSockets natively (the `websockets` lib is an alternative).
from fastapi import FastAPI, WebSocket, WebSocketDisconnect

app = FastAPI()

@app.websocket("/ws")
async def ws_handler(ws: WebSocket):
    # Validate origin yourself before accepting (sec 14); then complete the handshake.
    await ws.accept()                      # performs the 101 handshake (sec 4)
    try:
        while True:                        # the READ LOOP, one coroutine per connection
            msg = await ws.receive_text()  # awaits the next message
            await ws.send_text(msg)        # echo it straight back
    except WebSocketDisconnect:
        pass                               # client closed or connection died (sec 6)
    # FastAPI cleans up the connection when the coroutine returns

# uvicorn app:app, uvicorn speaks the WebSocket protocol for you

Go memberi tiap koneksi goroutine yang menjalankan loop baca blocking; Python memberi tiap koneksi coroutine async yang menunggu pesan. Struktur sama, terima, loop membaca, tulis, diekspresikan dalam model konkurensi tiap bahasa.

Backend sering juga klien WebSocket, mengonsumsi feed real-time dari layanan lain, menjembatani sistem, atau dalam tes. Sisi klien: dial URL ws:///wss:// (yang melakukan handshake), lalu baca dan tulis pesan. Bentuknya mencerminkan server.

// github.com/gorilla/websocket
func runClient() {
    // Dial performs the upgrade handshake; header carries auth where allowed (sec 13).
    h := http.Header{"Authorization": {"Bearer " + token}}
    conn, _, err := websocket.DefaultDialer.Dial("wss://api.example.com/ws", h)
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    // reader goroutine
    go func() {
        for {
            _, msg, err := conn.ReadMessage()
            if err != nil {
                return
            }
            log.Printf("recv: %s", msg)
        }
    }()

    // send a message
    conn.WriteMessage(websocket.TextMessage, []byte(`{"type":"hello"}`))

    // graceful close: send a close frame, then the socket shuts (sec 6)
    conn.WriteMessage(websocket.CloseMessage,
        websocket.FormatCloseMessage(websocket.CloseNormalClosure, "bye"))
}

# `websockets` library, clean async client
import asyncio, websockets

async def run_client():
    # extra_headers carries auth where the runtime allows it (sec 13);
    # browsers can't set headers, but a backend client can.
    async with websockets.connect(
        "wss://api.example.com/ws",
        extra_headers={"Authorization": f"Bearer {token}"},
    ) as ws:                                 # context manager -> handshake + clean close
        await ws.send('{"type":"hello"}')    # send a message

        async for msg in ws:                 # iterate incoming messages
            print("recv:", msg)
    # leaving the `async with` block sends a close frame and shuts down (sec 6)

asyncio.run(run_client())

Satu koneksi sepele; kerja nyata mengelola banyak. Server yang memegang ribuan koneksi live butuh tempat terpusat yang melacak siapa yang terhubung supaya bisa merutekan dan menyiarkan pesan. Solusi kanonis hub (atau "connection manager"): pemilik tunggal dari set koneksi aktif, dengan channel/lock untuk mendaftar, mencabut, dan mengirim, menghindari bahaya tulis-serentak dari bagian 8 dengan menyaring semua lewat satu koordinator.

type Hub struct {
    clients    map[*Client]bool
    register   chan *Client
    unregister chan *Client
    broadcast  chan []byte
}

// One goroutine owns the map -> all mutation is serialized here (no locks needed).
func (h *Hub) Run() {
    for {
        select {
        case c := <-h.register:
            h.clients[c] = true
        case c := <-h.unregister:
            if _, ok := h.clients[c]; ok {
                delete(h.clients, c)
                close(c.send) // tell the client's writer goroutine to stop
            }
        case msg := <-h.broadcast:
            for c := range h.clients {
                select {
                case c.send <- msg:        // queue into the client's buffered channel
                default:                   // buffer full -> slow client; drop it (sec 12)
                    delete(h.clients, c)
                    close(c.send)
                }
            }
        }
    }
}

import asyncio

class Hub:
    def __init__(self):
        self.clients: set[WebSocket] = set()   # the active connection set

    async def register(self, ws: WebSocket):
        await ws.accept()
        self.clients.add(ws)

    def unregister(self, ws: WebSocket):
        self.clients.discard(ws)               # idempotent removal

    async def broadcast(self, message: str):
        dead = []
        for ws in self.clients:
            try:
                await ws.send_text(message)     # fan out to everyone
            except Exception:
                dead.append(ws)                 # send failed -> connection is gone
        for ws in dead:
            self.unregister(ws)                 # clean up on the way out

hub = Hub()
# (asyncio is single-threaded, so the set needs no lock; just don't mutate
#  it while iterating, collect dead ones, remove after.)

Aplikasi nyata jarang mengirim ke semua orang, mereka mengirim ke subset relevan: anggota satu ruang chat, subscriber satu simbol saham, pemain satu game. Polanya room (alias channel atau topic): koneksi berlangganan ke grup bernama, dan Anda broadcast ke grup alih-alih seluruh server. Secara konkret, hub memegang map dari nama room ke set koneksi di dalamnya.

Mode kegagalan unik sistem push: apa yang terjadi saat Anda memproduksi pesan lebih cepat daripada yang bisa diterima klien? Ponsel di koneksi lemah, tab browser di-throttle di latar, klien menguras perlahan sementara server terus menghasilkan data untuknya. Tanpa rencana, data itu menumpuk di buffer per-klien yang tumbuh tanpa batas, dan satu klien lambat bisa menghabiskan memori server. Ini backpressure, dan Anda harus memutuskan kebijakan.

Implementasi standar (terlihat di hub bagian 10): beri tiap klien antrean kirim yang terbatas. Saat Anda mencoba enqueue dan penuh, Anda tidak memblokir broadcaster (itu akan membiarkan satu klien lambat menahan semua orang), gantinya Anda menerapkan kebijakan:

• Jatuhkan pesan: untuk data lossy yang hanya yang terbaru penting (posisi live, ticker), buang kelebihannya atau simpan hanya yang terbaru. Klien lambat melewatkan beberapa pembaruan tapi server tetap sehat.
• Putuskan klien: untuk data yang celahnya tak bisa diterima, tutup koneksi lambat dan biarkan ia terhubung ulang dan menyinkronkan ulang (bagian 17). Lebih baik menjatuhkan satu klien daripada menurunkan semua.
• Konflasi / batch: runtuhkan beberapa pembaruan tertunda menjadi satu (kirim snapshot terbaru alih-alih setiap langkah perantara).

Mengautentikasi WebSocket lebih rumit daripada request normal karena keterbatasan browser dari bagian 4: konstruktor WebSocket JavaScript tidak bisa men-set header kustom, jadi Authorization: Bearer biasa tidak tersedia dari browser. Anda mengautentikasi di handshake (ia tetap request HTTP, server bisa membaca cookie, URL, dan subprotokol) dan Anda melakukannya sebelum memanggil Upgrade/accept. Prinsip dari bab auth berlaku: verifikasi identitas di pintu; socket yang tidak terautentikasi tidak boleh pernah di-upgrade.

func wsHandler(w http.ResponseWriter, r *http.Request) {
    // AUTHENTICATE FIRST, before upgrading. Reject with a normal HTTP error.
    token := r.URL.Query().Get("token")          // or read a cookie / subprotocol
    user, err := verifyJWT(token)                 // your auth logic (auth chapter)
    if err != nil {
        http.Error(w, "unauthorized", http.StatusUnauthorized) // 401, no upgrade
        return
    }
    // Only now perform the upgrade; attach the identity to the connection.
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        return
    }
    serve(conn, user) // every message from this conn is now tied to `user`
}

@app.websocket("/ws")
async def ws_handler(ws: WebSocket):
    # AUTHENTICATE FIRST, before accept(). Close with a policy code if it fails.
    token = ws.query_params.get("token")          # or a cookie / subprotocol
    user = verify_jwt(token)                       # your auth logic (auth chapter)
    if user is None:
        await ws.close(code=1008)                  # 1008 = policy violation; no accept
        return
    await ws.accept()                              # only now complete the handshake
    await serve(ws, user)                          # messages are tied to `user`

WebSocket mewarisi model ancaman web plus beberapa miliknya sendiri. Prinsip bab keamanan berlaku langsung; ini esensial khusus WebSocket.

Ini masalah sulit yang mendefinisikan WebSocket, dan alasan ia memperumit arsitektur jauh lebih banyak daripada HTTP stateless. Koneksi WebSocket ber-state dan ter-pin ke satu server: socket hidup di memori instance spesifik tempat klien terhubung. Begitu Anda menjalankan lebih dari satu instance, yang harus Anda lakukan demi kapasitas dan ketersediaan, muncul pertanyaan menyakitkan: jika user A terhubung ke server 1 dan user B (di room chat yang sama) terhubung ke server 2, bagaimana pesan A mencapai B? Server 1 tidak punya akses ke koneksi server 2.

Solusinya backplane (alias adapter pub/sub): sistem pesan eksternal yang dihubungi semua instance server. Saat server perlu mengirim pesan ke klien yang mungkin di instance mana pun, ia menerbitkan pesan ke backplane; setiap instance berlangganan, menerimanya, dan meneruskannya ke koneksi lokal mana pun yang seharusnya menerimanya. Instance tidak lagi perlu tahu koneksi satu sama lain, mereka berkoordinasi lewat bus bersama. Backplane umum:

• Redis Pub/Sub: pilihan paling umum: sederhana, cepat, latensi rendah, fire-and-forget. Pas saat Anda hanya butuh fan-out live dan tidak butuh riwayat (user yang terputus cukup melewatkan pesan).
• Kafka: saat Anda juga ingin daya tahan, replay, dan event-nya memberi makan sistem lain (bab Kafka): terbitkan event ke topic, tiap instance WS mengonsumsi dan meneruskan. Lebih berat, tapi pesannya jadi bagian stream event tahan lama Anda.
• NATS / pub/sub cloud, opsi messaging cepat lain dengan mekanik serupa.

Menaruh load balancer di depan server WebSocket punya kerutannya sendiri, karena koneksinya panjang umur dan ber-state alih-alih request cepat. Tiga hal yang penting: LB harus mendukung WebSocket, koneksi biasanya butuh affinity, dan deploy harus menguras koneksi dengan anggun.

• LB harus bicara WebSocket. Ia harus meneruskan handshake Upgrade lalu menjaga koneksi tetap terbuka (proxy sadar L7/HTTP, atau pass-through TCP L4). Kebanyakan LB modern (Nginx, HAProxy, ALB cloud, controller Ingress Kubernetes bab 21) mendukung ini, tapi Anda mengonfigurasi idle timeout lebih panjang, idle timeout 60 detik default akan membunuh WebSocket yang sunyi, alasan lain untuk heartbeat (bagian 7).
• Sticky session / affinity. Begitu klien terhubung ke instance 1, semua frame-nya harus terus pergi ke instance 1 (di sanalah socket-nya hidup). Dengan TCP mentah itu otomatis (satu koneksi = satu backend), tapi koneksi ulang dan routing per-pesan menginginkan session affinity supaya klien kembali ke instance yang konsisten. Dengan backplane (bagian 15) affinity kurang penting untuk pengiriman (instance mana pun bisa publish/menerima), tapi ia tetap memengaruhi state lokal.
• Connection draining saat deploy. Yang besar: deploy versi baru (rolling update bab 21 bagian 18) menghentikan instance, dan setiap WebSocket di instance yang dihentikan jatuh. Anda harus menguras dengan anggun, berhenti menerima koneksi baru, kirim close frame (code 1001 "going away") supaya klien terhubung ulang bersih ke instance sehat, dan beri waktu sebelum SIGKILL (bab graceful shutdown). Meski begitu, deploy menyebabkan badai reconnection, itulah kenapa reconnection klien yang kokoh (bagian 17) wajib.

Mengingat semua di atas, koneksi jatuh diam-diam (bagian 6), deploy memutus semua orang (bagian 16), jaringan berisik, klien real-time yang tidak terhubung ulang otomatis rusak sejak desain. Ketahanan hidup kebanyakan di sisi klien, dengan dukungan sisi server untuk menyinkronkan ulang state yang terlewat. (Catatan: SSE memberi Anda reconnection gratis, alasan lain untuk memilihnya saat Anda hanya butuh server push, bagian 2.)

Checklist ketahanan

• Terhubung ulang dengan exponential backoff + jitter. Jangan menghantam server yang kesulitan dengan retry instan; kembangkan jeda (1s, 2s, 4s, ... dibatasi) dan tambah keacakan supaya ribuan klien yang terputus oleh deploy tidak terhubung ulang di instan yang sama (masalah thundering-herd / reconnect-storm dari bagian 16).
• Sinkronkan ulang setelah reconnect. Koneksi baru berarti kemungkinan celah di stream. Saat reconnect, klien harus mendamaikan: ambil state saat ini via panggilan HTTP normal, atau beri tahu server "event terakhir yang kulihat N, kirim aku semua sejak itu" (resume token / nomor urut). Di sinilah backplane tahan lama seperti Kafka (bagian 15) bersinar, pesan yang terlewat masih di log untuk diputar ulang.
• Putuskan jaminan pengiriman Anda. Seperti Kafka (bagian 9), pengiriman WebSocket tidak ajaib exactly-once. Untuk data kritis, beri pesan nomor urut/ID supaya klien bisa mendeteksi celah dan duplikat, dan buat penanganan idempotent. Untuk data lossy (posisi live), celah tidak masalah, pembaruan berikutnya mengoreksinya.
• Buffer keluar di klien saat terputus (dalam batas), dan flush saat reconnect, supaya aksi pengguna yang dilakukan selama blip tidak sekadar hilang.

Keputusan yang harus datang sebelum Anda membangun apa pun real-time. WebSocket kuat tapi membawa beban operasional Bagian IV (koneksi ber-state, backplane, sticky session, reconnection), jadi memilih tool paling sederhana yang cocok penghematan nyata. Empat penantang, menyatukan spektrum (bagian 2) dan bab gRPC.

Mode kegagalan yang menggigit server WebSocket di produksi, kebanyakan soal manajemen resource untuk koneksi panjang umur ber-state, disiplin yang tidak pernah dituntut HTTP stateless.

Menarik manual ke penilaian desain untuk apa pun real-time.

Prinsip desain

• Pilih transport paling ringan dulu. Polling -> SSE -> WebSocket -> gRPC streaming, paling kiri yang cocok (bagian 18). Jangan bayar kompleksitas WebSocket kecuali Anda butuh lalu lintas browser dua arah.
• Rancang backplane sejak hari pertama jika Anda akan pernah menjalankan lebih dari satu instance, yang selalu, di produksi (bagian 15). Meretrofit pengiriman lintas-instance ke desain satu-instance menyakitkan.
• Perlakukan disconnect sebagai normal. Heartbeat untuk mendeteksinya (bagian 7), drain anggun saat deploy (bagian 16), reconnection klien dengan backoff + jitter dan re-sync state (bagian 17). Koneksi akan bergejolak; bangun untuk itu.
• Batasi semuanya per koneksi. Ukuran buffer kirim, ukuran pesan, tingkat pesan, koneksi per pengguna (bagian 12, bagian 14, bagian 19). Apa pun tak terbatas pemadaman yang menunggu satu klien buruk.
• Jangan asumsikan pengiriman andal, terurut, exactly-once. Tambah nomor urut/ID untuk deteksi celah dan penanganan idempotent di tempat yang penting; terima kehilangan di tempat yang tidak (bagian 17, menggema Kafka bagian 9).
• Autentikasi di handshake, otorisasi setiap pesan, amankan kanalnya. wss://, pemeriksaan origin, pesan masuk divalidasi (bagian 13-14).
• Jaga loop baca cepat; geser kerja nyata ke antrean/worker (bab 10), dan seriakan tulis lewat satu writer per koneksi (bagian 8).

Seluruh manual dipadatkan menjadi yang Anda raih saat tertekan.