🔌
웹소켓(WebSocket)이란
한 번 연결을 맺으면 서버와 클라이언트가 계속 열려 있는 하나의 통로로 데이터를 양방향으로 주고받을 수 있게 해주는 프로토콜입니다.
일반 HTTP 통신은 클라이언트가 요청을 보내야만 서버가 응답하는 "요청-응답" 구조라, 서버가 먼저 클라이언트에게 새 정보를 알려줄 수 없습니다. 웹소켓은 이 한계를 넘어 연결이 유지되는 동안 서버와 클라이언트 어느 쪽이든 원할 때 자유롭게 메시지를 보낼 수 있는 실시간 양방향 통신을 제공합니다.
🔁
웹소켓 이전의 방식: 폴링
실시간처럼 보이는 기능을 흉내 내기 위해 클라이언트가 몇 초마다 반복해서 서버에 새 소식이 있는지 물어보는 방식이 폴링입니다.
짧은 폴링(short polling)은 일정 주기로 계속 요청을 보내 서버와 네트워크에 불필요한 부하를 주고, 롱 폴링(long polling)은 서버가 새 소식이 생길 때까지 응답을 미루는 방식으로 이를 다소 개선했지만, 여전히 매 요청마다 HTTP 헤더 오버헤드가 발생하고 완전한 양방향 통신은 아니었습니다. 웹소켓은 이런 반복 요청 없이 연결 하나로 문제를 해결합니다.
🤝
핸드셰이크와 프로토콜 업그레이드
웹소켓 연결은 일반 HTTP 요청으로 시작해, 서버가 이를 수락하면 같은 TCP 연결을 웹소켓 프로토콜로 "업그레이드"하는 방식으로 전환됩니다.
클라이언트가 `Upgrade: websocket` 헤더가 포함된 HTTP 요청을 보내고, 서버가 이를 받아들이면 HTTP 상태 코드 101(Switching Protocols)로 응답합니다. 이 순간부터 같은 연결이 더 이상 HTTP 요청-응답 방식이 아니라, 양쪽이 언제든 프레임을 주고받을 수 있는 웹소켓 연결로 바뀝니다.
🔒
ws:// 와 wss:// 의 차이
ws://는 암호화되지 않은 웹소켓, wss://는 TLS로 암호화된 웹소켓 연결을 의미하며 HTTP와 HTTPS의 관계와 같습니다.
일반 웹사이트에서 HTTPS를 쓰는 것처럼, 웹소켓도 민감한 데이터를 주고받는다면 반드시 wss://를 사용해 중간에서 데이터가 도청되거나 변조되지 않도록 해야 합니다. 대부분의 브라우저는 HTTPS로 접속한 페이지에서 암호화되지 않은 ws:// 연결 시도를 보안상의 이유로 차단합니다.
💬
실제 활용 사례
실시간 채팅, 주식·코인 시세 표시, 온라인 게임의 실시간 상태 동기화, 협업 문서의 동시 편집 반영 등에 널리 쓰입니다.
메신저 앱에서 상대방이 보낸 메시지가 새로고침 없이 바로 나타나는 것, 주식 차트의 실시간 가격이 계속 움직이는 것, 여러 명이 같은 문서를 동시에 편집할 때 서로의 커서와 수정 내용이 실시간으로 보이는 것 모두 웹소켓(또는 이와 유사한 실시간 기술)이 뒤에서 동작하고 있는 대표적인 예시입니다.
🆚
웹소켓과 대안 기술 비교
서버에서 클라이언트로만 실시간 데이터를 보내면 되는 경우에는 더 단순한 SSE(Server-Sent Events)가 대안이 될 수 있습니다.
SSE는 HTTP 위에서 서버가 클라이언트로 일방향으로 계속 데이터를 흘려보내는 기술로, 웹소켓보다 구현이 간단하고 기존 HTTP 인프라와도 잘 어울립니다. 반면 클라이언트도 서버에 자주 메시지를 보내야 하는 채팅이나 게임 같은 경우에는 양방향 통신이 가능한 웹소켓이 더 적합합니다.