HTTP 웹 지식 - HTTP 기본

HTTP (HyperText Transfer Protocol)

HTTP 메시지를 통해 모든 것을 담아 전송할 수 있다. TCP를 직접 연결해 전송하는 일은 거의 없다.

HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)

이렇게 거의 모든 형태의 데이터를 전송 가능하고 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다. (게임서버같은 경우만 다를 수 있다.)

HTTP의 역사

HTTP/0.9 : 1991년, GET 메서드만 지원, HTTP 헤더가 없다.
HTTP/1.0 : 1996년, 메서드와 헤더가 추가되었다.
HTTP/1.1 : 1997년, 가장 많이 사용되고 있고 우리에게 가장 중요한 버전
HTTP/2 : 2015년, 성능의 개선 (1.1의 HOL 문제, 무거운 헤더문 해결 등)
HTTP/3 : 진행중, TCP대신 UDP 사용하며 성능의 개선.

HTTP 기반 프로토콜

TCP : HTTP/1.1, HTTP/2
UDP : HTTP/3

현재는 HTTP/1.1을 주로 사용하지만 HTTP/2와 HTTP/3도 증가하는 추세이다.

** 개발자도구 -> Network -> Protocol 보면 h2, h3 등등 보이는데 이것이 HTTP/2, HTTP/3을 의미한다.

HTTP의 특징

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

클라이언트 서버 구조

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

비즈니스 로직, 데이터 등등은 서버에 UI, 사용성같은 부분은 클라이언트 이렇게 구분지어 서로 독립적으로 성장할 수 있게 만들어 진 것이다.

Stateful, Stateless

Stateless. 무상태 프로토콜이란 서버가 클라이언트의 상태를 보존하지 않는 것을 의미한다. Stateful은 이 반대이다.

ex) 고객이 노트북을 2개 산다고 가정해보자.

Stateful이라면 노트북 구매할게요 -> 2개 구매할게요. 이런 흐름으로 무엇을 2개 구매할 지 다시 말하지 않아도 된다.

하지만 Stateless라면 노트북 구매할게요 -> 2개 구매할게요 의 흐름으로 간다면 무엇을 2개 구매하신다는 말이죠? 가 되는 것이다. 노트북 2개 구매할게요 라고 해야된다.

장점 : 서버의 확장성이 높다
단점 : 클라이언트가 추가 데이터를 전송해야 한다.

Stateful

상태가 유지되기 때문에 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려주어야 하는 것.

Stateless

중간에 다른 점원으로 바뀌어도 된다.

갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. -> 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

무한한 서버 증설 가능.

애초에 필요한 정보를 모두 담아 요청하기 때문에 서버가 고장나도 다른 서버로 대체가 가능한 것이다.

Stateless의 실무 한계점

모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
데이터를 너무 많이 보낸다.
무상태
- ex) 로그인이 필요 없는 단순한 서비스 소개 화면
상태 유지
- ex) 로그인

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다. 일반적으로는 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다.

상태유지는 최소한만 사용해야 한다.

비연결성

이렇게 연결을 유지하는 모델은 서버의 자원이 낭비될 수 있다.

HTTP는 기본이 연결을 유지하지 않는 모델이다.
일반적으로 초 단위 이하의 빠른 속도로 응답한다.
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다. 사용자가 계속해서 새로고침을 누른다거나 하지 않기 때문이다. (선착순 할인, 명절 KTX 예약, 수강신청 등은 예외..)
서버의 자원을 효율적으로 사용 가능하다.

비연결성의 한계와 극복

TCP/IP 연결을 계속 새로 맺어야 한다. -> 3 way handshake 시간이 소모된다.
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드 된다. 자원을 받을 때마다 연결하고 끊고 하는 것은 매우 비효율적이다.

현재는 HTTP 지속 연결로 문제를 해결했고 HTTP/2와 /3에서 더 많은 최적화가 이루어 졌다.

HTTP 메시지

(요청 메시지도 바디 가질 수 있음.)

시작 라인(요청)

start-line = request-line(요청) / status-line(응답) 이 있다.
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
request-line = GET (SP) /search?q=hello&hl=ko (SP) HTTP/1.1 (CRLF)

HTTP 메서드

종류 : GET, POST, PUT, DELETE …
서버가 수행해야 할 동작을 지정한다.
ex) GET: 리소스 조회, POST: 요청 내역 처리

요청 대상

절대경로 “/” 로 시작하는 경로 (absolute-path[?query])

시작 라인(응답)

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-line = HTTP/1.1 SP 200 SP OK CRLF

200 = 성공, 400 = 클라이언트 요청 오류, 500 = 서버 내부 오류

reason-phrase : 사람이 이해할 수 있는 짧은 상태 코드 설명 글.

HTTP 헤더

호스트 (요청), 컨텐츠 타입 및 길이 등 (응답) 이 들어 있다.

HTTP 전송에 필요한 모든 부가 정보가 들어 있는 것이다. 필요 시 임의의 헤더를 추가 가능하다.

ex) 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등등…

HTTP 메시지 바디

실제 전송할 데이터로 HTML 문서, 이미지, 영상 등등이 들어간다.

종합

HTTP는 단순하고 확장이 쉽다.