HTTP - (3) HTTP 기본

sorikikikim·2022년 7월 4일
0

HTTP

목록 보기
3/4

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 정리하는 포스트입니다.

[HTTP]

1. HTTP (HyperText Transfer Protocol)

문서 간의 링크(HyperText)를 통해 연결할 수 있는 HTML을 전송하는 프로토콜로 시작되었다. 하지만 지금은 거의 모든 형태의 데이터(text, HTML, image, video, JSON 등)를 HTTP 메시지로 전송한다. 심지어 서버 간에 데이터를 주고 받을 때에도 대부분 HTTP를 사용한다.

역사

  • HTTP/0.9 - 1991년 : GET 메서드만 지원, HTTP 헤더 x
  • HTTP/1.0 - 1996년 : 메서드, 헤더 추가
  • HTTP/1.1 - 1997년 : 가장 많이 사용, 가장 중요한 버전
    RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014)
  • HTTP/2 - 2015년 : 성능 개선
  • HTTP/3 - 진행 중 : TCP 대신 UDP 사용, 성능 개선

기반 프로토콜

  • TCP : HTTP/1.1, HTTP/2
  • UDP : HTTP/3
    (TCP는 3 way handshaking, 많은 데이터, 속도가 빠른 메커니즘이 x
    -> UDP 프로토콜 위에 어플리케이션 레벨에서 성능을 최적화하도록 새로 설계)
  • 현재 HTTP/1.1 주로 사용 (HTTP/2, HTTP/3도 점점 증가)
    네이버는 HTTP/1.1과 HTTP/2 사용중

    크롬은 HTTP/2와 HTTP/3 사용 중

2. HTTP 특징

  • 클라이언트 서버 구조
  • 무상태 프로토콜(스테이스리스), 비연결성
  • HTTP 메시지
  • 단순함, 확장 가능

1) 클라이언트 - 서버 구조 (Request - Response 구조)

HTTP는 클라이언트와 서버를 개념적으로 분리해놓은 구조이다. 클라이언트가 메시지를 통해 서버에 요청을 보낸 후 서버에서 응답이 올 때까지 대기한다. 서버가 요청에 대한 결과를 만들어서 응답하면 클라이언트는 응답 메시지를 열어서 동작한다.

과거에는 클라이언트와 서버가 한 곳에 몰려있는 구조였다. 하지만 개념적으로 분리하여 비즈니스 로직이나 데이터는 서버로, UI와 사용성은 클라이언트로 집중시켜 양쪽이 독립적으로 진화가 가능해졌다.

2) 무상태 프로토콜 (Stateless)

HTTP는 무상태 프로토콜을 지향한다. 서버가 클라이언트의 상태를 보존하지 않는다는 것이다. 아직도 이해가 되지 않아 상태 유지와 무상태를 예제로 이해해보자.

Stateful, Stateless 차이

상태 유지 - Stateful

  • 고객 : 이 노트북 얼마인가요?
  • 점원 : 100만원 입니다. (노트북 상태 유지)

  • 고객 : 2개 구매하겠습니다.
  • 점원 : 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매하시겠어요? (노트북, 2개 상태 유지)

  • 고객 : 신용 카드로 구매하겠습니다.
  • 점원 : 200만원 결제 완료 되었습니다. (노트북, 2개, 신용카드 상태 유지)

상태 유지 - Stateful, 점원이 중간에 바뀌면?

  • 고객 : 이 노트북 얼마인가요?
  • 점원 A : 100만원 입니다.

  • 고객 : 2개 구매하겠습니다.
  • 점원 B : ? 무슨 제품을 2개 구매하시겠어요?

  • 고객 : 신용 카드로 구매하겠습니다.
  • 점원 C : ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?

무상태 - Stateless

  • 고객 : 이 노트북 얼마인가요?
  • 점원 : 100만원 입니다.

  • 고객 : 노트북 2개 구매하겠습니다.
  • 점원 : 노트북 2개는 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매하시겠어요?

  • 고객 : 노트북 2개를 신용카드로 구매하겠습니다.
  • 점원 : 200만원 결제 완료되었습니다.

무상태 - Stateless, 점원이 중간에 바뀌면?

  • 고객 : 이 노트북 얼마인가요?
  • 점원 A : 100만원 입니다.

  • 고객 : 노트북 2개 구매하겠습니다.
  • 점원 B : 노트북 2개는 200만원 입니다. 신용카드, 현금 중에 어떤 걸로 구매하시겠어요?

  • 고객 : 노트북 2개를 신용카드로 구매하겠습니다.
  • 점원 C : 200만원 결제 완료되었습니다.

상태 유지에서는 점원이 바뀌면 문맥이 사라져서(다른 점원으로 바뀔 때마다 상태 정보를 다른 점원에게 미리 알려줘야 함) 의사소통에 문제가 생기지만, 무상태에서는 고객이 필요한 정보를 매번 점원에게 넘기기 때문에 의사소통에 문제가 생기지 않는다. 따라서 갑자기 고객이 증가하는 경우, 점원을 대거 투입할 수 있다.

즉, 무상태는 서버에서 상태 유지를 하지 않고 요청 메시지에 상태를 저장하여 아무 서버나 호출이 가능하다.

이는 클라이언트 - 서버 아키텍처에서 무상태 프로토콜의 경우, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있음을 알 수 있다. 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 엄청난 확장성을 가져서 서버의 무한 증설이 가능하다.

Stateless 실무 한계
  • 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.(무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면, 상태 유지 : 로그인)
  • 로그인 한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 함
  • 일반적으로는 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
  • 최대한 무상태로 설계하되 어쩔 수 없는 부분에 한해서만 상태 유지는 사용하도록 잘 분리해서 사용하는 게 중요함
  • 무상태는 데이터를 많이 전송함
Stateless 관련 가장 어려운 업무
  • 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
  • 예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록 -> 수만명 동시 요청

3) 비 연결성 (Connectionless)

TCP/IP 연결의 경우는 기본적으로 연결을 유지한다. 즉 서버 자원을 계속해서 소모하고 있다는 것이다. 반면 비 연결성 모델의 경우 클라이언트와 서버는 연결을 유지하지 않아 최소한의 자원을 사용할 수 있다.

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

비 연결성의 한계와 극복
  • TCP/IP 연결을 새로 맺어야 함 (3 way handshake 시간 추가)
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐 아니라 JS, CSS, 추가 이미지 등 수많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화
지속 연결

4) HTTP 메시지

HTTP 메시지 구조

요청 메시지의 경우 요청 방식, 쿼리, 버전이 들어있는 시작 라인과 호스트 정보가 들어있는 헤더, 필수로 있어야하는 공백 라인이 있다.

반면 응답 메시지의 경우 요청 메시지와 시작 라인이 다르다. 시작라인에는 HTTP 버전, 요청 받은 값이 있으며 헤더에는 content의 정보가 들어있다. 응답 메시지 또한 공백 라인이 필수로 있어야하고 메시지 바디라인에는 응답할 메시지(HTML 등)가 온다.

공식 스펙
HTTP-message = start-line
			   * (header-filed CRLF)
               CRLF //공백
               [ message-body ]
(1) 시작 라인

  • start-line = request-line과 status-line으로 구성되어 있다.

  • request-line(요청 메시지) = method SP(공백) request-tartget(path, 요청할 대상) SP HTTP-version CRLF(엔터)
    => GET /search?q=hello&hl=ko HTTP/1.1

    HTTP method
    • 종류 : GET, POST, PUT, DELETE ...
    • 서버가 수행해야 할 동작 지정
      • GET : 리소스 조회
      • POST : 요청 내역 처리
    요청 대상
    • absolute-path[?query] : 절대 경로[?쿼리]
    • 절대 경로 = "/"로 시작하는 경로
    • http://...?x=y 와 같이 다른 유형의 경로 지정 방법도 있음
    HTTP 버전
    • HTTP Version

  • status-line(응답 메시지) = HTTP-version SP status-code(상태 코드) SP reason-phrase(이유 문구) CRLF

    HTTP 상태 코드

    클라이언트가 보낸 요청에 대한 상태를 서버가 보내줄 때 사용, 요청 성공과 실패를 나타냄

    • 200 : 성공
    • 400 : 클라이언트 요청 오류
    • 500 : 서버 내부 오류
    이유 문구

    사람이 이해할 수 있는 짧은 상태 코드 설명 글

    (2) HTTP 헤더

  • header-field = field-name(대소문자 구분 안함) : OWS(띄어쓰기 허용) field-value OWS
    => Host : www.google.com

    용도
    • HTTP 전송에 필요한 모든 부가정보
    • 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 어플리케이션 정보, 캐시 관리 정보 ...
    • 표준 헤더가 너무 많음
    • 필요시 임의의 헤더 추가 가능
      • helloworld: hihi
    (3) HTTP 메시지 바디
    • 실제 전송할 데이터
    • HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
    HTTP 메시지 장점
    • HTTP는 단순하다. 스펙도 읽어볼 만 하다.
    • HTTP 메시지도 매우 단순함
    • 크게 성공하는 표준 기술은 단순하지만 확장 기능한 기술
profile
sorikikikim
이전 포스트

HTTP - (2) URI, 웹 브라우저 요청 흐름

다음 포스트

HTTP - (4) HTTP API

0개의 댓글