Post
웹소켓 WebSocket
Web Socket이란 Protocol의 일종, HTTP 환경에서 클라이언트와 서버 사이에 TCP 연결을 통해 실시간으로 통신을 가능하게 한다. 서버와 클라이언트 간 Socket Connection을 유지해 양방향 통신, 데이터 전송을 가능하도록 한다.
Real-time Web Application 구현을 위해 사용되고 있다.(SNS, 게임, 구글 Doc, 증권거래 등) 양방향이 가능하기 때문에 이를 구현할 수 있다. 단방향 통신의 예로는 텔레비전, 라디오 등이 있다. 이는 데이터가 수신만 가능한지 전송까지 가능한지로 구별한다.
HTTP는 HTML이라는 문서를 운반하기 위한 프로토콜로 모든 HTTP를 사용한 통신은 클라이언트가 먼저 요청을 보내고, 그 요청에 따라 웹 서버가 응답하는 형태이며 웹 서버는 응답을 보낸 후 웹 브라우저와의 연결을 끊는다.
양쪽이 데이터를 동시에 보내는 것이 아니기 때문에 이러한 통신 방식을 반이중 통신(Half Duplex)이라고 한다.
여기서 발전된 방식이 Ajax통신으로 클라이언트에서 XMLHttpRequest 객체를 이용하여 서버에 요청을 보내면 서버가 응답을 하는 방식
페이지 요청이 아닌 데이터 요청이라 부분적으로 정보를 갱신할 수 있다.
사용자의 이벤트로부터 Javascript는 사용자가 작성한 값이 쓰여진 DOM을 읽고 XMLHttpRequest 객체를 통해 웹서버에 해당 값을 전송하고 웹서버는 요청을 처리하고 XML, Text, JSON 등을 이용하여 XMLHttpRequest 객체에 전송한다.
그런다음 JavaScript가 해당 응답정보를 DOM에 쓰게 된다.
Ajax를 사용하면 새로운 HTML을 서버로부터 받아야하는 것이 아닌 동일한 페이지의 일부를 수정할 수 있는 가능성이 생기고, 사용자 입장에서는 페이지 이동이 발생되지 않고 페이지 내부 변화만 일어나게 해주므로 그만큼의 자원과 시간을 아낄수 있다.
하지만, Ajax도 결국 HTTP를 이용하기 때문에 요청을 보내야 응답이 온다.
변경된 데이터를 가져오기 위해서 버튼을 누른다거나 일정 시간 주기로 요청을 보낸다면 번거로울 뿐더러 자원 낭비가 발생한다.
예를 들어 주식에서 기업의 주가를 보려면 매번 버튼을 갱신해서 요청을 하고 서버는 이에 응답을 해주는 것 을 들 수 있다.
이러한 문제들을 해결하기 위해 웹소켓이 탄생합니다.
웹 소켓 구동 방식
WebSocket 이전 HTTP에서 실시간성을 보장하는 기법
WebSocket이 존재하기 전에는 Polling이나 Long Polling, Streaming등의 방식으로 Real-time 구현
polling
출처: https://rubberduck-debug.tistory.com/123
클라이언트가 평범한 HTTP Request를 서버로 계속 요청해 이벤트 내용을 전달받는 방식. 가장 쉬운 방법이지만 클라이언트가 지속적으로 Request를 요청하기 때문에 클라이언트의 수가 많아지면 서버의 부담이 급증한다. HTTP Request Connection을 맺고 끊는 것 자체가 부담이 많은 방식이고, 클라이언트에서 실시간 정도의 빠른 응답을 기대하기 어렵다.
Long polling
출처: https://rubberduck-debug.tistory.com/123
클라이언트에서 서버로 일단 HTTP Request를 요청한다. 이 상태로 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 Response 메세지를 전달하며 연결이 종료된다. 곧이어 클라이언트가 다시 HTTP Request를 요청해 서버의 다음 이벤트를 기다리는 방식. polling보다 서버의 부담은 적으나, 클라이언트로 보내는 이벤트들의 시간간격이 좁다면 polling과 별 차이 없게 되며, 다수의 클라이언트에게 동시에 이벤트가 발생될 경우 서버의 부담이 급증한다.
Streaming
출처: https://rubberduck-debug.tistory.com/123
Long Polling과 마찬가지로 클라이언트 -> 서버로 HTTP Request를 요청한다. 서버 -> 클라이언트로 이벤트를 전달할 때 해당 요청을 해제하지 않고 필요한 메세지만 보내기(Flush)를 반복하는 방식. Long Polling과 비교하여 서버에 메세지를 보내지 않고도 다시 HTTP Request 연결을 하지 않아도 되어 부담이 경감된다고 한다.
사용이유
웹어플리케이션에서 기존의 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어 졌으며 HTTP는 Request/response기반의 Stateless protocol이다.
즉, 서버와 클라이언트 간의 Socket connection같은 영구적인 연결이 되어있지 않고 클라이언트 쪽에서 필요할때 Request를 할때만 서버가 Response를 하는 방식으로 통신이 진행되는 한방향 통신이다. 이럴경우 서버쪽 데이터가 업데이트 되더라도 클라이언트 쪽에는 화면은 Refresh하지 않는한 변경된 데이터가 업데이트 되지 않는 문제가 발생한다. 이런 문제는 일반적은 웹어플리케이션에서는 기존의 있던 임시방편인 Long polling이라던가 Ajax를 사용해도 어느정도 해결이 가능하지만 데이터의 빠른 업데이트가 아주 중요한 요소 중에 하나인 어플리케이션에서는 실시간 업데이트가 아주 중요하기 때문에 Web Socket이 아주 중요한 기술로 사용되고 있다.
Web Socket은 Stateful protocol이기 때문에 클라이언트와 한 번 연결이 되면 계속 같은 라인을 사용해서 통신하기 때문에 HTTP 사용시 필요없이 발생되는 HTTP와 TCP연결 트래픽을 피할 수 있다. 마지막으로 Web Socket은 HTTP와 같은 포트(80)을 사용하기에 기업용 어플리케이션에 적용할 때 방화벽은 재설정 하지 않아도 되는 장점이 있다.
HTTP통신방법과 WebSocket의 차이점
WebSocket 프로토콜은 접속 확립에 HTTP를 사용하지만, 그 후 통신은 WebSocket 독자의 프로토콜로 이루어진다. 또한, header가 상당히 작아 overhead가 적은 특징이 있다. 장시간 접속을 전제로 하기 때문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하다. 더불어 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어 하나의 커넥션으로 데이터를 송수신 할 수 있다.
[Servlet이란? Servlet LifeCycle
Servlet이란 클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 웹 …
blog.naver.com](https://blog.naver.com/qoxmfaktmxj/222695230585)
댓글