• 이런 고민을 한 이유: HTTP의 한계

    • 무상태성: 클라이언트의 상태를 기억하지 않기 때문에 클라이언트에게 갱신된 정보를 알려줄 수 없다.
    • 비연결성: 1개의 리퀘스트로 부터 응답을 하면 연결이 끊어진다.

  • Polling: 주기적으로 클라이언트가 request를 보내 새로운 정보를 갱신하는 방법

    • 장점
      • 구현이 단순하다.
    • 단점
      • 주기적으로 HTTP 연결을 맺고 끊는게 상당한 클라이언트와 서버 측에서 모두 큰 부담이 된다. 이를 어느 정도 해결하기 위해 전송하는 데이터 양을 줄이기 위해 ajax를 사용한다.

  • Long Polling(HTTP/1.1): 클라이언트와 서버가 계속 연결을 맺고 끊는 것을 줄이기 위해서 만든 방법. 일단 클라이언트가 서버로 HTTP 요청을 보낸 후, 그 상태로 계속 기다린다. 서버에서 해당 클라이언트로 전달할 정보가 생기면 그 순간 응답 메시지를 전달한 후 연결이 해제된다. 된다.

    • 장점
      • Polling 방식보다 어느 정도 클라이언트와 서버의 부담이 줄었다.
    • 단점
      • 정보 갱신이 잦으면 Polling 방식과 별 차이가 없다.
      • 정보 갱신이 발생하여 클라이언트에게 알려주면 클라이언트에서 다시 request를 동시에 보내기 때문에 순간적으로 서버에 부담이 증가한다.

  • HTTP Streaming(HTTP/1.1): 클라이언트가 HTTP 요청을 서버에게 보내면 연결을 해제하지 않은 상태에서 서버는 응답을 계속 보낸다.

    • 장점
      • 연결을 맺고 끊는 것에 발생하는 부담을 해결했다.
    • 단점
      • 하나의 TCP 포트를 이용해서 동시에 읽고 쓰기를 할 수 없기 때문에, 서버에서 클라이언트로 메시지를 보낼 수 있으나 동시에 클라이언트에서 서버로 메시지를 보내는 것은 어렵다. (추가적인 학습 필요)

  • WebSocket: HTTP의 근본적인 문제(무상태성, 비연결성)를 해결하기 위해 만들어진 프로토콜. 하지만 HTTP request 메시지를 변형없이 사용할 수 있기 때문에 80번과 433번 포트에서 동작할 수 있다. 웹소켓은 연결을 맺는 과정에서 일반 TCP 소켓과 다르게 HTTP 프로토콜을 사용한다. 따라서 추가적인 방화벽 설정을 할 필요가 없다.

    • 장점
      • 클라이언트의 상태를 기억할 수 있다.
      • 연결이 유지된다.
      • 일반 HTTP 통신과정에서 발생하는 HTTP와 TCP 연결에 필요한 비용을 줄일 수 있다.
      • 불필요한 헤더가 사라지기 때문에 통신량을 줄일 수 있다.
      • 웹 표준이다.
    • 단점
      • 오래된 브라우저에서 지원하지 않는다.
      • 서버와 클라이언트 간의 소켓 연결 자체가 자원을 소비하기 때문에 트래픽이 많은 서버 같은 경우 CPU에 부담이 될 수 있다.
      • 클라이언트의 상태를 기억하는 추가적인 구현이 필요하다. (자동 재연결, 연결 종료)

  • SSE(Server-Sent Events): HTTP Steaming 중 하나. HTTP를 통해 초기 연결이 되면 서버가 클라이언트로 전송을 할 수 있는 기술. W3C에 의해 HTML5 일부로 표준화 되었다. 하지만 SSE는 서버에서 클라이언트로 밖에 전송하지 못한다. 단방향 채널이다.

    • 장점
      • 전통적인 HTTP를 통해 전송하기 때문에 특별한 프로토콜이나 서버 구현이 필요하지 않다.
      • 웹 소켓에비해 해야될 선행작업이 적다. (재연결 내장 지원)
    • 단점
      • 양방향 연결이 아니다. 즉, 클라이언트에서 서버로 보내는 방법은 제공하지 않는다.
      • 최대로 열릴 수 있는 연결 수가 브라우저 당 6개로 제한되어있다.
      • HTTP2.0과 함께 쓰면 웹소켓과 비슷한 성능을 보이는데, HTTP2.0은 상대적으로 지원하는 브라우저가 적다.

  • WebTransport: HTTP/3 기반에서 동작하는 웹소켓 프로토콜. 아직 HTTP/3는 draft 단계이므로 생략한다.

참고 자료