홈 HTTP 기본
포스트
취소

HTTP 기본

게시 2024/03/19
By Sangwon Lee
23 분읽는 시간

HTTP(HyperText Transfer Protocol)란?

  • 웹에서 정보를 주고받기 위한 규약
  • 웹 브라우저, 웹 서버, API 등 다양한 프로그램들이 HTTP를 사용하여 서로 통신한다.
  • 클라이언트-서버 모델을 기반으로 동작한다.

HTTP의 주요 기능

  • 웹 페이지 요청 및 전송
    • 웹 브라우저가 웹 서버에 웹 페이지를 요청하고 서버가 웹 페이지를 전송하는 데 사용된다.
  • 다양한 데이터 전송
    • 이미지, 동영상, JavaScript, CSS 등 웹 페이지를 구성하는 다양한 데이터를 전송하는 데 사용된다.
  • API 통신
    • 웹 애플리케이션과 서버 간에 데이터를 주고받는 데 사용된다.

HTTP의 특징

  • 클라이언트-서버 구조
    • HTTP는 클라이언트-서버 구조로 동작한다.
    • 클라이언트는 서버에 요청을 보내고, 서버는 응답을 보낸다.
  • 무상태
    • HTTP는 무상태 프로토콜이다.
    • 서버는 클라이언트의 이전 요청을 기억하지 않는다.
  • 비연결성
    • HTTP는 비연결성 프로토콜이다.
    • 요청과 응답이 끝나면 연결이 종료된다.
  • 단순/확장 가능
    • HTTP는 단순하고 확장 가능한 프로토콜이다.
    • 새로운 기능을 쉽게 추가할 수 있다.
  • 캐싱
    • HTTP는 캐싱을 지원한다.
    • 캐싱 : 웹 페이지나 데이터를 로컬에 저장하여 다시 요청할 때 더 빠르게 불러올 수 있도록 하는 기능
  • 보안
    • HTTP는 HTTPS를 통해 보안을 강화할 수 있다.
    • HTTPS는 SSL/TLS 암호화를 사용하여 데이터를 보호한다.
  • 다양한 버전
    • HTTP는 여러 버전이 있다.
    • 현재 가장 많이 사용되는 버전은 HTTP/1.1이다.

HTTP의 장점

  • 간편성
    • 사용하기 쉽고 이해하기 쉬운 프로토콜이다.
  • 확장성
    • 다양한 유형의 데이터를 전송하는 데 사용할 수 있다.
  • 유연성
    • 다양한 프로그램들이 사용할 수 있다.
  • 효율성
    • 캐싱을 통해 성능을 향상시킬 수 있다.
  • 보안
    • HTTPS를 통해 데이터를 보호할 수 있다.

HTTP의 단점

  • 무상태
    • 서버는 클라이언트의 이전 요청을 기억하지 않기 때문에 세션 관리 등을 위해 추가적인 작업이 필요하다.
  • 비연결성
    • 요청과 응답마다 연결을 새로 열고 닫기 때문에 오버헤드가 발생할 수 있다.

HTTP의 발전

  • HTTP/0.9
    • 1991년
    • HTTP 메소드 중에서 GET만 지원됬음
    • HTTP 헤더가 없던 시절
  • HTTP/1.0
    • 1996년
    • 지원하는 HTTP 메서드 추가됨
    • HTTP 헤더 추가됨
  • HTTP/1.1
    • 1997년
    • TCP 위에서 동작한다.
    • 현재 가장 많이 사용되는 버전
    • 대부분의 기능이 다 들어 있다.
    • RFC2068 (1997) → RFC2616 (1999) → RFC7230~7235 (2014)
  • HTTP/2
    • 2015년
    • TCP 위에서 동작한다.
    • 성능 개선
  • HTTP/3
    • 진행 중
    • TCP 대신에 UDP를 사용한다.
    • 성능 개선

클라이언트-서버 구조

  • HTTP는 클라이언트-서버 구조로 동작한다.
  • 클라이언트는 서버에 요청을 보낸다.
  • 서버는 응답을 보낸다.

클라이언트

  • 웹 브라우저, 웹 애플리케이션 등 정보를 요청하는 프로그램
  • 서버 측에 HTTP 요청 메시지를 전달한다.
  • HTTP 요청 메시지 구조
    • 요청 메서드
      • GET, POST, PUT, DELETE 등 요청의 종류를 나타낸다.
    • URI
      • 요청하는 정보의 주소를 나타낸다.
    • 헤더
      • 요청과 관련된 추가 정보를 포함한다.

서버

  • 웹 페이지, API 등 정보를 제공하는 프로그램
  • 클라이언트 측에 HTTP 응답 메시지를 전달한다.
  • HTTP 응답 메시지 구조
    • 상태 코드
      • 요청의 성공 여부를 나타내는 숫자 코드를 나타낸다.
    • 헤더
      • 응답과 관련된 추가 정보를 포함한다.
    • 본문
      • 요청한 정보가 포함된다.

Stateful & Stateless

  • HTTP는 Stateless 프로토콜이다.
  • 다만 경우에 따라서는 Stateful하게 사용할 수도 있다

Stateful HTTP

  • 서버가 클라이언트의 이전 요청 정보를 기억한다.
  • 장점
    • 편리성
      • 세션 관리가 간편하고 사용자 경험이 향상된다.
  • 단점
    • 복잡성
      • 서버 구현이 복잡하고 확장성이 떨어진다.
    • 성능 저하
      • 리소스 소비가 증가하고 성능이 저하될 수 있다.
    • 안정성 문제
      • 세션 관리 문제가 발생할 가능성이 높아진다.
  • 사용 예시
    • 로그인
      • 사용자 로그인 상태를 유지해야 하는 경우
    • 쇼핑 장바구니
      • 사용자가 선택한 상품을 저장해야 하는 경우
    • 채팅
      • 사용자 간 메시지를 실시간으로 전달해야 하는 경우

Stateless HTTP

  • 서버가 클라이언트의 이전 요청 정보를 기억하지 않는다.
  • 장점
    • 간편성
      • 서버 구현이 간단하고 확장성이 좋다.
    • 성능
      • 리소스 소비가 적고 성능이 향상된다.
    • 안정성
      • 세션 관리 문제가 발생하지 않는다.
  • 단점
    • 세션 관리 어려움
      • 로그인, 쇼핑 장바구니 등 세션 관리가 필요한 경우 추가적인 작업이 필요하다.
  • 사용 예시
    • 정적 웹 페이지
      • 로그인이나 세션 관리가 필요하지 않은 웹 페이지
    • REST API
      • 자원을 조회, 생성, 수정, 삭제하는 API
    • 웹 캐싱
      • 웹 페이지를 캐싱하여 성능을 향상시키는 경우

차이점 이해하기

  • 만약 간단하게 만들어진 물건을 사는 API가 있다고 가정한다.
  • 해당 API를 이용하기 위해서는 세 항목의 값을 차례대로 전달해야 한다.
    1. 구매할 물건의 종류
    2. 구매할 물건의 개수
    3. 결제 수단
  • 이 세 항목의 값이 있어야지 결제가 진행되고 성공이라고 결과를 반환한다고 가정한다.
  • 각 경우에 대한 진행 과정을 고객과 점원의 대화로 예시를 든다.
  • 말투가 어색한 건 예시를 위한 것이니 넘어가도록 하자.
Stateful HTTP에서 하나의 서버에서만 통신하는 경우
  1. 고객 : 이 아메리카노의 가격은 얼마인가요?

  2. 점원 : 이 아메리카노의 가격은 2,000원입니다.

  3. 고객 : 5잔 구매하겠습니다.
  4. 점원 : 아메리카노를 5잔 구매하신다면 가격은 10,000원입니다.
    • 1번에서 고객이 아메리카노라는 정보를 전달한 것을 기억하고 있다.
  5. 고객 : 카드로 결제하겠습니다.
  6. 점원 : 아메리카노 5잔 총 10,000원 카드 결제 도와드리겠습니다.
    …
    결제 완료되었습니다. (성공)
    • 1번에서 고객이 아메리카노라는 정보를 전달한 것과 3번에서 고객이 5잔라는 정보를 전달한 것을 기억하고 있다.
  • Stateful HTTP에서는 서버가 클라이언트의 이전 요청 정보를 기억하고 있다.
  • 그래서 요청을 나눠서 보내도 문제없이 동작한다.
  • 대신 중간에 서버가 바뀌는 경우에는 문제가 발생한다.
Stateful HTTP에서 통신하던 서버가 교체되는 경우
  1. 고객 : 이 아메리카노의 가격은 얼마인가요?

  2. 점원 A : 이 아메리카노의 가격은 2,000원입니다.

  3. 고객 : 5잔 구매하겠습니다.
  4. 점원 B : 무엇?을 5잔 구매하시겠어요?
    • 1번에서 고객이 아메리카노라는 정보를 전달한 것을 모른다.
  5. 고객 : 카드로 결제하겠습니다.
  6. 점원 C : 무엇?을 얼만큼 카드로 결제하시겠어요?
    • 1번에서 고객이 아메리카노라는 정보를 전달한 것과 3번에서 고객이 5잔라는 정보를 전달한 것을 모른다.
  • Stateful HTTP에서는 직전에 통신한 서버만 클라이언트의 이전 요청 정보를 기억하고 있다.
  • 그래서 중간에 서버가 변경되면 변경된 서버는 클라이언트의 이전 요청 정보를 기억하지 못하기 때문에
    해당 API에 대한 정상적인 동작을 실행할 수 없다.
  • 예시는 이렇지만 실제로는 세션 저장소나 Sticky Session이나 여러 방법이 있다.
Stateless HTTP에서 하나의 서버에서만 통신하는 경우
  1. 고객 : 이 아메리카노의 가격은 얼마인가요?

  2. 점원 : 이 아메리카노의 가격은 2,000원입니다.

  3. 고객 : 아메리카노를 5잔 구매하겠습니다.
    • 1번에서 본인이 아메리카노라는 정보를 전달한 것을 기억하고 있다.

  4. 점원 : 아메리카노를 5잔 구매하신다면 가격은 10,000원입니다.

  5. 고객 : 아메리카노 5잔을 카드로 결제하겠습니다.
    • 1번에서 본인이 아메리카노라는 정보를 전달한 것과 3번에서 본인이 5잔라는 정보를 전달한 것을 기억하고 있다.
  6. 점원 : 아메리카노 5잔 총 10,000원 카드 결제 도와드리겠습니다.
    …
    결제 완료되었습니다. (성공)
  • Stateless HTTP에서는 클라이언트가 자신의 이전 요청 정보를 기억하고 있다.
  • 그래서 요청을 나눠서 보내도 문제없이 동작한다.
Stateless HTTP에서 통신하던 서버가 교체되는 경우
  1. 고객 : 이 아메리카노의 가격은 얼마인가요?

  2. 점원 A : 이 아메리카노의 가격은 2,000원입니다.

  3. 고객 : 아메리카노를 5잔 구매하겠습니다.
    • 1번에서 본인이 아메리카노라는 정보를 전달한 것을 기억하고 있다.

  4. 점원 B : 아메리카노를 5잔 구매하신다면 가격은 10,000원입니다.

  5. 고객 : 아메리카노 5잔을 카드로 결제하겠습니다.
    • 1번에서 본인이 아메리카노라는 정보를 전달한 것과 3번에서 본인이 5잔라는 정보를 전달한 것을 기억하고 있다.
  6. 점원 C : 아메리카노 5잔 총 10,000원 카드 결제 도와드리겠습니다.
    …
    결제 완료되었습니다. (성공)
  • Stateless HTTP에서는 클라이언트가 자신의 이전 요청 정보를 기억하고 있다.
  • 그래서 서버가 중간에 교체되어도 문제 없이 동작한다.

Stateless의 한계점

  • Stateless가 좋긴 하지만 만능은 아니다.
  • 모든 것을 Stateless로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
    • 예시 : 특정 사용자가 웹 사이트에 로그인을 했다면 웹 서버는 해당 사용자가 로그인했다는 상태를 서버에 유지해야 한다.
  • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지한다.
  • 상태 유지는 최소한만 사용해야 한다.

비연결성 (connectionless)

  • 기본적으로 클라이언트가 서버에 무언가를 요청하려고 하면 아래의 3단계를 거친다.
    1. TCP/IP 연결
    2. 클라이언트가 HTTP 요청 메시지를 서버에 전달한다.
    3. 서버가 HTTP 응답 메시지를 클라이언트에 전달한다.
  • 그런데 만약 요청이 끊나고도 TCP/IP 연결을 끊지 않는다면 어떻게 될까?
    • 클라이언트의 수만큼 연결되는 TCP/IP 연결의 수가 늘어난다.
    • 그것은 곧 서버의 자원 낭비가 된다.
  • HTTP는 서버의 자원 낭비를 막고자 위의 3단계를 거친 후 TCP/IP 연결을 종료한다.
    • 연결을 유지하지 않는다.
    • 최소한의 자원만 유지한다.
  • TCP/IP 연결을 종료할 때 최소한의 자원을 남겨두는 이유는 아래와 같다.
    • 빠른 재연결
      • TCP/IP 연결을 새로 구축하는 것보다 기존 연결을 재사용하는 것이 훨씬 빠르다.
      • 서버 부하를 줄이고 사용자 경험을 향상시킨다.
    • 자원 절약
      • TCP/IP 연결을 새로 구축할 때마다 서버 자원이 소모된다.
      • 최소한의 자원을 유지하면 불필요한 자원 낭비를 방지할 수 있다.
    • 연결 유지
      • HTTP keep-alive 기능을 사용하면 클라이언트와 서버 간에 연결을 유지하여 지속적인 통신을 가능하다.
      • 짧은 간격으로 데이터를 주고받는 경우 유용하다.
  • 장점
    • 높은 확장성
      • 많은 클라이언트를 동시에 처리할 수 있다.
    • 낮은 메모리 사용량
      • 연결 정보를 유지하지 않아 메모리 사용량이 적다.
    • 단순성
      • 구현 및 관리가 간단하다.
  • 단점
    • 지연
      • 각 요청/응답 쌍에 대해 연결을 새로 구축해야 하기 때문에 지연이 발생할 수 있다.
    • 보안 취약점
      • 연결 재사용으로 인해 세션 탈취 공격 등의 보안 취약점이 발생할 수 있다.
  • 한계점
    • TCP/IP 연결을 새로 맺어야 한다.
      • 3 way handshake를 하는 시간이 추가된다.
    • 웹 브라우저로 사이트를 연결하면 수많은 자원이 함께 다운로드된다.
  • 극복
    • HTTP 지속 연결 (Persistent Connections)
      • HTTP/1.1에서 도입된 기능
      • 클라이언트와 서버 간에 연결을 유지하여 여러 요청/응답 쌍을 주고받을 수 있도록 하는 기술
    • HTTP/2와 HTTP/3에서 많은 최적화를 진행했다.

HTTP 메시지

HTTP 메시지 기본 구조

  • 시작 라인 (start-line)
    • 요청/응답 메시지에서 각각 요청 라인(request-line)과 상태 라인(status-line)이라고 부른다.
    • 내부의 각 요소를 공백 문자로 구분한다.
  • 헤더
    • HTTP 전송에 필요한 모든 부가 정보가 포함된다.
    • 필드명:OWS필드값OWS처럼 작성한다.
    • OWS는 띄어쓰기 허용을 의미한다.
    • 필드명은 대소문자 구분이 없다.
    • 매우 많은 종류의 표준 헤더가 존재한다.
    • 필요 시 임의의 헤더를 추가해서 사용해도 된다.
      • 예시 : randomid: 79763213-a650-4928-9707-e435b81518a9
  • 공백 라인
    • 헤더와 본문을 명확하게 구분시키는 구분자 역할을 한다.
    • 헤더가 끝났음을 의미한다.
    • 헤더와 본문이 혼동되는 것을 방지한다.
  • 본문
    • 실제 저장할 데이터가 들어있다.

HTTP 요청 메시지 구조

  • 요청 라인
    • 메소드
      • GET, POST, PUT, DELETE 등
    • URI
      • 요청하는 리소스의 식별자
    • 프로토콜 버전
      • HTTP/1.1, HTTP/2 등
  • 헤더
    • Host
      • 요청하는 서버의 도메인 이름
    • User-Agent
      • 클라이언트 정보
    • Accept
      • 클라이언트가 받아들일 수 있는 MIME 유형
    • Accept-Encoding
      • 클라이언트가 지원하는 압축 코덱
    • Accept-Language
      • 클라이언트가 선호하는 언어
    • Connection
      • 연결 유지 방식
    • Content-Type
      • 요청 본문의 MIME 유형
    • Content-Length
      • 요청 본문의 길이
  • 본문
    • 주로 POST, PUT, DELETE 메소드에서 사용한다.
    • 서버에서 지원하면 GET 요청할 때도 요청 데이터를 포함한다.

HTTP 요청 메시지 예시

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive

HTTP 응답 메시지 구조

  • 상태 라인
    • 프로토콜 버전
      • HTTP/1.1, HTTP/2 등
    • 응답 코드
      • 200, 404, 500 등
    • 응답 설명
      • OK, Not Found, Internal Server Error 등
  • 헤더
    • Date
      • 응답 메시지 생성 시간
    • Server
      • 웹 서버 정보
    • Content-Length
      • 응답 본문의 길이
    • Content-Type
      • 응답 본문의 MIME 유형
    • Connection
      • 연결 유지 방식
  • 본문
    • HTML 페이지, JSON 데이터, 이미지 등 응답 내용

HTTP 응답 메시지 예시

HTTP/1.1 200 OK
Date: Wed, 22 Mar 2023 08:54:23 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Length: 138
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head>
<title>Welcome to Example.com</title>
</head>
<body>
<h1>Welcome to Example.com</h1>
<p>This is the default index page for Example.com.</p>
</body>
</html>

출처

이론 - 웹
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.
최근 업데이트
바로가기