3.1 모든 것이 HTTP (HyperText Transfer Protocol)
HTTP 메시지에 모든 것을 전송
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML (API)
- 거의 모든 형태의 데이터 전송 가능
- 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용
(TCP를 직접 연결하는 경우는 거의 없음)
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 사용, 성능 개선
기반 프로토콜
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- 현재 HTTP/1.1 주로 사용
(HTTP/2, HTTP/3 도 점점 증가)
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
3.2 HTTP 특징 1 - 클라이언트 서버 구조
- Request / Response 구조
- 클라이언트는 서버에 요청을 보내고, 서버는 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답을 함
클라이언트와 서버를 개념적으로 분리하면,
복잡한 비즈니스 로직과 데이터를 모두 서버에 넣고
UI와 사용성을 클라이언트에서 관리할 수 있다.
즉, 클라이언트와 서버는 각각 독립적으로 진화할 수 있다는 장점이 있다.
3.3 HTTP 특징 2 - Stateful, Stateless
무상태 프로토콜 (Stateless) 지원
- 서버가 클라이언트의 상태를 보존하지 않음
- 장점: 서버 확장성 높음 (스케일 아웃)
- 단점: 클라이언트가 추가 데이터 전송
Stateful, Stateless 차이
- Stateful : 노트북을 구매하는 중간에 다른 점원으로 바뀌면 안된다.
(중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)
- Stateless : 노트북을 구매하는 중간에 다른 점원으로 바뀌어도 된다.
갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
- 무상태는 응답 서버를 쉽게 바꿀 수 있다.
무한한 서버 증설 가능
상태 유지 - Stateful
: 항상 같은 서버가 유지되어야 한다.
클라이언트 A가 요청을 하고 서버 1이 응답을 했다고 가정하자.
상태 유지에서는 항상 같은 서버가 유지되어야 하므로,
클라이언트 A는 서버 1 이랑만 통신할 수 있게된다.
만약 중간에 서버 1에 장애가 발생하면 어떻게 될까?
클라이언트는 앞서 전송한 정보를 서버에 모두 다시 전송해야 한다.
무상태 - Stateless
: 아무 서버나 호출해도 된다
클라이언트 A가 요청을 하고 서버 1이 응답을 했다고 가정하자.
클라이언트는 요청할 때마다 필요한 데이터를 모두 담아서 보낸다.
또한 서버는 상태를 저장하지 않고, 단순히 클라이언트에게 응답만 한다.
만약 중간에 서버 1에 장애가 발생하면 어떻게 될까?
클라이언트는 항상 필요한 데이터를 모두 담아서 보내므로,
해당 요청을 서버2로 던져주면, 서버2가 응답할 수 있다.
따라서 Stateless는 수평 확장에 유리하다. (스케일 아웃)
Stateless 실무 한계
- 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태
예) 로그인이 필요 없는 단순한 서비스 소개 화면
- 상태 유지
예) 로그인 : 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 전송되는 데이터 양이 많음
- 상태 유지는 최소한만 사용
3.4 HTTP 특징 2 - 비 연결성 (Connectionless)
연결을 유지하는 모델
TCP/IP 는 주로 연결을 유지한다.
클라이언트1이 서버에 접속한 후, 클라이언트 3이 서버에 접속했다고 가정하자.
클라이언트의1의 요청이 끝났더라도, 클라이언트1은 계속 서버에 접속이 되어있는 상태이다.
이러한 방식은 서버가 연결을 계속 유지해야 하므로,
서버의 자원이 많이 소모된다.
연결을 유지하지 않는 모델
앞선 방식과 다르게, 요청이 끝나면 TCP/IP 연결을 종료한다.
서버는 연결을 유지하지 않으므로,
유지해야하는 자원을 최소환으로 줄일 수 있다.
비 연결성
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위의 이하의 빠른 속도로 응답
- 1시간 동안 수천명이 서비스를 사용해도, 실제 서버에서 동시에 처리하는 요청은 수십개 이 하로 매우 작음
예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
- 서버 자원을 매우 효율적으로 사용할 수 있음
비 연결성 - 한계와 극복
- TCP/IP 연결을 새로 맺어야 함
(3 way handshake 를 위한 시간 추가)
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등
수 많은 자원이 함께 다운로드 됨
- 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
- HTTP/2, HTTP/3에서 더 많은 최적화
1) HTTP 초기 - 연결, 종료 낭비
연결이 필요하면 연결하면 응답하고 종료한다. (0.9초 소요)
2) HTTP 지속 연결(Persistent Connections)
연결을 하고 요청과 응답을 모두 끝낸 후 종료한다.
해당 HTML 페이지를 모두 받을 때까지 연결을 유지한다.
[Stateless 를 기억하기]
: 서버 개발자들이 어려워하는 업무
정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽에 대응 가능
예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
예) 저녁 6:00 선착순 1000명 치킨 할인 이벤트에서 수만명 동시 요청
3.5 HTTP 특징 3 - HTTP 메시지
HTTP는 요청 메시지와 응답 메시지의 구조가 약간 다르지만,
기본적인 구조는 다음과 같다.
HTTP 메시지 구조는
시작 라인, 헤더, 공백 라인, message body 로 이루어져 있다.
시작 라인
1) 요청 메시지
- start-line 은 request-line / status-line 로 나눌 수 있음
- 요청 메시지 : request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
• HTTP 메서드 (GET: 조회)
• 요청 대상 (/search?q=hello&hl=ko)
• HTTP Version
2) 요청 메시지 - HTTP 메서드
- 종류: GET, POST, PUT, DELETE...
- 서버가 수행해야 할 동작 지정
- GET: 리소스 조회
- POST: 요청 내역 처리
3) 요청 메시지 - 요청 대상
- absolute-path[?query] (절대경로[?쿼리]) 로 시작함
- 절대경로= "/" 로 시작하는 경로
- 참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.
4) 요청 메시지 - HTTP 버전
- HTTP Version
5) 응답 메시지
- start-line = request-line / status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
• HTTP 버전
• HTTP 상태 코드: 요청 성공, 실패를 나타냄
( 200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류)
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP 헤더
- header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
- field-name은 대소문자 구문 없음
HTTP 메시지 헤더 - 용도
- HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
서버 애플리케이션 정보, 캐시 관리 정보...
- 표준 헤더가 너무 많음
- 필요시 임의의 헤더 추가 가능 (helloworld: hihi)
HTTP 메시지 바디 - 용도
- 실제 전송할 데이터가 들어 있음
- HTML 문서, 이미지, 영상, JSON 등
(byte로 표현할 수 있는 모든 데이터 전송 가능)
[HTTP 정리]
1) HTTP 메시지에 모든 것을 전송
2) HTTP 역사 HTTP/1.1을 기준으로 학습
3) 클라이언트 서버 구조
4) 무상태 프로토콜(스테이스리스)
5) HTTP 메시지
6) 단순함, 확장 가능
'HTTP 웹 기본 지식' 카테고리의 다른 글
| [HTTP 웹 기본 지식] 섹션 5. HTTP 메서드 활용 (0) | 2023.07.08 |
|---|---|
| [HTTP 웹 기본 지식] 섹션 4. HTTP 메서드 (0) | 2023.07.01 |
| [HTTP 웹 기본 지식] 섹션 2. URI와 웹 브라우저 요청 흐름 (0) | 2023.07.01 |
| [HTTP 웹 기본 지식] 섹션 1. 인터넷 네트워크 (0) | 2023.07.01 |
| [HTTP 웹 기본 지식] 섹션 0. HTTP를 공부하게 된 이유 / 강의 소개 (0) | 2023.07.01 |