Javascript

Javascript 란?

자바스크립트 엔진 - V8

자바스크립트 엔진은 자바스크립트 코드를 이해하고 실행을 도와줍니다. 대표적인 엔진으로 V8 Engine (Chrome, Node.js 에서 사용)이 있으며, 각 브라우저 별로 여러가지 엔진들이 존재합니다.

V8 엔진이란?

• Google이 주도하여 개발한 오픈소스임.
• C++로 작성된 고성능의 자바스크립트 & 웹 어셈블리 엔진임.
• Call Stack 과 Memory Heap으로 구성되어 있음.
• 웹 브라우저의 성능 향상 메커니즘으로 도입되었으며 다른 엔진보다 훨씬 향상된 인터프리터가 되었음.

⇒ V8과 다른 엔진의 가장 큰 차이점은 V8 엔진의 JIT(Just In Time) 컴파일러임.

     - JIT 컴파일러는 런타임에 모든 자바스크립트를 기계어 코드도 컴파일하고 중간 코드를 생성하지 않음.

V8 엔진의 동작 과정

1. 소스코드 파싱
2. 자바스크립트 소스코드를 가져와서 먼저 파서(Parser)에 넘기면, 소스코드를 분석한 후 AST(Abstract Syctax Tree,추상 구문 트리) 로 변환합니다.
3. Ignition 바이트코드(ByteCode)로 변환
4. Ignition은 자바스크립트 코드를 바이트코드로 변환하는 인터프리터이다. 원본 소스 코드보다 컴퓨터가 해석하기 쉬운 바이트 코드로 변환하여, 수시로 코드를 파싱하는 작업을 최소화하고 코드의 양도 줄임으로써 메모리 공간도 효율적으로 관리할 수 있게 된다.

• 인터프리터(Interpreter)란?
• 컴파일러와 반대로 인터프리터는 프로그램 실행시 한 번에 한문장씩 번역한다. 그렇기 때문에 한번에 전체를 스캔하고 실행파일을 만들어서 실행하는 컴파일러보다 실행시간이 더 걸린다. 인터프리터는 메모리 효율이 좋다. 대표적인 언어로 Python,Ruby,Javascript 등이 있음.
• 컴파일러란(Compiler)?
• 프로그램 전체를 스캔하여 이를 모두 기계어로 번역한다. 전체를 스캔하기 때문에 대개 컴파일러는 초기 스캔 시간이 오래 걸린다. 하지만 전체 실행 시간만 따지고 보면 인터프리터보다 빠르다. 대표적인 언어로 C,C++,JAVA 등이 있음.

• 자바스크립트는 정적 타이핑 언어가 아닌 동적 타이핑 언어입니다. 소스코드가 실행되기 전에는 알 수 없는 값들이 너무 많아 최적화가 힘들다는 단점이 있습니다. 때문에 모든 소스를 한 번에 해석하는 컴파일 방식이 아닌 코드 한 줄씩 실행될 때마다 해석하는 인터프리트 방식을 채택하여 세 가지 이점을 가져가고자 하였습니다.

• 메모리 사용량 감소 : 자바스크립트 코드에서 기계어로 컴파일하는 것보다 바이트 코드로 컴파일 하는 것이 더 편하다.
• 파싱 시 오버헤드 감소 : 바이트 코드는 간결하기 때문에 다시 파싱 하기 편하다.
• 컴파일 파이프라인의 복잡성 감소 : TurboFan을 통한 Optimizing 혹은 Deoptimizing 처리시에도 바이트코드가 편하다.

1. TurboFan으로 자주 사용하는 바이트코드를 컴파일

• TurboFan이란?
  • TurboFan은 V8 v5.9 버전 이전에 사용되었던 Crankshaft 컴파일러를 완전히 대체한 최적화 담당 컴파일러임.
  • TurboFan은 바이트 코드로 수시로 변환하는 과정을 최소화하기 위해 사용됨.
  • V8 런타임 중에 Profiler에게 함수나 변수들의 호출 빈도와 같은 데이터를 모으라고 시키며 이 데이터를 이용하여 TurboFan이 자기 기준에 맞는 코드를 가져와서 최적화를 시킴.

TurboFan 최적화 기법

• Hidden Class
  • 자바스크립트는 기본적으로 클래스가 없고 대신 Prototype이라는 개념이 있다. 자바스크립트 내에서 사용되는 Number,Boolean 등과 같은 정적 타입 데이터 외 모든 데이터를 객체로 취급됨.
  • 자바스크립트 엔진 내부의 Hidden Class라는 개념을 이용하여 각 객체에 대한 속성 값의 포인터만 가지고, 해당되는 구조를 참조함.
• Inline Caching

Javascript 엔진 구조도

V8 엔진의 구조도를 간단히 나타낸 그림

엔진의 주요 두 구성요소는

• Memory Heap : 메모리 할당이 일어나는 곳
• Call Stack : 코드 실행에 따라 호출 스택이 쌓이는 곳

참고 자료: 참고 자료:

컴파일러(compiler)와 인터프리터(interpreter)의 차이

[2020.10.16] Google Chrome V8 엔진을 파헤쳐보자

자바스크립트의 동작원리: 엔진, 런타임, 호출 스택

이벤트 디멀티플렉싱은 무엇인가?

이 매커니즘은 감시된 일련의 리소스들로부터 들어오는 I/O 이벤트를 수집하여 큐에 넣고 처리할 수 있는 새 이벤트가 있을 때까지 차단함.

socketA,pipeB
wahchedList.add(socketA, FOR_READ); // [1]
while(events = demultiplexer.watch(watchedList)){ //[2]
	foreach(event in events){
		//read는 블록되지 않으며 비어있을지언정, 항상 데이터를 반환함.
		data = event.resource.read();
		if(data === RESOURCE_CLOSED) demultiplexer.unwatch(event.resource);
		else resolve(data);
	}
}

[2]에서 디멀티플렉서에 감시할 것들을 추가. 이 호출은 동기식이며, 감시 대상 중 하나라도 데이터를 리턴하기 전까지 차단됨. 이때 이벤트 디멀티플렉서는 호출로부터 복귀하여 새로운 이벤트들을 처리할 수 있게됨(비동기)

[3]에서 디멀티플렉서가 반환한 이벤트가 처리됨. 여기를 Event Loop라고 부르며, 이곳에 도달했다는 것은 역으로 읽기 작업이 완료되었다는 것이므로 차단되지 않은 상황이라고 보증됨.

구체적으로, 바로 값을 가져올 수 없는 작업형 함수를 만날 경우(I/O) 일단 약속된 상수 값을 리턴시키고 해당 함수를 디멀티플렉서에 추가함. 이때 완료 후 호출될 핸들러(callback)와 이벤트가 디멀티플렉서에 들어감. 이벤트가 완료될 경우 디멀티플렉서가 이벤트를 반환함. 반환된 이벤트는 큐에 push되고, 이벤트 루프는 이벤트 큐를 순회하며 각각의 이벤트들에 대한 핸들러를 실행합니다.

이벤트 디멀티플렉싱 패턴을 사용하면 Busy-waiting을 사용하지 않고도 단일 스레드 내에서 여러 I/O 작업을 처리할 수 있습니다. 기존의 동기식 블로킹 I/O가 스레드를 만들어 다중 I/O 작업을 처리했다면 이는 하나의 스레드만 사용하여 시간에 따라 작업을 분리해 처리합니다. 따라서 위의 그림처럼 유휴시간(파란색)을 최소로 줄일 수 있습니다. 또한 프로세스 간의 경쟁 혹은 여러 스레드들의 동기화 걱정이 없는 훨씬 간단한 동시성 전략을 사용할 수 있습니다.

반응자 패턴 (Reactor Pattern)

리엑터 패턴의 핵심은 각 I/O 작업과 관련된 핸들러(callback)를 갖는 것입니다. 이 핸들러는 이벤트 루프에 의해 처리되는 즉시 호출됩니다. 리엑터 패턴은 위에서 설명한 이벤트 디멀티플렉싱을 활용하는 패턴입니다.

1. 애플리케이션이 요청을 이벤트 디멀티플렉서에 제출하여, 새로운 IO 작업을 생성한다. 애플리케이션은 또한 작업이 완료되면 호출할 핸들러(콜백)를 지정한다. 새로운 요청을 이벤트 디멀티플렉서에 제출하는 것은 논블로킹 요청으로, 즉시 애플리케이션에 통제권을 반환한다.
2. IO 작업 세트가 완료되면, 이벤트 디멀티플렉서가 해당 이벤트 세트를 이벤트 큐로 푸시 한다.
3. 이 때, 이벤트 루프는 이벤트 큐 항목에서 반복된다.
4. 각 이벤트에 연결된 핸들러가 호출된다.
5. a. 애플리케이션 코드의 일부인 핸들러(콜백) 실행이 완료되면, 이벤트 루프를 다시 제어한다. 5b. 콜백이 실행되는 동안, 새로운 비동기 작업을 요청할 수 있으며, 이는 이벤트 디멀티플렉서에 새로운 항목 추가를 야기한다.
6. 이벤트 큐의 모든항목이 처리되면, 이벤트 루프는 이벤트 디멀티플렉서를 다시 차단하며, 이 경우 새로운 이벤트가 가능해질 때 다시 트리거한다.

즉, 리엑터 패턴은 관찰 대상 리소스가 반응(콜백)하면 해당 이벤트의 핸들러를 추적해 실행하는 디자인 패턴입니다. 노드의 전신이라 할 수 있는 패턴입니다.

Node.js는 Reactor 패턴을 사용하며 JS Core API, V8 및 libuv에 의존하는 구조라고 할 수 있습니다.

• Binding: libuv 외 로우레벨 기능들을 JS에 랩핑하고 사용 가능하게 만들어 줌.
• V8: 구글에서 만든 크롬용 JS 엔진. V8 덕에 Node.js 가 매우 빠르고 효율적으로 작동한다.
• JS Core API: Node.js API 를 구현하는 자바스크립트 코어

참고 사이트 : Plus Ultra

Node.js란?

• 오픈 소스 Javascript 엔진인 Chrome V8에 비동기 이벤트 처리 라이브러리인 libuv를 결합해 만든 플랫폼임.

• 즉, Javascript 로 브라우저 밖에서 서버를 구축하는 등의 코드를 실행할 수 있게 해주는 런타임 환경임.

• Node.js는 단일 프로세서에서 작동하기 때문에 멀티코어를 완전히 사용하려면 코어갯수만큼의 프로세스를 띄우고 라우터나 로드 밸런서 등으로 요청을 각 프로세스로 분산시켜주어야함.

• Node 의 핵심 철학은 비동기로 동작하여 I/O 작업일 경우 워커스레드에 던져두고 이벤트 루프는 다른일을 한다는 것이며 이때 I/O작업 처리는 libuv가 담당함.

• 그러면, Node.js 싱글 스레드일까요?

  보통 Javascript는 싱글 스레드라고 합니다. 그럼 자바스크립트가 실행되는 환경인 노드는 싱글일까?

  ⇒ 정확하게 말하면 노드는 싱글스레드가 아닙니다.

  “자바스크립트를 실행하는 스레드는 단 하나이므로…”

• 그러면, libuv는 뭔가요?

  libuv란 C/C++로 작성된, Node.js가 사용하는 비동기 I/O 라이브러리입니다.

  이는 사실 운영체제의 커널을 추상화한 Wrapping된 라이브러리로 커널이 어떤 비동기 API로 지원하는지 알고 있다고합니다.

  • 그러면, 어떻게 처리를하나요?

    우리가 libuv에게 파일 읽기와 같은 비동기 작업을 요청하면 libuv는 이 작업을 커널이 지원하는지 확인합니다. 만약 지원한다면 libuv가 커널에게 비동기적으로 요청했다가 응답이 오면 그 응답을 우리에게 전달해줌. 만약 요청한 작업을 커널이 지원하지 않는다면 자신만의 워커스레드가 담긴 스레드 풀을 사용함.

    libuv는 기본적으로 4개의 스레드를 가진 스레드 풀을 생성함.

    결국에는, 이벤트 루프가 싱글 스레드이며, 블로킹 I/O 관련된 작업을 처리하는 백그라운드는 멀티스레드로 이루어져있다. I/O관련 블로킹 작업은 OS또는 libuv의 thread pool에서 처리하여 이벤트 루프가 blocking되지 않게 함.

    여기서 그러면, libuv와 Event loop와의 관계가 뭐길래, 어떻게 싱글 스레드로 논블로킹 비동기 작업을 지원하는가에 대해 궁금증이 생깁니다.

    간단하게 정리하자면, Node.js는 I/O작업을 자신의 메인 스레드가 아닌 다른 스레드에 위임함으로써 싱글 스레드로 논 블로킹 I/O를 지원함. 다시 말해, Node.js는 I/O작업을 libuv에 위임함으로써 논 블로킹 I/O를 지원하고 그 기반에는 이벤트 루프가 있음.

• 그러면, 싱글 스레드라면서 비동기 작업은 어떻게 가능할까요?

  스레드가 하나라면 동시에 하나의 작업만 처리할 수 있습니다. 어떻게 비동기 처리가 가능할까요?

  비동기란 먼저 실행된 코드의 작업이 끝나기 전에 더 나중에 실행된 코드의 작업이 끝날 수 있음을 의미합니다. 즉, 동시성을 가지고 있는 코드들이죠.

  스레드가 하나임에도 동시성이 지원되는 이유는 바로 “이벤트 루프” 라는 친구 때문입니다.

  그렇다면 이벤트 루프는 무엇일까요?

  • 이벤트 루프

    • 이벤트 루프는 Node.js가 여러 비동기 작업을 관리하기 위한 구현체입니다.

    • 이벤트 루프는 싱글 스레드이며 메인 쓰레드이며 비즈니스 로직을 수행합니다.

      console.log(’…’) 와 같은 동기 작업이 아니라 file.readFile(’test.txt’,callback)과 같은 비동기 작업들을 모아서 관리하고 순서대로 실행할 수 있게 해주는 도구임.

      Timer Phase, Pending Callbacks Phase, Idel,Prepare Phase, Poll Phase, Check Phase, Close Callbacks Phase로 구성되어있음.

      한 페이즈에서 다음 페이즈로 넘어가는 것을 틱(Tick)이라고 합니다.

RestAPI란?

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)

→ 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다. 주로 파일 제어, 창 제어… 등

인터페이스(Interface)는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면임. 즉, 사용자가 기기를 쉽게 동작시키느데 도움을 주는 시스템을 의미합니다.

REST(Representational State Transfer)

→ 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식임.

REST는 HTTP 기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍처라고 합니다.

구성 요소

• 자원(Resource)

  - 자원은 서버에 존재하는 데이터의 총칭이며 모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원에 대해 CRUD 명령을 수행할 수 있습니다.

• 행위(Verb)

   - 행위는 클라이언트가 HTTP Method를 이용하여 자원을 조작하는 것을 의미합니다.

• 표현(Representation)

   - 클라이언트가 HTTP Method로 자원을 조작하면 서버가 그에 대한 응답(JSON, XML)을 보내는데 그것을 의미합니다.

특징

• 서버-클라이언트 구조(Server-Client Architecture)

  - 서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을  분명하게 구분할 수 있습니다.

• 무상태성(Stateless)

  - HTTP를 이용하는만큼 Stateless의 특성을 가집니다. 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있습니다.

• 캐시 가능(Cacheable)

  - HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있습니다.

• 일관된 인터페이스(Uniform Interface)

  - HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있으며 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리됩니다.

• 자체적인 표현 구조(Self-Descriptiveness)

  - JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 지관적으로 이해할 수 있습니다.

• 계층 구조(Layered System)

  - 클라이언트는 대상 서버와 직접 통신하는지 아니면 중간 서버와 통신하는지 알 수 없습니다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있습니다.

장점

• 별도의 인프라 구축이 필요 없음

  - HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없습니다.

• 클라이언트와 서버의 분리

  - 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리됩니다.

• 플랫폼에 독립적

  - HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능합니다.

• 쉬운 사용

  - 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽습니다.

단점

• 표준이 존재하지 않음

  - 명확한 표준이 존재하지 않습니다. 따라서 REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 탄생할 수 있으며 관리가 어렵습니다.

• HTTP Method의 한계

  - HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원합니다.

• RDBMS와 맞지 않음

  - REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않은 형태입니다. 그래서 NoSQL이 더 선호되는 추세입니다.

회사다닐 때, 정리해두었던 자료를 늦게나마 블로그에 적어보려고합니다.

먼저, spread 문법과 map을 사용한 데이터 할당

// 1번
const newList = [...rawMemeberTypeList]; 

// 2번
const newList = rawMemberTypeList.map((item) => {...item});

Q. 1번은 어떻게 복사가 될까요?

A. 얕은 복사로서, "newList"는 "rawMember..." 와 같은 배열 요소를 참조합니다.
기존의 배열 "rawMember" 과 새로운 "newList" 중 하나를 수정하면 다른 배열에도 영향을 미친답니다.

Q. 2번은 어떻게 복사가 될까요?

A. 깊은 복사로서, map 함수를 통해 "rawMemberTypeList" 의 각 요소를 복사하여 새로운 배열 "newList" 를 생성합니다.
이렇게 하면 "newList"와 "rawMemberTypeList" 의 복제본이므로 두 배열은 독립적으로 존재합니다.
기존 "rawMember..." 나 "newList" 중 하나를 수정해도 다른 배열에 영향을 미치지 않습니다.

인증과 인가

Q. 인증(Authentication)과 인가(Authorization)란 무엇인가요?

A. 인증(Authentication)은 사용자가 본인이 주장하는 대로 자신임을 인증하는 과정입니다. 일반적으로 아이디와 비밀번호를 입력하여 로그인하는 것이 인증의 예입니다. 반면, 인가(Authorization)는 인증된 사용자가 특정 자원이나 기능을 사용할 수 있는 권한이 있는지 확인하는 과정입니다. 예를 들어, 일반 사용자가 관리자 페이지에 접근하는 것은 인가되지 않은 것입니다. 인가는 일반적으로 역할(Role)과 권한(Permission)을 기반으로 수행됩니다. 역할은 사용자 그룹을 의미하며, 권한은 해당 역할에 대해 부여된 권한을 의미합니다. 즉, 역할을 기반으로 권한을 관리하여 인가를 수행합니다.

Q. 왜 인증 방식이 필요한 가요?

A. HTTP의 비연결성과 비상태성이라는 특성 때문에 인증 방식이 필요합니다.

Session이란?

• Session은 사용자의 상태를 관리하는 기술로, 같은 사용자로부터 일련의 요청을 하나의 상태로 유지시키는 것입니다. 연결은 방문자가 웹 브라우저를 종료함으로써 끝납니다.
• HTTP의 비연결성과 비상태성으로 인해 인증 방식이 필요합니다. 인증은 사용자가 본인이 주장하는 대로 자신임을 인증하는 과정이고, 인가는 인증된 사용자가 특정 자원이나 기능을 사용할 수 있는 권한이 있는지 확인하는 과정입니다.
• 세션과 쿠키는 인증 문제를 해결하기 위해 사용됩니다. 세션은 서버에서 사용자의 상태를 관리하고, 쿠키는 클라이언트에서 사용자의 상태를 관리합니다. 세션은 보안성이 높지만, 서버 자원을 많이 사용합니다. 쿠키는 보안성이 낮을 수 있지만, 서버 자원을 적게 사용합니다.

Cookie란?

• 쿠키(Cookie)는 클라이언트 측에서 사용자의 상태를 관리하는 기술로, 브라우저에 저장됩니다. 서버에서 응답(Response)을 보낼 때, Set-Cookie 헤더를 사용하여 클라이언트에게 쿠키를 전송할 수 있습니다. 그러면, 클라이언트는 이후 요청(Request)에서 해당 쿠키를 서버에게 전송하여 사용자의 상태를 유지시킬 수 있습니다.

JWT란?

• JWT(Json Web Token)는 웹 표준으로 지정된 JSON 기반의 토큰입니다. JWT는 클라이언트와 서버 간의 정보를 안전하게 전송할 수 있도록 해줍니다. JWT는 페이로드(Payload)와 시그니처(Signature)로 구성되어 있으며, 페이로드는 정보를 담고 있고, 시그니처는 해당 정보가 유효한지 확인하는 데 사용됩니다. JWT는 세션과 쿠키와 같은 인증 방식을 대체하여 사용될 수 있습니다.
• 왜 JWT를 사용하는가?이 방법은 HTTP 프로토콜을 사용하여 통신을 합니다.
  1. Conncetionless ⇒ 연결을 유지하지 않는다.
  2. Stateless ⇒ 상태를 유지하지 않는다.
  3. : 서버와 클라이언트는 첫번째 통신을 하고 나서 두번째 통신을 할 때는 이전의 통신에 대한 정보를 가지고 있지 않음. → 즉, 새롭게 갱신을 해줘야함.그렇다면 로그인은 어떻게 처리를 해줘야 할까요?
  4. 로그인 처리 방법
  5. : 서버와 클라이언트가 한번 통신이 일어나고 나면 그 연결이 유지가 되는 것이 아니라 바로 끊어짐.
  6. DB에 USER ID와 PASSWORD 비교하여 로그인하기
     • 이 방법은 로그인 유지가 안될 뿐더러 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 해주거나 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 일이 발생 할 수 있음.
     • Sessiong(세션) 과 Token(토큰)세션 방식 → 서버의 메모리, 데이터베이스와 같은 서버의 자원들을 사용해서 사용자의 정보를 유지시키는 방식임.토큰 방식서버에 저장하지 않아서 서버에 확장성이 있음.
  7. 위에서 말한것처럼 로그인을 했을 때 해당 서버에만 요청을 보내는 것이 아닌 요청이 들어왔을 때 해당 토큰이 유효한지만 체크하면 됨.
  8. 토큰 방식은 사용자가 로그인을 하면 서버에서 발행해주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법임. 여기서 말하는 토큰이 우리가 말하고자하는 JWT임.
  9. 토큰보다 보안에 강하다는 장점이 있지만 단점으로 서버의 확장성이 떨어지고, 서버의 자원(세션을 저장, 유지할 공간) 이 많이 필요함. 또한 세션이 서버에 저장이 되고, 트래픽 분산을 위해 여러대의 서버를 사용할 때, 만약 사용자가 로그인을 했을 때는 만들어진 세션을 참조해야 하기 때문에 처음 로그인한 그 서버에서만 요청을 보내야한다는 단점이 있음.
• HTTP 프토토콜은 두 가지 특성이 있습니다.
• “로그인” 이라는 과정은 “서버와 클라이언트가 데이터를 주고 받는 통신 방법”이 필요합니다.
• JWT란?
  • 구성
    • Header
    • JWT를 검증하는데 필요한 정보를 가진 JSON을 BASE64 알고리즘 기반으로 인코딩한 문자열이며 검증을 하기 위한 내용을 가지고 있음.
    • Payload
      • Payload는 암호화되지 않기때문에 비밀번호와 같은 민감한 값을 넣으면 안됨.
    • JWT에 저장된 값이며, (name,value)의 쌍으로 이루어져 있고, JWT에는 이 값들을 여러개 할당할 수 있음.
    • Signature
    • JWT를 인코딩하거나 유효성 검증을 할 때 사용하는 암호화된 코드임.
  • Header - Payload - Signature
• JWT는 Client 와 Server 사이 통신 시 권한을 인가하기 위해 사용하는 토큰임.

RefeshToken과 AccessToken 의 관리는 고려...