꿀 떨어지는 코딩 양봉장

NestJS Lifecycle Events

nayoon030303 — Sun, 20 Aug 2023 03:14:09 +0900

그동안 1년정도 블로그를 쉬었던 것 같네요.

공부하고 그 내용을 정리해서 블로그에 올리는게 막상 쉽지는 않네요.

이제 다시 블로그에 올려보도록 하겠습니다. 혼자 하는 정리는 본인만 보는거라 부담이 없지만 블로그에 올리는건 다른 사람들도 볼 수 있는거라 더 부담이 크네요. 다시 홧팅!

- lifecycle events가 무엇인지 3줄 설명

- lifecycle 순서 설명 - 각 단계에 대해서 1줄 설명

- event 설명

- 내가 kafka 연결하면서 사용했던 예시 적기

Lifecycle Events

NestJS에 생명주기 이벤트들 입니다.

어플리케이션은 실행될 때, 종료 될 때 등등 어플리케이션 수명과 관련된 이벤트를 발생시킵니다.

그리고 NestJS에서 이벤트가 발생했을 때 실행할 동작들을 정의할 수 있습니다.

onModuleInit이라는 이벤트가 발생될 때 'Hello UserService'를 출력하겠다고 정의했습니다.

import { Injectable, OnModuleInit } from '@nestjs/common';

@Injectable()
export class UsersService implements OnModuleInit {
  onModuleInit() {
    console.log('Hello UserService');
  }
}

Lifecycle sequence

Lifecycle 공부를 하다보면 많이 보셨을 그림입니다.

생명주기는 크게 시작, 실행, 종료 부분으로 나눌 수 있습니다.

Lifecycle events

생명주기 hook 메서드	hook 메서드를 트러기하는 생명주기 이벤트
onModuleInit()	host 모듈의 종속성이 해결되면 호출 됩니다. (어플리케이션에 있어서 1회 호출)
onApplicationBootstrap()	모든 모듈이 초기화 된 다음 connection을 수신 대기 할 때 호출됩니다.(어플리케이션에 있어서 1회 호출)
onModuleDestroy()*	종료 신호(ex. SIGTERM) 가 호출되고 나서 실행됩니다.
beforeApplicationShutdown()*	onModuleDestroy()가 완료되고 나서 호출됩니다. 기존 모든 연결이 닫힙니다. (app.close() 호출)
onApplicationShutdown()*	연결이 종료된 후 호출됩니다. app.close()가 해결

* 표시가 있는 hook 메소드들은 사용을 위해서는 아래와 같이 작성해 줘야합니다.

shutdown hook listner는 시스템 리소스를 사용하므로 기본적으로 비활성화 되어있습니다.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Starts listening for shutdown hooks
  app.enableShutdownHooks();

  await app.listen(3000);
}
bootstrap();

WARNING

NestJS에서 shutdown hook을 제한적으로 지원합니다.
더 자세한것을 알고싶으면 https://nodejs.org/api/process.html#process_signal_events 링크를 통해주세요.

실제 사용 코드

제가 NestJS microservice 모듈을 이용해 kafka를 연결했을 때 사용한 코드입니다.

onModuleInit() 메서드를 오버라이딩하여 모듈의 종석성이 해결될 때 ClientKafka와 연결시켰습니다.

또 onModuleDestroy() 메서드를 이용해 어플리케이션에 종료 신호가 수신되었을 때 kafka connection을 닫도록 했습니다.

import {Controller, Get, Inject, OnModuleDestroy, OnModuleInit} from '@nestjs/common';
import { AppService } from './app.service';
import { ClientKafka } from '@nestjs/microservices';

@Controller()
export class AppController implements OnModuleInit, OnModuleDestroy{
  constructor(
    private readonly appService: AppService,
    @Inject('any_name_i_want') private readonly client: ClientKafka,
  ) {}

  async onModuleInit() {
    ['medium.rocks'].forEach((key) => this.client.subscribeToResponseOf(`${key}`));
    await this.client.connect(); // message가 비동기적으로 생성되면 connect하기 전 subscribeToResponseOf()함수를 호출해야합니다.
  }

  async onModuleDestroy() {
    await this.client.close();
  }

  @Get('kafka-test')
  testKafka(){
    const a =  this.client.emit('medium.rocks', {foo:'bar', data: new Date().toString()})
  }


  @Get('kafka-test-with-response')
  testKafkaWithResponse(){
    return this.client.send('medium.rocks', {foo:'bar', data: new Date().toString()})
  }


}

SSR, CSR, SPA, SEO

nayoon030303 — Sun, 24 Jul 2022 23:15:02 +0900

SSR이란?

Server Side Rendering
서버에서 사용자에게 보일 페이지(html, css, js)를 구성한 다음에 클라이언트에게 내려준다
페이지를 계속 렌더링 받아서 보여줘야하기 때문에 초반 로딩은 빠르지만 그 후로는 느리다.

CSR이란?

Client Side Rendering
최초요청시 html, css, js 파일을 받고 그다음부터는 서버에서는 필요한 데이터만 받아 자바스크립트단에서 View를 컨트롤한다.
초반 로딩은 느리지만 두번째 로딩부터는 서버에서 필요한 데이터만 내려받기 때문에 빠르다.

SPA이란?

Single Page Application
한 개의 페이지를 가진 애플리케이션
초기 렌더링 후 데이터만 받아오면 되기 때문에 개발에 용이하다.
기본적으로 SPA는 CSR이지만 SPA === CSR은 아니다.

SEO이란?

Search Engine Optimization
검색 엔진 최적화
검색할 때 검색 순위, 내용 등을 최적화하는 엔진

SPA의 SEO문제

SPA 초반에 렌더링이에서는 html, css, js를 받을 때는 아무런 내용이 들어가지 않는다. 그래서 검색엔진이 빈 페이지로 인식해 검색이 안될 수 있다.
하지만 SPA의 문제라기보다는 SEO(검색엔진)의 문제이다. 구글은 js를 인식할 수 있어서 크게 문제 되지 않는다.
네이버, 다음 검색 엔진 등은 자바스크립트를 인식하지 못해서 빈 페이지로 인식한다.

HTTP 헤더1 - 일반 헤더

nayoon030303 — Sun, 22 May 2022 00:29:29 +0900

HTTP 헤더 게요

HTTP 헤더 형식

header-field = field-name ":' OWS field-value OWS (OWS: 띄어쓰기 혀용)
field-name은 대소문자 구분이 없다.

HTTP 헤더 용도

HTTP 전송에 필요한 모든 부가정보가 들어있다.

HTTP 헤더 (과거: RFC2616)

과거에는 HTTP 헤더를 총 4가지로 분류했다. 하지만 2014년 RFC7230 ~7235 가 등장하면서 그전 RFC2616는 폐기되었다.

그전까지는 Entity라는 용어를 사용했지만 2014년 버전이 나오면서 Entity => Representation(표현)이라는 용어로 변경되었다.

Representatin = representation Metadata + representation Data

표현 = 표현 메타데이터 + 표현 데이터 를 뜻한다.

HTTP 표현 헤더

표현 헤더는 전송과 응답에 둘 다 사용할 수 있다.

Content - Type

표현 데이터의 형식을 설명한다.
Content-body에 들어가는 표현 데이터 형식을 설명한다.
예) text/html: charset = utf-8, image/png...

Content - Encoding

표현 데이터를 압축하기 위해서 사용된다.
보내는 쪽에서 데이터를 압축 한 다음 인코딩하고 인코딩 헤더를 추가한다.
받는 쪽에서 인코딩 헤더를 보고 압축을 해제한다.
예) gzip, deflate...

Content - Language

표현 언어의 자연 언어를 표현한다. body에 들어있는 언어가 영어인지, 한국어인지, 중국어인지를 알려준다.
예) ko, en, en-US

Content - Length

표현 데이터의 길이이고 바이트 단위이다.
Transfer-Encoding을 사용하면 Content-Length를 상용하면 안 된다.

HTTP 협상 헤더 (콘텐츠 네고시에이션)

협상 헤더는 요청 시에만 사용할 수 있다.

클라이언트가 선호하는 표현을 요청할 때 서버로 전송하는 것이다.

예를 들면 클라이언트가 선호하는 언어, 미디어 타입 등을 전송하고 서버는 그것을 보고 지원해 줄 수 있는 요청이면 응답을 해줄 때 지원한다.

Accept

클라이언트가 선호하는 미디어 타입을 주세요 하고 전달

Accept - Charset

클라이언트가 선호하는 문자 인코딩을 주세요 하고 전달

Accept - Encoding

클라이언트가 선호하는 압축 인코 등을 주세요 하고 전달

Accept - Language

클라이언트가 선호하는 자연언어를 주세요 하고 전달

HTTP 전송 방식

단순 전송: 메시지 바디에 대한 Content-Length를 지정하고 길이 값을 알 수 있을 때 사용
압축 전송: 서버에서 메시지 바디를 압축해서 전송
분할 전송: 분할해서 전송한다. 분할 전송을 사용할 때는 content-length를 사용하면 안 된다.
범위 전송: 범위를 지정해서 요청한다. 그러면 그만큼의 범위를 서버에서 전송

HTTP 일반 정보

Form: 유저의 이메일 정보
Refer: 이전 웹 페이지 주소, 유입 경로 분서 가능
User-Agent: 유저 에이전트 애플리케이션 정보, 클라이언트의 애플리케이션 정보(웹 브라우저 정보 등등)
Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
Date: 메시지가 생성된 날짜

이렇게 헤더들이 많은지 처음 알았습니다.

아직 인증과 쿠키 관련 헤더들이 남았지만 다음 포스팅에서 설명하겠습니다.

HTTP 상태 코드

nayoon030303 — Sun, 1 May 2022 21:51:11 +0900

HTTP 상태 코드

HTTP 상태 코드란 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

주로 1xx ~ 5xx 번대를 사용한다.

만약 모르는 상태 코드가 나타나도 상위 상태 코드로 해석해서 처리하면 된다.

1xx: 요청이 수신되어 처리 중
2xx: 요청 정상 처리
3xx: 요청을 완료하려면 추가 행동이 필요
4xx: 클라이언트 오류
5xx: 서버 오류

1xx (Informational)

요청이 수신되어 처리 중 (거의 사용되지 않는다.)

2xx (Successful)

200: 요청 성공
201: 요청이 성공되어 새로운 리소스가 생성
202: 요청이 접수되었지만 처리가 완료되지 않았다.
- 즉 요청은 들어왔지만 처리는 나중에 배치 프로 스세가 처리함
204: 요청은 성공했지만, 응답 페이로드 본문에 보낼 데이터가 없다.

주로 200과 201만 사용된다.

주로 개발할 때 API요청을 보내 성공했을 때 200 Response를 본 것 같다.

3xx (Redirection)

요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치가 필요

300은 사용하지 않고 301~308이 중요하다.

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동으로 이동한다. (이것을 리다이렉트)

리다이렉션 종류

영구 리다이렉션
일시 리다이렉션
특수 리다이렉션

이렇게 3가지 종류가 있다.

영구 리다이렉션 (301, 308)

리소스 URI가 완전히 변경되었다.
원래의 URI를 사용할 수 없다. 검색 엔진에서 기존 URI로 들어오면 변경
301
- 리다이렉트 요청이 GET으로 변하고, 본문이 제거될 수 있다. (될 수도 있고, 안 될 수도 있고)
308
- 301과 기능이 똑같다
- 하지만 요청 메서드와 본문을 유지한다. (POST를 보내면 리다이렉트도 POST 유지, PATCH를 보내면 리다이렉트도 PATCH 유지)
하지만 대체로 URI가 바뀌면 전송해야 하는 데이터도 달라져서 301을 사용한다고 한다.

일시적인 리다이렉션(302, 307, 303)

리소스 URI가 일시적으로 변경됨
검색 엔진에서 URI를 변경하면 안 된다.
302
- 리다이렉트 요청 시 메서드가 GET으로 변하고 본문이 제거될 수도 있다. (될 수도 있고, 안 될 수도 있고)
307
- 302와 기능이 같다.
- 리다이렉트 요청 시 메서드와 본문 유지
303
- 302와 기능이 같다.
- 리다이렉트 요청 시 메서드가 GET으로 변경

PRG ( Post/ Redirect/ Get )

그러면 일시적 리다이렉션은 언제 사용이 될까?

POST로 주문 요청을 하고 다시 웹 브라우저를 새로고침 한다면?

주문 요청을 다시 요청하여 중복 주문이 될 수 있다.

이것을 해결하기 위해서

POST로 주문 후에 주문 결과 화면을 리다이렉트
새로고침을 해도 리다이렉트 된 URI
중복 주문 대신 결과 화면만 GET으로 다시 요청

302, 307, 303 정리

현재 많은 애플리케이션들이 302를 기본값으로 상용한다.

자동 리다이렉션이 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제는 없다.

기타 리다이렉션

300
- 사용되지 않는다.
304
- 캐시를 목적으로 사용한다.
- 리소스가 수정되지 않았으므로 캐시 데이터를 사용하라고 지시
- 메시지 바디를 포함하면 안 된다.

4xx ( Client Error)

API 요청을 보내다 보면 가장 많이 만나는 상태 코드들 중 하나이다.

오류의 원인은 클라이언트에 있으므로 아무리 같은 요청을 보내도 해결되지 않는다.

400 Bad Request
- 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다.
- 예) 요청 파라미터가 잘못, API 스펙이 맞지 않다.
401 Unauthorized
- 인증(Authentication) 되지 않음
403 Forbidden
- 서버가 요청을 이해했지만 승인을 거부함
- 인증은 되었지만 접근 권한이 불충분하다.
404
- 요청 리소스를 찾을 수 없다.
- URL이 잘못되었거나, 권한이 부족한 리소스에 접할 때 해당 리소스를 숨기고 싶을 때

5xx ( Server Error)

API 개발을 하다 보면 굉장히 많이 만나는 상태 코드들 중 하나이다.

서버 내부의 문제로 같은 요청을 계속 보낸다면 서버 문제가 해결될 때 처리가 될 것이다.

500 Internal Server Error
- 서버 문제로 오류 발생
- 애매하면 500 에러를 발생
503 Service Unavailable
- 서버가 일시적으로 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
- 하지만 주로 이런 현상은 예측 불가능이기 때문에 주로 500 에러를 보게 된다.

HTTP 메서드 활용

nayoon030303 — Sat, 9 Apr 2022 23:39:47 +0900

클라이언트에서 서버로 데이터 전송 방법

클라이언트에서 서버로 데이터를 전송하는 방법은 크게 2가지이다.

쿼리 파라미터를 통한 데이터 전송 (GET)
메시지 바디를 통한 데이터 전송 (POST, PUT, PATCH)

클라이언트에서 서버로 데이터를 전송하는 상황은 크게 총 4가지이다.

정적 데이터 조회
- 정적 데이터 조회는 이미지, 텍스트 등 쿼리 파라미터 없이 리소스를 경로로 조회한다.
동적 데이터 조회
- 쿼리 파라미터를 사용해서 검색, 정렬 필터 등으로 사용된다.
HTML Form을 통한 데이터 전송
- GET, POST만 지원한다.
- 컨트롤 URI: 이런 제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.
HTTP API를 통한 데이터 전송
- HTML에서 FORM전송 대신 자바스크립트를 통한 통신에 사용된다.
- API를 호출할 때 메시지 바디에 데이터를 넣어서 전송
- 클라이언트 -> 서버뿐만 아니라
- 서버 -> 서버
- 앱 클라이언트 등에서도 사용된다.

HTTP API 설계 예시

회원 관리 시스템을 만든다고 한다면

- 회원 목록 /members -> GET
- 회원 등록/members -> POST
- 회원 조회/members/{id} -> GET
- 회원 수정/members/{id} -> POST, PATCH, PUT
- 회원 삭제/memvers/{id} -> DELETE

위처럼 만들 것이다.

다른 것들은 어떤 HTTP 메서드를 써야 할지 명확하지만 회원 수정에서 어떤 메서드를 사용해야 할까?

PUT: 기존의 리소스를 삭제하고 덮어버린다.

PATCH: 부분적으로 수정한다.

회원 수정을 할 때면 대체로 PATCH를 사용하는 것이 좋다.

게시판에 게시글을 수정할 때는 PUT을 사용한다. 게시판을 수정하는 것은 안에 내용들을 덮어쓰는 것이기 때문이다.

그럼 이런 의문이 든다. 회원 등록을 할 때도 PUT을 사용할 수 있는 게 아닐까?

어떤 상황에서 POST를 사용하고 어떤 상황에서 PUT을 사용해야 하는 것 일까?

PUT과 POST의 차이점

POST

클라이언트는 등록될 리소스 URI를 모른다.
- POST/members
서버가 등록된 리소스 URI를 생성해준다.
- /members/100
이러한 형식을 컬렉션이라고 한다.
- /members

PUT

클라이언트가 리소스 URI를 알고 있어야 한다.
- PUT/files/cat.jpg
이러한 형식을 스토어라고 한다.
- /files

PUT과 POST의 차이점은 클라이언트가 리소스 URI를 알고 있나 모르고 있나에 차이점이다.

만약 회원 등록을 한다고 하면 그 회원이 몇 번째 회원인지는 서버에서 확인할 수 있다. 즉 클라이언트는 리소스 URI를 알 수 없다.

참고하면 좋은 URI 설계 개념

문서(document)
- 하나의 개념(파일 하나, 인스턴스, 데이터베이스 row)
컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
스토어(store)
- 클라이언트가 관리하는 리소스 디렉터리
컨트롤러(controller), 컨트롤러 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행할 때 사용
- 동사를 직접 사용

HTTP 메서드

nayoon030303 — Mon, 4 Apr 2022 00:47:47 +0900

백앤드 개발을 하다 보면 API를 설계할 경우가 있다. 나도 과거에 API URI를 설계했던 적이 있었다.

그 당시 나는 URI 설계 방법에 대해서 하나도 몰랐다. 그래서 강의 처음에 나온 예시처럼

회원 목록 조회 /read-member-list
회원 조회 /read-member-by-id
회원 등록 /create-member
회원 수정 /update-membe
회원 삭제 /delete-member

이런 식으로 URI를 설계했던 적이 있었다.

그럼 좋은 URI를 설계하는 방법은 무엇일까?

API URI 설계

URI를 설계할 때 가장 중요한 것은 리소스 식별이다.

그럼 리소스는 무엇일까? 나는 리소스는 주어라고 생각한다.

위에 예시에서 회원 목록을 조회하고, 저장하고 하는 것에서 회원이라는 개념 자체가 바로 리소스이다.

조회하고, 저장하고.. 는 HTTP 메서드를 이용해서 판별할 수 있다.

리소스와 행위를 분리!

URI는 리소스만 식별한다.
리소스는 명사, 행위는 동사
행위는 HTTP 메서드를 이용해서 구분

HTTP 메서드

HTTP에 주요 메서드들만 설명하겠다.

GET

리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해 전달
message body를 사용할 수 있지만 지원하지 않는 서버가 있어서 권장하지 않음

POST

요청 데이터를 처리
애매하면 다 POST
message body를 사용해서 서버에 데이터 전달

PUT

리소스를 대체할 때 사용
클라이언트가 리소스를 알고 URI를 지정한다. (POST와의 차이점)
리소스를 완전히 대체한다.

PATCH

부분적으로 리소스를 변경할 때 사용

DELETE

리소스를 삭제

HTTP 메서드의 속성

안전

호출해도 리소스를 변경하지 않는다.

멱등(Idempotent)

한번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
멱등 메서드
- GET
- PUT
- DELETE
자동 복구 메커니즘에 활용된다.

캐시 가능

응답 결과 리소스를 캐시 해서 사용할 수 있는가?
GET, HEAD, POST, PATCH 캐시 가능
실제로는 GET, HEAD 정도만 캐시로 사용한다.

출처: HTTP - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

HTTP의 기본

nayoon030303 — Sun, 3 Apr 2022 01:23:14 +0900

HTTP는 HyperText Transfer Protocol의 약자로 개발자가 아니어도 많이 들어보았을 것이다.

HTTP는 HTML을 전송하는 프로토콜로 시작했지만 지금은 모든 것을 HTTP로 전송한다.(사진, JSON, 텍스트..)

HTTP에는 많은 버전들이 있다.

하지만 현재로 가장 표준 스펙이 되는 것은 1999년에 출시된 HTTP1.1이다.

HTTP 2.0과 HTTP3.0도 나왔지만 둘 다 성능을 개선시킨 것이다.

HTTP3.0은 UDP 기반으로 만들어졌다.

일단 지금 공부하는 HTTP는 1.1을 기준으로 설명하는 것이다.

HTTP의 특징

HTTP의 특징으로 크게 무상태 프로토콜(Stateless)과 비연결성이 있다.

무상태 프로토콜(Stateless)

무상태 프로토콜의 뜻은 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다.

아래 두 가지 상황이 있다. 비교하면서 읽어보자

상태 유지 - Stateful

고객: 자동차 얼마예요?
점원: 100만 원입니다. (자동차 상태 유지)

고객: 2개 주세요
점원: 200만 원입니다. 카드 또는 현금중 어떤 걸로 구매하시나요? (자동차, 2개 상태 유지)

고객: 현금으로 결제하겠습니다.
점원: 200만 원 결제 완료되었습니다. (자동차, 2개, 현금 상태 유지)

무상태 - Stateless

고객: 자동차 얼마예요?
점원: 100만 원입니다.

고객: 자동차 2개 주세요
점원: 200만 원입니다. 카드 또는 현금중 어떤 걸로 구매하시나요?

고객: 자동차 2개를 현금으로 결제하겠습니다.
점원: 200만 원 결제 완료되었습니다.

Stateless는 만약 중간에 점원이 다른 사람으로 바뀌어도 고객이 어떤 것을 원하는지 알 수 있다.

하지만 Stateful은 점원이 다른 사람으로 바뀌면 고객이 말한 정보를 미리 알려주지 않는 이상 알 수 없다.

그래서 Stateless는 고객이 갑자기 증가해도 점원을 대거 투입할 수 있다.

갑자기 클라이언트 요청이 증가해서 서버를 대거 투입할 수가 있다. 즉 스케일 아웃이 가능하다.

하지만 모든 것을 무상태로 설정할 수는 없다.

로그인이 필요한 것들은 상태를 유지해야 한다.

비연결성

HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 클라이언트와 서버가 계속 연결되어 있지 않는다.
일반적으로 초 단위의 이하의 빠른 속도로 응답한다.
서버 자원을 효율적으로 사용할 수 있다.

하지만 TCP/IP 연결을 새로 맺어야 한다. 3 way handshake 시간이 추가된다.

또 웹 브라우저로 사이트를 요청하면 계속 수많은 자원이 함께 다운로드된다.

지금은 HTTP 지속 연결로 문제를 해결하였다.

HTTP메시지

HTTP 메시지는

시작 라인(start-line)
HTTP 헤더(header)
공백 라인(empty line)
message body

로 구성되어있다.

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

시작 라인 (요청 메시지)

request-line으로

method SP request-target SP HTTP-version CRLF로 되어있다. (SP = 공백, CRLF = 엔터)

HTTP 메서드: GET, POST..
request-target: 요청 대상으로 절대 경로
HTTP-version: http 버전

시작 라인 (응답 메시지)

status-line으로

HTTP-version SP status-code SP reason-phrase CRLF로 되어있다. (SP = 공백, CRLF = 엔터)

HTTP-version: http 버전
status-code (HTTP 상태 코드): 요청의 성공, 실패를 나타냄
- 200: 성공
- 404: 요청 페이지 없음
reason-phrase (이유 문구): 이해할 수 있는 짧은 상태 코드 설명

HTTP 헤더

HTTP 전송에 필요한 모든 부가적인 정보가 들어간다.

메시지 바디의 크키, 압축, 인증, 내용, 등등

field-name ":" OWS field-value OWS로 되어있다. (OWS: 띄어쓰기 허용)

Message body

실제로 전송할 데이터가 들어간다.
HTML 문서, 이미지, 동영상, JSON 등등 byte로 표현할 수 있는 모든 데이터가 전송 가능하다.

HTTP 웹 기본 지식 공부하기

nayoon030303 — Thu, 31 Mar 2022 22:46:31 +0900

HTTP 웹 기본 지식을 공부하기에 앞서서

코딩을 공부하면서 나는 항상 서버와 클라이언트 통신에 대해서 궁금했었다.

tcp/ip, 프로토콜, url 등 완벽하게 알지는 못하지만 어느 정도 배웠다고 생각했다.

그러다 보안에 관련해서 궁금증이 생겼고 네트워크 통신에 대해서 더 자세히 알고 싶어서 인프런에서

모든 개발자를 위한 HTTP 웹 기본 지식이라는 강의를 찾아들었다.

강의 소개 영상에서

개발자는 평생 HTTP 기반 위에서 개발해야 하며 항상 고민한다고 말씀하셨다.

API URL은 어떻게 설계하는 것이 맞을까?
POST를 사용할까? PUT?을 사용할까?

나는 이 질문을 듣는 순가 회사에서 겪었던 상황들이 떠올랐다.

처음 API 개발을 하면서 URL을 어떻게 디자인해야 하는지(명명 규칙),

다른 회사 연동 문서에 에서 모든 api가 post로 작성되었던 상황들이 생각이 났다.

이 강의를 들으면서 http에 대해 내 머릿속에서 정리될 수 있으면 좋겠다.

총 9 섹션으로 내가 강의를 들으면서 배우게 된 것들 위주로 블로그에 정리하려고 한다.

인터넷 네트워크

IP( Internet Protocol)

IP란 주소이다. 인터넷에서 패킷을 전송하기 위해서는 간단하게 출발 IP와 도착 IP가 필요하다

우리가 편지를 보낼 때 보내는 주소와 도착하는 주소를 적는 것처럼 인터넷에서 메시지를 보낼 때 도 똑같다.

IP 프로토콜의 한계

비연결성
- 패킷을 받을 대상이 있는지 없는지 알 수 없어도 패킷을 전송한다.
비신뢰성
- 패킷이 중간에 없어질 수가 있다. (갑자기 전선이 끊기 던 지 불가피한 상황으로 패킷이 전송 안될 수 있음)
- 패킷이 순서대로 안 올 수 있다. ("안녕하세요"라고 보냈는데 "녕안세요하"라고 받을 수 있다.
프로그램 구분
- 같은 IP를 사용하는 서버 통신 프로그램이 여러 개일 수 있다. (유튜브 뮤직으로 음악을 들으면서 친구와 카톡 할 수도 있다.)

TCP/UDP

인터넷 프로토콜 4 계층으로 TCP/UDP는 전송 계층에 속한다.

인터넷 프로토콜이 무엇일까? 정보처리기능사를 공부하면서 엄청 많이 들었다.

하지만 설명할 수 있을 정도로 배우지는 못했다. 이번 강의를 통해 설명할 수 있게 되었다.

프로토콜 4 계층

애플리케이션 계층: HTTP, HTTPS, FTP
- 브라우저에서 socket 라이브러리를 통해 message를 생성한다.
전송 계층: TCP, UDP
- OS에서 생성된 message를 TCP/UDP로 감싼다.
인터넷 계층: IP
- TCP/UDP로 감싸지 message를 IP로 감싼다.
네트워크 인터페이스 계층
- LAN 드라이버, 장치 등으로 LAN 카드를 통해 서버로 전송한다.
- LAN 카드에 등록된 MAC 주소 등 물리적인 것이 포함된다.

TCP

TCP/UDP는 IP와 다르게 Port가 포함된다. 또 전송 순서, 신뢰성 등이 포함된다.

클라이언트와 서버가 연결되었는지 확인할 수 있는 방법으로 TCP 3 way handshake라는 것이 있다.

UDP

UDP는 IP에 Port만 추가되었다고 생각하면 된다.

거의 기능이 없고 기능을 추가하려면 개발자의 추가 작업이 필요하다.

하지만 TCP보다 단순하고 빠르다.

Port

IP를 설명할 때 말한 것처럼 같은 IP를 사용하는 서버와 통신하는 애플리케이션이 여러 개 있을 수 있다.

Port는 같은 IP에서 프로세스를 구분해준다.

IP가 아파트라고 생각하면

Port는 호수라고 생각하면 된다. 패킷이 101호로 가야 할지, 102호로 가야 할지 Port를 보면 알 수 있다.

DNS

도메인 네임 시스템으로 도메인 명을 IP주소로 변경해준다.

IP는 기억하기 어렵다.

ip주소가 200.200.200.123일 수도 있고 변경될 수도 있다.

우리가 맨날 그 ip주소를 기억하기 힘들다.

DNS 서버에 google.com은 200.200.200.123이라고 등록을 하면 google.com을 입력하면 자동으로 IP주소로 변경해준다.

URI, URL, URN 이란?

URI

URI는 User Resource Identifier의 약자로 리소스를 식별한다는 의미를 가지고 있다. 우리가 id로 식별하고 사람들을 주민번호로 식별하듯이 리소스(자원)가 어느 위치에 있는지 식별한다.

리소스란 모든 자원을 뜻한다. 브라우저의 html뿐만 아니라 음식점 정보, 실시간 교통량 등도 모두 리소스에 포함된다.

URI안에 URL, URN이 포함된다.

URL

URL은 Uniform Resource Locator의 약자로 리소스가 있는 위치를 뜻한다.

https://www.naver.com/

처럼 우리가 주소창에서 보는 것을 뜻한다.

URN

URN은 Uniform Resource Name의 약자로 리소스 이름을 뜻한다.

URN으로만 실제 리소스를 찾을 수 있는 방법이 보편화되어있지 않다고 한다.

이런 게 있다 정도로만 참고하기

웹 브라우저 요청 흐름

https://www.google.com/search?q=hello&sourceid=chrome&ie=UTF-8

웹브라우저 -> 구글 서버

DNS 조회를 한다. www.google.com
https 기본 포트는 443으로 생략
브라우저에서 HTTP 요청 메시지를 생성한다.
SOCKET 라이브러리 르 통해 TCP/IP로 HTTP메시지를 감싼다.
OS에서 TCP/IP 패킷을 생성한다.
LAN 카드를 통해 인터넷으로 전송

패킷을 전송받은 구글 서버는 HTTP 응답 메시지를 웹브라우저로 다시 전송한다.

SQL과 NoSQL의 차이점

nayoon030303 — Mon, 21 Feb 2022 13:18:56 +0900

이번에 새로운 토이 프로젝트를 하게 되면서 DB를 SQL로 가야 할지 NoSQl로 가는 게 좋을지에 대해 고민하게 되었습니다.

일단 SQL과 NoSQL이 무엇인지에 대해서 확실한 정의부터 알아보겠습니다.

DBMS란?

DBMS란 Data Base Management System으로 사용자와 데이터베이스 사이에서 사용의 요구에 따라서 정보를 생성해 주고 데이터 베이스를 관리해주는 소프트웨어입니다.

RDBMS란 Relational Data Base Management System으로 관계형 데이터베이스 시스템입니다.

이름과 같이 RDBMS는 RDB를 관리하는 시스템입니다. RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스입니다.

SQL 이란?

SQL은 Structure Query Language의 줄임말로 , 관계형 데이터베이스 시스템(RDBMS)에서 자료를 관리 및 처리하기 위해 설계된 언어입니다.

관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성 및 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었습니다.

핵심적인 특징으로는

데이터를 정해진 스키마에 따라서 테이블에 저장됩니다.
데이터는 관계를 통해 여러 테이블에 분산되어 저장됩니다.

대표적인 SQL 언어로는 mysql, oracle 등이 있습니다.

NoSQL 이란?

NoSQL이란 Not only SQL이라는 뜻으로 RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미합니다. 또 NoSQL은 RDBMS와는 다르게 테이블 간 관계를 정의하지 않습니다.

테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않습니다. 그래서 테이블 간 join도 불가능합니다.

NoSQL은 다양한 형태의 저장 기술을 지원하고 있습니다.

Key-value Database
Document Database
Wide Column Database
Graph Database

가 있습니다.

다양한 형태들에 대해서는 나중에 NoSQL을 정리하면서 다뤄보겠습니다.

NoSQL의 핵심적인 특징으로는

스키마가 없다.
테이블 간의 관계가 없다

확정성

SQL과 NoSQL의 장단점을 비교하기 전에 데이터베이스를 비교할 때 중요한 Scaling이라는 개념에 대해서 알아봅시다.

데이터베이스 서버의 확장성은 ‘수직적’ 확장과 ‘수평적' 확장으로 나누어집니다.

수직적 확장: 데이터베이스 서버의 성능을 향상하는 것을 말합니다.(ex. CPU 업그레이드)
수평적 확장: 더 많은 서버가 추가되어 데이터베이스가 전체적으로 분산되는 것을 의미합니다.

SQL의 장단점

장점

정해진 스키마에 따라서 데이터를 저장하기 때문에 명확한 데이터 구조를 보장한다.
관계는 각 데이터를 중복 없이 한 번만 저장할 수 있다.

단점

테이블 간 관계를 맺고 있어서 join문이 많은 복잡한 쿼리가 만들어질 수 있다.
유연하지 못한다. 나중에 스키마가 변경되는 경우 복잡해진다.
대체적으로 수직적 확장만 가능하다. 이로 인해 비용이 기하급수적으로 늘어날 수 있다.

NoSQL의 장단점

장점

스키마가 없어서 자유로운 데이터 구조를 가질 수 있다.
데이터 애플리케이션이 원하는 형식으로 데이터를 저장해서 읽는 속도가 빠르다.
수직적 확장, 수평적 확장 둘 다 가능하다.

단점

데이터 중복이 발생할 수 있다.
데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 한다.
명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정이 어려울 수 있다.

SQL 데이터베이스 사용이 더 좋을 때

관계를 맺고 있는 데이터가 자주 변경되는 경우
데이터 구조가 명확하여 스키마가 변경될 경우가 적은 경우

NoSQL 데이터베이스 사용이 더 좋을 때

정확한 데이터 구조를 알 수 없거나 변경/확장될 수 있는 경우
데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 시에는 모든 컬렉션을 수정해야 합니다. 그래서 read를 자주 하지만 update는 자주 없는 경우
막대한 양의 데이터를 다뤄야 하는 경우(수평적 확장

이번 토이 프로젝트로 ToDo리스트 웹을 만들기로 했습니다.

중복되는 데이터의 수가 적을 것 같고 데이터의 구조가 변경될 것을 고려해서(Todo리스트에서 부모 단위와 자식 단위의 구조) NoSQL을 사용할 것으로 결정했습니다.

Authentication(인증) & Authorization(허가)가 무엇인가?

nayoon030303 — Thu, 17 Feb 2022 01:43:26 +0900

Authorization(허가), Autentication(인증)은 대부분의 애플리케이션에서 필수적인 부분들입니다.

Authentication(인증) & Authorization(허가)가 무엇인가?

1. Authentication(인증)

사용자가 누구인지에 대해서 확인하는 절차입니다(로그인 또는 회원가입을 하는 것)

2. Autorization(허가)

사용자에 대한 권한을 허락하는 것입니다.

왜 필요할까?

서비스를 사용하는 사용자가 누구인지? 언제? 어디서? 어떻게? 사용하고 있는지 파악하기 위해서입니다.

Authentication(인증)

인증은 사용자가 누구인지(identifacation)을 확인하는 절차입니다.

예를 들면 사용자의 아이디와 비밀번호를 확인하는 과정입니다.

사용자의 비밀번호는 절대로 그대로 DB에 저장하지 않습니다.
DB를 해킹당하면 사용자의 정보가 그대로 노출되고 개발자가 사용자의 정보를 볼 수 있습니다.

Authorization(허가)

허가란 요청한 request를 실행할 수 있는 권한이 있는 사용자인지 확인하는 절차입니다.

예를 들어 쇼핑몰 사이트가 있다고 생각해봅시다. 관리자와 고객이 사용할 수 있는 요청 권한이 다를 것입니다.

관리자는 상품의 가격을 조정하는 요청을 보낼 수 있지만 고객은 그럴 수 없습니다.

Authorization 방법

Authentication(인증) 절차를 통해서 사용자에게 access_token을 발급합니다.
사용자가 request(요청)을 보낼 때 access_token을 같이 보냅니다.
서버에서 사용자가 첨부한 access_token을 검사합니다.
유저가 권한을 가지고 있다면 요청을 처리합니다.