김영한님의 모든 개발자를 위한 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을 기준으로 학습하자.
