CS/Network

HTTP의 기본

oxdjww 2023. 10. 3. 00:01
728x90
반응형

Intro

본 포스팅에서는 HTTP의 정의 및 특징 등 HTTP의 기본에 대해 다룬다.

Contents

  • HTTP의 정의

  • Client - Server 구조

  • Stateless Protocol

  • 비 연결성(connectionless)

  • HTTP Message


HTTP의 정의

HTTP는 HyperText Transfer Protocol의 약자이다.

HTTP 메시지로 다양한 데이터를 전송할 수 있다.

  • HTML, TEXT

  • IMAGE, 음성, 영상, 파일

  • JSON, XML(API)


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 사용, 성능 개선

실질적으로 필요한 기능은 HTTP 1.0 version에 모두 정의되어 있고, 실제로 대부분 쓰이는 것도 1.0 versiond이 많다.
2.0, 3.0 version은 성능 개선에 초점을 둔 version이다.


chrome 브라우저에서는 혼용하여 사용하고 있는 모습이다.

기반 프로토콜

  • TCP : HTTP/1.1, HTTP/2
  • UDP : HTTP/3

HTTP 특징

  • Client - Server 구조를 가진다.

  • 무상태 프로토콜(Stateless), 비연결성 특징을 가진다.

  • HTTP Message

  • 단순함, 확장 가능


Client - Server 구조

  • Request와 Request에 대한 Response를 가지는 구조이다.

  • 클라이언트는 서버에 요청을 보내고, 응답을 대기한다.

  • 서버가 요청에 대한 결과를 만들어서 응답한다.


Stateless Protocol

  • 서버가 클라이언트의 상태를 보존하지 않는다.

  • 장점 : 서버의 확장성이 높다

  • 단점 : 클라이언트의 데이터 전송량이 많다.


Stateful vs. Stateless

고객이 점원에게 노트북을 구입하는 상황을 가정하여 설명한다.
고객은 client, 점원은 server로 대입하여 해석할 수 있다.

Stateful한 경우

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

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

고객 : 신용카드로 구매하겠습니다.
점원 : 200만원 결제 완료 되었습니다.

상태를 유지하는 경우, 노트북의 가격, 개수, 결제 수단 등에 대한 정보를 유지하기 때문에 정보를 재전송하지 않아도 된다.

하지만 점원이 중간에 바뀌는 경우에는 어떨까?

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

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

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

상태를 유지할 경우 점원이 바뀌어 버리면 정보를 알 수 없다.

정리하자면 다음과 같다.

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

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

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

Stateless한 경우

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

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

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

상태를 유지하지 않을 경우, 고객은 많은 정보를 전달하게 된다.
stateless한 상태에서 점원이 바뀌는 경우에는 어떨까?

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

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

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

점원이 바뀌어도 상태를 유지하지 않기에 통신에 장애가 발생하지 않는 모습이다.

Stateful, Statelss 정리

  • Stateful : 중간에 다른 점원으로 바뀌면 안 된다.
    • 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 공유해야 한다.
  • Stateless : 중간에 다른 점원으로 바뀌어도 된다.
    • 고객이 증가해도 점원을 대거 투입할 수 있다.
    • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다는 말이다.

-> 즉, statless기반 통신은 응답 서버의 교체가 용이하다. 이는 무한한 서버 증설이 가능함을 의미한다.

Stateless Protocol 예제

위의 상황을 client와 server의 입장으로 다시 설명한다.

서버가 상태를 유지하며 저장하고 있기 때문에 한 클라이언트에 대해서 같은 서버가 계속 응답해야 하는 구조이다.
교체를 하려면 상태를 서버끼리 공유해야 한다.

하지만 갑작스런 장애로 인해 서버를 교체해야 하는 경우, 상태를 보존할 수 없어 문제가 된다.

하지만 stateless한 경우는 다르다.
상태를 저장하고 있지 않고 요청마다 정보가 담겨있는 구조이다.

서버의 장애가 발생해도 동일 기능을 하는 다른 서버로 교체하는 것에 제한을 받지 않는다.

이런 특징은 서버 확장의 용이함을 보장한다.

Stateless 실무 한계

--

  • 모든 것을 stateless하게 설계 할 수 있는 경우가 있고 없는 경우도 있다.

  • 무상태

    • 로그인이 필요 없는 단순 서비스 소개 화면

  • 상태 유지

    • 로그인

  • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다.

    • 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다.

  • 최대한 statless하게 설계하되, stateful은 최소한으로 사용한다는 것이 핵심이다.


비 연결성(connectionless)

TCP/IP기반 통신의 client - server 구조에서 연결성에 대해 알아보자.

연결을 유지하는 모델

server는 연결된 client마다 세션을 유지해야 한다.
유지할 때 서버의 리소스를 지속적으로 소모한다.

연결을 유지하지 않는 모델

server는 연결을 유지하지 않는다.
그러므로, 통신을 하지 않는 client와의 불필요한 연결 유지를 하지 않기에 리소스 낭비를 하지 않는다.

이렇게 연결을 유지하지 않는 모델을 채택한 HTTP는 다음과 같은 특징을 가진다.

  • HTTP는 기본적으로 연결을 유지하지 않는 모델이다.

  • 일반적으로 초 단위 이하의 빠른 속도로 응답한다.

  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.

  • 서버 자원을 매우 효율적으로 사용할 수 있다.


그리고 다음과 같은 한계도 가진다.

  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가

  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드

  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결

  • HTTP/2, HTTP/3에서 더 많은 최적화



HTTP Message

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

HTTP는 HTTP Request와 HTTP Response로 이루어져있고, 위와 같은 구조를 지닌다.
예제는 아래와 같다.

추가로, HTTP Request Message도 본문(body)를 가질 수 있다.
각 구조에 대해 더 자세히 알아보자.

start-line

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

상단인 start-line은 다음과 같은 구조를 가진다.
start-line = request-line / status-line
status-line = HTTP-version SP status-code SP reason-phrase CRLF

request-line은 HTTP Request인 경우이고,
statue-line은 HTTP Response인 경우이다.

request-line

Request-line의 start-line은 세 부분으로 구성되어 있다.

| HTTP method

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

종류 : GET, POST, PUT, DELETE..
서버가 수행해야 할 동작을 지정한다.

| 요청 대상

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

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

| HTTP version

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

사용하는 HTTP의 버전을 의미한다.

status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF
Status-line의 start-line은 세 부분으로 구성되어 있다.

| HTTP Version

사용하는 HTTP의 버전을 의미한다.

| HTTP Response Code

HTTP 상태 코드로서, 요청이 성공했는지 실패했는지를 의미한다.

  • 200 : 성공

  • 400 : 클라이언트 요청 오류

  • 500 : 서버 내부 오류


| Reason Phrase

이유 문구로서, 사람이 이해할 수 있는 짧은 상태 코드 설명 글이다.
e.g. OK

HTTP Header

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용이란 뜻)

헤더 필드는 위와 같은 구조를 가진다.
field-name은 대소문자를 구별하지 않는다.

  • 위는 HTTP header의 예제이다.
  • HTTP 전송에 필요한 모든 부가정보가 담겨있다.
  • 표준 헤더는 정말 많다.
  • 필요시 임의의 헤더를 추가할 수 있다.

HTTP Message Body

  • 실제로 전송할 데이터이다.

  • HTML document, image, vidoe, JSON, 등 byte로 표현 가능한 모든 데이터가 전송 가능하다.

  • 생략 가능하다.


감사합니다.


Ref

모든 개발자를 위한 HTTP 웹 기본 지식, 인프런 김영한 강사님

728x90
반응형

'CS > Network' 카테고리의 다른 글

HTTP Status Code  (0) 2023.10.03
HTTP 메서드와 활용  (0) 2023.10.03
웹 브라우저 요청 흐름  (0) 2023.10.02
URI  (0) 2023.10.02
DNS  (0) 2023.10.02

'CS/Network'의 다른글

  • 현재글HTTP의 기본

관련글

티스토리툴바