WebSocket: ano ito, full-duplex communication protocol at paano ito gumagana

Ano ang WebSocket?

WebSocket — ay isang communication protocol na gumagana sa TCP at nagbibigay ng full-duplex channel sa pagitan ng client at server. Ito ay na-standardize ng IETF bilang RFC 6455 noong 2011 at sinusuportahan ng lahat ng modernong browser, mobile platform, at server frameworks.

Hindi tulad ng HTTP, kung saan ang client ay nag-initiate ng request at tumatanggap ng response, ang WebSocket ay nagpapahintulot sa parehong partido na magpadala ng mga mensahe anumang oras pagkatapos maitatag ang koneksyon. Ginagawa nitong perpekto para sa mga scenario na nangangailangan ng instant delivery ng data: mga chat, notification, collaborative document editing.

Ang WebSocket protocol ay gumagamit ng HTTP port 80 o HTTPS port 443 para sa initial handshake, pagkatapos ay lumipat sa sarili nitong protocol na may minimal na header — 2 bytes lamang sa halip na 800+ bytes sa HTTP. Ang feature na ito ay nagbibigay ng makabuluhang performance advantage sa maraming bilang ng mga mensahe.

Mga pangunahing katangian ng protocol

Ang WebSocket connection ay nagsisimula sa HTTP Upgrade request, pagkatapos ay lumipat ang protocol sa binary frame format. Ang laki ng frame ay nag-iiba mula 2 bytes hanggang 2^63 bytes, na nagpapahintulot sa pagpapadala ng parehong maikling text messages at malalaking binary data. Ang fragmentation ng mensahe, masking ng data mula client papunta server, at ping/pong para sa pagpapanatili ng koneksyon ay sinusuportahan.

Paano gumagana ang WebSocket?

Ang proseso ng pagtatag ng WebSocket connection ay binubuo ng dalawang yugto: handshake at data transmission. Sa yugto ng handshake, ang client ay nagpapadala ng HTTP request na may header na Upgrade: websocket, at kinumpirma ng server ang paglipat ng protocol na may status na 101 Switching Protocols. Pagkatapos nito, ang koneksyon ay pumapasok sa full-duplex transmission mode.

Ang bawat mensahe sa WebSocket ay hinahati sa mga frame. Ang frame ay naglalaman ng opcode (text, binary data, closure, ping/pong), haba ng payload, at masking key para sa data mula sa client. Ang frame ay maaaring i-fragment — ang control frames (ping/pong) ay maaaring ipadala sa pagitan ng mga fragment ng mensahe, na pumipigil sa pagkaputol ng koneksyon sa mahabang transmission.

const ws = new WebSocket('wss://example.com/chat')

ws.addEventListener('open', () => {
    console.log('Naitatag ang koneksyon')
    ws.send('Kumusta server!')
})

ws.addEventListener('message', (event) => {
    console.log('Natanggap:', event.data)
})

ws.addEventListener('close', () => {
    console.log('Sarado ang koneksyon')
})

Sa halimbawa sa itaas, ang client ay gumagawa ng WebSocket object, na nagtutukoy ng secure na URL na wss://. Pagkatapos magbukas ng koneksyon, isang welcome message ang ipinapadala, at ang message handler ay tumatanggap ng mga tugon mula sa server. Sa pagsasara, ang close handler ay naa-activate — ito ay mahalaga para sa muling pagkonekta kapag naputol ang network.

WebSocket vs HTTP: paghahambing

Ang pangunahing pagkakaiba sa pagitan ng WebSocket at HTTP ay nasa modelo ng interaksyon. Ang HTTP ay gumagana sa request-response scheme: ang client ay nag-initiate ng request, ang server ay nagbabalik ng response, ang koneksyon ay sarado. Ang WebSocket naman ay nagtatag ng permanenteng channel kung saan ang parehong partido ay maaaring mag-initiate ng transmission anumang oras.

Para sa mga application na nangangailangan ng mababang latency at patuloy na daloy ng data, ang WebSocket ay mas mahusay. Ang HTTP Long Polling — isang alternatibo kung saan pinapanatili ng server ang request na bukas hanggang sa lumitaw ang data — ay lumilikha ng labis na load sa server at nagpapataas ng memory consumption dahil sa maraming sabay-sabay na koneksyon.

Ayon sa High Performance Browser Networking (Grigorik, O’Reilly), ang WebSocket ay nagpapababa ng network latency sa real-time na mga scenario ng 40–60% kumpara sa HTTP Long Polling, at ang server load ay nababawasan ng 3–5 beses dahil sa pag-aalis ng paulit-ulit na handshake.

Saan ginagamit ang WebSocket

Dahil sa mababang latency at bidirectional na komunikasyon, ang WebSocket ay ginagamit sa malawak na hanay ng mga application. Ang mga pangunahing scenario ay kinabibilangan ng instant messaging, state synchronization sa mga laro, at pagpapadala ng market data sa mga financial system.

Mga chat at messenger

Ang WebSocket ay naging de facto standard para sa mga chat application. Ang mga platform tulad ng Slack, Telegram Web, at WhatsApp Web ay gumagamit ng WebSocket para sa instant delivery ng mga mensahe. Ang protocol ay nagpapahintulot sa pagpapadala ng parehong text messages at files sa pamamagitan ng isang channel, at ang ping/pong mechanism ay nagpapanatili ng koneksyon na aktibo kahit walang aktibidad.

Online games

Ang multiplayer browser at mobile games ay nangangailangan ng minimal na latency para sa synchronization ng estado ng mga manlalaro. Ang WebSocket ay nagpapadala ng mga coordinate, aksyon, at events sa real-time nang walang latency ng HTTP requests. Ang mga frameworks tulad ng Socket.IO at Colyseus ay nag-aabstrak ng mababang-level na trabaho sa protocol, nagdaragdag ng automatic reconnection at rooms.

Financial applications

Ang stock market terminals at trading platforms ay gumagamit ng WebSocket para sa pagtanggap ng real-time na mga quote. Ang latency na ilang millisecond ay maaaring magkakahalaga ng milyun-milyong dolyar, kaya ang financial APIs — halimbawa, Binance WebSocket Streams, Coinbase Pro — ay nagbibigay ng WebSocket interfaces para sa market data.

Mobile applications at IoT

Sa mobile development, ang WebSocket ay ginagamit sa pamamagitan ng native APIs: URLSessionWebSocketTask sa iOS at OkHttp WebSocket sa Android. Para sa Flutter mayroong web_socket_channel library, at para sa React Native — react-native-websocket. Ang IoT devices ay gumagamit ng WebSocket para sa pagpapadala ng telemetry at pagtanggap ng control commands, dahil ang protocol ay kumukonsumo ng mas kaunting enerhiya kaysa sa patuloy na HTTP-polling.

Mga halimbawa ng code ng WebSocket

Tingnan natin ang halimbawa ng server side sa Node.js na may ws library — ang pinakasikat na implementasyon ng WebSocket para sa JavaScript. Ang server ay tumatanggap ng mga koneksyon, nagpoproseso ng mga mensahe, at nagbo-broadcast ng mga ito sa lahat ng konektadong clients.

const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })

wss.on('connection', (ws) => {
    console.log('Bagong client na konektado')

    ws.on('message', (data) => {
        console.log('Natanggap:', data.toString())
        ws.send('Tinanggap ng server ang iyong mensahe')
    })

    ws.on('close', () => {
        console.log('Nag-disconnect ang client')
    })
})

console.log('WebSocket server na pinasimulan sa port 8080')

Ang server ay gumagawa ng WebSocket.Server instance sa port 8080 at naghihintay ng mga koneksyon. Ang bawat bagong client ay binibigyan ng hiwalay na ws object, kung saan ang server ay maaaring magpadala ng mga indibidwal na mensahe. Ang broadcasting ng mga mensahe sa lahat ng clients ay ginagawa sa pamamagitan ng mass iteration ng connections array. Sa maraming bilang ng clients (higit sa 1000), inirerekomenda ang paggamit ng mga library na may clustering support tulad ng Socket.IO, na nagdaragdag ng scaling sa pamamagitan ng Redis at automatic reconnection.

Pagpapadala ng mensahe sa lahat ng clients

wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
        client.send('Mensahe para sa lahat ng kalahok')
    }
})

Ang pagsusuri ng readyState bago magpadala ay kinakailangan: kung ang client ay naka-disconnect na, ang send call ay magbibigay ng error. Ang flag na WebSocket.OPEN ay ginagarantiyahan na ang koneksyon ay aktibo at ang mensahe ay maihahatid.

Para sa mobile iOS applications, ang WebSocket ay ini-implement sa pamamagitan ng URLSessionWebSocketTask, available mula iOS 13. Ang session ay gumagawa ng task na may URL ng wss:// protocol, pagkatapos ang send at receive methods ay tinatawag. Ang pagtanggap ng mga mensahe ay maaaring i-organisa sa pamamagitan ng patuloy na receive recursion, na naghihintay ng susunod na mensahe pagkatapos iproseso ang nauna, na tinitiyak ang patuloy na pagtanggap ng data nang walang muling pagkonekta. Para sa Android, ginagamit ang OkHttp WebSocket, na nagbibigay ng katulad na interface na may mga callback na onOpen, onMessage, onClosing, at onClosed, pati na rin ang automatic reconnection kapag naputol ang koneksyon.

Sa pagtatrabaho sa WebSocket sa mobile applications, mahalagang isaalang-alang ang lifecycle management: kapag ang app ay pumunta sa background, ang koneksyon ay maaaring maputol ng system. Sa iOS, kailangan muling itatag ang koneksyon kapag bumalik sa foreground sa pamamagitan ng delegate na sceneDidBecomeActive. Sa Android, dapat gumamit ng Lifecycle-aware components o Service para mapanatili ang koneksyon. Dagdag pa, inirerekomenda na i-implement ang exponential backoff sa muling pagkonekta — pagtaas ng interval sa pagitan ng mga pagtatangka mula 1 hanggang 30 segundo, upang hindi lumikha ng labis na load sa server sa pansamantalang network problems.