[Web 일반] 실시간 통신 (Pooling, Long Pooling, Streaming, WebSocket) 비교

HTTP Pooling

Client가 Server로 주기적으로 요청을 날려 이벤트 확인하는 방식 (ex. 10초마다 서버로 Request 확인)

 

🎈 단점

• 일정 주기에 기반한 것이라 완벽한 실시간성이 보장되지 않음 (ex. 10초마다 , 서버는 근데 1초에 바뀌는 경우 9초 후에 전송되는 것)
• 요청 후 응답이 오래걸리더라도, Server로 계속 추가적인 Request를 보내기 때문에 Server의 부담이 큼

 

 

HTTP Long Pooling

Client가 Server로 요청을 날려 이벤트가 생길 때 까지 기다리는 방식 (ex. Request 10초 후 이벤트 발생하여 Response를 보내고, 응답 하는 즉시 Request를 보내 연결)

 

🎈 단점

• 요청이 많아지면 (동시에 이벤트가 발생하면) Server로의 Client의 연결이 많아지기 때문에, Server의 부담이 큼

 

HTTP Streaming

지속적인 업데이트를 위해 Client의 요청을 무한정 Server에 대기시키며, Connection을 유지시키는 것

 

🎈 단점

• Server는 연결되어 있는 Client에게 지속적으로 메시지를 보낼 수 있지만, Client는 Streaming을 수신하는 TCP Port로 수신과 전송을 동시에 할 수 없기 때문에 다른 요청을 할 수 없게 된다.
• Streaming 중 요청을 보내고 싶다면, TCP 이외의 다른 Port 사용 해야 함

 

HTML5 WebSocket

이전 http 통신과 달리 Web을 위한 Client와 Server간 양방향 통신 방식

 

🎈 특징

• HTTP Pooling, HTTP Long Pooling, Streaming등의 방법은 불필요한 요청/응답 Header 발생
• HTTP Header를 통해 Handsahking을 진행하고, 통과 후 WebSocket Protocol로 방식으로 통신
• Pooling 방식 보다 주고 받는 데이터 양이 작아(Handshaking 후에 순수 메시지 크기만 부담하므로) 네트워크 오버헤드가 적음

 

실시간 통신 비교 이미지

🎈 Pooling vs Long Pooling vs Streaming

 

pooling vs long pooling vs streaming 차이

 

🎈 Pooling vs WebSocket

 

pooling vs websocket

참고 문헌

https://mingule.tistory.com/60