RestApi Vs. Web Socket
- 채팅앱을 통하여 메리와 존이 대화를 하고 있는 상황에서 존이 송신자 메리가 수신자인 상황이다.
- Server쪽 db에는 대화의 내용이 저장된다.
RestAPI
json형식
{
method : post
user_id : "john"
message_payload :{
"hey mary!"
}
}
위 content를 db에 저장했다가 메리에게 메시지를 보낼 때 되찾는다.
하지만 만약 메시지를 주고 받는 과정에서 메리는 어떻게 john이 보낸 메시지를 알아차릴 것인가?
원시적인 해결책으로는 short polling이라는 방법이 있다. short polling은 메리의 앱이나 존의 앱이 get 방식을 통해서 새로운 메시지가 있는지 짧은 시간 텀(타이머)을 가지고 확인하는 방식이다. 계속 반복하다 보면 메시지가 새로 수신되면 메이의 앱에서는 message end-point로 부터 업데이트된 셋을 db로 부터 요청하게 된다. 사람들은 편하고 이 것의 의존성 때문에 이용하게 된다.
하지만 이방식은 server나 client 측에 좋지 않은 방식이다. 왜냐하면 latency delay가 발생하기 때문이다. 만약 타이머를 5초를 두면 5초의 간격마다 메시지 딜레이가 발생하게 된다. 그리고 http로 통신하기 때문에 request가 발생할 때마다 server로 요청하게 되는데 이 때문에 서버에 부하가 발생하는 것이다.
이를 개선한 방법으로 long polling이 있다. long polling을 이용하게 되면 매 x초마다 검사하는 것이 아니고 delay를 줘서 만약 새로운 메시지가 수신될 때마다 request를 하는 방식이다. short polling에 비해서 좋은 방식이지만 적용시키기에 다소 어렵고 백엔드에 더 많은 작업이 요구된다.
정리하면, Rest Api를 이용하여 http로 존이 post를 통해서 메리에게 메시지를 보내면 http를 통하여 server로 전달되고 db에 접근하여 메리를 찾아가고 메리 입장에서는 지속적으로 GET이 동작되어 본인에게 새로 온 메시지가 있는지 확인하게 된다. 하지만 만약에 traffic이 많아지거나 서버에 지속적인 stress가 누적되게 되면 메시지가 제대로 송, 수신 장애가 발생할 수 있다. 결론적으로 restAPI를 이용하면 결국에는 server가 직접 client에게 메시지가 들어올 때 push를 해줄 수 없고 단방향으로 client의 request에 따라 동작하기 때문에 좋은 메커니즘으로 설계하는 것이 제한적이다.
이를 해결할 수 있는 통신 방식이 바로 websocket이다 socket 통신은 end-to-end 방식으로 양방향으로 통신을 할 수 있게 한다.
Websocket
websocket 통신은 초기에 연결이 성립됬다는 것을 client가 서버에게 알린다. 만약 존이 메리에게 메시지를 보내게되면 메리 측에서는 지속적으로 request를 보낼 필요가 없이 server에 메리에게 송신된 메시지가 있으면 즉시 메시지를 메리에게 전달하게 된다. 양방향 통신이 가능하게 된 것이다.
만약 websocket을 이용한다면 end to end가 연결된 통신을 하게되어 서버의 부하를 줄임과 동신에 장애가 http를 통하여 메시지 송수신을 할 때보다는 원할하게 통신할 수 있다.
