HTTP 기본

목차
- 모든 것이 HTTP
- 클라이언트 서버 구조
- Stateful, Stateless
- 비연결성
- HTTP 메시지

HTTP

(= Hyper Text Transfer Protocol)

 

- 모든 형태의 데이터를 전송할 수 있다. (HTML, TEXT, IMAGE, 음성, 영상, JSON, XML 등) 

- 서버 간의 데이터를 주고 받을 때도 대부분 HTTP 사용

 

지금은 소녀시대 .. 가 아니고 HTTP 시대 !! 

 

HTTP 역사

현재 가장 많이 사용하고 있는 버전은 HTTP/1.1 이다.

(= 우리에게 가장 중요한 버전 / != 가장 최신 버전은 아니다.)

 

기반 프로토콜

TCP > HTTP/1.1, HTTP/2

UDP > HTTP/3

 

🤔 TCP가 더 안정적이고 좋은 것 아닌가?

TCP는 기본적인 메커니즘이 속도가 빠르지 않음, 이에 UDP에서 성능 최적화를 해서 만든 것이 HTTP/3임 

(HTTP/1.1에서 성능 버전 업 한것이 2, 3이므로 1.1만 제대로 알아도 된다 !!)

 

HTTP 특징

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

 

---

특징 1. 클라이언트-서버 구조

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

...

당연한 것 아님? 이라고 생각할 수 있는데,

 

🟢 중요한 것은 서버와 클라이언트를 분리했다는 것 !!

• 서버 > (복잡한)비즈니스 로직, 데이터 
• 클라이언트 > 사용성/UI에 집중 

-> 서버와 클라이언트가 각각 독립적으로 진화할 수 있음 !!! 

 

---

특징 2. 무상태 프로토콜 (Stateless)

뭔소리임? ㅇㅋㅇㅋ.

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

 

Stateful VS Stateless
Stateless하지 않다는 것은 Stateful하다는 것을 의미

예) 물건을 구매하려고 할 때 중간에 점원이 중간에 바뀌는 경우
Stateful > 상태를 유지하고 있음, 노트북 2개를 구매하고 싶다는 상태를 유지 + 신용카드 상태 유지 -> 이게 상태를 유지하는 것 
Stateless > 상태를 유지하지 않음, 점원은 고객의 상태를 유지하지 않고 고객이 먼저 말해줌 

Stateful 상태에서 중간에 점원이 바뀌면?
서비스 입장에서는 오류 또는 장애가 날 수 있다. (문맥/Context가 사라진다.)

그러나, Stateless 상태에서는?
고객이 먼저 원하는 정보를 다 먼저 제시하기 때문에 오류가 날 수 없다.

 

정리하자면,

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

 

🔴 단점

그러나, 한계가 존재. (제발 .. 하나로 해줘 하나로 .. ㅈㅅ.)

실무적인 한계가 무엇이냐면 !!

• 모든 것을 무상태로 설계할 수 없다는 것
  • 예를 들면, 로그인이 필요 없는 단순한 서비스 소개 화면 > 무상태로 설계하기 쉽다.
• 상태를 유지해야하는 경우가 무엇이 있는가?
  • 로그인 
  • 로그인 한 사용자의 경우 로그인 했다는 상태를 서버에 유지 
  • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지 
• 상태 유지는 최소한의 경우에만 사용 
• 전송되는 데이터가 많다. 

실무적인 한계, 단점 등이 있음에도 상태 유지는 최소한의 경우에만 사용해야 하고,
무상태성을 지향하는 것이 좋다.

---

 

특징 3. 비연결성 (Connectionless)

만약 계속 연결을 하고 있다면?

클라이언트가 일을 하고 있지 않음에도 불구하고 연결을 하고 있기 때문에 서버의 자원이 낭비 된다.

 

연결을 유지하지 않는다면?

클라이언트-서버의 할 일이 다 끝났다면 바로 연결을 해제 > 연결을 유지하지 않기 때문에 최소한의 자원을 유지한다. 

(최소한의 자원으로 서버을 유지할 수 있다.)

 

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

 

🔴 단점

• TCP/IP 연결을 새로 맺어야 한다. > 3 way handshake 시간 추가 
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라, 자바 스크립트/CSS/추가이미지 등 수많은 자원이 함께 다운로드

🔵 근데 해결할 수 있다.

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

왼) 초기 -> 오) 현재

Stateless를 기억하자.
서버 개발자들이 어려워하는 업무. 어떻게든 머리를 쥐어짜서 만들어라. 
예) 서버를 좀 제대로 구축하고 콘서트를 열어. 제발.

 

---

특징 4. HTTP 메시지 

remind - 모든 것이 HTTP입니다.

요청 메시지와 응답 메세지가 구조가 조금 다르다.

 

HTTP 메시지 구조

 

시작 라인

➡️ 요청 메시지 

HTTP 메서드 + 절대 경로 + HTTP 버전 

 

➡️ 응답 메시지 

HTTP 버전 + HTTP 상태 코드 + 이유 문구 

• HTTP 버전
• HTTP 상태 코드
  • 200 : 성공
  • 400 : 클라이언트 요청 오류
  • 500 : 서버 내부 오류
• 이유 문구 
  • 사람이 이해할 수 있는 짧은 상태 코드 설명 글 

 

HTTP 헤더

• HTTP 전송에 필요한 모든 부가정보
  • 메시지 바디 내용, 메시지 바디의 크기, .. 등 ..
• 표준 헤더 많음 ..
• 필요시 임의의 헤더 추가 가능 

 

HTTP 메시지 바디

실제 전송할 데이터

 

어떤 데이터가 전송가능한가?

HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능 

 

---

특징 5. 단순함, 확장 가능 

HTTP는 단순하다 !!

HTTP 메시지도 단순 !!

 

💨 HTTP 정리
- HTTP 메시지에 모든 것을 전송
- HTTP/1.1을 기준으로 학습
- 특징 1. 클라이언트-서버 구조
- 특징 2. 무상태 프로토콜
- 특징 4. HTTP 메시지
- 특징 5. 단순함, 확장 가능

...
지금은 HTTP 시대 !!