[네트워크] 웹소켓

웹소켓?

HTTP 환경에서 클라이언트와 서버 사이에 하나의 TCP연결을 통해 실시간으로 전이중 통신을 가능하게 하는 프로토콜

 

>> 연속적인 데이터 전송의 신뢰성을 보장하기 위해 Handshake 과정을 진행한다.

 

기존의 다른 TCP 기반의 프로토콜은 TCP Layer에서의 Handshake를 통해 연결을 수립하는 반면, 

웹 소켓은 HTTP 요청 기반으로 Handshake 과정을 거쳐 연결을 수립한다 (80,443 포트로 접속)

Handshake가 끝나면, HTTP 프로토콜을 websocket 프로토콜로 변환하여 통신한다

 

- 연결 과정

1. Client -> Server HTTP로 WebSocket 연결 요청

2. Server -> Client HTTP로 WebSocket 연결 승인

3. 양방향 연결로 Server와 Client가 통신

4. Client와 Server 중 하나에 의해 양방향 연결 종료

웹 소켓 vs HTTP

웹 소켓 : 클라이언트 - 서버 간 접속을 유지하며, 양방향 통신이다

HTTP : 클라이언트 - 서버 간 접속을 유지하지 않으며, 단방향 통신만 가능하다

 

웹 소켓은 초기 연결 수립을 위한 오직 하나의 URL만 존재하며, 모든 메시지는 초기에 연결된 TCP 연결로만 통신한다.

 

---

 

Polling : 클라이언트가 http request를 서버로 계속 날려서 이벤트 내용을 전달 받는 방식

- 장점 

일정하게 갱신되는 서버 데이터의 경우 유용하게 사용될 수 있음

- 단점

클라이언트가 많아지면, 서버의 부담이 급증한다

폴링의 주기가 짧으면 서버의 성능에 부담이 간다

주기가 길면 실시간성이 떨어진다

HTTP Request Connection 오버헤드 (전송하는 데이터 양에 비해 header의 양이 큰 문제) 발생

---

Long polling : 서버 측에서 접속을 열어두는 시간을 길게 하는 방식 

클라이언트에서 서버로 http request를  보내면,

(1) 서버에 응답에 대한 사용 가능한 데이터가 없으면 계속 기다리다가

(2) 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 response 메시지를 전달하면서 연결이 종료된다

클라이언트에서는 곧바로 다시 HTTP Request를 날려서 서버의 다음 이벤트를 기다리게 되는 방식이다

- 장점

일반 Polling보다 서버의 부담이 감소한다

- 단점

클라이언트로 보내는 이벤트들의 주기가 짧으면 polling과 별 차이가 없다

다수의 클라이언트에게 동시에 이벤트가 발생될 경우

곧바로 다수의 클라이언트가 서버로 접속을 시도하면서 서버의 부담이 급증하게 된다

---

Streaming : 서버 측에서 클라이언트로 이벤트를 계속 보낸다, 요청을 끊지않고 필요한 메시지만 보내기를 반복