❓ HTTP 역사는 아래의 그림과 같다.
💡 HTTP/1.1, HTTP/2 는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜이다.
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성(connectionless)
- HTTP 메세지
- 단순함, 확장 가능
무상태와 상태유지에 대한 설명은 아래와 같다.
상태유지
점원이 바뀌면
클라이언트의 상태를 모르기 때문에 정확한 주문이 안이루어진다.
이렇게 점원A가 고객의 상태를 기억하고 있는 것을 상태 유지라고 한다.
무상태
무상태에서는 고객이 자신의 주문을 기억하고 있어서 다른 점원이 바뀌어도 정확한 주문이 가능
무상태 프로토콜(Stateless)은 서버가 클라이언트의 상태를 보존하지 않는다.
❗️ 무상태 프로토콜에서도 실무 한계가 존재하는데 바로 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 떄문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다.
Connection Oriented
TCP/IP 의 경우 기본적으로 연결을 유지.
연결을 유지하는 모델에서는 클라이언트 1, 2는 요청을 보내지 않더라도 연결을 유지해야 한다.
이러한 경우 연결을 유지하는 서버의 자원이 계속 소모 된다.
Connectionless
비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고나면 TCP/IP 연결을 끊는다.
이를 통해 최소한의 자원으로 서버 유지가 가능하다.
💡 HTTP 특징 (비 연결성 - Connectionless)
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
❗️ 하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 비연결성은 한계를 보인다.
💡HTTP 특징(비 연결성 - Connectionless 한계와 극복)
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
- 지금은 HTTP 지속 연결(Persistent Connetctions)로 문제 해결
- HTTP/2, HTTP/3 에서 더 많은 최적화
초기에는 각각의 자원을 다운로드 하기 위해 연결과 종료를 반복
지속연결에서는 연결이 이루어 지고 난 뒤 각각의 자원들을 요청. 모든 자원에 대한 응답이 돌아온 후에 연결을 종료