[1] 모든 것이 HTTP

: HTTP 메시지로 거의 모든 형태의 데이터가 전송될 수 있다.
(ex. HTML, 텍스트, 이미지, 음성, 영상, 파일, JSON, XML(API)..)

서버 간 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

✔️ HTTP 역사
HTTP/1.1 (1997년) → 가장 많이 사용되며 우리에게 가장 중요한 버전으로 꼽힌다.

✔️ 기반 프로토콜
TCP: HTTP/1.1(현재 주로 사용), HTTP/2 → tcp 프로토콜 위 동작
UDP: HTTP/3 → udp 기반
(HTTP/2, HTTP/3 또한 점점 증가)

HTTP 특징

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

---

[2] 클라이언트 서버 구조

: Request Response 구조

---

[3] Stateful, Stateless

무상태 프로토콜 (Stateless)

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

Stateful 🆚 Stateless

📌 상태유지 (Stateful)의 예시를 들어보자.

🙋🏻‍♀️: 선생님, 저 아이스크림 먹고싶어요.
👩🏻‍🏫: 딸기? 초코? 어떤게 먹고싶니?

🙋🏻‍♀️: 저는 초코가 먹고싶어요.
👩🏻‍🏫: 그래, 초코 아이스크림은 냉동실 첫번째 칸에 있으니 가져다 먹어도 돼.

🙋🏻‍♀️: 두 개 먹어도 돼요 ??
👩🏻‍🏫: 그래 !!

이 대화를 보았을 때 아무런 문제가 없다. 단, 선생님이 바빠 이야기를 나누다 사라졌다 ..! 옆반 선생님이 오셨다면 ..?

🙋🏻‍♀️: 선생님, 저 아이스크림 먹고싶어요.
👩🏻‍🏫 (토끼반 선생님): 딸기? 초코? 어떤게 먹고싶니?
🏃🏻‍♀️💨
🙋🏻‍♀️: 저는 초코가 먹고싶어요.
👩🏻‍🏫 (기린반 선생님): ?? 갑자기 무슨 초코? 초콜렛이 먹고싶니?
🏃🏻‍♀️💨
🙋🏻‍♀️: 두 개 먹어도 돼요 ??
👩🏻‍🏫 (펭귄반 선생님): ?? 뭘 두 개나 먹겠다는 거야?

🙋🏻‍♀️ 아이의 대화는 똑같다. 그러나 선생님이 자꾸 바뀌면서 대화의 흐름을 파악하지 못하고 있다.

Stateful이라면 상태를 유지해줘야 한다.

🙋🏻‍♀️: 선생님, 저 아이스크림 먹고싶어요.
👩🏻‍🏫: 딸기? 초코? 어떤게 먹고싶니? (아이스크림 상태 유지)

🙋🏻‍♀️: 저는 초코가 먹고싶어요.
👩🏻‍🏫: 그래, 초코 아이스크림은 냉동실 첫번째 칸에 있으니 가져다 먹어도 돼. (아이스크림, 초코맛 상태 유지)

🙋🏻‍♀️: 두 개 먹어도 돼요 ??
👩🏻‍🏫: 그래 !! (노트북, 초코맛, 두 개 상태 유지)

📌 무상태 (Stateless)의 예시를 들어보자.

🙋🏻‍♀️: 선생님, 저 아이스크림 먹고싶어요.
👩🏻‍🏫: 딸기? 초코? 어떤게 먹고싶니?

🙋🏻‍♀️: 저는 초코 아이스크림이 먹고싶어요.
👩🏻‍🏫: 그래, 초코 아이스크림은 냉동실 첫번째 칸에 있으니 가져다 먹어도 돼.

🙋🏻‍♀️: 초코 아이스크림 두 개 먹어도 돼요 ??
👩🏻‍🏫: 그래 !! 초코 아이스크림 두개 먹어.

이건 무상태일 때 대화 내용이다.
이제 선생님이 바뀌었을 때를 다시 살펴보자.

🙋🏻‍♀️: 선생님, 저 아이스크림 먹고싶어요.
👩🏻‍🏫 (토끼반 선생님): 딸기? 초코? 어떤게 먹고싶니?
🏃🏻‍♀️💨
🙋🏻‍♀️: 저는 초코 아이스크림가 먹고싶어요.
👩🏻‍🏫 (기린반 선생님): 그래, 초코 아이스크림은 냉동실 첫번째 칸에 있으니 가져다 먹어도 돼.
🏃🏻‍♀️💨
🙋🏻‍♀️: 초코 아이스크림 두 개 먹어도 돼요 ??
👩🏻‍🏫 (펭귄반 선생님): 그래 !! 초코 아이스크림 두개 먹어.

이렇게 토끼반 선생님이든, 기린, 펭귄반 선생님이든 전혀 상관이 없어진다.

즉,

Stateful: 중간에 선생님이 바뀌면 안 된 다.
(바뀐다면 상태 정보를 선생님마다 미리 알려줘야한다.)

Stateless: 스케일 아웃 - 수평 확장 유리
선생님이 100번 바뀌어도 상관 없다.
- 갑자기 아이들이 한꺼번에 몰려와 아이스크림을 달라고 졸라도 선생님을 그만큼 모셔올 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. ➡️ 무한대로 서버 증설 가능
(상태유지는 갑자기 통신하던 서버가 고장난다면 처음부터 그 과정을 다시 해야한다.)

✔️ Stateless 실무 한계
모든 것을 무상태로 설계할 수 있는 경우도 있지만 그렇게 할 수 없는 경우도 있다.

무상태의 예: 로그인이 필요없는 단순 서비스 소개 화면
상태유지의 예: 로그인 (로그인 상태를 서버에 유지)

일반적으로 브라우저 쿠키와 서버 세션등을 사용해 상태 유지(상태 유지는 최소한만 사용)

---

[4] 비 연결성(connectionless)

➡️ 연결을 유지하지 않는 모델: 서버 자원 소모를 막을 수 있다.

비 연결성

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

단점

비 연결성이 단점이 없는 것은 아니다. 이렇게 최소한의 연결을 유지하면 TCP/IP 연결을 새로 맺어야 하는 경우가 자주 생기고 이는 3 way handshake를 수행하는 시간이 추가된다.

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

지금은 HTTP 지속 연결(Persistent Connections)로 해결
HTTP/2, HTTP/3에서 더 많은 최적화

✔️ 초기 HTTP (연결, 종료 낭비)
✔️ HTTP 지속 연결 (Persistent Connections)

---

[5] HTTP 메시지

본격적으로 HTTP 메시지를 알아보자.

시작 라인

start-line = request-line / status-line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

method: GET(리소스 조회), POST(요청 내역 처리), PUT, DELETE ...
request-target: path → absolute-path[?query]
(절대경로란 /로 시작하는 경로를 말함)

상태코드: 200(성공), 400(클라이언트 요청 오류), 500(서버 내부 오류)

HTTP header

header-field = field-name":"(띄어쓰기 불가) OWS(:띄어쓰기 허용) field-value OWS
(field-name은 대소문자 구분 없음)

✔️ HTTP 헤더는 HTTP 전송에 필요한 모든 부가 정보(메시지 바디 내용/크기, 인증, 클라이언트 정보..)들을 담고있다.
표준 헤더가 엄청 많고 필요시 임의의 헤더를 추가할 수 있다.

✔️ HTTP 바디는 실제 전송할 데이터를 담고 있으며 HTML 문서, 이미지, 영상, JSON.. byte로 표현 가능한 모든 데이터를 전송할 수 있다.

📌 정리하자면

• HTTP 메시지에 모든 것을 전송할 수 있으며
• HTTP 역사 HTTP/1.1을 기준으로 학습
• HTTP는 클라이언트-서버 구조이다.
• 또한, 무상태 프로토콜(Stateless)이며
• HTTP 메시지는 헤더, 바디로 이루어져있다.
• 단순하고 확장 가능하다.

---