목표 : HTTP의 특징에 대해서 알아보자.
모든 것이 HTTP(HyperText Transfer Protocol)
- 모든 것을 HTTP 프로토콜에 담아서 전송할 수 있다.
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML(API)
.... 등등 거의 모든 형태의 데이터 전송 가능. 서버 간에 데이터를 주고받을 때도 대부분 HTTP 사용
HTTP의 역사
- HTTP/0.9 : GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 : 메서드, 헤더 추가
- HTTP/1.1 : 가장 많이 사용, 우리에게 가장 중요한 버전
- HTTP/2 : 성능 개선
- HTTP/3 : TCP 대신에 UDP 사용, 성능 개선
기반 프로토콜
- TCP : HTTP/1.1, HTTP/2
- UDP : HTTP/3
- 현재 HTTP/1.1 주로 사용
HTTP 특징
- 클라이언트 서버 구조 --> HTTP 프로토콜은 기본적으로 이 구조를 바탕으로 동작한다.
- 무상태 프로토콜(Stateless)
- 비연결성(Connectionless)
- HTTP 메시지를 통해서 통신한다
- 단순하고 서버 확장이 용이하다.
1) 클라이언트 서버 구조
- 어떻게 보면 당연할 수 있지만, 윗 그림처럼 서버와 클라이언트를 분리하는 것이 중요하다.
- 비즈니스 로직, 데이터 처리 코드는 전부 서버 쪽에서 처리하도록 설계를 한다.
- 클라이언트 쪽은 UI, 사용성에 집중한다.
클라이언트와 서버, 양쪽이 독립적으로 발달하게 된다.
또한, 서버의 구조적 변경이 있더라도 클라이언트는 신경 쓰지 않아도 된다.
2) 무상태 프로토콜(Stateless)
무상태 프로토콜이란? ----> 서버가 클라이언트의 상태를 보존하지 않는 것을 의미한다.
장점 : 서버 확장성이 높음(스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송
무슨 뜻인지 천천히 알아보자.
특정 사이트에서 노트북을 구매하는 상황을 가정해 보자. 고객은 클라이언트, 점원은 서버다.
상태 유지(Stateful)의 경우
위 상황과 같이 중간에 점원(서버)이 특정 사건으로 바뀌게 된다면,
점원 A 가 유지하고 있는 상태는 다른 점원에게 미리 알려줘야 한다.
만약 다른 점원에게 미리 알려주지 못했다면 클라이언트는 처음부터 다시 결제를 해야 한다.
무상태(Stateless)의 경우
이런 식으로 중간에 점원이 바뀌어도 클라이언트가 그때그때 필요한 정보를 제공하니깐
중간에 점원(서버)이 바뀌더라도 큰 문제가 없다. ---> 손님이 갑자기 많아졌을 때, 점원을 대거 투입할 수 있다.
상태 유지(Stateful), 무상태(Stateless)의 차이
- 상태유지 :
- 중간에 다른 점원으로 바뀌면 안 된다.
(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)
위 사진처럼 중간에 서버가 죽는다면 클라이언트는 처음부터 다시 정보를 보내줘야 한다.
- 무상태 :
- 중간에 다른 점원으로 바뀌어도 된다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
- 무상태는 응답 서버를 쉽게 바꿀 수 있다.
위와 같이 갑자기 트래픽이 증가한다면 스케일 아웃(서버군 확장)이 용이하다.
Stateless의 실무 한계
모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
EX) 로그인이 필요 없는 단순한 서비스 소개 화면 ---> 무상태 (서버가 상태 유지를 할 필요가 없다)
EX) 로그인 ---> 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지해야 한다 (상태 유지 필요)
- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 로그인 상태를 유지한다.
- 상태 유지는 최소한만 사용
3) 비 연결성(Connectionless)
- 클라이언트와 서버가 연결을 지속적으로 유지하는 모델이라면 서버 자원이 지속적으로 소비될 것이다.
- 연결을 유지하지 않는 비 연결성 모델은 서버의 최소한의 자원을 유지하면서 클라이언트가 요청할 때만 연결한다.
- HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
- 일반적으로 초 단위의 이하의 빠른 속도로 응답한다.
- 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작다. EX) 웹 브라우저의 검색 버튼을 연속해서 누르지 않는다.
- 서버 자원을 효율적으로 사용할 수 있다.
- 비 연결성의 한계와 극복
- 요청이 있을 때마다 TCP/IP 연결을 매번 새로 맺어야 함 - 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드 -- > 지금은 HTTP 지속 연결(Persistent Connectipns)로 문제 해결
----> HTTP/2 , HTTP/3에서 더 많은 최적화
4) HTTP 메시지
- HTTP 메시지의 구조
- HTTP 요청 메시지의 예시(요청 메시지도 body 본문을 가질 수 있음)
GET /search?q=hello&hl=ko HTTP/1.1 / start-line 시작라인
Host: www.google.com / header 헤더
- HTTP 응답 메시지
HTTP/1.1 200 OK / start-line 시작 라인
Content-Type: text/html;charset=UTF-8 / header 헤더
Content-Length: 3428
/ 공백 라인(CRLF)
<html> / message body
<body>....</body>
</html>
- 요청 메시지 시작 라인
* request-line : 요청 라인
* request-target : 요청 대상
- HTTP 메서드(GET: 조회 )
- 요청 대상 (/search?q=hello&hl=ko)
- HTTP version
- GET : 리소스 조회 (서버에게 "이 리소스를 줘")
- POST : 요청내역 처리 (서버에게 "이 리소스를 줄 테니깐 처리해줘")
- 절대 경로 : "/"로 시작하는 경로
- 응답 메시지 시작 라인
* status-line : 상태 라인
*status-code : 상태 코드
*reason-phrase : 이유 문구
- HTTP 상태 코드 : (요청 성공 / 실패)를 나타냄
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류
- 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글 ---> OK
- HTTP 헤더
- HTTP 전송에 필요한 모든 부가정보
- 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보... ----> 헤더에 바디 정보 빼고 메타 데이터 정보가 다 있다.
- 표준 헤더가 너무 많다
- 필요시 임의의 헤더 추가 가능
- HTTP 바디
참고 :
본 포스팅에 있는 모든 자료는 김영한 님의 HTTP 웹 기본지식 강의의 자료들입니다.
'웹 > http' 카테고리의 다른 글
| 김영한 님의 HTTP 웹 기본지식 강의/4.HTTP 메서드/HTTP 메서드의 속성 (0) | 2021.09.18 |
|---|---|
| 김영한 님의 HTTP 웹 기본지식 강의/4.HTTP 메서드 (0) | 2021.09.18 |
| 김영한 님의 HTTP 웹 기본지식 강의/2.URI와 웹 브라우저 요청 흐름 (2) | 2021.09.11 |
| 김영한 님의 HTTP 웹 기본지식 강의/1.인터넷 네트워크/DNS (0) | 2021.09.10 |
| 김영한 님의 HTTP 웹 기본지식 강의/1.인터넷 네트워크 (0) | 2021.09.10 |
