diff --git a/Http/Https.md b/Http/Https.md
new file mode 100644
index 0000000..0f9bfa9
--- /dev/null
+++ b/Http/Https.md
@@ -0,0 +1,446 @@
+# 🌐 HTTP / HTTPS 완전 정복 스터디 자료
+
+> 취업 면접 대비 | 기초 → 중급 → 심화 순서로 구성
+
+---
+
+## 📋 목차
+
+1. [HTTP 구조 — 메서드, 상태코드, 헤더](#1-http-구조)
+2. [HTTP 1.1 → 2 → 3 진화 이유](#2-http-버전-진화)
+3. [HTTPS와 TLS Handshake 전체 흐름](#3-https와-tls-handshake)
+4. [면접 단골 질문 & 모범 답변](#4-면접-질문)
+
+---
+
+## 1. HTTP 구조
+
+### 1-1. HTTP란?
+
+**HTTP (HyperText Transfer Protocol)**는 클라이언트(브라우저)와 서버가 데이터를 주고받기 위한 **애플리케이션 계층 프로토콜**이다.
+
+- 기반 전송 프로토콜: **TCP** (HTTP/3은 QUIC 사용)
+- 기본 포트: **80번** (HTTPS는 443번)
+- 핵심 특성: **Stateless (무상태)** — 요청 간에 상태를 저장하지 않음
+
+> 💡 Stateless란?  
+> 서버는 이전 요청을 기억하지 않는다. 매 요청은 독립적으로 처리된다.  
+> → 이 한계를 극복하기 위해 쿠키/세션/JWT가 등장함
+
+---
+
+### 1-2. HTTP 메서드 (Method)
+
+HTTP 요청 시 **어떤 행동을 원하는지** 명시하는 동사.
+
+| 메서드 | 용도 | 멱등성 | 안전성 |
+|--------|------|--------|--------|
+| `GET` | 리소스 조회 | ✅ | ✅ |
+| `POST` | 리소스 생성 | ❌ | ❌ |
+| `PUT` | 리소스 전체 수정 | ✅ | ❌ |
+| `PATCH` | 리소스 일부 수정 | ❌ | ❌ |
+| `DELETE` | 리소스 삭제 | ✅ | ❌ |
+| `HEAD` | GET과 동일하나 body 없음 | ✅ | ✅ |
+| `OPTIONS` | 서버가 허용하는 메서드 확인 | ✅ | ✅ |
+
+> 💡 **멱등성(Idempotent)**: 같은 요청을 여러 번 보내도 결과가 같음  
+> 💡 **안전성(Safe)**: 리소스를 변경하지 않음  
+> → 면접에서 "PUT vs PATCH 차이"는 단골 질문!
+
+---
+
+### 1-3. HTTP 상태코드 (Status Code)
+
+서버가 요청을 처리한 결과를 **3자리 숫자**로 나타냄.
+
+#### 1xx — 정보
+| 코드 | 의미 |
+|------|------|
+| `100 Continue` | 요청 계속 진행해도 됨 |
+
+#### 2xx — 성공
+| 코드 | 의미 |
+|------|------|
+| `200 OK` | 요청 성공 |
+| `201 Created` | 리소스 생성 성공 |
+| `204 No Content` | 성공, 반환할 본문 없음 |
+
+#### 3xx — 리다이렉션
+| 코드 | 의미 |
+|------|------|
+| `301 Moved Permanently` | 영구 이동 (URL 변경됨) |
+| `302 Found` | 임시 이동 |
+| `304 Not Modified` | 캐시된 리소스 그대로 사용 가능 |
+
+#### 4xx — 클라이언트 오류
+| 코드 | 의미 |
+|------|------|
+| `400 Bad Request` | 잘못된 요청 문법 |
+| `401 Unauthorized` | 인증 필요 |
+| `403 Forbidden` | 권한 없음 (인증은 됐지만 인가 X) |
+| `404 Not Found` | 리소스 없음 |
+| `429 Too Many Requests` | 요청 횟수 초과 |
+
+#### 5xx — 서버 오류
+| 코드 | 의미 |
+|------|------|
+| `500 Internal Server Error` | 서버 내부 오류 |
+| `502 Bad Gateway` | 게이트웨이/프록시 오류 |
+| `503 Service Unavailable` | 서버 과부하 또는 점검 중 |
+
+> 💡 **401 vs 403 자주 헷갈림**  
+> - 401: 로그인 자체를 안 한 상태 (인증 실패)  
+> - 403: 로그인은 했지만 접근 권한이 없는 상태 (인가 실패)
+
+---
+
+### 1-4. HTTP 헤더 (Header)
+
+요청/응답에 **추가적인 메타데이터**를 담는 영역. `Key: Value` 형태.
+
+#### 요청(Request) 헤더 주요 항목
+```
+GET /index.html HTTP/1.1
+Host: www.example.com
+Accept: text/html
+Accept-Encoding: gzip, deflate
+Authorization: Bearer <token>
+User-Agent: Mozilla/5.0 ...
+Content-Type: application/json
+```
+
+| 헤더 | 설명 |
+|------|------|
+| `Host` | 요청 대상 서버 도메인 |
+| `Accept` | 클라이언트가 받을 수 있는 미디어 타입 |
+| `Authorization` | 인증 토큰 (Bearer, Basic 등) |
+| `Content-Type` | 요청 본문의 데이터 형식 |
+| `Cookie` | 저장된 쿠키 전송 |
+
+#### 응답(Response) 헤더 주요 항목
+```
+HTTP/1.1 200 OK
+Content-Type: text/html; charset=UTF-8
+Content-Length: 3423
+Set-Cookie: sessionId=abc123; HttpOnly
+Cache-Control: max-age=3600
+```
+
+| 헤더 | 설명 |
+|------|------|
+| `Content-Type` | 응답 본문의 데이터 형식 |
+| `Set-Cookie` | 브라우저에 쿠키 저장 지시 |
+| `Cache-Control` | 캐시 정책 지정 |
+| `Location` | 리다이렉션 대상 URL |
+
+---
+
+## 2. HTTP 버전 진화
+
+### 2-1. HTTP/1.0 — 연결의 비효율
+
+- 요청마다 **TCP 연결을 새로 맺고 끊음**
+- 1 요청 = 1 TCP 연결 → 오버헤드 엄청남
+- 이미지 10개 있으면 TCP Handshake를 10번 반복
+
+```
+[클라이언트]          [서버]
+    |--- TCP 연결 ----->|
+    |--- GET /img1 ---->|
+    |<-- 응답 ----------|
+    |--- TCP 종료 ----->|
+    |--- TCP 연결 ----->|   ← 다시 연결!
+    |--- GET /img2 ---->|
+    ...
+```
+
+---
+
+### 2-2. HTTP/1.1 — Keep-Alive와 파이프라이닝
+
+#### Keep-Alive (지속 연결)
+- TCP 연결을 **재사용** → 연결 오버헤드 감소
+- `Connection: keep-alive` 헤더로 활성화 (HTTP/1.1 기본값)
+
+```
+[클라이언트]          [서버]
+    |--- TCP 연결 ----->|
+    |--- GET /img1 ---->|
+    |<-- 응답 ----------|
+    |--- GET /img2 ---->|   ← TCP 재사용!
+    |<-- 응답 ----------|
+    |--- TCP 종료 ----->|
+```
+
+#### 파이프라이닝 (Pipelining)
+- 응답을 기다리지 않고 **요청을 연속으로 전송**
+- 이론상 빠르지만 **HOL Blocking** 문제 발생
+
+#### HOL Blocking (Head-of-Line Blocking)
+```
+요청: [A] [B] [C]
+응답:  A가 느리면... [A 대기중] [B 대기] [C 대기]
+      → B, C가 먼저 준비돼도 A를 기다려야 함!
+```
+
+> 💡 **HOL Blocking** = 앞선 요청이 막히면 뒤 요청도 전부 막히는 현상  
+> HTTP/1.1의 가장 큰 한계 → HTTP/2에서 해결하려 함
+
+---
+
+### 2-3. HTTP/2 — 멀티플렉싱
+
+#### 핵심 개념: 스트림(Stream) & 멀티플렉싱
+
+- 하나의 TCP 연결 위에 **여러 스트림을 동시에** 운반
+- 요청/응답이 **프레임(Frame)** 단위로 분할되어 전송
+- 순서와 무관하게 도착 → HOL Blocking 해결 (애플리케이션 레벨에서)
+
+```
+HTTP/1.1:  [요청A] → [응답A] → [요청B] → [응답B]   (순차적)
+
+HTTP/2:    Stream 1: [A 프레임] [A 프레임] [A 프레임]
+           Stream 2:      [B 프레임]  [B 프레임]
+           Stream 3:           [C 프레임]
+           → 하나의 TCP에서 동시에!
+```
+
+#### HTTP/2 주요 기능
+
+| 기능 | 설명 |
+|------|------|
+| **멀티플렉싱** | 하나의 연결로 여러 요청/응답 동시 처리 |
+| **헤더 압축 (HPACK)** | 중복 헤더를 압축해서 전송 |
+| **서버 푸시** | 클라이언트 요청 전에 서버가 먼저 리소스 전송 |
+| **바이너리 프레이밍** | 텍스트 → 바이너리로 파싱 효율 향상 |
+
+#### 한계: TCP 레벨 HOL Blocking
+- TCP는 **패킷 손실 시 재전송을 기다림**
+- 하나의 패킷이 손실되면 그 연결의 **모든 스트림이 대기**
+- → HTTP/3에서 근본적 해결 시도
+
+---
+
+### 2-4. HTTP/3 — QUIC 기반
+
+#### QUIC이란?
+- Google이 개발한 **UDP 기반** 전송 프로토콜
+- TCP의 신뢰성을 **애플리케이션 레벨**에서 구현
+- TLS 1.3이 **기본 내장** → 연결 수립이 더 빠름
+
+#### TCP vs QUIC 연결 수립 비교
+```
+TCP + TLS 1.2:
+  1. TCP SYN
+  2. TCP SYN-ACK
+  3. TCP ACK
+  4. TLS ClientHello
+  5. TLS ServerHello
+  6. TLS 키 교환 ...
+  → 최소 2~3 RTT 필요
+
+QUIC:
+  1. Initial Packet (연결 + 암호화 동시)
+  → 최초: 1 RTT / 재연결: 0 RTT 가능!
+```
+
+#### HTTP/3 장점 요약
+| 항목 | HTTP/2 (TCP) | HTTP/3 (QUIC) |
+|------|-------------|--------------|
+| 기반 프로토콜 | TCP | UDP + QUIC |
+| HOL Blocking | TCP 레벨에서 발생 | 스트림별 독립 → 해결 |
+| 연결 수립 | 2-3 RTT | 0-1 RTT |
+| 이동성 (모바일) | IP 바뀌면 재연결 | Connection ID로 유지 |
+
+> 💡 **왜 UDP를 쓰는데 신뢰성이 있나?**  
+> QUIC이 애플리케이션 레벨에서 재전송, 순서 보장 등을 직접 구현하기 때문.  
+> TCP가 OS 커널에서 하던 일을 QUIC이 앱 레이어에서 함.
+
+---
+
+## 3. HTTPS와 TLS Handshake
+
+### 3-1. HTTPS란?
+
+**HTTPS = HTTP + TLS (Transport Layer Security)**
+
+- HTTP 메시지를 전송 전에 **암호화**
+- 기본 포트: **443**
+- 제공하는 보안:
+  - **기밀성**: 내용을 제3자가 읽을 수 없음
+  - **무결성**: 전송 중 내용이 변조되지 않음
+  - **인증**: 내가 접속한 서버가 진짜인지 확인
+
+---
+
+### 3-2. 대칭키 vs 비대칭키
+
+| 구분 | 대칭키 암호화 | 비대칭키 암호화 |
+|------|-------------|---------------|
+| 키 개수 | 1개 (같은 키로 암/복호화) | 2개 (공개키 + 개인키) |
+| 속도 | 빠름 | 느림 |
+| 문제점 | 키 전달 과정이 취약 | 느린 속도 |
+| 대표 알고리즘 | AES | RSA, ECC |
+| TLS에서 역할 | 실제 데이터 암호화 | 대칭키를 안전하게 교환 |
+
+> 💡 **TLS는 두 방식을 조합해서 사용**  
+> 비대칭키로 대칭키를 안전하게 교환 → 이후 대칭키로 빠르게 통신
+
+---
+
+### 3-3. TLS Handshake 전체 흐름 (TLS 1.2 기준)
+
+```
+클라이언트                              서버
+    |                                    |
+    |------- ClientHello --------------->|
+    |  (TLS 버전, 지원 암호화 목록,         |
+    |   랜덤값 A)                          |
+    |                                    |
+    |<------ ServerHello ----------------|
+    |  (선택된 암호화 방식, 랜덤값 B)        |
+    |                                    |
+    |<------ Certificate ----------------|
+    |  (서버의 공개키 포함 인증서)            |
+    |                                    |
+    |<------ ServerHelloDone ------------|
+    |                                    |
+    | [클라이언트: 인증서 검증]              |
+    | [Pre-Master Secret 생성]            |
+    |                                    |
+    |------- ClientKeyExchange --------->|
+    |  (Pre-Master Secret, 공개키로 암호화) |
+    |                                    |
+    | [양쪽에서 Master Secret 생성]        |
+    | [세션 키(대칭키) 도출]                |
+    |                                    |
+    |------- ChangeCipherSpec ---------->|
+    |------- Finished ------------------>|
+    |                                    |
+    |<------ ChangeCipherSpec -----------|
+    |<------ Finished -------------------|
+    |                                    |
+    |====== 암호화된 HTTP 통신 시작 ========|
+```
+
+#### 각 단계 설명
+
+**① ClientHello**
+- 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록(Cipher Suite) 전송
+- 랜덤값 A (Client Random) 포함
+
+**② ServerHello**
+- 서버가 암호화 방식 선택 후 응답
+- 랜덤값 B (Server Random) 포함
+
+**③ Certificate**
+- 서버가 **공개키가 담긴 인증서** 전송
+- 클라이언트는 이 인증서가 **CA(인증기관)**에서 서명한 것인지 검증
+
+**④ 인증서 검증**
+- 브라우저에는 신뢰할 수 있는 **Root CA 목록**이 내장됨
+- 인증서 체인을 따라가며 Root CA까지 신뢰 확인
+
+**⑤ ClientKeyExchange**
+- Pre-Master Secret 생성
+- 서버의 공개키로 암호화해서 전송 → 서버만 개인키로 복호화 가능
+
+**⑥ 세션 키 생성**
+- 양쪽에서 `Client Random + Server Random + Pre-Master Secret` 조합
+- 동일한 **세션 키(대칭키)** 도출
+
+**⑦ ChangeCipherSpec + Finished**
+- "이제부터 암호화 통신 시작" 신호
+- Finished 메시지로 Handshake 완료 확인
+
+---
+
+### 3-4. TLS 1.3 — 더 빠르고 안전하게
+
+TLS 1.2의 단점을 개선한 버전 (2018년 표준화)
+
+| 항목 | TLS 1.2 | TLS 1.3 |
+|------|---------|---------|
+| Handshake RTT | 2 RTT | **1 RTT** |
+| 취약한 알고리즘 | RSA 키 교환 등 지원 | 제거 (Forward Secrecy 강제) |
+| 0-RTT | 없음 | 재연결 시 지원 |
+
+> 💡 **Forward Secrecy (전방 비밀성)**  
+> 세션 키가 나중에 유출되어도 과거 통신 내용은 복호화 불가.  
+> 매 세션마다 임시 키를 생성하고 버리기 때문.
+
+---
+
+### 3-5. SSL vs TLS 용어 정리
+
+> 💡 실무에서 "SSL 인증서"라고 부르지만, 현재 실제로 사용하는 건 **TLS**  
+> SSL은 구버전이고 보안 취약점으로 인해 사용 중단됨  
+> TLS 1.0, 1.1도 deprecated → 현재 표준은 **TLS 1.2 / 1.3**
+
+---
+
+## 4. 면접 질문
+
+### Q1. HTTP와 HTTPS의 차이점은?
+
+**모범 답변:**
+> HTTP는 데이터를 평문으로 전송하는 프로토콜이고, HTTPS는 TLS를 추가하여 암호화, 무결성, 인증을 제공합니다. HTTPS는 443 포트를 사용하며, 서버 인증서를 통해 클라이언트가 신뢰할 수 있는 서버인지 확인할 수 있습니다.
+
+---
+
+### Q2. 왜 TCP 3-way Handshake를 하나요?
+
+**모범 답변:**
+> TCP는 신뢰성 있는 연결을 보장하기 위해 3-way Handshake를 사용합니다. SYN으로 연결 요청 → SYN-ACK으로 수락 → ACK으로 확인하는 과정을 통해 양방향 통신이 가능한지 확인하고, 시퀀스 번호를 동기화하여 패킷 순서와 손실 감지를 가능하게 합니다.
+
+---
+
+### Q3. HTTP/2의 멀티플렉싱이 무엇인가요?
+
+**모범 답변:**
+> HTTP/1.1은 하나의 TCP 연결에서 요청-응답을 순차적으로 처리해야 했습니다. HTTP/2는 하나의 TCP 연결 위에 여러 스트림을 독립적으로 운반하는 멀티플렉싱을 도입하여, 여러 요청/응답을 동시에 처리할 수 있습니다. 이를 통해 HOL Blocking을 애플리케이션 레벨에서 해결합니다.
+
+---
+
+### Q4. TLS Handshake 과정을 설명해보세요.
+
+**모범 답변:**
+> 클라이언트가 ClientHello를 보내 지원하는 암호화 방식을 알리고, 서버는 인증서(공개키 포함)를 전송합니다. 클라이언트는 인증서를 CA를 통해 검증한 후, Pre-Master Secret을 서버의 공개키로 암호화해 전송합니다. 양측은 이를 이용해 동일한 세션 키(대칭키)를 생성하고, 이후 통신은 이 대칭키로 암호화합니다.
+
+---
+
+### Q5. HTTPS인데 왜 패킷 스니핑이 안 되나요?
+
+**모범 답변:**
+> TLS가 데이터를 암호화하기 때문입니다. 패킷을 가로채더라도 세션 키 없이는 복호화할 수 없습니다. 세션 키는 TLS Handshake 과정에서 비대칭키 암호화를 통해 안전하게 교환되므로, 중간에서 탈취해도 내용을 알 수 없습니다.
+
+---
+
+### Q6. HTTP/3는 왜 UDP를 사용하나요?
+
+**모범 답변:**
+> TCP는 커널 레벨에서 구현되어 있어 수정이 어렵고, 패킷 손실 시 TCP 레벨의 HOL Blocking이 발생합니다. HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용하여 신뢰성 보장 로직을 애플리케이션 레벨에서 직접 구현합니다. 이를 통해 스트림별 독립적인 패킷 손실 처리가 가능하고, 연결 수립 시간도 단축됩니다.
+
+---
+
+### Q7. 401과 403의 차이는?
+
+**모범 답변:**
+> 401 Unauthorized는 인증이 되지 않은 상태로, 로그인이 필요한 경우입니다. 403 Forbidden은 인증은 됐지만 해당 리소스에 대한 권한이 없는 경우입니다. 예를 들어, 일반 사용자가 관리자 페이지에 접근하면 403이 반환됩니다.
+
+---
+
+## 📌 핵심 요약 카드
+
+```
+HTTP   = 텍스트 기반 애플리케이션 프로토콜, Stateless
+HTTPS  = HTTP + TLS 암호화 (기밀성 + 무결성 + 인증)
+HTTP/1.1 = Keep-Alive, 파이프라이닝, HOL Blocking 문제
+HTTP/2   = 멀티플렉싱, 헤더압축, 바이너리, TCP HOL은 여전히 존재
+HTTP/3   = QUIC(UDP 기반), 0-1 RTT, 스트림별 독립 처리
+TLS      = 비대칭키로 대칭키 교환 → 대칭키로 실제 통신
+```
+
+---
+
+*참고: Foundations of Python Network Programming (fopnp) | 면접 스터디용*