1. 웹소켓이란?
위키백과에서는 웹소켓을 다음과 같이 정의합니다.
- 웹소켓(Websocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜입니다.
TCP 접속 ? 전이중 통신 ? 무슨 말인지 알기 어렵군요. 다시 정의해볼까요?
- 웹소켓은 서버와 클라이언트 간 연결을 유지해서 언제든 양방향 통신이 가능하도록 하는 기술입니다.
음~ 이제 무슨 말인지 알 것 같습니다. 그런데 언제든 양방향 통신이 가능하도록 하는 기술이라니, 이전에는 양방향 통신이 불가했었나요? 기억을 더듬어봅시다. 그런 것 같기도 하고... 아닌 것 같기도 하고... 웹소켓은 대체 왜 나오게 된 기술일까요?
2. HTTP의 문제
먼저 HTTP의 문제부터 생각해봅시다. 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어지니까요. HTTP란 웹 상에서 서버와 클라이언트 간 통신을 위한 프로토콜로, Stateless와 Connectionless 라는 특징을 가집니다.
- 서버는 클라이언트의 상태를 보존하지 않는다 (Stateless)
- 요청과 응답이 끝나면 연결 상태를 유지하지 않는다 (Connectionless)
a. 새로고침
HTTP에서 클라이언트가 요청을 하면 서버는 응답으로 HTML을 제공했습니다. 그런데 이렇게 HTML을 새로 받는다는 것은 새로운 페이지로 이동한다는 것, 즉 새로고침을 의미했습니다.
회원가입을 한다고 생각해봅시다. 아이디 중복 체크를 하기 위해 중복 체크 버튼을 눌렀더니(요청) 결과를 받는답시고 새로고침(응답)을 해버렸습니다. 그럼 이전에 작성한 값들이 모두 사라지게 되는거죠! 생각해보면, 이러한 문제를 해결하기 위해 예전에는 중복 체크 버튼을 누르면 작은 창이 뜨며 확인이 됐었던 것 같습니다.
이 이외에도 새로고침이라는 문제를 해결하기 위해 임시방편으로 사용하던 것이 iframe, 플래시, ActiveX 였습니다. 그리고 훗날, 구글이 Ajax을 통해 동일한 웹페이지 내에서 DOM을 변경하면서 위 문제를 해결할 수 있게 됩니다.
b. 요청과 응답
HTTP가 이제 괜찮아질 것 같지만, 위 문제 말고도 또 문제가 있었습니다. 좀 더 웹소켓과 밀접한 문제죠. HTTP는 단방향 통신이기 때문에 요청이 있어야만 응답도 있다는 것 입니다. 그래서 서버쪽에서 데이터가 업데이트 되더라도 클라이언트의 화면은 재요청을 하지 않는 한 업데이트가 되지 않습니다.
친구와 채팅을 한다고 생각해봅시다. 당신이 친구에게 메시지를 보내 서버에 데이터가 갱신됐습니다. 이 때, 친구에게 문제가 발생합니다. HTTP 통신에서는 요청이 있어야만 응답이 있기 때문에, 당신이 보낸 메시지를 받기 위해서는 친구가 서버에 요청을 보내야만 합니다. 즉, 상대 클라이언트의 데이터는 서버에 재요청을 하지 않는 한 업데이트 되지 않습니다. 하지만 언제 데이터가 올 줄 알고 재요청을 한답니까?
이 문제를 해결하기 위해 웹소켓 이전에는 polling, long polling, streaming 을 사용했습니다.
3. 웹소켓 이전의 방식
a. Polling
Polling은 특정 주기를 기준으로 요청과 응답을 반복하는 것 입니다. 당신이 채팅 메시지를 언제 보낼 지 모르니까, 친구가 특정 주기로 요청을 보내 확인하는 것이죠.
하지만 주기가 짧으면 서버에 무리가 가고, 주기가 길면 실시간성이 떨어집니다. 또, 자주 변경되지 않는 데이터라면 불필요한 요청, 응답 트래픽이 발생한다는 문제점이 있습니다.
b. Long Polling
Long Polling은 요청을 받고 서버에서 연결을 끊지 않고 기다리다가 time out되거나 이벤트의 업데이트가 있을 경우에 응답을 해주는 것입니다. 자주 변경되지 않는 데이터의 불필요한 요청, 응답 트래픽을 줄일 수 있으니 Polling의 문제점을 개선할 수 있고, 이벤트의 업데이트가 있을 경우에 응답을 해주기 때문에 실시간성도 높습니다.
하지만 데이터가 자주 바뀌는 경우에는 적절하지 못 합니다. 기본적으론 Polling과 동일하게 요청, 응답 트래픽이 많습니다. 더불어 100명의 채팅 이용자가 있다고 할 때, 한 사람이 채팅을 보내면 나머지 사람들은 응답을 받고 다시 요청을 보내게 됩니다. 그 탓에 짧은 시간 내에 REquest Queue가 쌓이게 되고 서버가 버벅이거나 뻗을 수 있습니다.
c. Streaming
Streaming은 클라이언트와 서버가 계속 접속을 유지한 상태에서 이벤트가 발생할 때마다 클라이언트에게 데이터를 보내줍니다. Long Polling과 달리 응답을 받고 다시 요청을 보낼 필요가 없어 더 효율적이고, 데이터가 자주 변경되는 경우 유리합니다.
하지만 연결을 길게 유지하고 있어야 하므로 유효성 관리 측면에서 부담이 생길 수 있습니다.
4. 웹소켓의 문제점
a. 지원하지 않는 브라우저
하지만 웹소켓에도 문제는 있었습니다. 가장 큰 문제는 웹소켓이 HTML5때 등장했기 때문에 오래된 버전의 웹 브라우저에서는 지원하지 않는다는 것입니다. 때문에, 이를 해결하기 위한 것이 Socket.io와 SockJS 입니다.
그 중 Socket.io는 node.js 기반으로 만들어진 기술로, 거의 모든 웹 브라우저와 모바일 장치를 지원하는 실시간 웹 애플리케이션 지원 라이브러리 입니다. 웹 브라우저와 웹 서버의 종류, 버전을 파악하여 가장 적합한 기술을 선택하여 실시간 웹을 사용할 수 있도록 해줍니다.
b. 문자열 해석이 어렵다
또, 웹소켓은 문자열을 주고 받을 수 있게 해줄 뿐 그 이상의 일은 하지 않습니다. 따라서 주고 받은 문자열의 해석은 애플리케이션이 해야합니다. 그런데 HTTP의 경우 형식이 있어 해석이 쉬웠지만, ws는 형식이 없기에 해석이 어려웠습니다. 이를 위해 Sub Protocol을 사용해서 주고 받는 메시지의 형태를 약속하도록 했고, 그 Sub Protocol 중 하나가 STOMP 입니다.
STOMP (Simple/Streaming Text Oriented Messaging Protocol) 는 websocket 위에서 동작하는 문자 기반 메세징 프로토콜입니다. TCP와 웹소켓과 같이 신뢰할 수 있는 양방향 스트리밍 네트워크 프로토콜에서 사용할 수 있으며, AMQP 나 MQTT 와 같은 메세지 전송을 위한 다른 프로토콜들과 다르게 binary 기반이 아닌 텍스트 기반입니다.
5. 웹소켓의 통신 방식
웹소켓은 HTTP로 handshake를 한 후, ws로 프로토콜을 변환하여 웹소켓 프레임을 통해 데이터를 전송합니다. 추가하고 싶지만 힘들어서 (...) 아래 두 링크를 참고하면 좋을 것 같습니다.
6. 참고자료
'CS > 네트워크' 카테고리의 다른 글
| TLS 핸드셰이크 (0) | 2022.07.20 |
|---|---|
| OSI 7계층이란? (0) | 2022.06.11 |
| 동기/비동기와 블로킹/논블로킹 (0) | 2022.05.22 |