[#04] HTTP vs WebSokets
실시간(real-time) 기능을 구현 하기 전, 어떤 것이 실시간을 가능하게 해주는지 알아보자
실시간 기능을 위해 사용할 것은 WebSoket 이라는 것인데, WebSoket 덕분에 실시간 chat, notification 같은
실시간(real-time)기능을 구현 할 수 있다.
WebSoket이 어떻게 작동하는지 알아보기 전에 HTTP가 무엇인지 살펴보자.
같은 이미지에 있는 이유는 둘 다 protocol(프로토콜)이기 때문이다.
[프로토콜: 복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약]
HTTP
HTTP란? 모든 서버들이 작동하는 방식이다. 위의 그림을 보고 설명하자면 사용자가 요청(request)을 보내면,
서버가 반응(response)한다. (인터넷 전체가 HTTP를 기반으로 만들어져있다.)
HTTP에서 기억할 중요한점은 stateless라는 것이다. 즉, back-end는 User를 기억하지 못한다.
User와 back-end 사이에 아무런 연결이 없다는 것이다. request와 response 과정 뒤에, back-end는 User를 잊어버린다.
서버는 오직 request 받을 때만 response만 해준다.
여기서 중요한 것은, 이건 실시간(real-time)으로 일어나지 않는다는 점이다.
서버는 내가 request를 보내야만 response라는 행위를 할 수 있다. 서버 혼자서는 아무것도 할 수 없다.
WebSoket
마찬가지로 Protocol이다. 예를 들어 https://www.testcoder.com으로 간다고 해보자. 이건 HTTP이다.
WebSoket을 사용해 연결하기를 원하고 서버가 지원한다면 wss(Secure Web Soket)를 하면된다.
HTTP와는 전혀 다른 Protocol이다.
위의 그림을 통해 WebSoket이 어떻게 작동하고, 실시간(real-time)을 어떻게 가능하게 해주는지 알아보자.
WebSoket 연결(connection)이 일어날 땐 마치 악수처럼 작동한다.
브라우저가 서버로 WebSoket Request를 보내면, 서버가 받거나(accept) 거절을 한다.
이런 악수 같은 절차 동의가 한번 일어나면, 연결은 성립(establish)된 것이다.
손을 잡고 있기 때문에 브라우저와 서버는 서로 소통이 가능해진다.
연결되어 있기 때문에 서버는 사용자가 누구인지 기억할 수 있다. 그리고 원한다면 서버가 유저에게 메세지를 보낼 수 있다.
서버는 request를 기다리지 않아도 된다. request, response 과정이 필요하지 않고, 그냥 발생한다.
위의 그림을 보면 WebSoket accept 후 자유롭게 메세지가 오가는 것을 확인 할 수 있다.
다시말하자면, 이 모든 것들은 connection(연결)중 일때만 발생한다.
정리
HTTP의 포인트는 stateless이다. 서버가 사용자를 기억하지 못한다는 것이다.
그리고 request가 있어야 response가 있다.
WebSoket에서는, 한번 연결이 성립되면, 양방향 연결이 생겨 메세지를 보내고 받고,
또 원하는 만큼 할 수 있으며 순서도 상관없다. request-response 같은게 필요 없다는 말이다.