김영한님의 모든 개발자를 위한 HTTP웹 기본지식 강의를 듣고 요약했습니다.

지금은 HTTP 시대

HTML 문서를 연결하는 프로토콜로 시작했다.
HTML, IMAGE, 음성, 영상, 파일, JSON ... 모두 HTTP 를 쓴다.
서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP 역사

HTTP 1.1 에 대해 공부하는 것이 중요하다.
대부분의 기능과 내용이 1.1에 있기 때문이다. 2와 3은 성능 개선 관련이고 상대적으로 내용이 적다.

HTTP 1.1 - 가장 많이 사용, 우리에게 가장 중요한 버전
HTTP 2 - 2015 성능 개선
HTTP 3 - 성능 개선을 위해 TCP 대신에 UDP 사용

HTTP의 기반 프로토콜

TCP기반으로 동작: HTTP/1.1, HTTP/2
UDP기반으로 동작: HTTP/3

현재 HTTP 1.1 을 주로 사용하고 있지만, HTTP2, 3도 점점 늘어나고 있다.

HTTP 특징

4가지 특징에 대해 이해해보자.

• 클라이언트 서버 구조

• 무상태 프로토콜(stateless)
• 비연결성
• HTTP 메시지로 요청/응답

클라이언트 서버 구조

클라이언트와 서버를 분리하는 것이 매우 중요하다. (예전에는 안그랬다)

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

클라이언트와 서버를 분리하는 것의 장점?

비즈니스 로직과 데이터를 전부 서버가 관리한다.
클라이언트는 UI와 사용성에 집중할 수 있다.
클라이언트가 PC만 서비스 하다가 Phone 이 필요해지면, application에 필요한 UI를 새로 만드는 것에 집중하면 된다. 클라이언트가 비즈니스 로직을 고민할 필요 없다.

클라이언트/서버가 분리된 구조를 통해 각각 독립적으로 진화할 수 있다는 것이 장점이다.

무상태 :stateless

서버가 클라이언트의 상태를 보존하지 않는다.
컨텍스트(context)를 모른다.

상태유지 무상태 이해를 위한 예시

고객이 물건을 구매할 때 점원과 대화하는 상황을 상상해보자.
고객은 클라이언트이고, 점원은 HTTP 서버 역할과 같다.

상태유지(stateful) 예시

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

고객 "2개 구매할께요."
점원A **"200만원 입니다. 신용카드, 현금 중에 어떤 걸로 결제하시나요?" **

-> 점원이 상황의 문맥(context)를 알고 있다.
따라서 점원은 100만원 x 2개 = "200만원 입니다." 라고 대답해줄 수 있다.

무상태(stateless) 예시

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

고객 "2개 구매할께요."
점원B **" ?? 무엇을 2개 구매하시겠어요? " **

-> 점원이 상황의 문맥(context)을 모른다.
무상태라면, 고객이 요청할 때마다 새로운 점원이 고객을 응대하는 것과 같다.

[중요]stateful과 stateless 차이

상태유지

• 중간에 다른 점원으로 바뀌면 안된다.
• 항상 같은 서버가 유지되어야 한다.
• 클라이언트 A는 계속 서버1과 통신해야 한다.

무상태

• 서버가 장애가 나면? 중간에 다른 점원(서버)으로 바뀌어도 된다.
• 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
• 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무상태의 강점은 서버1이 장애 나도 서버2가 대신 응답해줄 수 있다는 것이다.
서버가 클라이언트의 상태를 저장하지 않기 때문이다.
스케일 아웃 즉, 수평 확장에 유리하다.

[중요] stateless의 실무 한계

모든 것을 무상태로 설계 할 수도 있는 경우도 있고 없는 경우도 있다.

• 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면
• 상태유지: 로그인한 사용자의 경우.

    결제 과정이 필요하는 경우. 
    **브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지한다. **

무상태와 상태유지는 전송 데이터의 양에 차이가 있다.
상태 유지 시, 데이터의 양이 더 적을 수 있다.

따라서 ‘상태 유지’는 최소한만 사용해서 개발하자.

무상태(stateless)는 데이터 전송량이 좀 더 많다.
애플리케이션 설계 시, 되도록이면 무상태로 설계하는 것이 좋다.

비연결성

HTTP는 기본이 연결을 유지하지 않는 모델이다.
일반적으로 초 단위 이하의 빠른 속도로 응답한다.

연결을 유지하면?

클라이언트가 서버와 연결 유지하면 계속 서버가 자원을 소모하고 있게 된다.

연결을 유지하지 않으면?

요청/응답 만 하고, 연결을 끊어버려서 최소한의 자원만 사용한다.

비 연결성의 한계와 극복

1. 비연결성 이라면, 요청을 보낼 때 마다 TCP/IP 연결을 새로 맺어야 한다.

-> 3 way handshake 시간 추가된다.
사용자 입장에서는 시간이 단점이 된다.

2. 웹브라우저로 사이트를 요청하면 다운로드 받을 것이 많다.

HTML 뿐만 아니라 자바스크립트, css, image 등 많은 자원이 함께 다운로드 된다.

지금은 HTTP 지속 연결로 문제 해결

이전에는 HTML 응답, 이미지 응답, Javascript 응답.. 각각 연결해야 했었다.
하나의 페이지에는 HTML 말고도 이미지도 있고 여러개가 있는데, 하나 받을 때 마다 새로운 연결을 요청해야 했다.

이제는 Persistent connections 라는 지속 연결로 문제를 해결하고 있다.
한 번 연결이 되면, HTML와 이미지 여러개 등의 다운로드를 할 만큼의 시간동안 연결이 유지된다.
http/2, http/3에서 더 많은 최적화되고 있다.

stateless 를 기억하자

서버 개발자들이 가장 어려워하는 업무가 뭘까?

같은 시간에(일제히) 딱 맞추어 발생하는 대용량 트래픽에 대응하는 것이다.
ex) 명절 KTX예약, 수강신청, 선착순 이벤트

이것만 기억하자. "최대한 stateless 로 설계하자"
어떻게든 머리를 쥐어짜서 stateless로 설계해야 대응할 수 있다!

HTTP 메시지

요청 메시지와 응답 메시지 구조의 차이를 이해하자.

Request 요청 메시지

요청, URL, version
body 본문을 가질 수 있다.

HTTP 요청한것
헤더값
공백라인 CRLF
응답메시지

요청메시지에서 시작라인

start-line은 요청이냐 응답이냐에 따라 다르다.

요청메시지에서 시작라인은 request-line
응답메시지에서 시작라인은 status-line

요청메시지는 request-line이라고 한다.
request-line: method SP(공백) request-target SP. HTTP-version

(여기서 SP는 스페이스 라는 뜻이다. )

http 메서드 : 서버가 수행해야 할 동작 지정
종류 : GET, POST, PUT, DELETE…
GET: 리소스 조회
POST: 요청 내역 처리

요청대상 : 절대경로로 시작한다.
요청대상: 절대경로 “/“로 시작하는 경로

응답메시지의 시작라인

응답메시지의 시작라인은 status-line으로 되어 있다.

status-line 구성

HTTP-version SP
status-code SP
reason-phrase CRLF

(여기서 SP는 스페이스 라는 뜻이다. )

HTTP version: HTTP 1.1 / 2/3

HTTP 상태코드 : 요청의 결과를 의미한다.

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

HTTP 헤더

header-field: field-name:OWS
(OWS: 띄어쓰기 허용 )

HTTP 전송에 필요한 모든 부가정보를 포함한다.
HTTP 1.1을 기준으로 학습하자.

읽을 거리 :
MDN HTTP 개요