유지연

유지연

I’m a junior web developer.
Let’s code with me!

[HTTP] 3. HTTP 기본

업데이트:
6 분 소요

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리했습니다.

(1) 모든 것이 HTTP

HTTP

  • HyperText Transfer Protocol
  • HTTP는 문서간의 링크를 통해 연결할 수 있는 프로토콜을 의미하지만, 현재는 HTTP 메시지에 모든 것을 전송한다.
  • 거의 모든 형태의 데이터를 전송할 수 있다.
    • HTML, TEXT
    • IMAGE, 음성, 영상, 파일
    • JSON, XML (API)
  • 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP 역사

  • HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
  • HTTP/1.0 1996년: 메서드, 헤더 추가
  • HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
    • RFC2068 (1997) → RFC2616 (1999) → RFC7230~7235 (2014)
    • 인터넷 상의 문서를 보면 대부분 RFC2616 버전으로 설명이 되어있다.
  • HTTP/2 2015년: 성능 개선
  • HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

  • TCP: HTTP/1.1, HTTP/2
  • UDP: HTTP/3
  • 현재는 HTTP/1.1 주로 사용하고, HTTP/2, HTTP/3 도 점점 증가하고 있다.
  • TCP는 속도가 빠른 메커니즘이 아니다. HTTP/3은 성능을 최적화하도록 새로 설계한 버전이다.

HTTP 특징

  • 클라이언트 서버 구조로 동작한다.
  • 무상태 프로토콜을 지향하고, 비연결성이다.
  • HTTP 메시지로 통신한다.
  • 단순하고, 확장이 가능하다.

(2) 클라이언트 서버 구조

  • Request Response 구조
  • 클라이언트가 HTTP 메시지를 통해 서버에 요청(Request)을 보내고, 서버의 응답을 기다린다.
  • 서버가 요청에 대한 결과를 만들어서 응답(Response)을 한다.
  • 클라이언트는 그 응답 결과에 따라 동작을 한다.

http

  • 왜 서버와 클라이언트를 분리할까? 이전에는 둘이 분리되어있지 않았다. 클라이언트와 서버를 개념적으로 분리한다. 비즈니스 로직과 데이터는 서버에 몰아 넣고, 클라이언트는 UI와 사용성에 집중시킨다. 서버와 클라이언트는 서로 독립적이 된다. 서버는 서버의 역할에만 집중하고, 클라이언트는 클라이언트의 역할에만 집중한다. 즉, 서버의 백엔드에서는 서버의 성능에만 집중하면 되고, 클라이언트는 UI와 사용량에만 집중한다.

(3) Steteful, Stateless

Stateful

  • 서버가 클라이언트의 상태를 보존한다.
  • 고객이 노트북을 구입하는 상황, 고객이 점원과 나눈 대화의 내용이 유지된다. 따라서 고객의 마지막 대화에 이전 대화 내용을 포함하지 않아도 된다.
고객: 이 노트북 얼마인가요?
점원: 100만원 입니다. (노트북 상태 유지)

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

고객: 신용카드로 구매하겠습니다.
점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)
  • 위의 상황에서 중간에 점원이 바뀐다면, 점원B와 점원C는 컨텍스트를 모르는 상태로 고객을 응대한다.
고객: 이 노트북 얼마인가요? 
점원A: 100만원 입니다.

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

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

Stateless

  • 서버가 클라이언트의 상태를 보존하지 않는다.
  • 고객이 노트북을 구입하는 상황, 고객의 마지막 대화만으로도 점원과의 대화 진행이 가능하다.
고객: 이 노트북 얼마인가요? 
점원: 100만원 입니다.

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

고객: 노트북 2개를 신용카드로 구매하겠습니다. 
점원: 200만원 결제 완료되었습니다.
  • 위의 상황에서 점원이 바뀐다 하더라도, 고객의 마지막 대화만으로도 새로운 점원과 대화 진행이 가능하다. 이 때, 노트북의 종류가 하나라고 가정한다.
고객: 이 노트북 얼마인가요? 
점원A: 100만원 입니다.

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

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

Stateful, Stateless 차이

  • 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다. 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다. 다른 점원으로 바뀌면 장애가 발생한다.
    • 갑자기 고객이 증가해도 점원을 대거 투입하기 어렵다.
    • 갑자기 클라이언트의 요청이 증가해도 서버를 대거 투입할 수 없다.
  • 무상태 : 중간에 다른 점원으로 바뀌어도 된다. 그때그때 필요한 정보를 모두 넘기기 때문에 점원이 바뀌더라도 장애가 발생하지 않는다.
    • 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
    • 갑자기 클라이언트의 요청해도 서버를 대거 투입할 수 있다.
  • 무상태는 상태를 유지할 필요가 없기 때문에 응답 서버를 쉽게 바꿀 수 있다. 따라서 무한히 서버를 증설할 수 있다.

상태 유지

  • Stateful은 항상 같은 서버가 유지되어야 한다.
  • 클라이언트의 요청 정보를 서버에 계속 저장하고 있어야 한다.

http

  • 클라이언트의 요청이 완료되지 않은 상태에서 서버에 장애가 발생한다면, 클라이언트는 처음부터 요청을 다시 해야 한다.

http

무상태

  • Stateless는 서버가 상태를 보관하지 않는다.
  • 클라이언트가 요청을 할 때부터 필요한 정보를 모두 담아서 보낸다. 서버는 클라이언트의 상태를 보관하지 않고, 필요시에 응답한다.

http

  • 중간에 서버1에 장애가 발생한다면, 중계서버는 클라이언트의 요청을 서버2로 던진다. 클라이언트의 요청에 정보가 모두 포함되어 있기 때문에, 서버2는 문제 없이 요청을 처리할 수 있다.

http

스케일 아웃

  • 서버를 확장하는 것을 스케일 아웃이라 하는데, 무상태는 서버를 수평 확장하는 데 유리하다.

http

  • 예를 들어 이벤트 페이지가 있다면, 많은 사용자들이 해당 페이지에 접속하려고 할 것이다. 이런 경우에 대비하여 백엔드에서 간단하게 서버를 확장할 수 있다.

실무 한계

  • 모든 것을 무상태로 설계할 수는 없다. 무상태로 설계할 수 없는 경우가 반드시 존재한다.
    • 무상태 예) 로그인이 필요 없는 단순한 서비스 소개 화면
    • 상태 유지 예) 로그인
  • 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지해야 한다.
  • 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다.
  • 상태 유지는 최소한으로 사용하고, 꼭 필요한 경우에만 상태를 유지하는 것이 좋다.
  • Stateless는 전송하는 데이터량이 Stateful보다 더 많다는 단점이 있다.

(4) 비 연결성(connectionless)

연결을 유지하는 모델

  • 클라이언트1이 요청을 하고 서버가 응답한다.

http

  • 그리고 클라이언트2가 요청을 하고 서버가 응답 응답한다.그 동안에도 클라이언트1과 서버는 연결을 유지한다.

http

  • 클라이언트3이 요청을 하고 서버가 응답을 하는 동안에도 클라이언트1과 클라이언트2는 연결이 유지된다.

http

연결을 유지하는 모델에서 서버는 계속해서 연결을 유지하고, 따라서 연결을 유지하기 위한 서버 자원을 소모하게 된다.

연결을 유지하지 않는 모델

  • 클라이언트1이 요청을 하고 서버가 응답한다. 그리고 연결을 종료한다.

http

http

  • 클라이언트2가 요청을 하고 서버가 응답한다. 그리고 연결을 종료한다.

http

http

  • 클라이언트3이 요청을 하고 서버가 응답한다. 그리고 연결을 종료한다.

http

http

연결을 유지하지 않는 모델은 서버는 연결을 유지하지 않기 때문에 최소한의 자원만 사용하여 서버를 운영한다.

비 연결성

  • HTTP는 연결을 유지하지 않는 모델이 기본이다.
  • 일반적으로 초단위 이하의 바른 속도로 응답한다.
  • 1시간 동안 수천명이 서비스를 사용한다 하더라도, 실제 서버에서 동시에 처리하는 요청은 매우 작다.
  • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않는다. 검색 버튼을 누르고 결과를 보고 검색 버튼을 누른다.클라이언트가 요청을 보내지 않는 동안에는 연결을 끊는 편이 경제적이다.

서버 자원을 매우 효율적으로 사용할 수 있고, 자원의 가용성을 높인다.

한계와 극복

  • 매 요청마다 TCP/IP 연결을 새로 맺어야 한다. 따라서 3 way handshake 시간이 추가된다. 사용자입장에서는 시간이 오래걸린다는 것이 단점이다.
  • 웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 많은 자원이 함께 다운로드된다.
  • 계속해서 연결을 끊고 다시 연결하고 또 연결을 끊고 다시 연결하는 것은 비효율적이다. 모든 요청이 하나 끝날 때마다 연결을 종료하는 아래의 예시에서는 HTML, 자바스크립트, 이미지 응답을 받는 데 총 0.9초가 소요된다.

http

  • 최근에는 HTTP 지속 연결(Persistent Connection)로 문제 해결했다. 모든 요청이 끝날때 까지 연결을 유지하는 아래의 예시에서는 HTML, 자바스크립트, 이미지 응답을 받는 데 총 0.5초가 소요된다.

http

  • HTTP/2, HTTP/3에서는 위와 같은 과정을 더 빠르게 진행하도록 최적화하였다. 특히 HTTP/3에서는 UDP 프로토콜을 사용하기 때문에 연결 속도 자체가 훨씬 빠르다.

Stateless가 핵심!

  • 같은 시간에 딱 맞추워 발생하는 대용량 트랙픽의 경우, 최대한 Stateless하게 설계하는 것이 중요하다.
    • 예) 선착순 이벤트, 명절 KTX 예약, 학과 수강 신청
  • 로그인이 필요 없는 정적 파일을 먼저 뿌린 후, 사용자들이 그 페이지 안에서 시간을 보낸 후 이벤트 참여 버튼을 누르게끔 유도한다.

(5) HTTP 메서드

HTTP 메시지

  • 우리가 생각하는 모든 바이너리 데이터를 모두 HTTP 메시지로 보낼 수 있다.
    • 예) HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML
  • 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
  • HTTP 메시지는 요청 메시지와 응답 메세지의 구조가 다르다.
  • HTTP 요청 메시지
GET /search?q=hello&hl=ko HTTP/1.1 
Host: www.google.com
  • HTTP 응답 메시지
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8 
Content-Length: 3423

<html>
	<body>...</body>
</html>
  • HTTP 메시지는 시작 라인(start-line), 헤더(header), 공백 라인(empty line, CRLF), 메시지 바디(message body)로 구성된다.
    • 요청 메시지와 응답 메시지는 시작 라인이 다르고, 나머지 부분은 동일하다.
    • HTTP 요청 메시지도 메시지 바디를 가질 수 있다.

http

http

HTTP-message   = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

시작 라인

요청 메시지

http

  • start- line에는 request-line과 status-line이 있는데, 요청 메시지의 시작 라인은 request-line이다.
  • request-line = method SP(공백) request-target SP HTTP-version CRLF(앤터)
    • HTTP 메서드 : GET(조회)
    • 요청 대상 : /search?q=hello&hl=ko
    • HTTP version : 1.1
  • HTTP 메서드는 서버가 수행해야 할 동작을 지정한다.
    • 종류 : GET, POST, PUT, DELETE …
    • GET : 리소스 조회
    • POST : 요청 내역 처리
  • 요청 대상은 보통 절대 경로(absolute path)로 시작한다.
    • absolute-path[?query] (절대경로[?쿼리])
    • 절대 경로 : /로 시작하는 경로
    • 참고로 *, http://...?x=y와 같은 다른 유형의 경로 지정 방법도 있다.

응답 메시지

http

  • start- line에는 request-line과 status-line이 있는데, 응답 메시지의 시작 라인은 status-line이다.
  • status-line = HTTP-version SP status-code SP reason-phrase CRLF
    • HTTP 버전 : 1.1
    • HTTP 상태 코드 : 요청 성공, 실패를 나타냄
      • 200 : 성공
      • 400 : 클라이언트 요청 오류
      • 500 서버 내부 오류
    • 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

http

  • header-field = field-name:OWS field-value OWS
    • OWS : 띄어쓰기 허용
    • file-name과 : 사이는 띄어쓰기 허용 X
  • field-name은 대소문자를 구분하지 않는다.

용도

  • HTTP 헤더에는 HTTP 전송에 필요한 모든 부가 정보를 포함하고 있다. 메시지 바디의 내용을 제외한 모든 메타 데이터 정보를 포함한다.
    • 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보…
  • 표준 헤더는 종류가 매우 많다.
  • 필요시 임의의 헤더를 추가할 수 있다.
    • 예) hellowworld: hehe

HTTP 메시지 바디

http

  • HTTP 메시지 바디에는 실제 전송할 데이터가 들어있다.
  • byte로 표현할 수 있는 모든 데이터를 포함할 수 있다.
    • 예) HTML 문서, 이미지, 영상, JSON 등
  • 데이터를 압축하여 전송할 수도 있다.

단순한 HTTP

  • HTTP는 단순하다. 또한 HTTP 메시지도 단순하다.

크게 성공하는 표준 기술은 단순하지만 확장이 가능한 기술이다.

태그:

카테고리:

업데이트:

참고

2022-02-22 TIL(at work)

업데이트:
5 분 소요

업무 배경 이 업무가 할당된 이유 회사에서 맡고 있는 서비스 중, 회원이 구매를 신청하면 정부24에서 그 컨텐츠를 구매하여 제공을 하는 서비스가 있다. (참고로, 구매를 한다고 바로 완료되는게 아니라 구매 로직을 태운 후 실제로 컨텐츠를 가져오기까지 어느정도 시간이 소요된다....