정의
- 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜
목적
- 기존 방식의 단점 개선.
기존의 양방향 통신 (왜 써야할까?)
- HTTP 프로토콜
- HTTP는 클라이언트의 요청이 있어야만 서버가 응답할 수 있다. 반대로 서버가 먼저 보내는 요청은 클라이언트가 받을 수 없다. 이 단점을 개선하기 위해 나온 기술이 Polling이다.
- Polling은 주기적으로 서버에 요청을 보내서 받을게 있는지 확인하는 방법이다. 단점은 서버측에서 보낼 내용이 없어도 클라이언트는 알 수 없기 때문에 계속해서 request를 보내 확인을 해야하고, 지속적인 연결과 해제는 handshake가 필요하기 때문에 서버에 부담을 준다. 클라이언트가 많아질수록 더욱 커지게 된다. 이 polling의 단점을 조금 개선한 것이 long polling이다.
- Long Polling은 클라이언트의 요청에 대해 응답을 보내지 않고 있다가 이벤트가 발생했을때 리턴하는 방법이다. 클라이언트는 pending 상태로 대기하고 있다가 응답이 오면(연결이 끊어지면) 다시 연결하는 것을 반복한다. 폴링 방식보다 부담이 조금 줄어들 수 있으나, 이벤트의 텀이 짧으면 폴링과 차이가 나지 않게 된다.
- polling의 단점을 개선한 다른 방법으로는 Streaming 이 있다. 클라이언트가 request를 보내면 커넥션을 맺고, 이 커넥션을 유지하면서 서버가 계속 데이터를 보내는 방식이다. 클라이언트가 서버에 메시지를 보내고싶다면 새로운 커넥션을 맺어야 한다.
WebSocket
- 정의에서 알 수 있듯, WebSocket은 양방향 통신 프로토콜이다.
- WebSocket 프로토콜로 연결하기 위해서는 websocket handshake가 필요하다. URI 스키마는 ws://를 사용하며 암호화 소켓은 wss://를 사용한다.
- 웹소켓 사용을 위해서는 HTTP 통신을 통해 Upgrade Request를 보내야 한다.
-
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>
-
- 서버는 Status Code 101 Switching Protocols을 Response에 담아 보낸다.
-
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat
-
언제 써야할까?
- 아래 참고 항목에도 포함된 windows 개발자 블로그 글에 굉장히 잘 나와있다.
- 변경 사항에 빠르게 반응해야 하는경우. 예) 실시간 채팅
- 리소스 상태에 대한 지속적 업데이트가 필요할 때. 예) 문서 동시 편집
Socket.io ?
- 웹소켓에 대해 검색하면 Socket.io 관련내용과 비교가 많이 등장한다. Socket.io는 프로토콜의 이름이 아니고 양방향 통신 JS 라이브러리이다. 아마 가장 유명한 라이브러리인듯 하다.
- 내부적으로 웹소켓을 사용하여 양방향 통신하며, 웹소켓을 지원하지 않는 환경에서는 롱폴링을 사용하여 양방향 통신을 지원한다.
기타
- 웹소켓에 대해 깊이있게 작성된 글이 있어 추가한다. 영어로 작성된 글을 번역한 글이다.
- 연관 검색어로 STOMP가 등장한다. 이에 대해서는 추후 정리한다.