Socket 통신 vs http 통신 ( feat. polling, long polling, web socket )

Client - Server 통신

일반적으로 소프트웨어에서 사용하는 데이터들은 보통 서버에서 관리된다.

그럼 클라이언트에서 이 서버에 접속하여 데이터를 주고받게 되는데, 여기서 통신방식이 크게 Http 통신과 Socket 통신 2가지 방식이 있다.

 

 

• 일반적인 네트워크 애플리케이션은 2개의 서로 다른 종단시스템에 존재하는 서버 프로그램과 클라이언트 프로그램으로 구성된다.
• 얘네 둘을 실행시키면 각각의 프로세스가 생성되고
• 이 프로세스는 Socket 이라는 통로를 통해 읽기(read), 쓰기(write) 연산을 수행하면서 
• 서버와 클라이언트가 데이터를 주고 받는 것이다. 여기에서 통로 역할을 하는게 Socket

 

 

---

 

HTTP 통신

Client의 요청(Request)이 있을 때만 서버가 응답(Response)하여 해당 정보를 전송하고 곧바로 연결을 종료하는 방식

 

즉, http 통신은 Client가 요청을 보내는 경우에만 Server가 응답하는 단방향적 통신으로, Server가 Client에 요청을 보낼 수는 없다.

 

그렇기 때문에 요청을 보낼때, 내용을 기다리는 시간과 함께 연결하는 시간이 들어가게 된다. ( 연결을 하고 끊으니 다음번 요청에서는 다시 연결을 해야된다.)

 

그래서 Http 통신은 실시간 연결이 아닌, 필요한 경우에만 Server로 접근하는 콘텐츠 위주의 데이터를 사용할 때 용이하다.

 

만약 게시물에 대한 내용을 요청하기 위해 실시간 연결을 유지하는 Socek 통신을 사용하게 될 경우, 게시물을 받은 후에도 계속 통신을 위한 연결이 유지되어야 하기때문에 부하가 걸리게 된다.

 

일반적으로는 필요한 경우에만 Server로 정보를 요청하는 경우가 많은데, 이러한 Web Server로 Http 통신을 주로 사용하며 비용, 유지보수 등 다방면에서 이점이 있다.

 

---

 

Socket 통신

Server와 Client가 특정 Port를 통해 실시간으로 양방향 통신을 하는 방식.

 

Socket 통신은 Http 통신과 달리 Port를 통해 연결을 유지하고 있어 실시간으로 양방향 통신을 하는 방식이다.

 

그래서 연결지향형 통신이라고도한다. 

 

실시간 통신이 필요한 Streaming 중계나 실식나 채팅과 같이 즉각적으로 정보를 주고 받는 경우에 사용한다.

 

만약 실시간 영상 Streaming 서비스를 Http로 구현했다고 가정한다면, 사용자가 서버로 동영상을 요청하기 위해서는 동영상이 종료되는 순간 까지 계속해서 Http 통신을 보내야한다. 이런 계속적인 연결요청은 부하가 걸리기 쉽다.

 

---

 

Http 통신의 문제점을 해결하기 위한 해결책 :

 

Polling ?? ▼ 

우선 Polling 은 http의 단점을 보완하기 위해 고안된 기법이다.

 

http 통신의 문제는 서버에서 클라이언트로 역으로 요청하는건 불가능 하다는 것이다.

애당초 Client만이 Server로 연락할 수 있고 Server는 Client의 요청을 응답하는것만 가능하다는 것이다.

 

요즘에는 둘의 통신이 매우 중요한 시기가 되었기 때문에 Server에서 반대로 Client 에 요청을 하고싶다는 생각을 하게 되었다.

 

하지만 http프로토콜은 원래부터 단방향으로 만들어졌기 때문에,

http프로토콜을 뜯어 고치지 않는한 불가능했다.

 

그러나 http프로토콜은 웹에서 사용되는 표준 프로토콜이고 이를 이용해서 양방향을 사용해야하는 상황에 봉착하게됬다.

막말로 웹에서는 http말고는 방법이 없었다. 지금이야 웹소켓이 있었지만 과거 웹은 오직 http만 가능했다.

 

그래서 마치 통신하는 것처럼 느끼게 만드는 방법을 고안해냈다.

가장 초기모델이 바로 polling이라는 기법이다.

 

 

폴링(polling)이란 하나의 장치(또는 프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식을 말한다

 

가장 무식한 방법이다.

스토킹 마냥 계속해서 일정 시간 간격으로 물어보는 방법이다.

무식하고 별로라고 생각할 수 있겠지만 여러가지 장점이 있는 방식이다.

 

---

 

[ polling 의 특징 ] : 

 

1. 주기적으로 물어보므로 응답 간격을 일정하게 할 수 있다.
2. 주기적으로 몰아서 물어보는게 가능하므로 자동으로 배치프로세싱(일괄처리)되어서 db튜닝을 하는 효과가 나온다.
3. 실시간으로 주는건 불가능하다. 실시간 효과를 내려면 간격을 줄여야 하지만 서버와 클라이언트 모두에게 부담이다.
4. 보낼데이터가 없어도 계속해서 데이터를 줘야하므로 서버의 리소스를 낭비하게된다.

 

일단 계속해서 일괄적으로 물어보는점은 장점이다.

그래서 그래프를 그리거나 대용량의 데이터를 처리해야한다면 http polling은 아직도 유효하며 오히려 매우 간단하고 최적화된 방식이다.

 

문제는 실시간성이다. 이 방식은 어떻게 봐도 실시간성으로 좋지는 않은 방법이다.

위에도 설명을 했지만 http polling은 딜레마에 빠지게되는데 시간간격을 늘리면 실시간성이 떨어진다.

그래서 실시간 느낌을 주기위해서 시간간격을 줄이면 어떻게 될까?

http통신이 매우많이 마구마구보내지게 될 것이다.

http는 단발성 통신이기에 header가 매우 무거운 프로토콜중 하나이다.

이 프로토콜이 마구마구 보내진다면 서버에 매우 무거운 부하를 주게된다.

그렇다고 다시 시간을 늘리자니.... 이하 문제가 무한반복하게 된다.

그래서 새로운 기법을 고안하게 되었다.

 

---

 

바로 http long polling기법이다.

 

기본방식은 polling처럼 무한히 물어보는 것이다.

하지만 차이점이 있다면 일반 polling은 주기적으로 물어본다면,

long polling은 일단 보내고 time out될 때까지 무한정 기다린다는 것이다.

서버가 만약 "너 너무 나랑 오래 연결 되있어, 그럼 이만 끊을께" 하고 답을 보내면

바로 client는 집착녀,집착남 마냥 "헐.. 다시 연결할께"가 되는 것이다.

반대로 답을 주게 된다면 바로 이를 client에게 전달한다.

그리고 client는 정보를 받자말자 바로 다시 서버에 요청을 보낸다.

이 결과 연결은 무한히 지속되게 된다.

그리고 client는 마치 실시간으로 데이터를 받는 느낌을 받게 된다.

 

 

[ long polling 의 특징 ] : 

 

1. 항상 연결이 유지 되어 있다.
2. 변경에 매우 민감하게 반응한다. 사실상 실시간으로 통신이 가능하다.
3. 데이터가 주어지는 즉시 바로바로 반응하고 보내므로 요청간격이 줄어든다면 polling보다 훨씬 데이터를 많이 보내게된다.

 

long polling은 실시간으로 데이터를 핸들링 할수 있다는 polling에 없는 장점을 얻게 된다.

그래서  채팅을 구현할 때 많이 사용하는 기술중 하나이다.

다만 polling보다 좋은점만 있는것은 아니다.

일단 일반적으로 생각하기에는 polling보다 데이터를 적게 보낼꺼 같지만 만약 데이터 이동이 활발하다면??

그러면 오히려 주기적으로 한번에 보내는 polling보다 훨씬 더 많은 데이터를 보내게 된다.

위에서도 언급했지만 http는 헤더의 크기가 큰편에 속한다.

그래서 많은 데이터를 보낸다는것은 엄청난 비용이된다.

 

 

 

WebSocket ?? ▼

상호작용하는 웹 서비스를 위해 숨겨진 프레임(Hidden Frame)을 이용한 방법이나 Long Polling, Stream 등 다양한 방법을 사용했다. 그러나 이러한 방식은 브라우저가 HTTP 요청를 보내고 웹 서버가 이 요청에 대한 HTTP 응답를 보내는 단방향 메세지 교환 '규칙'을 변경하지 않고 구현한 방식이다. 그렇기 때문에 상호작용하는 웹 페이지를 복잡하고 어려운 코드로 구현해야 했다.

 

보다 쉽게 상호작용하는 웹 페이지를 만들려면 브라우저와 웹 서버 사이에 더 자유로운 양방향 메시지 송수신이 필요하다. 그래서 HTML5 표준안의 일부로 WebSocket API(이후 WebSocket)가 등장했다.

 

표준 WebSocket의 API는 W3C에서 관장하고, 프로토콜은 IETF(Internet Engineering Task Force)에서 관장한다. 그리고 WebSocket은 다른 HTTP 요청과 마찬가지로 80번 포트를 통해 웹 서버에 연결한다. 

 

 

웹서버, 클라이언트 둘다 websocket api 가 지원되어야한다.

 

클라이언트인 브라우저 중에서는 Chrome, Safari, Firefox, Opera에서 WebSocket을 사용할 수 있으며, 각종 모바일 브라우저에서도 WebSocket을 사용할 수 있다.

 

웹 서버 중에서는 Apache에서 별도의 모듈을 설치하여 WebSocket을 사용할 수 있다. JEE 환경의 WAS에서는 Jetty, GlassFish에서 WebSocket을 사용할 수 있다. 또한 Node.js에서도 WebSocket을 사용할 수 있다. 그러나 아직 Tomcat은 공식적인 지원 계획을 발표하고 있지 않다.

 

그렇다면 Socket.io는 무엇인가?

 

Socket.io는 JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다.

 

Guillermo Rauch가 만든 Socket.io는 WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling을 하나의 API로 추상화한 것이다.

 

즉 브라우저와 웹 서버의 종류와 버전을 파악하여 가장 적합한 기술을 선택하여 사용하는 방식이다.

 

개발자가 각 기술을 깊이 이해하지 못하거나 구현 방법을 잘 알지 못해도 사용할 수 있다. 

 

Web Socket과 달리 Socket.io는 표준 기술이 아니고 Node.js 모듈로서 Guillermo Rauch가 CTO로 있는 LearnBoost(https://www.learnboost.com)라는 회사의 저작물이며 MIT 라이센스를 가진 오픈소스다.

출처: https://jokergt.tistory.com/67?category=700532 [Gun's Knowledge Base]