Chapter3. HTTP

Date: 2021.12.27 Updated: 2021.12.27

카테고리: Network

태그: HTTP CS

인프런에 있는 김영한님의 모든 개발자를 위한 HTTP웹 기본 지식 강의를 듣고 정리한 내용입니다.
중간에 등장하는 ppt 내용들은 모두 강의자료를 캡처한 것입니다.

✈️ HTTP란?

HTML (HyperText Transfer Protocol) 은 HTML, Text를 전송하기 위해 만들어졌다.
현재에는 텍스트파일뿐 아니라 이미지, 음성, 영상, 파일, JSON과 XML(API) 등 거의 모든 형태의 데이터 전송이 가능하다. 또한 서버 간 데이터를 전송할 때도 대부분 HTTP를 사용한다.

HTTP 버전

이전 버전들…

HTTP/1.1 1997년 : 현재 사용하는 기능의 대부분이 들어있음. 가장 많이 사용하는 버전이다.
(HTTP 1.1의 최신 버전은 RFC 7230~7235로 2014년에 업데이트되었다. 옛날 버전 정보와 책이 많다고 한다.)
HTTP/2 2015년 : 성능 개선
HTTP/3 진행 중 : TCP 대신 UDP 사용. 성능 개선

HTTP/2, HTTP/3도 점점 증가하는 추세라고 한다.

✈️ HTML 특징

클라이언트 서버 구조
Stateless 지향
비연결성
메시지 구조

클라이언트 서버 구조

ch3 0

HTTP 통신은 기본적으로 클라이언트와 서버가 서로 요청, 응답하는 구조이다. 이런 식으로 역할을 나누면 클라이언트와 서버가 독립적으로 진화할 수 있다. 클라이언트는 데이터 로직이나 트래픽을 신경쓰지 않고 UI/UX 개발에 집중할 수 있고, 서버는 UI/UX에 상관 없이 서버를 늘리거나, 비지니스 로직을 수정할 수 있다.

무상태 프로토콜(Stateless Protocol) 지향

Stateful vs Stateless

우선 Stateless(무상태) 와 Stateful(상태 유지)가 무엇인지 알아보기 위해 다음 상황을 살펴보자.

Stateful	Stateless
- 고객: 이 노트북 얼마인가요? - 점원: 100만원 입니다.	- 고객: 이 노트북 얼마인가요? - 점원: 100만원 입니다.
- 고객: 2개 구매하겠습니다. - 점원: 200만원 입니다. 결제 도와드리겠습니다.	- 고객: 2개 구매하겠습니다. - 점원: 네? 무엇을 2개 구매한다는 것인가요?

쉽게 말해 Stateless는 서버가 클라이언트의 상태를 보존하지 않는다는 의미이다. 이런 방식으로 작동하면 클라이언트가 추가 데이터를 보내야한다는 단점이 있다. (ex. 노트북 얼마인가요? -> 노트북 2개 구매하겠습니다. -> 현금으로 노트북 2개 구매하겠습니다)
하지만 서버 확장성 측면에서는 엄청난 강점을 지니고 있다.

ch3 1

Stateless 상황에서는 중간에 점원이 교체되어도 아무 문제가 없다. 즉, 내가 통신하고있는 서버에 장애가 발생해도 다른 아무 서버를 연결하면 그만이다.

ch3 2

중간에 점원을 교체해도 문제가 없다는 뜻은 갑자기 고객이 증가해도 점원을 추가로 투입하기 쉽다는 뜻이다. 즉, 갑자기 클라이언트의 요청이 증가해도 응답 서버의 서버 증설이 간단한 편이다.

Stateless 한계

로그인이 필요없는 단순한 페이지의 경우 이상적인 Stateless Protocol이 가능하다. 하지만 대부분의 경우 사용자의 로그인 정보 같은 필수적으로 유지해야 하는 정보가 존재한다. 일반적으로 쿠키와 서버 세션등을 통해 최소한의 정보들을 상태유지하는데 이는 뒤에서 자세히 살펴보도록 하자.

비연결성(Connectionless)

수천명의 사용자가 사용하는 서비스가 있다고 생각해보자. 이때 서버가 동시에 처리하는 요청을 얼마나 될까? (보통 초 단위 이하의 빠른 속도로 응답한다.) 실제로는 수십개 이하로 매우 작다고 한다. 따라서 서버가 수천명의 클라이언트와 통신을 유지하고 있는 것은 매우 비효율적이다. 요청이 들어오면 그때그때 연결하고 끊어버리는 것이 훨씬 효율적이지 않겠는가?

HTTP 통신은 기본적으로 응답을 하고나면 연결을 끊는 비연결성 모델이다.

비연결성 한계

ch3 3

클라이언트가 서버에 html 페이지를 요청하고 응답 받았다고 가정해보자.

클라이언트가 페이지 요청 -> 연결 -> 연결 해제
어? 렌더링하는데 서버에 있는 css파일이 필요하네? -> 다시 연결 -> 연결 해제
어? 서버에서 이미지파일을 받아와야 하네? -> 다시 연결 -> 연결 해제

앞에서 봤다시피 TCP/IP 연결을 새로 맺을 때마다 번거로운 3 way handshake 과정이 필요하다. 이 때문에 적절한 기간 동안 (ex. 렌더링이 끝날 때까지) 연결을 유지하는 HTTP Persistent Connections(지속 연결) 로 문제를 해결한다. 또한 HTTP/2, HTTP/3에서는 UDP를 통하는 등 더 많은 최적화가 진행 중이다.

TMI

백엔드 개발자들이 가장 두려워하는 상황은 티켓예매나 수강신청처럼 동시에 대용량 트래픽이 발생하는 상황이라고 한다. HTTP의 특징을 공부하니 왜 까다로워하는지 조금은 이해가 간다.

✈️ HTTP 메시지

ch3 5

HTTP 메시지의 구조는 크게 시작라인, 헤더, 바디로 구성돼있다. HTTP Methods, 상태 코드, 표준 헤더 등 자세한 내용은 뒤에서 다시 다루니 지금은 대략적인 구조만 살펴보자.

HTTP 시작 라인

시작라인 - 요청

ch3 6

HTTP Method (ex. GET: 조회)
요청 대상 : 절대경로(/search) + ?쿼리(?q=hello&hl=ko)
HTTP 버전 (ex. HTTP/1.1)

시작라인 - 응답

ch3 7

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

HTTP 헤더

ch3 8

HTTP 전송에 필요한 부가정보.
바디의 파일형식, 크기, 인코딩 방식, 인증, 캐시 정보, 등등…
표준 헤더는 무수히 많음. 필요시 임의의 헤더 추가 가능

HTTP 메시지 바디

ch3 9

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

맨 위로 이동하기

등딱지빌런