HTTP 프로토콜
HTTP 프로토콜의 특징, 메시지, 메서드, 그리고 상태 코드
HTTP
HTTP Protocol
HTTP는 Hypertext Transfer Protocol의 약자로, 웹에서 HTML 문서와 같은 다양한 리소스를 가져올 수 있도록 하는 애플리케이션 계층 프로토콜이다. 웹 상의 모든 통신은 HTTP를 기반으로 이루어져, 클라이언트(브라우저)와 서버가 서로 대화하는 핵심 언어가 된다. HTTP는 인터넷을 통해 데이터를 주고받기 위해 만들어진 국제 표준 프로토콜로 구조가 단순하고 텍스트 기반이어서 사용하기 쉽다. 또한 JSON, HTML, 이미지, 영상 등 다양한 데이터 타입(MIME 타입)을 전송할 수 있어 웹 브라우저와 서버, 앱과 서버, 서버와 서버 등 이기종 시스템 간의 통신을 쉽게 처리할 수 있다.
HTTP는 단순한 데이터 전송을 넘어 현대 웹 기술의 근간을 이룬다. RESTful API 설계는 HTTP 메서드(GET, POST 등), 상태 코드(200, 404 등), URL 설계를 핵심으로 사용하며, 인증과 인가는 HTTP 헤더, 쿠키, 토큰 기반으로 처리된다. 또한 HTTPS, CORS(Cross-Origin Resource Sharing), CSRF(Cross-Site Request Forgery) 방어 등 대다수 보안 이슈와 네트워크 문제, API 호출 오류 역시 HTTP 레벨에서 파악할 수 있다.
HTTP와 HTTPS
HTTP는 요청과 응답이 평문으로 전송되어 암호화가 없다. 이와 달리 HTTPS는 HTTP에 TLS/SSL 암호화 계층을 추가한 것으로 데이터의 기밀성, 무결성, 인증을 보장한다. HTTP는 기본적으로 80번 포트를 사용하며 HTTPS는 443번 포트를 사용한다. HTTPS는 단지 HTTP의 버전 위(예: HTTPS 1.1, HTTPS 2.0)에 TLS를 얹어 보안을 추가한 것이지 독립적인 프로토콜은 아니다.
HTTP의 무상태성과 쿠키
HTTP는 기본적으로 무상태(Stateless) 프로토콜이다. 즉 서버는 클라이언트의 이전 요청에 대한 정보를 저장하지 않고 모든 요청을 독립적으로 처리한다. 이 특성은 서버의 확장성을 높이는 장점이 있지만, 로그인 세션 유지, 사용자 맞춤 설정 등 클라이언트의 상태를 지속적으로 유지하기 어렵다는 단점이 있다.
이러한 단점을 보완하기 위해 사용자 상태를 유지할 수 있는 쿠키(Cookie)가 도입되었다. 서버가 Set-Cookie 헤더를 통해 클라이언트에게 쿠키를 내려주면, 브라우저는 이 쿠키를 저장하고 이후 동일 도메인 요청 시 Cookie 헤더에 해당 데이터를 자동으로 포함하여 서버에 전송한다. 쿠키에는 주로 세션 ID, 사용자 설정 값, 인증 토큰 등 식별자나 상태 관련 데이터가 담긴다. 쿠키를 헤더에 담는 경우 HTTP 스펙에 따라 브라우저가 자동 관리 및 자동 전송하지만, HTTP 바디에 데이터를 담는 경우 애플리케이션 로직에서 수동으로 관리해야 하므로 매 요청마다 직접 데이터를 넣어야 한다는 차이가 있다.
URL
URL은 Uniform Resource Locator의 약자로, 웹 상에서 특정 리소스의 위치를 가리키는 주소다. URL은 URI(Uniform Resource Identifier)의 하위 개념으로 리소스의 위치를 계층적으로 지정한다.
URL은 크게 다음과 같이 구성된다.
- 스키마(Scheme): 리소스를 획득하기 위한 프로토콜을 나타낸다(
http,https,ftp). - 호스트명(Host): 리소스가 존재하는 호스트 컴퓨터(서버 주소)의 이름이다(
www.google.com). - 포트(Port): 서버에서 서비스에 접근하는 논리적인 통로 번호를 나타내며 기본 포트(80, 443)는 보통 생략된다.
- 경로명(Path): 지정된 호스트 내에서 리소스의 계층적인 위치를 나타낸다(
/webcontents/index.html). - 쿼리(Query): 리소스에 추가로 전달하는 파라미터를 담는다(
?name=value). - 프래그먼트(Fragment): 주소의 특정 부분을 지정하며 서버가 아닌 클라이언트(브라우저) 내에서만 사용된다.
HTTP Message
HTTP를 통한 정보 교환은 클라이언트가 보내는 HTTP 요청(Request)과 서버가 이에 응답하는 HTTP 응답(Response)의 형태로 이루어진다. 이 두 메시지는 모두 정해진 형식에 따라 헤더(Header)와 바디(Body)로 구성된다.
HTTP Request
클라이언트(웹 브라우저)가 서버에 리소스를 요청할 때 사용하는 메시지다. HTTP 요청은 요청 라인, 요청 헤더, 빈 줄, 요청 메시지 바디의 순서로 구성된다.
Request Message Header
헤더의 첫 줄인 요청 라인(Request Line)은 요청의 목적과 대상을 명시한다.
- HTTP 메서드: 클라이언트가 수행하고자 하는 동작을 정의한다. 주요 메서드로는 리소스 조회를 위한 GET, 데이터 생성을 위한 POST, 데이터 수정을 위한 PUT, 데이터 부분 수정을 위한 PATCH, 데이터 삭제를 위한 DELETE 등이 있다.
- URI: 요청하는 리소스의 경로를 나타낸다.
- HTTP 버전: 사용하고 있는 HTTP 프로토콜 버전을 명시한다(HTTP/1.1, HTTP/2).
요청 헤더(Request Headers)는 요청에 대한 부가 정보를 서버에 전달한다.
Host: 요청 대상 서버의 도메인 이름과 선택적인 포트 번호를 포함한다.User-Agent: 요청을 보낸 클라이언트 소프트웨어의 정보(웹 브라우저 종류, 운영체제 등)를 담는다.Accept: 클라이언트가 수신할 수 있는 선호하는 미디어 타입(MIME 타입)을 명시한다(text/html,application/json).Accept-Language: 클라이언트가 선호하는 언어 설정을 서버에 전달한다.Content-Type: 메시지 바디에 데이터가 포함된 경우 그 데이터의 형식(MIME 타입)을 명시한다.
Request Message Body
요청 메시지 바디는 서버에 전송할 실제 데이터를 담는 부분이다. GET 메서드와 같이 리소스를 조회하는 요청은 대부분 바디가 존재하지 않는다. 반면 POST, PUT, PATCH 등 서버에 새로운 데이터를 생성하거나 수정해야 하는 요청일 때 바디가 사용된다.
HTTP Response
서버가 클라이언트의 요청을 처리하고 그 결과를 돌려줄 때 사용하는 메시지다. HTTP 응답은 상태 라인, 응답 헤더, 빈 줄, 응답 메시지 바디의 순서로 구성된다.
Response Message Header
헤더의 첫 줄인 상태 라인(Status Line)은 요청 처리 결과를 나타낸다.
- HTTP 버전: 응답을 보낼 때 사용한 HTTP 프로토콜 버전을 명시한다.
- HTTP 상태 코드: 요청의 처리 결과를 나타내는 세 자리 숫자 코드다. 200(OK)은 성공, 201(Created)은 리소스 생성 성공, 404(Not Found)는 요청 리소스가 없음을 의미하는 등 다양한 코드가 있다.
- HTTP 응답 구문: 상태 코드를 사람이 이해하기 쉽게 설명하는 짧은 텍스트다(예: ‘OK’, ‘Not Found’, ‘Internal Server Error’)
응답 헤더(Response Headers)는 서버 정보, 캐시 제어 방법, 쿠키 설정 등 응답에 대한 부가 정보를 클라이언트에 전달한다.
Response Message Body
응답 메시지 바디는 클라이언트가 요청한 실제 리소스 데이터를 담는 부분이다. 웹 페이지 요청 시에는 HTML과 같은 텍스트 데이터가 담기며 이미지 파일 요청 시에는 GIF, JPEG와 같은 이미지 파일 데이터가 전송된다. 응답 바디의 형식은 응답 헤더의 Content-Type 필드를 통해 클라이언트에게 알려진다.
HTTP Method
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods
HTTP 메서드는 클라이언트가 서버에게 특정 리소스에 대해 수행하고자 하는 동작을 알리는 동사 역할을 한다. 리소스와 상호작용하는 방식과 서버에 미치는 영향을 규정한다.
GET
GET 메서드의 주요 목적은 서버로부터 리소스의 데이터를 조회하는 것이다.
멱등성
동일한 GET 요청을 반복해서 실행하더라도 서버에 미치는 영향이 없고 클라이언트가 받는 응답 결과 또한 항상 동일하다. 데이터 조회 목적으로 설계되었으므로, Request Body에 데이터를 포함하는 것은 표준적이지 않으며 멱등성을 깨뜨릴 수 있는 잠재적 위험을 안고 있어 권장되지 않는다. 리소스를 전달할 때는 쿼리(
?key=val) 방식을 사용한다.
안전성
GET 요청은 서버의 상태나 저장된 데이터에 어떠한 변경도 일으키지 않는다. 클라이언트가 몇 번을 요청하든 서버는 항상 동일한 리소스를 제공하며 부작용이 없다.
캐싱
GET 요청은 응답 결과에 대해 캐싱(Caching)이 가능하다는 이점이 있다. 서버가 응답한 리소스는 중간 계층(프록시 서버 등)이나 클라이언트 브라우저에 저장될 수 있으며, 동일한 요청이 다시 발생할 경우 서버에 직접 요청하는 대신 저장된 캐시된 응답을 사용하여 응답 시간을 단축하고 서버 부하를 줄일 수 있다.
POST
POST 메서드는 서버에 데이터를 전송하여 새로운 리소스를 생성하거나 특정 작업을 처리하도록 요청하는 데 사용된다.
비멱등성
같은 POST 요청을 여러 번 수행하면 반복적으로 새로운 리소스가 생성되거나 의도하지 않은 추가적인 부작용이 발생할 수 있다.(예: 결제 요청을 여러 번 보내면 중복 결제가 발생 가능)
비안전성
POST 요청은 서버의 상태를 변경할 목적으로 설계되었으므로 안전하지 않다.(예: 새 게시글 작성, 회원 가입)
Request Body 활용
POST 메서드는 전송할 데이터를 Request Body에 포함하며, 이는 메서드의 주요 특징이다. URL 길이에 제한 없이 대용량 데이터를 전송할 수 있으며, 민감한 정보도 URL 노출 없이 전송할 수 있다.
PUT
PUT 메서드는 요청 URI가 지정하는 리소스를 요청 본문에 담긴 내용으로 완전히 대체하는 데 사용된다. 만약 해당 URI에 리소스가 존재하지 않으면 서버는 새로운 리소스를 생성할 수도 있다. 주로 리소스 업데이트 목적으로 사용된다.
멱등성
같은 PUT 요청을 여러 번 수행하더라도 결과적으로 해당 리소스의 상태는 요청 본문의 내용으로 동일하게 유지된다. 즉, 한 번 업데이트하든 여러 번 업데이트하든 최종 상태는 같다.
비안전성
서버의 상태를 변경하므로 안전하지 않다.
전체 리소스 전송 필요
PUT을 사용할 때는 리소스의 일부만을 수정하더라도 요청 본문에 리소스의 전체를 담아 전송해야 한다. 이는 서버가 리소스를 완전히 교체하는 방식으로 작동하기 때문이다.
PATCH
PATCH 메서드는 요청 URI가 지정하는 리소스의 일부를 수정하는 데 사용된다. PUT이 리소스 전체를 교체하는 반면, PATCH는 리소스의 특정 필드나 속성만을 부분적으로 업데이트하기 위해 사용된다.
비멱등성
기본적으로 비멱등적이다. 예를 들어 “현재 값에 10을 더하라”는 PATCH 요청을 두 번 보내면, 리소스는 두 번 증가하여 처음과 다른 결과를 초래한다. 다만 조건부 요청 등을 사용하여 멱등적으로 구현할 수는 있다.
비안전성
서버의 상태를 변경하므로 안전하지 않다.
최소한의 데이터 전송
PATCH는 수정할 부분에 대한 정보만 담아 전송하므로, 전송되는 데이터의 양을 줄일 수 있어 대용량 리소스의 부분 수정 시 네트워크 효율성이 좋다.
DELETE
DELETE 메서드는 요청 URI가 지정하는 리소스를 삭제하도록 서버에 요청하는 데 사용된다.
멱등성
같은 DELETE 요청을 여러 번 수행하더라도, 첫 번째 요청으로 리소스가 삭제된 후에는 더 이상 추가적인 삭제 행위가 발생하지 않는다. 즉 리소스가 삭제된 상태로 동일하게 유지된다. 리소스가 이미 없는 상태에서 삭제를 시도하는 것도 성공으로 간주될 수 있기 때문에 멱등적이다.
비안전성
서버의 상태(해당 리소스의 존재 여부)를 변경하므로 안전하지 않다.
Request Body 사용 지양
DELETE 메서드는 주로 URI를 통해 삭제할 리소스를 식별하며, Request Body는 사용하지 않거나(일반적으로 정의된 의미가 없으므로) 사용을 지양하는 것이 좋다.
HTTP Status Code
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
HTTP 상태 코드는 클라이언트가 서버에 요청을 보냈을 때, 서버가 해당 요청을 어떻게 처리했는지 알려주는 세 자리 숫자다. 이 코드는 요청의 성공 여부, 오류 발생 여부 및 종류를 나타내어 통신을 어떻게 처리했는지 규정한다.
1xx(Informational)
1xx 코드는 요청이 접수되어 처리 중임을 나타낸다. 서버가 요청을 받았고, 계속 처리할 것임을 클라이언트에게 알려주는 용도로 최종 응답이 아니므로 일반적으로 응답 본문(Body)은 포함되지 않는다.
- 주요 코드
- 100 Continue: 클라이언트가 요청의 본문(Body)을 계속 전송해도 좋다는 응답이다. 클라이언트가 큰 파일을 보내기 전에 서버의 승인을 받는 데 사용된다.
- 101 Switching Protocols: 클라이언트의 요청에 따라 서버가 프로토콜을 변경하고 있음을 나타낸다.(HTTP에서 WebSocket으로 전환)
2xx(Success)
2xx 코드는 클라이언트의 요청이 성공적으로 수신, 이해 및 처리되었음을 나타낸다. 클라이언트가 기대한 결과나 그에 준하는 성공적인 처리 결과를 받았음을 나타낸다.
- 주요 코드
- 200 OK: 요청이 성공적으로 처리되었으며, 응답 본문에 요청한 데이터가 담겨있다. 가장 흔하게 볼 수 있는 성공 코드다.
- 201 Created: 새로운 리소스가 성공적으로 생성되었음을 나타낸다. 보통 POST 또는 PUT 요청의 결과로 사용된다.
- 204 No Content: 요청은 성공적으로 처리되었으나 클라이언트에게 돌려줄 응답 본문 데이터가 없음을 의미한다.(DELETE 요청 성공 후)
3xx(Redirection)
3xx 코드는 요청을 완료하기 위해 클라이언트가 추가적인 조치(리다이렉션)를 취해야 함을 나타낸다. 클라이언트에게 다른 URI로 요청을 다시 보내야 한다고 알려주며 이 과정은 캐싱과 관련이 있을 수 있다.
- 주요 코드
- 301 Moved Permanently: 요청한 리소스가 영구적으로 새로운 위치로 이동했음을 나타낸다.
- 302 Found(Temporarily Moved): 요청한 리소스가 일시적으로 다른 위치에 있음을 나타낸다.
- 304 Not Modified: 리소스가 변경되지 않았음을 알려주며 캐시된 버전을 사용하도록 클라이언트에 지시한다. GET 메서드의 캐싱 메커니즘에서 중요한 역할을 한다.
4xx(Client Error)
4xx 코드는 요청 구문이 잘못되었거나 유효하지 않은 요청을 보내는 등 클라이언트 측에 명백한 오류가 있어 서버가 요청을 처리할 수 없음을 나타낸다. 클라이언트가 요청을 수정해야 다시 성공할 수 있으며 요청은 멱등적이지 않을 수도 있다.
- 주요 코드
- 400 Bad Request: 요청의 구문이 유효하지 않거나 형식이 잘못되어 서버가 요청을 이해할 수 없다.
- 401 Unauthorized: 클라이언트가 인증(Authentication)되지 않았거나 유효한 인증 정보가 부족하다.
- 403 Forbidden: 서버가 클라이언트 요청을 이해했지만 권한 부족 등의 이유로 처리를 거부한다.(인증과 다르다)
- 404 Not Found: 요청한 리소스를 서버에서 찾을 수 없다. 가장 흔하게 발생하는 오류 코드다.
- 405 Method Not Allowed: 리소스는 존재하지만, 해당 리소스에 대해 요청에 사용된 HTTP 메서드(GET, POST 등)가 허용되지 않음을 나타낸다.
5xx(Server Error)
5xx 코드는 서버가 유효한 요청을 받았지만 내부적인 문제로 인해 요청을 처리하지 못했음을 나타낸다. 오류는 클라이언트의 잘못이 아니며 서버 측에서 해결해야 한다. 서버 오류이므로 일반적으로 멱등성 여부와 관계없이 재시도해 볼 수 있다.
- 주요 코드
- 500 Internal Server Error: 서버에 오류가 발생하여 요청을 처리할 수 없지만, 구체적인 오류 원인을 알 수 없을 때 사용되는 일반적인 오류 메시지다.
- 503 Service Unavailable: 서버가 과부하 또는 유지보수 등의 이유로 일시적으로 요청을 처리할 수 없음을 나타낸다. 서비스의 일시적인 중단을 알리는 데 사용된다.
HTTP 요약
HTTP Protocol
HTTP는 웹사이트에서 정보를 주고받는 프로토콜이다. 컴퓨터(클라이언트)와 정보를 가지고 있는 서버가 서로 대화할 때 쓰는 핵심 언어다. HTTP는 HTML, 사진, 동영상 등 다양한 종류의 데이터를 쉽게 전달할 수 있게 해준다. 한 번의 요청에 대해 서버가 이전 일을 기억하지 않는 ‘무상태’ 특징이 있지만, 쿠키라는 것을 이용해 로그인 같은 상태를 기억하게 할 수 있다. 정보를 안전하게 주고받기 위해 암호화를 추가한 것이 HTTPS이다.
HTTP Message
웹에서 정보가 오가는 방식은 두 가지 메시지로 이루어진다. 컴퓨터가 서버에게 정보를 달라고 보내는 ‘요청 메시지(Request)’와 서버가 그 요청에 대한 결과로 보내는 ‘응답 메시지(Response)’다. 요청 메시지에는 어떤 행동(GET, POST 등)을 하고 싶은지, 어떤 정보(URL)를 원하는지 등이 담겨 있다. 응답 메시지에는 요청 처리의 결과를 알려주는 세 자리 숫자(상태 코드)와, 요청한 실제 데이터(HTML, 이미지 등)가 담겨 있다. 예를 들어, 200은 성공, 404는 ‘요청한 페이지가 없다’는 의미다.