HTTP - HTTP 범위, 클라이언트-서버 구조, Stateful&Stateless

모든 것이 HTTP

HTTP란 HyperText Transfer Protocol의 약자다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML(API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
  • 게임서버 정도는 TCP를 사용함.

역사

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

기반 프로토콜

• TCP
  • HTTP/1.1, HTTP/2은 TCP 프로토콜 위에서 동작한다.
• UDP
  • HTTP/3는 UDP를 기반으로 개발되어 있다.
  • TCP 기반의 버전들은 UDP 기반의 버전들보다 데이터도 많고, 연결 과정이 많기 때문에 UDP 기반의 버전을 개조해서 사용.
• 현재 HTTP/1.1을 주로 사용한다.
  • HTTP/2, HTTP/3도 점점 증가하는 추세

특징

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이트리스), 비연결성
• HTTP 메시지
• 단순하고 확장 가능하다.

클라이언트 서버 구조

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

과거 클라이언트와 서버가 분리되어 있는 개념이 아니였다.
클라이언트와 서버를 개념적으로 분리해 비즈니스 로직과 데이터는 서버에 집중하고, 클라이언트는 UI 렌더링과 사용성 등에 집중을 하는 구조를 통해 클라이언트와 서버가 각각 독립적으로 진화를 했다.
때문에 클라이언트는 클라이언트의 역할에 집중해서 기술을 발전시키고, 서버는 서버의 역할에 집중해서 기술을 발전시킬 수 있다.

Stateful, Stateless

무상태 프로토콜(스테이트리스 Stateless)

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

Stateful, Stateless 차이

• 상태 유지(Stateful)
  • 중간에 서버가 바뀌면 안된다.
    • 혹여나 중간에 서버가 바뀐다면 기존 서버에서 바뀌는 서버에 정보를 전달해야 함
• 무상태(Stateless)
  • 중간에 서버가 바뀌어도 된다.
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
    • 무한한 서버 증설이 가능해진다!

한계

• 모든 것을 무상태로 설계 할 수 있는 경우도 있고, 없는 경우도 있다.
• 무상태
  • 로그인이 필요 없는 단순한 서비스 소개 화면
  • 상태 유지가 되지 않기 때문에 모든 데이터를 보내야 함.
    • 데이터를 너무 많이 보냄
• 상태 유지
  • 로그인
    • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다.
    • 일반적으로는 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지함.
    • 상태 유지는 최소한만 사용해야 한다.

인프런 김영한 지식 공유자님의 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식