[HTTP]모든 개발자를 위한 HTTP 웹 기본 지식 - 3
👩💻 HTTP 기본
📌 모든 것이 HTTP
✏️HTTP(HyperText Transfer Protocol)란?
: 문서 간의 링크를 통해서 연결할 수 있는 html을 전송하는 프로토콜로 시작하였지만, 현재는 거의 모든 것을 HTTP를 통해 전송한다
"HTTP"로 전송되는 데이터
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSO, XML
- 거의 모든 형태의 데이터 전송 가능
- 서버 간에 데이터를 주고받을 때도 대부분 HTTP 사용
- HTTP/1.1 버전을 가장 많이 사용하며, 중요한 버전이다
"특징"
- 클라이언트 서버 구조
- 무상태 프로토콜(stateless), 비연결성
- HTTP 메세지
- 단순함, 확장 가능
📌 클라이언트 서버 구조
✏️클라이언트 서버 구조
- Request Response 구조이다.
- 클라이언트가 Request를 보내면 서버가 Response를 할 때까지 기다렸다가 응답을 받고 동작한다.
- 클라이언트는 서버에 요청을 보내고, 서버에서 오는 응답을 대기한다.(서버는 응답이 올 때 까지 무작정 대기한다 그냥)
- 서버가 요청에 대한 결과를 만들어서 응답한다
- 여기서 중요한 것은 클라이언트와 서버는 개념적으로 분리된다는 것이다. 비즈니스 로직, 서비스 등은 서버에 다 밀어 넣고 클라이언트는 UI와 사용성에 집중한다.
📌 무상태 프로토콜
✏️무상태 프로토콜(스테이스리스)란?
:스테이스리스(stateless) = 서버가 클라이언트의 상태를 보존하지 않는다
- 서버가 클라이언트의 상태를 보존하지 않는다.
- 장점으론 서버 확장성이 높고, 단점으로는 클라이언트가 추가 데이터를 전송해야 한다.
✏️Stateful과 Stateless의 차이
1. Stateful(상태유지)
:Stateful이란, 서버가 클라이언트의 이전 상태를 보존하는 것을 말한다.(문맥을 보존한다.)
마지막 3번째 사진을 보자. 클라이언트의 상태를 계속 유지하고 있다.
2. Stateless(무상태)
:Stateful이란, 서버가 클라이언트의 이전 상태를 보존하지 않는 것을 말한다.
stateful(상태유지)에서는 점원이 바뀌면 장애가 발생하였지만, stateless(무상태)는 점원이 바뀌어도 고객이 필요한 데이터를 그때그때 다 넘기기 때문에 중간에 점원이 바뀌어도 문제가 발생하지 않는다.
3. 정리
- Stateful: 중간에 점원이 바뀌어선 안된다.(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려주어야 함)
- Stateless: 중간에 다른 점원으로 바뀌어도 된다.(고객이 필요한 데이터를 그때그때 다 넘기기 때문)
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.( = 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.)
- 무상태는 응답 서버를 쉽게 바꿀 수 있다 --> "무한한 서버 증설 가능"
✏️Stateless의 한계
:하지만 Stateless에도 실무 한계가 존재한다.
- 데이터 전송량이 많다. (필요한 데이터를 다 보내버리기 때문에)
- 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 존재한다.
- 무상태
- (ex) 로그인이 필요 없는 단순한 서비스 소개 화면
- 상태유지
- (ex) 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지해야 한다 (로그인 유지)
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다.
- 상태 유지는 최소한만 사용한다.
📌 비 연결성(connectionless)
✏️비 연결성(connectionlss)란?
: TCP/IP를 연결하여 요청과 응답을 끝내면 서버와 클라이언트의 연결을 즉시 끝내버린다.
- HTTP는 기본이 연결을 유지하지 않는 모델이다.
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청을 수십 개 이하로 매우 작다.
- (Ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다. (검색하고 한참보고 또 검색하고...)
- 서버 자원을 매우 효율적으로 사용할 수 있다.
- 왼쪽 그림의 경우, 연결을 계속 유지하는 모델이어서 클라이언트 1,2,3이 각각 요청을 보내고 응답을 받은 뒤에도 연결을 끊지 않는다. 즉, 클라이언트 1이 TCP/IP연결을 통해 요청과 응답을 할 때 클라이언트 2,3이 아무것도 안 하고 놀고 있는 상태여도 연결되는 것이다.
- 서버 연결 계속 유지
- 서버 자원 소모
- 오른쪽 두 개 그림의 경우, 클라이언트 1이 TCP/IP 연결을 통해 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어버린다.
- 서버 연결 계속 유지 X
- 최소한의 자원 유지 (클라이언트가 3대가 아니라 수 만대라고 생각했을 때 최소한의 자원을 유지할 수 있다)
✏️비 연결성(connectionlss)의 한계
:비 연결성의 한계와 극복
📌 HTTP 메시지
✏️HTTP 메시지란?
: 문서 간의 링크를 통해서 연결할 수 있는 데이터를 보내는 프로토콜
1. HTTP 메시지의 두가지 종류(요청, 응답)
2. HTTP 메세지의 구조
:HTTP 메세지의 구조에 대해 알아보자.
- start-line(시작라인
- header(헤더)
- empty lien(공백 라인 - 무조건 써야 함)
- message body start-line(시작라인)
1.start-line(시작라인)
- 시작라인은 "request-line(요청라인)"과 "status-line(응답라인)"으로 되어있다.
- "request-line"구조
- method SP(공백(GET, POST 등)) request-target SP(요청 대상) HTTP -version(HTTP버전) CRLF(엔터)
- HTTP method = GET, POST, PUT, DELETE...
- 서버가 수행해야 할 동작을 지정한다
- GET: 리소스 조회
- POST: 요청 내역 처리
- 요청 대상 = (/search? q=hello&hl=ko)
- absolut-path [? query] (절대경로[? 쿼리])
- 절대경로란 = "/"로 시작하는 경로
- HTTP Version = HTTP 버전
- "statue-line"구조
- status-line = HTTP-version Sp(HTTP버전) status-code SP(HTTP 상태코드) reason-phrase CRLF
- HTTP-version = HTTP 버전
- HTTP 상태 코드: 요청 성공, 실패를 나타냄
- 200 = 성공, 400 = 클라이언트 요청 오류, 500 = 서버 내부 오류
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 설명 글 (400이면 클라이언트 요청 오류등을 알 수 있음)
- "request-line"구조
2. header(헤더)
- header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
- field-name은 대소문자 구문 없음
- header(헤더)의 용도
- HTTP 전송에 필요한 모든 부가정보가 들어가 있다.
- (ex) 메시지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트 정보 등등..
- 메시지 바디빼고 필요한 메타 정보가 모두 들어가있다고 생각하면 된다.
3.HTTP 메세지 바디
- 실제 전송할 데이터
- (ex) HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
