동기 (sync)

• 메소드를 실행시킴과 동시에 결과 값이 기대되는 경우, 요청을 보낸쪽에서 결과가 반환될 때까지 기다린다.
• 안전성과 실행순서가 보장된다.
• 느리다.

비동기 (async)

• 요청을 보낸 쪽이 아니라 응답을 주는 쪽에서 결과를 알려준다.
• 요청을 보낸 쪽은 응답이 올 때까지 다른일을 하고 있는다.
• 빠르다.
• 순서가 보장되지 않기 때문에 처리하기가 까다로울 수 있다.
• 비동기로 처리하면 백그라운드에서 해당 작업을 처리하는 것을 의미한다.

블로킹(blocking)

• 스레드에서 발생하는 대기현상
• 네트워킹을 해야하는 대상이 여럿이라면 블로킹 소켓의 경우 대상 개수만큼 스레드를 생성한다. (멀티 스레드)
• 스레드가 많아지면 각 스레드가 차지하는 호출 스택 자원과 컨텍스트 스위칭 비용이 많이 발생한다.
• 즉, 블로킹 매커니즘의 주요 특징은 I/O가 가득 수신할 때까지 주어진 스레드가 아무것도 하지 않는다고 가정하는 것이다. 이 경우 메서드가 제어권을 반환하지 않으므로 애플리케이션 플로우가 블록된다.

논블로킹(non-blocking)

• 소켓 시스템콜에 대해 네트워크 시스템이 즉시 처리할 수 없는 경우라도 제어권이 바로 리턴되어 프로그램이 블록되지 않게하는 소켓 모드이다.
• 통신 상대가 여럿이거나 여러 작업을 병행하려면 논블로킹 또는 비동기 모드를 사용해야 한다.
• 어떤 시스템콜이 성공적으로 실행될 때까지 계속 루프를 돌면서 확인한다.(폴링)
• 단일 스레드로 운영할 경우 순차 실행을 보장할 수 있지만, 시간이 오래걸리면 그만 큼 다른 채널의 이벤트를 수행하지 못한다. 이럴땐 멀티스레드로 구현해야 한다.
• 논블로킹 매커니즘은 I/O요청을 즉시 큐에 넣고 애플리케이션 플로우 제어를 반환한다. 요청은 나중에 커널에서 처리된다. (리액티브)
• 블로킹보다 구현이 어렵지만, 성능과 확장에 유리하다.

논블로킹 ≠ 비동기

• 논블로킹 환경에서 응답이 빨리 돌아오지 않는다면 API는 에러와 함께 복귀하고 다른 행동을 하지 않는다. 반면 비동기 환경에서는 API는 항상 즉시 복귀하지만 응답은 늦게 돌아오기도 한다.
• 즉, 논블로킹 매커니즘에서 함수가 호출되어 있어도 제어권이 반환되었으므로 다음 작업을 실행하고, 비동기 매커니즘에서는 함수호출을 스택에 남겨두고 함수호출을 대신하여 작업이 계속 이어진다. (다른 스레드에서!)
• 비동기는 병렬(parallel)에 가깝고, 논블로킹은 폴링(polling)에 가깝다.

문제점

• 많은 요청이 들어왔을 때 순차적으로 실행이 돼 속도가 느리고 서버에 과부화 가 걸린다고 생각

해결방안

• 데이터가 많을 시 로직이 다 수행 되는 데 시간이 많이 걸리므로 api 요청을 즉시 반환하고 제어권이 반환되었으므로 다음 작업을 실행하고, 비동기 매커니즘에서는 함수 호출을 스택에 남겨두고 함수 호출을 대신하여 작업이 계속 이어지게 함.(다른 쓰레드에서)

@Configuration
@EnableAsync
public class AsyncConfig extends AsyncConfigurerSupport {
//    @Configuration : Spring설정 관련 Class로 @Component
//등록되어 Scanning될 수 있다.
//    @EnableAsync : Spring method에서 비동기 기능을 사용가능하게 활성화 한다.
//    CorePoolSize :기본 실행 대기하는 Thread의 수**
//    MaxPoolSize :동시 동작하는 최대 Thread의 수
//    QueueCapacity : MaxPoolSize초과 요청에서 Thread생성 요청시,
//해당 요청을 Queue에 저장하는데 이때 최대 수용 가능한 Queue의 수,
//    Queue에 저장되어있다가 Thread에 자리가 생기면 하나씩 빠져나가 동작
//    ThreadNamePrefix :생성되는 Thread접두사 지정
//크기가 제한된 큐에 작업이 가득 차면 집중 대응 정책 saturation policy가 동작한다.
//    1.집중 대응 정책은 ThreadPoolExecutor에 setRejectedExecutionHandler메소드를 사용해 설정할 수 있다.
//중단 정책(abort)
//기본적으로 사용하는 집중 대응 정책이며 execute메소드에서 RejectedExecutionException을 던진다.
@Override
public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor =newThreadPoolTaskExecutor();
        executor.setCorePoolSize(8);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(10000);
        executor.setThreadNamePrefix("async-tread-");
        executor.setRejectedExecutionHandler(newThreadPoolExecutor.AbortPolicy());
        executor.initialize();
return executor;
    }
}

결과

• 응답 속도는 엄청 나게 빨라 졌지만 @Async의 기본 반환이 void라 프론트에 반환해줘야 할 데이터가 반환 되지 않음.
• CompletableFuture<ResponseDto<LankRoundDto>> CompletableFuture을 사용하면 원하는 반환 값을 리턴 할 수 있다고 하여 사용

FULLTEXT 검색 방식

• 자연어 검색(natural search)
  검색 문자열을 단어 단위로 분리한 후, 해당 단어 중 하나라도 포함되는 행을 찾는다.
• 불린 모드 검색(boolean mode search)
  검색 문자열을 단어 단위로 분리한 후, 해당 단어가 포함되는 행을 찾는 규칙을 추가적으로 적용하여 해당 규칙에 매칭되는 행을 찾는다.
• 쿼리 확장 검색(query extension search)
  2단계에 걸쳐서 검색을 수행한다. 첫 단계에서는 자연어 검색을 수행한 후, 첫 번째 검색의 결과에 매칭된 행을 기반으로 검색 문자열을 재구성하여 두 번째 검색을 수행한다. 이는 1단계 검색에서 사용한 단어와 연관성이 있는 단어가 1단계 검색에 매칭된 결과에 나타난다는 가정을 전제로 한다.

풀 텍스트 인덱스 생성

1. CREATE FULLTEXT INDEX unique_code_idx ON lotto(unique_code);

2. alter table lotto add FULLTEXT(unique_code);

FULLTEXT 검색 엔진 설정하기

검색어가 너무 짧은 경우 아무런 검색결과도 나오지 않는다. 이때 짧다는 기준은 4글자 이하다. 만약 2글자의 검색어를 지원하려면 최소 검색어 길이 값을 2로 수정해야 한다. my.cnf 설정파일을 열어서 ft_min_word_len 변수 값을 기본값인 4에서 2로 변경한다

적용 되었는지 확인

풀텍스트 쿼리 문

1. 자연어

자연어 검색 시 관련이 낮은 것도 같이 검색이 된다.

select * FROM lotto WHERE MATCH(unique_code) AGAINST("d4b42907b15d43cfb0b1e635aeff4a00" );

2. 불린 모드

• 검색의 정확도에 따라 결과가 정렬되지 않는다.
• 구문 검색이 가능하다
• 필수(+), 예외(-), 부분(*) 연산자를 사용할 수 있다

d4b42907b15d43cfb0이 포함된 구문만 검색 된다.

select * FROM lotto WHERE MATCH(unique_code) AGAINST("+d4b42907b15d43cfb0*" IN BOOLEAN MODE);

3.인덱스 타는 지 확인.

describe select * FROM lotto WHERE MATCH(unique_code) AGAINST("d4b42907b15d43cfb0b1e635aeff4a00" IN BOOLEAN MODE);

요번주는 모의 기술면접을 봤다.....

코딩공부를 하면서 이분야에서 처음 보는 면접이였고 긴장되어서 질문을 받았을 때 잘 생각이 나지않았다 ㅠㅠ

면접을 보면서 cs지식도 많이 필요하다고 느꼈다.

면접 질문 중 db에 대해 많이물어보셨다.

그중 가장 기억나는 거는 트랜젝션이였다.

서비스 코드에서 @Transactional 을 많이 쓴다.

그런데 사실 뜻도 잘 모르고 좋다고 쓴거라... 정확히 설명하기가 어려웠다.

트랜잭션이란?

데이터베이스 트랜잭션은 데이터베이스 관리 시스템 또는 유사한 시스템에서 상호작용의 단위이다.

여기서 단위라는 말을 사용했는데, 쉽게 말하면 더 이상 쪼개질 수 없는 최소의 연산이라는 의미가 된다.

1. 트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위이다.

2. 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업단위이다.

3. 하나의 트랜잭션은 Commit되거나 Rollback된다.

Atomicity(원자성)

1. 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.

2. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

Consistency(일관성)

1. 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.

2. 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.

Isolation(독립성,격리성)

1. 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다.

2. 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

Durablility(영속성,지속성)

1. 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

Commit연산

1. Commit 연산은 한개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.

Rollback연산

1. Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산이다.

2. Rollback시에는 해당 트랜잭션을 재시작하거나 폐기한다.

@Transactional의 작동 원리와 흐름

그렇다면 @Transactional이 붙은 메서드를 호출할 경우, 우리 코드에는 어떤 일이 벌어질까?

@Transactional이 클래스 내지 메서드게 붙을 때, Spring은 해당 메서드에 대한 프록시를 만든다.

프록시 패턴은 디자인 패턴 중 하나로, 어떤 코드를 감싸면서 추가적인 연산을 수행하도록 강제하는 방법이다.

--프록시란 실제 엔티티 객체 대신에 사용되는 객체로서 실제 엔티티 클래스와 상속 관계 및 위임 관계에 있습니다.

프록시 객체는 실제 엔티티 클래스를 상속 받아서 만들어지므로 실제 엔티티와 겉모습이 같습니다.

트랜잭션의 경우, 트랜잭션의 시작과 연산 종료시의 커밋 과정이 필요하므로, 프록시를 생성해 해당 메서드의 앞뒤에 트랜잭션의 시작과 끝을 추가하는 것이다.

서비스 클래스에서 @Transactional을 사용할 경우, 해당 코드 내의 메서드를 호출할 때 영속성 컨텍스트가 생긴다는 뜻이다. 영속성 컨텍스트는 트랜잭션을 시작할 때 생겨나고, 메서드가 종료되어  트랜잭션을 커밋할 경우 영속성 컨텍스트가 flush되면서 해당 내용이 반영된다. 이후 영속성 컨텍스트 역시 종료되는 것이다.

isolation

트랜잭션에서 일관성없는 데이터 허용 수준을 설정한다

propagation

트랜잭션 동작 도중 다른 트랜잭션을 호출할 때, 어떻게 할 것인지 지정하는 옵션이다

noRollbackFor

특정 예외 발생 시 rollback하지 않는다.

rollbackFor

특정 예외 발생 시 rollback한다.

timeout

지정한 시간 내에 메소드 수행이 완료되지 않으면 rollback 한다. (-1일 경우 timeout을 사용하지 않는다)

readOnly

트랜잭션을 읽기 전용으로 설정한다.

DB의 꽃 옵티마이저의 실행 계획 수립

RDBMS에서 가장 복잡하면서 가장 중요한 것은 옵티마이저(Optimizer)가 쿼리를 어떻게 실행할지 실행 계획을 결정하는 부분이다.

똑같은 쿼리라 할지라도 다양한 방법과 순서로 실행 될 수 있다.

어떤 실행 계획이 좋고 어떤 실행 계획이 안 좋은지 판단하는 건 온전히 옵티마이저의 몫이지만 개발자 역시도 어떤 실행 계획으로 수행되어야 좋은지를 알아야 최적의 실행 계획을 사용할 수 있도록 옵티마이저에게 힌트를 줄 수 있기 때문에 중요하고 반드시 학습해야하는 부분이다.

사전 지식

실행 계획에 대해 자세히 살펴보기 전에 아래의 사전 지식이 있어야 한다.

• 쿼리 실행 절차
  1. SQL을 SQL 파서가 파싱하여 파서 트리(parser tree)를 만든다.
  2. 파서 트리를 기준으로 옵티마이저가 분석하여 실행 계획을 만든다.
• 옵티마이저의 종류
  1. 규칙 기반 옵티마이저 : 이제는 안 쓰임
  2. 비용 기반 옵티마이저 : 쿼리 대상 테이블의 레코드 수, 선택도 등 통계 정보를 바탕으로 비용이 가장 적을 것 같은 방향으로 실행 계획 생성 → 대부분 이 방식 옵티마이저 사용(MySQL포함)
• 통계 정보가 정확할 수록 좋은 실행 계획을 만들 확률이 높다.
  • 통계 정보는 서비스중에도 수집되고 수정된다. innodb_stats_sample_pages 설정값은 통계 정보를 위해 분석할 인덱스 페이지의 개수(기본값:8)를 지정하는 것인데, 분석할 페이지 개수를 늘려서 더 정확한 통계 정보를 수집할 수 있지만, 수집 중에 테이블의 읽기/쓰기가 되지 않으므로 문제될 수 있다. 따라서 최대 16~24까지만 설정해야한다.
  • MySQL 8.0 부터는 인덱스 말고 일반 컬럼에도 통계 정보(Histogram)를 수집하기 때문에 더 정확한 통계를 토대로 실행 계획을 수립할 수 있다.
  • ANALYZE 키워드를 이용해 테이블의 통계 정보를 다시 수집할 수 있다.
• EXPLAIN 키워드를 SELECT 쿼리 앞에 붙여서 실행 계획을 살펴볼 수 있다.
  • INSERT, UPDATE, DELETE 쿼리는 실행 계획을 알 수 없다.

인덱스 사용중인 지 확인을 위함.

클라우드 사용시 대량의 데이터 트래픽을 기본 프리티어로 견디지 못해 서버거 자꾸 내려감.

클라우드 티어 업그레이드 할 시 비용 문제로 인한 개인 서버 사용.

온프레미스

집을 짓는다고 할 때 집을 짓기 위한 자제 구매부터 건물 도면을 그리는 작업, 시공, 건축 그리고 인테리어까지 모든 과정을 도움없이 집을 필요로 하는 사람이 혼자서 다 처리하는 방법

즉, 온프레미스란 필요한 시스템을 구축하기 위해서 하드웨어와 소프트웨어를 구입하여, 시스템 구성 상황에 맞게 환경을 구성하는 것을 말합니다. 즉 서버실과 혹은 데이터 센터와 같이 특정 공간에 IT 인프라를 구축하여 소프트웨어를 사용하는 방식입니다. 이러한 방법은 인프라를 구축하기 위한 기간이 필요하며, 상황에 따라서는 몇 개월 이상이 걸리기도 합니다. 또한 시스템을 구축하기 위한 물리적인 하드웨어 장비를 구매하는 비용이 들어가며, 부차적으로는 이를 관리 및 운용을 위한 유지보수 비용을 필요로 합니다.

클라우드 시스템

온프레미스처럼 집을 짓는다고 가정하면, 집을 만드는 과정에서 자내나 도구 혹은 전문가의 도움을 필요에 따라 제공받는 방법.
그렇기 때문에 온프레미스는 서비스를 만들기 위해 하나부터 열까지 다 알아야 하지만, 클라우드 시스템은 하나부터 다섯까지 정도만 알아도 ok

즉, 온프레미스와 클라우드 시스템의 가장 큰 차이는

서비스를 제공함에 있어 사용하는 IT 자원을 누가 관리하느냐임
온프레미스: 서비스를 공급하는 서비스 제공자가 직접적으로 IT 자원을 관리하는 주체
클라우드 시스템: 서비스를 공급하는 서비스 제공자는 IT 자원을 사용할 뿐, 대부분의 IT 자원 관리는 클라우드 서비스 제공자에게 제공받음

어떻게 보면 클라우드 시스템은

서비스에 필요한 인프라를 직접 보유하지 않고 필요할 때만 사용할 수 없을까?라는 질문에 답을 하기 위해 나온 기술

이라고 봐도 좋다.

차이점

1. 비용

클라우드 서비스가 제공되지 이전에는 IT 프로젝트를 구성하기 위해서는 온프레미스 시스템을 먼저 도입하고 프로젝트를 진행함.

일반적으로 예측된 데이터를 기준으로 인프라 지식을 갖춘 기술자가 물리적인 구성을 설계함

이때 물리적인 구성은 최대 사양을 기준으로 구성되기 때문에 실제 프로젝트 오픈 시 예측과 다른 경우가 많음 => 이로인해 불필요한 비용이 사용되는 경우가 많음

반면 클라우드 시스템의 경우 서비스에서 제공되는 옵션을 통해 시스템 사양을 실시간으로 수정해 사용이 가능

즉, 불필요한 비용이 들지 않음!

온프레미스는 한번 확정이 된 시스템 사양을 바꾸기가 어렵기 때문에 불필요한 비용이 지속적으로 낭비되지만, 클라우드 시스템은 상황에 따라 적절한 비용으로 시스템을 운용할 수 있도록 도와줌

또한 온프레미스는 물리적인 구성에 필요한 절차 및 시간을 필요로 하는데 클라우드 시스템은 가상에서 시스템을 구성할 수 있어 불필요한 절차를 없애고 쉽게 프로젝트를 구성할 수 있도록 함 => 프로젝트 초기 구성시 드는 비용을 줄여주는 효과

2. 시스템 유지 보수

일반적으로 서버 인프라는 기본 지식으로만 응대하기 어려운 부분이라 인프라에 관한 전문가가 필요함

인프라는 단순히 서버 물리적인 위치 구성 뿐만 아니라 서버 간의 흐름, 역할에 맞는 서버 배치 및 보안 관리 이슈등 여러가지 관점에서 관리되어야 하는 분야이기 때문에 한 명의 전문가가 모든 일들을 처리할 수 없음

이러한 관점에서 프로젝트는 시작부터 유지보수 단계까지 지속적으로 인프라 전문가 인원을 운용해야
또한 온프레미스는 인프라를 직접 운영하고 관리하기 때문에, 현대와 같이 IT 인프라가 점차 복잡해지는 환경에서는 유지보수가 용이하지 못합니다. 직접 인프라를 운용하는 기업들은 날이 갈수록 발전하고 복잡해지는 IT 환경 속에서 지속적으로 발생하는 인프라의 확충과 컴퓨팅 파워 및 저장능력 향상에 대한 끊임없는 책임을 지녀야 하고, 기업이 가진 자산 혹은 개인정보를 지키기 위해서 많은 노력과 비용을 투자해야 하기 때문입니다.

이때, 온프레미스는 모든 관리를 직접적으로 하기 때문에 인프라 전문들을 지속적으로 유지해야 하고 섭외하지 않은 분야의 문제가 생기는 경우 빠른 대처가 어려움. 특히 성능 이슈로 인해 서버의 증설 문제가 발생하는 경우 물리적인 시간 필요

반면 클라우드 시스템은 말 그대로 인프라에 관련된 전문가들이 항시 문제를 해결할 수 있도록 대기중이며, 어떤 이슈가 발생하더라도 응대할 수 있는 인원 및 체계가 갖춰져 있음.
또한 성능 이슈로 인한 서버 증설 문제의 경우 단 한번의 클릭으로 몇분, 몇 시간 내 해결 가능

4조 실전 프로젝트 팀 노션 (notion.site)

실전프로젝트 시작

주제 : 로또 시뮬레이션

목적 : 대용량의 클라이언트 로또 번호 더미데이터를 생성하고 그것을 로직화하여 당첨번호와 비교하여 등수 가려내는 로직 목적

ERD

레이아웃

회차별 당첨번호 < 로또6/45 < 당첨결과 | 동행복권 (dhlottery.co.kr)

느낀점

매일 회의를 하며 일일 회고를 노션을 통해 쓰기 시작했고 자신이했던 일들을 기록하면서 서로 회의를 하며 프로젝트를 진행하고 있다. 백엔드 적인 기능 구현을 중점으로 만들어진 백엔드 반이라 처음에는 어떤것을 해야하는지를 모르기떄문에 많은 생각을 하게되었고 서로 의견이 맞지않아 트러블도 생겼다 . 나는 새로운 기술 스텍을 사용하여 그것을 파고 들고 그그 기술을 잘 활용하면 될것 같다 생각을 했지만 토요일에 피드백을 받고 우선 항해에서 원하는 것은 느리더라도 기본을 우선 파고들고 기본 스프링에서 여러가지를 해본 후 더 이상  해결 할 수 없을 것 같을 경우에 나중에서야 그 기술 스텍을 사용하라고 하는 것 같았다.  배우는 입장이기 때문에 우선 이렇게 진행하기로 헀다.

• 기간 10월 28일(금)~11월 4일(목)
• 프론트&백엔드 협업 클론 코딩(KAKAOTALK)

Redis

1. 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)

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 문자로 설정한다.