이 자료는 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 학습하고 정리한 자료입니다.
바야흐로 대HTTP시대.. HTTP에 대해 알아보자.
HTTP(HyperText Transfer Procotol)
HTTP는 웹 상에서 정보를 주고 받을 수 있는 프로토콜이다.
HTTP 메시지에 HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML 등 거의 모든 형태의 데이터 전송이 가능하다.
서버간 데이터를 주고 받을 때도 대부분 HTTP 사용한다.
HTTP 역사
HTTP/0.9(1991)
GET 메서드만 지원, HTTP 헤더 X
HTTP/1.0(1996)
- 버전 정보 전송 시작
- HTTP 헤더 추가
HTTP/1.1(1997~2014)
현재 가장 많이 사용하는 버전
HTTP/2(2015)
성능 개선
HTTP/3(2022~ing)
- 구글 자체 프로토콜 QUIC가 표준화됨.
- 장점
- Zero RTT(Round Trip Time)
- 패킷 손실에 대한 빠른 대응
- 사용자 IP 바뀌어도 연결 유지
- RFC9114
기반 프로토콜
- TCP: HTTP/1.1, HTTP
- UDP: HTTP/3
HTTP 특징
클라이언트 서버 구조
위 이미지 같이 클라이언트 - 서버간 구조는 Request, Response로 이루어져 있다.
Clien는 Server에 요청을 보내고 응답을 대기하고 Server는 Client 요청에 따라 결과를 만들어 응답한다.
서버/클라이언트 분리 중요성
- 각각 독립적으로 고도화 가능
- 서버 - 비즈니즈 로직과 데이터에 집중하여 트래픽이 증가했을 경우 서버 아키텍쳐나 대용량 트래픽 고도화 집중 가능
- 클라이언트 - 복잡한 비즈니스 로직이 없기 때문에 단순하게 UI,UX 집중 가능
Stateless
HTTP는 무상태 프로토콜(Stateless)을 지향한다.
무슨 뜻인가한고 서버가 클라이언트의 상태를 보존하지 않는다.
- 장점: 서버 확정성 높음 -> scale out이 용이하다.
- 단점: 클라이언트가 추가 데이터를 전송해야 한다.
Stateful, Stateless
Stateless가 정확히 무엇인지 반대의 개념인 Stateful와 비교해보며 알아보자.
Stateful
위 이미지처럼 Stateful은 새로운 요청이 들어와도 Server에서 상태 정보를 기억하고 있다.
따라서 Client 요청 데이터 자체가 줄어들지만 Server가 중간에 바뀌면 상태 정보가 없어져 통신이 정상적으로 이루어질 수 없다.
그리고 중간에 Server가 장애가 나면 대응할 수가 없다.
Stateless
위 이미지처럼 Stateless는 Client 측에서 요청마다 필요한 정보를 담아서 Server에 요청한다. 그리고 Server는 요청 데이터를 이용하여 응답한다.
그렇기 때문에 Stateful과 달리 중간에 서버가 달라져도 통신이 정상적으로 이루어진다.
또한 중간에 Server가 장애가 날 경우 같은 역할을 하는 다른 Server로 전달하면 해결된다.
즉, Client 요청이 증가해도 서버를 쉽게 늘릴 수 있기 때문에 돈만 있다면 무한하게 서버를 증설할 수 있다.
실무 한계
- 모든 것을 Stateless로 설계할 수 없는 경우도 있다.
- 로그인이 필요 없는 단순한 서비스 소개 화면 -> Stateless
- 로그인 -> Stateful
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지 해야 한다.
- 일반적으로 브라우저 쿠키와 서버 세션와 서버 세션 등을 사용해서 상태 유지한다.
- Stateful은 최소화만 사용한다.
- 많은 데이터를 요청한다.
Connectionless
또 다른 특징인 비연결성(Connectionless)도 반대 개념인 연결지향(Connection Oriented)와 비교해보며 알아보자.
Connection Oriented
연결 지향 모델의 경우 Server-Client 간 통신이 있을 때마다 연결을 유지하기 때문에 Client 요청이 늘어갈수록 서버 자원 소모가 극심해질 것이다.
Connectionless
비연결성 모델의 경우 Server-Client 간 통신이 끝날 경우 연결을 끊는다. 따라서 Server는 최소한의 자원을 유지할 수 있다.
특징
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음
- 웹 브라우저에서 동시에 검색 버튼을 누르지는 않는다.
- 서버 자원을 매우 효율적으로 사용할 수 있음
한계
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 js, css, 이미지 등 수많은 리소스들이 함께 다운로드
극복
- 지금은 HTTP 지속 연결(Persitent Connections)로 문제 해결
- HTTP/2, HTTP/3에서 더 많은 최적화
