## 문제 해결 접근 방법
### 링크
- <a href="https://www.acmicpc.net/problem/2178" target="_blank">백준-미로탐색 2178</a>

미로 탈출
### 문제 이해
- 이 문제 N x M 크기의 미로에서 (1,1)에서 출발하여 (N,M)의 위치로 이동할 때 지나야 하는 최소 칸수를 구하는 문제이다.
- 미로에서 1은 이동할 수 있는 칸을 나타내고, 0은 이동할 수 없는 칸을 나타낸다.
- 이동은 상하좌우로만 가능하다.

### 문제 해결 방식
- 그래프 탐색 알고리즘 중 너비 우선 탐색(BFS, Breadth-First Search)을 사용하여 해결할 수 있다.
- BFS는 시작 지점에서 가까운 노드부터 차례대로 탐색하기 때문에, 최단 경로를 찾는데 적합하다.

### 의사코드
1. 입력을 받아 미로를 2차원 배열로 저장
2. BFS를 위한 큐 생성
3. 시작점 (0,0)을 큐에 넣고 방문 표시
4. 큐가 빌 때까지 다음을 반복:
	- 큐에서 현재 위치를 꺼냄
	- 현재 위치가 도착점이면 이동 횟수 반환
	- 상하좌우 네 방향에 대해:
		- 새 위치가 미로 범위 내이고, 이동 가능하며, 방문하지 않았다면:
			- 새 위치를 큐에 넣고 방문 표시
			- 새 위치의 이동 횟수를 현재 위치 + 1로 설정

---
## Node.js 구현 예시

```javascript
const BAEKJOONFILE = "/dev/stdin";
const VSCODEFILE = "./coding/example.txt";

const fs = require('fs');
const input = fs.readFileSync(VSCODEFILE).toString().trim().split('\n');

const [N, M] = input[0].split(' ').map(Number);
const maze = input.slice(1).map(line => line.split('').map(Number));

function bfs() {
	const queue = [[0, 0, 1]];
	const visited = Array.from({length: N}, () => new Array(M).fill(false));
	visited[0][0] = true;

	const dx = [-1, 1, 0, 0];
	const dy = [0, 0, -1, 1];

	while (queue.length > 0) {
		const [x, y, count] = queue.shift();
		
		if (x === N - 1 && y === M - 1) {
			return count;
		}

		for (let i = 0; i < 4; i++) {
			const nx = x + dx[i];
			const ny = y + dy[i];

			if (nx >= 0 && nx < N && ny >= 0 && ny < M && maze[nx][ny] === 1 && !visited[nx][ny]) {
				queue.push([nx, ny, count + 1]);
				visited[nx][ny] = true;
			}
		}
	}
}

console.log(bfs());
```

---
## 부분 설명

### 입력 처리
```javascript
const [N, M] = input[0].split(' ').map(Number); 
const maze = input.slice(1).map(line => line.split('').map(Number));
```

- 첫 줄에서 미로의 크기 N과 M을 받고, 나머지 줄에서 미로의 구조를 2차원 배열로 변환한다.

### BFS 함수
```javascript
function bfs() { 
	const queue = [[0, 0, 1]]; 
	const visited = Array.from({length: N}, () => new Array(M).fill(false)); 
	visited[0][0] = true;
```

- BFS 함수를 정의하고, 시작점 (0,0)과 이동 횟수 1을 큐에 넣는다. 방문 배열을 생성하고 시작점을 방문 처리한다.

### 방향 배열
```javascript
const dx = [-1, 1, 0, 0]; 
const dy = [0, 0, -1, 1];
```

- 상하좌우 이동을 위한 방향 배열을 정의한다.

### BFS 루프
```javascript
while (queue.length > 0) { 
	const [x, y, count] = queue.shift(); 
	if (x === N - 1 && y === M - 1) { 
		return count; 
	}
```

- 큐가 빌 때까지 반복하며, 현재 위치가 도착점이면 이동 횟수를 반환한다.

### 주변 탐색
```javascript
for (let i = 0; i < 4; i++) { 
	const nx = x + dx[i]; 
	const ny = y + dy[i]; 
	
	if (nx >= 0 && nx < N && ny >= 0 && ny < M && maze[nx][ny] === 1 && !visited[nx][ny]) { 
		queue.push([nx, ny, count + 1]); 
		visited[nx][ny] = true; 
	} 
}
```

- 현재 위치에서 상하좌우를 탐색하며, 미로 범위 내이고 이동 가능하며 방문하지 않은 칸이면 큐에 추가하고 방문 처리한다.

---
### 블로그 내 관련 문서

---
### 참고 자료
출처 :
- <a href="https://rayc20.tistory.com/264" target="_blank">Ray 수학</a>

백준 미로탐색 2178번 문제 Node.js, JavaScript 풀이

미로탐색 2178번

## 문제

### 링크

- <a href="https://www.acmicpc.net/problem/7569" target="_blank">백준-토마토7569</a>

### 이해
3차원 상자에 담긴 토마토들이 익어가는 과정을 시뮬레이션 하는 것.
1. 익은 토마토는 하루가 지나면 주위의 익지 않은 토마토를 익게 만든다.
2. 주위(인접한)의 토마토는 위, 아래, 왼쪽, 오른쪽, 앞, 뒤 여섯 방향을 의미한다.
3. 모든 토마토가 익는데 걸리는 최소 일수를 구해야 한다.


---

## 해결

### 전체 코드
```javascript
const BAEAKJOONFILE = "/dev/stdin";
const VSCODEFILE = "./coding/example.txt";

const fs = require('fs');
const input = fs.readFileSync(VSCODEFILE).toString().trim().split('\n');

const [M, N, H] = input[0].split(' ').map(Number);
const box = [];
const queue = [];
let unripeTomatoes = 0;

for (let h = 0; h < H; h++) {
	const floor = [];
	for (let n = 0; n < N; n++) {
		const row = input[1 + h * N + n].split(' ').map(Number);
		floor.push(row);
	
	for (let m = 0; m < M; m++) {
		if (row[m] === 1) queue.push([h, n, m, 0]);
		else if (row[m] === 0) unripeTomatoes++;
		}
	}
	box.push(floor);
}

const directions = [
	[0, 0, 1], [0, 0, -1], [0, 1, 0], [0, -1, 0], [1, 0, 0], [-1, 0, 0]
];

let maxDays = 0;
let queueIndex = 0;

while (queueIndex < queue.length && unripeTomatoes > 0) {
	const [h, n, m, days] = queue[queueIndex++];
	for (let i = 0; i < 6; i++) {
		const nh = h + directions[i][0];
		const nn = n + directions[i][1];
		const nm = m + directions[i][2];
		
		if (nh >= 0 && nh < H && nn >= 0 && nn < N && nm >= 0 && nm < M && box[nh][nn][nm] === 0) {
			box[nh][nn][nm] = 1;
			queue.push([nh, nn, nm, days + 1]);
			unripeTomatoes--;
			maxDays = days + 1;
		}
	}
}

console.log(unripeTomatoes === 0 ? maxDays : -1);
```

### 부분 설명
#### 입력
```javascript
const fs = require('fs');
const input = fs.readFileSync(VSCODEFILE).toString().trim().split('\n');

const [M, N, H] = input[0].split(' ').map(Number);
```
- 파일에서 입력을 읽어 온다. 첫 줄에서 상자의 가로(M), 세로(N), 높이(H)를 가져온다.


#### 토마토 상태 파악하기
```javascript
const box = [];
const queue = [];
let unripeTomatoes = 0;

for (let h = 0; h < H; h++) {
	const floor = [];
	for (let n = 0; n < N; n++) {
		const row = input[1 + h * N + n].split(' ').map(Number);
		floor.push(row);
	
	for (let m = 0; m < M; m++) {
		if (row[m] === 1) queue.push([h, n, m, 0]);
		else if (row[m] === 0) unripeTomatoes++;
		}
	}
	box.push(floor);
}
```
- 문자열로 된 배열을 숫자 형태로 변환하면서 3차원 배열로 생성
- 만약 토마토가 익었다면(1이라면) 큐에 넣기, 큐의 마지막은 날짜(days)가 됨.
- 아니고 만약 토마토가 안 익었다면(0이라면) 안 익은 토마토 변수의 값을 1 증가

#### 토마토 익히기
```javascript
const directions = [
	[0, 0, 1], [0, 0, -1], [0, 1, 0], [0, -1, 0], [1, 0, 0], [-1, 0, 0]
];

let maxDays = 0;
let queueIndex = 0;

while (queueIndex < queue.length && unripeTomatoes > 0) {
	const [h, n, m, days] = queue[queueIndex++];
	for (let i = 0; i < 6; i++) {
		const nh = h + directions[i][0];
		const nn = n + directions[i][1];
		const nm = m + directions[i][2];
		
		if (nh >= 0 && nh < H && nn >= 0 && nn < N && nm >= 0 && nm < M && box[nh][nn][nm] === 0) {
			box[nh][nn][nm] = 1;
			queue.push([nh, nn, nm, days + 1]);
			unripeTomatoes--;
			maxDays = days + 1;
		}
	}
}
```

BFS(너비 우선 탐색)를 사용해 토마토가 익어가는 과정을 시뮬레이션
- 큐에서 익은 토마토를 하나씩 꺼내서 주변 6방향 확인
- 안 익은 토마토를 발견하면 익힌 후 큐에 넣기
- 위 과정 반복하며 최대 일수 갱신


### 특이사항
#### 시간 초과
현재 코드말고 이전 코드로 했을 때 시간 초과가 났었다.

#### 토마토의 익힘 정도
[토마토상태파악하기](#토마토-상태-파악하기) 부분의 코드를 전에는 3차원 배열을 만드는 로직과 토마토의 익힘 정도 찾는 로직을 따로 for문을 사용해 처리 했다. 아마 시간초과에 유의미한 차이가 있을 것 같아 한 번에 배열과 토마토의 익힘 정도를 구분하는 로직을 모두 처리하기로 한다. 이를 통해 불필요한 반복은 줄이고 실행 시간은 단축시킨다.

#### 큐 구현
```javascript
const [h, n, m, days] = queue[queueIndex++]; // 이 부분을
const [h, n, m, days] = queue.shift(); // 이렇게 했었다.
```

이전의 코드와 비교하면 다음과 같이 차이가 난다고 한다.
- `shift` 연산의 시간 복잡도는 O(n)
- `인덱스`를 사용하여 큐를 구현하면 O(1)
이라고 한다.

##### Shift와 인덱스의 시간 차이
1. shift 연산(Array.prototype.shift):
	- shift 연산은 배열의 첫 번째 요소를 제거하고 반환한다.
	- 이 연산은 O(n) 시간 복잡도를 가진다, 이유는:
		- 첫 번째 요소를 제거한 후 나머지 모든 요소를 한 칸씩 앞으로 이동시키기 때문이다.
	- 따라서 배열의 크기가 클수록 이 연산은 더 많은 시간이 걸리게 된다.
2. 인덱스를 사용한 큐 구현:
	- 배열을 그대로 두고 인덱스만 이동시킨다.
	- 큐에서 요소를 꺼낼 때마다 인덱스를 1 증가시키기만 하면 된다.
	- 이 연산은 O(1) 시간 복잡도를 가진다. 단순히 인덱스 값만 변경하기 때문이다.

결론적으로, 맨 앞의 값을 꺼내오는 것은 동일하지만, 그 과정에서 발생하는 내부 연산의 복잡도 차이로 인해 성능 차이가 발생한다. 따라서 큐를 구현할 때는 가능한 인덱스 기반의 접근 방식을 사용하는 것이 효율적이라 한다.

---
### 블로그 내 관련 문서
- 

---
### 참고 자료
출처 :
- AI가 그렇다고 함

백준 7569번 토마토 문제 Node.js, JavaScript 풀이

토마토 백준 7569번

## 문제 해결 접근 방법

### 링크
- <a href="https://www.acmicpc.net/problem/10026" target="_blank">백준-적록색약 10026</a>

이 문제는 일반적인 사람과 적록색약인 사람이 그림을 보는 방식의 차이를 고려하여 두 가지 경우의 영역의 수를 구하는 문제이다.
### 문제 이해
- 그림은 N x N 크기의 격자로 주어지며, 각 칸은 'R', 'G', 'B' 중 하나의 색으로 채워져 있다.
- 일반적인 사람은 세 가지 색을 모두 구분할 수 있지만, 적록색약인 사람은 'R'과 'G'를 같은 색으로 인식한다.
- 두 가지 경우에 대해 각각의 연결된 같은 색 영역의 수를 구해야 한다.

### 그래프 탐색
- DFS(깊이 우선 탐색) 또는 BFS(너비 우선 탐색)를 사용하여 연결된 영역을 찾는다.
- 두 번의 탐색이 필요하다. 하나는 일반적인 경우, 다른 하나는 적록색약인 경우이다.

### 구현 단계
- 입력을 받아 N x N 배열로 저장한다.
- 두 개의 방문 배열을 사용하여 각각의 경우에 대해 방문 여부를 기록한다.
- DFS 또는 BFS를 통해 각 칸에서 시작하여 연결된 같은 색 영역을 탐색하고 카운트한다.

---
## Node.js 구현 예시

아래는 Node.js로 구현한 예시 코드이다. 이 코드는 DFS를 사용하여 문제를 해결한다.
```javascript
const BAEAKJOONFILE = "/dev/stdin";
const VSCODEFILE = "./coding/example.txt";

const fs = require('fs');
const input = fs.readFileSync(VSCODEFILE).toString().trim().split('\n');

const N = parseInt(input[0]);
const picture = input.slice(1).map(line => line.split(''));

const directions = [
	[0, 1], [1, 0], [0, -1], [-1, 0]
];

function isValid(x, y) {
	return x >= 0 && x < N && y >= 0 && y < N;
}

function dfs(x, y, color, visited, isColorBlind) {
	const stack = [[x, y]];
	visited[x][y] = true;

	while (stack.length > 0) {
		const [cx, cy] = stack.pop();
		
		for (const [dx, dy] of directions) {
			const nx = cx + dx;
			const ny = cy + dy;

			if (isValid(nx, ny) && !visited[nx][ny]) {
				if (isColorBlind) {
					if ((color === 'R' || color === 'G') && (picture[nx][ny] === 'R' || picture[nx][ny] === 'G')) {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					} else if (color === 'B' && picture[nx][ny] === 'B') {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					}
				} else {
					if (picture[nx][ny] === color) {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					}
				}
			}
		}
	}
}

function countRegions(isColorBlind) {
	const visited = Array.from({ length: N }, () => Array(N).fill(false));
	let regionsCount = 0;

	for (let i = 0; i < N; i++) {
		for (let j = 0; j < N; j++) {
			if (!visited[i][j]) {
				dfs(i, j, picture[i][j], visited, isColorBlind);
				regionsCount++;
			}
		}
	}
	return regionsCount;
}

const normalCount = countRegions(false);
const colorBlindCount = countRegions(true);

console.log(normalCount + " " + colorBlindCount);
```

이 코드는 입력을 받아 그림을 저장한 후 두 번의 DFS 탐색을 통해 일반적인 경우와 적록색약인 경우 각각의 영역 수를 계산한다. `countRegions` 함수는 `isColorBlind` 플래그에 따라 탐색 방식을 다르게 하여 두 가지 경우를 처리한다.

---
## 부분 설명

### 입력 처리
```javascript
const fs = require('fs');
const input = fs.readFileSync(VSCODEFILE).toString().trim().split('\n');

const N = parseInt(input[0]);
const picture = input.slice(1).map(line => line.split(''));
```

이 부분은 입력을 받아 처리한다.
- `fs` 모듈을 사용하여 표준 입력(`/dev/stdin`)에서 데이터를 읽어온다.
- 첫 번째 줄에서 N(그림의 크기)을 가져온다.
- 나머지 줄들을 2차원 배열 `picture`로 변환한다.

### 방향 설정 및 유효성 검사 함수
```javascript
const directions = [
	[0, 1], [1, 0], [0, -1], [-1, 0]
];

function isValid(x, y) {
	return x >= 0 && x < N && y >= 0 && y < N;
}
```

- `directions`는 상하좌우 이동을 위한 배열이다.
- `isValid` 함수는 주어진 좌표가 그림 내(정해진 범위 내)에 있는지 확인한다.

### DFS 함수
```javascript
function dfs(x, y, color, visited, isColorBlind) {
	const stack = [[x, y]];
	visited[x][y] = true;

	while (stack.length > 0) {
		const [cx, cy] = stack.pop();
		
		for (const [dx, dy] of directions) {
			const nx = cx + dx;
			const ny = cy + dy;

			if (isValid(nx, ny) && !visited[nx][ny]) {
				if (isColorBlind) {
					if ((color === 'R' || color === 'G') && (picture[nx][ny] === 'R' || picture[nx][ny] === 'G')) {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					} else if (color === 'B' && picture[nx][ny] === 'B') {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					}
				} else {
					if (picture[nx][ny] === color) {
						visited[nx][ny] = true;
						stack.push([nx, ny]);
					}
				}
			}
		}
	}
}
```

이 함수는 깊이 우선 탐색(DFS)을 구현한다.
- 스택을 사용하여 반복적 DFS를 구현한다.
- `isColorBlind` 매개변수에 따라 색 구분 로직이 달라진다.
- 적록색약인 경우, 'R'과 'G'를 같은 색으로 처리한다.

### 영역 카운팅 함수
```javascript
function countRegions(isColorBlind) {
	const visited = Array.from({ length: N }, () => Array(N).fill(false));
	let regionsCount = 0;

	for (let i = 0; i < N; i++) {
		for (let j = 0; j < N; j++) {
			if (!visited[i][j]) {
				dfs(i, j, picture[i][j], visited, isColorBlind);
				regionsCount++;
			}
		}
	}
	return regionsCount;
}
```

이 함수는 전체 그림을 순회하며 영역의 수를 세는 역할을 한다.
- 방문하지 않은 칸을 발견하면 DFS를 시작하고 영역 수를 증가시킨다.
- `isColorBlind` 매개변수로 일반인과 적록색약인 경우를 구분한다.

### 결과 출력
```javascript
const normalCount = countRegions(false); 
const colorBlindCount = countRegions(true); 

console.log(normalCount + " " + colorBlindCount);
```

- 일반인의 경우와 적록색약인 경우 각각에 대해 `countRegions` 함수를 호출한다.
- 두 결과를 공백으로 구분하여 출력한다.

---
## DFS 사용 이유

DFS(깊이 우선 탐색)를 사용하여 "적록색약" 문제를 해결한 이유는,

1. 메모리 효율성: DFS는 스택을 사용하므로 BFS(너비 우선 탐색)에 비해 일반적으로 메모리 사용량이 적다. 이 문제에서는 그래프의 크기가 크기 않아 큰 차이는 없지만, 대규모 그래프에서는 이점이 될 수 있다.
2. 구현의 간단함: DFS는 재귀적으로 구현하기 쉽다. 이 문제에서는 반복적 DFS를 사용했지만, 재귀적 구현도 가능하며 코드가 더 간결해질 수 있다.
3. 연결된 영역 탐색: 이 문제는 연결된 색상 영역을 찾는 것이 목적이다. DFS는 한 영역을 완전히 탐색한 후 다음 영역으로 넘어가는 특성이 있어, 이런 유형의 문제에 적합하다.
4. 최단 경로 불필요: BFS는 최단 경로를 찾는 데 유용하지만, 이 문제에서는 단순히 연결된 영역의 수만 필요하므로 시간 복잡도는 동일하다.
5. 성능 차이 미미: 이 문제에서는 BFS와 DFS의 성능 차이가 크지 않다. 모든 노드를 방문해야 하므로 시간 복잡도는 동일하다.
 
결론적으로, DFS를 선택한 것은 구현의 간단함과 문제의 특성(연결된 영역 찾기)에 잘 맞기 때문이다. 하지만 BFS로도 충분히 해결 가능한 문제이며, 실제로 큰 차이는 없다.

---
### 블로그 내 관련 문서

---
### 참고 자료
출처 :
- <a href="https://www.geeksforgeeks.org/difference-between-bfs-and-dfs/" target="_blank">geeksforgeeks</a>
- <a href="https://www.reddit.com/r/leetcode/comments/uhiitd/when_to_use_bfs_vs_dfs_in_graphs/" target="_blank">reddit</a>
- <a href="https://www.geeksforgeeks.org/when-to-use-dfs-or-bfs-to-solve-a-graph-problem/" target="_blank">geeksforgeeks2</a>
- <a href="https://www.wscubetech.com/resources/dsa/dfs-vs-bfs" target="_blank">wscubetech</a>

백준 적록색약 10026번 문제 Node.js, JavaScript 풀이

백준 적록색약 10026번

## 3차원 배열

3차원 배열은 세 개의 차원을 가진 데이터 구조이다. 이해하기 쉽게 실생활의 예를 들어본다.

### 아파트 구조로 생각하기
- 1차원 배열: 한 층의 각 호실
- 2차원 배열: 여러 층의 호실들
- 3차원 배열: 여러 동의 여러 층 호실들

```javascript
let apartment = [ 
	// 1동 
	[ 
		[101, 102, 103], // 1층 
		[201, 202, 203], // 2층 
		[301, 302, 303] // 3층 
	], 
	// 2동 
	[ 
		[101, 102, 103], 
		[201, 202, 203], 
		[301, 302, 303] 
	] 
]; 


// 2동 3층 2호실에 접근하려면: 
console.log(apartment[1][2][1]); // 302 출력
```

이 구조에서:
- 첫 번째 인덱스: 동
- 두 번째 인덱스: 층
- 세 번째 인덱스: 호실
을 나타낸다.

---
## BFS(너비 우선 탐색) 알고리즘

BFS는 그래프나 트리 구조에서 데이터를 탐색하는 방법 중 하나이다.

### 쉬운 예: 소문 퍼뜨리기
1. 당신이 소문을 알게 됐습니다.
2. 먼저 당신의 친한 친구들에게 소문을 전합니다.
3. 그 다음, 친구의 친구들에게 소문이 전해집니다.
4. 이런 식으로 점점 더 멀리 소문이 퍼져 나간다.

### BFS의 특징:
1. 시작 지점에서 가까운 노드부터 차례대로 탐색한다.
2. 큐(Queue)를 사용하여 구현한다.
3. 최단 경로를 찾는 데 유용하다.


### 알고리즘 단계:
1. 시작 노드를 큐에 넣는다.
2. 쿠에서 노드를 꺼내고, 방문했다고 표시한다.
3. 꺼낸 노드의 인접 노드 중 방문하지 않은 노드를 모두 큐에 넣는다.
4. 큐가 빌 때까지 2-3 단계를 반복한다.

---

### 블로그 내 관련 문서
- 

---
### 참고 자료
출처 :
- AI 선생님

알고리즘 문제와 코딩을 하는데 기초가 되는 것들을 메모한다.

알고리즘 풀이 도움

## Base64란 무엇인가?

Base64는 이진 데이터를 텍스트로 인코딩하는 방식이다. 컴퓨터의 세계에서 이진 데이터(0과 1로 이루어진 데이터)를 사람이 읽을 수 있는 텍스트로 변환하는 도구라고 생각하면 된다.

### 장점
1. 데이터 호환성 향상
	- 바이너리 데이터를 텍스트 기반 프로토콜에서 안전하게 전송할 수 있다.
	- 이메일 첨부 파일이나 HTML/CSS에 이미지를 임베딩할 때 유용하다.
1. 프로토콜 제한 우회
	- 일부 레거시 시스템에서 7비트 또는 6비트 데이터만 허용하는 경우, Base64를 사용하여 8비트 데이터를 전송할 수 있다.
2. HTTP 요청 감소
	- 작은 이미지를 Base64로 인코딩하여 HTML에 직접 포함시키면, 별도의 HTTP 요청이 필요 없어 페이지 로딩 시간을 줄일 수 있다.
3. 데이터 무결성
	- 인코딩 과정에서 정보 손실이 없어 원본 데이터를 그대로 보존할 수 있다.
4. 크로스 플랫폼 호환성
	- 대부분의 프로그래밍 언어에서 Base64 인코딩/디코딩 기능을 제공하여 시스템 간 호환성이 높다.

### 단점
1. 데이터 크기 증가
	- 인코딩된 데이터는 원본보다 약 33% 더 커진다. 이는 저장 공간과 대역폭 사용량을 증가 시킨다.
2. 성능 저하
	- 인코딩과 디코딩 과정에서 추가적인 CPU 리소스가 필요하다.
	- 대량의 Base64 데이터를 포함하면 페이지 로딩 시간이 늘어날 수 있다.
3. 캐싱 문제
	- Base64로 인코딩된 이미지는 HTML이나 CSS에 직접 포함되어 브라우저 캐싱의 이점을 활용할 수 없다.
4. SEO 및 사용성 저하
	- Base64로 인코딩된 이미지는 별도의 URL이 없어 검색 엔진 최적화(SEO)에 불리할 수 있다.
5. 보안 취약성
	- Base64는 인코딩 방식일 뿐 암호화가 아니므로, 민감한 정보 보호에는 적합하지 않다
6. 브라우저 호환성
	- 일부 구형 브라우저에서는 Base64 인코딩을 지원하지 않을 수 있다.
7. 디버깅 어려움
	- Base64로 인코딩된 데이터는 사람이 읽기 어려워 디버깅이 복잡해질 수 있다.


---
## 작동 원리

Base64는 64개의 안전한 문자(A-Z, a-z, 0-9, +, /)를 사용하여 모든 종류의 데이터를 표현한다. 이는 마치 우리가 26개의 알파벳으로 모든 단어를 만드는 것과 비슷하다. 

작동 과정을 간단히 설명하면 다음과 같다.
1. 데이터를 3바이트씩 나눈다.
2. 각 3바이트(24비트)를 6비트씩 4개 그룹으로 나눈다.
3. 각 6비트 그룹을 Base64 문자로 변환한다.
 
예를 들어, "Cat" 이라는 단어를 인코딩 한다고 생각해보자.
1. C = 01000011
2. a = 01100001
3. t = 01110100
이를 6비트씩 나누면: 010000 110110 000101 110100
 
이제 각 6비트를 Base64 문자로 변환하면: Q2F0 
따라서 "Cat"은 Base64로 "Q2F0"가 된다. 

다시 한번 정리하면,
1. 64개의 안전한 문자 사용: Base64 A-Z, a-z, 0-9, 그리고 '+'와 '/'를 사용한다. 총 64개의 문자로 이루어져 있어서 'Base64'라고 부른다.
2. 3바이트씩 나눈 뒤 그룹화: 3바이트(24비트)의 데이터를 6비트씩 4개 그룹으로 나눈다. 각 그룹은 0~63 사이의 값을 가지게 되고, 이 값에 해당하는 Base64 문자로 변환된다.
3. 패딩 처리: 입력 데이터의 길이가 3의 배수로 떨어지지 않는 경우 패딩 표시를 한다.

---
## 패딩?
6비트씩 4개 그룹으로 완전히 나눠지지 않는 경우에 패딩(padding)이 필요하다.

Base64 인코딩은 3바이트(24비트)의 데이터를 4개의 6(bit)비트 그룹으로 변환하는 것을 기본으로 한다. 하지만 실제 데이터의 길이가 항상 3의 배수인 바이트(byte)로 떨어지지는 않는다. 이런 경우에 패딩(=)이 필요하다.

### 패딩 처리 방법
- 2바이트만 남은 경우:
	- 16비트의 데이터가 남는다.(1바이트(byte) = 8비트(bit))
	- 이를 6비트씩 나누면 6비트, 6비트, 4비트가 된다.
	- 마지막 4비트에 2개의 0을 추가해 6비트로 만든다.
	- 결과적으로 3개의 Base64 문자가 생성되고, 마지막에 '=' 하나를 추가한다.
- 1바이트만 남은 경우:
	- 8비트의 데이터가 남는다.
	- 이를 6비트로 나누면 6비트와 2비트가 된다.
	- 마지막 2비트에 4개의 0을 추가해 6비트로 만든다.
	- 결과적으로 2개의 Base64 문자가 생성되고, 마지막에 '=' 두개를 추가한다.
### 패딩 예시
"Cat"과 "Hello" 라는 단어로 예시를 만들어 보자.
#### Cat 예시
"Cat"은 3바이트이므로 패딩이 필요없다.

```text
C a t 
67 97 116 (ASCII 값) 
01000011 01100001 01110100 (2진수) 
010000110110000101110100 (모든 비트 연결)
010000 110110 000101 110100 (6비트씩 나눔) 
Q 2 F 0 (Base64 인코딩)
```


#### Hello 예시
```text
H e l l o
72 101 108 108 111 (ASCII 값) 
01001000 01100101 01101100 01101100 01101111 (2진수)
0100100001100101011011000110110001101111 (모든 비트 연결)
010010 000110 010101 101100 011011 000110 1111 (6비트씩 나눔) 
010010 000110 010101 101100 011011 000110 111100 (마지막 그룹에 0추가해서 6비트)
SGVsbG8= (Base64 인코딩)
```

"Hello"는 5바이트(40비트)이다. Base64 인코딩은 3바이트(24비트)씩 처리하므로, 마지막에 2비트가 남는다.
- 앞의 3바이트(24비트)는 완전히 처리된다: SGVs
- 남은 2바이트(16비트)와 추가된 2비트의 0:
	- 16비트: 0110111101101111
	- 추가된 2비트: 00
	- 총 18비트: 011011110110111100
	- 이를 6비트씩 나누면: 011011 110110 111100
	- 변환 결과: bG8
마지막 6비트 그룹(111100)은 원래 데이터에 없던 2비트의 0이 추가된 것이다. 이를 표시하기 위해 패딩 문자 '='를 하나 추가한다.


#### 만약 C만 있다면(1바이트)
```text
C 
67 (ASCII 값) 
01000011 (2진수) 
010000 110000 (6비트로 나누고, 마지막에 4비트 추가) 
Q w = = (Base64 인코딩, 마지막에 '==' 추가)
```


### 패딩의 의미
패딩 문자 '='는 디코더에게 중요한 정보를 제공한다.
- '=' 하나는 원본 데이터의 마지막 그룹이 2바이트였음을 의미한다.
- '=' 두 개는 원본 데이터의 마지막 그룹이 1바이트였음을 의미한다.
이를 통해 디코더는 정확히 몇 비트가 의미 있는 데이터인지 알 수 있고, 나머지 패딩 비트는 무시할 수 있다.


### 주의사항
1. 패딩은 인코딩된 문자열의 길이가 항상 4의 배수가 되도록 보장한다.
2. 일부 Base64 구현에서는 패딩을 생략하기도 한다. 이 경우, 디코더는 문자열의 길이를 기반으로 원본 데이터의 길이를 추론해야 한다.
3. JWT(JSON Web Token)와 같은 일부 응용 프로그램에서는 URL 안전 Base64 변형을 사용하며, 여기서는 '+' 대신 '-', '/' 대신 "아래밑줄"를 사용한다.
#### URL-safe Base64의 패딩
URL-safe Base64에서 패딩을 제거할 경우, 디코딩 과정에서 원래 데이터의 길이를 정확하게 복원하는 문제는 다음과 같이 해결된다.
1. 문자열 길이를 이용한 추론: 인코딩된 문자열의 길이를 통해 원본 데이터의 길이를 추론할 수 있다. Base64로 인코딩된 데이터의 길이는 항상 4의 배수임으로, 이를 이용해 패딩의 수를 유추할 수 있다.
2. 추가 정보 제공: 일부 구현에서는 원본 데이터의 길이 정보를 별도로 전달하거나, 인코딩된 문자열에 추가 정보를 포함시킨다.
3. 컨텍스트 기반 해석: 많은 경우, 디코딩 된 데이터의 형식이나 구조가 미리 알려져 있어, 이를 바탕으로 정확한 길이를 유추할 수 있다.
4. 패딩 문자 대체: 일부 구현에서는 패딩 문자 '='를 URL에 안전한 다른 문자(예:'.')로 대체하여 사용한다.
5. 길이 정보 인코딩: 일부 고급 구현에서는 원본 데이터의 길이 정보를 인코딩된 문자열의 일부로 포함시킨다.

### 패딩의 중요성
1. 길이 정보 제공: 패딩은 디코더에게 원본 데이터의 정확한 길이를 알려준다. 'SGVsbG8='에서 '='는 마지막 그룹에 2비트가 추가되었음을 의미한다.
2. 그룹화 유지: Base64는 4글자 단위로 그룹화된다. 패딩은 이 그룹화를 유지하여 디코딩 과정을 단순화 한다.
3. 데이터 무결성: 패딩은 인코딩된 데이터가 완전한지 확인하는 데 도움을 준다. 패딩이 잘못되면 데이터가 손상되었을 가능성이 있다.
4. 호환성: 일부 시스템은 패딩이 있는 Base64만 처리할 수 있다. 패딩을 사용함으로써 다양한 시스템과의 호환성을 보장한다.


---

## Base64 사용

### JWT에서 사용

JWT(JSON Web Token)에서 Base64는 중요한 역할을 한다.
1. 헤더와 페이로드 인코딩: JWT의 헤더와 페이로드 부분은 Base64Url(URL 안전 버전의 Base64)로 인코딩 된다.
2. 가독성과 전송 용이성: Base64 인코딩은 JWT를 URL에 포함시키거나 HTTP 헤더로 전송할 때 안전하고 편리하게 만든다.
3. 데이터 무결성: Base64 인코딩은 JWT의 서명 부분과 함께 사용되어 토큰의 무결성을 보장한다.


### 웹 개발
Base64를 HTML이나 CSS에 직접 이미지를 삽입할 때 사용하는데 이유는 여러 가지 있다.
1. URL 안전성: Base64는 URL에 안전한 문자만 사용한다. 이는 특수 문자나 공백 등으로 인한 URL 인코딩 문제를 피할 수 있게 해준다.
2. 데이터 무결성: 이미지 데이터를 Base64로 인코딩하면 텍스트 형태로 변환되어 HTML이나 CSS 파일에 직접 포함될 수 있다. 이는 데이터의 무결성을 보장하며, 네트워크 전송 중 데이터 손실 위험을 줄인다.
3. HTTP 요청 감소: 이미지를 Base64로 인코딩하여 HTML이나 CSS에 직접 포함시키면, 별도의 HTTP 요청 없이 이미지를 로드할 수 있다. 이는 특히 작은 이미지나 아이콘의 경우 성능 향상에 도움이 될 수 있다.
4. 브라우저 호환성: Data URL 형식으로 이미지를 포함시키는 것은 현재 대부분의 브라우저에서 지원된다.
5. 파일 관리 간소화: 이미지를 HTML이나 CSS에 직접 포함시키면 별도의 이미지 파일을 관리할 필요가 없어진다.

>[!note] 프로젝트 만들 때 문제 생겼던 점
> 전에 프로젝트를 만들 때 서버에 이미지를 저장하고 다시 불러오는 상황마다
> 오류가 생겨서 문제를 못 찾아서 한참 헤매고 있던 때가 있었다. 여러 글을 찾아 보던 중,
> base64로 했더니 비슷한 문제를 해결했다는 글을 보고 따라 하니 신기하게도 문제가 풀렸는데, 
> 그 이유를 찾을 시간도 없이 급하게 후순위에 있던 다른 문제 해결과 기능을 제작 하는데 정신이 팔려, 
> 그때 알지 못 했던 문제와 해결 된 이유를 지금 알게 된 것 같다.

#### 웹 개발 시 base64 사용 단점
1. 파일 크기 증가: Base64 인코딩은 원본 데이터 크기를 약 33% 증가 시킨다.
2. 캐싱 문제: 이미지가 HTML이나 CSS에 직접 포함되면 개별적으로 캐시할 수 없다.
3. 성능 영향: 큰 이미지의 경우 Base64 인코딩이 오히려 성능을 저하시킬 수 있다.

---

## 코드 예시

브라우저 내장 함수인 `btoa()`와 `atob()`를 사용한다. 이 함수들은 현재 대부분의 브라우저에서 지원된다.
### app.js
```javascript
// Base64 인코딩 함수 
function encodeToBase64(str) { 
	try { 
		return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, function(match, p1) { 
			return String.fromCharCode('0x' + p1); 
		})); 
	} catch (e) { 
		console.error('인코딩 중 오류 발생:', e); 
		return null; 
	} 
} 

// Base64 디코딩 함수 
function decodeFromBase64(str) { 
	try { 
		return decodeURIComponent(atob(str).split('').map(function(c) {
			return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
		}).join('')); 
	} catch (e) { 
		console.error('디코딩 중 오류 발생:', e); 
		return null; 
	} 
} 

// 테스트 함수 
function testBase64() { 
	const originalText = "안녕하세요! Hello, こんにちは!"; 
	console.log("원본 텍스트:", originalText); 
	
	const encodedText = encodeToBase64(originalText); 
	console.log("인코딩된 텍스트:", encodedText); 
	
	const decodedText = decodeFromBase64(encodedText); 
	console.log("디코딩된 텍스트:", decodedText); 
	
	console.log("원본과 디코딩된 텍스트 일치 여부:", originalText === decodedText); 
} 

// 테스트 실행 
testBase64();
```
### 결과
```text
원본 텍스트: 안녕하세요! Hello, こんにちは!
인코딩된 텍스트: 7JWI64WV7ZWY7IS47JqUISBIZWxsbywg44GT44KT44Gr44Gh44GvIQ==
디코딩된 텍스트: 안녕하세요! Hello, こんにちは!
원본과 디코딩된 텍스트 일치 여부: true
```


### 부분 설명
#### encodeToBase64 함수
```javascript
function encodeToBase64(str) { 
	try { 
		return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, function(match, p1) { 
			return String.fromCharCode('0x' + p1); 
		})); 
	} catch (e) { 
		console.error('인코딩 중 오류 발생:', e); 
		return null; 
	} 
} 
```

이 함수는 문자열을 Base64로 인코딩한다.
1. encodeURIComponent(str) : 먼저 입력 문자열을 URI 인코딩한다. 이는 유니코드 문자를 안전하게 처리하기 위해서이다.
2. replace() : URI 인코딩된 문자열에서 퍼센트 인코딩 된 부분을 찾아 실제 문자로 변환한다. 예를 들어, '%41'은 'A'로 변환된다.
3. btoa() : 최종적으로 변환된 문자열을 Base64로 인코딩 한다.
4. 오류 처리 : try-catch 문을 사용하여 인코딩 과정에서 발생할 수 있는 오류를 처리한다.


#### decodeFromBase64 함수
```javascript
function decodeFromBase64(str) { 
	try { 
		return decodeURIComponent(atob(str).split('').map(function(c) {
			return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
		}).join('')); 
	} catch (e) { 
		console.error('디코딩 중 오류 발생:', e); 
		return null; 
	} 
} 
```

이 함수는 Base64로 인코딩된 문자열을 원래의 문자열로 디코딩한다.
1. atob(str) : Base64 문자열을 디코딩한다.
2. split().mpa() : 디코딩 된 문자열을 개별 문자로 분리하고, 각 문자를 16진수 형태의 퍼센트 인코딩으로 변환한다.
3. decodeURIComponent() : 최종적으로 URI 디코딩을 수행하여 원래의 문자열을 얻는다.
4. 오류 처리: try-catch 문을 사용하여 디코딩 과정의 오류를 처리한다.

#### URI 인코딩
URI 인코딩은 URL에서 사용할 수 없는 문자들을 안전하게 표현하기 위한 방법이다. 이는 URL 인코딩이라고도 불린다. URI 인코딩의 주요 특징과 목적은 다음과 같다.
1. 특수 문자 변환 : 
	- URL에서 특별한 의미를 가지는 문자들(예: '?', '&', '=', '#')과 URL에 직접 사용할 수 없는 문자들(예: 공백, 한글, 이모지)을 안전한 문자열로 변환한다.
2. 퍼센트 인코딩 : 
	- 변환 과정에서 특수 문자나 예약된 문자는 '%' 기호와 해당 문자의 ASCII 코드 16진수 값으로 대체된다. 예를 들어 공백 '%20'으로 변환된다.
3. 데이터 무결성 보장 :
	- URI 인코딩을 통해 모든 문자를 안전하게 URL에 포함시킬 수 있어, 데이터의 손실이나 변조 없이 전송할 수 있다.
4. 웹 애플리케이션 안정성 :
	- URI 인코딩은 웹 서버와 클라이언트 간의 안전한 데이터 전송을 가능하게 하여 웹 애플리케이션의 안정성을 높인다.
5. 보안 강화 :
	- 사용자 입력을 URL에 포함시키기 전에 인코딩함으로써 XSS(Cross-Site Scripting)와 같은 보안 취약점을 방지할 수 있다.
	- 여기서 사용자 입력을 URL에 포함시키는 경우란 HTML 폼에서 사용자 입력을 처리하는 경우와 사용자가 직접 URL을 조작하는 경우 모두 해당한다.
1. 다국어 지원 :
	- URI 인코딩을 통해 영어 외에 다른 언어 문자(예: 한글, 일본어, 중국어 등)도 URL에 안전하게 포함시킬 수 있다.

따라서 `encodeURIComponent(str)`에서 URI 인코딩은 입력된 문자열의 모든 특수 문자와 예약된 문자를 안전한 형태로 변환하는 과정을 의미한다. 이를 통해 어떤 문자열이든 URL의 일부로 안전하게 사용할 수 있게 된다.

---

### 블로그 내 관련 문서
- [[토큰 기반 인증]]
- [[리프레시 토큰]]

---
### 참고 자료
출처 :
- <a href="https://stackoverflow.com/questions/58341833/why-base64-is-used-in-jwts" target="_blank">stackoverflow</a>
- <a href="https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464" target="_blank">wikipedia</a>
- <a href="https://www.ioriver.io/terms/base-64-encoding" target="_blank">ioriver</a>
- <a href="https://www.redhat.com/en/blog/base64-encoding" target="_blank">redhat</a>
- <a href="https://www.tutorialspoint.com/what-is-base64-encoding" target="_blank">tutorialspoint</a>
- <a href="https://bunny.net/blog/why-optimizing-your-images-with-base64-is-almost-always-a-bad-idea/" target="_blank">bunny.net</a>
- <a href="https://www.linode.com/docs/guides/javascript-base-64-decode/" target="_blank">Akamai</a>
- <a href="https://www.programiz.com/javascript/examples/encode-string-Base64" target="_blank">programiz</a>
- <a href="https://www.geeksforgeeks.org/javascript-encode-decode-a-string-to-base64/" target="_blank">geeksforgeeks</a>
- <a href="https://www.geeksforgeeks.org/explain-the-concept-of-url-encoding-describe-the-need-for-encoding-in-html/" target="_blank">geeksforgeeks2</a>
- <a href="https://www.freecodecamp.org/news/what-is-base64-encoding/" target="_blank">freecodecamp</a>
- <a href="https://dev.to/brianmmdev/what-is-base64-encoding-and-how-is-it-used-in-web-development-3p4e" target="_blank">dev.to</a>
- <a href="https://builtin.com/software-engineering-perspectives/base64-encoding" target="_blank">builtin</a>
- <a href="https://blog.shiftasia.com/base64-encode/" target="_blank">shiftasia</a>
- <a href="https://www.csscraft.dev/blog/integrating-base64-images-in-your-web-projects" target="_blank">csscraft</a>

Base64

## HTTP와 메서드

### HTTP 메서드도 프로토콜인가?
GET과 POST는 프로토콜이 아닌 HTTP 메서드(HTTP Method)다.

HTTP(HyperText Transfer Protocol)가 프로토콜이고, GET과 POST는 이 HTTP 프로토콜 내에서 사용되는 요청 메서드들이다. 쉽게 설명하자면,
- 프로토콜(Protocol): HTTP/1.1과 같이 웹에서 데이터를 주고받는 방식을 정의한 규약
- HTTP 메서드(Method): GET, POST, PUT, DELETE 등과 같이 HTTP 프로토콜 내에서 서버에 요청을 보내는 방식을 나타낸다.

이를 실생활에 비유하면:
- 프로토콜(HTTP)은 우체국 시스템과 같은 전체 통신 체계이다.
- HTTP 메서드(GET/POST)는 그 시스템 내에서 우편물을 보내는 구체적인 방식(일반우편, 등기우편 등)이라고 볼 수 있다.

---
## GET 메서드

GET 메서드는 서버에서 정보를 '가져오는' 용도로 사용된다. 마치 햄버거 가게에서 메뉴판을 보는 것과 같다. 우리가 메뉴를 보고 싶다고 요청하면, 가게는 메뉴 정보를 보여준다. 이때 우리는 메뉴 정보를 변경하거나 새로운 메뉴를 추가하지 않고, 단순히 정보를 받아볼 뿐이다.
### GET 메서드의 주요 특징
1. 데이터 요청에 사용된다.
2. URL에 파라미터가 노출된다.
3. 브라우저 히스토리에 남는다.
4. 북마크가 가능하다.
5. 캐시될 수 있다.
6. 데이터 길이에 제한이 있다.

---
## POST 메서드

POST 메서드는 서버로 데이터를 '보내는' 용도로 사용된다. 햄버거 가게에서 주문을 하는 것과 비슷하다. 우리가 원하는 햄버거와 음료, 사이드 메뉴를 선택해서 주문하면, 가게에서는 그 정보를 받아 처리한다. 이때 우리는 새로운 정보(주문)을 가게에 전달하고 있는거다.

### POST 메서드의 주요 특징
1. 데이터 제출에 사용된다.
2. URL에 데이터가 노출되지 않는다.
3. 브라우저 히스토리에 남지 않는다.
4. 북마크할 수 없다.
5. 캐시되지 않는다.
6. 데이터 길이에 제한이 없다.

---
## GET과 POST의 주요 차이점

### 데이터 전송 방식
- GET: URL의 쿼리 문자열로 데이터를 전송한다.
- POST: HTTP 요청의 본문에 데이터를 전송한다.
### 보안
- GET: URL에 데이터가 노출되어 상대적으로 덜 안전하다.
- POST: 데이터가 본문에 포함되어 상대적으로 더 안전하다.
### 캐싱
- GET: 요청 결과를 캐시할 수 있어 성능상 이점이 있다.
- POST: 일반적으로 캐시되지 않는다.
### 멱등성
- GET: 멱등적이다. 같은 요청을 여러 번 해도 결과가 동일하다
- POST: 멱등적이지 않다, 같은 요청을 여러 번 하면 어러 번의 작업이 수행될 수 있다.

---
## 예제

Node.js와 Express를 사용하여 예제를 만들어 보자.

### 프로젝트 설정
1. 새 프로젝트 폴더 생성:
```bash
mkdir hamburger-shop 
cd hamburger-shop
```

2. Node.js 프로젝트 초기화:
```bash
npm init -y
```

3. 필요한 패키지 설치:
```bash
npm i express cors
```


### 폴더 구조
```text
hamburger-shop/ 
│
├── server.js
└── public/
	└── index.html
```


### 코드
#### 서버코드(server.js)
```javascript
const express = require('express');
const cors = require('cors');
const app = express();
const port = 3000;

app.use(cors());
app.use(express.json());
app.use(express.static('public'));

// 메뉴 데이터
const menu = {
	"햄버거": 5000,
	"치즈버거": 5500,
	"치킨버거": 6000
};

// 주문 목록
let orders = [];

// GET 요청 처리 (메뉴 조회)
app.get('/menu', (req, res) => {
	res.json(menu);
});

// POST 요청 처리 (주문하기)
app.post('/order', (req, res) => {
	const order = req.body;
	orders.push(order);
	res.status(201).json({ message: "주문이 완료되었습니다.", order: order });
});

app.listen(port, () => {
	console.log(`서버가 http://localhost:${port} 에서 실행 중입니다.`);
});
```

1. 필요한 모듈을 불러온다.
	- `express`: 웹 서버 프레임워크
	- `cors`: Cross-Origin Resource Sharing을 허용하기 위한 미들웨어
1. Express 앱을 생성하고 미들웨어를 설정한다.
	- `cors()`: 모든 출처에서의 요청을 허용한다.
	- `express.json()`: JSON 형식의 요청 본문을 파싱한다.
	- `express.static('public)`: 정적 파일을 제공한다.
1. 메뉴와 주문 데이터를 저장할 변수를 선언한다.
2. GET 요청 처리기를 만들어 메뉴를 반환한다.
3. POST 요청 처리기를 만들어 주문을 받고 처리한다.
4. 서버를 지정된 포트에서 실행한다.


#### 클라이언트 코드(public/index.html)
```html
<!DOCTYPE html>
<html lang="ko">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>햄버거 가게</title>
</head>
<body>
	<h1>햄버거 가게</h1>
	<button onclick="getMenu()">메뉴 보기</button>
	<button onclick="placeOrder()">주문하기</button>
	<div id="result"></div>
	
	<script>
		function getMenu() {
			fetch('http://localhost:3000/menu')
				.then(response => response.json())
				.then(data => {
					document.getElementById('result').innerHTML = '메뉴: ' + JSON.stringify(data);
				})
				.catch(error => console.error('에러:', error));
		}

		function placeOrder() {
			fetch('http://localhost:3000/order', {
				method: 'POST',
				headers: {
					'Content-Type': 'application/json',
				},
				body: JSON.stringify({
					"햄버거": 2,
					"치즈버거": 1,
					"음료": "콜라"
				}),
			})
			.then(response => response.json())
			.then(data => {
				document.getElementById('result').innerHTML = '주문 결과: ' + JSON.stringify(data);
			})
			.catch(error => console.error('에러:', error));
		}
	</script>
</body>
</html>
```

1. 간단한 HTML 구조를 만들고 두 개의 버튼을 추가한다.
2. JavaScript 함수를 정의한다.
	- `getMenu()`: 서버에 GET 요청을 보내 메뉴를 가져온다.
	- `placeOrder()`: 서버에 POST 요청을 보내 주문을 한다.
1. `fetch()` 함수를 사용하여 서버와 통신한다.
2. 응답 결과를 페이지에 표시한다.
### 실행
1. `server.js` 파일을 실행한다.
```bash
node server.js
```
2. 웹 브라우저를 열고 `htttp://localhost:3000`으로 접속한다.
3. "메뉴 보기" 버튼을 클릭하여 GET 요청을 테스트한다.
4. "주문하기" 버튼을 클릭하여 POST 요청을 테스트한다.

---
## 구조 파악

### GET 메서드 구조
GET 메서드는 마치 햄버거 가게의 메뉴판을 보는 것과 같다.
1. 구조: URL을 통해 데이터를 요청한다. 예를 들어, 
	- 'https://hamburger.com/menu?item=cheeseburger'
2. 데이터 전송: URL의 쿼리 문자열에 데이터를 포함한다.
	- '?key1=value1&key2=value2' 형식이다.
3. 길이 제한: URL 길이에 제한이 있어 일반적으로 2,000자 미만으로 사용한다.
4. 가시성: URL에 모든 데이터가 노출되어 누구나 볼 수 있다.
5. 캐싱: 브라우저나 서버에서 캐시할 수 있어 동일한 요청의 응답 속도가 빨라질 수 있다.
6. 브라우저 히스토리: URL에 데이터가 포함되어 있어 브라우저 히스토리에 남는다.
7. 데이터 타입: ASCII 문자열에만 전송 가능하다.
8. 보안: URL에 데이터가 노출되므로 비밀번호 같은 민감한 정보 전송에는 부적합하다.
9. 멱등성: 동일한 요청을 여러 번 보내도 결과가 같다.
10. 응답 코드: 성공 시 일반적으로 HTTP 상태 코드 200을 반환한다.

### POST 메서드
POST 메서드는 햄버거 가게에서 주문서를 작성하여 제출하는 것과 비슷하다.
1. 구조: 요청 본문(body)에 데이터를 포함하여 전송한다.
2. 데이터 전송: 요청 본문에 데이터를 담아 전송한다. 다양한 형식(form-data, JSON 등) 사용 가능하다.
3. 길이 제한: 요청 본문의 크기에 제한이 없어 대용량 데이터 전송이 가능하다.
4. 가시성: URL에 데이터가 노출되지 않아 GET보다 보안성이 높다.
5. 캐싱: 일반적으로 캐시되지 않는다. 필요시 별도 설정이 필요하다.
6. 브라우저 히스토리: 데이터가 URL에 포함되지 않아 브라우저 히스토리에 남지 않는다.
7. 데이터 타입: 문자열뿐만 아니라 바이너리 데이터도 전송 가능하다.
8. 보안: 데이터가 URL에 노출되지 않아 민감한 정보 전송에 적합하다.
9. 멱등성: 동일한 요청을 여러 번 보내면 여러 번의 작업이 수행될 수 있다.
10. 응답 코드: 성공적으로 생성된 경우 일반적으로 HTTP 상태 코드 201을 반환한다.

---
## HTTP 요청 구조

### GET 요청
우리가 작성한 기본 GET 요청 코드
```javascript
fetch('http://localhost:3000/menu')
```

이 코드가 실행될 때 실제로 생성되는 HTTP 요청 구조는 다음과 같다.
```text
GET /menu HTTP/1.1 
Host: localhost:3000 
User-Agent: Mozilla/5.0 
Accept: application/json 
Accept-Language: ko-KR,ko 
Accept-Encoding: gzip, deflate 
Connection: keep-alive
```


### POST 요청
```javascript
fetch('http://localhost:3000/order', { 
	method: 'POST', 
	headers: { 
		'Content-Type': 'application/json', 
	}, 
	body: JSON.stringify({ 
		"햄버거": 2, 
		"치즈버거": 1, 
		"음료": "콜라" 
	}), 
})
```

이 코드가 실행될 때 생성되는 실제 HTTP 요청 구조는 다음과 같다.
```text
POST /order HTTP/1.1 
Host: localhost:3000 
Content-Type: application/json 
Accept: application/json 
Accept-Language: ko-KR,ko 
Content-Length: 89 
Connection: keep-alive 

{ 
	"햄버거": 2, 
	"치즈버거": 1, 
	"음료": "콜라" 
}
```


우리가 `fetch()`로 작성한 간단한 코드는 브라우저에 의해 자동으로 완전한 HTTP 요청 구조로 변환된다. 개발자가 직접 모든 헤더를 작성할 필요 없이, 브라우저가 필요한 기본 헤더들을 자동으로 추가해준다.


### 주요 구성 요소
#### HTTP 요청의 기본 구조
HTTP 요청은 다음과 같은 주요 구성 요소로 이루어진다.
1. HTTP 메서드(The HTTP Method)
	- GET, POST, PUT, DELETE 등의 요청 방식을 지정한다.
2. 리소스 경로(Path to the source)
	- 웹 서버에서 요청하고자 하는 리소스의 경로다.
	- 예: 'hamburger.com'
3. 매개변수(Parameters)
	- 서버로 전달하는 추가 정보다.
	- GET 방식의 경우: '?item=cheeseburger' 와 같이 URL에 포함된다.
4. 프로토콜 버전(Protocol Version)
	- 사용하는 HTTP 프로토콜의 버전이다.
	- 예: 'HTTP/1.1'

#### 요청 헤더(Request Headers)
요청 헤더는 클라이언트가 서버에 전달하는 부가 정보를 포함한다.
1. Host
	- 요청하는 서버의 도메인 이름
	- 예: 'localhost:3000 '
1. User-Agent
	 - 클라이언트 프로그램 정보
	 - 예: 'Mozilla/5.0'
1. Accept
	- 클라이언트가 처리할 수 있는 컨텐츠 타입
	- 예: 'text/xml, text/html, text/plain, image/jpeg'
1. Accept-Language
	- 클라이언트가 선호하는 언어
	- 예: 'ko-KR,ko', 'en-US,en;q=0.5'
	- 여기서 'q=0.5'는 가중치를 의미하고, 1.0이 가장 높은 선호도다.
	- 'en-US,en;q=0.5'만 놓고 볼 경우, 미국 영어를 가장 선호하고, 그 다음으로 일반 영어를 선호한다는 의미이다.
1. Accept-Encoding
	- 클라이언트가 처리할 수 있는 인코딩 방식
	- 예: 'gzip, deflate, br, zstd'
2. Accept-Charset
	- 클라이언트가 지원하는 문자 인코딩
	- 예: 'ISO-8859-1, utf-8'
	- 현재는 거의 사용되지 않는다. UTF-8이 표준 되었기 때문이다.
1. Keep-Alive
	- 연결 유지 시간(초)
	- 예: 'timeout=5'
	- timeout: 연결을 5초 동안 유지
1. Connetion
	- 클라이언트와 서버 간의 연결 방식
	- 현재 연결이 끝난 후 네트워크 연결을 유지할지 결정하는 헤더
	- 예: 'Keep-alive'
	- Keep-alive의 경우 연결을 유지한다.



---


### 블로그 내 관련 문서
- [[HTTP 상태 코드]]

---
### 참고 자료
출처 :
- <a href="https://www.baeldung.com/cs/http-get-vs-post" target="_blank">baeldung</a>
- <a href="https://www.guru99.com/difference-get-post-http.html" target="_blank">guru99</a>
- <a href="https://www.akto.io/academy/get-vs-post" target="_blank">akto</a>
- <a href="https://www.geeksforgeeks.org/difference-between-http-get-and-post-methods/" target="_blank">geeksforgeeks</a>
- <a href="https://stackoverflow.com/questions/3477333/what-is-the-difference-between-post-and-get" target="_blank">stackoverflow</a>
- <a href="https://blog.postman.com/what-are-http-methods/" target="_blank">postman</a>
- <a href="https://apidog.com/blog/http-methods/" target="_blank">apidog</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET" target="_blank">mdn-get</a>
- <a href="https://http.dev/post" target="_blank">.dev-post</a>
- <a href="https://http.dev/get" target="_blank">.dev-get</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST." target="_blank">mdn-post</a>
- <a href="https://http.dev/accept" target="_blank">.dev-accept</a>
- <a href="https://www.holisticseo.digital/technical-seo/http-header/content-negotiation/accept-language/" target="_blank">holisticseo</a>
- <a href="https://www.geeksforgeeks.org/http-headers-keep-alive/" target="_blank">geeksforgeeks-keep-alive</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive" target="_blank">mdn-keep-alive</a>
- <a href="https://etloveguitar.tistory.com/137" target="_blank">쿼카러버의 기술 블로그</a>
- <a href="https://http.dev/accept-charset" target="_blank">.dev-accept-charset</a>
- <a href="https://http.dev/accept-encoding" target="_blank">.dev-accept-encoding</a>

HTTP 메서드 중 GET과 POST에 대해 알아보자

HTTP 메서드 GET과 POST

## PUT 메서드

PUT 메서드는 주로 리소스를 업데이트하거나 새로운 리소스를 생성할 때 사용된다.

### PUT의 주요 특징
1. 멱등성(Idempotent): PUT 요청은 여러 번 실행해도 결과가 동일하다.
2. 전체 리소스 교체: PUT은 리소스 전체를 교체한다.
3. 리소스 생성 가능: 지정된 URI에 리소스가 없으면 새로 생성할 수 있다.

### PUT 예제
음식 주문 시스템을 예로 들어보자. 고객이 주문한 피자의 토핑을 변경하고 싶다고 가정해보자.

```text
PUT /orders/12345 HTTP/1.1 
Host: pizza.example.com 
Content-Type: application/json 

{ 
	"orderId": "12345", 
	"customerName": "흰둥이", 
	"pizza": "치즈 피자", 
	"toppings": ["올리브", "버섯", "파인애플"], 
	"size": "large", 
	"status": "준비중" 
}
```

이 요청은 주문 ID 12345의 전체 정보를 업데이트한다. 서버는 이 정보로 기존 주문을 완전히 대체한다.

---
## PATCH 메서드

PATCH 메서드는 리소스의 부분적인 수정을 위해 사용된다.

### PATCH의 주요 특징
1. 부분 수정: 리소스의 일부만 수정할 수 있다.
2. 비멱등성: PATCH 요청은 멱등하지 않을 수 있다.
3. 유연성: 다양한 형식의 패치 문서를 사용할 수 있다.

### PATCH 예제
같은 피자 주문 시스템에서, 이번에는 주문 상태만 변경하고 싶다고 가정해보자.

```text
PATCH /orders/12345 HTTP/1.1 
Host: pizza.example.com 
Content-Type: application/json-patch+json 

[ 
	{ "op": "replace", "path": "/status", "value": "배달중" } 
]
```

이 요청은 주문 상태만 "배달중"으로 업데이트한다. 다른 정보는 그대로 유지된다.

---
## PUT vs PATCH

1. 데이터 범위: PUT은 전체 리소스를 교체하지만, PATCH는 일부만 수정한다.
2. 멱등성: PUT은 멱등하지만, PATCH는 항상 그렇지는 않다.
3. 사용 상황:
	- PUT: 리소스 전체를 업데이트하거나 새로 생성할 때
	- PATCH: 리소스의 일부만 수정할 때

---
## 예제

Node.js와 Express를 사용한 간단한 실습 예제를 만들어보자. 이 예제는 사용자 정보를 관리하는 간단한 API다

### 프로젝트 설정
1. 새 디렉토리 생성 및 초기화
```bash
mkdir http-methods-example 
cd http-methods-example 
npm init -y
```


 
2. 필요한 패키지 설치
```bash
npm install express
```


 
3. 프로젝트 구조
```text
http-methods-example/ 
│ 
├── server.js 
└── package.json
```

 
### 코드(server.js)
```javascript
const express = require('express');
const app = express();
app.use(express.json());

let users = [
	{ id: 1, name: '신짱구', email: 'shin@example.com', age: 5 }
];

// PUT 요청 처리
app.put('/users/:id', (req, res) => {
	const id = parseInt(req.params.id);
	const updatedUser = req.body;
	const index = users.findIndex(user => user.id === id);
	
	if (index !== -1) {
		users[index] = { ...updatedUser, id };
		res.json(users[index]);
	} else {
		users.push({ ...updatedUser, id });
		res.status(201).json(updatedUser);
	}
});

// PATCH 요청 처리
app.patch('/users/:id', (req, res) => {
	const id = parseInt(req.params.id);
	const updates = req.body;
	const index = users.findIndex(user => user.id === id);
	
	if (index !== -1) {
		users[index] = { ...users[index], ...updates };
		res.json(users[index]);
	} else {
		res.status(404).json({ message: '사용자를 찾을 수 없습니다.' });
	}
});

// 사용자 목록 조회 (테스트용)
app.get('/users', (req, res) => {
	res.json(users);
});

const PORT = 3000;
app.listen(PORT, () => console.log(`서버가 http://localhost:${PORT} 에서 실행 중입니다.`));
```


이 예제에서 PUT 요청은 사용자 정보 전체를 교체하거나 새로운 사용자를 생성한다. PATCH 요청은 기존 사용자 정보의 일부만 수정한다.

### 실행
1. 서버 실행
```bash
node server.js
```


 
### 테스트 방법
서버를 실행한 뒤 API 클라이언트(예: Postman) 또는 `curl` 명령어를 사용하여 테스트할 수 있다. 본 글에서는 `curl` 명령어를 상용한 테스트를 진행한다.

 

>[!note] curl이란?
>curl은 다양한 프로토콜을 사용하여 데이터를 전송하는 명령줄 도구이다. 웹 개발자들이 API를 테스트하거나 HTTP 요청을 보낼 떄 자주 사용한다.


 

curl의 주요 특징:
1. 다양한 프로토콜 지원 (HTTP, HTTPS, FTP 등)
2. 데이터 전송 및 수신 가능
3. 인증, 쿠키, 헤더 설정 등 다양한 옵션 제공
4. 스크립트에서 사용하기 좋음

 
#### PUT 요청 테스트
- 아래와 같은 형태의 PUT 요청을 한다고 가정한다.(신짱아 추가)
```text
PUT /users/2 HTTP/1.1 
Content-Type: application/json 

{ 
	"name": "신짱아", 
	"email": "hima@example.com", 
	"age": 0
}
```


 
- 터미널에 curl 명령어 입력
```bash
curl -X PUT -H "Content-Type: application/json" -d '{"name":"신짱아","email":"hima@example.com","age":0}' http://localhost:3000/users/2
```


 
- 결과: 
```text
{"name":"신짱아","email":"hima@example.com","age":0}%
```

 
#### PATCH 요청 테스트
- 아래와 같은 형태의 PATCH 요청을 한다고 가정한다.(신짱구 나이 30으로 변경)
```text
PATCH /users/1 HTTP/1.1 
Content-Type: application/json 

{ 
	"age": 30
}
```


 

- 터미널에 curl 명렁어 입력
```bash
curl -X PATCH -H "Content-Type: application/json" -d '{"age":30}' http://localhost:3000/users/1
```


 
- 결과:
```text
{"id":1,"name":"신짱구","email":"shin@example.com","age":30}%
```


 
#### 사용자 목록 조회(변경 확인)
```bash
curl http://localhost:3000/users
```


 

결과
```text
[{"id":1,"name":"신짱구","email":"shin@example.com","age":30},{"name":"신짱아","email":"hima@example.com","age":0,"id":2}]%
```



PUT과 PATCH 메서드를 사용하면 리소스를 효율적으로 관리할 수 있다. PUT은 전체 리소스를 한 번에 업데이트하고 싶을 때, PATCH는 일부만 수정하고 싶을 때 사용하면 된다.

 
#### 주의사항
- 이 예제는 메모리 내 데이터를 사용하므로 서버를 재시작하면 변경사항이 초기화 된다.
- 실제 프로젝트에서는 데이터베이스를 사용하여 영구적으로 데이터를 저장해야 한다.
- 보안, 유효성 검사 등의 추가적인 처리가 필요하다.


---
## PUT과 POST의 차이

PUT과 POST 모두 리소스를 생성할 수 있는데, 무슨 차이가 있을까?
 

| 특징 | PUT | POST |
| ---------------- | ------------------------------- | ----------------------------------------- |
| 멱등성(Idempotency) | O 같은 요청을 여러 번 보내도 결과가 동일하다. | X 같은 요청을 여러 번 보내면 여러 개의 리소스가 생성될 수 있다. |
| URI 의미 | URI로 리소스의 정확한 위치를 지정한다. | URI가 리소스를 처리할 위치를 나타낸다. |
| 리소스 생성 방식 | 클라이언트가 리소스의 URI를 알고 있어야 한다. | 서버가 새 리소스의 URI를 결정한다. |
| 기존 리소스 처리 | 기존 리소스가 있으면 완전히 대체한다. | 새 리소스를 생성한다 |
| 요청 본문 | 전체 리소스 데이터를 포함해야 한다. | 새 리소스에 필요한 데이터만 포함할 수 있다. |
| 용도 | 주로 업데이트에 사용된다. | 새 리소스 생성에 사용된다. |


 
### 멱등성과 URI 차이
예를 들어 PUT의 경우
```bash
curl -X PUT -H "Content-Type: application/json" -d '{"name":"신짱아","email":"hima@example.com","age":0}' http://localhost:3000/users/2
```

 
이렇게 `/users/2` 라는 특정 위치에 리소스를 생성하거나 업데이트한다. 같은 요청을 여러 번 보내도 결과는 동일할 것이다. 이것이 PUT의 멱등성(idempotency)이다.

 
반면 POST의 경우 일반적으로 새로운 리소스를 생성하는 데 사용되며, 서버가 새 리소스의 URI를 결정한다.
예를 들어, server.js에 다음 코드를 추가한 뒤

```javascript
// POST 요청 처리 
app.post('/users', (req, res) => { 
	const newUser = req.body; 
	const newId = users.length > 0 ? Math.max(...users.map(u => u.id)) + 1 : 1; 
	const userWithId = { id: newId, ...newUser }; 
	users.push(userWithId); 
	res.status(201).json(userWithId); 
});
```


 
아래와 같은 curl 명령어를 입력해보자.

```bash
curl -X POST -H "Content-Type: application/json" -d '{"name":"흰둥이","email":"whitey@example.com","age":2}' http://localhost:3000/users
```


 
이 요청을 여러 번 보내면, 서버는 매번 새로운 리소스를 생성할 수 있다. 
맨 처음에는 "id:2"로 추가되고, 한번 더 하면 "id:3"로 또 다시 흰둥이가 추가된다. 따라서 POST는 멱등하지 않다.

 

요약하자면:
1. PUT은 클라이언트가 리소스의 위치(URI)를 정확하게 알고 있을 때 사용한다.
2. POST는 새 리소스를 생성할 때 사용하며, 서버가 새 리소스의 URI를 결정한다.
3. PUT은 멱등하지만, POST는 멱등하지 않다.

---
### 블로그 내 관련 문서
- [[HTTP 메서드 PUT과 PATCH]]

---
### 참고 자료
출처 :
- <a href="https://http.dev/put" target="_blank">.dev/put</a>
- <a href="https://http.dev/patch" target="_blank">.dev/patch</a>
- <a href="https://reqbin.com/req/orjagaoq/http-put-request" target="_blank">reqbin</a>
- <a href="https://en.wikipedia.org/wiki/PATCH_(HTTP)" target="_blank">wikipedia</a>
- <a href="https://www.akto.io/academy/put" target="_blank">akto</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH" target="_blank">mdn</a>
- <a href="https://www.lonti.com/blog/understanding-http-methods-in-rest-api-development" target="_blank">lonti</a>
- <a href="https://www.akto.io/academy/put-vs-post" target="_blank">akto-put-vs-post</a>
- <a href="https://sentry.io/answers/what-is-the-difference-between-post-and-put-in-http/" target="_blank">sentry</a>
- <a href="https://www.freecodecamp.org/news/http-request-methods-explained/" target="_blank">freecodecamp</a>
- <a href="https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/PUT-vs-POST-Whats-the-difference" target="_blank">theserverside</a>

HTTP 메서드 중 PUT과 PATCH에 대해 알아보자

HTTP 메서드 PUT과 PATCH

## HTTP 상태 코드란

일상생활에서 사용하는 신호등과 비슷하다고 생각하면 된다. 
빨간불, 노란불, 초록불이 각각 다른 의미를 가지고 있듯이, HTTP 상태 코드도 서버와 클라이언트 간의 통신 상태를 나타내는 신호등 역할을 한다.

## HTTP 상태 코드의 기본 구조

HTTP 상태 코드는 3자리 숫자로 구성되어 있으며, 첫 번째 숫자에 따라 5개의 클래스로 나뉜다.
1. 1xx (정보): 요청을 받았으며 프로세스를 계속 진행한다.
2. 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용했다.
3. 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다.
4. 4xx (클라이언트 오류): 요청의 문법이 잘 못 되었거나 요청을 처리할 수 없다.
5. 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다.

좀 더 자세히 보자면,
### 1xx 정보 응답
이 클래스의 상태 코드는 임시적인 응답이다. 현재는 HTTP/1.1 명세에 정의된 1xx 상태 코드가 많이 사용되지 않는다.
- 100 Continue: 지금까지의 진행상태에 문제가 없으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.
- 101 Switching Protocols: 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 해당하며 서버에서 프로토콜을 변경할 것임을 알려준다.
#### Upgrad 요청 헤더
Upgrad 요청 헤더는 클라이언트가 서버에게 현재 사용 중인 프로토콜에서 다른 프로토콜로 전환하고 싶다는 의사를 전달하는 HTTP 헤더다. 이는 마치 대화 중에 "우리 이제부터 영어로 대화할까요?"라고 제안하는 것과 비슷하다.

예를 들어, 클라이언트가 다음과 같은 요청을 보낼 수 있다.
```text
GET /index.html HTTP/1.1 
Host: www.example.com 
Connection: Upgrade 
Upgrade: websocket
```

여기서 클라이언트는 현재의 HTTP 연결을 WebSocket 프로토콜로 업그레이드하고 싶다고 요청하고 있다.
 
서버가 이 요청을 수락하면, 101 Switching Protocols 응답을 보낸다. 이는 "네, 당신의 요청을 수락하고 프로토콜을 변경하겠습니다"라는 의미다.

```text
HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade
```

이 과정은 이미 서비스 중인 웹의 전체 프로토콜을 바꾸는 것이 아니라, 특정 연결에 대해서만 프로토콜을 변경하는 것이다. 따라서 다른 사용자들의 연결에는 영향을 미치지 않는다.
### 2xx 성공 응답
이 클래스의 상태 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타낸다.
- 200 OK: 요청이 성공적으로 처리된 상태. 가장 자주 볼 수 있는 상태 코드다.
- 201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됐음을 의미한다. 이는 일반적으로 POST 요청 이후에 따라온다.
- 204 No Content: 요청이 성공적으로 처리되었지만 제공할 컨텐츠가 없음을 의미한다.

### 3xx 리다이렉션 메시지
이 클래스의 상태 코드는 클라이언트가 요청을 완료하기 위해 추가적인 동작이 필요함을 나타낸다.
- 301 Moved Permanently: 요청한 리소스의 URI가 변경되었음을 의미한다. 새로운 URI가 응답에서 제공된다.
- 302 Found: 요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 향후 요청시 원래 URI를 계속 사용해야 한다.
- 304 Not modified: 클라이언트가 조건부 Get 요청을 했고, 리소스에 접근은 허용되지만 조건에 맞지 않아 변경되지 않았음을 나타낸다.

### 4xx 클라이언트 에러 응답
이 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.
- 400 Bad Request: 서버가 요청을 이해할 수 없음을 의미한다. 클라이언트는 수정 없이 이 요청을 재전송하면 안 된다.
- 401 Unauthorized: 인증이 필요한 리소스에 대해 인증 없이 접근했을 때 발생한다.
- 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부했음을 의미한다.
- 404 Not Found: 서버가 요청한 리소스를 찾을 수 없다. 브라우저에서 가장 자주 볼 수 있는 오류 중 하나이다.

### 5xx 서버 에러 응답
이 클래스의 상태 코드는 서버가 유효한 요청을 수행하지 못 했음을 나타낸다.
- 500 Internal Server Error: 서버에 오류가 발생하여 요청을 수행할 수 없다.
- 502 Bad Gateway: 게이트웨이나 프록시 역할을 하는 서버가 업스트림 서버로부터 유효하지 않은 응답을 받았음을 나타낸다.
- 503 Service Unavailalbe: 서버가 일시적으로 서비스를 제공할 수 없다. 일반적으로 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버에서 발생한다.
#### 업스트림

> [!info] 업스트림 서버
> '업스트림 서버'는 원본 서버 또는 백엔드 서버를 의미한다. 이는 마치 물이 상류에서 하류로 흐르는 것처럼, 데이터가 원본 서버에서 프록시 서버를 거쳐 클라이언트로 흐르는 것을 비유한 표현이다.


웹 아키텍처를 강물에 비유하자면,
1. 클라이언트(사용자의 브라우저): 강 하구
2. 프록시 서버 또는 게이트웨이: 강의 중간 지점
3. 원본 서버(업스트림 서버): 강의 상류
 
502Bad Gateway 오류는 프록시 서버가 업스트림 서버로부터 잘못된 응답을 받았을 때 발생한다. 
예를 들어:
1. 클라이언트가 웹 사이트를 요청한다.
2. 이 요청은 먼저 프록시 서버(예: CDN)에 도달한다.
3. 프록시 서버는 원본 서버(업스트림 서버)에 요청을 전달한다.
4. 원본 서버가 잘 못된 형식의 응답을 보내거나, 응답을 보내지 않는다.
5. 프록시 서버는 이 상황을 502 Bad Gateway 오류로 클라이언트에게 알린다.
 
이는 마치 강의 중간에서 물을 정화하는 시설이 상류에서 오염된 물을 받아 제대로 처리할 수 없는 상황과 비슷하다고 볼 수 있다.

HTTP 상태 코드는 마치 웹 세상의 교통 신호와 같다. 200 OK는 초록불처럼 모든 것이 순조롭게 진행되고 있음을, 404 Not Found는 길을 잃었다는 빨간불과 같다. 301 Moved Permanently는 "이 길은 막혔으니 다른 길로 가세요"라는 안내 표지판과 비슷하다.

---


### 블로그 내 관련 문서
- [[HTTP에 대해2]]

---
### 참고 자료
출처 :
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status" target="_blank">mdn</a>
- <a href="https://www.semrush.com/blog/http-status-codes/" target="_blank">semrush</a>
- <a href="https://developers.cloudflare.com/support/troubleshooting/http-status-codes/http-status-codes/" target="_blank">cloudflare</a>
- <a href="https://techcommunity.microsoft.com/blog/appsonazureblog/troubleshooting-azure-app-service-apps-using-web-server-logs/392329" target="_blank">microsoft</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade" target="_blank">mdn2</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism?v=1.1.1" target="_blank">mdn3</a>

HTTP 상태코드란 서버와 클라이언트 간의 통신 상태를 나타내는 역할

HTTP 상태코드

## HTTPS와 TLS 핸드셰이크의 상세한 과정 및 관련 개념들

### TLS 핸드셰이크의 기본 개념

- **TLS (Transport Layer Security)**: 인터넷 상의 통신을 위한 개인 정보와 데이터 보안을 제공하는 보안 프로토콜로, 이전의 SSL(Secure Socket Layer) 프로토콜에서 발전한 것이다. TLS는 암호화, 인증, 및 무결성을 제공한다.

---
### TLS 핸드셰이크 과정

TLS 핸드셰이크는 클라이언트와 서버가 안전한 통신을 설정하기 위해 수행하는 일련의 단계다. 
아래는 이 과정의 설명이다.

#### 1. **Client Hello**
- 클라이언트가 서버에게 Client Hello 메시지를 전송한다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원되는 암호화 알고리즘(Cipher Suites), 클라이언트 무작위 데이터, 세션 ID, 및 서버명(SNI)이 포함된다.

#### 2. **Server Hello**
- 서버는 Server Hello 메시지를 클라이언트에게 전송한다. 이 메시지에는 서버가 선택한 TLS 버전, 선택한 암호화 알고리즘, 서버 무작위 데이터, 및 서버의 TLS 인증서가 포함된다.

#### 3. **인증서 전달 및 인증**
- 서버는 자신의 TLS 인증서를 클라이언트에게 전달한다. 이 인증서는 서버의 공개 키와 도메인 소유자에 대한 정보를 포함하며, [CA(Certificate Authority)](#ca)가 서명한 것이다. 클라이언트는 이 인증서를 사용하여 서버의 신원을 확인한다. 클라이언트는 내장된 CA 공개 키로 인증서를 복호화하여 정상적으로 발급된 것인지 확인한다.

#### 4. **키 교환 (Key Exchange)**
- 클라이언트와 서버는 키 교환 알고리즘을 사용하여 대칭키(세션 키)를 생성한다.
 - **RSA 키 교환**: 클라이언트는 `premaster secret`을 생성하고, 이를 서버의 공개 키로 암호화하여 전송한다. 서버는 자신의 개인 키로 이를 복호화한다.
 - **Diffie-Hellman (DH) 및 ECDHE**: 클라이언트와 서버는 DH 매개변수를 교환하여 동일한 `premaster secret`을 생성한다. ECDHE는 타원곡선 암호를 사용한 DH 알고리즘으로, 보안성이 높고 효율적이다.

#### 5. **세션 키 생성**
- 클라이언트와 서버는 클라이언트 무작위 데이터, 서버 무작위 데이터, 및 `premaster secret`을 사용하여 대칭키인 세션 키를 생성한다. 이 세션 키는 이후의 통신에서 데이터를 암호화하고 복호화하는 데 사용된다.

#### 6. **Change Cipher Spec**
- 클라이언트와 서버는 Change Cipher Spec 메시지를 전송하여 이후의 모든 패킷이 협상된 알고리즘과 키를 사용하여 암호화됨을 알린다.

#### 7. **Finished**
- 클라이언트와 서버는 Finished 메시지를 전송하여 TLS 핸드셰이크가 성공적으로 완료되었음을 확인한다. 이제부터 모든 통신은 세션 키를 사용하여 암호화된다.

---
### 추가적인 개념들

#### Cipher Suites
- **Cipher Suites**는 클라이언트와 서버가 사용할 수 있는 암호화 알고리즘의 집합을 의미한다. 클라이언트는 Client Hello 메시지에서 지원하는 Cipher Suites를 서버에게 전송하고, 서버는 Server Hello 메시지에서 선택한 Cipher Suite를 클라이언트에게 전송한다.

#### DH 매개변수와 키 교환 알고리즘
- **Diffie-Hellman (DH)**: DH 알고리즘은 클라이언트와 서버가 공개적으로 매개변수들을 교환하여 동일한 대칭키를 생성하는 방식이다. ECDHE는 타원곡선 암호를 사용한 DH 알고리즘으로, 보안성이 높고 효율적이다.

#### 인증서와 CA
- 서버의 TLS 인증서는 서버의 공개 키와 도메인 소유자에 대한 정보를 포함하며, CA가 서명한 것이다. 클라이언트는 이 인증서를 사용하여 서버의 신원을 확인한다.

#### CA
CA는 단순 서명만 하는 것이 아니라, 인증서의 발급, 관리 및 신뢰성을 보장하는 중요한 역할을 수행한다. 
이는 인터넷 상의 안전한 통신과 트랜잭션을 지원하는 데 필수적인 요소이다.
##### CA의 주요역할
1. 신원확인
	- CA는 인증서를 요청하는 엔티티의 신원을 확인한다.
	- 이는 도메인 소유권, 조직 정보, 개인 정보 등 다양한 검증을 통해 이루어진다.
2. 인증서 발급
	- 인증서 요청자가 자신의 신원을 확인한 후, CA는 해당 엔티티에게 디지털 인증서를 발급한다.
	- 이 인증서에는 엔티티의 공개 키와 기타 정보가 포함되며, CA의 개인 키로 디지털 서명한다.
3. 디지털 서명
	- CA는 발급한 인증서에 디지털 서명을 한다.
	- 이 디지털 서명은 인증서의 유효성과 무결성을 보장하며, 브라우저나 다른 클라이언트가 인증서를 신뢰할 수 있도록 한다.
4. 인증서 관리
	- CA는 인증서의 전체 수명주기를 관리한다.
	- 이는 인증서의 발급, 갱신 및 해지 등을 포함한다.
	- 예를 들어, 인증서가 만료되거나 취소될 경우, CA는 이를 관리하고 알림을 제공한다.
5. 공개 키 인프라 (PKI) 유지
	- CA는 공개 키 인프라를 기반으로 운영되며, 루트 인증서와 중간 인증서를 포함한 계층 구조를 유지한다.
	- 이 계층 구조는 브라우저와 다른 클라이언트가 CA에서 발급한 인증서를 신뢰할 수 있도록 한다.

##### CA의 서명 과정
- 인증서 서명 요청 (CSR) 생성:
	- 클라이언트는 자신의 공개 키와 개인 키 쌍을 생성하고, 공개 키와 기타 정보를 포함한 CSR을 생성한다.
- CA에 요청 제출:
	- 클라이언트는 CSR을 CA에 제출하고, CA는 요청자의 신원을 확인한다.
- 인증서 발급:
	- 신원이 확인된 후, CA는 인증서를 발급하고, 자신의 개인 키로 디지털 서명을 한다.
	- 이로써 인증서가 유효하고 신뢰할 수 있음을 보장한다.

#### RSA의 취약점
- RSA 키 교환 알고리즘은 이전 버전의 TLS에서 사용되었지만, 현재는 보안 취약점으로 인해 TLS 1.3에서는 지원하지 않는다[1][6].

#### 0-RTT (Zero Round-Trip Time Resumption)
- TLS 1.3에서 도입된 기능으로, 이전에 설정된 세션을 재사용하여 초기 핸드셰이크를 생략하고 즉시 데이터 전송을 시작할 수 있다. 이는 성능을 개선하는 데 도움이 된다.

#### 해싱 알고리즘
- 해싱 알고리즘은 데이터의 무결성을 확인하는 데 사용된다. 예를 들어, SHA-256 등의 해싱 알고리즘은 원본 데이터가 변경되지 않았는지 확인하는 데 사용된다. TLS 핸드셰이크 과정에서 해싱 알고리즘은 인증서의 서명 검증과 데이터의 무결성을 확인하는 데 사용된다.

#### TLS 패킷 분석
- TLS 패킷을 분석하여 통신의 보안성을 확인할 수 있다. 예를 들어, Wireshark와 같은 도구를 사용하여 TLS 패킷을 캡처하고 디코딩할 수 있다.

---
### 예제와 도구

#### OpenSSL을 사용한 TLS 핸드셰이크 확인
- OpenSSL을 사용하여 TLS 핸드셰이크 과정을 직접 확인할 수 있다. 예를 들어, 다음 명령어를 사용하여 Google의 TLS 정보를 확인할 수 있다:

```bash
openssl s_client -connect google.com:443
```

이 명령어를 실행하면, TLS 핸드셰이크 과정이 출력되며, 사용된 프로토콜 버전, 암호화 알고리즘, 세션 정보 등을 확인할 수 있다

#### DH 매개변수 생성
- OpenSSL을 사용하여 DH 매개변수를 생성할 수 있다. 예를 들어, 다음 명령어를 사용하여 DH 매개변수를 생성할 수 있다:

```bash
openssl dhparam -out dhparams.pem 2048
```

이 명령어는 2048비트의 DH 매개변수를 생성하여 `dhparams.pem` 파일에 저장한다

---
### 중요 개념 요약

- **Cipher Suites**: 클라이언트와 서버가 사용할 수 있는 암호화 알고리즘의 집합.
- **키 교환 알고리즘**: RSA, DHE, ECDHE 등이 있으며, 각 알고리즘의 보안성과 효율성을 고려하여 선택한다.
- **인증서와 CA**: 서버의 신원을 확인하는 데 사용되는 인증서와 CA의 역할.
- **RSA의 취약점**: RSA 키 교환 알고리즘의 보안 취약점으로 인해 TLS 1.3에서는 지원하지 않는다.
- **0-RTT**: 이전에 설정된 세션을 재사용하여 초기 핸드셰이크를 생략하고 즉시 데이터 전송을 시작할 수 있는 기능.
- **해싱 알고리즘**: 데이터의 무결성을 확인하는 데 사용되는 알고리즘.
- **TLS 패킷 분석**: TLS 통신의 보안성을 확인하는 데 사용되는 도구와 방법.

---
### 블로그 내 관련 문서
- [[HTTP에 대해2]]

---
### 참고 자료
출처 : 
- <a href="https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/" target="_blank">cloudflare</a>
- <a href="https://velog.io/@seyoung755/TLS-handshake%EA%B0%80-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95 " target="_blank">seyoung755</a>
- <a href="https://brunch.co.kr/@sangjinkang/38 " target="_blank">sangjinkang</a>
- <a href="https://lesstif.gitbooks.io/web-service-hardening/content/ssl-tls-https.html " target="_blank">견고한 웹 서비스 만들기</a>
- <a href="https://aws-hyoh.tistory.com/39 " target="_blank">네트워크엔지니어환영의기술블로그</a>
- <a href="https://velog.io/@developerwan/TLS-1.2%EC%97%90%EC%84%9C-%ED%95%B8%EB%93%9C-%EC%89%90%EC%9D%B4%ED%81%AC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C " target="_blank">developerwan</a>
- <a href="https://sunrise-min.tistory.com/entry/TLS-Handshake는-어떻게-진행되는가" target="_blank">내가보기위한기록</a>
- <a href="https://docs.netapp.com/ko-kr/e-series/vcenter-plugin/vc-olh-use-ca-signed-certificates.html" target="_blank">NetApp</a>
- <a href="https://www.digicert.com/kr/faq/code-signing-trust/what-is-code-signing" target="_blank">digicert</a>
- <a href="https://docs.netapp.com/ko-kr/e-series/vcenter-plugin/vc-olh-use-ca-signed-certificates.html" target="_blank">NetApp</a>
- <a href="https://guide.ncloud-docs.com/docs/privateca-info" target="_blank">ncloud</a>
- <a href="https://www.digicert.com/kr/faq/compliance/what-is-a-certificate-authority-ca" target="_blank">digicert2</a>

HTTPS와 TLS 핸드셰이크의 상세한 과정 및 관련 개념들

HTTPS와 TLS에 대해

# HTTP/2

## HTTP/2 개요

- HTTP/2는 HTTP/1.1의 단점을 보완하고 새로운 기능을 추가하여 웹 성능을 향상 시키기 위해 개발된 프로토콜이다. 이는 구글의 SPDY 프로토콜을 기반으로 표준화되었다.

- HTTP/2는 TCP 프로토콜 위에서 동작하며, 여러 개의 데이터 요청을 하나의 TCP 연결을 통해 병렬로 전송할 수 있는 멀티플렉싱을 지원한다.
## HTTP/2 장점

- **멀티플렉싱**: 여러 개의 요청과 응답을 하나의 TCP 연결에서 동시에 전송할 수 있어, Head-of-Line Blocking(HOLB) 문제를 부분적으로 해결한다. 이는 여러 스트림을 통해 데이터를 전송할 수 있게 해준다.

- **헤더 압축**: HTTP 메시지의 헤더를 압축하여 전송하는 HPACK 알고리즘을 사용한다. 이는 중복되는 헤더 값을 테이블에 저장하고 참고하는 방식으로, 헤더의 크기를 줄여준다.

- **바이너리 프로토콜**: 텍스트 프로토콜에서 바이너리 프로토콜로 전환되어, 명령어를 더 단순하게 구현할 수 있다.

- **서버 푸시**: 서버는 요청되지 않았지만 향후 요청에서 예상되는 추가 정보를 클라이언트에 전송할 수 있다.
## HTTP/2 단점

- **TCP의 한계**: TCP 프로토콜을 사용하기 떄문에, TCP의 핸드셰이크 과정과 패킷 손실에 따른 재전송 지연 등이 여전히 존재한다. 이는 HOLB 문제를 완전히 해결하지 못 한다.

- **패킷 손실**: 하나의 TCP 연결에서 여러 개의 스트림이 동작하기 때문에, 패킷 손실이 발생하면 전체 연결이 영향을 받을 수 있다.

---
# HTTP/3

## HTTP/3 개요

- HTTP/3은 HTTP/2의 장점들을 유지하면서 TCP가 가지는 원초적인 단점을 보완하기 위해 개발된 프로토콜이다. HTTP/3은 QUIC(Quick UDP Internet Connections)프로토콜을 기반으로 한다.

- QUIC는 UDP를 사용하여 통신하며, 이는 TCP의 핸드셰이크 과정과 패킷 손실에 따른 재전송 지연을 줄이는 데 중점을 두었다.
## HTTP/3 장점

- **QUIC 기반**: UDP를 사용하여 통신하기 때문에, TCP의 핸드셰이크 과정과 HOLB 문제를 완전히 해결할 수 있다. 이는 연결 설정에 필요한 정보와 데이터를 첫 전째 핸드셰이크 때 함께 보내서 RTT(Round Trip Time)를 줄인다.

- **빠른 패킷 손실 감지**: QUIC는 패킷 손실을 빠르게 감지하고 재전송할 수 있어, 전반적인 통신 속도를 향상시킨다.

- **연결 유지**: 사용자 IP가 변경되더라도 연결을 유지할 수 있다.

- **보안 강화**: QUIC 내에 TLS가 기본적으로 포함되어 있어, 헤더 영역도 암호화 된다.
## HTTP/3 단점

- **도입 초기 단계**: 현재 HTTP/3은 아직 도입 초기 단계에 있으며, 더 많은 수정과 발전이 필요하다.

- **인프라 의존성**: 통신 인프라가 빈약한 지역에서는 큰 차이를 느낄 수 있지만, 잘 발달된 통신 인프라를 가진 지역에서는 체감할 수 있는 차이가 적을 수 있다.

---
# 주요 차이점

## 전송 프로토콜

- HTTP/2: TCP를 사용한다.

- HTTP/3: UDP를 기반으로 하는 QUIC 프로토콜을 사용한다.
## HOLB 문제

- HTTP/2: HOLB 문제를 부분적으로 해결하지만, TCP의 한계로 인해 완전히 해결하지 못 한다.

- HTTP/3: QUIC을 통해 HOLB 문제를 완전히 해결한다.
## 핸드셰이크 과정:

- HTTP/2: TCP와 TLS의 핸드셰이크 과정으로 인해 3RTT가 필요하다.

- HTTP/3: 첫 번째 핸드셰이크 때 연결 설정에 필요한 정보와 데이터를 함께 보내서 1RTT로 줄인다.
## 패킷 손실 대응:

- HTTP/2: TCP의 재전송 메커니즘으로 인해 패킷 손실이 발생하면 전체 연결이 영향 받을 수 있다.

- HTTP/3: QUIC를 통해 빠르게 패킷 손실을 감지하고 재전송할 수 있다.

---

# 추가로 알면 좋은 것들

## 멀티플레싱과 스트림:

- HTTP/2와 HTTP/3 모두 멀티플렉싱을 지원하여 여러 개의 요청과 응답을 하나의 연결에서 동시에 전송할 수 있다.

그러나 HTTP/3은 독립 스트림 방식으로 더 강화된 멀티플렉싱을 제공한다.

## 보안:

- HTTP/3은 QUIC 내에 TLS가 기본적으로 포함되어 있어, 보안을 더욱 강화한다.
## HTTPS:

- HTTP/2와 HTTP/3 모두 HTTPS를 필수로 사용한다. 따라서 보안 인증서 관리가 중요하다.

---
### 블로그 내 관련 문서
- [[HTTPS와 TLS]]

---
### 참고 자료
출처 : 
- <a href="https://woojinger.tistory.com/85" target="_blank">woojinger</a>
- <a href="https://inpa.tistory.com/entry/WEB-🌐-HTTP-30-통신-기술-이제는-확실히-이해하자#" target="_blank">inpa</a>
- <a href="https://github.com/dongkyun-dev/TIL/blob/master/web/HTTP1.1과%20HTTP2.0,%20그리고%20간단한%20HTTP3.0.md" target="_blank">dongkyun</a>
- <a href="https://evan-moon.github.io/2019/10/08/what-is-http3/" target="_blank">evan</a>
- <a href="https://blog.cloudflare.com/ko-kr/http3-the-past-present-and-future/" target="_blank">cloudflare</a>
- <a href="https://www.saturnsoft.net/network/2019/03/26/quic-http3-2/" target="_blank">saturnsoft</a>
- <a href="https://web.dev/articles/performance-http2?hl=ko" target="_blank">web.dev</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview" target="_blank">mozilla</a>

HTTP2와 HTTP3

## 로컬스토리지

로컬스토리지는 웹 브라우저 내에 데이터를 key: value 형식으로 저장하는 웹 스토리지 API의 한 부분이다. 이 데이터는 브라우저 세션이 종료되어도 유지되며, 사용자가 명시적으로 삭제하지 않는 한 지속된다.

### 로컬스토리지의 주요 특징
- 영구성: 브라우저를 닫아도 데이터가 사라지지 않는다.
- 키-값 쌍 저장: 모든 데이터는 UTF-16 문자열 형식으로 저장된다.
- 오리진 기반 접근: 동일한 오리진(프로토콜, 호스트, 포트 조합)에서만 데이터에 접근할 수 있다. 이는 보안상의 이유로 다른 도메인 간의 데이터 접근을 방지한다.
### 로컬 스토리지의 장점
- 데이터 지속성: 세션 종료 후에도 데이터를 유지할 수 있어 사용자 경험을 개선할 수 있다.
- 간편한 사용법: 간단한 API로 데이터를 저장, 조회, 삭제할 수 있다.
### 로컬 스토리지의 단점
- 보안 문제: 사용자가 브라우저 개발자 도구를 통해 데이터를 볼 수 있어 민감한 정보 저장에 적합하지 않다.
- 오리진 제한: 다른 도메인에서는 접근할 수 없으므로, 여러 도메인에서 공유해야 하는 데이터에는 부적합하다.

---

## 오리진

오리진은 URL의 프로토콜, 호스트 및 포트 조합을 의미한다. 로컬스토리지는 이 오리진을 기준으로 데이터를 격리하여 보관한다. 즉, 같은 오리진에서만 로컬스토리지에 접근할 수 있다.

### 오리진의 정의
오리진은 URL의 세 가지 요소로 정의된다.

- 프로토콜 (예: HTTP, HTTPS)
- 호스트명 (예: example.com)
- 포트 번호 (예: 80, 443)

이 세 요소가 모두 동일해야만 두 URL이 같은 오리진으로 간주된다.

#### 예시
- 같은 오리진:
	- 동일 프로토콜, 호스트, 포트 : `https://example.com/page1` → `https://example.com/page2` = O
- 다른 오리진:
	- 다른 프로토콜 : `https://example.com` → `http://example.com` = X
	- 다른 호스트 : `https://example.com` → `https://other.com` = X
	- 다른 포트 : `https://example.com` → `https://example.com:8080` = X


### 오리진 주요개념
- 오리진 격리: 각 오리진은 독립적인 스토리지 공간을 가진다. 이를 통해 도메인 간의 데이터 침해를 방지한다.
- 프로토콜 차이: HTTP와 HTTPS는 다른 오리진으로 간주되므로, 같은 도메인이라도 프로토콜이 다르면 로컬스토리지에 접근할 수 없다.

### 오리진의 중요성
1. 보안 정책: 오리진은 웹 보안의 핵심인 동일 출처 정책(Same-Origin Policy)의 기반이 된다. 이 정책은 한 오리진에서 로드된 문서나 스크립트가 다른 오리진의 리소스와 상호작용하는 것을 제한한다. 이는 악성 스크립트가 다른 사이트의 민감한 데이터에 접근하지 못 하도록 막는다.
2. 데이터 격리: 각 오리진은 독립적인 스토리지 공간을 가지며, 로컬스토리지나 세션스토리지 같은 웹 스토리지 API는 이 오리진을 기준으로 데이터를 저장한다. 따라서 다른 오리진에서는 이러한 데이터 접근할 수 없다.
3. 신뢰 관계: 오리진은 신뢰할 수 있는 리소스를 식별하는 데 사용된다. 예를 들어, HTML 문서에서 특정 스크립트를 실행할 때 해당 스크립트의 URI를 통해 신뢰 관계를 설정한다.

### 오리진 핵심 사항
- 오리진 비교: 두 URI가 같은 오리진인지 확인하려면 프로토콜, 호스트명, 포트 번호가 모두 일치해야 한다.
- 보안 강화: 프로토콜을 포함하여 오리진을 정의하는 것은 보안을 위해 필수적이다. 예를 들어,  [http://example.com과](http://example.xn--com-rg8l/) [https://example.com은](https://example.xn--com-7e0o/) 다른 오리진으로 간주된다.
- 동일 출처 정책: 이 정책은 브라우저가 한 페이지의 스크립트가 다른 페이지의 DOM에 접근하는 것을 제한하여 보안을 강화한다.
- CORS(Cross-Origin Resource Sharing): 동일 출처 정책의 제한을 완화하기 위해 사용되며, 서버가 다른 오리진에서 오는 요청을 허용할 수 있도록 한다.
- 오리진 변경: 일부 경우에는 'document.domain'을 설정하여 오리진을 변경할 수 있지만, 이는 보안상의 이유로 권장되지 않는다.

---

블로그 내 관련 문서
- [[로컬스토리지의 개념]]

---
### 참고 자료
출처 :
- <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage" target="_blank">mdn</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API" target="_blank">mdn2</a>
- <a href="https://www.rfc-editor.org/rfc/rfc6454" target="_blank">rfc</a>
- <a href="https://developer.mozilla.org/en-US/docs/Glossary/Origin" target="_blank">mdn3</a>
- <a href="https://auth0.com/blog/secure-browser-storage-the-facts/" target="_blank">auth0</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy?li_fat_id=bf90e1c3-40c1-4dfd-9935-d72f26d934c2" target="_blank">mdn4</a>
- <a href="https://dev.to/luwadev/handling-browser-storage-cookies-local-storage-session-storage-33h9" target="_blank">dev.to</a>

오리진과 로컬스토리지의 관계

로컬스토리지와 오리진

## 로컬 스토리지 (Local Storage) 개요

로컬 스토리지는 웹 스토리지 API의 핵심 구성 요소 중 하나로, 웹 애플리케이션이 사용자의 브라우저에 데이터를 저장할 수 있게 해주는 메커니즘이다. 로컬 스토리지는 브라우저 세션 간에 데이터를 유지하며, 브라우저가 닫히고 다시 열린 후에도 데이터가 보존된다.

---
## 로컬 스토리지 주요 특징

1. **영구성**: 로컬 스토리지에 저장된 데이터는 사용자가 브라우저를 닫거나 컴퓨터를 재시작해도 유지된다. 이는 세션 스토리지와의 주요 차이점이다.
2. **용량**: 로컬 스토리지는 일반적으로 최소 5MB의 저장 공간을 제공한다. 이는 쿠키(대개 4KB)보다 훨씬 큰 용량이다.
3. **도메인 특정성**: 로컬 스토리지는 도메인 및 프로토콜 특정적이다. 즉, 한 도메인에서 저장한 데이터는 다른 도메인에서 접근할 수 없다.
4. **문자열 기반**: 로컬 스토리지는 키-값 쌍으로 데이터를 저장하며, 모든 값은 문자열로 저장된다.

---
## 사용 방법

로컬 스토리지는 다음과 같은 주요 메서드를 제공한다:

```javascript
// 데이터 저장 
localStorage.setItem('key', 'value'); 

// 데이터 검색 
const value = localStorage.getItem('key'); 

// 데이터 삭제 
localStorage.removeItem('key'); 

// 모든 데이터 삭제 
localStorage.clear();
```

---
## 고급 사용 사례

1. **JSON 데이터 저장**: 객체나 배열을 저장할 때는 JSON.stringify()를 사용하여 문자열로 변환해야 한다. 검색 시에는 JSON.parse()를 사용하여 다시 객체로 변환할 수 있다.
2. **스토리지 이벤트**: 다른 탭이나 창에서 스토리지가 변경될 때 'storage' 이벤트가 발생한다. 이를 활용하여 실시간으로 데이터 변경을 감지할 수 있다.
3. **프라이빗 브라우징**: 프라이빗 모드에서는 로컬 스토리지가 세션 스토리지처럼 동작할 수 있다.
4. **용량 초과 처리**: 스토리지 용량을 초과할 경우 QuotaExceededError가 발생할 수 있으므로, 이를 적절히 처리해야 한다.

---
## 보안 고려사항

1. **민감한 정보 저장 금지**: 암호나 개인식별정보와 같은 민감한 데이터는 로컬 스토리지에 저장하지 않아야 한다.
2. **XSS 공격 대비**: 저장된 데이터를 사용하기 전에 항상 유효성을 검사해야 한다.
3. **HTTPS 사용**: 데이터 전송 시 암호화를 위해 HTTPS를 사용해야 한다.

> [!faq]- XSS란?
> XSS는 웹 애플리케이션의 취약점을 이용한 공격 방식이다.

### XSS

#### XSS주요 특징:
- 악성 스크립트를 신뢰할 수 있는 웹사이트에 주입하는 공격이다.
- 공격자가 사용자의 브라우저에서 스크립트를 실행하게 만든다.
- 사용자의 쿠키, 세션 토큰 등 민감한 정보를 탈취할 수 있다.

#### XSS의 공격 유형:
1. Reflected XSS: 악성 URL을 통해 즉시 반사되는 공격
2. Stored XSS: 서버에 악성 스크립트를 저장하여 나중에 실행하는 공격
3. DOM-based XSS: 클라이언트 측 스크립트의 취약점을 이용한 공격

---
## 로컬 스토리지 vs 세션 스토리지 vs 쿠키

### 지속성
- 로컬스토리지: 영구적
- 세션스토리지: 탭/창 종료 시 삭제
- 쿠키: 설정된 만료 기간에 따라 다름
### 용량
- 로컬스토리지: 일반적으로 5MB
- 세션스토리지: 일반적으로5MB
- 쿠키: 4KB
### 서버 통신
- 로컬스토리지: 클라이언트 측에만 존재
- 세션스토리지: 클라이언트 측에만 존재
- 쿠키: 매 HTTP 요청마다 서버로 전송 됨

---

## 다른 저장 방식 비교

로컬 스토리지는 웹 애플리케이션에서 클라이언트 측 데이터 저장을 위한 강력하고 유용한 도구이다. 
그러나 보안 고려사항과 사용 제한을 잘 이해하고 적절히 사용하는 것이 중요하다. 대규모 애플리케이션이나 복잡한 데이터 구조를 다룰 때는 IndexedDB와 같은 다른 클라이언트 측 저장 옵션도 함께 고려해볼 수 있다.

### IndexedDB과 비교
- 복잡성: 로컬 스토리지는 간단한 키-값 저장소인 반면, IndexedDB는 `더 복잡한 구조화된 데이터`를 저장할 수 있다.
- 비동기 작업: IndexedDB는 비동기적으로 작동하여 대량의 데이터 처리에 더 적합할 수 있다.

### IndexedDB의 저장 방식
IndexedDB는 브라우저에 내장된 NoSQL 데이터베이스로, 복잡한 구조의 데이터를 저장할 수 있다.
#### IndexedDB의 주요특징
- 키-값 저장소 방식을 사용한다.
- 객체 저장소(Object Store)를 통해 데이터를 구조화한다.
- 트랜잭션을 지원하여 데이터 무결성을 보장한다.

#### IndexedDB 데이터 저장 예시
```html

<!DOCTYPE html>
<html lang="ko">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>IndexedDB 테스트</title>
</head>
<body>
	<h1>IndexedDB 테스트</h1>
	<div id="result"></div>
	<script src="test.js"></script>
</body>
</html>
```


```javascript
// test.js
let db;
const request = indexedDB.open("MyDatabase", 1);

request.onupgradeneeded = (event) => {
	db = event.target.result;
	const objectStore = db.createObjectStore("users", { keyPath: "id" });
	objectStore.createIndex("name", "name", { unique: false });
	objectStore.createIndex("email", "email", { unique: true });
};

request.onsuccess = (event) => {
	db = event.target.result;
	const transaction = db.transaction(["users"], "readwrite");
	const objectStore = transaction.objectStore("users");

	const user = {
		id: 1,
		name: "YDK",
		email: "DDUCK@example.com",
		age: 26,
		address: {
			street: "얼음길",
			city: "심시티",
			country: "대한민국"
		},
		hobbies: ["책싫어요", "멍때리기", "하늘바라보기"]
	};
	
	const addRequest = objectStore.add(user);

	addRequest.onsuccess = () => {
		document.getElementById('result').textContent = '사용자가 성공적으로 추가되었습니다.';
		};

	addRequest.onerror = () => {
		document.getElementById('result').textContent = '사용자 추가 중 오류가 발생했습니다.';
		};
};

request.onerror = (event) => {
	document.getElementById('result').textContent = 'IndexedDB를 열 수 없습니다: ' + event.target.error;
};
```

vscode와 같은 코드 에디터를 사용한다면 live server와 같은 확장 프로그램을 이용해 쉽게 브라우저에서 위 코드를 실행시킬 수 있다. IndexedDB는 브라우저 API이기 때문에 브라우저에서 실행 시키는게 편하다.
1. 실행 브라우저로 이동
2. 개발자 도구 열기
3. Application 탭으로 이동
4. 왼쪽 사이드바에서 "IndexedDB" 클릭
5. "MyDatabase" 클릭 후 "users" 객체 저장소 클릭 하면 저장된 데이터 확인 가능

IndexedDB는 중첩된 객체와 배열을 포함한 JavaScript 객체를 그대로 저장할 수 있어, 관계형 데이터베이스 보다 더 유연한 데이터 모델을 제공한다.

---
### 블로그 내 관련 문서
- [[HTTPS와 TLS]]

---
### 참고 자료
출처 : 

- <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage" target="_blank">mdn</a>
- <a href="https://www.geeksforgeeks.org/difference-between-local-storage-session-storage-and-cookies/" target="_blank">geeksforgeeks</a>
- <a href="https://dev.to/eddiemuhoro/understanding-session-storage-local-storage-and-cookies-in-web-development-1i14" target="_blank">dev.to</a>
- <a href="https://www.w3schools.com/html/html5_webstorage.asp" target="_blank">w3schools</a>
- <a href="https://www.freecodecamp.org/news/web-storage-localstorage-vs-sessionstorage-in-javascript/" target="_blank">freecodecamp</a>
- <a href="https://www.freecodecamp.org/news/web-storage-api-how-to-store-data-on-the-browser/" target="_blank">freecodecamp-2</a>
- <a href="https://www.freecodecamp.org/news/use-local-storage-in-modern-applications/" target="_blank">freecodecamp-3</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API" target="_blank">mdn-2</a>
- <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local" target="_blank">mdn-3</a>
- <a href="https://developers.google.com/privacy-sandbox/cookies/storage-partitioning?hl=ko" target="_blank">developers.google</a>
- <a href="https://owasp.org/www-community/attacks/xss/" target="_blank">owasp</a>
- <a href="https://www.telerik.com/blogs/beginners-guide-indexeddb" target="_blank">telerik</a>
- <a href="https://web.dev/articles/indexeddb?hl=ko" target="_blank">web.dev</a>
- <a href="https://ko.javascript.info/indexeddb" target="_blank">javascript.info</a>

로컬스토리지의 개념에 대해 알아보기

로컬스토리지의 개념

## 리프레시 토큰

리프레시 토큰(Refresh Token)은 액세스 토큰이 만료 되었을 때, 클라이언트가 새로 로그인하지 않고도 새로운 액세스 토큰을 발급받기 위한 용도로 사용된다.

### 만료된 토큰 처리
JWT는 만료 시간이 지나면 더 이상 유효하지 않기 때문에, 만료된 토큰을 처리하는 로직이 필요하다. 이를 위해 리프레시 토큰(Refresh Token)을 사용하는 방법이 일반적이다.

### 리프레시 토큰 사용 흐름
- 엑세스 토큰: 짧은 유효기간을 가지며, 만료되면 클라이언트는 서버로부터 새로운 액세스 토큰을 발급 받아야 한다.
- 리프레시 토큰: 더 긴 유효기간을 가지며, 액세스 토큰이 만료 되었을 때, 클라이언트가 서버에 리프레시 토큰을 보내어 새로운 액세스 토큰을 발급받는다.


### 구현 방법
리프레시 토큰을 구현하기 위해서는:
1. 액세스 토큰과 라프레시 토큰을 함께 발급.
2. 리프레시 토큰을 저장하고, 액세스 토큰이 만료되었을 때 이를 통해 새로운 액세스 토큰을 발급하는 라우트를 추가.


---
## 코드 예시

### 서버코드(app.js)
```javascript
const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');
const path = require('path');

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());
app.use(express.static('public'));

const ACCESS_TOKEN_SECRET = 'accessTokenSecret';
const REFRESH_TOKEN_SECRET = 'refreshTokenSecret';

// 리프레시 토큰 저장소 (실제 구현에서는 데이터베이스를 사용해야 한다)
const refreshTokens = new Set();

// 사용자 데이터베이스 (예시)
const users = {
	'user1': 'password1',
	'user2': 'password2'
};

// 로그인 페이지 라우트
app.get('/login', (req, res) => {
	res.sendFile(path.join(__dirname, 'public', 'login.html'));
});

// 로그인 처리 (POST 요청)
app.post('/login', (req, res) => {
	const { username, password } = req.body;
	if (users[username] && users[username] === password) {
		const accessToken = generateAccessToken(username);
		const refreshToken = generateRefreshToken(username);
		refreshTokens.add(refreshToken);
		res.json({ accessToken, refreshToken });
	} else {
		res.status(401).send('로그인 실패! 사용자 이름 또는 비밀번호가 잘못되었습니다.');
	}
});

// 액세스 토큰 생성 함수
function generateAccessToken(username) {
	return jwt.sign({ username }, ACCESS_TOKEN_SECRET, { expiresIn: '1m' });
}

// 리프레시 토큰 생성 함수
function generateRefreshToken(username) {
	return jwt.sign({ username }, REFRESH_TOKEN_SECRET, { expiresIn: '7d' });
}

// 토큰 갱신 엔드포인트
app.post('/token', (req, res) => {
	const { refreshToken } = req.body;
	console.log('리프레시 토큰 요청 받음:', refreshToken);
	if (!refreshToken || !refreshTokens.has(refreshToken)) {
		console.log('유효하지 않은 리프레시 토큰');
		return res.status(403).json({ error: '유효하지 않은 리프레시 토큰입니다.' });
	}

	jwt.verify(refreshToken, REFRESH_TOKEN_SECRET, (err, user) => {
		if (err) {
			console.log('리프레시 토큰 검증 실패:', err);
			return res.status(403).json({ error: '리프레시 토큰 검증 실패' });
		}

	const accessToken = generateAccessToken(user.username);
		console.log('새 액세스 토큰 생성:', accessToken);
		res.json({ accessToken });
	});
});

// 로그아웃 처리
app.post('/logout', (req, res) => {
	const { refreshToken } = req.body;
	refreshTokens.delete(refreshToken);
	res.sendStatus(204);
});

// 대시보드 페이지 라우트 (HTML 파일 제공)
app.get('/dashboard', (req, res) => {
	res.sendFile(path.join(__dirname, 'public', 'dashboard.html'));
});

// 대시보드 API 엔드포인트 (인증 필요)
app.get('/api/dashboard', authenticateToken, (req, res) => {
	res.json({ message: `환영합니다, ${req.user.username}님!` });
});

// 미들웨어: 액세스 토큰 검증
function authenticateToken(req, res, next) {
	const authHeader = req.headers['authorization'];
	const token = authHeader && authHeader.split(' ')[1];

	if (!token) {
		return res.status(401).json({ error: '액세스 토큰이 필요합니다.' });
	}

	jwt.verify(token, ACCESS_TOKEN_SECRET, (err, user) => {
		if (err) {
		return res.status(403).json({ error: '유효하지 않은 액세스 토큰입니다.' });
	}
	req.user = user;
	next();
	});
}

app.listen(3000, () => {
	console.log('서버가 http://localhost:3000 에서 실행 중입니다.');
});
```

### 로그인페이지(public/login.html)
```html
<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>로그인</title>
</head>

<body>
	<h2>로그인</h2>
	<form id="loginForm">
		<label>사용자 이름:</label>
		<input type="text" id="username" />
		<label>비밀번호:</label>
		<input type="password" id="password" />
		<button type="submit">로그인</button>
	</form>

<script>
	document.getElementById('loginForm').addEventListener('submit', async function(event) {
		event.preventDefault();
		const username = document.getElementById('username').value;
		const password = document.getElementById('password').value;

	try {
		const response = await fetch('/login', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ username, password })
		});

		if (!response.ok) {
			throw new Error('로그인 실패');
		}

		const data = await response.json();

		// 액세스 토큰과 리프레시 토큰을 로컬 스토리지에 저장
		localStorage.setItem('accessToken', data.accessToken);
		localStorage.setItem('refreshToken', data.refreshToken);

		alert('로그인 성공! 대시보드로 이동합니다.');
		window.location.href = '/dashboard.html';
	} catch (error) {
		alert(error.message);
	}
});
</script>
</body>
</html>
```


### 대시보드페이지(public/dashboard)
```html
<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>대시보드</title>
</head>

<body>
	<h2>대시보드</h2>
	
	<button id="logoutButton">로그아웃</button>

	<script>
		async function loadDashboard() {
			const accessToken = localStorage.getItem('accessToken');
			const refreshToken = localStorage.getItem('refreshToken');
			
			if (!accessToken || !refreshToken) {
				console.log('토큰이 없습니다. 로그인 페이지로 이동합니다.');
				window.location.href = '/login.html';
				return;
			}

		try {
			const response = await fetch('/api/dashboard', {
				method: 'GET',
				headers: {
					'Authorization': 'Bearer ' + accessToken
				}
			});

			if (response.status === 403) {
				console.log('액세스 토큰이 만료되었습니다. 새 토큰을 요청합니다.');
				const newAccessToken = await refreshAccessToken(refreshToken);
				if (newAccessToken) {
					console.log('새 액세스 토큰을 받았습니다. 대시보드를 다시 로드합니다.');
					localStorage.setItem('accessToken', newAccessToken);
					return loadDashboard(); // 새로운 액세스 토큰으로 다시 시도
				}
			}

			if (!response.ok) {
				throw new Error('대시보드 접근 실패');
			}

			const data = await response.json();
			console.log('대시보드 로드 성공:', data.message);
			document.getElementById('welcomeMessage').innerText = data.message;
		} catch (error) {
			console.error('오류 발생:', error.message);
			alert(error.message);
			window.location.href = '/login.html';
		}
	}

	async function refreshAccessToken(refreshToken) {
		try {
			const response = await fetch('/token', {
				method: 'POST',
				headers: { 'Content-Type': 'application/json' },
				body: JSON.stringify({ refreshToken })
			});

			if (!response.ok) {
				throw new Error('토큰 갱신 실패');
			}

			const data = await response.json();
			return data.accessToken;
		} catch (error) {
			console.error('리프레시 토큰 사용 실패:', error);
			return null;
		}
	}

	document.getElementById('logoutButton').addEventListener('click', async () => {
		const refreshToken = localStorage.getItem('refreshToken');
		try {
			await fetch('/logout', {
				method: 'POST',
				headers: { 'Content-Type': 'application/json' },
				body: JSON.stringify({ refreshToken })
			});
			localStorage.removeItem('accessToken');
			localStorage.removeItem('refreshToken');
			window.location.href = '/login.html';
		} catch (error) {
			console.error('로그아웃 실패:', error);
		}
	});
	loadDashboard();
	</script>
</body>
</html>
```

---
## 부분 설명

### 리프레시 토큰 저장소
```javascript
const refreshTokens = new Set();
```
- app.js에서 주석으로 표시한 것과 같이, 실제 서비스에서는 데이터베이스에 저장하는 것이 좋다고 한다.

### 새로운 액세스 토큰 발급 라우트
```javascript
async function refreshAccessToken(refreshToken) {
	try {
		const response = await fetch('/token', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ refreshToken })
		});
```

- 클라이언트는 `/token` 경로로 POST 요청을 보내며, 본문에 리프레시 토큰을 포함해야 한다.
- 서버는 해당 리프레시 토큰이 유효한지 확인하고, 유효하다면 새로운 액세스 토큰을 발급한다.

### 로그아웃 처리
```javascript
try {
	await fetch('/logout', {
		method: 'POST',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ refreshToken })
	});
	localStorage.removeItem('accessToken');
	localStorage.removeItem('refreshToken');
```

- 클라이언트가 로그아웃할 때 `/logout` 경로로 POST 요청을 보내며 본문에 리프레시 토큰을 포함한다.
- 서버는 해당 리프레시 토큰을 삭제하여 더 이상 사용할 수 없도록 한다.

---


### 블로그 내 관련 문서
- [[토큰 기반 인증]]

---
### 참고 자료
출처 :
- <a href="https://developer.okta.com/docs/guides/refresh-tokens/main/" target="_blank">okta</a>
- <a href="https://www.descope.com/learn/post/refresh-token" target="_blank">descope</a>
- <a href="https://auth0.com/learn/refresh-tokens" target="_blank">auth0</a>
- <a href="https://auth0.com/docs/secure/tokens/refresh-tokens" target="_blank">auth0 by Okta</a>

엑세스 토큰이 만료되었을 때, 새로운 토큰 발급받기

리프레시 토큰 사용 방법

## 세션 기반 인증이란?

세션 기반 인증은 사용자가 웹 사이트에 로그인할 때, 서버에서 세션(session)을 생성하고 이를 통해 사용자의 인증 상태를 유지하는 방식이다. 세션은 서버 측에서 관리되며, 클라이언트는 서버로부터 받은 세션 ID를 쿠키에 저장하여 이후의 요청마다 이 세션 ID를 함께 전송함으로써 인증 상태를 유지한다.

### 왜 필요하지?
HTTP의 특징 중 하나는 무상태(Stateless) 하다는 것이다. 그렇기에 HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는 특징이 있다. 
따라서 "로그인 상태를 어떻게 유지하는가"에 대한 의문점이 생기기 마련이다. 로그인은 이전에 로그인한 상태값이 남아 있어야 하기 때문이다. 예를 들어, 메인 페이지에서 로그인을 한 뒤 페이지를 이동했을 때 로그인이 유지되지 않고 다시 로그인 해야 한다면 매우 귀찮아질 것 이다.

### 동작 원리
1. 로그인 요청: 사용자가 로그인 폼을 통해 자격 증명(예: 사용자 이름, 비밀번호)을 서버로 제출한다.
2. 자격 증명 확인: 서버는 데이터베이스에서 사용자의 자격 증명을 확인한다.
3. 세션 생성: 자격 증명이 유효하면 서버는 고유한 세션 ID를 생성하고, 이 세션 ID와 함께 사용자 정보를 서버 측 세션 스토리지에 저장한다.
4. 세션 ID 전달: 서버는 클라이언트에게 세션 ID를 쿠키에 담아 전달한다.
5. 요청 시 세션 ID 전송: 이후 클라이언트는 모든 요청에 세션 ID를 포함시켜 서버로 전송하며, 서버는 이 세션 ID를 확인하여 해당 사용자의 인증 상태를 유지한다.
6. 세션 만료/로그아웃: 세션은 일정 시간이 지나면 만료되거나, 사용자가 명시적으로 로그아웃하면 삭제된다.

#### 세션, 세션ID
- 세션: 
	- 세션은 사용자가 웹 사이트에 접속한 후부터 로그아웃하거나 브라우저를 닫을 때까지의 일시적인 상태 정보를 말한다.
	- 서버는 사용자의 세션을 통해 로그인 상태나 장바구니 정보 같은 사용자 고유의 데이터를 관리한다.
	- 세션 데이터는 주로 서버 측에서 관리되며, 각 사용자마다 고유한 세션이 생성된다.
- 세션ID: 
	- 세션 ID는 각 사용자의 세션을 식별하기 위한 고유한 값이다.
	- 서버는 사용자가 로그인하면 세션을 생성하고, 고유한 세션 ID를 클라이언트에게 전달한다.
	- 이 세션 ID는 주로 쿠키에 저장되며, 클라이언트가 서버에 요청할 때마다 함께 전송된다. 이를 통해 서버는 해당 클라이언트를 식별하고 그에 맞는 세션 데이터를 제공한다.

### 사용 사례
사용자가 쇼핑몰에 로그인한 후, 페이지 간 이동 시에도 로그인이 유지된다. 이는 각 요청마다 클라이언트가 쿠키에 저장된 세션 ID를 서버로 보내기 때문에 가능하다.

대부분의 전통적인 웹 애플리케이션에서 널리 사용된다. 예를 들어:
- 쇼핑몰 사이트에서 로그인 상태 유지
- 포럼이나 블로그 같은 웹 애플리케이션

---
## 세션 인증의 장단점

### 세션 기반 인증의 장점
1. 단순성: 구현이 비교적 간단하며, 많은 웹 프레임워크에서 기본적으로 지원하는 기능이다.
2. 서버 제어: 세션은 서버 측에서 관리되므로, 서버가 언제든지 특정 세션을 무효화하거나 만료 시킬 수 있다.
3. 복잡한 권한 관리 가능: 세션을 통해 사용자 정보뿐만 아니라 권한 정보도 저장할 수 있어, 복잡한 권한 관리가 가능하다.

### 세션 기반 인증의 단점
1. 서버 부하: 모든 사용자에 대한 세션 정보를 서버가 유지해야 하므로, 많은 사용자가 접속할 경우 서버의 메모리나 스토리지 자원이 많이 소모될 수 있다.
2. 확장성 문제: 세션이 서버에 저장되기 때문에, 여러 대의 서버에서 동일한 세션 정보를 공유하려면 추가적인 설정(예: 세션 클러스터링)이 필요하다.
3. 보안 취약점: 세션 ID가 탈취되면 공격자가 해당 사용자의 권한을 가질 수 있다. 이를 방지하기 위해 HTTPS를 사용하고, `HttpOnly`, `Secure`, `SameSite` 속성을 설정하여 보안을 강화해야 한다.


---

## 보안 고려 사항

- HTTPS 사용: 세션 ID가 네트워크 상에서 탈취되지 않도록 HTTPS를 통해 암호화된 통신을 해야 한다.
- 쿠키 설정 강화:
	- HttpOnly: 자바스크립트 쿠키에 접근하지 못하게 하여 XSS(크로스 사이트 스크립팅) 공격을 방지한다.
	- Secure: HTTPS 연결에서만 쿠키가 전송되도록 설정한다.
	- SameSite: CSRF(크로스 사이트 요청 위조) 공격을 방지하기 위해 쿠키가 동일 사이트 내에서만 전송되도록 설정한다.
- 세션 만료 시간 설정: 일정 시간 동안 활동이 없으면 자동으로 세션이 만료되도록 설정하여 보안을 강화할 수 있다.

---
## 다른 인증 방식과 비교

| 특성 | 세션 기반 인증(Session-Based Authentication) | 토큰 기반 인증(Token-Based Authentication) |
| ----- | -------------------------------------- | ------------------------------------ |
| 저장 위치 | 서버 측 (세션 스토리지) | 클라이언트 측 (JWT 등 토큰 자체에 정보 포함) |
| 확장성 | 낮음 (서버 상태 유지 필요) | 높음 (서버 상태 불필요) |
| 보안성 | 적절한 설정 시 안전함 | 토큰 탈취 시 위험 (하지만 서명 검증 가능) |
| 복잡도 | 상대적으로 간단 | 상대적으로 복잡 (토큰 발급 및 검증 필요) |

---
## 코드 예시

### 초기화 및 설정
```bash
npm init -y
npm install express express-session body-parser
```

- 'npm init' 명령어로 새로운 Node.js 프로젝트 초기화
- 필요한 패키지 설치
	- express: Node.js에서 서버를 쉽게 구축할 수 있는 프레임워크
	- express-session: 세션 관리를 위한 미들웨어
	- body-parser: POST 요청에서 보낸 데이터를 파싱하기 위한 미들웨어

### 서버 코드(app.js)

```javascript
const express = require('express'); 
const session = require('express-session'); 
const bodyParser = require('body-parser'); 

const app = express(); 

// Body parser 설정 (POST 요청 데이터 파싱) 
app.use(bodyParser.urlencoded({ extended: true })); 

// 세션 설정 
app.use(session({ 
	secret: 'mySecretKey', // 세션을 암호화하기 위한 키 
	resave: false, // 세션이 수정되지 않아도 다시 저장할지 여부 
	saveUninitialized: true, // 초기화되지 않은 세션도 저장할지 여부 
	cookie: { secure: false } // HTTPS가 아닌 경우에도 쿠키를 사용할 수 있도록 설정 
})); 

// 간단한 사용자 데이터베이스 (예시) 
const users = { 
	'user1': 'password1', 
	'user2': 'password2' 
}; 

// 로그인 페이지 
app.get('/login', (req, res) => { 
	res.send(` 
		<h2>로그인</h2> 
		<form method="POST" action="/login"> 
			<label>사용자 이름:</label> 
			<input type="text" name="username" /> 
			<label>비밀번호:</label> 
			<input type="password" name="password" /> 
			<button type="submit">로그인</button> 
		</form> 
	`); 
}); 

// 로그인 처리 
app.post('/login', (req, res) => { 
	const { username, password } = req.body; 
	
	// 사용자 인증 확인 
	if (users[username] && users[username] === password) {
		req.session.user = username; // 세션에 사용자 정보 저장
		res.redirect('/dashboard'); 
	} else { 
		res.send('로그인 실패! 사용자 이름 또는 비밀번호가 잘못되었습니다.'); 
	} 
}); 

// 대시보드 페이지 (로그인된 사용자만 접근 가능) 
app.get('/dashboard', (req, res) => { 
	if (req.session.user) { 
		res.send(`<h2>환영합니다, ${req.session.user}님!</h2><a href="/logout">로그아웃</a>`); 
		} else { res.send('로그인되지 않았습니다. <a href="/login">로그인 페이지로 이동</a>'); 
	} 
}); 

// 로그아웃 처리 
app.get('/logout', (req, res) => { 
	req.session.destroy(); // 세션 삭제 
	res.send('로그아웃 되었습니다. <a href="/login">다시 로그인</a>'); 
}); 

// 서버 실행 
app.listen(3000, () => { 
	console.log('서버가 http://localhost:3000 에서 실행 중입니다.'); 
});
```

### 부분 설명

#### 세션 설정
```javascript
app.use(session({ 
	secret: 'mySecretKey', 
	resave: false, 
	saveUninitialized: true, 
	cookie: { secure: false } 
}));
```

- secret: 세션을 암호화하기 위한 키이다.
- resave: 세션이 수정되지 않아도 매번 저장할지 여부를 설정한다.
- saveUninitialized: 초기화되지 않은 세션도 저장할지 여부를 설정한다.
- cookie.sccure: HTTPS 환경에서만 쿠키를 전송할지 설정한다. 개발 환경에서는 'false'로 설정한다.

#### 로그인 처리
```javascript
app.post('/login', (req, res) => { 
	const { username, password } = req.body; 
	
	// 사용자 인증 확인 
	if (users[username] && users[username] === password) {
		req.session.user = username; // 세션에 사용자 정보 저장
		res.redirect('/dashboard'); 
	} else { 
		res.send('로그인 실패! 사용자 이름 또는 비밀번호가 잘못되었습니다.'); 
	} 
}); 
```

- 사용자가 로그인 폼을 제출하면 서버는 해당 자격 증명을 확인하고, 성공하면 세션에 사용자 정보를 저장한다.


#### 대시보드 접근 제어
```javascript
app.get('/dashboard', (req, res) => { 
	if (req.session.user) { 
		res.send(`<h2>환영합니다, ${req.session.user}님!</h2><a href="/logout">로그아웃</a>`); 
		} else { res.send('로그인되지 않았습니다. <a href="/login">로그인 페이지로 이동</a>'); 
	} 
}); 
```

- 사용자가 대시보드에 접근할 때마다 세션에 저장된 'user' 정보를 확인하여 로그인 여부를 판단한다.


#### 로그아웃 처리
```javascript
app.get('/logout', (req, res) => { 
	req.session.destroy(); // 세션 삭제 
	res.send('로그아웃 되었습니다. <a href="/login">다시 로그인</a>'); 
}); 
```

- 사용자가 로그아웃하면 서버에서 해당 사용자의 세션을 삭제하고 로그아웃 상태로 만든다.


#### 실행
```bash
node app.js
```

1. 브라우저에서 'http://localhost:3000/login' 으로 접속하여 로그인 페이지로 이동한다.
2. 제공된 사용자 목록 중 하나(예: 'user1', 'password1')로 로그인한다.
3. 로그인에 성공하면 대시보드 페이지로 리디렉션된다.
4. 로그아웃 링크를 클릭하면 로그아웃되고 다시 로그인 페이지로 돌아간다.

---
### 블로그 내 관련 문서
- [[캐싱과 쿠키]]
- [[로컬스토리지의 개념]]

---
### 참고 자료
출처 :
- <a href="https://roadmap.sh/guides/session-based-authentication" target="_blank">roadmap.sh</a>
- <a href="https://www.swequiz.com/learn/session-based-authentication" target="_blank">swequiz</a>
- <a href="https://dev.to/emmykolic/cookies-based-authentication-vs-session-based-authentication-1f6" target="_blank">dev.to</a>
- <a href="https://blog.naver.com/PostView.naver?blogId=weekamp&isHttpsRedirect=true&logNo=220931266233" target="_blank">Everybody's On The Run</a>
- <a href="https://masteringbackend.com/posts/authentication-token-based-auth-vs-session-based-auth" target="_blank">masteringbackend</a>
- <a href="https://www.nilebits.com/blog/2023/12/session-based-token-based/" target="_blank">nilebits</a>

사용자가 웹 사이트에 로그인할 때 인증 방식에 대해 알아보자

세션 기반 인증

## 세션스토리지란

세션 스토리지는 웹 브라우저의 Web Storage API 중 하나로, 특정 탭 또는 창에서만 유효한 데이터를 저장하는 클라이언트 측 저장소이다. 세션 스토리지는 페이지 세션이 종료될 때(즉, 탭이나 창을 닫을 때) 자동으로 삭제되며, 오리진(Origin)에 따라 데이터가 격리된다.

### 주요특징
- 세션 단위 데이터 저장: 세션 스토리지는 브라우저 탭이나 창에서만 유효하며, 해당 탭이나 창이 닫히면 데이터가 삭제된다.
- 오리진 기반 격리: 동일한 오리진 내에서만 세션 스토리지에 접근할 수 있다. 즉, 동일한 프로토콜, 호스트명, 포트 번호를 공유하는 페이지들만 이 데이터를 사용할 수 있다.
- 탭/창 별로 독립적: 각 브라우저 탭 또는 창은 자체적인 세션 스토리지 인스턴스를 가진다. 즉, 같은 사이트를 여러 탭에서 열더라도 각 탭의 세션 스토리지 데이터는 서로 공유되지 않는다.

---
## 세션 스토리지 사용법

세션 스토리지는 자바스크립트의 'window.seesionStorage' 객체를 통해 접근할 수 있다. 주로 다음과 같은 메서드를 사용한다.

### 데이터 저장
- sessionStorage.setItem(key, value)
```javascript
sessionStorage.setItem('username', 'orange');
```

위 코드는 'username' 이라는 키에 'orange' 라는 값을 저장한다.

### 데이터 조회
- sessionStorage.getItem(key, value)
```javascript
let username = sessionStorage.getItem('username'); 
console.log(username); // 'orange'
 ```

저장된 데이터를 조회할 때는 'getItem()' 메서드를 사용한다.

### 데이터 삭제
- sessionStorage.removeItem(key)
```javascript
sessionStorage.removeItem('username');
```

특정 키에 저장된 데이터를 삭제할 수 있다.

### 모든 데이터 삭제
- sessionStorage.clear()
```javascript
sessionStorage.clear();
```

세션 스토리지에 저장된 모든 데이터를 삭제한다.

---

## 세션 스토리지의 장단점

### 세션 스토리지의 장점
- 보안성: 세션이 종료되면 자동으로 데이터가 삭제되므로, 민감한 데이터를 임시로 저장하는 데 적합하다.
- 탭/창 별로 독립적: 각 브라우저 탭 또는 창은 독립적인 세션 스토리지를 가지므로, 특정 탭에서 발생한 데이터가 다른 탭에 영향을 미치지 않는다.
- 간단한 API: 자바스크립트에서 간단한 메서드로 데이터를 저장하고 조회할 수 있어 사용이 용이하다.

### 세션 스토리지의 단점
- 데이터 지속성 부족: 브라우저 탭이나 창을 닫으면 데이터가 사라지기 때문에, 장기적으로 데이터를 유지해야 하는 경우에는 적합하지 않다.
- 저장 용량 제한: 일반적으로 약 5MB 정도의 제한이 있어 대용량 데이터를 저장하기에는 한계가 있다.
- 보안 취약점: 세션 스토리지는 클라이언트 측에서 쉽게 접근할 수 있기 때문에, 민감한 정보(예: 비밀번호나 인증 토큰)는 저장하지 않는 것이 좋다.

---
## 세션/로컬 스토리지 비교


| 특성 | 세션스토리지(Session Storage) | 로컬스토리지(Local Storage) |
| ----- | ----------------------- | --------------------- |
| 지속성 | 브라우저 탭/창이 닫힐 때 삭제됨 | 명시적으로 삭제하지 않는 한 영구적 |
| 오리진격리 | 동일 오리진 내에서만 접근 가능 | 동일 |
| 용량제한 | 약 5MB | 약 5MB |
| 데이터접근 | 자바스크립트를 통해 접근 가능 | 동일 |
| 사용사례 | 일시적인 상태 유지(예: 쇼핑 카드) | 사용자 설정이나 테마 등 영구적 데이터 |

## 사용 사례

세션 스토리지는 다음과 같은 상황에서 유용하게 사용된다.
- 쇼핑몰 사이트에서 페이지 간 이동 시 장바구니 상태 유지
- 여러 단계로 나뉜 폼(form) 입력 과정에서 입력값 임시 저장
- 로그인 상태를 유지하지 않고도 특정 페이지에서 사용자 설정을 임시로 저장

### 따라서
세션 스토리지는 특정 브라우저 탭 또는 창에서만 유효한 데이터를 임시로 저장하는 데 매우 유용하다.
특히, 페이지 간 이동 시 일시적인 상태를 유지하거나 민감한 정보를 짧은 시간 동안 안전하게 관리하는 데 적합하다. 다만, 영구적으로 데이터를 유지해야 하는 경우에는 로컬스토리지나 쿠키와 같은 다른 클라이언트 측 저장소를 고려해야 한다.

---

블로그 내 관련 문서
- [[로컬스토리지와 오리진]]

---
### 참고 자료
출처 : 
- <a href="https://dev.to/eddiemuhoro/understanding-session-storage-local-storage-and-cookies-in-web-development-1i14" target="_blank">dev.to</a>
- <a href="https://developer.mozilla.org/ko/docs/Web/API/Window/sessionStorage" target="_blank">mdn</a>
- <a href="https://www.cybrosys.com/blog/an-overview-session-storage-in-javascript" target="_blank">cybrosys</a>
- <a href="https://www.ramotion.com/blog/what-is-web-storage/" target="_blank">ramotion</a>
- <a href="https://www.freecodecamp.org/news/web-storage-localstorage-vs-sessionstorage-in-javascript/" target="_blank">freecodecamp</a>
-

Web Storage API 중 하나인 세션스토리지에 대해

세션스토리지

## 웹브라우저 저장소

캐싱, 쿠키, 세션, 로컬스토리지는 모두 클라이언트 측에서 데이터를 저장하고 관리하는 방식이지만, 저장 위치, 목적, 유효 기간, 보안성 등에서 차이가 있다. 이 4가지 개념을 비교해보자.

### 캐싱(Caching)
캐싱은 웹 페이지나 리소스를 빠르게 로드하기 위해 데이터를 임시로 저장하는 기술이다. 주로 브라우저나 프록시 서버에 저장되며, 이미지 , CSS 파일, JavaScript 파일 등과 같은 정적 리소스를 캐싱하여 페이지 로딩 속도를 향상시킨다.

- 저장 위치: 브라우저나 프록시 서버
- 저장 데이터: 정적 리소스(HTML, CSS, JavaScript 이미지 등)
- 유효 기간: HTTP 헤더(`Cache-Control`, `Expires`)에 의해 설정됨
- 목적: 성능 최적화 (빠른 로드 시간 및 네트워크 트래픽 감소)
- 보안성: 민감한 정보는 캐싱하지 않음 (보통 정적 리소스만 캐싱)

### 쿠키(Cookies)
쿠키는 사용자의 세션 정보나 인증 상태를 유지하기 위해 클라이언트 측에서 작은 데이터를 저장하는 방식이다. 주로 세션 ID와 같은 정보를 저장하여 사용자가 로그인 상태를 유지하거나 사용자 맞춤형 경험을 제공하는데 사용된다.

- 저장 위치: 클라이언트(브라우저) 측
- 저장 데이터: 세션 ID, 사용자 설정(예: 언어 설정), 추적 정보 등
- 유효 기간: 만료 기간 설정 가능 (`Set-Cookie` 헤더로 지정)
- 목적: 세션 관리, 사용자 맞춤형 경험 제공
- 보안성: 민감한 정보는 저장하지 않는 것이 권장됨 (XSS 공격에 취약할 수 있음)


### 세션(Session)
세션은 사용자가 웹사이트에 접속한 후부터 로그아웃하거나 브라우저를 닫을 때까지의 일시적인 상태를 유지하는 기술이다. 세션은 주로 서버 측에서 관리되며, 클라이언트는 서버에서 발급한 고유한 세션 ID를 쿠키에 저장하여 서버와의 상호작용을 유지한다.

- 저장 위치: 서버 측 (세선 데이터는 서버에 저장되고, 세션 ID는 클라이언트의 쿠키에 저장)
- 저장 데이터: 로그인 상태, 장바구니 정보 등
- 유효 기간: 브라우저 탭/창이 닫힐 때까지 또는 명시적으로 로그아웃할 때까지
- 목적: 사용자 상태 관리 (로그인 상태 유지 등)
- 보안성: 상대적으로 안전함 (데이터는 서버에 저장되므로 클라이언트가 직접 접근 불가)

### 로컬스토리지(Local Storage)
로컬스토리지(Local Storage)는 브라우저 내에 데이터를 영구적으로 저장하는 방식이다. 로컬스토리지에 저장된 데이터는 브라우저 탭이나 창을 닫아도 삭제되지 않으며, 사용자가 명시적으로 삭제하지 않는 한 지속된다.
- 저장 위치: 클라이언트(브라우저) 측
- 저장 데이터: 키-값 쌍으로 저장된 문자열 데이터
- 유효 기간: 영구적 (사용자가 삭제하거나 브라우저 캐시가 지워지기 전까지 유지)
- 목적: 영구적인 사용자 데이터 저장 (예: 사용자 설정, 테마 등)
- 보안성: 민감한 정보를 저장하지 않는 것이 좋음 (클라이언트가 쉽게 접근 가능)

---
## 비교 요약

| 특성 | 캐싱(Caching) | 쿠키(Cookies) | 세션(Session) | 로컬스토리지(Local Storage) |
| ------ | ------------------------------------------- | ------------------------------------------ | ------------------------------------------------------- | ---------------------- |
| 저장 위치 | 브라우저 또는 프록시 서버 | 클라이언트(브라우저) | 서버 측(세션 ID는 쿠키로 클라이언트에 저장) | 클라이언트(브라우저) |
| 데이터 유형 | 정적 리소스(HTML, CSS, JS 파일 등) | 세션 ID, 사용자 설정 | 로그인 상태, 장바구니 정보 등 | 키-값 쌍으로 된 문자열 데이터 |
| 유효기간 | HTTP 헤더(`Cache-Control`, `Expires`)로 설정 | 만료 시간 설정 가능 | 브라우저 탭/창이 닫힐 때까지 | 영구적 (명시적으로 삭제할 때까지 유지) |
| 목적 | 성능 최적화 (빠른 로드 시간) | 세션 관리 및 사용자 맞춤형 경험 제공 | 사용자 상태 관리 | 영구적인 사용자 데이터 저장 |
| 보안성 | 민감한 정보는 캐싱 하지 않음 | 민감한 정보는 저장하지 않는 것이 좋음 | 상대적으로 안전함(데이터는 서버에 있음) | 민감한 정보를 저장하지 않는 것이 좋음 |


---

## 따라서

1. 캐싱(Caching): 주로 성능 최적화를 위해 사용되며, 자주 사용하는 정적 리소스를 임시로 저장해 빠르게 접근할 수 있게 한다.
2. 쿠키(Cookies): 주로 세션 관리와 사용자 맞춤형 경험을 제공하기 위한 작은 데이터를 클라이언트 측에 저장한다.
3. 세션(Session): 사용자의 상태를 일시적으로 유지하며, 로그인 상태나 장바구니 정보를 관리하는 데 적합하다.
4. 로컬스토리지((Local Storage): 영구적으로 데이터를 브라우저에 저장하며, 페이지 간 이동이나 브라우저 재시작 후에도 데이터를 유지할 수 있다.

각 기술은 목적과 용도에 따라 다르게 사용되며, 웹 애플리케이션의 요구 사항에 맞게 적절히 선택해야 한다.

---
### 블로그 내 관련 문서
- [[로컬스토리지의 개념]]
- [[세션스토리지]]
- [[캐싱과 쿠키]]

---
### 참고 자료
출처 :
- <a href="https://www.cloudflare.com/ko-kr/learning/cdn/what-is-caching/" target="_blank">cloudflare</a>
- <a href="https://f-lab.kr/insight/understanding-caching-strategies-in-web-development" target="_blank">f-lab</a>
- <a href="https://maker5587.tistory.com/72" target="_blank">maker5587</a>
- <a href="https://developer.mozilla.org/ko/docs/Web/API/Web_Storage_API" target="_blank">mdn</a>
- <a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies" target="_blank">mdn2</a>
- <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching" target="_blank">mdn3</a>

웹 브라우저의 데이터를 저장하고 관리하는 방식을 비교

웹브라우저 저장소 비교

## 캐싱(Caching)

캐싱은 자주 사용하는 데이터를 임시 저장소에 저장하여, 동일한 데이터에 대한 요청이 있을 때 서버에 다시 요청하지 않고 빠르게 접근할 수 있도록 하는 기술이다. 캐시는 웹 페이지의 성능을 크게 향상시키고, 네트워크 트래픽을 줄이며, 서버 부하를 줄이는 데 중요한 역할을 한다.

### 캐싱의 주요 특징
- 속도 향상: 캐시된 데이터를 사용하면 서버에 다시 요청할 필요가 없으므로 응답 속도가 빨라진다.
- 네트워크 트래픽 감소: 동일한 리소스를 반복적으로 다운로드 하지 않기 때문에 네트워크 트래픽이 줄어든다.
- 서버 부하 감소: 서버로의 요청이 줄어들어 서버 자원을 절약할 수 있다.

### 캐시의 종류
1. 브라우저 캐시: 브라우저가 웹 페이지의 리소스(HTML, CSS, 이미지 등)를 로컬에 저장하여, 사용자가 같은 페이지를 다시 방문할 때 빠르게 로드할 수 있도록 한다.
2. 프록시 캐시: 프록시 서버가 중간에서 캐싱하여 여러 사용자가 동일한 리소스를 요청할 때 서버 대신 제공할 수 있다.
3. CDN 캐시: 콘텐츠 전송 네트워크(CDN)가 전 세계 여러 위치에 캐시된 데이터를 저장하여, 사용자에게 더 가까운 서버에서 빠르게 데이터를 제공할 수 있다.

### 캐싱의 동작 방식
- HTTP 헤더 기반 캐싱: 웹 서버는 HTTP 응답 헤더를 통해 브라우저가 리소스를 얼마나 오래 캐시해야 하는지 정의한다.예를 들어,
	- Cache-Control : 캐싱 정책(예: `max-age`, `no-cache`)을 설정하는데 사용된다.
	- ETag : 리소스의 고유 식별자를 사용하여 클라이언트가 가진 캐시가 최신 버전인지 확인하는 데 사용된다.
	- Expires : 리소스가 만료되는 시점을 지정하는 헤더이다.
- 만료된 캐시 갱신: 리소스가 만료되면 브라우저는 서버에 다시 요청하여 최신 버전의 데이터를 받아온다.

### 캐싱의 장단점
#### 캐싱 장점
- 성능 향상: 자주 요청되는 데이터를 캐시에 저장함으로써 응답 시간을 단축하고 서버 부하를 줄일 수 있다.
- 네트워크 비용 절감: 동일한 데이터를 반복적으로 다운로드하지 않으므로 네트워크 트래픽이 감소한다.
- 사용자 경험 개선: 빠른 페이지 로딩 속도로 인해 사용자 경험이 향상된다.

#### 캐싱 단점
- 데이터 최신성 문제: 캐시는 일정 시간 동안 데이터를 유지하기 때문에, 원본 데이터가 변경되었더라도 캐시된 오래된 데이터를 제공할 수 있다. 이를 해결하기 위해 적절한 캐시 만료 정책(TTL)을 설정해야 한다.
- 캐시 무효화: 원본 데이터가 변경되었을 때, 캐시에 저장된 데이터를 무효화하는 과정에서 문제가 발생할 수 있다. 이를 적절히 관리하지 않으면 오래된 데이터가 사용자에게 제공될 수 있다.

---
## 쿠키(Cookies)

쿠키는 클라이언트(사용자)의 브라우저에 작은 데이터를 저장하는 방법이다. 쿠키는 주로 사용자의 세션 상태를 유지하거나, 사용자 정보를 기억하는데 사용된다.

### 쿠키의 주요 특징
- 작은 데이터 저장소: 쿠키는 일반적으로 4KB 이하의 작은 데이터를 저장하는 데 사용된다.
- 서버와 클라이언트 간 데이터 교환: 쿠키는 클라이언트와 서버 간에 주고 받으며, 주로 세션 정보나 사용자 인증 상태를 유지하는 데 사용된다.
- 만료 시간 설정 가능: 쿠키는 만료 시간을 설정할 수 있으며, 만료 시간이 지나면 자동으로 삭제된다.

### 쿠키의 동작 방식
1. 쿠키 생성: 서버는 HTTP 응답 시 `Set-Cookie` 헤더를 통해 클라이언트에게 쿠키를 생성하도록 지시한다.
2. 쿠키 전송: 이후 클라이언트는 해당 도메인으로 요청을 보낼 때마다 쿠키를 함께 전송한다.
3. 쿠키 만료 및 삭제: 쿠키에는 만료 시간이 설정될 수 있으며, 만료 시간이 지나면 브라우저에서 자동으로 삭제된다.

### 쿠키의 사용 사례
- 세션 관리: 사용자 로그인 상태 유지
- 사용자 맞춤 설정 저장: 예를 들어, 다크 모드 설정이나 언어 선택 등을 기억
- 추적 및 분석: 광고 추적이나 웹사이트 방문 기록 분석

### 쿠키의 종류
1. 세션 쿠기(Session Cookie): 브라우저 세션 동안만 유지되며, 브라우저가 닫히면 자동으로 삭제된다.
2. 영구 쿠키(Persistent Cookie): 만료 시간이 설정되어 있으며, 그 시간까지 브라우저에 남아 있다. 예를 들어, 로그인 상태 유지 기능은 영구 쿠키를 통해 구현된다.

### 쿠키의 장단점
#### 쿠키 장점
- 상태 유지: HTTP는 비상태성(stateless) 프로토콜이므로, 쿠키를 사용하여 사용자의 상태(로그인 여부 등)를 유지할 수 있다.
- 개인화된 경험 제공: 사용자 맞춤형 광고나 웹사이트 설정 등을 기억하여 개인화된 경험을 제공한다.

#### 쿠키 단점
- 보안 취약성: 쿠키는 클라이언트 측에서 쉽게 접근할 수 있기 때문에 민감한 정보를 저장하는 데 적합하지 않다. 이를 보완하기 위해 'HttpOnly' 속성을 사용하여 자바스크립트로 접근하지 못하게 하거나, 'Secure' 속성을 통해 HTTPS 연결에서만 전송되도록 할 수 있다.
- 크로스 사이트 공격 위험: 쿠키는 크로스 사이트 스크립팅(XSS)이나 크로스 사이트 요청 위조(CSRF) 공격에 노출될 수 있다. 이를 방지하기 위해 'SameSite' 속성을 활용하여 크로스 오리진 요청 시 쿠키 전송을 제한할 수 있다.

---

## 차이점

| 특성 | 캐싱(Caching) | 쿠키(Cookies) |
| --------- | --------------------------------------- | ----------------------------- |
| 목적 | 리소스 재사용 및 성능 향상 | 세션 상태 유지 및 사용자 정보 저장 |
| 데이터 저장 위치 | 브라우저 또는 프록시 서버 | 클라이언트(브라우저) |
| 데이터 크기 | 일반적으로 대용량 리소스(HTML, CSS, 이미지 등) | 작은 데이터 (일반적으로 4KB 이하) |
| 유효 기간 | HTTP 헤더로 설정('Cache-Contorl', 'Expires') | 만료 시간 설정 가능 ('Set-Cookie' 헤더) |
| 보안 이슈 | 오래된 데이터 제공 가능성 | XSS나 CSRF 공격 시 민감한 정보 노출 위험 |

### 따라서
캐싱과 쿠키 모두 웹 애플리케이션에서 중요한 역할을 하지만 그 목적과 사용 방식은 다르다.
- 캐싱은 성능 최적화와 네트워크 비용 절감을 위한 기술로, 자주 사용하는 리소스는 임시로 저장해 빠르게 접근할 수 있게 한다.
- 반면, 쿠키는 세션 관리와 사용자 맞춤형 경험 제공을 위한 기술로, 작은 데이터를 클라이언트 측에 저장해 로그인 상태나 사용자 선호도를 기억하게 한다.

---
### 블로그 내 관련 문서
- [[로컬스토리지의 개념]]

---
### 참고 자료
출처 :
- <a href="https://f-lab.kr/insight/understanding-caching-strategies-in-web-development" target="_blank">f-lab</a>
- <a href="https://www.cloudflare.com/ko-kr/learning/cdn/what-is-caching/" target="_blank">cloudflare</a>
- <a href="https://maker5587.tistory.com/72" target="_blank">maker5587</a>
- <a href="https://digitaloasis.tistory.com/entry/cookie-and-session" target="_blank">digitaloasis</a>

웹 브라우저에서 데이터를 효율적으로 관리하는 방법

캐싱과 쿠키

## 토큰 기반 인증이란?

**토큰 기반 인증**은 사용자가 로그인하면 서버가 토큰(Token)을 발급하고, 클라이언트는 이 토큰을 저장한 후 요청할 때 마다 이를 서버로 보내어 인증을 받는 방식이다. 이 방식은 Stateless(무상태)한 인증 방식으로, 서버가 사용자의 세션 상태를 기억할 필요가 없다.

---
## 동작 원리

1. 로그인 요청: 사용자가 자격 증명(예: 사용자 이름, 비밀번호)을 서버에 제출한다.
2. 토큰 발급: 서버는 자격 증명이 유효하면, 클라이언트에게 JWT(JSON Web Token)와 같은 토큰을 발급한다.
3. 토큰 저장: 클라이언트는 이 토큰을 브라우저의 로컬 스토리지나 쿠키에 저장한다.
4. 요청 시 토큰 전송: 이후 클라이언트는 모든 요청에 이 토큰을 HTTP 헤더에 포함하여 서버로 전송한다.
5. 서버에서 토큰 검증: 서버는 전송된 토큰의 유효성을 확인하고, 유효한 경우 요청을 처리한다.
6. 토큰 만료/재발급: 토큰이 만료되면, 클라이언트는 새로 로그인하거나 리프레시 토큰(refresh token)을 사용해 새로운 액세스 토큰(access token)을 발급받는다.

---
## JWT(JSON Web Token)

JWT(JSON Web Token)는 JSON 형식으로 데이터를 안전하게 주고 받기 위한 웹 표준이다. JWT는 크게 세 부분으로 나뉜다.

1. Header (헤더): 토큰의 타입(JWT)과 서명에 사용할 해싱 알고리즘(예: HS256)을 정의한다.
2. Payload (페이로드): 사용자 정보나 기타 데이터를 담고 있으며, 이는 암호화되지 않은 상태로 Base64로 인코딩 된다.
3. Signature (서명): 헤더와 페이로드를 조합하고 비밀키로 서명한 값이다. 이 서명을 통해 데이터의 무결성을 검증할 수 있다.

### JWT 구조
- https://jwt.io/

위 링크로 이동하면 JWT의 형태를 볼 수 있다. JSON 웹 토큰은 헤더, 페이로드, 서명 세 부분으로 구성된다. 헤더와 페이로드는 Base64로 인코딩된 다음 마침표로 연결된다. 

header.payload.signature

```javascript
// 토큰 전체
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 // 여기가 헤더

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
// 여기까지가 페이로드

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c // 서명 부분이다
```



---
## 토큰 기반 인증의 장단점

### 장점
- 무상태(Stateless): 서버가 세션 상태를 유지할 필요가 없으므로 확장성(Scalability)에 유리하다.
- 다양한 플랫폼에서 사용 가능: 모바일 앱, 웹 애플리케이션 등 다양한 환경에서 쉽게 사용할 수 있다.
- 보안성 강화: 각 요청마다 토큰이 포함되므로, 세션 탈취 공격(Session Hijacking)을 줄일 수 있다.

### 단점
- 보안 문제: JWT가 탈취되면 만료될 때까지 악용될 수 있으므로 안전하게 저장해야 한다.
- 토큰 크기 문제: JWT는 서명과 페이로드를 포함하므로 쿠키보다 크기가 커질 수 있으며, 대역폭을 더 많이 차지할 수 있다.
- 만료된 토큰 처리 복잡성: 만료된 토큰을 처리하는 로직이 복잡할 수 있다.

---
## 코드 예시

### 설정 및 패키지 설치
```bash
mkdir jwt-auth-example 
cd jwt-auth-example 
npm init -y 
npm install express jsonwebtoken body-parser
```

- express: Node.js에서 서버를 쉽게 구축할 수 있는 프레임워크
- jsonwebtoken: JWT 생성 및 검증을 위한 라이브러리
- body-parser: POST 요청에서 보낸 데이터를 파싱하기 위한 미들웨어

### app.js
```javascript
const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));

const SECRET_KEY = 'mySecretKey'; // JWT 서명에 사용할 비밀키

// 간단한 사용자 데이터베이스 예시
const users = {
	'user1': 'password1',
	'user2': 'password2'
};

 

// 로그인 페이지 (GET 요청)
app.get('/login', (req, res) => {
	res.send(`
		<h2>로그인</h2>
		<form method="POST" action="/login">
			<label>사용자 이름:</label>
			<input type="text" name="username" />
			<label>비밀번호:</label>
			<input type="password" name="password" />
			<button type="submit">로그인</button>
		</form>
	`);
});

 

// 로그인 처리 (POST 요청)
app.post('/login', (req, res) => {
	const { username, password } = req.body;

	// 사용자 인증 확인
	if (users[username] && users[username] === password) {
		// JWT 생성 (유효기간 1시간)
		const token = jwt.sign({ username }, SECRET_KEY, { expiresIn: '1h' });
		res.json({ token });
	} else {
		res.status(401).send('로그인 실패! 사용자 이름 또는 비밀번호가 잘못되었습니다.');
	}
});

// 보호된 라우트 (JWT 검증)
app.get('/dashboard', (req, res) => {
	const token = req.headers['authorization'];

	if (!token) {
		return res.status(403).send('토큰이 필요합니다.');
	}

	// JWT 검증
	jwt.verify(token, SECRET_KEY, (err, decoded) => {
		if (err) {
			return res.status(401).send('유효하지 않은 토큰입니다.');
		}

		// 유효한 토큰일 경우 사용자 정보 제공
		res.send(`환영합니다, ${decoded.username}님!`);
	});
});

 

// 서버 실행
app.listen(3000, () => {
	console.log('서버가 http://localhost:3000 에서 실행 중입니다.');
});
```

### 실행
```shell
node app.js
```

- 미리 정의된 사용자 정보(user1, password1) 을 로그인 폼에 입력
- 토큰이 화면에 표시
- 표시된 토큰을 https://jwt.io/ 링크를 통해 디코딩하면 정보를 확인할 수 있음

#### 토큰 저장
실제 애플리케이션에서는 이 토큰을 로컬 스토리지나 쿠키에 저장하여 이후 요청 시 사용할 수 있도록 한다.

```javascript
localStorage.setItem('token', token);
```

#### 보호된 경로 접근 시 토큰 전송
클라이언트는 보호된 경로(예: dashboard)에 접근할 때마다 이 토큰을 HTTP 요청의 Authorization 헤더에 포함시켜 서버로 전송해야 한다.

#### 저장 및 대시보드 이동 예시
##### 서버 코드(app.js)
```javascript
const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());
app.use(express.static('public')); // 정적 파일 제공을 위해 public 폴더 사용

const SECRET_KEY = 'mySecretKey'; // JWT 서명에 사용할 비밀키

// 간단한 사용자 데이터베이스 예시
const users = {
	'user1': 'password1',
	'user2': 'password2'
};

// 로그인 페이지 (GET 요청)
app.get('/login', (req, res) => {
	res.sendFile(__dirname + '/public/login.html'); // 로그인 페이지 제공
});

// 로그인 처리 (POST 요청)
app.post('/login', (req, res) => {
	const { username, password } = req.body;

	// 사용자 인증 확인
	if (users[username] && users[username] === password) {
		// JWT 생성 (유효기간 1시간)
		const token = jwt.sign({ username }, SECRET_KEY, { expiresIn: '1h' });
		res.json({ token }); // JWT 토큰 반환
	} else {
		res.status(401).send('로그인 실패! 사용자 이름 또는 비밀번호가 잘못되었습니다.');
	}
});

// 보호된 라우트 (JWT 검증)

app.get('/dashboard', (req, res) => {
	const authHeader = req.headers['authorization'];

	if (!authHeader) {
		return res.status(403).send('토큰이 필요합니다.');
	}

	const token = authHeader.split(' ')[1];

	// JWT 검증
	jwt.verify(token, SECRET_KEY, (err, decoded) => {
		if (err) {
			return res.status(401).send('유효하지 않은 토큰입니다.');
		}

		// 유효한 토큰일 경우 사용자 정보 제공
		res.send(`환영합니다, ${decoded.username}님!`);
	});
});

// 서버 실행
app.listen(3000, () => {
	console.log('서버가 http://localhost:3000 에서 실행 중입니다.');
});
```


##### 로그인페이지(public/login.html)
```html
<!DOCTYPE html> 
<html lang="en"> 
<head> 
	<meta charset="UTF-8"> 
	<meta name="viewport" content="width=device-width, initial-scale=1.0"> 
	<title>로그인</title> 
</head> 

<body> 
	<h2>로그인</h2> 
	<form id="loginForm"> 
		<label>사용자 이름:</label> 
		<input type="text" id="username" /> 
		<label>비밀번호:</label> 
		<input type="password" id="password" /> 
		<button type="submit">로그인</button> 
	</form> 
	
	<script> 
		document.getElementById('loginForm').addEventListener('submit', async function(event) { 
		event.preventDefault(); 
		const username = document.getElementById('username').value; 
		const password = document.getElementById('password').value; 
		
		try { 
			const response = await fetch('/login', { 
				method: 'POST', 
				headers: { 'Content-Type': 'application/json' },
				body: JSON.stringify({ username, password }) 
			}); 
			
			if (!response.ok) { 
				throw new Error('로그인 실패'); 
			} 
			
			const data = await response.json(); 
			
			// JWT를 로컬 스토리지에 저장 - 추가된 부분 
			localStorage.setItem('token', data.token); 
			alert('로그인 성공! 대시보드로 이동합니다.'); 
			// 대시보드로 이동 - 추가된 부분 
			
			window.location.href = '/dashboard.html'; 
		} catch (error) { 
			alert(error.message); 
		} 
	}); 
	</script> 

</body> 
</html>
```


##### 대시보드페이지(public/dashboard.html)
```html
<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>대시보드</title>
</head>

<body>
	<h2>대시보드</h2>
	

	<script>
		async function loadDashboard() {
		const token = localStorage.getItem('token'); // 로컬 스토리지에서 토큰 가져오기

		if (!token) {
			alert('로그인이 필요합니다.');
			window.location.href = '/login.html';
			return;
		}

		try {
			const response = await fetch('/dashboard', {
				method: 'GET',
				headers: {
					'Authorization': 'Bearer ' + token // Authorization 헤더에 토큰 추가
				}
			});

			if (!response.ok) {
				throw new Error('대시보드 접근 실패');
			}

			const message = await response.text();
			document.getElementById('welcomeMessage').innerText = message;
		} catch (error) {
			alert(error.message);
		}
	}
	loadDashboard();
	</script>

</body>
</html>
```



> [!info] Bearer란
> dashboard.html 을 보면 headers의 토큰 앞에 Bearer를 추가한 것을 볼 수 있다.


---
## Bearer

Bearer는 OAuth 2.0 인증 프레임워크에서 사용하는 토큰 인증 방식 중 하나다. 이 방식에서 Bearer 토큰은 보호된 리소스에 접근할 수 있는 권한을 부여하는 엑세스 토큰의 일종이다.

### Bearer의 의미
- Bearer는 "소유자"라는 뜻이다. 즉, Bearer 토큰은 "이 토큰을 소유한 사람에게 권한을 부여해줘"라는 의미를 내포하고 있다.
- Bearer 토큰은 클라이언트가 서버에 요청을 보낼 때, HTTP 요청의 Authorization헤더에 포함되어 전송된다.

### 헤더에서 Bearer 사용
- HTTP 요청에서 Bearer 토큰을 전송할 때, Authorization 헤더에 다음과 같은 형식으로 포함한다.
```javascript
Authorization: Bearer <token>
```
#### 예시
```javascript
fetch('/dashboard', { 
	method: 'GET', 
	headers: { 
		'Authorization': 'Bearer ' + localStorage.getItem('token') 
	} 
})
```

### Bearer 사용하는 이유
- Bearer는 서버에서 "이 토큰을 가진 사람은 인증된 사용자이므로, 이 사용자가 보호된 리소스에 접근할 수 있도록 해달라"는 의미를 전달한다.
- 이 방식은 OAuth 2.0에서 주로 사용되며, 클라이언트가 서버에 다시 로그인하지 않고도 보호된 리소스에 접근할 수 있도록 한다.

### 사실 Bearer 없어도 됨
- Bearer 없이도 JWT를 사용할 수 있지만, 일반적으로 OAuth 2.0 및 여러 표준에서는 Bearer 방식을 권장한다.
- Bearer 없이도 JWT를 Authorization 헤더에 포함시켜 서버로 전송할 수 있지만, 보안 표준과 명확한 의사소통을 위해 Bearer 방식을 사용하는 것이 더 안전하고 일관성 있는 방법이다.

### 서버 측 코드
서버 측에서 Bearer를 이용한 JWT를 검증할 때, `Authorization` 헤더에서 Bearer 토큰을 추출하여 검증한다. 이 과정에서 헤더가 올바르게 전달되지 않으면 인증 실패로 처리된다.

```javascript
// Authorization 헤더 가져오기
const authHeader = req.headers['authorization']; 

// Bearer 뒤의 실제 토큰만 추출
const token = authHeader.split(' ')[1]; 
```

위 코드에서 `authHeader.split(' ')[1]`은 `Authorization` 헤더에서 "Bearer"를 제외한 실제 JWT 토큰 부분만 추출하는 코드이다.

그렇기에 "Bearer " 뒤에 한 칸의 공백을 반드시 포함시켜야 한다.

---
### 블로그 내 관련 문서
- [[세션 기반 인증]]

---
### 참고 자료
출처 :
- <a href="https://www.okta.com/identity-101/what-is-token-based-authentication/" target="_blank">okta</a>
- <a href="https://www.cloudflare.com/learning/access-management/token-based-authentication/" target="_blank">cloudflare</a>
- <a href="https://auth0.com/learn/token-based-authentication-made-easy" target="_blank">auth0</a>
- <a href="https://jwt.io/" target="_blank">jwt.io</a>
- <a href="https://www.strongdm.com/blog/token-based-authentication" target="_blank">strongdm</a>
- <a href="https://www.fortinet.com/resources/cyberglossary/authentication-token" target="_blank">fortinet</a>
- <a href="https://datatracker.ietf.org/doc/html/rfc6750" target="_blank">rfc6750</a>
- <a href="https://velog.io/@tosspayments/Basic-%EC%9D%B8%EC%A6%9D%EA%B3%BC-Bearer-%EC%9D%B8%EC%A6%9D%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83" target="_blank">tosspayments</a>
- <a href="https://www.fortinet.com/resources/cyberglossary/authentication-token" target="_blank">fortinet</a>

토큰 기반 인증

# 테스트에요

- 내용1
- 내용2

---


## 사진



![](https://i.imgur.com/5wUmW65.jpeg)


## 콜아웃

---

> [!note]
> 제목에 아무것도 안 쓰면 대괄후의 내용이 그대로 나타난다.

> [!abstract] 여기에는 제목을 쓰고
> 여기에는 내용!

> [!success] 당연하지만 제목만 달랑 있어도 상관 없다.

> [!info] info
> >[!] 이렇게, >와 함께 괄호를 쓰고 그 안에 !를 쓰면 예시 리스트가 나오니 골라서 쓰자

> [!tip] tip

> [!success] success

> [!warning] warning

> [!fail] fail

> [!error] error

> [!bug] bug

> [!example] example

> [!quote] quote

> [!faq]- 이 콜아웃은 펼칠 수 있을까?
> 네 맞습니다!, -는 기본이 닫혀진 상태

> [!warning]+ 이 콜아웃은 접을 수 있다!
> 디폴트가 펼쳐진 상태, +는 기본이 펼쳐진 상태
> 추가요! 2번째 줄
> 3번째 줄
> 마지막이요!


---




블로그 내 관련 문서
- [[]]

---
### 참고 자료
출처 : 
 
- <a href="https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/" target="_blank">cloudflare</a>

FromTo World

탐색기

From Word to World

Prologue

내가 바라는 것

이 생각을 실현시키기 위해

모바일 화면 사용방법

사용 예시

Recent Posts

Graph View