WebSocket

먼저 Socket부터

소켓은 네트워크 상에서 동작하는 프로그램 간 통신의 엔드포인트이다.

• 소켓은 서로 떨어져 있는 두 호스트를 연결해 주는 도구이다.

소켓 통신의 흐름

• 서버

  • 먼저 클라이언트 소켓의 연결 요청을 대기한다.
  • 연결 요청이 오면 클라이언트 소켓을 생성해서 통신을 진행한다.
    1. socket() 함수로 소켓을 생성한다.
    2. bind() 함수로 IP 주소와 PORT 번호를 설정한다.
    3. listen() 함수로 클라이언트의 접근 요청에 대한 대기열을 만든다
    4. accept() 함수로 클라이언트 연결을 기다린다.

• 클라이언트

  • 실제로 데이터 송수신을 진행하는 것은 클라이언트 소켓이다.
    1. socket() 함수로 소켓을 연다.
    2. connect() 함수로 서버에 설정된 IP 주소와 PORT 번호로 통신을 시도한다.
    3. 통신을 시도한 뒤 서버가 accept() 함수로 클라이언트의 소켓 디스크립터를 반환한다.
    4. 이를 통해 클라이언트와 서버가 서로 read(), write()를 하면서 통신한다.

엔드포인트는 IP 주소, PORT 번호의 조합으로 이루어진 최종 목적지를 말한다.
소켓 디스크립터는 시스템이 특정 소켓에 할당해 준 정수 값을 말한다.

---

Polling, Long Polling, Streaming?

WebSocket 등장 이전에는 Polling, Long Polling, Streaming 방식을 많이 사용했다.

Polling

• Polling은 클라이언트가 HTTP Request를 서버에게 계속 요청하여 이벤트 내용을 전달받는 방식이다.
• 구현은 쉽지만, 클라이언트가 많아지면 지속적인 요청으로 서버의 부담이 굉장히 커진다.
• 또한 HTTP를 사용하므로 매번 연결 -> 송수신 -> 해제 과정이 반복되고, 서버 부하와 함께 지연 시간도 증가한다.

Long Polling

• Long Polling은 클라이언트가 요청을 한 번 보내고 서버의 응답을 기다리다가, 서버에서 클라이언트에 전달할 이벤트가 있다면 그때 응답을 보내주는 방식이다.
• Polling보다는 서버의 부담이 덜하지만, 클라이언트로 보내는 이벤트의 주기가 짧다면 Polling과 별반 다를 게 없다.
• 또한 Polling과 마찬가지로 클라이언트의 수가 많다면 Long Polling이더라도 서버에 부담이 된다.

Streaming

• Streaming은 Long Polling처럼 클라이언트가 요청을 보내고 서버의 응답을 기다리는 것은 동일하다.
• 하지만 서버의 응답을 받더라도 요청을 해제하지 않고 필요한 메시지만 보내는 것(Flush)을 반복한다.
• Long Polling과 비교했을 때 HTTP 연결 과정이 처음에 한 번만 있어서 상대적으로 서버의 부담이 덜하다고 한다.

---

WebSocket 등장

Polling, Long Polling, Streaming의 단점은 HTTP의 비연결성의 영향이 가장 크다.
연결 -> 송수신 -> 해제의 반복으로 데이터 전송 효율이 떨어지고, 지연 시간이 발생한다.

⭐️ WebSocket은 이러한 상황을 극복하기 위해 탄생했다. ⭐️

• WebSocket은 서버와 클라이언트 사이에 소켓 커넥션을 유지하면서 양방향 통신이 가능한 기술이다.
• 일반 Socket 통신과는 달리 HTTP PORT 80, HTTPS PORT 443을 사용해서 방화벽에 제약이 없다.
• 중요한 것은 최초 접속은 HTTP Handshake를 이용하고, 그 이후 통신은 WebSocket 프로토콜을 사용한다는 것이다.

✏️ 모든 HTTP를 사용하는 통신은 반이중 통신이다.

반이중 통신은 클라이언트가 먼저 요청을 보내고, 그 요청에 따라 웹 서버가 응답하는 형태이다.
따라서 HTTP만 사용하면 클라이언트와 서버가 동시에 데이터를 보낼 수 없다.
하지만 WebSocket은 HTTP 환경에서 전이중 통신을 지원해서 양방향 통신이 자유롭다.

WebSocket을 사용하는 이유는?

• 양방향 통신 지원

  • WebSocket은 TCP 연결을 통해 양방향 통신 채널을 제공한다.
  • 이를 위해 클라이언트는 서버에 소켓 연결을 한 상태로 유지된다.
  • HTTP는 폴링을 통해 지속적으로 데이터를 요청해야 하지만 WebSocket은 그럴 필요가 없다.

• HTTP의 한계 극복

  • HTTP 환경에서는 이러한 실시간/양방향 통신을 구현하는 것이 쉽지 않다.
  • HTTP는 한 번 통신을 주고받으면 곧바로 연결을 해제한다. -> 비연결성
  • 변경 사항 확인을 위해 주기적으로 서버를 호출하는 폴링 방식은 오버헤드가 크다.

WebSocket은 브라우저마다 지원 현황이 다르다. 자세한 내용은 이곳을 참고하자.

참고로 스프링은 SockJS를 제공한다.

---

WebSocket 통신 구조를 알아보자

An Introduction to WebSockets

• 먼저 클라이언트는 서버에 HTTP Upgrade 프로토콜로 Handshake 요청을 한다.
• 서버는 이에 대한 응답으로 101 응답 코드를 보낸다.

✏️ WebSocket을 위한 별도의 PORT를 오픈할 필요는 없다.

WebSocket은 HTTP PORT 80, HTTPS PORT 443 위에서 동작되도록 설계되었다.
HTTP Upgrade 헤더를 사용하기 때문에 Handshake 과정 중에 HTTP에서 WebSocket으로 변경된다.

✏️ ws와 wss의 차이는?

일반적으로 웹에서는 HTTP 통신이 아닌 HTTPS 통신을 해야 한다.
WebSocket 역시 ws가 아닌 wss를 사용해야 Secure 통신이 가능하다.

---

WebSocket vs. OOO

Websocket vs. TCP

• WebSocket은 연결 요청에 대해 HTTP를 통한 Switching/Handshaking이 이루어진다.
• TCP는 바이너리 데이터만 주고받을 수 있지만, WebSocket은 바이너리와 텍스트 데이터를 주고받을 수 있다.

WebSocket vs. HTTP

실시간성 측면에서 WebSocket과 HTTP의 가장 큰 차이는 수립된 connection을 활용하는 방식이다.

• WebSocket

  • 한 번 HTTP를 통해 연결하면, 그 연결을 계속 유지한다.
  • 연결이 계속 유지되므로, 요청 없이 상대의 응답을 계속 기다리면 된다.
  • 한 번 연결이 수립되면, 간단한 데이터만 오고 간다. (비용 저렴)

• HTTP

  • 클라이언트와 연결을 맺고 데이터 송수신을 완료하면 연결을 끊는다. (비연결성)
  • 이때 연결은 TCP 3-way handshake, 연결 해제는 TCP 4-way handshake를 이용한다.
  • 요청과 응답이 한 쌍을 이루며, 요청/응답 메시지에 많은 정보가 포함된다.