[HTTP] 3. HTTP 기본

임정규·2025년 9월 21일
StatefulStatelessUDPhttptcp

Infra

목록 보기
5/10
post-thumbnail

1. HTTP (HyperText Transfer Protocol)

HyperText란? 문서 간에 링크를 통해서 연결할 수 있는 것!

HTTP 메시지에 모든 것을 전송할 수 있다.

  1. HTML, TEXT
  2. IMAGE, 음성, 영상, 파일
  3. JSON, XML (API)

거의 모든 형태의 데이터 전송 가능하다.
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용한다.

참고
HTTP/1.1: 가장 많이 사용
HTTP/2, HTTP/3 (진행중) - 성능 개선 초첨
HTTP/3는 TCP 대신 UDP 사용

기반 프로토콜

HTTP가 패킷을 전달할 때, 기반으로하는 프로토콜은 버전별로 다음과 같다.

1. TCP: HTTP/1.1, HTTP/2
2. UDP: HTTP/3

HTTP 특징

  1. 클라이언트 서버 구조
  2. 무상태 프로토콜(Stateless), 비연결성
  3. HTTP 메시지
  4. 단순함, 확장성

아래 내용부터 이 특징들을 하나씩 정리해보겠다.

2. 클라이언트 서버 구조

  1. Request Response 구조
  2. 클라이언트는 서버에 요청을 보내고, 응답을 대기
  3. 서버가 요청에 대한 결과를 만들어서 응답

클라이언트와 서버가 개념이 분리되고, 비즈니즈 로직은 서버, UI/UX는 클라이언트에 집중(독립)할 수 있다는 것이 중요!

3. 무상태 프로토콜 (Stateless)

  1. 서버가 클라이언트의 상태를 보존X
  2. 장점: 서버 확장성 높음 (스케일 아웃)
  3. 단점: 클라이언트가 추가 데이터 전송

Stateful - 예시

Stateful - 점원이 일정한 경우

대화 주체발화 내용점원이 기억하는 상태
고객노트북 얼마?-
점원100만원(노트북)
고객2개 구매함(노트북, 2개)
점원200만원임, 신용카드, 현금 중에 뭘로 구매?(노트북, 2개)
고객신용카드로 ㄱ(노트북, 2개, 신용카드)
점원200만원 결제완료(노트북, 2개, 신용카드)

Stateful - 점원이 중간에 바뀌는 경우

대화 주체발화 내용점원이 기억하는 상태
고객노트북 얼마?-
점원A100만원(노트북)
고객2개 구매함
점원B??? 뭘 2개???(2개)
고객신용카드로 ㄱ
점원C??? 뭘 신용카드로???(신용카드)

Stateful
항상 같은 서버가 유지가 되어야 한다.
응답해주던 서버가 맛이 가면 클라이언트는 처음부터 다시 해야한다.

Stateless - 예시

대화 주체발화 내용점원이 기억하는 상태
고객노트북 얼마?-
점원100만원-
고객노트북 2개 구매함-
점원노트북 2개는 200만원임, 신용카드, 현금 중에 뭘로 구매?-
고객노트북 2개를 신용카드로 구매함-
점원200만원 결제완료-

이 경우에는 중간에 점원이 바뀌더라도, 요청마다 필요한 정보를 모두 전달하므로 응답에 문제가 없다.
즉, 고객이 무엇을 요청해왔는 지, 서버에서 그 상태를 저장할 필요없이 설계하는 것이 Stateless이다.

Stateless
상태를 보관하지 않으니깐, 아무 서버나 호출해도 된다.
그래서 스케일 아웃(수평 확장)에 유리하다.

Stateful, Stateless 차이

Stateful: 중간에 다른 점원으로 바뀌면 안된다.
(중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다.)

Stateless: 중간에 다른 점원으로 바뀌어도 된다.

  • 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

Stateless 실무 한계

모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

  • Stateless로 가능한 것 -> 로그인이 필요 없는 단순한 서비스 소개 화면
  • Stateful이 필요한 것 -> 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지한다.
일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지한다.

따라서, Stateful은 최소한만 사용하는 방향으로 설계하는 것이 중요하다.
그리고 Stateless의 단점으로 보내야하는 데이터가 너무 많다는 단점이 있다.

Stateless를 구현하기 정말 어려운 상황
정말 같은 시간에 딱! 맞추어서 발생하는 대용량 트래픽
ex) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
ex) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청
항상 Stateless하게 설계하는 것이 중요하다! 머리를 갈아넣더라도...

4. 비연결성 (connectionless)

연결을 유지하는 모델 특징

  • TCP 연결이후 작업이 끝나고 연결 유지한다.
  • 서버자원 소모한다.

연결을 유지하지 않는 모델 특징

  • TCP 연결이후 작업이 끝나면 연결 해제한다.
  • 최소한의 자원 사용한다.

HTTP는 기본이 연결을 유지하지 않는 모델이다.

  • 일반적으로 초 단위의 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
    ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
  • 서버 자원을 매우 효율적으로 사용할 수 있다.

그런데, 연결을 유지하지 않는 모델이 최소한의 자원만 사용하는 것 같아 장점만 있는 것 같지만 아니다.

  • HTTP 요청을 보낼 때마다 TCP/IP 연결을 새로 맺어야한다.
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지등 수많은 자원들이 함께 다 다운로드된다.

이러한 문제들은 응답시간을 늦추는 한계가 된다. 이를 해결하기 위해 HTTP 지속 연결 (Persistent Connections)로 문제를 해결하고 있고, HTTP/2, HTTP/3에서 더 많은 최적화가 이루어지고 있다.

HTTP 초기HTTP 지속 연결 적용

5. HTTP 메시지


empty line(CRLF) 무조건 있어야한다.
공식 스펙에 명시되어 있다.

start-line

요청 메시지 (request-line)응답 메시지 (status-line)
예시
GET /search?q=hello&hl=ko HTTP/1.1		예시
HTTP/1.1 200 OK
형식
start-line = request-line(요청)
request-line = method SP request-target SP HTTP-version CRLF		형식
start-line = status-line(응답)
status-line = HTTP-version SP status-code SP reason-phrase CRLF
method
- GET, POST, PUT, DELETE…
- 서버가 수행해야 할 동작 지정
 • GET: 리소스 조회
 • POST: 요청 내역 처리		status-code
- 요청 성공, 실패를 나타냄
 • 200: 성공
 • 400: 클라이언트 요청 오류
 • 500: 서버 내부 오류
request-target
- absolute-path[?query]
- 절대경로 "/"로 시작
- 참고: *, http://...?x=y 등 가능		reason-phrase
- 사람이 이해할 수 있는 짧은 상태 코드 설명 글
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구분 없음

용도

  • HTTP 전송에 필요한 모든 부가정보가 다 있다. (body를 제외한 필요한 모든 메타데이터가 여기 있다.)
  • 표준 헤더가 많다
  • 필요시 임의의 헤더도 추가가 가능하다.

message body

용도

  • 실제 전송할 데이터
  • HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능

정리하며...

오늘 정리한 게 난잡해보여서 맘에 들지가 않는다...
일단 가져갈 것은
1. Stateless의 구조로 수평적인 확장이 자유로운 것
2. 비연결성의 구조지만 지속 연결이라는 최적화를 통해 한계를 해결
3. HTTP 구조가 단순해서 여기저기 확장이 가능하다
정도 확실하게 가져가자.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

https://inf.run/YZxop

profile
임정규
아키텍처 설계부터 고민하는 개발자
이전 포스트

[HTTP] 2. URI, 웹 브라우저 요청 흐름

다음 포스트

[HTTP] 4. HTTP 메서드

0개의 댓글