Ch.8 네트워크 | CS Visualizer

PACKET

패킷의 여행 (How Packets Travel)

여러분이 google.com을 열면, 데이터는 '패킷'으로 쪼개져 여러 라우터를 거쳐 목적지에 도달합니다. 각 라우터는 '다음에 어디로 보낼지'만 결정합니다 — 마치 우편물이 중간 우체국을 경유하듯. TTL(Time to Live)은 매 홉마다 1씩 감소합니다.

노드를 클릭하거나 패킷 전송을 시작하세요.

TRACEROUTE 시뮬레이션

1192.168.1.1(공유기)— ms

2210.100.45.1(ISP)— ms

372.14.197.2(백본 A)— ms

4108.170.246.3(백본 B)— ms

5142.250.80.46(Google)— ms

IP 주소와 서브넷 (IP Addressing)

IP 주소는 인터넷의 '집 주소'입니다. IPv4는 32비트 = 4개의 숫자(0-255). 서브넷 마스크는 '어디까지가 네트워크 주소인가'를 정의합니다. /24(255.255.255.0)는 마지막 8비트만 호스트 주소로 씁니다 = 254개의 주소.

IP 주소

서브넷 CIDR

/24

32비트 이진수 표현 (파란색=네트워크, 주황색=호스트)

네트워크 주소—

브로드캐스트—

서브넷 마스크—

사용 가능한 호스트 수—

공인 IP vs 사설 IP — NAT 변환

사설 IP 대역 (인트라넷)

10.0.0.0 /8

172.16.0.0 /12

192.168.0.0 /16

인터넷에서 라우팅 불가. 내부 네트워크 전용.

NAT →

NAT 공유기

사설 IP + 포트 ↔ 공인 IP + 포트 매핑 테이블 유지

→

공인 IP (인터넷)

203.0.113.45

ISP가 할당. 인터넷에서 라우팅 가능.

TLS

HTTPS와 TLS 핸드셰이크

HTTP는 평문(암호화 없음)이라 중간에서 도청 가능합니다. HTTPS는 TLS(Transport Layer Security)로 암호화합니다. TLS 1.3 핸드셰이크는 안전한 채널을 만드는 과정입니다.

🔓 핸드셰이크 대기 중...

HTTP (평문)

GET /login HTTP/1.1
Host: bank.com
Authorization: password=1234
← 스니핑 시 그대로 노출!

HTTPS (TLS 암호화)

17 03 03 00 28 8f a3 2c
e1 b4 7d 91 0a 55 cf 2b
3e 84 ...
← 스니핑해도 암호문만!

HTTP

HTTP 요청 / 응답

메서드와 상태코드를 선택하여 HTTP 메시지 구조를 확인하세요. HTTP/1.1은 요청당 하나의 응답(HOL 블로킹), HTTP/2는 스트림 멀티플렉싱으로 여러 요청을 동시 처리합니다.

HTTP 메서드

응답 상태코드

REQUEST →

← RESPONSE

HTTP/1.1 vs HTTP/2 — 멀티플렉싱

HTTP/1.1 (순차 처리)

req1

HTML

req2

CSS (대기)

req3

JS (대기)

HOL 블로킹: 앞 요청이 완료될 때까지 대기

HTTP/2 (스트림 멀티플렉싱)

stream 1

HTML

stream 3

CSS

stream 5

단일 TCP 연결로 동시 다중 스트림 처리

코드	의미	설명
1xx	정보	요청 수신, 처리 중
2xx	성공	요청 성공적으로 처리됨
3xx	리다이렉션	추가 동작 필요
4xx	클라이언트 오류	잘못된 요청
5xx	서버 오류	서버 처리 실패

DNS

DNS 조회 과정

도메인 이름이 IP 주소로 변환되는 과정입니다. DNS는 계층적 분산 데이터베이스입니다. Root → TLD → Authoritative 순으로 질의합니다. Recursive Resolver(통상 ISP 또는 8.8.8.8)가 대신 조회해 줍니다.

      조회 도메인: www.example.com
    

DNS 계층 구조

. (Root)

.com

.net

.org

.kr

example.com

google.com

github.com

www

mail

api

조회 과정 시뮬레이션

다음 단계 버튼을 눌러 DNS 조회를 시작하세요.

재귀 질의 (Recursive)

클라이언트 → Resolver

Resolver → Root → .com → Auth

Resolver → 클라이언트 (최종 IP)

Resolver가 모든 작업 대신 수행. 일반적 방식.

반복 질의 (Iterative)

클라이언트 → Root (referral)

클라이언트 → .com TLD (referral)

클라이언트 → Auth (최종 IP)

클라이언트가 직접 각 서버에 질의. 서버 간 통신에 사용.

08 — WEB BASICS

웹 기초 — 쿠키/세션/JWT & CORS

웹 인증 방식과 브라우저 보안 정책의 핵심 개념입니다. 면접에서 가장 자주 나오는 웹 지식입니다.

① 인증 방식 비교: Cookie vs Session vs JWT

클라이언트 (브라우저)

            Set-Cookie 수신 후 저장

            user=alice

            token=xyz123

요청마다 자동으로 전송
          
서버

            응답 시 Set-Cookie 헤더

            쿠키 값으로 사용자 식별

            ⚠ XSS/CSRF 취약점 주의

            HttpOnly, Secure 옵션 필수

쿠키: 브라우저에 저장되는 작은 데이터(≤4KB). 만료일, 도메인, 경로, HttpOnly, Secure, SameSite 속성으로 제어. 서버 상태를 클라이언트에 저장 → Stateless 서버 가능.

② CORS (Cross-Origin Resource Sharing)

        브라우저의 Same-Origin Policy: 다른 출처(도메인/포트/프로토콜)의 리소스 접근 차단. CORS는 서버가 명시적으로 허용하는 메커니즘.
      

③ REST API 설계 원칙

HTTP 메서드	URI 예시	동작	멱등성
GET	/users /users/1	조회	✓ 멱등
POST	/users	생성	✗ 비멱등
PUT	/users/1	전체 수정	✓ 멱등
PATCH	/users/1	부분 수정	△ 경우에 따라
DELETE	/users/1	삭제	✓ 멱등

REST 6원칙: Stateless(서버 상태 미보존) · Uniform Interface(표준 HTTP) · Cacheable · Client-Server · Layered System · Code on Demand(선택). URI는 명사 사용, 동사 금지. 버전은 /v1/users 형식.

09 — TCP vs UDP

TCP vs UDP

두 전송 계층 프로토콜의 핵심 차이입니다. 신뢰성이 필요하면 TCP, 속도가 중요하면 UDP를 선택합니다.

항목	TCP	UDP
연결 방식	연결지향 (3-way handshake)	비연결 (connectionless)
신뢰성	✓ 보장 (ACK, 재전송)	✗ 보장 안됨
순서 보장	✓ 순서 보장	✗ 순서 보장 안됨
속도	느림 (오버헤드 있음)	빠름 (오버헤드 없음)
헤더 크기	20~60 bytes	8 bytes
흐름/혼잡 제어	✓ 있음	✗ 없음
주요 사용처	HTTP/S, 이메일, 파일전송	DNS, 스트리밍, 게임, VoIP

전송 시뮬레이션

TCP

UDP

TCP 흐름/혼잡 제어

흐름 제어 (Flow Control)

            · 수신자 처리 속도에 맞게 전송 속도 조절

            · 슬라이딩 윈도우 (Sliding Window) 방식

            · 수신자가 rwnd(수신 윈도우 크기) 알림

            · rwnd=0이면 전송 중단
          
혼잡 제어 (Congestion Control)

            · 네트워크 혼잡 감지 및 전송량 조절

            · Slow Start: cwnd 1부터 지수 증가

            · Congestion Avoidance: 선형 증가

            · 패킷 손실 시 cwnd 감소

QUIC: Google이 개발한 UDP 기반 프로토콜. TCP의 신뢰성 + UDP의 속도. HTTP/3의 기반. 연결 설정이 0-RTT로 가능.

네트워크