강의 '모든 개발자를 위한 HTTP 웹 기본 지식'를 듣고 학습한 내용을 개인적으로 정리한 글 입니다.
📌 HTTP Hyper Text Transfer Protocol
처음엔 하이퍼텍스트 전송용이지만 현재는
HTML, Texxt
Image, 음성, 영상,파일
JSON, XML (API)
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
지금은 HTTP 시대이다.
심지어 모바일게임에선 HTTP로 송수신하기도 한다.
지금 가장 많이 쓰고있는 것은 HTTP/1.1 이고 HTTP/2 와 HTTP/3은 성능개선에 초점을 맞췄다. HTTP는 단순하다. 메세지도 단순하다.
📌 HTTP 특징
클라이언트 서버 구조
무상태 Protocol(Stateless) / 비연결성
HTTP 메시지
단순하고 확장이 가능하다.
📌 클라이언트 서버 구조
무상태 프로토콜 (스테이스리스)
비연결성
HTTP 메시지
클라이언트, 백엔드 양쪽이 분리됨으로 독립적으로 진화가 가능하다
Request/ Response 구조
클라이언트는 서버에 Request 후 응답을 대기한다.
이후 서버에서는 요청에 대한 결과를 만들어 Response한다.
클라이언트와 서버를 개념적으로 분리하였고 각자 집중고도화가 가능해졌다.
📌 Stateless 무상태프로토콜
서버가 클라이언트의 상태를 보존하지 않는다.
Stateful 은 상태유지인데, Context를 유지해서 이미말한 데이터를 반복해서 전달하지 않아도된다.
Why Use Stateless?
같은 응답서버를 이용하면 이전상태를 보존하는것이 효율적일 수도 있겠다.
하지만 응답서버가 변경된다면?
Context를 모르는 다른 서버가 응답을 하게되면 Stateful은 장애가 발생하게된다.
하지만 상태를 보존하지 않기때문에 모든 데이터를 매번 가지고있는 Stateless 는 어떤 응답서버로 변경되고 추가되어도 장애발생이 없다. 즉, 의사소통에 문제가없다!
따라서 클라이언트가 막 늘어나는 경우에도 무한증설이 가능해진다. * 스케일 아웃 : 수평확장
Stateless에도 한계
알고있는 데이터까지 유지없이 매번 가지고 전달한다. 즉 데이터를 많이 쓴다.
또한, 상태를 유지해야하는 경우
예를 들어 로그인한 회원의 페이지를 회원이 계속 사용할 수 있도록 상태를 유지해야하는 경우가 생긴다면?
이럴경우에는 일반적으로 쿠키와 세션을 이용해 상태를 유지하게된다
단, 상태유지는 최소한만 사용하자. 이런 단점에도 웹 어플리케이션 설계시에는 최대한 무상태로 설계하는 것을 권장한다.
📌 Connectionless 비연결성
TCP/IP는 연결을 유지한다.
HTTP는 기본적으로 비연결성의 특징을 가지고 있다.
연결 주고 받고 통신 끊는다.
서버 유지 자원을 최소화한다.
HTTP는 기본이 연결을 유지하지 않는 모델이다.
일반적으로 초 단위의 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음 (ex 웹 브라우저에서 연속해서 검색 버튼을 누르지는 않는다.)
기본적으로 비연결성 모델인 HTTP가 왜 요즘은 지속연결(Persistent Connections)로 이용되고 있을까?
비연결방식은 사용이 끝나면 매번 연결을 종료하기 때문에
TCP/IP 연결을 새로 맺어야함 3way handshake 시간추가
또한, 웹 브라우저 사이트를 이용할때 HTML만 있는게 아니라 용량이 큰 data나, CSS 등 수많은 자원이 있는데 비연결식으로 이용하게 되면 매번, 매순간 다운로드를 해야한다.
이런 단점때문에 현재의 HTTP는 지속연결 Persistent Connections로 Connectionless의 문제를 해결하고 있다.
HTTP/2, HTTP/3에서 더 많은 최적화가 이루어져 있다.
[##Image|kage@yO5zd/btrwgD04YKT/sr7P4yqRaiWz75WP4w4Wg1/img.png|CDM|1.3|{"originWidth":1056,"originHeight":510,"style":"alignLeft","width":500,"height":241,"filename":"스크린샷 2022-03-18 오전 12.18.18.png"}##
📌 HTTP 메시지
바디 전에 공백 반드시 온다.
시작라인
요청메시지 - HTTP 메서드
종류 : GET, POST, PUT, DELETE ...
서버가 수행해야 할 동작 지정
GET: 리스트 조회
POST: 요청내역처리
요청메시지 - 요청 대상
absolute-path[?query](절대경로[?쿼리])
절대경로="/" 로 시작하는 경로
응답메시지
HTTP 헤더
HTTP 헤더 용도
HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저)정보, 서버 애플리케이션 정보, 캐시 관리 정보
표준 헤더가 너무 많음
필요시 임의의 헤더 추가 가능
메시지 바디 용도
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능
