HTTP, AJAX, 폴링, 롱폴링 기법, 웹소켓

HTTP 부터 웹 소켓 까지 각각의 배경, 사용 이유, 각 기능의 장단점을 알아보았다.

 

[Http]

-> HTTP는 서버와 클라이언트가 인터넷상에서 데이터를 주고받기 위한 프로토콜
-> HTTP는 서버/클라이언트 모델
-> Client가 요청을 보내는 경우에만 Server가 응답하는 단방향 통신. Server로부터 응답을 받은 후에는 연결이 바로 종료
--> 즉각적인 갱신을 요구하는 실시간 통신에서는 불리하다. 다수의 요청을 반복해서 보내야 하기때문에 리소스 낭비가 심함.

[AJAX]

AJAX : 비동기적으로 서버와 통신을 하면서, 동적으로 페이지를 변경하게 한다.
-> http의 단점을 보완해, 웹페이지를 리로드하지 않고 데이터를 불러와 페이지를 부분적으로 변경시킬 수 있다.
-> 비동기 방식을 활용하여 필요한 부분만 불러와 사용할 수 있으므로 큰 장점

-> 단점으로, 어디까지나 일부 랜더링 문제이고, 결국 HTTP 자체를 벗어날 순 없었다.
-> 즉 양방향 통신이 불가능 하다는 점이 단점

 

[폴링]

-> 양방향 통신을 근접하게 구현하기 위한 방법들
-> 클라이언트가 서버에게 일정한 주기를 가지고 지속적으로 요청 후 응답을 받는 방식

-> 단점으로, 폴링의 주기가 짧으면 성능에 부담이 가고, 주기가 길면 실시간성능이 떨어진다.
-> 서버에서 정보가 변하지 않으면 요청 응답 과정에서 리소스를 낭비하고, 오버헤드 트래픽이 발생한다.

 

[롱폴링 기법]

-> 이러한 폴링의 문제점을 개선한 방식이다.
-> 클라이언트가 요청을 보냈을 때 그 요청에 대한 연결을 서버가 이벤트가 발생할때까지 가지고 있는 것. 
-> 즉 클라이언트에게 받은 요청을 가지고 있다가, 이벤트 발생시 응답.
-> 변경이 빈번하다면 이 역시 얻을 수 있는 이득이 크지 않다.

* 폴링 롱폴링 모두 서버측 푸시 기술을 구현하기 위한 대안이었지만 클라이언트의 요청을 통해야만 서버에게 데이터를 전송 받는다는 한계점 존재.
-> 불필요한 헤더와 높은 트래픽을 야기한다는 단점.

 

[웹소켓]

-> http의 한계를 극복하고 실시간 서비스를 개발하기 위해 탄생함
-> 사용자의 웹 브라우저에서 서버로 영구 양방향, 전이중 tcp 연결을 위한 통신 프로토콜
(양방향 통신 안에 전이중(쌍방이 동시 송신 가능), 반이중(한쪽이 송신하고 있는 동안은 수신) 이 있다.)

-> 서버와 클라이언트 사이에 웹소켓이 열리면 서버 또는 사용자 둘 중 하나가 세션을 닫을 때까지 언제든지 메시지를 보낼 수 있다.
-> http 요청과 마찬가지로 80번 포트를 통해서 웹서버를 연결한다.
-> 웹소켓은 잘 알려진 기존 포트를 사용하기 때문에 추가로 방화벽을 열지 않고도 양방향 통신을 실현할 수 있다.
-> Client만 필요한 경우에 요청을 보낼 수 있는 Http 프로그래밍과 달리 Socket 프로그래밍은 Server 역시 Client로 요청을 보낼 수 있으며, 계속 연결을 유지하는 연결 지향형 방식이기 때문에 실시간 통신이 필요한 경우에 자주 사용.

-> 단점으로 웹소켓과 http 세션이 서로 다르다는 것. 주기적으로 웹소켓 세션과 서버에 저장하는 http 세션을 동기화하는 모듈을 구현해야 한다는 것.
-> 대용량 트래픽에서는 서버가 클라이언트 수만큼의 연결을 유지해야 한다는 부담 존재.