웹소켓 (WebSocket)

 

 

 

---

 

웹소켓은 무엇인가?

 

 

---

 

 

 

 

HTTP 통신

 

--

기본적으로 HTTP 통신은

클라이언트가 서버에게 요청을 보내고,

서버는 해당 요청에 대한 응답을 다시 보내는 "단방향 통신"으로 소통한다.

 

 

일반적인 기능들은 위와 같은 "단방향" 통신으로 구현이 가능하지만

만약 실시간 채팅, 멀티 게임 등 실시간으로 통신을 해야 하는 경우에 한계가 존재한다.

 

A와 B가 서로 채팅을 하고 있다고 가정하자.

1. A가 메시지를 작성하여 전송하기 요청
2. 서버는 해당 요청에 대한 응답을 전달 (전송한 메시지 내용이 화면에 보이게)
3. B는 서버로부터 최신값을 받지 못해서 A가 메시지를 전송했는지 확인 불가

위 상황처럼

A는 요청과 함께 서버로부터 최신 정보들을 받아와 화면이 변화한 것을 볼 수 있지만

B는 서버에 요청을 하지 않아 서버로부터 최신 정보를 받지 못해 A가 메시지를 보냈는지 알 수 없다.

즉, B는 "새로고침"을 통해 서버로부터 최신화된 정보를 받아와야 확인할 수 있게 된다.

 

이를 해결하기 위해서는

꼭 사용자가 요청을 보내지 않고

클라이언트가 주기적으로 자동 요청을 보내 서버로부터 최신화 정보를 받아오는 방법이 있다.

 

다만 이러한 방법을 사용하면 크게 2가지 문제점이 존재한다.

• 요청을 보내는 "주기"만큼의 최신 정보을 적용하는 지연이 발생할 수 있다.
  (10s 간격으로 요청을 보내는 상황에서 만약 2s 지나고 최신 정보로 업데이트된다면 8s동안 최신 정보를 알 수 없음)
• 불필요한 요청들로 인해 트래픽 낭비가 심해진다.

정보 최신화를 지연하는 것을 방지하기 위해 요청 주기를 짧게 하면

그많큼 불필요한 요청들이 많아지니 트래픽 낭비가 더욱 심해지고,

트래픽 낭비를 줄이기 위해 요청 주기를 줄이면

정보 최신화가 더욱 지연될 수 있다.

 

위와 같은 상황을 개선하기 위해 "Long Polling"이라는 통신 방식이 생겼다.

 

 

 

Long Polling

클라이언트와 서버 간에 "비동기 통신 방식" 중 하나로,

클라이언트가 서버로 요청을 보내면, 서버가 즉시 응답하지 않고 새로운 데이터가 생길 때까지 응답을 대기하여 지연시키는 방식으로 새로운 데이터가 생기면 응답을 보내는 방식이다.

즉, 실시간 통신과 유사한 효과를 제공할 수 있다.

 

 

서버는 클라이언트로부터 요청을 받을 때

해당 요청을 응답할 때까지 해당 클라이언트와 연결을 지속해야 한다.

 

만약 수많은 클라이언트가 요청을 보내 모두 응답을 지연하여 대기하게 되면

해당 클라이언트의 수만큼 서버는 연결을 유지해야 하므로

부하가 발생하여 서버에 큰 부담이 된다.

이로 인해 업데이트에 대한 반응이 느려지게 된다.

--

 

 

 

 

웹소켓 (WebSocket)

 

--

웹소켓은

HTTP 기반에서 동작하는 응용 계층 프로토콜로,

웹 환경에서 실시간 양방향 통신을 제공하기 위해 설계된 기술이다.

 

위와 같이 기존의 HTTP의 한계를 보완하며,

실시간 데이터를 효율적으로 주고받기 위해 설계되었고,

HTTP "핸드셰이크"를 통해 양방향 연결을 시작한 후, 지속적인 양방향 통신을 제공한다.

연결이 이루어지면
그때부터 클라이언트와 서버는 "HTTP"가 아닌 "WebSocket 프로토콜"을 사용하여 소통한다.
그래서 꼭 클라이언트는 요청을 보내고 서버는 요청에 대한 응답을 보내는 것이 아닌
서로 자유롭게 메시지를 보낼 수 있게 된다.

 

 

 

핸드셰이크 (Handshake)
두 시스템 간의 통신을 시작하기 전에 연결을 설정하고 규칙을 협상하는 과정을 의미하며,
네트워크 통신에서 클라이언트와 서버가 서로 신뢰하고 데이터를 교환할 준비가 되었는지 확인하는 단계다.

과정
1. 클라이언트 -> 서버 요청 : 요청 메시지에는 통신에 필요한 초기 정보(프로토콜 정보, 옵션 등)를 포함
2. 서버 -> 클라이언트 응답 : 응답 메시지에는 협상된 통신 규칙이나 인증 정보를 포함
3. 양방향 연결 확립 : 클라이언트와 서버가 협상된 규칙에 동의하면 연결이 된다.
연결이 되었다면 이후 데이터 전송을 자유롭게 시작된다.

해당 연결은 둘 중 한쪽이 연결을 종료하자는 (close 프레임)신호를 보낼 때까지 연결이 지속된다.

 

 

웹소켓의 장단점

• 서버와 클라이언트 간 실시간 데이터 전송에 적합
• HTTP Polling 또는 Long Polling 보다 훨씬 빠르고 효율적
• 지속적인 연결로 헤더 오버헤드를 줄여 네트워크 리소스 절약
• 요청/응답 반복이 필요 없어지므로 레이터시 감소
• 이벤트 기반으로 서로 데이터 전송 가능
• API로 간단하게 구현 가능

• HTTP 기반 애플리케이션보다 구현이 다소 복잡할 수 있음
• 서버 측에서 지속적인 연결 관리를 위해 추가적인 자원이 필요
• 일부 구형 브라우저 or 네트워크 환경에서는 지원 불가
• HTTPS 기반이 아닌 경우, 데이터가 암호화되지 않아 도청 가능성 있음

HTTP 통신이 아닌 Websocket 통신으로 이루어져
http:// 가 아닌 ws://로 URL 형식이 바뀌게 된다.
ws는 http처럼 데이터가 암호화되지 않고 전송하기 때문에 보안적으로 위험이 있다.
그래서 https로 적용하는 것처럼 동일하게 SSL/TLS 인증서를 발급받은 뒤에 wss로 설정해야 한다.

--