[네트워크] HTTP 프로토콜

✅ HTTP(HyperText Transfer Protocol)란?

: 애플리케이션 계층의 프로토콜로, 웹 서비스 통신에 사용

 

웹 브라우저와 서버 간에 텍스트, 이미지, 영상, JSON 등의 데이터를 주고받을 때 사용된다.
기본적으로 80번 포트를 사용하며, 우리가 흔히 웹 페이지를 열 때 사용하는 방식이 바로 HTTP다.

HTTP는 다음과 같이 크게 2가지 주요한 특징을 가진다.

 

---

 

1️⃣ Connectionless Protocol (비연결성 프로토콜)

: 한 번의 요청과 응답이 오간 후에 맺었던 연결을 끊어버림

• 서버는 다수의 불특정 클라이언트와 연결을 유지하지 않아도 된다.
• 하지만, 매번 새로운 연결을 맺어야 하는 오버헤드가 발생한다.
• HTTP 1.0부터는 KeepAlive 헤더를 통해 HTTP 연결 지속이 가능하다.

 

---

 

2️⃣ Stateless Protocol(무상태 프로토콜)

: 클라이언트의 요청 내역을 기억하지 않음

• HTTP는 무상태 프로토콜이다.
• 서버는 클라이언트가 누구인지 식별하지 못한다.
• 따라서 클라이언트가 누구인지 식별해야 하는 경우, 상태 유지 기술인 쿠키와 세션을 사용해야 한다.

 

---

✅ HTTP 진화 과정

 

📍 HTTP 1.0

: HTTP 0.9를 확장

 

• 버전 정보가 각 요청에 포함
• 요청 메서드가 GET, HEAD, POST 세 가지로 확장
• 상태 코드가 각 응답의 시작 부분에 포함되어, 브라우저가 해당 요청에 대한 성공, 실패 파악 가능해짐
• HTTP 헤더 개념이 등장
• Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐

 

---

 

📍 HTTP 1.1

: 표준화된 HTTP

• Keep-Alive: 한 번 수립한 연결을 재사용하게 설정
• Pipelining: 여러 개의 요청을 보낼 때 처음 용청이 응답될 때까지 기다리지 않고 바로 요청을 한꺼번에 보냄
• 단점은 HOL Blocking 발생

HOL(Head-of-Line) Blocking: 컴퓨터 네트워킹에서 패킷 대기열이 존재할 때, 앞선 패킷이 지연될 때 발생하는 성능 저하 현상

 

---

 

📍 HTTP 2.0

: 기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜

• binary protocol(바이너리 프로토콜): 데이터를 이진 형식으로 전송하여 성능을 향상
• 멀티플렉싱(Multiplexing): 여러 요청과 응답을 동시에 처리할 수 있어 대기 시간을 줄임
• 헤더 압축: 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킴
• 서버 푸시: 서버가 클라이언트의 요청 없이 미리 리소스를 전송할 수 있음

 

---

 

📍 HTTP 3.0

: QUIC라는 프로토콜 기반으로 동작하는 프로토콜

• QUIC(Quick UDP Internet Connections) 프로토콜을 기반: UDP를 사용하여 빠른 연결 및 전송을 지원
• 연결 설정과 데이터 전송의 지연 시간을 줄여 더욱 빠른 성능을 제공

 

---

 

✅ HTTP의 요청/응답 모델: Client-Server Model

: 클라이언트가 HTTP request를 서버에 보내면 서버는 HTTP response를 보내는 구조

• 클라이언트와 서버로 이루어져 있다.
• 클라이언트와 서버의 모든 통신이 요청과 응답으로 이루어져 있다.

 

---

 

📍 Request Message 구조

1. Start Line : HTTP method, Request target, HTTP version으로 구성
   • Request target: HTTP Request가 전송되는 목표 주소
2. Headers: request에 대한 추가 정보를 담고 있는 부분으로 Key: Value 형태로 구성   
   •  다음과 같은 값들이 담겨 있다.
     • Connection: close(메시지 교환 후 TCP 연결 종료) / Keep-Alive(메시지 교환 후 TCP 연결 유지)
     • Host: 클라이언트의 호스트명, 포트 번호
     • User-Agent: 클라이언트의 소프트웨어 정보
     • Accept: 클라이언트가 원하는 미디어 타입 및 우선순위
     • Cookie: 이전에 저장된 쿠키를 포함

3. Body: HTTP Request가 전송하는 데이터를 담고 있는 본문

 

 

---

 

✅ HTTP 메서드

: 서버가 어떤 동작을 취해야 하는지 알려주는 메서드

 

HTTP request message마다 한 개의 HTTP 메서드를 가진다.

 

 

📍 HTTP 메서드 설명

GET	리소스 조회
POST	리소스 추가
DELETE	리소스 삭제
PUT	리소스 전체 수정
PATCH	리소스 부분 수정
OPTIONS	서버가 지원하는 메서드 목록 조회

 

---

 

📍 GET vs. POST

• 전달 값 노출 여부:
  • GET 방식은 URL을 통해 전달하므로 주소창에 전달 값이 노출
  • POST 방식은 HTTP Body에 데이터를 포함해서 전달하여 노출되지 않음
• 전송 데이터 양 제약:
  • GET 방식은 URL 길이 제한으로 전송 데이터 양이 한정됨
  • POST 방식은 길이 제한 없음
• 역할:
  • GET 방식은 서버에서 데이터를 가져와서 보여주는 용도(SELECT적인 성향)
  • POST 방식은 서버의 값이나 상태를 변경하기 위한 용도

 

---

 

📍 PUT vs PATCH

두 메서드 모두 서버의 자원을 수정할 때 사용한다.

 

하지만 다음과 같은 차이점이 있다.

• 수정 범위:
  • PUT 방식은 자원 전체 수정
  • PATCH 방식은 자원 일부 수정
• 자원이 존재하지 않을 경우:
  • PUT 방식은 새로 생성하여 삽입
  • PATCH 방식은 오류 발생
• 멱등성:
  • PUT 방식은 전체 데이터를 수정하므로 멱등하다. 
  • PATCH 방식은 멱등하지 않다. ex) 사용자의 나이를 더하는 경우

 

멱등성: 동일한 요청을 여러 번 수행해도 결과가 동일하게 유지되는 특성

---

 

📍 POST vs PUT

PUT도 자원이 존재하지 않을 경우 새로 생성해 주니 리소스 추가에 사용해도 되지 않을까?라고 생각하면 안 됩니다!

• POST는 동일한 요청 시마다 새로운 데이터를 생성한다.
• PUT은 동일한 요청 시, 처음에 자원이 없을 때만 새로 생성하고 그 이후에는 데이터가 새로 생성되지 않는다. = 멱등성을 가진다.

---

📍 멱등성 정리

 

메서드	멱등성
GET	O
POST	X
PUT	O
DELETE	O
PATCH	X
OPTIONS	O

 

---

 

✅ HTTP 상태 코드

: 클라이언트에게 요청이 성공했는지, 실패했는지 등을 알려주는 3자리 숫자

 

모든 HTTP response message는 HTTP 상태 코드와 함께 반환된다.

 

상태 코드 범주는 다음과 같이 나눌 수 있다.

• 1xx: 정보 응답 (Informational)
  : 요청을 받았으며, 처리를 계속 진행 중
• 2xx: 성공 (Success)
  : 요청이 정상적으로 수신되고, 처리까지 완료되었음
• 3xx: 리다이렉션 (Redirection)
  : 요청을 완료하려면 추가적인 작업(다른 URL로 이동 등)이 필요함
• 4xx: 클라이언트 오류 (Client Error)
  : 클라이언트의 요청에 문법적인 오류가 있거나, 요청을 처리할 수 없는 경우
• 5xx: 서버 오류 (Server Error)
  : 서버 내부에서 문제가 발생해 유효한 요청을 제대로 처리하지 못했음

 

---

 

📍 대표적인 HTTP 상태 코드

200(OK)	서버가 요청을 성공적으로 처리
201(Created)	요청이 처리되어서 새로운 리소스를 생성
400(Bad Request)	요청의 구문이 잘못됨
401(Unauthorized)	지정한 리소스에 대한 액세스 권한이 없음
403(Forbidden)	지정한 리소스에 대한 액세스가 금지됨
404(Not Found)	지정한 리소스를 찾을 수 없음
500(Internal Server Error)	서버에 에러가 발생

 

 

• 401 vs. 403
  • 401은 요청한 리소스에 대한 접근 권한이 없다는 의미로, 리소스에 접근하기 전에 인증이 필요하다는 의미이다.
  • 403은 요청한 리소스에 대한 접근이 금지됐다는 의미로, 인증은 했지만 리소스에 대한 권한이 없다는 의미이다.
• 200 vs. 201
  • 200은 서버가 요청을 성공적으로 처리했음을 의미한다.
  • 201은 서버가 요청을 성공적으로 처리해, 그 결과로 새로운 리소스를 생성했음을 의미한다.
  • 둘은 성공적인 처리라는 의미를 모두 포함하지만, 201은 추가로 새로운 리소스 생성의 의미도 포함한다. 이는 주로 POST나 PUT 응답에서 사용된다.

 

---

✨ 추가 질문

 

[ 왜 HTTP는 Stateless 구조를 채택하고 있을까요? ]

상태를 저장하지 않기 때문에 요청을 어느 서버에서 처리하든 결과가 동일하다.

- 서버 장애에 강함: 서버 1에서 장애가 터지더라도 서버 2가 대신 처리해 주면 된다.
- 수평 확장에 있어서 유리: 같은 기능을 하는 서버를 여러 개로 쉽게 확장 가능하다. (로드밸런싱도 간편해진다)

 

[ Connectionless의 논리대로면 성능이 되게 좋지 않을 것으로 보이는데, 해결 방법이 있을까요? ]

1. Keep-Alive 설정 : HTTP/1.1부터는 keep-alive 헤더를 통해 하나의 TCP 연결을 여러 요청에 재사용할 수 있다. 
2. 상태 유지 기술 사용 : 쿠키, 세션, 토큰(JWT 등)을 이용하면 클라이언트의 인증 정보나 상태를 유지할 수 있어, 매번 반복된 정보를 전송하지 않아도 된다. 
3. 멀티플렉싱 지원 : HTTP/2부터는 하나의 Connection에서 여러 요청과 응답을 동시에 처리할 수 있는 멀티플렉싱 기능이 도입되었다.

 

[ 필요하다면 저희가 직접 응답코드를 정의해서 사용할 수 있을까요? 예를 들어 285번처럼요. ]

아직 할당되지 않은 HTTP 상태 코드 범위에 대해서는 직접 정의하여 사용할 수 있다.

하지만 정의할 때는 가장 앞자리 숫자가 의미하는 범주(클래스)를 정확히 이해하고 있어야 한다.
예를 들어, 4xx는 클라이언트 측의 오류를 의미하므로, 이 범위에 속하는 코드를 정의할 경우 클라이언트의 잘못된 요청이라는 맥락을 가져야 한다.

이처럼 주의할 점이 많기 때문에, 가능하다면 이미 정의된 상태 코드를 활용하는 것이 바람직하다.

* 아래 링크에서 아직 할당되지 않은 범위를 확인할 수 있다.
https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

 

[ HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요? ]

1. 호환성 문제
HTTP/1.1 명세상 GET 메서드에 Body가 허용되긴 하지만
대부분의 서버, 프록시, 캐시 등은 이를 지원하지 않거나 무시한다.

2. REST 원칙 위반
REST에서 GET은 안전하고 조회 전용인 메서드로 정의된다.
Body를 통해 부가 정보를 전달하면 의도가 불명확해지고, 리소스 조회 목적과 어긋나게 된다

 

[ 왜 HTTP는 TCP를 사용하나요? ]

HTTP는 신뢰성이 매우 중요한 프로토콜이다.
중요한 웹 정보를 클라이언트-서버가 손실 없이, 순서대로 전달해야 하므로 이를 보장해주는 TCP가 사용한다.

 

[ 그렇다면, 왜 HTTP/3 에서는 UDP를 사용하나요? UDP의 문제가 해결되었나요? ]

HTTP/3는 빠른 통신을 위해 UDP 기반의 QUIC 프로토콜을 사용한다.
기존 TCP는 연결을 수립하고 해제하는 과정에서 지연이 발생한다.
이를 해결하기 위해 HTTP/3는 TCP 대신 UDP를 선택하고, 그 위에 QUIC이라는 전송 계층 프로토콜을 도입했다.

QUIC는 UDP의 비신뢰성, 비연결성 한계를 해결해준다.
QUIC은 UDP 위에 자체적으로 연결 관리, 암호화, 흐름 제어 기능을 구현하여
TCP 수준의 신뢰성을 유지하면서도 지연을 줄이는 장점이 있다.

 

 

[ 브라우저는 어떤 서버가 TCP를 쓰는지 UDP를 쓰는지 어떻게 알 수 있나요? ]

브라우저는 서버가 TCP를 사용하는지 UDP를 사용하는지를 직접적으로 알아내지 않는다.
대신, 사용자가 요청한 애플리케이션 계층 프로토콜(예: HTTP, HTTPS, DNS 등)에 따라 미리 정해진 전송 계층 프로토콜(TCP 또는 UDP)을 자동으로 사용한다.

 

---

🔗 Next: HTTPS

https://dev-heyjin.tistory.com/entry/Network-HTTPS-Protocol

[네트워크] HTTPS 프로토콜