HTTP

바그다드·2023년 3월 7일

HyperText Transfer Protocol
HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 레이어 프로토콜

HTML, TEXT, image, 영상, 파일 json, xml 등등 거의 모든 형태의 데이터 전송 가능
서버간 데이터를 주고 받을 때도 대부분 http를 사용

HTTP 역사

HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X

HTTP/1.0 1996년: 메서드, 헤더 추가

HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

HTTP/2 2015년: 성능 개선

HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

TPC는 주로 HTTP/1.1, HTTP/2를 사용
UDP는 주로 HTTP/3에서 사용

HTTP 특징

1. 클라이언트 - 서버 구조

1. 클라이언트가 서버에 요청을 보내고 대기
2. 서버가 요청에 대한 결과를 만들어 응답
* 클라이언트는 UI/UX에 집중을 하고 서버는 비즈니스 로직에 집중을 할 수 있음

2. 무상태 프로토콜(stateless)

Stateful

항상 같은 서버가 유지되어야 함
중간에 서버가 바뀌거나 장애가 발생하면 여태 서버가 가지고 있던 컨텍스트가 사라지게 됨

Stateless

아무 서버나 호출해도 됨
서버 증설이 용이함
- 스케일 아웃(수평 확장)에 용이함
클라이언트가 추가 데이터를 전송해야 한다는 단점이 있음

Stateless의 한계

로그인 같은 상태 유지가 필요한 기능의 경우 상태를 서버에 유지해야함
- 일반적으로 쿠키와 세션을 활용해서 상태를 유지함
하지만 상태 유지는 최소한만 사용

스테이스리스를 기억하자!

명절 KTX예약이나 수강 신청 등의 경우 수백 수천 수만명이 동시 요청을 진행하기 때문에
최대한 stateless를 유지할 수 있도록 고민해야 한다.

3. 비연결성

연결을 유지하는 경우

클라이언트2와 3은 놀고 있는데도 연결이 유지되어 서버 자원을 소모하게 됨

비연결

연결을 유지하지 않는 모델
사용자가 아무리 많더라도 초단위로 나눠보면 서버에서 동시에 처리하는 요청은 매우 적음

비연결의 한계

요청을 할 때마다 연결을 새로 해야함 - 3way handshake 시간 소모
이 때 HTML,css,js등 수많은 자원이 다운로드 됨

HTTP 지속 연결

왼쪽의 경우 연결과 종료로 인해 오히려 필요 없는 시간이 발생
오른쪽의 그림처럼 HTTP지속 연결을 통해 모든 자원을 받을 동안 연결을 유지해 효율성을 높임

HTTP 메세지

1. 시작 라인

요청 메시지의 경우

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
method : 요청할 행동
- 서버가 수행해야 할 동작
- get, post, put, delete등
request-target : 요청 대상
- absolute-path[?query]
- 절대 경로(절대경로[?쿼리]) : "/"로 시작하는 경로
HTTP-version : HTTP버전

응답 메세지의 경우

status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP-version : HTTP 버전
status-code : 상태 코드
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류
reason-phrase : 사람이 이해할 수 있는 짧은 상태 코드 설명글

2. HTTP 헤더

HTTP 전송에 필요한 모든 부가 정보 또는 메타 데이터
표준 헤더가 많음
필요에 따라 새로운 헤더를 추가할 수 있으나,
이 헤더는 해당 클라이언트와 서버 사이에서만 사용 가능
메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증,
요청 클라이언트(브라우저) 정보,서버 애플리케이션 정보, 캐시 관리 정보 등등이 들어있음