STUDY

[네트워크] HTTP 정리: 특징, 메시지 구조, 메서드, 상태 코드

sed 2026. 5. 28. 23:56
SMALL

HTTP

HTTP는 웹에서 가장 중요한 프로토콜 중 하나이다.

 

우리가 웹 브라우저에서 페이지를 열고, 이미지를 보고, 파일을 내려받고, 서버에 데이터를 보내는 과정 대부분은 HTTP를 기반으로 이루어진다.

 

HTTP는 HyperText Transfer Protocol의 약자이다.

이름만 보면 하이퍼텍스트를 전송하기 위한 프로토콜처럼 보이지만, 오늘날 HTTP는 HTML 문서뿐만 아니라 이미지, 영상, JSON, XML, PDF 등 다양한 자원을 주고받는 데 사용된다.

 

HTTP의 대표적인 특징은 다음과 같다.

요청-응답 기반 프로토콜
미디어 독립적 프로토콜
상태를 유지하지 않는 프로토콜
지속 연결을 지원하는 프로토콜

 

요청-응답 기반 프로토콜

HTTP는 클라이언트와 서버 구조를 기반으로 동작한다.

 

클라이언트는 서버에게 요청을 보내고, 서버는 그 요청에 대한 응답을 보낸다.

 

웹 브라우저에서 어떤 웹 페이지에 접속하는 상황을 생각해보자.

 

브라우저는 서버에게 “이 페이지를 주세요”라고 요청한다.
서버는 요청받은 페이지를 찾아서 응답으로 돌려준다.

 

HTTP는 요청 메시지와 응답 메시지가 따로 존재한다.

클라이언트가 보내는 HTTP 요청 메시지와 서버가 보내는 HTTP 응답 메시지는 구조가 조금 다르다.

 

미디어 독립적 프로토콜

HTTP는 특정 종류의 데이터만 주고받는 프로토콜이 아니다.

HTML 문서, 이미지, 영상, JSON, XML, PDF 등 다양한 자원을 HTTP로 주고받을 수 있다.

 

HTTP 공식 문서에서는 HTTP가 요청하는 대상을 자원(resource)이라고 설명한다. HTTP는 자원의 종류를 제한하지 않고, 자원과 상호작용하기 위한 인터페이스를 정의한다.

 

자원은 대부분 URI로 식별된다.

 

예를 들어 다음과 같은 자원들이 모두 HTTP로 주고받아질 수 있다.

HTML 문서
JPEG 이미지
PNG 이미지
JSON 데이터
XML 데이터
PDF 파일
동영상 파일

 

HTTP는 자원의 내용이 무엇인지에 강하게 묶이지 않는다.
서버와 클라이언트가 주고받는 자원의 종류는 미디어 타입으로 표현된다.

 

미디어 타입

미디어 타입(media type)은 HTTP에서 주고받는 자원의 종류를 나타내는 정보이다.

MIME 타입이라고도 부른다.

 

미디어 타입은 타입/서브타입 형식으로 표현된다.

타입은 데이터의 큰 분류를 나타내고, 서브타입은 그 안의 세부 형식을 나타낸다.

 

예를 들어 HTML 문서는 다음처럼 표현된다.

text/html

 

JSON 데이터는 다음처럼 표현된다.

application/json

 

미디어 타입에는 선택적으로 매개변수가 붙을 수도 있다.

 

예를 들어 문자 인코딩 정보를 함께 나타내면 다음처럼 쓸 수 있다.

text/html; charset=UTF-8

 

대표적인 미디어 타입의 큰 분류는 다음과 같다.

text
image
video
audio
application
multipart

 

여러 미디어 타입을 통칭할 때는 별표 문자를 사용할 수 있다.

 

HTTP는 주고받을 미디어 타입에 특별한 제한을 두지 않는다.
그래서 HTTP를 미디어 독립적 프로토콜이라고 한다.

 

상태를 유지하지 않는 프로토콜

HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜이다.

서버가 클라이언트의 이전 요청 상태를 기본적으로 기억하지 않는다는 뜻이다.

 

클라이언트가 같은 서버에 여러 번 요청을 보내더라도, 각각의 요청은 기본적으로 독립적인 요청으로 간주된다.

 

예를 들어 클라이언트가 다음과 같이 요청한다고 하자.

첫 번째 요청: 상품 목록 주세요.
두 번째 요청: 장바구니에 담아주세요.
세 번째 요청: 결제할게요.

 

HTTP 자체만 놓고 보면 서버는 이전 요청을 자동으로 기억하지 않는다.
각 요청은 독립적으로 처리된다.

 

HTTP가 상태를 유지하지 않는 이유

HTTP 서버는 일반적으로 매우 많은 클라이언트와 동시에 통신한다.

만약 서버가 모든 클라이언트의 상태를 계속 기억해야 한다면 서버 부담이 커진다.

 

또한 오늘날 웹 서비스는 여러 서버가 함께 동작하는 경우가 많다.

 

클라이언트의 상태를 특정 서버만 기억한다면, 그 클라이언트는 계속 같은 서버와만 통신해야 한다.
이렇게 되면 서버를 여러 대로 확장하거나, 장애가 발생했을 때 다른 서버로 대체하기 어려워진다.

 

HTTP가 상태를 유지하지 않으면 클라이언트가 특정 서버에 강하게 묶이지 않는다.

서버에 문제가 생겨도 다른 서버가 요청을 처리할 수 있고, 여러 서버가 나누어 요청을 처리하기도 쉬워진다.

 

이 특성은 확장성과 견고성에 유리하다.

 

다만 실제 웹 서비스에서는 로그인 상태나 장바구니처럼 상태가 필요한 경우가 많다.
이런 상태는 쿠키, 세션, 토큰 같은 별도의 기술을 이용해 관리한다.

 

지속 연결을 지원하는 프로토콜

초기의 HTTP는 비지속 연결 방식으로 동작했다.

비지속 연결에서는 요청과 응답이 한 번 끝나면 TCP 연결을 닫는다.

 

다시 요청을 보내려면 TCP 연결을 새로 수립해야 한다.

TCP 연결 수립
HTTP 요청
HTTP 응답
TCP 연결 종료

 

웹 페이지 하나를 불러올 때 HTML 문서뿐만 아니라 이미지, CSS, JavaScript 파일 등 여러 자원이 필요하다.

 

매번 TCP 연결을 새로 만들고 닫으면 시간이 많이 든다.

 

이를 줄이기 위해 HTTP는 지속 연결을 지원한다.

 

지속 연결(persistent connection) 또는 keep-alive는 하나의 TCP 연결에서 여러 HTTP 요청과 응답을 주고받을 수 있게 하는 방식이다.

TCP 연결 수립
HTTP 요청/응답
HTTP 요청/응답
HTTP 요청/응답
TCP 연결 종료

 

지속 연결을 사용하면 불필요한 연결 수립과 종료 비용을 줄일 수 있다.

 

 

HTTP 메시지 구조

HTTP 메시지는 크게 세 부분으로 구성된다.

시작 라인
필드 라인
메시지 본문

 

필드 라인은 없을 수도 있고 여러 개 있을 수도 있다.

 

메시지 본문도 항상 존재하는 것은 아니다.
GET 요청처럼 본문이 없는 요청도 있고, POST 요청처럼 본문을 포함하는 요청도 있다.

 

필드 라인과 메시지 본문 사이에는 빈 줄이 들어간다.

 

 

 

HTTP 메시지는 요청 메시지일 수도 있고 응답 메시지일 수도 있다.

 

요청 메시지의 시작 라인은 요청 라인이라고 한다.
응답 메시지의 시작 라인은 상태 라인이라고 한다.

 

요청 라인

HTTP 요청 메시지의 시작 라인은 요청 라인이다.

 

요청 라인은 다음 형식으로 구성된다.

메서드 요청 대상 HTTP 버전

 

예를 들어 다음과 같다.

GET /index.html HTTP/1.1

 

여기서 GET은 메서드이다.

/index.html은 요청 대상이다.

HTTP/1.1은 HTTP 버전이다.

메서드

메서드는 클라이언트가 서버의 자원에 대해 수행하려는 작업의 종류를 나타낸다.

대표적인 메서드에는 GET, POST, PUT, PATCH, DELETE 등이 있다.

 

요청 대상

요청 대상은 HTTP 요청을 보낼 서버의 자원을 나타낸다.

보통 URI의 경로가 들어간다.

 

예를 들어 다음 요청에서 요청 대상은 /users이다.

GET /users HTTP/1.1

 

하위 경로가 없더라도 요청 대상은 /로 표시한다.

GET / HTTP/1.1

 

상태 라인

HTTP 응답 메시지의 시작 라인은 상태 라인이다.

상태 라인은 다음 형식으로 구성된다.

HTTP 버전 상태 코드 이유 구문

 

예를 들어 다음과 같다.

HTTP/1.1 200 OK

 

상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수이다.

 

이유 구문은 상태 코드에 대한 짧은 설명이다.

200 OK
404 Not Found
500 Internal Server Error

 

필드 라인

필드 라인은 HTTP 헤더를 나타낸다.

 

HTTP 헤더는 HTTP 통신에 필요한 부가 정보를 담는다.

 

헤더는 콜론을 기준으로 헤더 이름과 헤더 값으로 구성된다.

 

예를 들어 다음과 같다.

Content-Type: application/json
Content-Length: 123
Host: example.com

 

헤더에는 자원의 미디어 타입, 메시지 본문의 길이, 인증 정보, 캐시 정보 등 다양한 부가 정보가 들어갈 수 있다.

메시지 본문

메시지 본문은 HTTP 요청이나 응답에서 실제 데이터를 담는 부분이다.

항상 존재하는 것은 아니다.

 

예를 들어 GET 요청은 보통 메시지 본문이 없다.

 

반면 POST 요청은 서버에 보낼 데이터를 메시지 본문에 담는 경우가 많다.

응답 메시지에서는 HTML 문서, JSON 데이터, 이미지 파일 등이 메시지 본문에 담길 수 있다.

 

HTTP 메서드

HTTP 메서드는 클라이언트가 서버의 자원에 대해 어떤 작업을 하려는지 나타낸다.

GET

GET은 자원을 조회할 때 사용하는 메서드이다.

클라이언트가 서버에게 특정 자원을 요청할 때 사용한다.

GET은 웹에서 가장 자주 사용되는 메서드이다.

HEAD

HEAD는 GET과 비슷하지만 응답 본문을 받지 않는다.

서버는 요청에 대한 응답으로 헤더만 반환한다.

본문을 가져오지 않고 자원의 메타데이터만 확인하고 싶을 때 사용할 수 있다.

POST

POST는 서버가 특정 작업을 처리하도록 요청할 때 사용한다.

처리할 데이터는 보통 메시지 본문에 담긴다.

새로운 자원을 생성할 때 자주 사용된다.

예를 들어 사용자가 회원가입 정보를 서버에 보낼 때 POST를 사용할 수 있다.

 

새로운 자원이 생성되면 서버는 응답 메시지의 Location 헤더를 통해 생성된 자원의 위치를 알려줄 수 있다.

PUT

PUT은 요청한 자원을 새로 만들거나 완전히 대체할 때 사용한다.

 

요청한 자원이 없으면 메시지 본문을 바탕으로 새 자원을 생성할 수 있다.

요청한 자원이 이미 존재하면 기존 자원을 메시지 본문의 내용으로 완전히 덮어쓴다.

 

PUT은 “이 자원을 이 내용으로 바꿔주세요”에 가깝다.

PATCH

PATCH는 자원의 일부를 수정할 때 사용한다.

PUT이 전체 대체에 가깝다면, PATCH는 부분 수정에 가깝다.

 

예를 들어 사용자 정보 중 이름만 바꾸거나, 설정 값 일부만 바꿀 때 사용할 수 있다.

DELETE

DELETE는 특정 자원을 삭제할 때 사용한다.

CONNECT, OPTIONS, TRACE

CONNECT는 주로 프록시 서버를 통해 터널을 만들 때 사용된다.

OPTIONS는 서버가 특정 자원에 대해 어떤 메서드를 지원하는지 확인할 때 사용할 수 있다.

TRACE는 요청 메시지가 서버까지 어떻게 도달하는지 테스트하기 위한 용도로 사용된다.

다만 실제 서비스에서는 보안상의 이유로 TRACE를 비활성화하는 경우가 많다.

HTTP 메서드와 서버 구현

HTTP 메서드의 의미는 정해져 있지만, 특정 URL에 어떤 메서드를 허용하고 어떤 동작을 수행하게 할지는 서버 개발자가 설계한다.

같은 URL이라도 메서드에 따라 다른 동작을 하도록 만들 수 있다.

GET /users
사용자 목록 조회

POST /users
새 사용자 생성

GET /users/1
1번 사용자 조회

PATCH /users/1
1번 사용자 일부 수정

DELETE /users/1
1번 사용자 삭제

 

서버가 어떤 메서드는 구현할 수도 있고, 어떤 메서드는 지원하지 않을 수도 있다.

HTTP 상태 코드

HTTP 상태 코드는 클라이언트의 요청에 대한 처리 결과를 나타내는 세 자리 정수이다.

상태 코드는 백의 자리 숫자를 기준으로 유형을 구분한다.

100번대: 정보성 상태 코드
200번대: 성공 상태 코드
300번대: 리다이렉션 상태 코드
400번대: 클라이언트 에러 상태 코드
500번대: 서버 에러 상태 코드

 

100번대 상태 코드

100번대 상태 코드는 정보성 상태 코드이다.

요청이 계속 처리 중이거나, 클라이언트가 다음 동작을 이어가도 된다는 의미로 사용된다.

일반 사용자가 웹 브라우징 중 직접 자주 마주치는 코드는 아니다.

200번대 상태 코드

200번대 상태 코드는 요청이 성공했음을 의미한다.

대표적인 상태 코드는 다음과 같다.

200 OK
201 Created
202 Accepted
204 No Content

 

200 OK는 요청이 성공적으로 처리되었음을 나타낸다.

201 Created는 요청이 성공했고 새로운 자원이 생성되었음을 나타낸다.

202 Accepted는 요청을 잘 받았지만 아직 처리가 완료되지 않았음을 나타낸다.

204 No Content는 요청은 성공했지만 응답 본문으로 보낼 데이터가 없음을 나타낸다.

300번대 상태 코드

300번대 상태 코드는 리다이렉션과 관련된다.

리다이렉션은 클라이언트가 요청한 자원이 다른 위치에 있거나, 요청을 완수하기 위해 다른 URL로 이동해야 하는 상황을 말한다.

리다이렉션은 크게 영구적인 리다이렉션과 일시적인 리다이렉션으로 나눌 수 있다.

영구적인 리다이렉션

영구적인 리다이렉션은 자원의 위치가 완전히 새로운 곳으로 옮겨졌을 때 사용된다.

기존 URL로 요청을 보내면 앞으로도 계속 새로운 URL로 이동해야 한다.

 

대표적인 상태 코드는 다음과 같다.

301 Moved Permanently
308 Permanent Redirect

 

301은 영구 이동을 의미한다.
다만 재요청 과정에서 메서드가 GET으로 바뀔 수 있다.

 

예를 들어 클라이언트가 GET이 아닌 요청을 보냈더라도, 리다이렉션된 URL로 다시 요청할 때 GET으로 바뀔 수 있다.

 

308도 영구 리다이렉션을 의미하지만, 재요청 메서드가 변경되지 않는다.

 

일시적인 리다이렉션

일시적인 리다이렉션은 자원의 위치가 임시로 바뀌었거나, 임시 URL을 사용해야 할 때 사용된다.

기존 URL은 여전히 기억해야 한다.

 

대표적인 상태 코드는 다음과 같다.

302 Found
303 See Other
307 Temporary Redirect

 

302는 일시적인 리다이렉션을 의미한다.
재요청 메서드가 GET으로 바뀔 수 있다.

303은 다른 위치를 GET 메서드로 조회하라는 의미로 사용된다.

307은 일시적인 리다이렉션이지만, 재요청 메서드가 변경되지 않는다.

 

400번대 상태 코드

400번대 상태 코드는 클라이언트 쪽 요청에 문제가 있음을 나타낸다.

 

대표적인 상태 코드는 다음과 같다.

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed

 

400 Bad Request는 클라이언트의 요청 자체가 잘못되었음을 의미한다.

요청 형식이 잘못되었거나, 필요한 값이 누락되었거나, 서버가 요청을 이해할 수 없는 경우에 발생할 수 있다.

401 Unauthorized는 인증이 필요하다는 의미이다.

특정 자원에 접근하려면 로그인이나 인증 정보가 필요한데, 클라이언트가 적절한 인증 정보를 보내지 않았을 때 사용된다.

403 Forbidden은 서버가 요청을 이해했지만, 클라이언트에게 접근 권한이 없다는 의미이다.

인증은 되었지만 권한이 부족한 경우에 자주 사용된다.

404 Not Found는 요청한 자원을 찾을 수 없다는 의미이다.

해당 URL의 자원이 존재하지 않거나, 공개되지 않은 자원에 접근하려고 할 때 볼 수 있다.

405 Method Not Allowed는 요청한 메서드를 서버가 지원하지 않는다는 의미이다.

예를 들어 특정 URL은 GET만 지원하는데 DELETE 요청을 보내면 405가 발생할 수 있다.

500번대 상태 코드

500번대 상태 코드는 서버 쪽 문제로 요청을 처리하지 못했음을 나타낸다.

클라이언트가 올바른 요청을 보냈더라도 서버 내부 문제로 에러가 발생할 수 있다.

 

대표적인 상태 코드는 다음과 같다.

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable

 

500 Internal Server Error는 서버 내부에서 예기치 못한 문제가 발생했음을 의미한다.

서버 코드 오류, 예외 처리 실패, 내부 설정 문제 등 다양한 원인으로 발생할 수 있다.

502 Bad Gateway는 중간 서버나 게이트웨이에서 잘못된 응답을 받았을 때 발생한다.

클라이언트와 최종 서버 사이에 있는 프록시, 게이트웨이, 로드 밸런서 등의 통신 문제와 관련될 수 있다.

503 Service Unavailable은 현재 서버가 요청을 처리할 수 없음을 의미한다.

서버가 과부하 상태이거나, 일시적인 점검 중일 때 볼 수 있다.

상태 코드 정리

HTTP 상태 코드는 다음처럼 정리할 수 있다.

 

상태코드범위 의미 예시
100번대 정보성 응답 100 Continue
200번대 성공 200 OK, 201 Created, 204 No Content
300번대 리다이렉션 301, 302, 303, 307, 308
400번대 클라이언트 에러 400, 401, 403, 404, 405
500번대 서버 에러 500, 502, 503

 

 

 

 

 

 

LIST