Redis

Redis & Cache

Cache : 나중에 요청할 결과를 미리 저장해둔 후 빠르게 서비스 해주는 것. 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache에 접근해서 요청을 처리한다.

1) Client로부터 요청을 받는다.

2) Cache에서 이미 들어왔던 작업인지 확인한 후 만약 참이면 Cache 내용을 리턴한다.

3) 거짓이라면 DB or Server에 접근해서 작업한다.

4) DB를 접근했기 때문에 한번 들어온 내용은 Cache에 저장이 되고 따라서 다시 Cache와 작업한다.

WebSocket

웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다.

웹소켓은 HTTP와 구별된다. 두 프로토콜 모두 OSI 모델의 제7계층에 위치해 있으며 제4계층의 TCP에 의존한다. 이들에 차이가 있으나 "RFC 6455"에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되었으며 HTTP 프록시 및 중간 층을 지원하도록 설계되었으므로 HTTP 프로토콜과 호환이 된다. 호환을 달성하기 위해 웹소켓 핸드셰이크는 HTTP 업그레이드 헤더를 사용하여[1] HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.

웹소켓 프로토콜은 HTTP 폴링과 같은 반이중방식에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이케 한다. 이는 먼저 클라이언트에 의해 요청을 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공함으로써, 또 연결이 유지된 상태에서 메시지들을 오갈 수 있게 허용함으로써 가능하게 되었다. 이러한 방식으로 양방향 대화 방식은 클라이언트와 서버 간에 발생할 수 있다. 통신은 TCP 포트 80(TLS 암호화 연결의 경우 443)를 통해 수행되며 방화벽을 통해 웹이 아닌 인터넷 연결을 차단하는 일부 환경에 도움이 된다. 단순 양방향 브라우저-서버 통신은 코멧 등의 스톱갭(stopgap) 기술을 사용하는 비표준 방식으로 수행된다.

구글 크롬, 마이크로소프트 에지, 인터넷 익스플로러, 파이어폭스, 사파리, 오페라 등 대부분의 브라우저가 이 프로토콜을 지원한다.

웹소켓 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

웹소켓 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹

ko.wikipedia.org

STOMP

STOMP는 Simple/Stream Text Oriented Messaging Protocol 약자다.

말 그대로 간단한 문자 기반 메세징 프로토콜이다.

프로토콜이란 원거리에서 메세지를 서로 주고 받을때 정의된 양식 규칙 체계이다.

다시말해 STOMP는 웹 상에서 텍스트 송,수신을 위해 미리 정의된 특정한 규칙이다.

STOMP에 정의한 규칙만 잘 지키면 여러 언어, 여러 플랫폼간에서 메세지를 상호 운영할 수 있다.

STOMP는 기존 AMQP 나 MQTT 와 같은 메세지 전송을 위한 다른 프로토콜들과 다르게 binary 기반이 아닌 텍스트 기반 프로토콜이다.

그렇기 때문에 개발자가 읽기 쉽고 사용하기에 좋다.

STOMP는 HTTP와 마찬가지로 프레임(frame)을 사용해 전송하는 프로토콜이다.
프레임이란 주소와 명령, 명령 수행을 위한 데이터가 모두 포함된 데이터를 의미한다.

기본적으로는 텍스트 기반 통신을 사용하지만, 바이너리 기반 통신도 지원한다.

메시지 전송 방식은 TCP 위에서 STOMP에서 정의한 Frame 구조로 Client와 Server 상호간에 메세지를 전달한다.

STOMP는 메시지를 수신 할 대상 집합을 관리하는 일을 한다.

STOMP는 메시지에 대한 스팩만을 정의하고 있기 때문에, 기능 구현은 전적으로 서버에 맡긴다.

Frame 구조

Frame은 명령(Command)과 추가적인 헤더(Header)와 추가적인 바디(Body)로 구성이 된다.

Frame은 몇 개의 텍스트 라인으로 지정된 구조인데 첫번째 라인은 텍스트(Command 명령어)이고 이후 key:value 형태로 header 정보를 포함한다.

header이후에 공백 줄을 하나 더 추가하는 것으로 header의 끝을 설정할 수 있다.

header이후에는 Payload(Body)가 존재한다.
페이로드(Payload)는 전송되는 데이터를 의미.
[EX] JSON에서 DATA 부분.
[EX] 택배 배송을 보내고 받을 때, 택배 물건이 payload.

Payload(데이터)는 Body에 위치하는데, 끝은 NULL 문자로 설정한다.

아쉬운점/느낀점

새로운 기술을 사용하고 싶은 마음에 시작했지만 일주일 이라는 시간은 부족한 것 같았다. 밤을 새가며 공부하고 구현은 성공했지만, 팀원 끼리 같이 하는 프로젝트기 때문에 다같이 힘들었을 것이다.팀원들의 동의 하에 시작하긴 했지만 처음 하는 것이라 많은 어려움이 있었다.

레디스를 사용한 이유는 통신 속도를 올리기 위해서 사용했지만, 서버쪽에 인베디드 하여 사용하니 서버를 껏다키면 모든 캐시가 날아가는 형상이 생겼다, 최근 카카오톡 서버 다운으로 인한 데이터가 날아가 엄청난 사태가 벌어졌었다. 그것을 기반으로 레디스도 서버가 꺼지더라도 데이터가 안날라 가게 하기 위해 고민을 계속 하던 도중 레디스 서버를 도커를 이용해 서버를 배포하여 사용하기로 하였고, 모든 채팅들이 저장 되게 하였고 서버거 꺼지더라도 데이터가 날라가지 않고 프론트 랜더링 시 바로 데이터가 넘어가도록 설정 하였다.