모든 것이 HTTP

HTTP

HyperText Transfer Protocol

→ hypertext html 문서 간의 링크를 통해서 연결할 수 있는 html를 전송하는 프로토콜

현재는 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)
HTTP/2
- 2015년: 성능 개선
HTTP/3
- 진행중: TCP 대신에 UDP 사용, 성능 개선

→ HTTP/2, HTTP/3는 주로 성능 위주, 스펙은 HTTP/1.1을 주로 봐야함

기반 프로토콜

TCP: HTTP/1.1, HTTP/2
- 일반적으로 TCP는 사전처리 작업도 많고, 시간도 느리다
UDP: HTTP3
현재 HTTP/1.1 주로 사용
- HTTP/2, HTTP/3도 점점 증가

예를 들어

여기에 이렇게 보이는 h2와 h3가 각각 HTTP/2, HTTP/3를 의미한다.

HTTP 특징

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

클라이언트 서버 구조

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

클라이언트와 서버를 분리하는 것이 중요하다 !

비지니스 로직과 데이터를 모두 서버에 넣는다.

클라이언트는 UI 그리고 사용성에 집중한다.

이렇게 하면 클라이언트와 서버가 각각 독립적으로 진화 할 수 있다.

서버도 php를 쓰든, java를 쓰든 상관 없이 트래픽이나 백엔드 로직에 대해 집중하면 된다.

클라이언트는 복잡한 비지니스 로직이나 복잡한 데이터를 다룰 필요 없이 단순하게 UI를 어떻게 그릴지에 대해 고민하면 된다.

Stateful, Stateless

무상태 프로토콜

스테이트리스(Stateless)

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

Stateful, Stateless 차이

상태 유지: 중간에 다른 점원으로 바뀌면 안된다.
(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려주어야 한다.)
무상태: 중간에 다른 점원으로 바뀌어도 된다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. → 무한한 서버 증설 가능

상태 유지 - Stateful

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

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

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

중간에 점원이 바뀌면?

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

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

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

→ 즉 이러한 상태가 무상태라고 할 수 있다.

무상태 - Stateless

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

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

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

→ 점원이 계속 바뀌어도 연결이 된다. 상태유지에서는 다른 점원을 만나면 에러가 발생한다.

이러한 무상태가 클라이언트 서버 아키텍쳐에서는 엄청난 확장성 을 가지고 온다

상태 유지 - Stateful

항상 같은 서버가 유지되어야 한다.

중간에 서버가 장애나면?

→ 요청을 처음부터 처리해야 한다.

무상태 - Stateless

아무 서버나 호출해도 된다.

중간에 서버가 장애나면?

→ 아무 서버나 연결해준다.

스케일 아웃 - 수평 확장에 유리

Stateless 실무 한계

모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
무상태
- 예) 로그인이 필요 없는 단순한 서비스 소개 화면
상태 유지
- 예) 로그인
로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
상태 유지는 최소한만 사용

데이터를 대량으로 전송해야 한다

비 연결성(connectionless)

연결을 유지하는 모델

클라이언트1이 서버에 요청을 보내면 서버는 응답을 보내준다.

클라이언트2가 서버에 요청을 보내면 서버는 응답을 보내준다.

이 때에도 클라이언트1은 서버와 연결이 되고 있는 상태이다.(= 자원을 소모하고 있다.)

클라이언트3이 서버에 요청을 보내면 서버는 응답을 보내준다.

이 때에도 클라이언트1과 클라이언트2는 서버와 연결이 되고 있는 상태이다.(= 자원을 소모하고 있다.)

클라이언트1이 서버에 요청을 보내면 서버는 응답을 보내준다.

이 때에도 클라이언트2와 클라이언트3은 서버와 연결이 되고 있는 상태이다.(= 자원을 소모하고 있다.)

클라이언트2와 클라이언트3이 놀고 있어도 서버가 연결을 계속 유지해야 한다.

연결을 유지하지 않는 모델

클라이언트1이 서버에 요청을 보내면 서버는 응답을 보내준다.

응답을 보낸 후에는 클라이언트1과 서버의 연결은 종료가 된다.

클라이언트2나 클라이언트3이 요청을 보내 서버는 응답을 보낸 후에도 둘 사이의 연결은 종료된다.

이렇게 되면 자원을 현재 요청을 주고 받을 때에만 연결을 하고 그 다음에는 끊어버려서 서버가 유지하는 자원을 최소한으로 유지한다.

비 연결성

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

한계와 극복

TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 사용자 입장에서 단점(시간이 더 오래 걸림)
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바 스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 초기 - 연결, 종료 낭비

HTTP 지속 연결(Persistent Connections)

HTML 문서 하나를 모두 받을 때까지 연결을 유지한다.

→ HTTP2나 HTTP3를 이용하면서 더 빨라졌다.

스테이트리스를 기억하자

서버 개발자들이 어려워하는 업무

정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
예) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 → 수만명 동시 요청

HTTP 메시지