HTTP 기본

모든 것이 HTTP

HTTP는 본래 HTML을 전송하기 위한 프로토콜이었으나 요즘엔 모든 형태의 데이터를 HTTP로 전송한다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)

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  : 성능 개선, 3 버전부터 TCP 대신 UDP 사용

클라이언트 서버 구조

HTTP는 클라이언트 서버 구조를 기반으로 한다. 클라이언트 서버 구조는 클라이언트에서 요청(Request)를 보내면 서버는 요청을 받아 응답(Response)하는 구조이다. 클라이언트와 서버를 분리함으로써 클라이언트는 UI에 집중하고 서버는 비즈니스 로직에 집중할 수 있다.

클라이언트 서버 구조

Stateless, Stateful

Stateful : 클라이언트 서버 관계에서 서버가 클라이언트의 상태를 보존하고 있음

• 메시지가 간결
• 상태 보존으로 인해 시스템 관리와 확장이 복잡해짐

Stateless : 라이언트 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음

• 메시지가 길어짐(필요한 모든 정보를 담아 보내야 되기 때문)
• 상태 보존이 없어 시스템 관리와 확장이 간단

Statelful 프로토콜에는 TCP, FTP가 있으며, Stateless 프로토콜에는 HTTP, UDP가 있다. 즉 TCP와 FTP를 사용하는 서버는 클라이언트의 상태를 보존하며 HTTP와 UDP를 사용하는 서버는 클라이언트의 상태를 보존하지 않으면서 통신한다. 예를 들어보자. Stateless, Stateful 방식의 통신 과정을 손님과 점원과의 대화로 비유한 것이다.

Stateful 대화 : 서버(점원)는 클라이언트(손님)의 주문 내역을 기억해 간결하게 주문 가능, 손님마다 주문 내역을 유지하는게 어려움 (중간에 점원이 바뀌는 경우, 새 점원 추가되는 경우 등)

 

Stateless 대화 : 한번에 주문을 해야되기에 주문이 매우 길어짐, 손님마다 주문 내역을 기억하지 않아 점원이 바껴도 문제가 발생하지 않음

 

HTTP가 성공한 이유는 간단하기 때문이고 HTTP가 간단한 이유는 Stateless 방식과 비연결성 덕분이다. Stateless 방식은 어떤 점에서 유리할까? 시스템 관리와 확장이 단순하다는 이점을 가진다.

 

Stateless의 장점

Stateful 방식의 서버는 클라이언트의 수가 늘어날수록 시스템이 복잡해진다. 예를 들어 Stateful 방식의 서버 중 하나에 장애가 생겼다고 가정해보자. 그러면 다른 서버에서 응답해야하는데 그럴 수 없다. 다른 서버는 해당 클라이언트의 상태를 모르기 때문이다. 이러한 문제를 해결하려면 서버마다 상태를 동기화하는 작업이 추가적으로 필요하다.

 

반면에 Stateless 방식의 서버는 클라이언트의 수가 늘어나도 시스템이 단순하다. 예를 들어 서버 중 하나에 장애가 생겨도 다른 서버가 바로 응답할수 있다.

 

또한 갑자기 많은 트래픽이 생겨도 단순히 서버를 증설해 해결할 수 있다.

 

Stateless의 단점, 결론

Stateless 방식은 요청 메세지에 상태 정보를 포함해 필요한 모든 정보를 포함시키기에 송신 데이터 양이 많아지며 사용자 인증 등 서버에 부하가 걸리는 처리를 반복한다는 단점이 있다.

 

하지만 이럼에도 Stateless 방식이 주는 이점이 크기에 로그인 등 클라이언트 상태 보존이 꼭 필요한 경우를 제외하고는 최대한 서버에서 클라이언트 상태 보존을 하지 않도록 아키텍처를 구성하는 것이 중요하다.

비연결성

HTTP는 연결을 유지하지 않는다. 이러한 특성을 비연결성이라 한다. 즉 클라이언트가 요청할 때 연결(TCP 3way handshake)하고 서버의 응답이 끝나면 연결을 끊는다.

 

비연결성의 장점은 서버 자원을 효율적으로 사용할 수 있다는 점이다. 여러 클라이언트와 연결될 수록 서버의 자원이 고갈되기에 요청에 대해 응답할때만 연결되면 서버의 자원을 아낄 수 있다. 하지만 이로 인해 요청마다 연결 과정을 반복해야 된다는 단점이 생긴다.

요청마다 연결 반복

이러한 단점은 HTTP 지속 연결로 해결하고 있다. 아래 그림 처럼 연결 한 뒤 필요한 모든 데이터를 보내고 연결을 끊는다. 이것에 그치지 않고 HTTP2, HTTP3에서는 더욱 최적화가 이루어졌다.

연결 시 필요한 모든 데이터를 보냄

HTTP 메세지 구조

HTTP 메세지의 구조는 다음과 같다.

HTTP 메세지 구조

START-LINE

HTTP 메세지는 start-line으로 시작한다. 요청 메세지는 request-line이 오며 응답 메세지는 status-line이 온다.

 

HEADER

start-line 다음 줄에 헤더가 온다. 헤더에는 HTTP 전송에 필요한 모든 부가 정보가 들어있다. 필요 시 임의의 헤더를 추가 할 수 있다.

• header-field = field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)
• field-name은 대소문자 구분하지 않는다.

MESSAGE BODY

실제 전송할 데이터가 들어있다. HTML, 영상, 이미지 등 바이트로 보낼 수 있는 모든 데이터를 전송할 수 있다.

 

HTTP 요청 메세지

HTTP 요청 메세지를 살펴보자. 아래의 메세지는 바디가 비워있지만 채워져 있을 수도 있다.

HTTP 요청 메세지

요청 메세지의 start-line으로 request-line이 온다. request-line은 아래의 구조를 가진다.

method SP(공백) request-target SP HTTP-version CRLF(엔터)

• method : HTTP method(GET, PUT, POST ···)
• request-target : 절대경로[?쿼리], 절대경로는 "/"로 시작하는 경로이다.
• HTTP-version : HTTP 버전

 

HTTP 응답 메세지

HTTP 응답 메세지를 살펴보자

 

HTTP 응답 메세지

응답 메세지의 start-line으로 state-line이 온다. state-line은 아래의 구조를 가진다.

HTTP-version SP status-code SP reason-phrase CRLF

• HTTP-version : HTTP 버전
• status-code : HTTP 상태 코드 (200, 400, 500  ···), 응답 상태를 나타냄
• reason-phrase : 이유 문구, 사람이 이해할 수 있는 짧은 상태 코드 설명글