HTTP

HTTP(Hypertext Transfer Protocol)는 웹에서 클라이언트와 서버 간에 데이터를 주고받기 위한 프로토콜
HTTP/1.0은 요청마다 새로운 TCP 연결을 맺고 해제하는 방식으로 동작하는 상태 비저장 프로토콜
HTTP/1.1은 상태 비저장 프로토콜이지만, Keep-Alive를 통해 TCP 연결을 유지하도록 개선
HTTP/2.0은 하나의 TCP 연결에서 여러 요청을 동시에 처리할 수 있는 멀티플렉싱(Multiplexing)을 지원
HTTP/3.0은 TCP 대신 QUIC 프로토콜을 사용하여 멀티플렉싱 성능을 향상시키고, 연결 지연을 줄여 더 빠르고 안정적인 통신을 제공하는 프로토콜

 

 

 

 

✅ HTTP(Hypertext Transfer Protocol):
웹에서 클라이언트와 서버 간에 데이터를 주고받기 위한 프로토콜. 기본적으로 Stateless(상태 비저장) 방식으로 동작.

✅ HTTP/1.0 (1996)

• 요청마다 새로운 TCP 연결을 맺고 해제하는 방식 → 성능 저하 발생.
• 헤더에 "Connection: Keep-Alive"를 명시하면 연결 유지 가능하지만 기본 지원 X.

✅ HTTP/1.1 (1997)

• Keep-Alive 기본 지원 → 한 개의 TCP 연결을 유지하면서 여러 요청 처리 가능.
• 파이프라이닝(Pipelining) 도입: 여러 요청을 순차적으로 보내는 기능 (하지만 HOL Blocking 문제 존재).
• Host 헤더 추가 → 하나의 서버에서 여러 도메인 호스팅 가능(가상 호스팅 지원).

✅ HTTP/2.0 (2015)

• 하나의 TCP 연결에서 여러 요청을 동시에 처리 가능 (멀티플렉싱, Multiplexing) → 성능 개선.
• 헤더 압축(HPACK) 도입 → 중복 데이터 제거로 전송 속도 향상.
• 서버 푸시(Server Push) 지원 → 클라이언트 요청 없이도 서버가 미리 데이터 전송 가능.

✅ HTTP/3.0 (2022)

• TCP 대신 QUIC(UDP 기반) 사용 → 연결 속도 향상 및 패킷 손실 시 복구 속도 개선.
• 0-RTT 핸드셰이크 지원 → 기존 연결을 재사용할 때 빠르게 데이터 전송 가능.
• 멀티플렉싱 개선 → HTTP/2.0은 하나의 스트림이 지연되면 다른 스트림도 영향을 받았지만, HTTP/3.0은 독립적으로 처리 가능.

 

 

🔹 HOL Blocking(Head-of-Line Blocking) 문제란?

**HOL Blocking(헤드 오브 라인 블로킹)**은 처음에 대기 중인 요청이 지연되면, 뒤따르는 모든 요청도 영향을 받아 지연되는 문제를 말해.

---

1. HTTP/1.1에서의 HOL Blocking 문제

• Keep-Alive로 TCP 연결을 유지해도, 하나의 연결에서 요청을 순차적으로 처리해야 함.
• 앞 요청의 처리가 느리면, 뒤 요청들도 기다려야 해서 병목(Bottleneck) 발생.
• 파이프라이닝(Pipelining) 기능이 추가되었지만, 여전히 앞 요청이 지연되면 뒤 요청도 대기해야 하는 문제가 있었음.

📌 예시 (HTTP/1.1)

1. 클라이언트가 서버에 요청 A, B, C를 보냄.
2. 요청 A가 오래 걸리면, 요청 B, C도 A가 끝날 때까지 기다려야 함.
3. 결과적으로 전체 성능이 저하됨.

---

2. HTTP/2.0에서의 HOL Blocking 문제

• HTTP/2.0에서는 **멀티플렉싱(Multiplexing)**을 도입하여, 하나의 TCP 연결에서 여러 요청을 동시에 처리 가능.
• 하지만, 모든 요청이 하나의 TCP 연결을 공유하기 때문에 한 요청의 패킷 손실이 발생하면 해당 연결을 공유하는 모든 요청이 지연되는 문제가 있음.
• 즉, TCP 프로토콜 자체에서 발생하는 HOL Blocking 문제를 완전히 해결하지 못함.

📌 예시 (HTTP/2.0)

1. 클라이언트가 서버에 요청 A, B, C를 보냄.
2. 요청 A의 패킷이 손실되면, TCP는 이를 재전송해야 해서 같은 연결 내의 B, C 요청도 영향을 받음.
3. 한 요청의 지연이 다른 요청에도 영향을 주는 문제 발생.

---

3. HTTP/3.0에서의 HOL Blocking 해결

• HTTP/3.0에서는 TCP 대신 QUIC(UDP 기반) 프로토콜을 사용하여 HOL Blocking 문제를 해결!
• QUIC은 각 요청을 독립적인 스트림(Stream)으로 처리하므로, 어떤 요청이 지연되더라도 다른 요청에는 영향을 주지 않음.

📌 예시 (HTTP/3.0 - QUIC 적용)

1. 클라이언트가 서버에 요청 A, B, C를 보냄.
2. 요청 A의 패킷이 손실되더라도, 요청 B, C는 영향을 받지 않고 정상적으로 처리됨.
3. 각 요청이 독립적으로 처리되므로 전체 성능이 향상됨.

---

✅ 결론: HOL Blocking 문제를 해결하는 흐름

1. HTTP/1.1 → 요청이 순차적으로 처리되어 HOL Blocking 발생.
2. HTTP/2.0 → 멀티플렉싱 도입, 하지만 TCP 기반이라 HOL Blocking 완전히 해결 못함.
3. HTTP/3.0 → QUIC(UDP 기반) 사용하여 각 요청을 독립적으로 처리, HOL Blocking 완전 해결!

* 크로, 파이어폭스 등의 브라우저는 HTTP/1.1에서 HOL 문제를 완화하기 위해 도메인당 최대 6개의 TCP 연결을 사용함.

 

 

자주 사용되는 HTTP Status Code + 사용 예시

1xx (Informational) - 정보 응답

코드설명사용 예시

코드	설명	사용예시
100 Continue	클라이언트 요청의 일부를 수신했으며, 계속 요청을 진행하라는 의미	대용량 파일 업로드 시, 서버가 클라이언트에게 계속 업로드하라고 응답
101 Switching Protocols	클라이언트의 프로토콜 변경 요청을 승인	HTTP에서 WebSocket으로 연결을 변경하는 경우

 

2xx (Success) - 성공 응답

코드설명사용 예시

코드	설명	사용예시
200 OK	요청이 정상적으로 처리됨	일반적인 GET, POST 요청 성공 시
201 Created	새로운 리소스가 성공적으로 생성됨	회원가입 성공 후 새 사용자 계정이 생성됨
204 No Content	요청은 성공했지만 반환할 데이터 없음	사용자의 삭제 요청 처리 후 응답 데이터가 필요 없는 경우

 

3xx (Redirection) - 리디렉션 응답

코드설명사용 예시

코드	설명	사용예시
301 Moved Permanently	요청한 리소스가 영구적으로 새로운 URL로 이동함	HTTP에서 HTTPS로 영구 리디렉션할 때
302 Found	요청한 리소스가 임시적으로 새로운 URL로 이동함	로그인 후, 원래 페이지로 리디렉트할 때
304 Not Modified	캐시된 리소스를 그대로 사용하라는 의미	클라이언트가 If-Modified-Since를 보냈고 변경된 내용이 없을 때

 

4xx (Client Error) - 클라이언트 에러 응답

코드설명사용 예시

코드	설명	사용예시
400 Bad Request	잘못된 요청(문법 오류, 잘못된 파라미터 등)	JSON 형식 오류, 필수 파라미터 누락
401 Unauthorized	인증이 필요하지만 제공되지 않았거나 잘못됨	로그인하지 않고 인증이 필요한 API 요청 시
403 Forbidden	접근 권한이 없어 요청이 거부됨	일반 사용자가 관리자 페이지에 접근하려 할 때
404 Not Found	요청한 리소스를 찾을 수 없음	존재하지 않는 API 엔드포인트 요청
405 Method Not Allowed	요청한 HTTP 메서드가 허용되지 않음	GET만 허용하는 API에 POST 요청을 보냈을 때
408 Request Timeout	서버가 클라이언트의 요청을 일정 시간 동안 받지 못함	API 요청이 너무 오래 걸려 서버가 응답을 종료할 때
409 Conflict	요청이 서버 상태와 충돌이 발생함	회원가입 시 이미 존재하는 이메일을 사용했을 때
422 Unprocessable Entity	요청은 이해했지만, 특정 필드가 유효하지 않아 처리할 수 없음	회원가입 시 비밀번호가 너무 짧거나, JSON 필드가 올바르지 않을 때
429 Too Many Requests	너무 많은 요청을 보내서 제한됨 (Rate Limiting)	사용자가 너무 많은 API 요청을 보낼 때 (Rate Limit 초과)

 

📝 422 Unprocessable Entity vs 400 Bad Request 차이

코드차이점

코드	차이점
400 Bad Request	요청이 아예 잘못된 경우 (잘못된 JSON 형식, 필수 파라미터 없음 등)
422 Unprocessable Entity	요청 자체는 문제없지만, 비즈니스 로직에서 유효하지 않은 경우 (예: 비밀번호 길이 부족, 형식 불일치)

 

📌 422를 주로 쓰는 상황

• 회원가입 시 이메일 형식이 잘못됨 (email: "notanemail")

• 비밀번호가 너무 짧음 (password: "123")

• JSON 필드는 있지만, 특정 값이 유효하지 않음 (age: -5)

 

5xx (Server Error) - 서버 에러 응답

코드설명사용 예시

코드	설명	사용예시
500 Internal Server Error	서버 내부 오류로 요청을 처리할 수 없음	코드 실행 중 예상치 못한 예외가 발생한 경우
502 Bad Gateway	게이트웨이 또는 프록시 서버가 잘못된 응답을 받음	NGINX가 백엔드 서버로부터 올바른 응답을 받지 못한 경우
503 Service Unavailable	서버가 과부하 상태이거나 유지보수 중	서버가 다운되었거나 유지보수 중일 때
504 Gateway Timeout	게이트웨이 또는 프록시 서버의 응답 시간이 초과됨	리버스 프록시 서버(NGINX)가 백엔드 서버로부터 응답을 받지 못한 경우

 

📌 핵심 정리

• ✅ 클라이언트 요청 오류: 400, 401, 403, 404, 405, 422, 429

• ✅ 서버 문제: 500, 502, 503, 504

• ✅ 리디렉션: 301, 302, 304

• ✅ 성공 응답: 200, 201, 204