HTTP
HTTP란?
HyperText Transfer Protpcol이라는 뜻으로, HyperText 문서를 통해서 연결할 수 있는 Html을 전송하는 프로토콜로 처음 시작되었다.
지금은 HTTP 메시지에 HTML 문서 뿐만 아니라 거의 모든 형태의 데이터를 담아서 전송할 수 있다.
- HTML, TEXT
- 이미지, 음성, 영상, 파일
- JSON, XML
- 보통 서버 간에 통신할 때 사용한다. (API)
💡 서버 간 통신을 할 때 TCP 프로토콜을 직접 이용해서 데이터를 전송하는 경우는 거의 없다.
이 경우는 게임 서버 혹은 특수한 경우로, 대부분은 HTTP 프로토콜로 연결한다.
HTTP 버전
HTTP/0.9
- 1991년, 초창기 버전
- GET 메서드만 지원
- HTTP 헤더 없음
HTTP/1.0
- 1996년
- 메서드
- 헤더 추가
HTTP/1.1
강의에서는 이 버전으로 설명되었다.
- 1997년
- 가장 많이 사용 (강의 기준)
- 이 스펙에 대부분의 기능이 들어있고, 이 이후로는 성능 개선에 초점이 맞춰져 있다.
- 여러 번 개정되었다.
- RFC2068 (1997)
- RFC2616 (1999)
- RFC7230 ~ 7235 (2014)
HTTP/2
- 2015년
- 성능 개선
HTTP/3
- 진행 중
- 성능 개선
- TCP 대신에 UDP 사용
HTTP와 프로토콜
원래 HTTP는 TCP 프로토콜을 사용했다.
그런데 TCP는 3-way handshake를 해야 하고, 기본적으로 안에 데이터도 많고, 속도도 빠르지 않다.
따라서 UDP 프로토콜 위의 애플리케이션 계층에서 성능을 최적화하도록 새로 설계한 버전이 나왔다.
- TCP 프로토콜을 사용하는 버전
- HTTP/1.1, HTTP/2
- UDP 프로토콜을 사용하는 버전
- HTTP/3
Tip: 사용 중인 프로토콜 보는 법
- F12로 개발자 툴을 연다.
- Network 탭에 들어간다.
- 우클릭 후 ‘Protocol’에 체크한다.
이후, 네이버나 크롬을 들어가면 프로토콜 정보를 볼 수 있다.
아래 그림의 빨간 박스친 곳이 프로토콜 정보이며, h2가 HTTP/2 이고 H3가 HTTP/3 이며, HTTP/1.1 도 확인할 수 있다.
HTTP 특징
클라이언트 서버 구조
클라이언트는 HTTP 메시지를 통해 서버에 요청을 보내고(Request) 응답을 대기한다.
그리고 서버는 요청에 대한 결과를 만들어서 응답(Response)하는 구조이다.
예전에는 구분 없이 하나로 취급했는데, 클라이언트와 서버를 개념적으로 분리했다.
- 비즈니스 로직과 데이터는 서버에서 관리한다.
- 클라이언트는 UI에 집중한다.
장점
이렇게 분리함으로써 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.
- 클라이언트는 단순히 UI와 UX를 그리는 데에 집중하면 된다.
- 서버는 아키텍처를 어떻게 할지, 대용량 트래픽을 어떻게 처리하고 고도화시킬지만 고민한다.
- 서로 몰라도 된다! (독립적으로 진행 가능)
무상태 프로토콜 (Stateless)
HTTP는 무상태 프로토콜을 지향한다.
- 서버가 클라이언트의 상태를 보존 X
- 장점: 서버 확장성 높음 (스케일 아웃)
- 단점: 클라이언트가 추가 데이터 전송
Stateful이란?
서버가 클라이언트의 이전 상태를 유지하는 것이다.
예를 들어, 클라이언트 A가 노트북의 정보를 열람 후 구매를 하는 과정을 그림으로 보도록 하자.
클라이언트가 요청을 한 내용을 서버가 기억을 해두고 있어서(붉은 글씨), 클라이언트가 ‘노트북’ 혹은 ‘2개’라는 정보를 다시 보내지 않아도 된다.
그런데, 이렇게 되면 항상 같은 서버가 유지되어야 한다.
만약 서버를 여러 대 두었고, 서버 A와 통신하던 상태라고 하자.
- 장애가 나서 서버 B로 이동되었다면, 서버 B는 이전 정보가 없으므로 다시 처음부터 정보를 받아야만 한다.
Stateless란?
서버가 클라이언트의 상태를 유지하지 않는 것이다.
즉, 무상태에서 클라이언트 A가 노트북의 정보를 열람 후 구매를 하는 과정은 다음과 같이 흘러간다.
서버가 내려주는 응답값과 흐름은 똑같아 보이지만, 클라이언트가 요청을 할 때마다 모든 정보를 같이 보내주는 것을 볼 수 있다.
따라서 무상태는 중간에 응답 서버가 다른 서버로 바뀌어도 된다.
즉, 갑자기 클라이언트 요청이 증가해도 서버를 증설하여 대거 투입할 수 있다.
- Scale-Out에 유리
💡 Scale-Up과 Scale-Out
서버를 확장시키기 위한 방법이다.
- Scale-Up: 기존 서버의 사양을 업그레이드
- Scale-Out (수평 확장): 비슷한 사양의 서버를 여러 대 추가
다만, 다음과 같은 한계가 있다.
- 데이터를 많이 보내야 한다.
- ‘노트북’이나 ‘2개’같은 정보를 계속 포함해야 한다.
- 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
- 로그인의 경우: 로그인 했다는 상태를 유지해야 한다.
- 일반적으로 로그인의 경우엔 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지한다.
그래도 웹 애플리케이션을 설계할 때는 최대한 무상태로 설계하며, 상태 유지는 최소한만 사용해야 한다.
비연결성 (connectionless)
연결성과 비연결성
- TCP/IP 연결은 기본적으로 연결을 유지해야 한다.
- 연결된 서버가 계속 유지해야 한다.
- 서버의 자원이 계속 소모된다.
- 연결을 유지하지 않으면 최소한의 자원으로 유지할 수 있다.
- 요청을 하고 응답을 받으면 바로 연결을 끊어버린다.
- 유지하는 자원을 최소한으로 줄일 수 있다.
HTTP와 비연결성
- HTTP는 기본이 연결을 유지하지 않는 모델이다.
- 따라서 일반적으로 초 단위 이하의 빠른 속도로 응답한다.
- 서버 자원을 매우 효율적으로 사용할 수 있다.
비연결성의 한계
- 요청을 할 때마다 TCP/IP 연결을 새로 맺어야 한다.
- 연결 시 3-way handshake을 해야 하므로 시간이 추가된다.
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 이미지 등의 수 많은 자원들이 함께 다운로드 된다.
- 자원을 받을 때마다 연결을 반복해야 한다.
비연결성의 한계를 극복
- HTTP 지속 연결(Persistent Connections)로 문제 해결
- Keep Alive
- 내부적으로 다르지만, 연결을 바로 끊지 않고 몇 초 동안 유지하는 식의 메커니즘이다.
- 대체로 HTML 페이지를 하나 받을 때까지는 연결을 유지한다.
- HTTP/2와 HTTP/3에서 더 많은 최적화가 되었다.
Tip: 실무의 비연결성
최대한 stateless하게 설계하면 대응할 수 있는 부분들이 많아진다.
- 예를 들어, 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
- 선착순 이벤트나 수강 신청과 같은 상황
HTTP 메시지
HTTP 메시지 구조
먼저, 공식 스펙(RFC문서)을 보면 아래와 같이 정의되어 있다.
- CRLF는 공백으로, 필수로 있어야 한다.
HTTP 시작 라인
역시 공식 스펙을 보면 아래와 같이 정리되어 있다.
- request-line: 요청 메시지일 경우
- HTTP 메서드
- 요청 대상: absolute-path[?query]
- HTTP Version
💡 HTTP 메서드는 서버가 수행해야 할 동작을 지정하는 것으로, 다음 글에서 설명할 것이다.
- status-line: 응답 메시지일 경우
- HTTP 버전
- HTTP 상태 코드
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
💡 HTTP 상태코드는 클라이언트가 보낸 요청의 성공 여부를 말하며, 이후 글에서 설명한다.
보통 200이 성공, 400은 요청 오류, 500은 서버 오류이다.
HTTP 헤더
HTTP 전송에 필요한 모든 부가정보를 담고 있으며, 표준 헤더 필드는 무수히 많다.
- OWS는 띄어쓰기를 허용한다는 뜻이다.
- 여기에선 OWS가 없으면 띄어쓰기를 해선 안 된다!
- field-name은 대소문자를 구분하지 않는다.
- 필요 시 임의의 헤더를 추가할 수 있다.
- 클라이언트와 약속이 된 상태여야 한다.
HTTP 메시지 바디
- 실제 전송할 데이터
- byte로 표현할 수 있는 모든 데이터 전송 가능
- HTML 문서, 이미지, JSON 등
예시
그림으로 보자면 다음과 같다.
Reference
인프런 강의
