[SERVER][HTTP, AJAX 통신, WebSocket, SSE] 특징, 장단점

HTTP

HyperText Transfer Protocol

HTTP 이전의 통신은 FTP, NNTP 등의 프로토콜이 사용되었는데, 터미널 위에서만 통신이 가능했으며 전문가 말고는 사용이 정말 어려웠습니다.

Server와 Client간의 일련의 흐름을 하나의 약속으로 지정한 프로토콜이 바로 HTTP입니다.

HTTP 통신 과정은 다음과 같습니다!

Client가 어떠한 정보를 요청하면, Server는 그런 정보를 처리해서 HTML화 시킨 후 응답하는 거죠

하지만 이 방법은 큰 문제점이 하나 있었는데요!

Server가 html을 통해서 결과창 자체를 결과로써 전송하기 때문에 client가 결과를 확인하기 위해서는 반드시 페이지를 이동해야 했다는 것입니다.

그래서 옛날에는 어떤 결과를 봐야할 때 팝업을 많이 이용했다고 해요!

페이지를 매번 이동하는 것은 여러 문제를 야기하고 자원을 낭비하게 하니까요!

하지만 구글이 이 답답한 HTTP 방식을 약간 우회할 수 있는 AJAX를 내놓으면서 상황이 달라지게 됩니다.

AJAX 통신

Asynchronous Javascript And Xml 비동기적인 자바스크립트와 XML

비동기 방식: 웹페이지를 리로드하지 않고 데이터를 불러오는 방식, AJAX의 특성

이미지, 스크립트를 요청했을 때, 동기 방식은 이미지와 스크립트를 한번에! 모든 페이지를 돌면서 불러와야 하므로 리소스 낭비가 큽니다.

비동기 방식은 필요한 부분만 불러와서 사용할 수 있으므로 큰 이익을 볼 수 있겠죠.

동작 방법

사용자의 이벤트로부터 Javascript는 사용자가 작성한 값이 쓰여진 DOM(Document Object Model은 웹 페이지에 대한 인터페이스입니다.

기본적으로 여러 프로그램들이 페이지의 콘텐츠 및 구조, 그리고 스타일을 읽고 조작할 수 있도록 API를 제공합니다.)을 읽습니다.

그리고 XMLHttpRequest 객체를 통해 웹서버에 해당 값을 전송하고 웹서버는 요청을 처리하고 XML, Text, JSON 등을 이용하여 XMLHttpRequest 객체에 전송합니다.

그런다음 JavaScript가 해당 응답정보를 DOM에 쓰여집니다.

이점 1. 부분적으로 변화시킬 수 있다.

Client가 Server에 요청을 보낼 때 대부분의 상황에서는 모든 페이지의 변화를 요구하지 않습니다.

그러므로 이렇게 부분만의 변화를 요할 때에는 HTML 페이지의 전체가 아닌 일부분만 갱신할 수 있도록 XML HttpRequest 객체를 통해 서버에 request를 보내는거죠.

이 경우 Json이나 XML 형태로 필요한 데이터만 받아서 갱신하기 때문에 자원과 시간을 아낄 수 있습니다.

이점2. 변경사항이 발생할 때마다 페이지를 이동할 필요가 없다.

옛날에는 회원가입을 할 때 팝업창을 띄워서 아이디 유효성 검사를 했었다고 합니다.

기존 환경에서는 내가 적은 아이디를 사용할 수 있는지 유효성 검사를 하기 위해 Client가 Server에 아이디 정보를 보내면 Server는 새 창을 통해서만 검사 결과를 보낼 수 있었습니다.

하지만 이렇게 되면 작성해 놓은 회원가입 정보가 다 날아갈 수 있겠죠?

AJAX를 이용하면 그냥 ID를 쓰면 바로 그 창에서 유효검사를 할 수 있게 되었습니다.

부분 반환이 가능해졌기 때문이죠! 이게 현재 많이 사용하는 방식인거죠!

하지만 이 방법에도 경우에 따라 단점이 있습니다.

Client가 요청을 보내지 않아도 Server로부터 응답을 받아야 하는 상황이 존재합니다.

채팅이나 알림(push 메세지)의 경우가 그러합니다.

채팅 상대방이 방에 들어오고 채팅을 받고 보내는 과정들을 Client의 요청이 있을 때만 Server가 응답해준다면 엄청 답답하겠죠

또 특정 앱의 push 메세지가 언제 도착할지 모르는 상황에서 핸드폰이 항상 이를 대기하고 있지 않을 겁니다.

이러한 불편함을 HTML5와 함께 등장한 WebSocket이 해결해줍니다.

WebSocket 웹 소켓

처음에도 언급했듯이 웹 소켓은 통신 프로토콜로 서버와 클라이언트 간의 효율적인 양방향 통신을 실현하기 위한 구조입니다.

웹소켓은 단순한 API로 구성되어 있으며, 웹소켓을 이용하면 양방향 메세지를 자유롭게 주고 받을 수 있습니다.

브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있습니다.

채팅, 게임, 실시간 주식차트와 같은 실시간이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현할 수 있습니다.
가상화폐의 분산화 기술의 핵심도 WebSocket으로 구현할 수 있습니다.

작동 원리

웹소켓 연결 역시 HTTP 프로토콜을 통해 이루어집니다.

연결이 정상적으로 이루어진다면 서버와 클라이언트 간에 웹소켓 연결(TCP/IP기반)이 이루어지고 일정 시간이 지나면

HTTP연결은 자동으로 끊어집니다.

기본적으로 웹소켓 API는 아주 간단한 기능들만을 제공하기 때문에 대부분의 경우 SockJS나 Socket.IO같은 오픈 소스 라이브러리를 많이 사용하고 있으며 메시지 포맷 또한 STOMP같은 프로토콜을 같이 이용합니다.

문제점

1. 프로그램 구현에 보다 많은 복잡성을 초래합니다.

웹 소켓은 HTTP와 달리 Stateful protocol(상태 프로토콜)이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 비정상적으로 연결이 끊어졌을때 적절하게 대응해야 합니다. 이는 기존의 HTTP 사용시와 비교했을때 코딩의 복잡성을 가중시키는 요인이 될 수 있습니다.
서버와 클라이언트 간의 Socket 연결을 유지하는 것 자체가 비용이 듭니다.
특히나 트래픽 양이 많은 서버같은 경우에는 CPU에 큰 부담이 될 수 있습니다.
오래된 버전의 웹 브라우저에서는 지원하지 않습니다. (물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있습니다.)

SSE (Server-Sent Events)

SSE는 HTTP 스트리밍을 통해 서버에서 클라이언트로 단방향의 Push Notification을 전송할 수 있는 HTML5 표준 기술입니다.

웹 소켓 방식이 서버와 클라이언트 간의 연결을 유지해야 하는 반면 SSE는 http 연결만 되어 있으면 클라이언트 요청 없이도 서버에서 클라이언트로 데이터를 보낼 수 있습니다.

전통적인 웹 애플리케이션이라면 클라이언트의 요청 단건에 대해 서버가 응답하는 방식이지만 SSE를 이용하면 별도의 복잡한 기술이 필요없이 HTTP 프로토콜을 기반으로 서버에서 클라이언트로 Real-Time Push Notification을 전송할 수 있는 것입니다. 클라이언트의 요청에 의해 한 번 연결이 맺어지면 서버가 원하는 시점에 클라이언트에게 원하는 메시지를 전송할 수 있습니다. 이러한 특징 덕분에 최소의 오버헤드로 모니터링 시스템의 그래프 갱신, 채팅 및 메신저 등의 비지니스에 광범위하게 적용할 수 있습니다.

REFERENCE

20.06.05 WebSocket_1 WebSocket이전의 Web

웹 소켓 이전의 이야기들. 1. HTTP 2. AJAX 설명은 직접 제작한 발그림과 함께

velog.io

Spring Boot, SSE(Server-Sent Events)로 단방향 스트리밍 통신 구현하기

개요 Server-Sent Events (이하 SSE)는 HTTP 스트리밍을 통해 서버에서 클라이언트로 단방향의 Push Notification을 전송할 수 있는 HTML5 표준 기술이다. 이번 글에서는 Spring Boot에서 SSE를 이용한 단방향 스..

jsonobject.tistory.com

[Spring + SSE] Server-Sent Events를 이용한 실시간 알림

코드리뷰 매칭 플랫폼 개발 중 알림 기능이 필요했다. 리뷰어 입장에서는 새로운 리뷰 요청이 생겼을 때 모든 리뷰가 끝나고 리뷰이의 피드백이 도착했을 때 리뷰이 입장에서는 리뷰 요청이 거