STUDY - Network

수현·2023년 7월 31일

IT (CS)

목록 보기

7/12

📒 네트워크

📕 네트워크의 기초

1. 네트워크 개념

노드(node)와 링크(link)가 서로 연결되어 있고, 리소스를 공유하는 집합
- 노드 : 서버, 라우터, 스위치 등 네트워크 장치
- 링크(edge) : 유선/무선과 같은 연결매체 (ex. 와이파이, LAN)

2. 트래픽 (traffic)

특정 시점에 링크 내에 흐르는 데이터 양
단위 : bps(bits per second)
🗒️ 예시 : 서버에 저장된 파일(문서, 이미지)을 클라이언트(사용자)가 다운로드 시 발생되는 데이터의 누적량(트래픽 발생)
- Q : 100KB 이미지를 1,000명이 다운로드 시 누적 트래픽은?
  - A : 100KB X 1,000 = 100,000KB(100MB)
- Q : 10MB 동영상을 10명이 다운로드 시 누적 트래픽은?
  - A : 10MB X 10 = 100MB

📖 참고 📖 트래픽 vs 처리량

✏️ 트래픽 : 흐르는 데이터의 양

✏️ 처리량 : 처리되는 트래픽의 양

3. 처리량 (throughput)

링크 내에서 성공적으로 전달된 데이터의 양 (트래픽 처리한 정도)
단위 : bps 초당 전송 또는 수신되는 비트 수
처리량에 영향 조건
- 사용자들이 접속할 때마다 커지는 트래픽
- 네트워크 장치 간의 대역폭
- 네트워크 증간에 발생하는 에러
- 장치의 하드웨어 스펙

4. 대역폭 (bandwidth)

주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수 (최대로 처리할 수 있는 트래픽)
단위 : bps 초당 전송 또는 수신되는 비트 수
🗒️ 예시 : 고속도로 차선이 2차선보다 8차선일 경우
- 대역폭이 높을수록 사용자에게 빠른 서비스 제공 가능
- Q : 100Mbps라는 대역폭을 가진 서버가 있고 한 사용자당 100kbps로 동영상 파일을 요청하면, 최대 동시접속자수는?
  - A : 100Mbps / 100kbps = 약 1000명

5. RTT (왕복 지연시간, Round Trip Time)

신호를 전송하고 해당 신호의 수신확인에 걸린 시간을 더한 값
어떤 메시지가 두 장치 사이를 왕복하는데 걸린 시간
🗒️ 예시 : google에 ping 보내기

📖 참고 📖 ping (Packet InterNet Groper)

컴퓨터의 네트워크 상태를 점검, 진단하는 명령

대상 컴퓨터를 향해 일정 크기의 packet 보내고(ICMP echo request), 대상 컴퓨터가 응답 메시지(ICMP echo reply) 보내면 분석하여 장동 여부 및 네트워크 상태 파악

TCP/IP 프로토콜 중 ICMP 통해 동작하므로, 해당 프로토콜 지원하지 않는 기기는 ping 수행 불가

6. 네트워크 토폴로지

개념 : 노드와 링크가 어떻게 구성되었는지
종류
- (1) 버스 토폴로지
- 특징
  - 하나의 회선에 여러개 노드
  - 노드 추가 삭제 쉬움
  - 설치비용⬇️
- 장점
  - 소규모 네트워크를 구축하기 쉬움
  - 한 노드에 장애가 발생해도 다른 노드에 영향X (중앙노드 방화벽⬆️)
- 단점
  - 메인 링크에 많은 트래픽이 생길 경우 정체현상 발생 (패킷 손실율⬆️)
  - 메인 링크 망가지면 문제
- (2) 스타 토폴로지
- 특징
  - 중앙에 있는 노드 기반으로 연결된 형태
  - 노드 추가, 삭제 쉬움
- 장점
  - 중앙노드가 아닌 한 노드에 장애가 발생해도 다른 노드에 영향X
  - 안정성 높음 (중앙노드가 아니면 한 노드에 침해 발생시 다른 노드로 확장X)
- 단점
  - 중앙노드 에러시 문제
- (3) 트리 토폴로지
- 특징
  - 계층적 토폴로지
  - 리프노드 기반으로 확장 쉽지만, 다른 노드는 어려움
  - 하이브리드 형태 (버스 + 스타)
- 장점
  - 노드 확장이 쉬움 (리프노드로 확장)
  - 리프노드 에러는 나머지 부분에 영향 미치지X
- 단점
  - 특정 노드 트래픽 집중시 하위노드에 영향
  - 루트노드에 문제 발생시 전체 네트워크에 문제
  📖 참고 📖 백본케이블
  - 여러 소형 네트워크를 묶어 대규모 파이프라인을 통해 높은 대역폭으로 다른 네트워크들의 집합과 연결되는 네트워크 (대규모 패킷 통신망)
- (4) 링형 토폴로지
- 특징
  - 고리 형태
  - 노드 추가, 삭제 쉬움
- 장점
  - 노드 수가 많아져도 데이터 손실 없음
  - 토큰을 기반으로 연속적으로 노드 거침
  - 토큰을 통해 통신권한 여부를 파악하여 해당 권한이 없는 노드는 데이터 전달받지X
- 단점
  - 링크/노드 에러 발생시 전체 네트워크에 영향
  - 토큰이 없는 노드는 통신에 참여를 못하고, 데이터 공유 불가
- (5) 메시 토폴로지
- 종류
  - full mesh
  - partionalliy mesh
- 특징
  - 그물망 형태
  - 노드 추가, 삭제 어려움
  - full mesh 토폴로지의 경우 : n * (n - 1) / 2 회선 필요
- 장점
  - 안정성⬆️
  - 한 노드에 장애가 발생해도 다른 노드에 영향X
  - 트래픽 분산 가능
- 단점
  - 회선이 비효율적으로 많아 구축비용⬆️

7. 네트워크 병목현상 (bottleneck)

개념 : 트래픽에 의해 데이터 흐름이 제한되는 상황 (핫스팟)
해결 : 구축된 시스템의 토폴로지를 파악하고, 어떤 회선/서버의 사용량 증가하는지 확인

8. 네트워크 통신

(1) 유니캐스트 (1:1 통신)
- HTTP 통신
- 일반적인 네트워크 전송 형태
(2) 멀티캐스트 (1:N 통신)
- 연결된 모든 노드들에게 데이터 전달하지 않고, 특정 그룹에게만 데이터 전달

(3) 브로드캐스트 (1:N 통신)

그룹이 아닌 연결된 모든 노드에게 데이터 전달
🗒️ 예시 : 브로드캐스트
- 노드 설치

server.js

const app = require('express')(); // express 기반 서버를 구동시키는데 필요한 노드 구성
const http = require('http').Server(app); const io = require('socket.io')(http); // web socket 기반으로 broadcast 하는데 필요한 모듈
const port = process.env.PORT || 3000;
app.get('/', (req, res) => {
res.sendFile(__dirname + '/index.html'); // index.html 전달
});
io.on('connection', (socket) => { // 연결된 user 들에게 메시지 전달
socket.on('chat message', msg => {
  io.emit('chat message', msg);
});
});
http.listen(port, () => {
console.log(`Socket.IO server running at
http://localhost:${port}/`);
});

node a.js 명령어 실행
127.0.0.01:3000 접속

index.html

<!DOCTYPE html>
<html>
<head>
  <title>Socket.IO chat</title>
  <style>
body { margin: 0; padding-bottom: 3rem; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; }
#form { background: rgba(0, 0, 0, 0.15); padding: 0.25rem; position: fixed; bottom: 0; left: 0; right: 0; display: flex; height: 3rem; box-sizing: border-box; backdrop-filter: blur(10px); }
#input { border: none; padding: 0 1rem; flex-grow: 1; border-radius: 2rem; margin: 0.25rem; }
#input:focus { outline: none; }
#form > button { background: #333; border: none; padding: 0 1rem; margin: 0.25rem; border-radius: 3px; outline: none; color: #fff; }
#messages { list-style-type: none; margin: 0; padding: 0; } #messages > li { padding: 0.5rem 1rem; }
#messages > li:nth-child(odd) { background: #efefef; }
  </style>
</head>
<body>
  <ul id="messages"></ul>
  <form id="form" action="">
    <input id="input" autocomplete="off" /><button>Send</button>
  </form>
  <script src="/socket.io/socket.io.js"></script>
  <script>
var socket = io();
var messages = document.getElementById('messages'); var form = document.getElementById('form');
var input = document.getElementById('input');
    form.addEventListener('submit', function(e) { e.preventDefault();
if (input.value) {
        socket.emit('chat message', input.value);
        input.value = '';
      }
});
socket.on('chat message', function(msg) {
var item = document.createElement('li'); item.textContent = msg; messages.appendChild(item);
window.scrollTo(0, document.body.scrollHeight);
});
  </script>
</body>
</html>

📖 참고 📖 socket

두 호스트를 연결하는 인터페이스 역할을 하는 데이터 주고받는 구조체

구성 : 프로토콜, IP 주소, 포트 넘버

9. 네트워크 분류

(1) LAN (근거리 통신망, local area network)
- 안정성⬆️, 속도⬆️
- 보통 허브, 스위치로 연결된 네트워크 (소규모 네트워크)
- 1개의 논리적인 주소(IP) 기반으로 여러개의 물리적 주소(MAC)을 구별하는 네트워크
(2) MAN (대도시 통신망, metropolitan area network)
- 도시-도시의 통신망
- 2개 이상의 LAN이 연결되어 구성
- 라우터, 브리지 등으로 연결
(3) WAN (광역 통신망, wide area network)
- 국가-국가 통신망
- 수많은 라우터를 거쳐 디른 국가와 연결되는 범위 (인터넷)

📕 TCP/IP 4계층

1. TCP(Transmission Control Protocol) / IP (Internet Protocol)

1) TCP/IP 4계층 개념
- 장치간 인터넷을 통해 데이터 송수신에 사용되는 프로토콜
- IP로 패킷 전송시 TCP를 활용해 패킷을 정상적으로 수신 받음
- 계층별 처리 역할이 달라서 계층별 간섭⬇️, 유지보수⬆️
- 다른 계층간 데이터 전달 과정을 알 필요가 없어 데이터 캡슐화 가능

📖 참고 📖 TCP / IP 과정

1) 웹 브라우저에 www.google.com 입력

구글 웹 서버에 80번 포트로 HTTP Request 보내는 것과 동일

2) HTTP Request 보내기 위해 각 계층에 필요한 정보를 패킷에 담아 전송

3) Application 계층 : HTTP Request 헤더 추가

4) TCP 계층 : TCP 헤더

SP (출발지 포트 번호) : 내 컴퓨터에서 만든 소켓의 포트 번호

DP (목적지 포트 번호) : 80포트로 요청

5) Internet 계층 : IP 헤더

SA (출발지 IP 주소) : 내 IP 주소

DA (목적지 IP 주소) : 도메인 정보로 IP주소 알기 위해 도메인 서버에 DNS 쿼리 보내고, IP 주소 응답 받음

6) Network Access 계층 : Ethernet 헤더

SA (출발지 MAC 주소) : 내 MAC 주소

DA (목적지 MAC 주소) : 구글 MAC 주소가 아닌, 물리적으로 연결된 패킷 전달된 라우터/게이트웨이의 MAC 주소 (ARP 프로토콜 사용)

7) 패킷 전송 전, 3-way handshaking으로 연결 설정

컨트롤 비트(ACK, SYN 플래그) 사용

8) 라우팅 통해 완성된 패킷을 목적지 서버에 전송

www.google.com에 패킷 전송 후 HTML 응답 받음

클라이언트는 응답 받은 HTML을 브라우저에 띄움

9) HTTP 응답 끝나면, 4-way handshaking으로 연결 종료

컨트롤 비트 (ACK, FIN 플래그) 사용

2) 캡슐화/비캡슐화
- 캡슐화 : 송신자가 수신자에게 데이터 보낼 때 계층을 지나면서 헤더 추가되는 과정
- 🗒️ 예시 : 전송계층 ➡️ TCP 헤더 추가, 네트워크 계층 ➡️ IP 주소 헤더 추가
- 비캡슐화 : 수신자측에서 캡슐화된 데이터를 역순으로 제거하는 과정

📖 참고 📖 PDU (Protocol Data Unit)

애플리케이션 계층 : 메시지

전송 계층 : 세그먼트(TCP), 데이터그램(UDP)

세그먼트 : 적절한 크기로 쪼갠 조각 (세그먼트 = 데이터그램)

인터넷 계층 : 패킷

패킷 : 세그먼트 SP와 DP가 포함된 IP 헤더가 붙은 형태의 조각

링크 계층 : 프레임(데이터 링크 계층), 비트(물리 계층)

프레임 : MAC 주소 헤더와 CRC/체크섬 트레일러가 붙은 조각

📖 참고 📖 CRC/체크섬 트레일러

데이터 오류 감지를 위한 함수가 적용된 값

링크의 오류(과도한 트래픽)로 인해 데이터 손상을 감지하는 역할

2. MTU, MSS, PMTUD

MTU (Maximum Transmission Unit)
- 네트워크 통신이 가능한 가장 큰 PDU의 크기
- IP 헤더와 TCP 헤더 크기 포함
- MTU 확인 : ping www.google.com -f -l 1500
  - 1500바이트를 보냄
  - DF, 패킷분할이 안되서 손실률 100%
  - ping의 경우 IP 헤더(20바이트) + ICMP 헤더(8바이트)로 요청을 보내는 것 (MSS = 1472(1500 - 28)까지 가능)
- 내 장치 MTU 확인 : (mac) ifconfig en0 (windows)netsh interface ipv4 show interfaces
MSS (Maximum Segment Size)
- TCP에서 사용할 수 있는 데이터의 크기
- IP 헤더와 TCP 헤더 크기 포함X
- 🗒️ 예시 : MTU 1500바이트여도 데이터는 1460바이트 이하 크기 보내야 전달 가능
- 이더넷 프레임 : 이더넷 헤더 14바이트 + FCS 4바이트가 포함한 것
- FCS (Frame Check Sequence) : 데이터 에러검출을 위해 삽입되는 필드 (CRC에 의해 생성된 것 포함)
- 총 이더넷 프레임 크기 = 1518 바이트
PMTUD (Path MTU Discovery)
- 수신자와 송신자의 경로 상에서 장치가 패킷을 누락한 경우 패킷의 크기를 낮추면서 MTU에 맞게끔 반복해서 보내는 과정
패킷이 분할되지 않는 경우
- 패킷을 분할할 수 없어 네트워크 경로 상에 있는 어떤 라우터나 장치의 MTU 초과하면, 아예 전달하지 않음
- IPv6 : 분할X
- IPv4 : flags 필드에서 bit=1이면, "Don't Fragment(플래그 활성화함)" 분할 불가능

3. 애플리케이션 계층

1) application layer 개념
- 웹 서비스, 이메일 등 서비스를 사용자에게 실질적으로 제공
- 🗒️ 예시 : HTTP, SMTP, SSH, FTP
2) HTTP (HyperText Transfer Protocol)
- 서버-브라우저간 (서버-서버간) 데이터를 주고 받기 위한 프로토콜
- 헤더를 통한 확장 쉬움 (헤더값에 특정값 넣어 HTTP 요청시 쉽게 다른 값 추가 가능)
- stateless (연속적인 상태값 없음)
3) SSH (Secure SHell)
- 보안되지 않는 네트워크간 서비스를 안전하게 운영하기 위한 암호화 네트워크 프로토콜
- ssh <pem> <user>@<serverIP>
- scp 이용해서 SSH로 파일 전송 가능
- scp <source> <destinatino>
4) FTP (File Transfer Protocol)
- 노드간 파일 전송시 사용되는 프로토콜
- 현재는 파일 암호화 전송을 위해 FTPS / SFTP 사용
- FTP 소프트웨어 : FileZilla

5) SMTP (Simple Mail Transfer Protocol)

인터넷을 통한 메일 전송 프로토콜
서비스 운영시 node.js를 통해 메일 보낼 경우 사용

🗒️ 예시 : 자바스크립트 Nodemailer 라이브러리 이용하여 JS 기반으로 SMTP 통해 메일

// create reusable transporter object using the default SMTP
transport
let transporter = nodemailer.createTransport({
host: "smtp.ethereal.email",
port: 587,
secure: false, // true for 465, false for other ports auth: {
user: testAccount.user, // generated ethereal user
pass: testAccount.pass, // generated ethereal password },
});

4. 전송 계층

1) transport layer 개념
- 메시지를 세그먼트(TCP)/데이터그램(UDP)으로 나눠 데이터를 오류 없이 순서대로 전달
- 🗒️ 예시 :TCP, UDP
2) TCP (Transmission Control Protocol)
- 가상회선 패킷 교환 방식 (순서 보장)
- 전이중, 점대점 방식 (멀티캐스팅X, 브로드캐스팅X)
- 오류 검사 : 재전송, 체크섬
- 헤더 : 20 ~ 60바이트로 가변적
3) UDP (User Datagram Protocol)
- 데이터그램 패킷 교환 방식
- 흐름제어X, 오류제어X, 재전송X
- 오류 검사 : 체크섬만 지원
- 헤더 : 8바이트 고정 길이
- 🗒️ 예시 : DNS

📖 참고 📖 오류 검사 메커니즘

✏️ 재전송

시간 초과 기간 지나면 서버는 전달되지 않은 데이터에 대해 재전송 시도

✏️ 체크섬

송신된 데이터 체크섬과 수신된 체크섬 값을 비교해서 동일한지 확인 (무결성 평가)

5. 인터넷 계층

1) Internet layer 개념
- 세그먼트/데이터그램을 패킷화하여 한 노드에서 다른 노드(목적지)로 전송
- 🗒️ 예시 : IP, ICMP, ARP, RARP
2) ICMP (Internet Control Message Protocol)
- 노드간 통신 확인 프로토콜
- 데이터 교환하는데 사용X (테스팅에 사용)
- 독립적인 비연결 프로토콜
3) ARP
- IP 주소 ➡️ MAC 주소 변환
- 해당 주소에 맞는 MAC 주소 찾기 위해 Brodcasting 통해 연결된 네트워크 장치에 데이터 전송
- 맞는 장치 있으면 해당 장치가 Unicast를 통해 데이터 전달해서 주소 찾음
4) RARP
- MAC 주소 ➡️ IP 주소 변환

6. 링크 계층 (네트워크 접속 계층)

Link layer 개념
- 데이터가 네트워크를 통해 물리적으로 전송
- 🗒️ 예시 : 전선, 광섬유, 무선

7. 3-way handshake (연결 성립)

(1) SYN 단계 🤵‍♀️ ➡️ 🖥️
- 클라이언트🤵‍♀️ : 서버에 클라이언트의 ISN을 담아 SYN 패킷 보냄
- SYN (synchronization) : 연결 요청 플래그
(2) SYN + ACK 단계 🖥️ ➡️ 🤵‍♀️
- 서버🖥️ : 클라이언트의 SYN 수신하고, 서버의 ISN을 보내며 승인번호로 ISN + 1 보냄
(3) ACK 단계 🤵‍♀️ ➡️ 🖥️
- 클라이언트🤵‍♀️ : 서버의 ISN + 1한 값인 승인번호를 담아 ACK를 서버에 보냄
- ACK (acknowledgement) : 응답 플래그
클라이언트와 서버의 상태
- 클라이언트🤵‍♀️ : closed, syn_sent, establised
- 서버🖥️ : closed, listen, syn_received, established

📖 참고 📖 listen

서버가 클라이언트 연락 대기 상태

해당 상태기반으로 서버 메서드 이름 결정
const express = require('express') const app = express()
const port = 3000
app.get('/', (req, res) => {
  res.send('Hello World!')
})
app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

📖 참고 📖 ISN

TCP 기반 데이터 통신에서 각 새 연결에 할당된 고유한 32비트 시퀀스 번호

TCP 연결을 통해 전송되는 다른 데이터와 충돌되지 않도록 시퀀스 번호 할당

wireshark(패킷 분석 tool)로 TCP 연결 확인

8. 4-way handshake (연걸 해제)

(1) FIN 🤵‍♀️ ➡️ 🖥️
- 클라이언트🤵‍♀️ : 서버에 FIN 설정 세그먼트 전송 후 FIN_WAIT_1 상태
- 서버 응답 대기
(2) ACK 🖥️ ➡️ 🤵‍♀️
- 서버🖥️ : ACK라는 승인 세그먼트 전송 후 CLOSE_WAIT 상태
- 클라이언트는 세그먼트 받으면 FIN_WAIT_2 상태
(3) FIN 🖥️ ➡️ 🤵‍♀️
- 서버🖥️ : LAST_ACK 상태가 되고, 일정 시간 이후 클라이언트에 FIN 세그먼트 전송
(4) ACK 🤵‍♀️ ➡️ 🖥️
- 클라이언트🤵‍♀️ : TIME_WAIT 상태가 되고, 서버로 ACK 전송
- 서버는 ACK 받고 CLOSED 상태
- 클라이언트는 일정 시간(TIME_WAIT 설정 시간) 대기 후 연결 닫힘

📖 참고 📖 TIME_WAIT

지연 패킷 등 발생시 데이터 무결성을 해결하기 위한 패킷 대기 시간

(FIN 플래그가 ACK 보다 먼저 도착한 경우)아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 패킷 기다리는 과정

2 * MSL 동안 대기

MSL (Maximum Segment Lifetime) : 최대 패킷 수명 (보통 2분)

연결이 올바르게 닫힌 상태로 만들기 위해 존재

CLOSED가 안되어 있을 경우 오류 발생하여, 일정 시간만 기다리도록 설정

CentOS/Ubuntu : 60초, Window :4분

Ubuntu 설정 파일
  include/net/tcp.h
#define TCP_TIMEWAIT_LEN (60*HZ) //TIME-WAIT

📕 라우팅

1. router / routing

1) router 개념
- 네트워크 사이에서 데이터 전달 장치
- 데이터(패킷)를 목적지로 보낼 때 최적의 경로 결정하고, 해당 경로로 넘겨주는 일(라우팅) 수행
- 라우터는 라우팅테이블 기반으로 데이터를 다음 목적지에 전달
2) routing 개념
- 네트워크에서 데이터(패킷) 전송시 최적 경로 선택
- routing 필요 정보
  - 출발지/목적지 네트워크 정보
  - 목적지로 가는 경로
  - 최적 경로
  - 지속적인 네트워크 상태 확인
3) routing 기법
- 정적 라우팅 : 라우팅 테이블에 정보를 관리자가 수동으로 입력 및 업데이트 필요
- 동적 라우팅 : 인접 라우터와 라우팅 정보를 자동 교환하여 라우팅 테이블 자동 작성 (큰 네트워크 사용)
- 디폴트 라우팅 : 라우팅 테이블에 등록되지 않은 주소를 가진 패킷이 경우 지정 경로로 전송

📖 참고 📖 routing protocol

EGP (Exterior Gateway Protocol)
: 다른 그룹과 라우팅 정보를 교환하는 프로토콜 (도메인간 라우팅)

1) EGP (게이트웨이 역외 프로토콜)

2) BGP (경계 게이트웨이 프로토콜)

IGP (Internal Gateway Protocol)
: 동일 그룹 내에서 라우팅 정보를 교환하는 프로토콜 (기업 내부)

Distance Vector Protocol

경로 설정을 위한 요소를 거리와 방향에 중점

홉 수를 기준으로 경로 찾음

1) RIP (라우팅 정보 프로토콜)

2) IGRP (내부 경계 라우팅 프로토콜)

Link State Protocol

전체 네트워크 topology, path 등 정보를 DB로 저장

DB 근거로 SPF 알고리즘(Shortest Path First) 사용하여 경로 찾음

3) OSPF (최단 경로 우선 프로토콜)

2. routing table

1) 개념
- IP 주소를 기반으로 라우터 위치를 저장한 테이블
- 네트워크에 대한 정보 및 네트워크에 연결 방법 포함
2) 구성요소
- 네트워크 대상 (Network Destination) : 목적지 네트워크의 IP 주소
- 서브넷 마스크 (Netmask) : 대상 주소를 설명시 사용
- 게이트웨이 (Gateway)
- 인터페이스 (Interface)
- 메트릭 (Metric)
3) 실습
```
netstat -r 
```

3. 게이트웨이

1) gateway 개념
- 서로 다른 네트워크 상의 통신 프로토콜을 변환해주는 역할
- 장치와 연결된 홉, 패킷이 전달되는 다음 IP 주소 정보 (외부 네트워크와 연결된 장치)
- 라우터와 기능 유사
2) gateway 방식
- 목적지가 로컬 네트워크라면 "연결됨(connected)"
- 다른 네트워크라면 "해당 네트워크의 게이트웨이 가리킴"
3) 홉
- 네트워크에서 출발지와 목적지 사이에 위치한 장치
- 홉 카운트 : 데이터가 출발지와 목적지간 통과해야 하는 홉의 개수
- Routing = hop by hop 통신

4. 인터페이스

게이트웨이로 가기위해 거치는 장치 (10.0.0.2는 eth3을 통해 접근 가능)

5. 메트릭

패킷 전송을 위해 최적 경로 선택시 참고되는 값(우선순위)
동일한 라우팅 테이블 요소가 2개 있을 때 메트릭 값 낮으면 선택
홉 수 + 지연시간 + 처리량 등

📕 IP 주소체계

1. IP 주소 vs MAC 주소

1) IP 주소 (Internet Protocol Address)
- 논리 주소
- 네트워크에서 장치간 인식하고 통신하기 위해 사용
2) MAC 주소 (Media Access Control Address)
- 네트워크 인터페이스에 할당된 고유 식별자
- 유일하지 않을 수 있음 (실수/의도적으로 UAA중복되게 만듦)
- 장치의 NIC(Network Interface Card)에 할당됨
- 48비트로 구성 (24비트 OUI + 24비트 UAA)
- MAC 주소 확인 : (mac) ipconfig en0의 ethernet, (windows)ipconfig/all

📖 참고 📖 OUI와 UAA

OUI : IEEE에서 할당한 제조사 코드

UAA : 제조사에서 구별되는 코드

📖 참고 📖 IEEE (Institute of Electrical and Electronics Engineers)

전기/전자/전산 분야의 국제 기구 및 학회

관련 전문가들이 합병해서 창설한 국제 조직

관련 기술 공유와 표준 정의등 활동

2. IPv4와 IPv6

1) IPv4 개념
- 32비트로 표현되는 주소 체계
- 2^32개의 주소(41억 9천만) 표현 가능
- 8비트씩 4개, .(점)으로 구분, 10진수
- 단점 : 주소 부족으로 NAT, 서브네팅 생김
2) IPv6 개념
- 128비트로 표현되는 주소 체계
- 2^128개의 주소 표현 가능
- 16비트씩 8개, :(콜론)으로 구분, 16진수
- 앞의 0 연속되면 생략 가능
- 구성 : 64비트 네트워크 주소 + 64비트 인터페이스 주소
- IPSec 내장됨 (데이터 패킷을 암호화하는 보안 네트워크 프로토콜)
- 단순해진 헤더 포맷 (IPv4의 불필요한 필드 제거)

3) IPv4 헤더
- checksum 필드 : CRC를 통한 손상된 패킷을 확인하고 폐기하는데 사용
- 헤더 : 가변길이
- 속도 : 느림
4) IPv6 헤더
- checksum 필드 : 없음 (상위 프로토콜(TCP/UDP)에 체크섬 필드 중복됨)
- 헤더 : 고정길이(40바이트)라서 인터넷 헤더길이 정보 없음
- 속도 : 빠름
- TTL ➡️ HOP limit (이름 변경)

📖 참고 📖 TTL

패킷이 네트워크에서 무한순환하지 않도록 하는 변수

패킷이 네트워크에서 라우터 거칠 때마다 TTL값 1씩 감소

값이 0이 되면 패킷 폐기

📖 참고 📖 CRC

순환 중복 검사

네트워크상에서 데이터 오류가 있는지 확인하기 위한 체크값 결정 방식

데이터 전송하기 전에 주어진 데이터의 값에 따라 CRC값 계산하여 데이터 붙여 전송

데이터 전송이 끝난 후 받은 데이터의 값으로 다시 CRC값 계산

두 값 비교해서 다를 경우, 데이터 전송 과정 중 오류(잡음 등)가 추가되어 전송된 것

설치
npm install crc
사용
import crc32 from 'crc/crc32':
crc32('hello').toString(16):
// "3610a686"

3. Classful IP Addressing

classful 개념
- 인터넷 상의 IP 주소를 크기별(클래스별)로 구분하는 방식
- 네트워크 주소를 매기고 크기를 다르게 구분하여 클래스 할당하는 주소 체계
IP 주소 구성: 네트워크 주소 + 호스트 주소
- 네트워크 주소 : 호스트를 모은 네트워크 (동일시 로컬 네트워크)
- 호스트 주소 : 호스트 구분
- 네트워크 호스트 : 컴퓨터 네트워크에 연결된 컴퓨터 및 기타 장치
1) 클래스 A
- 한 네트워크 당 1600만개 호스트 ID / 0 (2^24 -2)
- 네트워크 주소 범위 : 1 ~ 126 시작
- 127.x.x.x 루프백 주소로 제외 (본인 IP 지칭하는 주소)
- 0.0.0.0 특수 주소로 제외 (알 수 없는 대상을 위한 임시 주소)
2) 클래스 B
- 한 네트워크당 6만 5천개 호스트 ID / 10 (2^16 - 2)
- 네트워크 주소 범위 : 128 ~ 191 시작
3) 클래스 C
- 한 네트워크당 254 호스트 ID / 110 (2^8 - 2)
- 네트워크 주소 범위 : 192 ~ 223 시작

📖 참고 📖 클래스풀 IP 주소 규칙

첫 주소 : 네트워크 주소 (X.0.0.0)

마지막 주소 : 브로드캐스팅 주소 (X.255.255.255)

항상 2개 제외하고 사용

4. Classless, Subnetmask, Subneting

Classful 단점
- 네트워크 크기가 작은 경우 큰 네트워크 필요한 조직은 여러개 확보
- 네트워크 크기가 작은 네트워크 필요한 조직은 IP 낭비
Classless 개념
- 클래스로 나누지 않고 서브넷마스크 기준으로 네트워크 주소와 호스트 주소 구분 (현재 주소체계 사용)
- 서브넷팅 : 네트워크 나눔
- 서브넷 : 서브 네트워크 (쪼개진 네트워크)
- 서브넷마스크 : 서브 네트워크를 위한 비트마스크
서브넷마스크
- 네트워크 주소 부분 : 1 설정
- 호스트 주소 부분 : 0 설정
- 확인 : ipconfig

5. Public IP와 Private IP, NET

IP 주소 부족을 공인IP와 사설 IP로 나누고 NAT으로 해결
NAT (Network Address Translation)
- 패킷이 트래픽 라우팅 장치를 통해 전송되는 동안 패킷의 IP주소를 변경
- IP 주소를 다른 IP 주소로 매필하는 방법
- NAT을 통해 내부 네트워크 IP가 노출되지 않음

📕 HTTP

1. HTTP 헤더

사용자가 HTTP 요청시 헤더와 바디 주고 받음

1) HTTP Header 개념
- 헤더에 바디(html, xml, json 등 본문) 정보 포함
- 콜론(:)으로 서로 구분되는 key-value 형태
- HTTP 요청시 일반헤더/요청헤더/응답헤더 자동 생성
  📖 참고 📖 HTTP 확인
  - 1) www.naver.com ➡️ chrome 개발자 도구
  - 2) Network ➡️ Fetch/XHR
  - 3) (API 요청시 받는 리소스 중) count.nhn 확인
  - 4) Preview (Body)
2) 일반헤더
- Referrer Policy : 보안정도 설정 (요청한 URL/요청 메서드/해당 자원 출처 URL의 노출 여부를 결정)
3) 요청헤더
- 클라이언트에서 설정하는 헤더
- 메서드, 클라이언트의 OS, 브라우저 정보 포함
4) 응답헤더
- 서버에서 설정하는 헤더
- 서버의 소프트웨어 정보 포함 (보안을 위해 간략하게 표시)
- NWS (Naver Web Server)
- 생성

// node.js
  const http = require('http');  // http 모듈 불러옴
  const hostname = '127.0.0.1'; 
  const port = 3000;
  
  const server = http.createServer((req, res) => { // server 객체에 server 인스턴스 담기
  	res.setHeader('Content-Type', 'text/plain; charset=utf-8'); // key-value 형태
    res.setHeader('kundol', "i love you, but you don't love me"); // 헤더 커스텀 가능 
    res.end('큰돌, 그는 신인가?!\n');
});

  server.listen(port, hostname, () => { // 해당 메소드를 통해 server 구동
  	console.log(`Server running at http://${hostname}:${port}/`);
});

// 실행 : node [실행파일명]

2. HTTP/1.0

HTTP/1.0 특징
- 수명 짧은 연결
- 기본적으로 연결당 하나의 요청을 처리하도록 설계 ➡️ RTT 증가
- 각 HTTP 요청당 TCP 핸드셰이크 발생

📖 참고 📖 RTT (Round Trip Time, 왕복 지연 시간)

신호를 전송 + 신호의 수신확인에 걸린 시간

어떤 메시지가 두 장치 사이를 왕복하는 데 걸린 시간

3. HTTP/1.1

장점1️⃣) keep-alive
- default (기본 옵션) : 매번 데이터 요청시마다 TCP 연결 새로 하지 않고, 1번 연결만으로 여러 개 파일 송수신 가능
- header : timeout(연결유지시간) 및 max(최대 요청 수) 지정

const express = require('express') // express 모듈 기반으로 서버 가동
const app = express() 
app.get('/',(req, res) =>{ // path(/)에 접근하게 되면, 하단 json 반환하는 서버 
  res.json({"a" : 1})
})
const server = app.listen(12010)
server.keepAliveTimeout = 30 * 1000 // KeepAliveTimeout(TCP 연결을 언제까지 유지할지 설정하는 헤더) 30초로 설정 (default 5초)

장점2️⃣) 호스트 헤더
- HTTP/1.0 : 하나의 IP에 하나의 호스트만 가짐
- HTTP/1.1 : 헤더에 특정 호스트를 포함하여 요청하도록 변경
장점3️⃣) 대역폭 최적화
- HTTP/1.0 : 파일 다운로드 받다가 연결 끊기면 다시 받기 불가능
- HTTP/1.1 : Range:bytes=5000- 헤더 추가하여 다운로드 재개 요청 가능
단점1️⃣) HOL (Head Of Line blocking) 문제
- 네트워크에서 같은 큐에 있는 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
- 🗒️ 예시 : image.jpg 다운 지연시 전체 다운로드가 지연됨
요청 줄이기
- 해결1️⃣) 이미지 스프라이트 : 여러개 이미지를 1개의 이미지로 합쳐서 다운받음 (background-position으로 특정 이미지 표기)
- 해결2️⃣) 코드 압축 : 코드에서 들여쓰기/개행문자/빈칸 등 필요없는 부분 제거 (용량⬇️)
- 해결3️⃣) Base64 인코딩 기술 : 이미지 파일을 64진법 문자열로 인코딩 (이미지 서버에 대한 HTTP 요청할 필요 없음, 용량⬆️)

4. HTTP/2

HTTP/2 개념
- 구글에서 HTTP/1.1 한계 극복 위해 SPDY 프로토콜 (speedy) 개발
- 바이너리 포맷 계층
  - 애플리케이션 계층과 전송 계층 사이에 추가
  - 0과 1로 이뤄진 바이너리 데이터로 변경하여 더 작은 메시지가 프레임으로 캡슐화되어 전송
장점1️⃣) HOL Blocking 해결
장점2️⃣) 멀티플렉싱
- 하나의 TCP 연결에 여러 스트림 사용해서 여러 HTTP 요청/응답을 동시에 병렬로 송수신
- 리소스를 작은 프레임으로 나누고, 스트림으로 전달
- 각 프레임은 스트림ID, 해당 청크의 크기를 나타내는 프레임 추가 ➡️ 응답데이터에서 순서 보장
장점3️⃣) 서버푸시
- 향후 요청에서 예상되는 추가 정보를 미리 클라이언트에 푸시함
- 🗒️ 예시 : html 읽으면서 그 안에 참조된 css, js파일을 푸시하여 미리 보냄
장점4️⃣) 헤더압축
- HTTP/1.x의 크기가 큰 헤더의 문제 해결
- 똑같은 서버에서 2개의 이미지 전달할 경우 중복되는 헤더는 제외 후 공통 필드로 헤더 재구성
- 중복되지 않은 헤더를 허프만 인코딩 압축 방법을 통해 압축 후 전송
장점5️⃣) 스트림 우선순위 설정
- 서버에서 원하는 순서대로 우선순위를 정해 리소스 전달
- 클라이언트가 선호하는 응답 수신 방식을 지정해서 응답 받을 수 있음
- 🗒️ 예시 : html 문서 내에 css 파일 1개 + 이미지 파일 2개 요청할 경우
  - css 파일 수신이 이미지 파일보다 늦어지면, 브라우저 렌더링에 문제 발생
  - 리소스 간의 의존 관계에 따른 우선순위 설정 가능
📖 참고 📖 허프만 인코딩
- 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트수로 표현
- 빈도수 낮은 정보는 많은 비트수로 표현해 필요한 비트양을 줄이는 알고리즘

5. HTTP/3

HTTP/3 개념
- UDP 기반의 QUIC (Quick UDP Internet Connections) 프로토콜 사용하여 통신
장점1️⃣) 멀티플렉싱, 초기 연결 설정시 지연시간 감소
장점2️⃣) 초기 연결 설정시 지연시간 감소
- QUIC은 UDP 기반이라 3-way handshaking 과정X
- 첫 연결 설정에 1-RTT 소요
장점3️⃣) FEC (Forward Error Correction, 순방향 오류 수정 메커니즘)
- 전송된 패킷 손실시 수신측에서 에러 검출 + 수정
- 열악한 네트워크 환경에서도 낮은 패킷 손실률

6. 암호화

1) 암호화 개념
- 승인된 당사자만 정보를 이해할 수 있도록 데이터 스크램블
- ciphertext(암호문) = plaintext(평문) + key
- 통신을 하이재킹하여 읽을 수 없도록 데이터 유출 방지, 데이터 무결성 보장
2) 스크램블
- 각 단어나 문자를 패턴에 따라 암호화X, 무작위 방식으로 개별 데이터 비트를 섞음
- 🗒️ 예시 : AES (공통 128비트 고급 암호화 표준)의 암호화 파일의 경우
  - 10회 스크램블되고, 키없이 해독할 경우 오랜 시간 걸림
3) 대칭 암호화
- 키를 1개만 사용하는 암호화 방법
- 암호화/복호화에 동일한 키 사용
- 키 교환 시 Diffie-Hellman 방식 사용
- 🗒️ 예시 : DES, AES
4) 비대칭 암호화 (공개키 암호화)
- 2개의 다른 키(공개키, 개인키)로 데이터 암호화/서명
- 공개키로 암호화된 데이터는 개인키로만 복호화 가능
- HTTPS에서 사용되는 TLS 프로토콜에서 부분적으로 비대칭 암호화 사용 (TLS 1.3)
  - TLS Handshake 과정에서 첫 인증 때 DH 같은 키 교환 방식으로 클라이언트-서버간 세션키 교환
  - 세션키 이용한 대칭 암호화 기반으로 암호화된 통신
- 🗒️ 예시 : RSA, DH(Diffie-Hellman)

📖 참고 📖 RSA 취약점

RSA의 경우 : 클라이언트가 생성한 세션키(임시 암호값)을 서버로 전송
➡️ 제3자가 서버의 개인키 탈취할 경우 SSL Handshake 과정 복호화 하여 볼 수 있음 (PFS 지원X)

DH의 경우 : 클라이언트-서버가 서로 교환한 DH 매개변수 사용해 개인키 만듦
➡️ DH 탈취당해도 공통 암호키 만들지 못해 위험 적음

RSA 키 교환 과정

서버에서 공개키+개인키 생성하고 SSL 인증서를 통해 공개키를 클라이언트에게 전송

클라이언트는 공개키로 세션키를 암호화 하여 서버에 전송

서버는 세션키를 복호화 하여 통신에 사용

📖 참고 📖 PFS (Perfect Forward Secrecy)

비밀키가 노출되었을 경우에도 기존 암호문을 노출된 비밀키로 해독X

ECDHE 방식이 PFS 지원

DH 방식은 세션키를 안전하고 간단하게 생성 가능 ➡️ 주기적으로 세션키 변경하여 일정 주기마다 다른 세션키 가짐

공격자가 특정 시점의 데이터를 복호화하고 싶을 경우 특정 시점의 세션키 필요

7. TLS 핸드셰이크

1) TLS 개념
- 전송 계층에서 보안 제공하는 프로토콜
- 클라이언트와 서버가 통신할 때 TLS 통해 제3자가 메시지를 도청/변조를 막음
- SSL(Secure Socket Layer)에서 업그레이드 되며 TLS(Transport Layer Security Protocol) 명칭 변경
- 비대칭 암호화로 인증 ➡️ 대칭 암호화로 보안적 통신
- HTTPS = HTTP + TLS
2) TLS Handshake (TLS 1.3)
- 사용할 TLS 버전 정하기 ➡️ 사이퍼슈트, 서버 공개키, SSL 인증서 기반 인증작업 수행 ➡️ 대칭 암호화를 위해 세션키 생성
- (1) Client Hello
  - 클라이언트 : TLS버전, 사이퍼슈트, 클라이언트 랜덤값(무작위 문자열), 임시 DH 매개변수 서버에 보냄
- (2) Server HEllo, EncryptedExtensions, Certificate, CertificateVerify
  - 서버 : 클라이언트로부터 받은 옵션 확인 (서버와 클라이언트 모두 지원하는 높은 TLS 버전 식별하여 결정, 사이퍼슈트 지원 여부 확인)
  - 서버 : 공개키가 포함된 SSL 인증서, 서버 랜덤값, 임시 DH 매개변수 보냄
  - 클라이언트/서버 : 서로 교환한 DH 매개변수 사용하여 세션키(임시 암호 키) 생성
- (3) Finished
  - 클라이언트-서버가 세션키 기반으로 대칭 암호화 통신 시작 (보안 세션)
  - 키 교환 알고리즘 : RSA, DH(타원곡선 DH)
3) TLS 패킷분석
- SSL : ssllabs 이용
- TLS : wireshark 이용
- client가 사이퍼슈트 전송
- EC 디피헬만 (타원곡선 + 디피헬만) 이용
- 암호화된 데이터
4) DH 매개변수 (Diffie-Hellman)
- 공통 암호키 만드는 알고리즘
- a. b : Alice & Bob만이 알고 있는 비밀값
- g, p : 공개값
- Alice가 A, g, p Bob에게 전송
  ➡️ Bob이 B를 Alice에게 전송
  ➡️ Alice와 Bob은 서로 받은 매개변수(A, B)로 공통 키 값인 K 생성 가능
- 종류
  - DHE : 일반 디피헬만
  - ECDHE : 타원곡선암호화 방법 + DH
📖 참고 📖 타원곡선 암호화 방법
- 곡선을 사용하여 개인 키 보유자만 알 수 있는 타원곡선 그림
- 타원곡선을 기반으로 교차점 생성
- 교차점의 수를 기반으로 암호 설정하는 방법
5) 사이퍼슈트
- 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규악 (암호제품군)
- 🗒️ 예시 : TLS 1.3 버전
  - TLS_AES_128_GCM_SHA256
  - TLS_AES_256_GCM_SHA384
  - TLS_CHACHA20_POLY1305_SHA256
  - TLS_AES_128_CCM_SHA_256
  - TLS_AES_128_CCM_8_SHA256
- 🗒️ 예시 : TLS_AES_128_GCM_SHA256은 3가지 규약 들어 있음을 의미
  - TLS : 프로토콜
  - AES_128_GCM : AEAD 사이퍼 모드
  - SHA256 : 해싱 알고리즘

📖 참고 📖 AEAD (Authenticated Encryption with Associated Data) 사이퍼 모드

데이터 암호화 알고리즘

🗒️ 예시 : AES_128_GCM

128비트의 키를 사용하는 AES 알고리즘 + 병렬 계산에 용이한 GCM 암호화 알고리즘이 결합된 알고리즘

6) 해싱 알고리즘
- 데이터를 작고 섞인 조각으로 만드는 알고리즘
- SSL/TLS에서 해싱 알고리즘으로 SHA-256, SHA-384 사용
- 🗒️ 예시 : SHA-256 알고리즘
  - 해시 함수의 결괏값이 256비트
  - 비트 코인 등 많은 블록체인 시스템에서 사용
- TLS에서 해싱 알고리즘 사용
  - 인증 생성작업 : 전자서명 만드는데 서명되는 메시지 해싱
  - 인증 확인작업 : 메시지를 복호화해서 해시를 서로 비교해 올바른 메시지인지 확인

📖 참고 📖 전자서명

송신자가 자신의 신원을 증명하는 절차/정보

전자서명을 통해 인증서의 주체가 서비스 제공자인지 확인

기록된 전자서명 기반으로 CA의 공개키로 복호화 해서 지문을 얻고, 인증서에 기록된 정보를 해시 함수에 입력하여 두 해시의 일치 여부 확인 (유효성 검증)

유효성 검증 : 인증서가 변조되지 않고, 인증서가 "서비스 제공자"것임을 확인하는 과정

📖 참고 📖 인증서

주체 + 공개키 포함하는 단순 데이터 파일

주체 : 인증서 발급한 CA, 도메인, 웹사이트 소유자, 인증서 소유자

공개키 : 첫 인증시 사용 (공개키, 공개키 암호화 방법)

클라이언트에서 의도한 서버가 맞는지 확인시 사용

인증기관(CA)에서 발급한 SSL 인증서 기반으로 인증

자신의 웹사이트 안에서 SSL 인증서 만들 수도 있음

📖 참고 📖 CA (Certificate Authority)

인증서를 발급하는 기업들

CA로부터 인증서를 구입할 때 서비스의 도메인, 공개키 같은 정보를 제출해야 함

종류

단일 도메인 : 1개 도메인에 적용되는 인증서 (ex. www.naver.com)

와일드카드 : 도메인의 하위도메인도 포함하는 인증서 (www.cloudflare.com, blog.cloudflare.com)

멀티 도메인 : 관련되지 않은 다수의 도메인에 적용되는 인증서

📖 참고 📖 0 - RTT

세션키 생성 후 다시 사이트 방문하면, 미리 만들어 놓은 세션키(PSK)를 기반으로 연결해서 인증에 드는 비용X

인증에 관한 RTT가 발생하지 않음

📕 웹브라우저의 캐시

1. 로컬스토리지

개념
- 웹 브라우저 내에 { key : value } 형태로 오리진에 종속되어 저장되는 웹 스토리지 객체
- 오리진이 같은 브라우저 내에서 공유됨
특징
- 하나의 키에 오로지 하나의 값만 저장
- 데이터는 사용자가 브라우저에서 수동으로 삭제하지 않는 한 평생 동안 로컬 저장소에 저장되며 만료날짜 없음 (사용자가 창/탭 닫거나 컴퓨터 종료해도 만료X)
- 최대 저장용량 5MB
- 로그인 유지하기 위한 값 등으로 사용됨
- 로컬 스토리지 데이터는 자동으로 서버 전송X (쿠키는 자동 전송)
사용법
- 설정 : localStorage.setItem(key, value);
- key에 해당하는 value 가져오기 : localStorage.getItem(key);
- 제거 : localStorage.removeItem(key);
- 전체 제거 : localStorage.clear();

2. origin

query string (search)
https://search.shopping.naver.com (오리진) + /catalog + (경로) /33803998618?adId... (쿼리)

3. 로컬스토리지 활용

(1) 로그인 유지에 사용
(2) 캐싱
- 🗒️ 예시 : UX를 개선하기 위해 텍스트 창에 입력한 값을 로컬 스토리지를 통해 캐싱

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width,
initial-scale=1.0">
    <title>Document</title>
    <style>
/* CSS */
        .button-62 {
            background: linear-gradient(to bottom right, #EF4765,
#FF9A5A);
            border: 0;
            border-radius: 12px;
            color: #FFFFFF;
            cursor: pointer;
            display: inline-block;
            font-family: -apple-system, system-ui, "Segoe UI",
Roboto, Helvetica, Arial, sans-serif;
                 font-size: 16px;
            font-weight: 500;
            line-height: 2.5;
            outline: transparent;
            padding: 0 1rem;
            text-align: center;
            text-decoration: none;
            transition: box-shadow .2s ease-in-out;
            user-select: none;
            -webkit-user-select: none;
            touch-action: manipulation;
            white-space: nowrap;
}
        .button-62:not([disabled]):focus {
            box-shadow: 0 0 .25rem rgba(0, 0, 0, 0.5), -.125rem
-.125rem 1rem rgba(239, 71, 101, 0.5), .125rem .125rem 1rem
rgba(255, 154, 90, 0.5);
}
        .button-62:not([disabled]):hover {
            box-shadow: 0 0 .25rem rgba(0, 0, 0, 0.5), -.125rem
-.125rem 1rem rgba(239, 71, 101, 0.5), .125rem .125rem 1rem
rgba(255, 154, 90, 0.5);
} #field{
            font-size: 27px;
        }
body{
display: flex;
            justify-content: center;
            align-items: center;
            margin: 0 auto;
            height: 100vh;
}
    </style>
</head>
<body> <div>
<input type="text" id="field" />
<input type="button" class="button-62" value="검색"id="save" />
<input type="button" class="button-62" value="조회"
id="read" />
<input type="button" class="button-62" value="삭제"
id="clear" />
    </div>
</body>
<script>
window.onload = async () => {
const field = document.getElementById("field"),
            save = document.getElementById("save"),
            read = document.getElementById("read"),
            clear = document.getElementById("clear")
save.addEventListener("click", e => localStorage.setItem("입력값", field.value))
read.addEventListener("click", e => alert(window.localStorage["입력값"]))
        clear.addEventListener("click", e => {
            window.localStorage.clear()
            field.value = ""
})
if (window.localStorage["입력값"]) {
field.value = window.localStorage["입력값"] }
}
</script>
</html>

4. 세션스토리지

개념
- 웹 스토리지 객체로 브라우저 내에 { key : value } 형태로 오리진에 종속되어 저장되는 데이터
- 오리진이 같은 브라우저 내에서 공유됨
- 보통 세션스토리지보다 로컬스토리지 많이 사용
특징
- 하나의 키에 오로지 하나의 값만 저장
- 최대 저장용량 5MB
- 사용자가 브라우저에서 탭을 닫으면 데이터 만료됨(삭제)
사용법
- 설정 : sessionStorage.setItem(key, value);
- 탐색 : sessionStorage.getItem(key);
- 제거 : sessionStorage.removeItem(key);
- 전체 제거 : sessionStorage.clear()

5. 쿠키

1) 개념
- 클라이언트에 데이터 저장하는 방법
- 요청시 서버에 자동으로 쿠키 전송됨
- 클라이언트와 서버 둘 다 조작 가능
  - 보통 서버에서 만료기한 등 설정해서 쿠키 생성
  - 자바스크립트의 document.cookie 통해 쿠키 설정 (헤더 = 쿠키값)
  ➡️ 쿠키 제어권을 클라이언트가 가지면 쿠키에 민감한 정보가 담길 수 있어서, 서버가 제어권 갖게 해야함
```
axios.get(url, { 
headers: {
              Cookie: "cookie1=value; cookie2=value; cookie3=value;"
		}
}).then
```
- 서버에서 응답헤더로 Set-cookie 설정해서 쿠키 보내면, 클라이언트에서 요청헤더 Cookie에 설정되어 자동으로 서버 전달되고, 브라우저에 저장
- 저장용량 최대 4KB
- 🗒️ 예시 : 로그인, 장바구니, 사용자 커스터마이징, 사용자 행동분석(개인화 광고에 사용)
2) 세션 쿠키
- Expires 또는 Max-Age 속성을 지정X
- 브라우저가 종료되면 쿠키도 사라짐
3) 영구 쿠키
- Expires 또는 Max-Age 속성을 지정
- 브라우저 닫을 때 만료X (특정 날짜 또는 일정 기간이 지나면 삭제)

4) 문법

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict

(1) Secure : https로만 쿠키 주고받을 수 있게 함 (현재 크롬은 안전하지 않은 사이트가 Secure 지시문으로 쿠키 설정 금지함)
(2) HttpOnly : 공격자가 자바스크립트로 빼낼 수 없게 만듦 (document.cookie로 접근 불가)

(3) SameSite : 요청이 동일한 도메인에서 시작한 경우에만 쿠키가 애플리케이션으로 전송되도록 허용

const http = require('http');
const hostname = '127.0.0.1';
const port = 3000;
const server = http.createServer((req, res) => {
res.setHeader('Content-Type', 'text/plain; charset=utf-8');
res.setHeader('Set-Cookie', ['kundol = amumu; httponly',
'loltier = master; Secure']);
res.end('큰돌, 그는 신인가?!\n'); });
server.listen(port, hostname, () => {
console.log(`Server running at http://${hostname}:${port}/`);
});

5) 쿠키의 시큐어코딩
- 세션ID 설정시
  - cookie에 세션ID를 세션ID 기반으로 클라이언트의 개인정보를 유추할 수 없게 해야함 (세션ID 어렵고, 길고, 랜덤하게 생성 알고리즘 사용)
  - 자바스크립트로는 파악할 수 없게 http only 옵션 적용
  - 일정시간의 세션 타임아웃 걸기
- 쿠키 허용 관련 알림창 생성
- 서비스 운용시 쿠키 사용할 경우 쿠키 허용 관련 알림창 생성
방문 기록을 추적할 때 쿠키 사용됨
- 사용자의 데이터 간접 수집에 해당되어 KISA(한국인터넷진흥원) 지침 준수
- 정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준(KISA) - 간접수집 보호조치
  - 정보주체(이용자) 이외로부터 개인정보 수집하거나 제공받는 경우에는 업무에 필요한 최소한의 개인정보만 수집, 이용하여야 하고 법령에 근거하거나 정보주체(이용자)의 요구가 있으면 개인정보의 수집 출처, 처리목적, 처리정지의 요구권리를 알려야 한다.
  - 다만, 서비스 제공 계약 이행과는 무관한 목적으로 이용하기 위해 수집하는 경우에는 선택 동의 항목으로 분류하여 별도의 사전 동의를 받아야 함 (예를 들어, 쿠키를 통해 수집하는 행태 정보를 분석하여 개인별 맞춤형 광고에 활용하는 경우)

📖 참고 📖 업비트의 쿠키 세션 타임아웃 (공격자 접근 차단)

로그인 유지하기 위해서 업비트 로그인 화면에서 '로그인 상태 유지' 활성화

PC 웹에서 지원되는 기능으로 '로그인 상태 유지' 활성화 여부에 따라 기본 로그인 유지 시간이 설정됨

로그인 상태 유지 활성화 : 로그인 유지 시간 기본 24시간

로그인 상태 유지 비활성화 : 로그인 유지 시간 기본 3시간

6. 로컬/세션 스토리지와 쿠키 비교

공통점1️⃣) 필요한 이유
- 브라우저에 캐싱을 함으로써 서버에 대한 요청을 줄여 서버 부하 방지
- 캐싱으로 인해 다운로드하는 컨텐츠 줄어 웹사이트의 컨텐츠를 더 빨리 다운로드 가능
공통점2️⃣) 저장목록
- 사이트 기본 설정 커스터마이징(색상, 글꼴 크기 등)
- 로그인 상태 저장
차이점1️⃣) 로컬 스토리지 vs 세션 스토리지 vs 쿠키
차이점2️⃣) 세션쿠키 vs 영구쿠키
차이점3️⃣) 세션 vs 세션쿠키 vs 세션 스토리지

📕 로그인

1. 세션기반 인증방식

1) 개념
- HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보를 유지X (stateless) ➡️ 세션 필요
- 세션 : 서버와 클라이언트 연결이 활성화된 상태
- 세션ID : 웹 서버 또는 DB에 저장되는 클라이언트에 대한 유니크 ID
2) 인증 프로세스
- 1️⃣ : 처음 로그인 ➡️ 세션ID 생성 ➡️ 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
- 2️⃣ : 이후 요청마다 HTTP 헤더에 세션ID를 쿠키에 포함시켜 요청
- 3️⃣ : 해당 쿠키에 맞는 세션ID로 전에 로그인한 ID인지 확인
- 4️⃣ : 로그인 유지
3) 단점
- 로그인 중인 유저의 수가 늘어날 경우
  ➡️ 서버의 메모리 과부하
- DB중 RDBMS에 저장할 경우
  ➡️ 직렬화 및 역직렬화에 관한 오버헤드 발생

📖 참고 📖 직렬화 및 역직렬화

네트워크간 객체를 송수신하기 위해서 객체를 데이터스트림으로 변환 필요

✏️ 직렬화

객체에 저장된 데이터를 스트림에 담기 위해 연속적인(serial) 데이터로 변환

✏️ 역직렬화

스트림 데이터를 다시 읽어와서 객체로 만듦

4) 실습

node.js 설치 및 라이브러리 설치

npm install escape-html express express-session

세션 생성 후 자동으로 쿠키값 설정

// 사용자가 보낸 값을 보안을 위해 escape하기 위한 모듈입니다. // 예를 들어 foo&bar>>foo&amp;bar 로 바꿉니다.
const escapeHtml = require('escape-html')
const express = require('express')
const session = require('express-session')
const app = express()
// 박종선바보멍청이 >> SHA256 >>
// 9e8821c8ef4ab43ba09310af54e98caedc13e314efdea720bf513b9b3675faf4 app.use(session({
name: "session-id",
secret:
"9e8821c8ef4ab43ba09310af54e98caedc13e314efdea720bf513b9b3675faf4"
,
resave: false,
saveUninitialized: false
}))
// 미들웨어 : auth
const isAuthenticated = (req,res, next) =>{
// 만약 세션이 있다면 다음 미들웨어로. 그게 아니라면. 다음 route로 제어권을 넘깁니다.
if (req.session.user) next()
else next('route') }
// 만약 isAuthenticated 하다면 logout을 보여준다. app.get('/', isAuthenticated, function (req, res) {
res.send(escapeHtml(req.session.user) + '님 환영합니다!') })
// 만약 isAuthenticated 하지 않다면 login을 보여준다. app.get('/', function (req, res) {
res.send('<p>로그인</p><form action="/login" method="post">' + 'Username: <input name="user"><br>' +
'Password: <input name="pass" type="password"><br>' + '<input type="submit" text="Login"></form>')
})
// 로그인요청 >> 세션 생성
app.post('/login', express.urlencoded({ extended: false }), function (req, res) {
if(req.body.user === "kundol" && req.body.pass === "1234"){ req.session.regenerate(function (err) {
if (err) next(err)
// input : user 에 있는 값을 req.session.user에 할당 req.session.user = req.body.user
//세션 생성>>쿠키값 설정>>이후 다시 리다이렉팅 req.session.save(function (err) {
if (err) return next(err)
       res.redirect('/')
     })
})
}else res.redirect('/')
})
app.listen(3000, () => console.log("server is started :
http://localhost:3000"))

2. 토큰기반 인증방식

1) 개념
- state를 모두 토큰으로 처리
- 인증은 토큰 인증서버를 통해 하고, 다른 서버는 stateless한 방식
2) 인증 프로세스
- 1️⃣ : /login 요청 ➡️ JWT토큰 생성
  (access 토큰 수명 짧게 + refresh 토큰 수명 길게)
- 2️⃣ : access 토큰을 HTTP Header-Authorization/Cookie에 담아 서버에 요청
  - Bearer <token> 형식으로 토큰기반 인증방식 알리기
  - https 사용
  - 쿠키에 저장할 경우 sameSite: 'Strict' 사용
  - 수명이 짧은 access token 발급
  - url 토큰 전달X
- 3️⃣ : access 토큰 만료/새로고침시 refresh 토큰을 기반으로 새로운 access 토큰 얻음
3) JWT (JSON Web Token)
- 특징 : JSON 객체로 인코딩
- 사용 : 인증, 암호화에 사용
- 구성 : 헤더, 페이로드, 서명
- Header
  - 어떤 방법의 서명 알고리즘 사용 정보
  - 토큰 유형과 서명 알고리즘, base64URI로 인코딩됨
- Payload
  - 인증이 필요한 최소한의 정보
  - 데이터, 토큰 발급자, 토큰 유효기간, base64URI로 인코딩됨
- Signature
- (인코딩된 header + payload) + 비밀키 기반으로 헤더에 명시된 알고리즘으로 다시 생성한 서명값
4) 장점
- 사용자가 인증되면 모든 시스템이서 사용할 수 있는 보안 토큰 받음
- 보안 토큰은 일종의 단일 엔드포인트로서 다른 모든 서버간 API 상호작용을 인증할 수 있음
- 사용자 인증 정보는 모두 토큰에 포함되어 별도의 인증 저장소 필요X
- 다른 유형의 토큰(SAML)과 비교하면 사이즈⬇️
- 확장성, 디버깅 성능⬆️ (디코딩시 쉽게 직렬화, 역직렬화 가능)
5) 단점
- 토큰이 비대해질 경우 서버 과부하에 영향
- 토큰을 탈취당할 경우 디코딩하면 데이터 볼 수 있음

📖 참고 📖 SAML (Security Assertion Markup Language)

인증(Authentication)/인가(Authorization)
➡️ SAMLAssertion 안에 인증/권한 정보

아이덴티티 공급업체(IdP)에서 서비스 공급업체(SP)로 권한 인증 자격 증명을 전달할 때 사용되는 XML기반 표준 데이터 포맷

SSO 기능 제공하기 위해 엔터프라이즈 애플리케이션에서 일반적으로 사용

애플리케이션간 커뮤니케이션이 안전하게 이루어져 1번의 디지털 서명으로 모든 리소스 이용

인증 플로우

User : 인증 원하는 사용자

Indentity Provider(IDP) : 인증 정보 제공자

Service Provider(SP) : 서비스 제공자

📖 참고 📖 OAuth (Open Authorization)

~~인증(Authentication)~~/인가(Authorization)
➡️ Access Token 안에 권한 정보

사용자가 로그인 자격 증명을 공유하지 않고, 타사 애플리케이션이 사용자 데이터에 액세스할 수 있도록 하는 개방형 인증 표준

소셜 미디어 플랫폼이나 API 같은 외부 서비스의 데이터에 액세스 해야하는 애플리케이션에서 사용

인증 플로우

Resource Owner : 자원 소유자 (User)

Client : 클라이언트 (ex. 3rd party app)

Service Provider : 서비스 제공자
- Resource Server : 자원 서버
- Authorization Server : 권한 서버

📖 참고 📖 OIDC (OpenID Connect)

인증(Authentication)/~~인가(Authorization)~~
➡️ ID Token 안에 인증 정보

Access Token : Bearer 토큰 형식

ID Toekn : JSON Web Toekn 형식
(누가 인증했는지, 발행자(issuer) 누구인지 확인 가능)

인증 플로우

6) 실습

모듈 설치

npm install express cookie-parser jsonwebtoken cors

로그인을 해서 access token, refresh token 발급 받음

// npm install express cookie-parser jsonwebtoken
// 보통 이런 토큰에 관한 내용은 따로 .env 파일에 놓습니다.
// 예제이기 때문에 한파일에 놓습니다.
// 토큰을 생성할 때 사용되는 비밀키
// 박종선바보멍청이 >> SHA256 >> 9e8821c8ef4ab43ba09310af54e98caedc13e314efdea720bf513b9b3675faf4 const ACCESS_TOKEN_SECRET= "9e8821c8ef4ab43ba09310af54e98caedc13e314efdea720bf513b9b3675faf4" const REFRESH_TOKEN_SECRET= "9e8821c8ef4ab43ba09310af54e98caedc13e314efdea720bf513b9b3675faf4"
const PORT = 12010
//라우팅설정을 쉽게, 미들웨어 설정을 쉽게 도와주는 express 프레임워크
const express = require('express');
// 쿠키 핸들링을 쉽게 해주는 모듈
const cookieparser = require('cookie-parser');
//jwt에 관한 로직을 설정할 수 있게 하는 모듈.
const jwt = require('jsonwebtoken')
// browser - postman에서 요청을 하게 되면 CORS가 걸리는데 이를 가능하게 해주는 모듈.
// CORS의 자세한 설명은 큰돌의 터전 - CORS를 참고.
const cors = require('cors')
const app = express();
// 미들웨어를 설정
app.use(cors())
app.use(express.json()); app.use(express.urlencoded({ extended: false })); app.use(cookieparser());
// DB에 있는 유저 정보를 흉내내는 객체 const userInfo = {
  username: 'kundol',
  password: '1234',
  email: 'kundol@gmail.com'
}
//토큰을 만들 때 쓰는 유저 객체 const user = {
  username: userInfo.username,
  email: userInfo.email
}
// 두개의 토큰에 대한 만료기한 옵션 : access토큰은 짧게. refresh토큰은 길게
const accessOpt = {
  expiresIn: '10m'
}
const refreshOpt = { expiresIn: '1d'
}
// 쿠키 옵션
const cookieOpt = {
  httpOnly: true,
  sameSite: 'Strict',
    secure: true,
  maxAge: 24 * 60 * 60 * 1000
}
const isAuthenticated = (req, res, next) =>{ if(!req.headers.authorization){
return next('route') }
let auth = req.headers.authorization
if (auth.startsWith("Bearer ")){
auth = auth.substring(7, auth.length);
}
const user = jwt.verify(auth, ACCESS_TOKEN_SECRET)
//인증된 유저가 있다면 다음 미들웨어로. 그게 아니라면 다음 라우팅으로. 제어권을 넘긴다.
if (user) return next()
else return next('route') }
app.get('/', isAuthenticated, function (req, res) { return res.status(200).send("허용된 요청입니다.")
})
app.get('/', (req, res) =>{
return res.status(401).send("허용되지 않은 요청입니다.") })
app.post('/login', (req, res) => {
const { username, password } = req.body; console.log(req.body)
console.log(username, password)
if (username === userInfo.username && password ===
userInfo.password) {
const accessToken = jwt.sign(user, ACCESS_TOKEN_SECRET,
accessOpt);
const refreshToken = jwt.sign(user, REFRESH_TOKEN_SECRET,
refreshOpt);
// cookie에는 refresh토큰을 담습니다.
// 이후 요청시에 refresh토큰을 기반으로 accesstoken을 갱신받습니다.
console.log("jwt토큰이 생성되었습니다.")
        console.log(refreshToken)
      console.log(accessToken)
      res.cookie('jwt', refreshToken, cookieOpt);
return res.json({ accessToken, refreshToken}); }
else {
//만약 인증을 하지 않은 경우
return res.status(401).json({message: "인증되지 않은
요청입니다."}); }
})
// access토큰 요청 전에 먼저 refresh 토큰 요청을 먼저 함. app.post('/refresh', (req, res) => {
console.log("REFRESH요청") console.log(req.cookies) if (req.cookies.jwt) {
const refreshToken = req.cookies.jwt; jwt.verify(refreshToken, REFRESH_TOKEN_SECRET, (err, decoded) => {
if (err) {
return res.status(401).json({ message: '인증되지
않은 요청입니다.' }); }else {
              console.log(decoded)
const accessToken = jwt.sign(user, ACCESS_TOKEN_SECRET, accessOpt);
return res.json({ accessToken }); }
}) } else {
return res.status(401).json({ message: "인증되지 않은 요청입니다." });
} })
app.listen(PORT, () => {
console.log(`서버시작 : http://localhost:${PORT}`); console.log(`로그인요청 : http://localhost:${PORT}/login`); console.log(`refresh요청 : http://localhost:${PORT}/refresh`);
})
/*
서버시작 : http://localhost:12010
로그인요청 : http://localhost:12010/login refresh요청 : http://localhost:12010/refresh {
  "username": "kundol",
  "password": "1234",
  "email": "kundol@gmail.com"
}
curl -X POST http://localhost:12010/refresh -H 'Content-Type:
application/json' --cookie
"jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Imt1bmRv
bCIsImVtYWlsIjoia3VuZG9sQGdtYWlsLmNvbSIsImlhdCI6MTY3MjI3MzgxNSwiZX
hwIjoxNjcyMzYwMjE1fQ.rAhD3tF11APHaSoxUp1F5DtNUte-5mt8HjawHoVVbns"
*/

📕 HTTP 상태코드

1. 1xx (정보)

서버가 요청 받음 + 해당 프로세스를 계속 처리 (HTTP1.0 이후 잘 사용X)
- 100 : 계속함

2. 2xx (성공)

서버가 요청 잘 받음 + 클라이언트에게 성공적으로 데이터 보낸 것
- 200 OK : 요청이 성공적으로 처리
- 201 CREATED : 요청이 성공적 + 그 결과 새로운 리소스 생성됨

3. 3xx (리다이렉션)

서버가 클라이언트 요청에 대해 완료하기 위해 추가 작업 조치 필요
- 301 MOVED_PERMANENTLY : 요청한 리소스의 URI가 변경되었음 (변경된 새로운 URI를 reponse로 전달)

4. 4xx (클라이언트 오류)

클라이언트가 요청한 페이지를 제공할 수 없음 / 클라이언트의 요청 문법 잘못되어 요청 처리 못함
- 400 BAD_REQUEST : 잘못된 문법으로 서버가 요청을 이해할 수 없음
- 401 UNAUTHORIZED : 클라이언트의 인증이 되지 않음
- 403 FORBIDDEN : 클라이언트가 콘텐츠 접근할 권리를 가지지X
- 404 NOT_FOUND : 서버가 요청받은 컨텐츠를 찾을 수 없음

5. 5xx (서버 오류)

서버가 클라이언트의 요청을 처리하지 못하는 상태
- 500 INTERNAL_SERVER_ERROR : 서버에 오류가 있음
- 502 BAD_GATEWAY : 게이트웨이/프록시서버가 오류가 생김
- 504 GATEWAY_TIMEOUT : 게이트웨이/프록시서버가 정해진 Timeout 시간동안 클라이언트 요청을 처리하지 못함

6. 실습

설치

npm install express

코드

const express = require('express') const app = express()
const port = 3000
app.get('/', (req, res) => { res.status(401).send('인증되지 않은 요청입니다.')
})
app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

📕 HTTP 메서드

1. HTTP 메서드 개념

종류
- GET
- POST
- PUT
- HEAD
- DELETE
- PATCH
- OPTIONS
- CONNECT
- TRACE

2. GET과 POST 차이

GET : 데이터 읽기
- url 기반으로 데이터 요구 (길이 제한 2000자 미만)
  ➡️ 해당 요청의 파라미터가 브라우저 기록에 남음
  ➡️ 요청할 때 ASCII 문자열만 보낼 수 있음
- 성공시 : HTTP 상태코드 200 반환
- 오류시 : 404(NOT_FOUND) 또는 400(BAD_REQUEST) 반환
- 캐싱 가능
- 사용자 이름, 비밀번호 등 민감한 정보 전달시 사용X
POST : 데이터 생성
- url이 아닌 HTTP message body를 통해 데이터 전달 (길이 제한 없음)
  ➡️ 해당 요청의 파라미터가 브라우저 기록에 남지 않음
  ➡️ 요청할 때 ASCII 문자열 뿐만 아니라 모든 유형의 데이터 기반으로 요청 가능
- 성공시 : HTTP 상태코드 201 반환 (생성한 경우 201, 생성하지 않은 경우 200)
- 캐싱 불가능
- 사용자 이름, 비밀번호 등 민감한 정보 전달시 사용
실습

3. PUT과 PATCH 차이

PUT : 데이터 전체 수정
- 요청을 보낼 때 데이터 전체 교체
- 해당 데이터가 없을 경우 생성 / 있을 경우 보낸 데이터와 교체
- 성공시 : 수정된 결과값 전달
PATCH : 데이터 일부 수정
- 요청을 보낼 때 수정하는 일부분만 교체
- 성공시 : 수정된 결과값 전달
실습

// 예를 들어 email: "kundol@naver.com"을 수정한다고 했을 떄 const obj = {
    "id": 2,
    "email": "kundol@naver.com",
    "first_name": "Janet",
    "last_name": "Weaver",
    "avatar": "https://reqres.in/img/faces/2-image.jpg"
}
const obj2 = {
    "email": "kundol@naver.com"
}
// PUT
const PutRequest = () => { fetch("https://reqres.in/api/users/2", {
      headers: {
        "Accept": "application/json",
        "Content-Type": "application/json"
    },
    method: "PUT",
    body: JSON.stringify(obj)
}).then(res => res.json())
.then(data => console.log(data))
PutRequest();
// PATCH                          
const PatchRequest = () => {
    fetch("https://reqres.in/api/users/2", {
            headers: {
};
        "Accept": "application/json",
        "Content-Type": "application/json"
    },
    method: "PATCH",
    body: JSON.stringify(obj2)
}).then(res => res.json())
.then(data => console.log(data))
PatchRequest();
/* {
  id: 2,
  email: 'kundol@naver.com',
  first_name: 'Janet',
  last_name: 'Weaver',
  avatar: 'https://reqres.in/img/faces/2-image.jpg',
  updatedAt: '2022-12-19T01:13:39.638Z'
}
{ email: 'kundol@naver.com', updatedAt: '2022-12-19T01:13:39.639Z'
}
*/

📕 OSI 7계층

1. PDU

2. 계층별 네트워크 장치

애플리케이션 계층 : L7 스위치
전송 계층 : L4 스위치
인터넷 계층(네트워크 계층) : 라우터, L3 스위치
데이터링크 계층 : L2 스위치, 브리지
물리 계층 : NIC, 리피터, AP

3. 애플리케이션 계층

1) 개념
- 응용 프로세스와 직접 관계하여 서비스 수행
- 프로토콜 : HTTP, FTP, SMTP, POP3, IMAP, Telnet
2) L7 스위치
- IP주소, TCP/UDP 포트 정보 및 패킷 내용 참조하여 스위치
- L4 스위치 기능 + 컨텐츠 기반 제어
- 서버 이중화, 보안에 강점 (웹 방화벽 및 보안 스위치에 사용)
- 서버의 부하를 분산하는 기기 (로드밸런서)
  - IP, Port 뿐만 아니라 url, 헤더, 쿠키 기반으로 트래픽 분산
- 헬스체크를 통해 장애가 발생한 서버 확인 ➡️ 해당 서버로 트래픽을 보내지 못하게 하는 역할

📖 참고 📖 헬스체크

서버의 정상/비정상 여부 판별

전송 주기와 재전송 횟수 등을 설정한 후 반복적으로 서버에 요청을 보냄

L4 또는 L7 스위치에 사용

📖 참고 📖 서버 이중화

로드 밸런서의 대표적 기능

서비스를 안정적으로 이용하기 위해서 2대 이상의 서버 필수적

에러가 발생하여 서버 1대 종료해도 안정적으로 운용 목적

4. 전송 계층

1) 개념
- 두 지점간 신뢰성 있는 데이터 주고받는 역할 (port 번호, 전송방식 결정)
- 에러 제어, 경로 제어
- 프로토콜 : TCP, UDP
2) L4 스위치
- IP주소, TCP/UDP 포트 정보 참조하여 스위치
- L3 스위치 기능 + 로드 밸런싱
- 서버의 부하를 분산하는 기기 (로드밸런서)
  - 패킷의 IP주소와 Port번호를 참고해서 트래픽 분산
  - TCP, UDP 헤더를 기반으로 우선순위를 판단해서 스위칭 판단 가능
- 헬스체크를 통해 장애가 발생한 서버 확인

5. 네트워크 계층

1) 개념
- 라우터를 통해 경로 선택 + 주소 지정 + 패킷 전달
- 단위 : packet
- 장비 : router
2) 라우터
- 네트워크에서 경로를 선택하는 장비
- 다른 네트워크에 존재하는 장치끼리 데이터 주고 받을 경우 ➡️ 패킷 소모 최소화, 경로 최소화
3) L3 스위치
- IP주소 참조하여 스위치
- L2 스위치 기능 + 라우팅
- 라우팅테이블을 참조해서 IP패킷에 IP주소를 담아 보냄
- 패킷 목적지 주소가 라우팅테이블에 없을 경우 패킷 버림

6. 데이터링크 계층

1) 개념
- 송수신되는 정보의 오류와 흐름을 관리하여 통신의 흐름을 관리 (프레임에 MAC주소 부여)
- 에러 검출, 재전송, 흐름 제어
- 단위 : frame
- 장비 : bridge, switch, Ethernet
2) L2 스위치
- MAC address 참조하여 스위치
- 장치들의 MAC 주소를 MAC 주소 테이블을 통해 관리
- 네트워크 계층에서 받은 패킷을 기반으로 이더넷프레임 만들어 목적지MAC주소로 패킷 보내주는 역할
3) 브리지
- 두 개의 LAN을 상호 접속 할 수 있도록 하는 통신망 연결 장치 (포트간 다리 역할)
- 통신망의 범위 확장 or 서로 다른 LAN을 기반으로 하나의 통신망 구축

7. 물리 계층

1) 개념
- 무선LAN과 유선LAN을 통해 0/1로 이루어진 데이터를 보내는 계층
- 단위 : bit
- 장비 : repeater, hub, 통신 케이블
2) NIC (Network Interface Card)
- LAN 카드
- 2대 이상의 컴퓨터 네트워크를 구성하는데 사용
- 네트워크와 빠른 속도로 데이터 송수신 하도록 PC에 설치된 확장 카드
- 장치에 PC 고유의 식별번호(MAC 주소) 저장
3) 리피터
- 들어오면서 약해진 신호 증폭하여 다른 쪽으로 전달하는 장치
- 패킷 더 멀리 보냄
- 광케이블 보급으로 현재 사용X
4) AP (Access Point)
- 패킷을 복사하는 장치
- AP에 유선 LAN을 연결한 후 다른 장치에서 무선 LAN기술(wifi 등)을 사용하여 무선 네트워크 연결 가능

📖 참고 📖 OSI 7계층 vs TCP/IP 4계층

OSI 7계층 : 네트워크 전송의 데이터 표준 정림

TCP/IP 4계층 : 실제 인터넷 통신을 반영한 인테넛 표준

📖 참고 📖 유선 LAN

동축케이블, 광케이블 기반으로 만들어진 유선LAN을 이루는 이더넷은 IEEE802.3 프로토콜을 기반으로 전이중화 통신을 사용

광역 통신망 기술에도 활용되지만 일반적으로 근거리 통신망 기술

✏️ IEEE802.3

연결된 이더넷에서 물리 계층, 데이터링크 계층의 매체 접근 제어를 정의하는 Working Group

이더넷프레임을 어떤 구조 기반인지, 케이블의 최대 전송량, 어떤 케이블만 가능한지 등 정한 규칙

✏️ 전이중화 통신 (Full Duplex)

양쪽 장치가 동시에 송수신할 수 있는 방식

송신로, 수신로 나눠서 데이터 주고받음

현대 고속 이더넷의 기반

✏️ CSMA/CD (Carrier Sense Multiple Access with Collision Detection)

충돌 감지 기능을 사용해 충돌 여부 확인

IEEE 802.3 LAN의 이더넷 전송 프로토콜에서 사용

1️⃣ 회선감지 : 송신 전에 회선이 비어있는지 확인 (Carrier Sense)

2️⃣ 데이터 전송 : 비어있을 경우 네트워크상 모든 컴퓨터가 데이터 전송위해 동시에 액세스 시도 (Multiple Access)

3️⃣ 충돌 발생 : 동시에 데이터 전송할 경우 충돌 발생 후 네트워크 상의 다른 컴퓨터에게 충돌 알림 (Collision Detection)

4️⃣ 회선 감지: 충돌 있을 경우 일정 시간 대기 후 재전송

CSMA방식 단말의 증가에 따라 동시 전송(충돌)할 확률 높아지는 문제점 개선

📖 참고 📖 무선 LAN

IEEE802.11 표준규격을 따르며 반이중화 통신을 사용

무선랜, wifi 등 무선 근거리 통신망을 위한 컴퓨터 무선 네트워크에 사용되는 기술

✏️ 반이중화 통신 (Half Duplex)

양쪽 장치는 서로 통신할 수 있지만, 동시에는 통신X

한 번에 한 방향만 통신하는 방식

장치가 신호를 수신하기 시작하면, 바로 응답할 수 없고 수신이 완료될 때까지 대기

✏️ CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)

충돌 회피 기능 사용

장치에서 데이터 보내기 전 Carrier 감지 등으로 사전에 가능한 충돌 방지

IEEE 802.11 무선 랜 전송 프로토콜에서 사용

1️⃣ 회선 감지 : 송신 전에 회신이 비어있는지 확인 (Carrier Sense)

2️⃣ IFS 대기 : 채널이 idle 해도 IFS 동안 대기하여 전송 늦춰 충돌 피함

IFS(InterFrame Space) 프레임간 공간

IFS 작으면 프레임 우선순위 높음

3️⃣ Cotention Window 대기

Contention Window는 time-slot으로 나뉜 일정 시간

전송할 준비가 된 노드는 random 수(0~(2^k-1))만큼 대기 후 프레임 전송

노드는 매 time-slot 뒤에 채널 감지

해당 시간동안 busy 상태면 타이머 중지 후 idle 상태가 되면 다시 타이머 시작

충돌 가능성 있을 경우 피함 (Collision Avoidcnace)

4️⃣ 데이터 전송

프레임 제대로 받고 + ACK 세그먼트 받을 경우 ➡️ 종료

프레임 받지 못할 경우 ➡️ k = k + 1 위 과정 반복 (k가 정해진 Kmax보다 커지면 해당 프레임 전송 버림)

📕 대규모 트래픽으로 인한 서버 과부하 해결방법

1. 서버 과부하

1) 개념
- 서버가 리소스를 소진하여 들어오는 요청을 처리하지 못함
- 🗒️ 예시 : 서버는 사용자의 웹요청을 처리하지 못해 응답없음이 뜸
2) 해결 방법
- 모니터링을 통한 자원 할당
- 로드밸런서
- 블랙스완 프로토콜
- 서킷 브레이커
- 컨텐츠 관리

2. 모니터링을 통한 자원 할당

1) 원인
- 자원(CPU, 메모리, 대역폭 등)의 한계점 도달
- 보통 서버의 CPU 사용량이 80~90%에 도달하거나 메모리가 부족해 계속 스와핑하면 과부하
2) 모니터링
- 서버 과부화로 인한 서버 중지 대처
  - 어떤 페이지에 어떤 트래픽이 얼마나 발생했는지 확인
  - 어떤 네트워크에서 병목현상이 일어났는지 확인
- 모니터링을 하면 페이지 활용도 높은지/낮은지 파악하여 서비스 개선에 도움
- 해결하기 위한 문제점 파악
- cloudflare는 모니터링 결과와 함께 서비스 중단 여부를 사용자에게 알림
3) AWS 오토스케일링
- 서비스 이용불가능 상태 발생 이전 cloud watch가 계속 모니터링하여 서버 대수 늘려주는 방법
- 애플리케이션을 자동으로 모니터링하고 자원의 용량을 자동으로 조정함
4) netdata를 이용한 모니터링
- AWS 대체하는 무료 모니터링 서비스
- 지속적인 모니터링, 자원할당 해결
- slack과 연동하여 설정한 임계치를 기반으로 알림서비스 구축 가능

3. 로드밸런서

1) 개념
- 서버 앞단에서 로드밸런스 통해 트래픽 분산
- 한 서버에 장애가 발생하면 트래픽을 다른 기능 서버로 리다이렉션하여 시스템 중단 방지

4. 블랙스완 프로토콜

1) 블랙스완 개념
- 예측할 수 없는 사고가 일어난 것
- 사후에는 이 사고의 원인 분석할 수 있지만, 사전에는 사고를 예측할 수 없음
2) 블랙스완 발생시 운영 수칙
- 영향을 받은 시스템과 각 시스템의 상대적 위험 수준을 확인
  - 체계적으로 데이터 수집
  - 원인에 대한 가설을 수립한 후 테스팅
- 잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락
- 최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
- 복원 계획을 포함한 우리의 대응 과정을 파트너/고객 등 외부에 전달

5. 서킷 브레이커

1) 개념
- 서비스 장애를 감지하고 연쇄적으로 생기는 오류 전파를 방지하는 기법
- 연쇄적 장애 전파 막기 위해 자동으로 외부 서비스와 연결을 차단/복구
- 서비스-서비스간 서킷브레이커 계층을 둠
- 연속적인 에러를 막아 일부 서비스 종료되더라도 다른 서비스 동작 가능
2) 서킷 브레이커 동작과정
서킷 브레이커를 서비스간 사이에 넣고 관련 함수들 래핑
네트워크 장애를 모니터링하여 특정 서비스가 timeou으로 설정된 시간 초과할 경우
- 몇번의 요청을 한 이후에도 계속 timeout 시간을 초과하면 장애로 인식 (에러 반환)
서킷 브레이커가 trip 되며 그 이후 추가적인 호출은 발생X (fail fast)
- trip : 서킷 브레이커 open 된 상태
- closed 상태라면 기본적인 요청 수행하고, open된 상태라면 요청 수행하지 않고 빠르게 오류 반환
3) 서킷 브레이커 상태
- closed[정상] : 네트워크 요청의 실패율이 임계치보다 낮음
- open[오류] : 임계치 이상의 상태, 요청을 서비스로 전송하지 않고 바로 오류 반환 (fail fast)
- half_open[확인중] : 장애가 해결되었는 지 확인을 위해 요청을 전송하여 응답 확인 (장애 풀리는지 확인 후 성공시 closed, 실패시 open)
4) 구현
- 넷플릭스의 Hystrix와 Resilience4j

6. 컨텐츠 관리

1) 불필요한 컨텐츠 제거
- 불필요한 쿼리 등 제거
  - 인덱스를 추가하거나 쿼리를 변경해서 인덱스 사용하도록 개선
  - 개선이 안되는 쿼리라면 차라리 기능 OFF
  - select *로 조회하던 쿼리에서 실제 기능이 사용되지 않는 칼럼 모두 제거
- 🗒️ 예시 : 인프런의 장애 복구 사례
  - 고용량의 컬럼을 강의 관련 쿼리에서 조회 항목에 포함시켜 가져옴
2) CDN을 통한 컨텐츠 제공
- 분산된 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 서버 부하 줄임
- CDN (Content Delivery Network) : 분산된 서버를 연결한 네트워크
3) 컨텐츠 캐싱
- 브라우저 캐시(쿠키, 로컬저장소, 세션저장소)를 통해 해당 요청에 관한 항목을 캐시에서 응답을 읽어 네트워크 요청에 관한 비용을 모두 제거
4) 컨텐츠 압축
- 텍스트 기반 리소스는 gzip 또는 Brotli 통해 압축함 (70% 까지 압축)
- 압축을 풀기 위해 서버에서 자원(CPU)를 사용하는 양 고려 필요
5) 컨텐츠 미리 준비된 응답
- 시스템의 과도한 부하를 줄이기 위해 제공하는 컨텐츠 및 기능일 일시적으로 줄임
- 방식
  - 정적 테스트 페이지 제공
  - 검색 비활성화
  - 더 적은 수의 검색 결과 반환
  - 필수적인지 않은 기능 비활성화

📕 REST API

1. 개념

RESTful한 API

2. 특징

1) Uniform-Interface

API에서 자원들은 각각의 독립적인 인터페이스를 가짐
각 자원들이 url 자원식별, 표현을 통한 자원조작, Self-descriptive messages, HATEOAS 구조를 가짐
독립적인 인터페이스 : 서로 종속적이지 않은 인터페이스
🗒️ 예시 : 웹페이지를 변경했다고 웹 브라우저를 업데이트 하지X, HTTP 명세가 변경되어도 웹페이지 작동에 영향X
url 자원식별 : identification of resources
자원은 url로 식별되어야 함
표현을 통한 자원조작 : manipulation of resources through representation
url과 GET, DELETE 등 HTTP 표준메서드 등을 통해 자원을 조회, 삭제 등 작업을 설명할 수 있는 정보가 담겨야 함
Self-descriptive messages : HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 함
🗒️ 예시 : .json을 반환하면 application/json으로 명시
MIME types는 문서, 파일 등 특성과 형식을 나타내는 표준
IETF의 RFC6838에 정의 및 표준화 되어 있음
font/ttf, text/plain, text/csv

구현

const express = require('express')
const app = express()
app.get('/good',(req, res) =>{
  res.status(200).json({"a" : 1})
})
app.get('/bad',(req, res) =>{ 
res.setHeader('content-type', 'application/json'); // json()메서드 쓰게 되면, application/json 형식
res.send("큰돌이")
})
const server = app.listen(12010, () =>{
console.log("오늘도 재밌는 CS공부서버 ~ : http://127.0.0.1:12010/good") })

HATEOAS 구조 (Hypermedia As The Engine Of Application State)
하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해줘야 함
href, links, link, url 속성 중 하나에 해당 데이터의 URL을 담아서 표기
_links 속성에 담기도 함, 링크를 유추할 수 있는 변수명 사용
동적으로 링크를 만들며 href속성을 통해 설정
rel은 relation으로 링크와 요청한 자원과의 관계를 나타냄
self : 해당 자원에 대한 링크를 나타냄

상세한 내용을 보여준다면 detail, 책을 사는 정보를 담고 있다면 buybook 등 들어감

const express = require('express'); const app = express();
const books = [
{ id: 1, title: '자바스크립트 풀스택 MEVN', author: '큰돌1'}, { id: 2, title: 'CS지식노트', author: '큰돌2'},
{ id: 3, title: '자바스크립트 어나더레벨', author: '큰돌3'},
];
app.get('/books', (req, res) => {
const bookCollection = books.map((book) => ({
...book,
  links: [{ rel: 'self', href: `/books/${book.id}` }]
}));
res.status(200).json(bookCollection);
});
app.get('/books/:id', (req, res) => {
const bookId = parseInt(req.params.id);
const book = books.find((book) => book.id === bookId);
if (book) {
book.links = [{ rel: 'self', href: `/books/${book.id}` }]; res.status(200).json(book);
} else {
res.status(404).json({ error: 'Book not found' });
} });
app.listen(12010, () => { console.log('큰돌이의 책서버 시작 :
http://127.0.0.1:12010/books');
});

link 속성을 기반으로 설정
데이터 하나당 link 한개가 아니라 데이터 여러개 당 link 한개로 걸 수 있음
```
{"link":http://kundol.net/todos/{id}, "data":[{...}]}
```

실제 github에서 제공하는 REST API, url 속성을 기반으로 설정

[ {
  "url":
"https://api.github.com/repos/octocat/Hello-World/milestones/1",
  "html_url":
"https://github.com/octocat/Hello-World/milestones/v1.0",
  "labels_url":
"https://api.github.com/repos/octocat/Hello-World/milestones/1/lab
els",
  "id": 1002604,
  "node_id": "MDk6TWlsZXN0b25lMTAwMjYwNA==",
  "number": 1,
  "state": "open",
  "title": "v1.0",
  "description": "Tracking milestone for version 1.0",
  "creator": {
    "login": "octocat",
    "id": 1,
    "node_id": "MDQ6VXNlcjE=",
    "avatar_url":
"https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "",
    "url": "https://api.github.com/users/octocat",
    "html_url": "https://github.com/octocat",
    "followers_url":
"https://api.github.com/users/octocat/followers",
    "following_url":
"https://api.github.com/users/octocat/following{/other_user}",
    "gists_url":
"https://api.github.com/users/octocat/gists{/gist_id}",
    "starred_url":
"https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url":
"https://api.github.com/users/octocat/subscriptions",
    "organizations_url":
"https://api.github.com/users/octocat/orgs",
    "repos_url": "https://api.github.com/users/octocat/repos",
    "events_url":
"https://api.github.com/users/octocat/events{/privacy}",
    "received_events_url":
"https://api.github.com/users/octocat/received_events",
    "type": "User",
    "site_admin": false
  },
  "open_issues": 4,
  "closed_issues": 8,
  "created_at": "2011-04-10T20:09:31Z",
  "updated_at": "2014-03-03T18:58:10Z",
  "closed_at": "2013-02-12T13:22:01Z",
  "due_on": "2012-10-09T23:39:01Z"
} ]

2) Stateless
- HTTP가 stateless이기 때문에 HTTP 이용하는 것만으로 만족
- REST API에서 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 않는다는 의미
3) Cacheable
- HTTP는 캐싱 가능 (cache-control = public 기본, cache-control = no=store 캐싱 안됨)
- 아무런 로직을 구현하지 않더라도 자동적으로 캐싱됨
- 새로고침을 하면 304가 뜨면서 원래 있던 js와 css 이미지를 불러옴
- HTTP 메서드 중 GET에 한정되며 'Cache-control:max-age=100(100초)' 이런 형식으로 한정된 시간 정함
- 캐싱된 데이터가 유효한지 판단하기 위해 'Last-modified'와 'Etag'라는 헤더값 사용
- 'Etag'는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지 확인해줌
4) Client-Server 구조
- 클라이언트와 서버가 서로 독립적인 구조여야 함
- HTTP를 통해 가능한 구조
- 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타남
- 서버는 API를 제공하고, API에 맞는 비즈니스 로직을 처리함
- 클라이언트는 HTTP로 받는 로직만 잘 처리함
5) Layered System
- 계층구조로 나눠져 있는 아키텍처
- WEB기반 서비스를 하면 계층 시스템 구축함

2. URI 규칙

1) 동작은 HTTP 메소드만 해야하고 url에 해당 내용이 들어가면 안됨
- 수정 = put, 삭제 = delete, 추가 = post, 조회 = get 이용
- 🗒️ 예시 : /books/delete/1 금지
2) .jpg, .png 등 확장자 표시X
3) 동사가 아닌 명사로 표기
- 🗒️ 예시 : '유저가 책을 소유한다' 표현할 경우
  - 유저/유저아이디/inclusion/책/책아이디 로 표현
- 🗒️ 예시 : '유저가 소유한 아파트를 조회한다' 표현할 경우
  - /users/{userid}/aprst
4) 계층적인 내용 담기
5) 대문자가 아닌 소문자로 쓰기
- 너무 길 경우에 언더바(_) 아닌 하이픈(-) 사용
6) HTTP 응답 상태코드를 활용
- 성공시에 200
- 리다이렉트 301
🗒️ 예시 : 도서관 시스템 REST API 생성

app.get('/books')
// 모든 책을 조회합니다. app.post('/books/:booksid')
// 책을 생성합니다. app.put('/books/:booksid')
// 책을 수정합니다. app.get('/books/:booksid')
// 특정 책을 조회합니다. app.put('/users/:userid/books/:booksid') // 어떤 유저가 특정 책을 빌립니다. app.patch('/users/:userid/books/:booksid') // 어떤 유저가 특정 책을 빌립니다.

🗒️ 예시 : 쿼리스트링과 혼합한 url
- REST API는 /를 기반으로 구축되지만, 적절히 쿼리스트링을 혼재해서 사용
- 검색, 페이지네이션, 정렬 등 매개변수가 많거나 복잡할 때 쿼리스트링 사용
- 실제 워드프레스에서 제공하는 REST API (posts의 2번째 결과물을 나타냄) : /wp/v2/posts?page=2
- 실제 KAKAO API : /oauth/token?grant_type=refresh_token&client_id=${REST_API_KEY}
- 바벨이 필요한 운동정보 가져오기 : /api/v1/workouts?equipment=barbell
- 모든 운동정보를 생성날짜 기준으로 내림차순으로 가져오기 : /api/v1/workouts?sort=-createdAt

📕 브라우저 렌더링 과정

1. 브라우저 렌더링 과정

1) 브라우저 구성
- 브라우저 엔진
- 렌더링 엔진
- 네트워크 통신부
- 자바스크립트 해석기
- UI 백엔드
- 자료저장소
2) 과정
- 렌더링 엔진이 브라우저 렌더링을 담당
- DOM트리, CSS파서 등 기반으로 렌더트리 구축해 화면 구축

2. DOM 트리와 CSSOM 트리 구축 (Parsing)

1) 과정
- HTML 문서를 파싱해 브라우저가 이해할 수 있는 자료구조(DOM 트리) 생성
- DOM 트리는 HTML element들이 하나하나 노드로 구성
- HTML 파싱 중 CSS 파일을 로드하는 link/style 태그를 만나면 DOM 트리 생성 중단
  ➡️ CSS 파일을 서버로부터 요청하고, HTML과 동일한 파싱과정을 거쳐 CSSOM 트리 생성
- CSS 파싱을 전부 완료하면 다시 HTML 파싱 재개
2) DOM 트리 구축
- html 페이지의 div, span 등 요소가 HTML파서에 의해 구문 분석됨
- 요소는 하나하나가 노드로 설정되어 트리 형태로 저장
3) CSSOM 트리 구축
- 각 노드는 CSS파서에 의해 정해진 스타일 규칙이 적용됨
- DOM트리 구축과 동시에 일어남

3.렌더트리 생성 (Style)

DOM 트리와 CSSOM 트리를 순서에 맞게 결합하여 렌더객체 (Render Object) 생성
- 랜더객체가 모여 렌더트리 생성
렌더 트리는 레이아웃에서 공간을 차지하지 않는 요소는 포함X
- disply:none인 요소
- 상속적인 스타일은 부모 노드에만 위치

📖 참고 📖 display:none 와 visibility:hidden 차이

display:none : 렌더트리에서 삭제됨

visibility:hidden : 요소는 보이지 않지만, 삭제되지 않고 레이아웃에 공간 차지함

4. 렌더 트리의 정보를 토대로 위치와 크기 계산 (Layout)

루트에서부터 탐색하여 실제 기기 화면의 크기에 맞춰 노드의 정확한 위치와 크기 계산
- 상대적이었던 측정값을 화면안에서의 절대적인 픽셀로 변환하는 과정
- 좌표는 부모를 기준으로 설정
브라우저 사이즈를 변경하거나 폰트 변경시 Global Layout 발생
- Global Layout : 전체를 Layout 하는 것 (브라우저 사이즈가 증가하거나 폰트 사이즈 커지면 변경됨)

5. Render Object를 정해진 기준에 따라 Layer 나눔 (Update Layer Tree)

렌더 레이어가 완성될 때 GPU에서 처리되는 부분은 Graphic Layer로 분리
- GPU 처리 부분 : CSS3D/ video & canvas / filter / animation / tramsform : tranlateZ(0)
나머지는 Rander Layer로 분리

6. Layout 단계에서 계산된 값을 이용해 각 Layer를 화면상에서 실제 픽셀로 변환 (Paint)

픽셀마다 점을 찍듯 칠함 (레스터화)
픽셀로 변환된 결과는 하나의 레이어가 아니라 여러 개의 레이어로 관리됨

7. 레이어 합치기 및 표기 (Composite Layer)

각각 레이어로부터 비트맵이 생성되고, GPU에 텍스처로 업로드
텍스처들은 서로 합쳐져 하나의 이미지로 렌더링되며 화면으로 출력

📖 참고 📖 Render트리와 DOM트리는 1:1 대응일까

NO

DOM트리 > 렌더객체 > 렌더트리 되는 과정에서 display:none으로 사라지는 렌더 객체(노드)들이 있어서 1:1 대응 안됨

📕 www.naver.com을 쳤을 때 생기는 과정

1. 과정

1) 리다이렉트, 캐싱, DNS, IP 라우팅, ARP, TCP 연결 구축을 거쳐 컨텐츠 요청, 응답하는 TTFB(Time to First Byte)
2) 컨텐츠 다운받고, 브라우저 렌더링 과정을 거쳐 네이버 화면 나타남

2. 리다이렉트

1) 개념
- 'URL을 다시 가리킨다'는 의미
- 서버에서 클라이언트가 요청한 URL에 응답에서 다른 URL로 재접속하라고 명령 보냄
2) 과정
- 리다이렉트 있으면 진행하고, 없으면 해당 요청에 대한 과정 진행

3. 캐싱

1) 과정
- 해당 요청이 캐싱 가능한지/아닌지 파익
- 요청된 값의 캐싱된 값을 저장하고, 그 값 다시 요청할 때 빠르게 제공
- 브라우저 캐시/공유 프록시 캐시로 나뉨
2) 브라우저 캐시
- 쿠키, 로컬스토리지 등 포함한 캐시
- 개인캐시 (private cache)
- 사용자가 HTTP를 통해 다운로드 하는 모든 문서를 브라우저 자체에 저장
- 🗒️ 예시 : 사이트 재방문시 컨텐츠가 빠르게 표시되는 경우
3) 공유 프록시 캐시
- 서버에서 프록시서버가 캐싱
- 클라이언트와 서버 사이에 있고, 사용자간에 공유할 수 있는 응답 저장
- 요청한 서버 앞단에 프록시 서버가 캐싱하는 것
  - 리버스 프록시를 둬서 내부 서버로 포워드함
- 🗒️ 예시 : Node.js(웹서버) 앞단에 Nginx서버(프록시 서버)를 둬서 캐싱서버로 이용

4. DNS

1) DNS(Domain Name Server)
- 도메인명과 IP주소를 매핑해주는 서버
  - 계층적인 도메인 구조와 분산된 데이터베이스를 이용한 시스템
  - FQDN을 인터넷 프로토콜인 IP로 바꿔주는 시스템
- 리졸버와 네임서버로 구성
  - 리졸버 : DNS관련 요청을 네임서버로 전달하고, 해당 응답값을 클라이언트에게 전달
  - 네임서버 : 도메인을 IP로 변환
2) 과정
- 브라우저가 요청 IP 주소를 확인하는 단계
- FQDN인 www.naver.com 등의 이름을 DNS를 통해 실제 IP 주소 확인
- DNS서버로 요청을 전달하기 전에 캐시를 먼저 확인 후 캐시미스일 경우 요청
- 🗒️ 예시 : www.naver.com에 DNS 쿼리가 올 경우
  - Root DNS ➡️ .com DNS ➡️ .naver DNS ➡️ .www DNS
  - 맞는 주소를 찾아 IP 주소로 매핑

📖 참고 📖 FQDN (Fully Qualified Domain Name)

호스트와 도메인이 합쳐진 완전한 도메인 이름

호스트 : www 등

도메인 : naver.com

3) DNS 캐싱
- 미리 해당 도메인 이름 요청했을 경우 local PC에 자동적으로 저장됨
- 브라우저 캐싱과 OS캐싱으로 구성
  - 브라우저 캐싱 : chrome://net-internals#dns
  - OS 캐싱 : ipconfig/displaydns

5. IP 라우팅

해당 IP를 기반으로 IP 라우팅과 ARP 과정을 거쳐 실제 서버를 찾음

6. TCP 연결 구축

브라우저가 TCP 3-way handshake 및 SSL 연결 등 통해 연결 설정
- TCP 연결은 HTTP/2 까지 일어남
- HTTP/3은 QUIC를 통해 연결하고, 데이터를 주고받음
연결 설정된 후 요청을 보내면 해당 서버로부터 응답 받음

7. 콘텐츠 다운로드

브라우저가 서버로부터의 응답 수신
브라우저는 사용자가 요청한 컨텐츠를 서버로부터 다운받음

8. 브라우저렌더링

받은 데이터를 바탕으로 브라우저 엔진이 브라우저렌더링 과정을 거쳐 화면을 만듦
🗒️ 예시 :

📖 참고 📖

✏️

📕 이더넷 프레임

1. 개념

데이터링크 계층의 데이터 단위
이데넛 프레임을 기반으로 데이터 전달

2. 구성

Preamble[7바이트]
- 이더넷 프레임이 시작임을 알림
SFD[1바이트]
- Start Frame Delimiter
- 다음 필드로부터 주소필드가 시작됨을 알려줌
Destination Address[6바이트]
- 목적지 주소
Source Address[6바이트]
- 시작지 주소
Ether Type[2바이트]
- 데이터링크 계층 위의 IP 프로토콜을 정의 (IPv4/IPv6)
Payload[가변바이트]
- 데이터 또는 페이로드
- 가변길이 필드
- 해당 필드는 이진데이터(0/1)로 구성
- IEEE 표준은 최대 페이로드를 1500 바이트로 지정함
FCS[4바이트]
- Frame Check Sequence
- 수신측의 에러검출을 위해 삽입되는 필드
- CRC 에러검출 기법에 의해 생성된 비트배열이 담김
- 비트배열을 기반으로 수신된 데이터가 손상되었는지 확인하고, 에러 확인시에는 해당 프레임 폐기하고 송신측에 재전송 요구

수현

Notion으로 이동 (https://24tngus.notion.site/3a6883f0f47041fe8045ef330a147da3?v=973a0b5ec78a4462bac8010e3b4cd5c0&pvs=4)