웹소켓 프로토콜은 클라이언트와 서버가 오랫동안 지속되는 연결을 통해서 동시에 데이터를 주고받을 수 있다. HTTP 폴링보다 오버헤드가 적기 때문에, 애플리케이션 실시간 기능에 활용할 수 있다.
1) 양방향 통신으로, 양쪽에서 언제든지 메세지를 보낼 수 있다. 데이터를 빠르게 주고 받아야할 때 좋다.
2) 짧은 대기 시간 -> 웹소켓을 쓰면 데이터가 즉시 전송된다. 클라이언트는 계속 메시지 조회를 할 필요가 없다.
3) 지속적인 연결 -> 전통적인 HTTP 연결에서는 클라이언트가 요청을 하고, 응답을 보낸 후 연결이 닫힌다. HTTP/1.1에서 TCP 연결을 재사용하는 지속적 연결을 도입했음에도 이러한 한계는 여전히 존재한다.
웹소켓 연결을 사용하면, 클라이언트는 서버와의 모든 웹소켓 통신에 대해서 하나의 연결로 계속 통신이 가능하다.
HTTP/1.1에서는 TCP/IP 연결 재사용으로 일부 성능이 향상되었지만, KEEP-ALIVE의 세부사항은 서버마다 다르고 대부분 비활성화 된 시간이 임계점에 다다르면 닫힌다.
HTTP로 실시간에 가까울 정도로 서비스를 구현하려면, 클라이언트가 서버에 새로운 message가 있냐고 물어보는 주기를 짧게 하는 방법이 있다. 주기가 짧아질수록 부하가 커진다.
HTTP Streaming이라고 해서, 연결을 유지하면서 서버가 데이터가 생길 때마다 클라이언트에게 보내는 방법도 있다고 한다. 다만, 이 방법은 일방향방식이라서, 양쪽에서 데이터를 주고 받아야 하는 채팅이나 멀티플레이게임/피그마같은 collaborative 앱에서는 부적절하다고 한다.
1) 단순성과 편재성 -> 단순하고, 어디서든 사용한다.
2) 상태 비저장 특성 및 캐싱 지원
3) 강력한 보안 매커니즘 -> HTTPS를 사용할 수 있다.
10KB의 메시지를 보낸다고 해보자. HTTP는 여기에 더해 쿠키를 포함해서 2800KB, 쿠키 없이 490바이트를 보내게 된다. 10KB+수KB가능.
반면 웹소켓은 처음에 커넥션을 맺은 이후로, 6바이트의 오버헤드만 추가된다(헤더 2바이트, 마스크값 4바이트). 처음에 커넥션을 맺을 때는 HTTP와 웹소켓 모두 지연이 발생할 수 있지만, 이후로는 큰 차이가 발생하는 것이다.
In addition, the TCP connection setup latency is probably a bigger factor than the size or processing time for each request.
주로 이러한 TCP연결이 주된 지연 시간의 원인인데, HTTP는 TCP연결을 맺고 끊는 게 웹소켓보다 많을수밖에 없다.
그렇지 않다. 웹소켓은 HTTP의 extension(확장)으로 볼 수 있다.
웹소켓 등장 전에는 웹브라우저와 서버가 실시간으로 통신하는 방법은 XmlHttpRequest였다고 한다.
하지만, 이 방법은 서버가 클라이언트에게 자발적으로 데이터를 보낼 수 없고, 클라이언트의 요청이 필요했다. 웹소켓은 서버가 원할 때 데이터를 보낼 수 있어, 낮은 지연시간으로 게임 구현에도 활용할 수 있다.
They are solving two different problems. Their requirements are different. It will be like comparing apples to oranges. They are different.
이 두가지는 해결하려는 문제가 다를 뿐, 무엇이 더 좋고 나쁘고를 가리기 어렵다. HTTP는 클라이언트가 무언가를 원하면, 서버가 응답하는 구조다. 해결하려는 주요 문제는, 클라이언트로부터 요청이 왔고 이에 대한 응답을 보내는 것이다.
웹소켓은 요청-응답 방식의 프로토콜이 아니다. TCP 소켓과 매우 유사한 소켓이다. TCP 소켓과의 차이는 브라우저에서 쓸 수 있다는 것이다. 다만, 브라우저는 대체적으로 80과 443 포트를 제외하곤 대부분 제한을 하기 때문에, 기존 HTTP 인프라에서 핸드세이킹을 활용해 HTTP에서 웹소켓으로 업그레이드를 한다.
(웹소켓은 처음에는 HTTP요청처럼 보이지만, 헤더의 특별한 지시어(Upgrade: websocket)가 서버에게 비동기 모드로 통신을 시작하라고 알린다.)