HTTP란?
-
Hypertext Transfer Protocol
Hypertext html: 문서 간의 링크를 통해서 연결할 수 있는 HyperText 문서를 통해서연결할 수 있는 html을 전송하는 프로토콜로 시작이 되었다. -
그런데 지금은 모든 것을 HTTP protocol에 담아서 전송한다.
HTML, TEXT, Image, 음성, 영상, 파일, JSON, XML...etc 거의 모든 형태의 데이터를 전송할 수 있다.
version
- HTTP/0.9: Get method만 지원, HTTP 헤더 X
- HTTP/1.0: 메서드, 헤더 추가
- HTTP/1.1: 가장 많이 사용
- RFC2068 -> RFC2616 -> RFC7230~7235
- HTTP/2: 성능개선
- HTTP/3: TCP대신에 UDP 사용, 성능 개선(3-way handshake, 데이터도 너무 많아지고 -> 속도가 빠른 메커니즘이 아니다. 그래서 UDP 프로토콜 위에 그냥 어플리케이션 레벨에서 성능을 최적화하도록 설계해서 나온것이다.)
기반 프로토콜
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- 현재 HTTP/1.1 주로 사용
- HTTP/2, HTTP/3 도 점점 증가
-
보면 h2가 http 2이고 인프런은 없는데 구글에서 구글링을 하다보면 http3도 가끔 보인다.
-
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(stateless), 비연결성
- HTTP message
- 단순함, 확장 가능
클라이언트 서버 구조
- req, res 구조
- 클라이언트는 서버에 요청을 보내고 응답을 대기(pending)
- 서버가 요청에 대한 결과를 만들어서 응답
- 클라이언트와 서버를 분리했다는 것이 중요하다.
서버에는 비즈니스 로직과 데이터를 넣고 클라이언트에는 UI/UX에 집중한다.
이는 각각 독립적으로 진화를 할 수 있다.
Stateful, Stateless
Stateless
- 무상태 프로토콜로 HTTP는 무상태 프로토콜을 지향한다.
- Stateless란 서버가 클라이언트의 상태를 보존하지 않는다는 것이다.
장점: 서버 확장성 높음(scale out)
단점: 클라이언트가 추가 데이터 전송
상태, 무상태
- 상태와 무상태는 무엇일까?
바로 상태는 앞선 context들이 있다고 가정하고 대화하는 것
무상태는 앞선 context들이 없다고 가정하고 대화하는 것이다.
상태 유지
무상태
- 이는 굉장히 큰 차이점을 보이는데 이렇게 무상태로 설계를 하면 클라이언트 서버 아키텍처에서는 엄청난 확장성을 가져온다.
Stateless와 Stateful의 차이
-
결국은 stateful은 중간에 다른 점원으로 바뀌면 대화가 안 된다.
다만, 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야한다. -
무상태 중간에 다른 점원으로 바뀌어도 된다.
갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
==갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. -
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능
잘 이해가 가지 않는다면 아래 그림을 보자.
- 클라이언트와 대화를 하기위해 1개 서버를 잡고 얘가 계속해서 응답을 해줘야한다.
그리고 만약 서버 1이 갑자기 죽는다면 클라이언트는 처음주서 state를 다시 쌓아야한다.
-
반면 무상태라면 클라이언트에 정보를 다 갖고있기 때문에 서버를 다른걸로 바꾸어도 아무 문제가 되지 않는다.
-
그리고 이 서버를 수평확장 즉, scale out할 때 용이하다.
Stateless의 한계
-
모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
무상태: 로그인이 필요없는 단순한 소개화면
상태 유지: 로그인 -
로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
-
상태 유지는 최소한만 사용
-
클라이언트에서 보내는 정보의 양이 많아짐.
웹 어플리케이션을 설계할 땐 최대한 무상태로 설계하고
최소한의 상태유지를 유지한다.
비연결성(connectionless)
- 만약 클라이언트와 서버가 연결을 유지한다고 생각해보자. 그럼 클라이언트 1,2는 아무것도 안 해도 서버는 계쏙해서 연결을 해야하기 때문에 서버 자원을 계속해서 소모해야한다.
- 반면 이렇게 연결을 끊어주면 서버는 최소한의 자원을 유지할 수 있다.
HTTP의 비연결성
-
HTTP는 기본적으로 비연결성이다.
왜냐하면 사용자가 많이 사용한다고 해도 동시에 수많은 요청이 들어오는 경우는 극히 드물기 때문이다. 그래서 요청을 짧고 빠르게 치고 빠지는것이 더 유리하다. -
즉, 누군가가 검색을 해서 문서를 보고 또 한참후에 검색을 하고 이렇게 하기 때문에 아무것도 하지 않을 때 연결을 끊어서 서버의 자원을 최소한으로 유지하는 것이 유리하는 것이다.
한계
- 그럼 당연 한계가 명확하게 보인다.
- TCP/IP를 새로 맺어야함 -> 3-way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, css, image등 수많은 자원이 함께 다운로드됨
- 이렇게 하면 연결, 종료가 낭비된다.
극복
- 지금은 HTTP 지속연결(persistent connections)로 문제해결
HTTP/2, HTTP/3에서 더 많은 최적화
- 한 번 연결되었을 때 잠깐 지속연결을 하여 한 큐에 다 req, res를 하고 연결을 끊는 것이다.
HTTP message
- 이때 공백 라인이 반드시 있어야한다.
- 위 사진은 공식 스펙이 올라와있는 HTTP message 구조로 가운에 message-body는 있어도 되고 없어도 된다는 뜻이다.
시작 라인
요청 메시지
- start-line = request-line
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
HTTP 메서드 (GET:조회)
요청대상 (/search?q=hello&hl=ko)
- 절대경로[?쿼리]
HTTP version
응답 메시지
- start-line = status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP version
Status code
- 200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류
이유 문구
- 사람이 이해할 수 있는 짧은 상태 코드 설명 글
Header
- header-field = field-name: OWS filed-value OWS (OWS:띄어쓰기 허용)
- field-name은 대소문자 구분 없음
- 이때 위 사진을 보면 알 수 있듯 field-name과 ":"은 붙어있어야한다.
용도
- HTTP 전송에 필요하나 모든 부가 정보가 다 들어있다.
- 예를들어 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트의 브라우저 정보, 서버 어플리케이션 정보, 캐시 관리정보 등등...
- 표준 스펙으로 올라와있는 헤더가 엄청 많다.
- 필요시 임의의 헤더 추가 가능 (약속된 서버와 클라이언트여야 임의의 헤더를 이해할 수 있음.)
