# HTTP

## 1. 정의

* HTTP(Hypertext Transfer Protocol)은 애플리케이션 계층 프로토콜.
* 클라이언트와 서버간의 데이터를 주고 받기 위해 사용
* HTML, JSON, 이미지 등 다양한 형식 데이터를 전송

## 2. 특징

* 텍스트 기반 프로토콜: 사람이 읽을 수 있는 텍스트 형식으로 작성됩니다.
* Stateless: 이전 요청 상태를 기억하지 않음. 매 요청마다 쿠키/토큰을 사용하거나 세션을 사용
* 클라이언트-서버 모델: 클라이언트가 요청을 보내고 서버가 응답을 반환.
* 확장성: 다양한 데이터 형식(JSON, HTML, XML 등)을 지원하며, API개발에도 사용

## 3. 구조

### 3.1. 요청 구조

1. 요청 라인: 요청의 핵심 정보를 포함. (GET /index.html HTTP/1.1)
2. 헤더: 요청의 부가 정보 포함. (Host: [www.example.com](http://www.example.com)  User-Agent: Mozilla/5.0)
3. 본문: POST, PUT 등 메서드에서 서버로 전송되는 데이터가 포함.

### 3.2. 응답 구조

1. 상태 라인: 서버의 처리 결과를 나타냄. (HTTP/1.1 200 OK)
2. 헤더: 응답 부가 정보 포함. (Content-Type: text/html)
3. 본문: 서버가 전달하는 실제 데이터. (HTML, JSON, 이미지)

## 4. 메서드

### 4.1. GET

* 리소스 조회
* 멱등. 캐싱 가능
* 리소스를 변경하지 않는 안전한 메서드

### 4.2. POST

* 새로운 데이터를 전송하거나 생성할때 사용
* 멱등하지 않음. 캐싱 불가능
* 리소스 변경으로 안전하지 않음

### 4.3. PUT

* 데이터를 전체적으로 교체할때 사용
* 멱등. 데이터를 덮어쓰는 경우

### 4.4. PATCH

* 데이터를 일부만 수정할때 사용
* 멱등하지 않을수도 있음. (+1 같은 경우)

> **멱등:**
>
> * 안정성 및 오류 처리: 네트워크 오류로 여러번 요청을 보내더라도 문제 없음.
> * 안전한 재시도 로직 구현: 요청 재시도로 여러개의 요청을 보내도 문제 없음.
> * 캐싱과 성능 최적화: 서버나 프록시에서 캐싱이 용이. 결과를 재생성하지 않아도 됨.
> * 분산 시스템에서의 일관성 유지: 분산 시스템에서는 요청이 중복으로 처리될 가능성이 있음.
> * 서비스 안정성: 서비스 장애 시 복구 과정에서 멱등한 요청은 중복된 작업을 수행하더라도 안전함.

## 5. 상태 코드

### 2XX 성공

* 200 OK: 요청 성공
* 201 Created: 리소스 생성 성공

### 3XX 리다이렉션

* 301 Moved Permanently: 리소스가 영구적으로 이동됨. 클라이언트는 새로운 URL을 캐싱하여, 요청시 항상 새 URL로 요청
* 302 Found: 리소스가 임시로 이동됨. 클라이언트는 새 URL로 이동하지만, 기존 URL에 계속 요청함.

### 4XX 클라이언트 오류

* 400 Bad Request: 잘못된 요청
* 404 Not Found: 요청한 리소스를 찾을 수 없음

### 5XX 서버 오류

* 500 Internal Server Error: 서버에서 처리 중 오류 발생
* 503 Service Unavailable: 서버가 현재 처리 불가능

## 6. 버전

### 1.0

* 헤더
* 상태 코드
* GET외의 메서드
* Stop and Wait Protocol

### 1.1

* Keep-Alive
* 파이프라이닝: 연속적으로 여러 요청을 보냄. 하지만 응답은 순서대로 받아야함. 요청 자체로 인한 HOL Blocking.
* Chunk Transfer
* Etag Caching

### 2.0

* Binary Framing Layer: 요청 응답을 이진 형식으로 변환, 헤더와 데이터를 프레임으로 쪼갬(프레임 독립성)
* 멀티플랙싱: TCP연결에서 스트림채널을 열어, 여러 HTTP 요청/응답을 병렬로 전송. TCP 패킷 손실로 인한 HOL Blocking.
* Stream Prioritization: 요청에 대한 우선순위 부여
* Server Push: 요청이 없거나 하나의 요청에 대해 여러 응답 가능
* HPack Compression: 과거 요청 헤더를 기억하고 압축 가능

### 3.0 QUIC

* 패킷 손실 복구(SACK, Selective Ack): 받지 못한 패킷에 대해서만 Ack를 보내어 신뢰성 확보.
* 0-RTT: 이전 연결 정보를 저장합니다. 첫 연결 종료시 서버의 세션 티켓, 사전 공유 키(PSK)를 저장합니다. 두 번쨰 연결시, 이를 재활용하여 요청 데이터와 함께 보냅니다. 서버는 세션 티켓을 검증하고, PSK를 사용해 암호화 키를 설정하고 클라이언트 요청을 처리합니다. 서버는 핸드쉐이크 완료 메세지를 보내고, 데이터를 클라이언트에 전송합니다.
* 스트림 독립성: 각 패킷이 어느 요청의 것(스트림)인지 명시적으로 구분하여 독립적으로 관리되도록 함. 멀티플랙싱의 HOL blocking 문제를 해결.
* 헤더 압축: QPack을 사용. Hpack보다 헤더 크기가 줄어듬

<details>

<summary>Pipelining Head-Of-Line Blocking</summary>

요청이 순차적으로 처리되기 때문에, 앞선 요청이 지연되면 뒤따르는 요청도 지연.

</details>

<details>

<summary>Multiplexing Head-Of-Line Blocking</summary>

상황:

요청1의 패킷1,2,3 \
요청2의 패킷1,2,3 \
요청3의 패킷1,2,3 이 있는 상황에서, 요청 2의 패킷 2가 손상됬을때, 나머지 요청들의 처리가 차단.

수신측에서는 손실된 패킷이 요청2의 패킷이라는걸 모르기때문에 기다리는 것

</details>

## 10. 단점과 해결 방법

* 무상태성 -> 쿠키, 세션, JWT 사용
* 보안 문제 -> HTTPS 도입
* 성능 문제 -> HTTP/2, HTTP/3 도입
