인사
안녕하세요. 오랜만에 포스팅을 하게 되었습니다.
그동안 이것저것 바쁘게 지내다 보니 글을 미루게 되었는데요, 앞으로도 자주 올리기는 쉽지 않을 것 같습니다. 그래도 시간이 날 때마다 꾸준히 기록을 남기려고 합니다.
오늘 다룰 주제는 HTTP 프로토콜입니다.
HTTP는 오랫동안 가장 많이 사용되는 프로토콜 중 하나로 자리 잡았으며, 웹을 이해하는 데 있어 핵심적인 요소입니다. 따라서 HTTP 프로토콜을 정확히 이해하는 것은 개발자에게 매우 중요한 학습 과정이라고 생각합니다.
이번 글에서는 HTTP 프로토콜을 간단히 소개하려고 합니다. 글의 내용은 MDN 문서를 참고하여 정리하였으니, 더 깊이 있는 설명이 필요하신 분들은 MDN 공식 문서를 참고하시는 것을 추천드립니다.
http 프로토콜이란?
HTTP(HyperText Transfer Protocol)는 하이퍼텍스트 기반의 통신 규약으로, 두 매개체가 하이퍼텍스트를 이용해 데이터를 주고받는 방식을 정의합니다. 이때 전송되는 데이터의 타입은 특정한 형식에 국한되지 않으며, Stateless(무상태) 특성을 가지고 있어 각 요청은 독립적으로 처리됩니다. 요청 시에는 상황에 따라 헤더(header) 정보와 함께 본문(body) 데이터를 전달하는 구조를 가집니다.
원래 HTTP는 클라이언트와 서버 간 통신을 목적으로 설계되었지만, 현재는 웹뿐만 아니라 다양한 분야에서 활용되며 가장 널리 사용되는 프로토콜로 자리잡았습니다.
따라서 HTTP 프로토콜은 백엔드 개발자와 프론트엔드 개발자 모두 필수적으로 이해해야 하는 핵심 기술입니다. 현재 주로 사용되는 버전은 HTTP/1.1, HTTP/2, HTTP/3이며, 최근에는 HTTP/3가 점유율을 점점 확대해 나가고 있지만 여전히 HTTP/1.1과 HTTP/2도 활발히 사용되고 있습니다.
이번 글에서 다룰 내용
제가 이번에 소개할 HTTP 프로토콜의 주요 요소는 다음과 같습니다:
-
Header: 요청 및 응답의 메타데이터
-
MIME Type: 데이터의 형식을 정의하는 방법
-
Status Code: 요청 처리 결과를 나타내는 응답 코드
-
HTTP 버전(1.1, 2, 3): 각 버전별 특징과 차이점
HTTP 프로토콜의 Header
HTTP 프로토콜은 요청(request)과 응답(response)을 주고받을 때 헤더(Header) 와 본문(Body) 를 함께 전달합니다. (HTTPS의 경우, 보안 계층에서 암호화 과정을 거친 뒤 전달됩니다.)
Body는 메서드에 따라 포함될 수도 있고 생략될 수도 있지만, Header는 반드시 포함되어야 합니다.
Method란?
HTTP 프로토콜에서 Method는 요청의 동작을 나타내며 흔히 HTTP 동사라고 불립니다. 대표적인 메서드는 다음과 같습니다:
-
GET: 데이터 조회
-
POST: 데이터 생성
-
PUT: 데이터 수정
-
DELETE: 데이터 삭제
필수 헤더
요청과 응답에는 반드시 포함되어야 하는 기본 헤더가 존재합니다.
-
요청 헤더 필수 요소:
(메서드) (라우트) (HTTP 버전)
예)POST / HTTP/1.1 -
응답 헤더 필수 요소:
(HTTP 버전) (Status 코드) (메시지)
예)HTTP/1.1 200 OK
헤더의 역할
필수 헤더 외에도 다양한 헤더가 존재하며, 브라우저가 자동으로 설정하는 경우도 있고, 프론트엔드 개발자가 직접 추가할 수도 있습니다. 이를 통해 서버와 클라이언트는 캐싱, 압축, 보안, 데이터 타입 지정 등 다양한 기능을 수행할 수 있습니다.
1. 캐싱(Cache)
Cache-Control 헤더가 있습니다. 요청과 응답 모두에 사용 가능하며, 서버에서 최종적으로 승인합니다.각 옵션의 의미는 다음과 같습니다.
-
no-cache: 캐시된 데이터를 쓰기 전에 반드시 서버 검증 필요
-
no-store: 캐시 자체를 저장하지 않음
-
must-revalidate: 캐시 사용 전 유효성 재검증
이러한 캐싱은 주로 변경이 적은 정적 리소스(CSS, JS 등) 에 사용되어 UX를 향상시킬 수 있습니다. 반면, 보안과 직결된 데이터에는 캐싱을 피하는 것이 중요합니다.
2. 압축(Compression)
대표적으로 Content-Encoding 헤더가 있으며, 요청과 응답 모두에서 활용됩니다. 주로 서버에서 설정하며 성능 최적화에 중요한 역할을 합니다.
지원되는 압축 방식:
gzip-
deflate -
br(Brotli, 2015년 등장)
특징:
-
압축 대상은 주로 텍스트 기반 데이터(HTML, JS, CSS 등) 입니다.
-
이미지, 동영상, 음성은 이미 자체 압축 형식이 있으므로 별도의 HTTP 압축을 적용할 필요가 없습니다.
-
gzip은 전통적인 중복 치환 방식으로 널리 사용되며, br은 더 높은 압축률을 제공하지만 압축 시간이 길다는 특징이 있습니다.
브라우저는 응답 시 Content-Encoding 헤더를 보고 자동으로 압축을 해제한 뒤 사용자에게 표시합니다.
3. 보안(Security)
보안과 관련된 다양한 헤더들이 존재하며, 대표적으로 다음과 같은 문제를 방지하기 위해 사용됩니다.
-
CORS (교차 출처 리소스 공유)
-
Access-Control-Allow-*헤더를 통해 클라이언트-서버 간 계약 관계를 정의
-
-
XSS (교차 사이트 스크립트 공격)
-
X-XSS-Protection헤더를 통해 스크립트 삽입 방어
-
-
CSRF (사이트 간 요청 위조)
-
Cookie헤더 및 토큰 기반 전략으로 방지
-
이러한 보안 이슈는 웹 개발에서 가장 중요한 부분 중 하나이므로, 헤더를 적절히 설정하는 것이 필수적입니다.
MIME Type
MIME Type의 표준화
-
MIME Type은 IETF의 표준에 따라 정의되며, 관리 기관은 IANA(Internet Assigned Numbers Authority) 입니다.
-
헤더에서
Content-Type을 통해 명시되며, 요청과 응답 모두에서 지정할 수 있습니다. -
형식은
type/subtype구조를 따르며, 필요 시 세미콜론(;)을 기준으로 선택적 매개변수를 추가할 수 있습니다.
예시:
MIME Type의 분류
MIME Type은 크게 두 가지 클래스로 나뉩니다.
1. Discrete (단일 타입)
-
application/json,text/html,image/png등 개별 파일 형식을 나타냅니다. -
주로 텍스트 파일(html, css, js 등)이나 이미지, 오디오, 비디오 데이터에 사용됩니다.
-
장점: 단순하고 구현이 쉽다.
2. Multipart (다중 파트 타입)
-
여러 개의 다른 타입 데이터를 묶어서 전송할 때 사용됩니다.
-
예: 인스타그램 게시글 → 이미지(jpeg) + 텍스트(html) 같이 서로 다른 타입을 한 번에 전송 가능
-
자바스크립트에서는 FormData API가 이를 활용합니다.
-
장점: 다양한 타입을 한 번에 보낼 수 있음
-
단점: 서버-클라이언트 간 계약이 필요하며 구조가 더 복잡함
대표적인 MIME Type
-
텍스트 계열:
-
text/plain,text/html,text/css,text/javascript
-
-
데이터 교환:
-
application/json,application/xml
-
-
이미지:
-
image/png,image/jpeg,image/webp
-
-
오디오/비디오:
-
audio/wav,video/webm
-
이를 통해 HTTP는 단순한 문서 교환을 넘어 다양한 멀티미디어 데이터 교환을 가능하게 합니다.
Multipart 예시
Multipart 전송에서는 boundary를 이용해 각 파트를 구분합니다.
각 파트는
boundary로 구분됩니다.-
각 구간 안에는 소규모 헤더(Content-Disposition, Content-Type) 와 실제 데이터가 들어갑니다.
-
서버는 이를 파싱해 각각의 데이터를 분리하고 저장합니다. (Node.js 환경에서는 주로 Buffer를 사용해 처리)
정리
MIME Type은 HTTP 프로토콜의 본질적 목적 중 하나인 데이터 교환을 가능하게 하는 핵심 요소입니다.
-
서버는 MIME Type을 통해 클라이언트가 데이터를 이해할 수 있도록 정의하고,
-
클라이언트는 이를 기반으로 올바르게 파싱하여 사용자에게 표시합니다.
즉, MIME Type은 서버와 브라우저 간의 공통 언어라 할 수 있습니다.
HTTP Status Code
HTTP의 상태 코드(Status Code) 는 서버가 클라이언트의 요청을 처리한 결과를 알려주는 중요한 수단입니다. 보통 응답 헤더(Response Header) 에 포함되어 브라우저나 클라이언트에게 전달되며, 이를 통해 클라이언트는 요청이 성공했는지, 추가 동작이 필요한지, 오류가 발생했는지를 이해할 수 있습니다.
상태 코드는 1xx, 2xx, 3xx, 4xx, 5xx 다섯 가지 범주로 나뉘며, 각 범주는 의미가 다릅니다.
1. 2xx – 성공(Success)
2xx 상태 코드는 요청이 정상적으로 처리되었음을 의미합니다.
-
200 OK : 요청이 성공적으로 처리됨
-
201 Created : POST 요청 등으로 새로운 리소스가 생성됨
-
204 No Content : 요청은 성공했으나 반환할 데이터가 없음
→ 서버와 클라이언트 간에 문제가 없는 깔끔한 성공 관계를 나타냅니다.
2. 3xx – 리다이렉션(Redirection)
3xx 상태 코드는 요청을 완료하기 위해 추가 동작(리다이렉션) 이 필요함을 의미합니다.
-
300 Multiple Choices : 여러 응답 중 클라이언트가 선택해야 함
-
302 Found : 임시 이동, GET은 그대로 유지되지만 POST는 상황에 따라 바뀔 수 있음
-
303 See Other : 요청 결과를 GET으로 다시 요청하도록 유도 (POST → GET 변환)
-
307 Temporary Redirect : 메서드(GET, POST 등)를 바꾸지 않고 리다이렉션
-
308 Permanent Redirect : 영구 리다이렉션, 메서드 유지
→ 3xx 계열은 주로 리다이렉션 처리에서 사용되며, 브라우저가 자동으로 새 위치(Location)로 이동할 수 있습니다.
3. 4xx – 클라이언트 오류(Client Error)
4xx 상태 코드는 문제의 원인이 클라이언트 측에 있을 때 사용됩니다.
-
400 Bad Request : 잘못된 요청 (데이터 검증 실패, 규격 불일치 등)
-
401 Unauthorized : 인증 실패 (JWT 토큰 불일치, 세션 만료 등)
-
403 Forbidden : 인가 실패 (권한 없음)
-
404 Not Found : 요청한 리소스를 찾을 수 없음 (또는 보안상 숨김 처리)
-
409 Conflict : 요청 충돌 (중복된 리소스, 이메일 중복 등)
→ 클라이언트가 요청을 잘못 보냈거나 권한 문제로 요청이 거절된 상황을 알리는 데 쓰입니다.
4. 5xx – 서버 오류(Server Error)
5xx 상태 코드는 요청 자체는 유효하지만, 서버 내부에서 문제가 발생했을 때 사용됩니다.
-
500 Internal Server Error : 예상치 못한 서버 오류 (구체적 원인은 숨기는 것이 일반적)
-
502 Bad Gateway : 게이트웨이나 프록시 서버가 잘못된 응답을 받음 (API Gateway, MSA 환경에서 자주 발생)
-
503 Service Unavailable : 서버 과부하 또는 점검으로 서비스 불가
-
504 Gateway Timeout : 게이트웨이나 프록시가 응답을 제때 받지 못함
→ 서버 측 문제이므로 클라이언트는 요청을 반복하거나 다른 서버를 시도할 수 있습니다.
정리
HTTP 상태 코드는 단순한 숫자가 아니라, 클라이언트-서버 간의 소통을 돕는 중요한 언어입니다.
-
2xx → 성공
-
3xx → 리다이렉션
-
4xx → 클라이언트 오류
-
5xx → 서버 오류
특히 303 See Other처럼 리다이렉션과 메서드 변환을 명확히 지정할 수 있는 상태 코드는 기능적으로나 디버깅 측면에서 매우 중요한 역할을 합니다.
HTTP의 종류 (1.1 / 2 / 3)
HTTP/3이 가장 최신 버전으로 HTTP/2의 한계를 개선한 형태로 등장했지만, 반드시 상위 호환이라 볼 수는 없으며, 상황에 따라 여전히 HTTP/1.1과 HTTP/2가 사용됩니다. 따라서 프로젝트의 규모, 인력, 시간, 비용을 고려하여 적절한 버전을 선택하는 것이 중요합니다.
1. HTTP/1.1
-
특징: 바이트 스트림 기반
-
가장 오래되었지만 여전히 많이 사용되는 버전
-
Keep-Alive 옵션으로 TCP 연결을 일정 시간 유지 → 매 요청마다 핸드셰이크를 하지 않아도 됨
-
과거에는 파이프라이닝으로 병렬 처리 시도를 했으나, 요청/응답 순서 제약으로 사실상 사용되지 않음
-
현재는 여러 개의 소켓을 열어 직렬 처리
-
장점: 구현이 쉽고 안정적, 성능 문제도 크지 않음
-
단점: 대규모 트래픽 환경에서는 소켓을 많이 열어야 하므로 비효율적
2. HTTP/2
-
특징: 바이너리 프레임 기반
-
HTTP/1.1의 파이프라이닝 문제를 해결 → 하나의 연결에서 병렬 처리 가능
-
TCP 연결 기반으로 신뢰성 확보
-
요청과 응답이 순서와 상관없이 처리 가능 → 조립 과정에서 문제 없음
-
TLS와 결합하여 핸드셰이크 시간을 단축, 성능 향상
-
장점: 높은 성능, 병렬 처리, 기존 1.1에서 확장 용이
-
단점:
-
하나의 소켓에 다수 요청을 몰아 처리 → 특정 요청 오류가 다른 요청에도 영향을 줌
-
클라이언트가 소켓을 오래 점유할 경우 병목 현상 발생 가능
-
3. HTTP/3
-
특징: UDP 기반, QUIC 프로토콜 활용 (2015년 구글이 제안)
-
HTTP/2의 성능 문제와 TCP 한계를 개선
-
요청 단위로 병렬 처리 가능, 오류 발생 시에도 다른 요청에 영향 없음
-
HTTPS 필수 → 공개키가 자동 전달되어 TLS 핸드셰이크 포함
-
장점:
-
빠른 속도
-
각 요청이 독립적으로 처리되어 안정성 확보
-
순서 제약 없음 → 네트워크 환경이 불안정해도 성능 유지
-
-
단점:
-
HTTP/1.1 → HTTP/2는 확장이 비교적 쉬웠으나, HTTP/3는 구조적 차이로 인해 전환 비용이 큼
-
기존 대규모 시스템에 적용하려면 많은 시간과 비용이 필요
-
정리
-
HTTP/1.1: 단순, 안정적, 소규모/중규모 프로젝트에 여전히 적합
-
HTTP/2: 병렬 처리 성능, 기존 시스템에서 확장 용이
-
HTTP/3: 최신 기술, 빠르고 안정적이지만 도입 난이도와 비용이 존재
즉, HTTP 버전 선택은 “기술적 이점”뿐 아니라 프로젝트 규모·예산·기술 스택까지 고려해야 하는 전략적인 결정입니다.
마무리
오늘은 오랜만에 HTTP 프로토콜에 대해 정리해 보았습니다.
앞서 말씀드린 것처럼 HTTP는 프론트엔드와 백엔드 개발자 모두 반드시 이해해야 할 핵심 기술입니다.
짧게나마 주요 개념과 요소들을 살펴보았는데, 이 글이 HTTP 프로토콜을 공부하시거나 정리하는 데 작은 도움이 되었으면 합니다.
그럼 모두 남은 연휴 잘 보내시고, 하시는 일마다 좋은 결과 있으시길 바랍니다.
