HTTP

하마·2025년 3월 19일

Spring

목록 보기

5/22

HTTP/1.1에 대한 정리 글

HTTP 동작 순서

클라이언트는 요청 Request 을 보내고, 응답 Response 을 기다림
서버는 요청 Request 에 대한 처리 후 결과를 응답 Response 함

HTTP의 특징

1. 클라이언트-서버 구조

클라이언트는 UI에 중점을 두도록 만듦
서버에서 데이터와 비즈니스 로직을 담당하도록 만듦

2. Stateless (무상태)

서버는 클라이언트의 상태를 보존하지 않음
Stateless

3. Connectionless (비연결)

HTTP는 연결을 유지하지 않는 모델임
Connectionless

HTTP Message 구조

HTTP 통신에서 주고받는 데이터를 의미함
요청, 응답 메세지 두 종류가 있고, 구조가 각각 다름

1. Request Message (요청 메세지)

구성 요소	설명
1. Start Line	요청의 시작 줄
1-1. HTTP Method	`GET`, `POST`, `PUT`, `PATCH`, `DELETE` 등 요청의 의도
1-2. Request Target	요청 대상 (`/event`, `/search?keyword=sparta` 등)
1-3. HTTP Version	`HTTP/1.1`
2. Header	요청에 대한 부가 정보 (예: `Host`, `Content-Type`, `User-Agent` 등)
3. Empty Line	헤더와 본문 사이의 공백 한 줄 (필수)
4. Message Body	요청 시 전송할 데이터 (JSON, HTML, 이미지 등)

1. Start Line

HTTP Method
- GET
- CRUD 요청의 의도
  - Create - POST
  - Read - GET
  - Update - PUT(전체), PATCH(일부)
  - Delete - DELETE
path
- /event
- HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로)
- Query String(Parameter) 에 해당하는 값도 포함
  ex) /search?keyword=sparta
HTTP Version
- HTTP/1.1

2. Header

Host: spartacodingclub.kr
- field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조
- field-name 은 대소문자를 구분하지 않음
임의의 Header를 추가할 수 있음
- 단, 서버가 값을 알고 있어야 함
요청의 추가 정보들을 가지고 있음
ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

3. Empty Line

공백 한 줄
필수 값

4. Message Body

실제 전송하는 데이터가 담겨 있는 부분
- HTML, 이미지, JSON 등 byte 로 표현되는 모든 데이터 전송 가능.
요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않음

2. Response Message (응답 메세지)

구성 요소	설명
1. Start Line	응답의 시작 줄
1-1. HTTP Version	`HTTP/1.1`
1-2. Status Code	응답 상태 코드 (`200 OK`, `404 Not Found` 등)
1-3. Status Text	상태 코드와 함께 전달될 메시지
2. Header	응답에 대한 부가 정보 (예: `Content-Type`, `Set-Cookie` 등)
3. Empty Line	헤더와 본문 사이의 공백 한 줄 (필수)
4. Message Body	응답 시 전송할 데이터 (HTML, JSON, 이미지 등)

1. Start Line

HTTP Version
Status Code
- 요청이 성공했는지, 실패했는지 나타내는 코드
Status Text
- 코드와 함께 전달될 메세지

2.Header

Response에서만 사용되는 Header 값들이 따로 존재

3. Empty Line

공백 한줄
필수 값

4. Message Body

실제 전송하는 데이터가 담겨 있는 부분
만약 전송할 데이터가 없다면, Body가 공백으로 존재

3. 요청 & 응답 메세지 정리

구성 요소	HTTP Request (요청)	HTTP Response (응답)
Start Line	`GET /event HTTP/1.1` (메서드, 경로, 버전)	`HTTP/1.1 200 OK` (버전, 상태 코드, 메시지)
Header	`Host: spartacodingclub.kr` `User-Agent: Mozilla/5.0`	`Content-Type: text/html` `Content-Length: 1234`
Empty Line	헤더와 바디 사이 공백 한 줄 (필수)	헤더와 바디 사이 공백 한 줄 (필수)
Message Body	JSON, HTML, 이미지 등 요청 데이터 (`GET` 요청에서는 거의 사용 안 함)	JSON, HTML, 이미지 등 응답 데이터 (없을 수도 있음)

Request 예시 (GET)

GET /search?keyword=sparta HTTP/1.1

Host: spartacodingclub.kr
User-Agent: Mozilla/5.0 Accept: text/html

(Empty Line)

Response 예시 (200 OK)

HTTP/1.1 200 OK

Content-Type: text/html
Content-Length: 1234

(Empty Line)

<html>
  <body>Hello, World!</body>
</html>

4. HTTP Header

클라이언트와 서버가 요청/응답으로 부가적인 정보를 전송할 수 있도록 만듦

1. Header 구조

field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)
field-name은 대소문자 구분을 하지 않는다.
HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.
임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
텍스트 (plain text)로 이루어져 있다.
각각의 헤더는 하나의 줄로 구분된다.

Request	Response
Content-Type: application/json	Content-Type: application/json Content-Length: 30 Location: /users/1

2. 표현 헤더 (Representation)

리소스에 대한 표현 정보(어떤 데이터 형식으로 보낼지)를 나타냄
요청, 응답에 모두 사용되는 Header

Content-Type : 형식
- 전송할 데이터의 미디어 타입, 문자 인코딩을 나타낸다.
- text/html; charset=utf-8
- application/json
Content-Encoding : 압축 방식
- 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제한다.
- gzip
- identity : 압축하지 않음
Content-Language : 언어
- 데이터의 언어를 표현한다.
  ex) ko로 되어있으면 한글을 보여주고, en으로 되어있으면 영어로된 페이지를 보여줄 수 있다.
Content-Length : 길이
- 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더이다.
- byte 단위로 나타낸다.

3. 컨텐츠 협상 (Content Negotiation)

클라이언트가 선호하는 표현을 요청한다.
요청시에만 사용되는 Header
우선 순위 존재
- Quality Values 줄여서 q 값 사용
- 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높다.
- Value가 1인 경우 생략 가능
  ex) Accept-Language: ko-KR,en-US;q=0.9,en;q=0.8
  → 서버에서 지원 가능하다면 우선순위를 기반으로 응답 데이터를 표현한다.
q가 생략되었다면 선언된 순서대로 우선순위를 가진다.
Accept: application/json, text/plain, */*
→ application/json ⇒ text/plain ⇒ */*
구체적으로 선언된 것이 우선순위가 높다.
Accpet: text/*, text/plain, text/plain;format=flowed, */*
→ text/plain;format=flowed ⇒ text/plain ⇒ text/* ⇒ */*

Accept : 선호하는 미디어 타입
Accept-Charset : 선호하는 문자 인코딩
Accept-Encoding : 선호하는 압축 인코딩
Accept-Language : 선호하는 언어

4. 일반 정보

단순한 정보들을 나타내는 Header 이다.

Referer : 현재 요청된 페이지의 이전 웹 페이지 주소
- 유입 경로 파악 가능
- 요청시 사용하는 Header
User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile 브라우저)
- 어떤 환경에서 주로 접속하는지 확인
- 어떤 종류의 환경에서 장애가 발생하는지 파악 가능
- 요청시 사용하는 Header
Server : 요청을 처리하는 ORIGIN 서버의 Software 정보
- 응답에서 사용
Date : HTTP 요청이 발생한 날짜와 시간
- 응답에서 사용

5. 특별 정보

Host : 요청한 도메인 정보
- 필수적으로 포함해야하는 Header 이다.
- 요청시 사용한다.
Location : 생성된 리소스 URI, 리다이렉트 주소
- 3xx와 함께 응답되면 리다이렉트 주소이다.
- 201(Created)와 함께 응답되면 생성된 리소스의 URI 이다.
Allow : 허용 가능한 HTTP Method
- 405 (Method Not Allowed)와 함께 응답된다.
  ex) Allow: GET, POST
Retry-After : 다음 요청까지 대기 해야하는 시간
- 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려준다.
  - 초단위, 날짜단위 모두 표현이 가능하다.

6. 인증

Authorization : 클라이언트 인증 정보
- 선택한 인증 방법에 따라 Value를 작성한다.
WWW-Authenticate : 리소스에 필요한 인증 방법
- 401 (Unauthorized) 응답과 함께 사용된다.

HTTP는 Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
Cookie를 사용하여 모든 요청마다 상태를 전달한다.
사용자 세션 관리, 광고 정보 트래킹에 많이 사용된다.

Set-Cookie : 서버에서 응답시 클라이언트로 Cookie 값 전달
- 만료기간(expire, max-age), 사용될 위치(domain, path)를 설정할 수 있다.
  - 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 한다.
  - 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다.
Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.
- Secure : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다.
  - 기본적으로 http, https 구분하지 않고 쿠키를 전송한다.
HttpOnly : http 전송에만 사용한다.
- 자바스크립트에서 쿠키를 접근하지 못하게 만든다.
SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

8. Cache

캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받는다.
새로 다운로드 받는만큼 속도가 느려지고, 비용이 발생한다.

Cache-Control

응답시 사용하는 헤더이다.

값	Cache-Control: max-age	Cache-Control: no-cache	Cache-Control: no-store
의미	- 캐시 유효 시간(초) - 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신한다.	- 캐시 가능한 데이터 - 서버에 검증하고 사용해야 한다.	- 보안에 민감한 데이터 - 캐시하지 않는다.

if-modified-since : 캐시로 저장된 데이터 최종 수정일
- 요청시 사용하는 헤더이다.
Last-Modified : 데이터가 마지막으로 수정된 시간
- if-modified-since 요청이 오면 응답한다.
- 304 (Not Modified) 상태코드와 함께 응답되면 수정되지 않았다는 의미
  - HTTP Message Body가 존재하지 않는다. 캐시 사용
- 응답시 사용하는 헤더이다.
ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정한다.
- if-modified-since + Last-Modified 방식은 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분하지 못한다.
- 요청시 사용하는 헤더이다.

5. HTTP 상태 코드 종류

1xx (정보)
- 잘 사용하지 않음
2xx (성공)
- 정상 처리가 완료된 상태
3xx (리다이렉션)
4xx (클라이언트 에러)
5xx (서버 에러)

전부 기억할 필요는 없고 몇 번대 코드인지, 앞자리 숫자가 뭘 의미하는지만 알면 됨

응답 코드를 상황에 맞게 잘 작성해야 함
- 매우 기본이고 매우 중요

HTTP Method

HTTP 통신에서 처리할 행위를 말함
클라이언트-서버 간 이루어지는 요청, 응답 데이터를 전송하는 방식

POST

리소스 생성
주로 HTML FORM(회원가입, 게시글 작성 등)에 사용됨
요청 데이터를 처리하는 방식은 정해져있지 않음
- 요청 데이터 처리(로그인 등)에 사용함
- 조회 시 JSON 요청 데이터가 필요한 경우 사용될 수 있음
Message Body를 통해 요청 데이터를 전달함

GET

리소스 조회

Query String 미포함
Query String 포함

서버에 추가적인 데이터 전송 필요 시
Message Body 가 아닌 Query String 를 사용함

PUT

리소스 덮어쓰기
POST 와 다르게 클라이언트 측에서 리소스를 식별해 URI를 지정함

기존 리소스가 존재할 경우

리소스 전체를 수정함 (덮어씌움)

기존 데이터가 아래와 같다고 하자.
{
  "id": 2,
  "name": "codingclub",
  "age": 100
}
에서 PUT /users/2
{
  "name": "codingclub2",
  "age": 200
}
을 진행하면,
{
  "id": 2,
  "name": "codingclub2",
  "age": 200
}
가 된다!

기존 리소스가 존재하고, 일부만 변경할 경우

같은 경로에 리소스가 존재할 때 일부만 변경하면
일부만 변경되는 게 아닌, 완전히 새로운 값으로 덮어씌워짐

기존 데이터가 아래와 같다고 하자.
{
  "id": 2,
  "name": "codingclub",
  "age": 100
}
에서 PUT /users/2
{
  "age": 200
}
을 진행하면,
{
  "id": 2,
  "age": 200
}
가 된다 !

기존 리소스가 없는 경우

그냥 새롭게 리소스가 생성된다.

PATCH

리소스를 부분만 수정한다.

DELETE

리소스를 삭제한다.

HTTP Method의 속성

1. 안전성 (Safe)

GET 메소드(조회)는 안전하다.
- 저장된 데이터를 변환하지 않음
POST, DELETE, PUT, PATCH는 안전하지 않다.
- 데이터를 생성/수정/삭제함

2. 멱등성 (Idempotent)

몇 번 호출해도 항상 결과는 같음
- GET : 같은 결과가 계속 조회된다.
- PUT : 수정해서 대체된 후의 결과는 계속 같다.
- DELETE : 같은 요청을 여러번해도 삭제된 결과는 계속 같다.
- POST : 멱등성을 보장하지 않는다.
  - 계좌 송금을 두번한다면?
  - 게시판 글쓰기
  - 회원가입
요청이 실패한 경우 재시도 하기위해 필요
1. 항상 결과가 같다면 마음껏 재시도 해도된다.
2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
3. 복구 매커니즘에 사용한다.
  ex) 요청 실패시 서버에서 자동으로 재시도
리소스 GET 재요청 중간에 변경된다면?
- 재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않음
  
  ex) 도서관 책 재고 조회(실시간으로 대여 혹은 판매됨)

3. 캐시가능성 (Cacheable)

재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
- GET, HEAD, POST 메소드는 캐시가 가능하다.
- 일반적으로 GET, HEAD 정도만 캐시로 사용한다.
ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱한다.

참고자료

Spring 입문 - 1주차

HTTP 1강
HTTP 2강
HTTP 3강

하마

이전 포스트

Scale Up/Out, Statefull(less), Connection(less)

다음 포스트

HTTP

Spring

HTTP 동작 순서

HTTP의 특징

1. 클라이언트-서버 구조

2. Stateless (무상태)

3. Connectionless (비연결)

HTTP Message 구조

1. Request Message (요청 메세지)

1. Start Line

2. Header

3. Empty Line

4. Message Body

2. Response Message (응답 메세지)

1. Start Line

2.Header

3. Empty Line

4. Message Body

3. 요청 & 응답 메세지 정리

Request 예시 (GET)

Response 예시 (200 OK)

4. HTTP Header

1. Header 구조

2. 표현 헤더 (Representation)

3. 컨텐츠 협상 (Content Negotiation)

4. 일반 정보

5. 특별 정보

6. 인증

7. Cookie

8. Cache

5. HTTP 상태 코드 종류

HTTP Method

POST

GET

PUT

PATCH

DELETE

HTTP Method의 속성

1. 안전성 (Safe)

2. 멱등성 (Idempotent)

3. 캐시가능성 (Cacheable)

참고자료

Scale Up/Out, Statefull(less), Connection(less)

RESTful API

0개의 댓글