[HTTP] 기본

HTTP 프로토콜에 대해서 알아본다

HTTP(Hyper Text Transfer Protocol)

W3(www, world wide web)상에서 정보를 주고받을 수 있는 프로토콜.
주로 HTML 문서를 주고받는 데에 사용되었으나 최근에는 HTTP 메시지에 모든 것을 전송하고 있다.

HTTP 역사

• HTTP/0.9 1991년: GET 메서드만 지원, 서버로부터의 응답은 무조건 HTML문서였다.
• HTTP/1.0 1996년: 메소드와 헤더 필드를 통한 효율적인 보안 프로토콜로 업데이트 되었다.
• HTTP/1.1 1997년: 가장 많이 보편화되어 있는 버전이다. 이후의 버전들은 1.1버전에서 성능만 개선되었으므로 가장 중요한 버전으로 불린다.
  • RFC2068(1997) -> RFC2616(1999) -> RFC7230 ~ 7235(2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신 UDP를 기반으로 개선되면서 성능이 개선되었다.

클라이언트 서버 구조

• 클라이언트(Request), 서버(Response) 구조를 가진다.
• 클라이언트는 서버에 요청을 보내고 응답을 대기한다.
• 서버는 요청에 대한 결과를 만들어서 클라이언트에 응답한다.

Stateful vs Stateless

• HTTP는 무상태(Stateless) 프로토콜이다.
• 서버가 클라이언트의 상태를 저장하지 않는다.
• 서버 확장성이 높다.(scale out)
• stateful 보다 클라이언트가 추가해야 할 데이터가 많다.

클라이언트가 서버를 통해 단계적으로 차량을 구매하는 과정을 살펴보면서 Stateful과 Stateless의 차이를 알아본다.
둘의 비교를 위해 같은 역할을 하는 A서버와 B, C서버 세 개가 존재하고 앞단의 LoadBalancer가 클라이언트의 요청을 분배한다고 가정한다.

Stateful & A서버에만 요청되는 상황

Client: 쏘나타는 얼마?
A Server: 1000만원

Client: 두 대 구매
A Server: 쏘나타 두 대는 2000만원, 일시불 or 할부?

Client: 일시불
A Server: 결제 완료

Stateful & A서버, B서버, C서버 번갈아 요청되는 상황

Client: 쏘나타는 얼마?
A Server: 1000만원

Client: 두 대 구매
B Server: 어떤차를 두 대 구매?

Client: 일시불
C Server: 어떤차, 몇 대를 일시불로 구매?

문제점이 보이는가 A Server, B Server, C Server는 서로 Client의 상태를 저장하고 있지만 이 상태를 공유하지 않기때문에
여러 서버로 요청이 가게되면 서버에서는 이를 처리하는 로직이 필요해진다.
이러한 점 때문에 scale out 하기에는 많이 수고로움이 따른다.

Stateless & A서버, B서버, C서버 번갈아 요청되는 상황

Client: 쏘나타는 얼마?
A Server: 1000만원

Client: 쏘나타 두 대 구매
B Server: 쏘나타 두 대는 2000만원, 일시불 or 할부?

Client: 쏘나타 두 대 일시불
C Server: 결제 완료

클라이언트에서 요청시에 서버에서 자신의 상태를 기억하지 못해도 상관없도록 데이터를 전송한다.
그렇기에 어떤 서버에 요청이 되더라도 클라이언트는 자신이 원하는 응답을 얻을 수 있다.

이러한 특성으로 인한 장점은 아래와 같다.

• 갑자기 Client가 급증하더라도 Server를 대량으로 늘려서 해결할 수 있다.
• Client의 요청이 급증하더라도 Server를 대량으로 늘려서 해결할 수 있다.

하지만 모든 것을 무상태로 설계 할 수는 없다.
예를들어 사용자의 로그인 상태는 서버에서 상태를 유지시켜야한다.
이러한 경우 보통 브라우저의 쿠키와 서버의 세션을 통해서 상태를 유지한다. (요즘은 JWT를 많이 사용한다. 언젠가 JWT에 대해서도 다룰 예정)

connectionless (비연결성)

HTTP는 기본이 연결을 유지하지 않는 connectionless(비연결성) 모델이다.

여러 사용자가 네이버에 접속하고 메일을 확인한다고 가정해보자.
A사용자는 접속하고 바로 메일로 들어갈테고 B사용자는 30분 후에 들어갈 수도 있다.

A사용자의 경우 문제가 되지 않지만 B사용자의 경우 30분간 불필요한 connection이 이루어져있었다.
이렇게 불필요한 connection이 많아지면 서버는 부담스러워질 것이다.

이러한 이유때문에 HTTP는 기본이 connectionless 모델이다.

하지만 이러한 connectionless에는 치명적인 단점이 있다.
아래는 google에 아무 검색어나 검색했을 때의 request 양이다.

이 모든 요청이 3 way handshake를 통해서 새로운 연결을 만들고 또 그 연결을 끊는다고 생각해보자.
좋은 퍼포먼스를 기대하기 힘들 것이다.

이러한 문제점을 보완하기 위해서 HTTP 지속 연결(Persistent Connections)가 사용된다.
또한, HTTP/2, HTTP/3에서 더 많은 최적화가 이루어졌다.

HTTP 지속 연결, HTTP/2, HTTP/3은 다음 글에서 더 자세하게 알아보도록 한다.