Websocket이 태어난 배경
WebSocket은 HTTP와는 구분되는 별도의 통신 프로토콜이지만 HTTP를 기반으로 동작한다.
HTTP는 단방향 통신을 지원하는 프로토콜이므로 서버에서 클라이언트로 데이터를 보내기 위해서는 클라이언트가 주기적으로 서버에 요청을 보내야 했다.
WebSocket은 이런 한계를 극복하기 위해 개발된 프로토콜로, 양방향 통신을 지원한다. WebSocket 연결이 수립되면 서버와 클라이언트는 TCP 연결을 유지하면서 실시간으로 데이터를 주고받을 수 있다. 이를 통해 서버에서 클라이언트로 데이터를 푸시하는 등의 실시간 통신이 가능해진다.
WebSocket 연결은 HTTP로 시작되는데, 클라이언트가 HTTP 요청을 서버에 보내고, 서버는 요청을 받아 WebSocket 연결을 수립한다. 하지만 WebSocket 연결이 확립되면, 이후의 통신은 HTTP와는 별도의 프로토콜인 WebSocket 프로토콜을 따른다. 그래서 WebSocket은 HTTP와 구분되는 별도의 통신 프로토콜이다.
WebSocket Connection | HTTP Connection |
양방향(전이중) 통신 프로토콜(Server도 Client에게 요청을 보낼 수 있고, 계속 연결을 유지하고 실시간 데이터 주고 받음) | 단방향 프로토콜(Client가 요청을 보내는 경우에만 Server가 응답) |
이미 수립된 연결 채널을 사용하여 데이터를 전송한다. 연결은 클라이언트 또는 서버 중 한 쪽에서 종료될 때까지 유지 |
HTTP 요청 메서드를 사용하여 연결을 생성하고, 응답을 받은 후에 HTTP 연결이 닫힌다. |
거래, 모니터링, 알림 등과 같은 대부분의 실시간 애플리케이션에 사용 | 간단한 RESTful 애플리케이션에 상태를 유지하지 않는 HTTP 프로토콜을 사용 |
HTTP 연결보다 빠르기 때문에 자주 업데이트되는 애플리케이션들은 Websocket을 사용한다. | 특정 시간 동안 연결을 유지하거나 데이터 전송을 위해 연결을 재사용하지 않고자 할 때, HTTP 연결은 WebSocket에 비해 느릴 수 있다. |
Websocket의 정의
웹소켓은 전이중통신(Full-Duplex Communication)을 지원한다.
웹소켓으로 연결된 서버와 클라이언트는 각 주체가 요청과 응답없이 능동적으로 메시지를 보낼 수 있다.
따라서 웹소켓은 전이중통신과 실시간 네트워킹이 보장되어야 하는 환경에서 유용하게 사용할 수 있다.
동작원리
1. 연결 수립
최초 연결 요청 시에 클라이언트에서 HTTP를 통해 웹서버에 요청한다. 이를 핸드셰이크(Handshake)라고 한다.
핸드셰이크를 위해 클라이언트는 서버에 아래와 같은 요청(HTTP Upgrade)을 보낸다.
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
서버는 아래와 같이 응답한다. 101 Status 는 성공을 의미한다.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
핸드셰이크가 성공하면, 서버와 클라이언트의 통신 프로토콜은 Websocket으로 전환된다.
2. 전이중통신
연결이 수립되면 클라이언트와 서버 간의 데이터 통신 단계가 시작된다.
서로는 메시지를 보내며 통신하는데, 이 때 메시지는 프레임(Frame) 단위로 이루어진다.
연결 수립 이후에는 서버와 클라이언트는 언제든 상대방에게 ping 패킷을 보낼 수 있다.
ping을 수신한 측은 가능한 빨리 pong 패킷을 상대방에게 전송해야 한다.
이런 방식으로 서로의 연결이 살아있는지를 주기적으로 확인할 수 있는데, 이를 Heartbeat라고 한다.
3. 연결종료
클라이언트 혹은 서버 양측 누구나 연결을 종료할 수 있다.연결 종료를 원하는 측이 Close Frame을 상대쪽으로 전송하면 된다.
Socket.io
웹소켓은 HTML5의 기술이기 때문에 오래된 버전의 웹 브라우저는 웹소켓을 지원하지 않는다. 특히 자동 업데이트가 되지않는 익스플로러 구 버전 사용자들은 웹소켓으로 작성된 웹페이지를 볼 수 없다. 이를 해결하기 위해 나온 여러 기술 중 하나가 Socket.IO이다.
Socket.IO는 node.js 기반으로 만들어진 기술로, 거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리이다.
100% 자바스크립트로 구현되어 있으며, WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling 등 현존하는 대부분의 실시간 웹 기술들을 추상화해 놓았다.
Socket.IO는 자바스크립트를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다.
WebSocket과 Socket.io의 차이
웹 소켓은 양방향 소통을 위한 프로토콜이고, Socket.io는 WebSocket을 기반으로 확장된 기능과 호환성을 제공하는 라이브러리이다. (ex 자바스크립트와 jQuery의 관계와 비슷)
WebSocket | Socket.io |
클라이언트와 서버 간의 양방향 통신을 지원하는 프로토콜(HTTP 기반 동작) | WebSocket 외에도 다른 통신 기술을 사용할 수 있도록 추상화된 라이브러리(WebSocket 기반 동작) |
모던 웹 브라우저와 대부분의 서버 플랫폼에서 원활하게 작동하지만 구형 웹 브라우저에서는 지원이 제한적 | 다양한 환경에서 호환성 제공. 소켓 연결 실패시 fallback을 통해 다른 방식으로 알아서 해당 클라이언트와 연결을 시도 |
이벤트를 단순히 듣고, 보내는 것만 가능 데이터를 전달하는 역할에 집중하고, 추가적인 기능은 구현 |
WebSocket을 기반으로 확장된 기능을 제공 이벤트 기반의 통신을 위한 인터페이스, 실시간 방 입장/퇴장 관리, 메시지 브로드캐스팅, 네임스페이스 및 방(room) 관리 등의 기능을 내장하고 있다. |
*fallback?* : WebSocket을 지원하지 않는 환경에서 사용되는 대체 통신 방식
1. 롱 폴링(Long Polling): WebSocket을 지원하지 않는 브라우저에서 클라이언트가 서버에 지속적으로 HTTP 요청을 보내고, 서버는 새로운 데이터가 도착할 때까지 응답을 보류한다. 이를 통해 실시간성을 유지할 수 있다.
2. AJAX 폴링(AJAX Polling): 클라이언트가 일정한 간격으로 서버에 HTTP 요청을 보내고, 서버는 새로운 데이터가 있을 때만 응답을 반환합니다. 롱 폴링과 유사하지만, 응답 후에는 클라이언트가 다시 요청을 보내야 한다.
Socket.IO는 이러한 fallback 메커니즘을 내장해 WebSocket을 지원하지 않는 환경에서도 실시간 통신을 가능하게 한다. 클라이언트와 서버 간에 우선적으로 WebSocket 연결을 시도하고, 실패한 경우에는 폴백 방식을 사용하여 실시간 통신을 유지한다.
채팅서비스를 구현하며 배워보는 Websocket 원리 (feat. node.js)
What is web socket and how it is different from the HTTP?
'cs' 카테고리의 다른 글
CS 요약본 및 궁금증 요약본 (0) | 2023.06.08 |
---|---|
String의 불변성과 StringBuilder와 StringBuffer의 차이 (0) | 2023.06.08 |
[HTTP] 멱등성이 뭔가요 영어론 Idempotency (0) | 2023.05.30 |
JPA와, JPA에서 영속성에 대한 궁금증.. (0) | 2023.05.24 |
리눅스란 뭐지..? + 리눅스 주요 디렉토리 및 리눅스 명령어 (0) | 2023.05.15 |