3. HTTP 기본

suyeon·2022년 9월 15일

HTTP

목록 보기
3/4
post-thumbnail

📌 모든 것이 HTTP

HTTP (HyperText Transfer Protocol)

HTTP 메시지에 모든 것을 전송한다.

  • HTML, TEXT
  • IMAGE, 음성, 영상, 파일
  • JSON, XML (API)
  • 거의 모든 형태의 데이터 전송 가능
  • 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
  • 지금은 HTTP 시대

HTTP 역사

  1. HTTP/0.9 (1991년) : GET 메서드만 지원, HTTP 헤더X
  2. HTTP/1.0 (1996년) : 메서드, 헤더 추가
  3. HTTP/1.1 (1997년) : 가장 많이 사용, 우리에게 가장 중요한 버전 ⭐
    • RFC2068 (1997) → RFC2616 (1999) → RFC7230~7235 (2014)
  4. HTTP/2 (2015년) : 성능 개선
  5. HTTP/3 (진행중) : TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

HTTP/1.1, HTTP/2 같은 경우에는 TCP 프로토콜 위에서 동작을 한다.

HTTP/3은 UDP 프로토콜 기반으로 개발이 되어 있다. TCP는 3 way handshake도 해야 되고 기본적으로 데이터도 많고 매커니즘 자체가 속도가 느린 편이다. 그래서 UDP 프로토콜 위에 애플리케이션 단계에서 성능을 최적화하도록 새로 설계한다.

현재는 HTTP/1.1 주로 사용하지만, HTTP/2, HTTP/3 도 점점 증가하고 있다.

HTTP 특징

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

📌 클라이언트 서버 구조

  • Request Response 구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기
  • 서버가 요청에 대한 결과를 만들어서 응답
💬 클라이언트와 서버를 개념적으로 분리한다. 분리함으로써 각각 독립적으로 진화할 수 있다.
클라이언트는 UI, 사용성
서버는 비즈니스 로직, 데이터

📌 Stateful, Stateless

Stateful, Stateless 차이

ex) 유튜브 사이트
사용자가 유튜브에 로그인 후 영상을 시청하다가 1분에 영상을 종료 → 다시 재생 시

  • 상태 유지 (Stateful)

    • 사용자가 종료한 시점이 서버에 저장되어 있고, 다시 영상을 재생시켰을 경우 서버에서 영상 정보 및 종료 시점 등을 받아와 종료한 시점부터 재생

    • 서버 증설은 불가능 : A 서버에 사용자 종료한 시점이 지정되어 있을 경우, B 서버에는 종료한 시점을 보내줄 수가 없다.

  • 무상태 (Stateless)

    • 다시 영상을 재생시켰을 때, 영상 정보 및 영상 종료 시점 등의 정보를 같이 서버에 보내서 종료한 시점부터 재생
    • 서버 증설 가능 : 요청 시 정보를 보내기 때문

상태 유지 (Stateful)

서버에 상태를 저장하므로 항상 같은 서버가 유지되어야 한다.
중간에 서버가 장애나면, 해당 서버를 바라보고 있던 유저의 상태가 소실된다. 처음부터 다시 해야 된다.

무상태 (Stateless)

서버가 클라이언트의 상태를 보관하지 않기 때문에 아무 서버나 호출해도 된다.
중간에 서버가 장애나면, 클라이언트가 필요한 정보들을 이미 담고 있어서 다른 서버에 요청하면 된다.
서버 확정성(스케일 아웃)이 높다.

실무 한계

Stateful

  • 로그인 해야 되는 경우는 로그인한 사용자가 로그인했다는 상태를 서버에 유지해야 한다.
  • 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다. 서버에 세션이 날아가거나 세션 서버가 죽어버리면 전체적으로 로그인이 풀려버리게 된다.
  • 상태 유지는 최소한만 사용한다.

Stateless

  • 로그인할 필요 없는 단순한 소개 화면일때는 상태를 유지할 필요가 없어서 설계가 쉽다.
  • 클라이언트가 전송할 때 필요한 정보를 담아야 해서 데이터량이 많다.

📌 비 연결성 (connectionless)

연결을 유지하는 모델

여러 클라이언트에서 서버로 응답을 요청하면 서버는 요청이 들어온 클라이언트 마다 TCP/IP 연결을 유지해서 상태를 저장한다.
클라이언트를 사용하지 않아도 서버를 계속 유지하는 서버 자원이 소모되는 단점이 있다.

연결을 유지하지 않는 모델

클라이언트가 요청할 때마다 서버는 응답만 보내고 TCP/IP 연결을 종료하기 때문에 서버가 최소한의 자원을 사용한다.

비 연결성 (connectionless)

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

비 연결성 한계

  • TCP/IP 연결을 새로 맺어야 함 → 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드 → 다운로드할 때 마다 연결하고 끊고 비효율적

비 연결성 극복

  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 초기 - 연결, 종료 낭비

HTTP 지속 연결 (Persistent Connections)

연결을 유지 하면서 종료하기 전까지 내부 매커니즘으로 요청하고 응답을 다 하고 종료하면 속도가 빠르다.

Stateless를 기억하자

서버 개발자들이 어려워하는 업무가 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽발생할 때가 어렵다. 이럴 때는 Sateless하게 설계하는 게 제일 중요하다.

ex) 선착순 이벤트, 명절 KTX 예약, 수강 신청
ex) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 → 수만명 동시 요청

📌 HTTP 메시지

HTTP 요청 메시지

• HTTP 메서드 (GET: 조회)
• 요청 대상 (/search?q=hello&hl=ko)
• HTTP Version

시작 라인 ( start-line = request-line )

  • request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

    • method (HTTP 메서드)

      • 종류 : GET, POST, PUT, DELETE...
      • 서버가 수행해야 할 동작 지정
        • GET : 리소스 조회
        • POST : 요청 내역 처리

    • request-target (요청 대상)

      • absolute-path[?query]
      • 절대경로[?쿼리]
      • 절대경로= "/" 로 시작하는 경로
      • 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.

    • HTTP-version (HTTP 버전)

HTTP 응답 메시지

시작 라인 (start-line = status-line)

  • status-line = HTTP-version SP status-code SP reason-phrase CRLF

    • HTTP-version (HTTP 버전)

    • status-code (상태 코드)

      • 요청 성공, 실패를 나타냄
        • 200 : 성공
        • 400 : 클라이언트 요청 오류
        • 500 : 서버 내부 오류

    • reason-phrase (이유 문구)

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

헤더 (header)

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

용도

  • HTTP 전송에 필요한 모든 부가 정보
  • ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보..
  • 표준 헤더가 너무 많음
  • 필요시 임의의 헤더 추가 가능

바디 (body)

용도

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

단순함 확장 가능

  • HTTP는 단순하다.
  • HTTP 메시지도 매우 단순하다.
  • 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술이다.

📌 HTTP 정리

  • HTTP 메시지에 모든 것을 전송
  • HTTP 역사 HTTP/1.1을 기준으로 학습
  • 클라이언트 서버 구조
  • 무상태 프로토콜(stateless)
  • HTTP 메시지
  • 단순함, 확장 가능
  • 지금은 HTTP 시대
profile
suyeon
이전 포스트

2. URI와 웹 브라우저 요청 흐름

다음 포스트

4. HTTP 메서드

0개의 댓글