4 minute read

김영한의 HTTP강의 정리 내용입니다.
모든 개발자를 위한 HTTP 웹 기본 지식

모든 것이 HTTP

HTTP(HyperText Transfer Protocol)

문서간의 링크(HyperText)를 통해서 연결할 수 있는 전송 프로토콜이다.

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

HTTP 역사

  • HTTP/0.9
    GET 메서드만 지원, HTTP 헤더 없음
  • HTTP/1.0
    메서드, 헤더 추가
  • HTTP/1.1
    가장 많이 사용
  • HTTP/2
    성능 개선
  • HTTP/3
    TCP대신에 UDP사용, 성능 개선

1.1에 대부분의 기능이 들어있으며 2와 3은 성능개선에 초점이 맞춰져 있다. 1.1을 가장 많이 사용하며 2와 3은 현재 증가하는 추세이다.

기반 프로토콜

1.1과 2는 TCP프로토콜 위에서 동작한다. 3은 UDP기반으로 개발되어 있으며 애플리케이션 레벨에서 직접 성능을 최적화 할 수 있도록 나왔다.

HTTP 특징

  • HTTP 메시지에 모든 것을 전송한다.
  • 클라이언트 서버 구조로 동작한다.
  • 무상태 프로토콜(스테이스리스)을 지향한다.
  • 비연결성
  • HTTP 메시지를 통해서 통신한다.
  • 단순하고 확장 가능하다.

클라이언트 서버 구조

HTTP는 클라이언트와 서버 구조로 되어있다.

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

과거에는 하나였지만 클라이언트와 서버를 개념적으로 분리해냈다. 비즈니스 로직과 데이터 같은 것들은 모두 서버에 넣는다. 그리고 클라이언트는 UI, 사용성에 집중한다. 이렇게 하면 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.

상태유지,무상태 프로토콜

스테이스리스(Stateless)

  • 서버가 클라이언트의 상태를 보존하지 않는다.
  • 장점 - 서버 확장성이 높다(스케일 아웃).
  • 단점 - 클라이언트가 추가 데이터를 전송한다.

Stateful, Stateless 차이

  • Stateful(상태유지)
    • 서버가 클라이언트의 이전 상태(문맥)를 보존한다.
      • 고객 : 이 노트북 얼만가요?
      • 점원 : 100만원 입니다.
      • 고객 : 2개 구매하겠습니다.
      • 점원 : 결제 완료되었습니다.
    • 항상 같은 서버가 유지되어야 한다.
      • 고객 : 이 노트북 얼만가요?
      • 점원1 : 100만원 입니다.
      • 고객 : 2개 구매하겠습니다.
      • 점원2 : ??? 무엇을 2개 구매하시겠어요???
    • 중간에 서버가 장애나면 결제를 처음부터 다시 진행해야 한다.
      현재까지의 문맥이 모두 사라진다.
  • Stateless(무상태)
    • 아무 서버나 호출해도 된다.
      • 고객 : 이 노트북 얼만가요?
      • 점원1 : 100만원 입니다.
      • 고객 : 노트북 2개 구매하겠습니다.
      • 점원2 : 결제 완료되었습니다.
        중간에 다른 점원으로 바뀌어도 된다. 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. 무상태는 응답 서버를 쉽게 바꿀 수 있으니 무한한 서버 증설이 가능하다.
    • 중간에 서버가 장애나면 서버를 교체하면 된다.
      상태를 보관하지 않으니 서버를 교체하면 그만이다.
    • 스케일 아웃 - 수평 확장에 유리하다.

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다. 일반적으로 브라우저 쿠키와 서버 세션등을 이용해서 상태를 유지한다. 이런 경우 같이 상태 유지는 꼭 필요한 경우에만 어쩔 수 없이 최소한만 사용한다.
선착순 이벤트같이 같은 시간에 딱 맞춰 발생하는 경우에 대응하려면 최대한 스테이스리스하게 설계하는 것이 중요하다.

비 연결성(connectionless)

연결을 유지하는 모델

클라이언트1,2,3이 하나의 서버와 연결되어 있을 때 현재 클라이언트1만 요청/응답을 하고있더라도 클라이언트2와3 또한 계속 연결을 유지하며 서버의 자원을 소모하게 된다.

연결을 유지하지 않는 모델

클라이언트1과 서버가 TCP/IP 연결을 하여 요청/응답을 하고 TCP/IP 연결을 종료한다. 나머지 클라이언트도 동일한 과정을 거친다. 현재 요청/응답을 주고 받을 때만 서버에 연결하고 끝날시 바로 연결을 끊어서 서버를 유지하는 자원을 최소화한다.

비연결성

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

한계와 극복

  • 요청시 마다 TCP/IP 연결을 새로 맺어야하니 3 way handshake 시간이 추가된다.
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, css, 추가 이미지 등 수 많은 사원이 함께 다운로드 된다.
  • 지금은 HTTP지속 연결(Persistent Connections)로 문제를 해결한다.

    HTTP지속 연결

    클라이언트와 서버가 연결을 하고 HTML을 요청/응답하고 연결을 종료할 것이다. 그리고 HTML을 읽어 나가다가 JS가 필요하면 또 연결을 하고 JS를 요청/응답하고 연결을 종료할 것이다. 이 과정을 계속 반복하게 되면 연결과 종료의 낭비가 생기게 된다.
    최초에 한번만 연결을 하고 HTML과 JS를 모두 받아온뒤 연결을 종료하면 연결과 종료의 빈도를 줄일 수 있다. 그래서 연결을 하고 내부 매커니즘에 따라 웬만한 HTML페이지 하나를 받을 때 까지 유지를 하고 다 받고 나면 종료를 한다.

HTTP 메시지

초록색 부분의 공백라인은 반드시 있어야 한다.

start-line (시작 라인)

start-line은 request-line과 status-line으로 구성된다. 요청 메시지는 request-line이고 응답 메시지는 status-line이다.

요청 메시지

request-line = method SP request-target SP HTTP-version CRLF 이렇게 구성된다. SP는 공백(스페이스)를 말하고 CRLF는 엔터를 말한다. GET은 HTTP 메서드, /search?q=hello&hl=ko는 요청 대상, HTTP/1.1은 HTTP버전이다.

  • HTTP 메서드
    GET /search?q=hello&hl=ko HTTP/1.1
    • 종류
      • GET(서버에게 해당 리소스를 요청한다.)
      • POST(해당 리소스를 넘겨서 처리를 요청.)
      • PUT
      • DELETE(삭제)
      • 등등이 있다.
  • 요청 대상
    GET /search?q=hello&hl=ko HTTP/1.1
    • absolute-path[?query]
    • 보통 절대경로로 시작한다. 절대경로(absolute-path)란 “/”로 시작하는 경로를 말한다.
    • *, http://…?x=y와 같이 다른 유형의 경로지정 방법도 있다.
  • HTTP 버전
    GET /search?q=hello&hl=ko HTTP/1.1
    HTTP Version이다.

응답 메시지

status-line은 HTTP-version SP status-code SP reason-pharse CRLF 이렇게 3개가 들어간다. HTTP/1.1은 HTTP버전, 200은 상태코드, OK는 이유 문구다. 상태코드는 요청 성공, 실패를 나타낸다. 200은 성공, 400은 클라이언트 요청 오류, 500은 서버 내부 오류다. 이유 문구는 사람이 이해할 수 있는 짧은 상태 코드 설명 글이다.

HTTP 헤더

header-field = field-name“:” OWS field-value OWS 이렇게 구성된다. OWS는 띄어쓰기를 허용한다는 말이다. field-name은 대소문자 구분이 없다.

  • HTTP 전송에 필요한 모든 부가정보가 다 들어있다.
  • 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등등…
  • 표준 헤더는 아주 많다.
  • 필요시 임의의 헤더를 추가 가능하다. 서로 약속된 서버와 클라이언트라면 이해 가능할 것이다.
    • 예) helloworld: hihi

HTTP 메시지 바디

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

Tags:

Categories:

Updated:

Leave a comment