HTTP 통신
HTTP 통신은 다음과 같은 특징을 가진다.
- 대부분의 파일 형식 전송 가능
- 클라이언트 - 서버 구조
- Stateless
- Connectionless
대부분의 파일 형식 전송 가능
HTTP란 HyperText Transfer Protocol의 약자로 HTML 파일을 전송하는 프로토콜이라는 의미를 가지지만, 오늘날에는 거의 모든 파일 형식을 HTTP 통신을 이용해 전송 가능하다. 특히 우리가 자주 사용하는 JSON, TEXT, IMAGE 파일은 물론 음성 파일 등도 HTTP를 통해 전송이 가능해졌다.
클라이언트 - 서버 구조
클라이언트 - 서버 구조
클라이언트의 요청이 있을 때 서버가 응답하는 단방향 통신이다.
HTTP는 클라이언트에서 서버에 요청을 하는 단방향 통신이다. 서버는 클라이언트에 요청을 하지 않으며 클라이언트의 요청에 대한 응답만을 할 뿐이다.
그림1. 클라이언트 서버 구조
클라이언트의 요청에 대한 서버의 응답에는 요청 처리 결과에 따라 응답 코드가 다르게 온다. 따라서 응답 코드 별로 처리 로직을 만들어 서버의 상황에 대한 대응이 가능해진다.
예를 들어, 이미지 파일을 요청하는데 URL이 바뀌어 이미지 파일이 해당 경로에 더이상 없을 때, 서버에서는 다른 경로로 다시 요청하라는 응답을 보낸다. 이 때 클라이언트는 해당 경로로 다시 요청을 하여 이미지 파일을 받아올 수 있다.
Stateless
HTTP 통신에서 서버는 클라이언트의 상태를 저장하지 않는다. 클라이언트의 상태를 저장하지 않는다는 말은 클라이언트가 이전에 했던 요청이 무엇인지에 따라 반응이 달라지지 않는다는 것이다.
Stateless
서버는 클라이언트의 상태를 저장하지 않는다.
Stateless가 중요한 이유는 서버가 확장 가능해야 하기 때문이다. 보통 대규모 트래픽이 발생하는 서비스에서는 서버가 여러대가 있다. 서버가 많아지면 많아질 수록 서로 간에 정보를 공유하기 위한 비용이 비싸진다. Stateless하게 사용할 경우 정보 공유가 최소화되어 정보를 공유하기 위한 비용을 최소화 할 수 있다.
Stateful의 의미와 한계점
서버가 클라이언트(어플리케이션)의 상태를 저장하는 것을 Stateful이라 한다. HTTP에서는 Stateful을 사용하면 정보를 공유하기 위한 비용이 비싸지므로 사용하지 않는다. 정보를 공유하기 위한 비용이 왜 비싸지는지 살펴보자.
그림2. Stateleful 예시
예를 들어 상품 구매 서버를 만든다고 해보자. 유저는 서버에 안마의자 상품에 대한 정보를 요청한 후 안마의자가 마음에 들어 안마의자 2개를 주문하려 한다. 이 때 유저가 안마의자 상품에 대한 정보를 요청한 것을 서버가 알고 있다면, 이후 유저는 2개를 주문하는 것만 서버에 보내면 된다.
그림3. 다중 서버에서의 Stateful
하지만, 서버가 1번부터 100번까지 100개가 있고 유저가 안마의자 상품에 대해 정보를 요청한 것을 1번 서버만 알고 있다고 하자. 유저의 2개 구매 요청을 받은 서버는 100번 서버이다. 이 때 100번 서버가 유저가 조회한 것을 알기 위해서는 1~99번 서버에 대해 유저가 상품을 조회한 기록이 있는지 살펴봐야 한다. 만약 서버가 1000대가 있었으면 999개의 서버를 돌아봐야 한다.
이렇게 할 경우 너무 비효율 적이다. 이를 Stateless한 방식으로 하면 <그림4>와 같이 하면 된다.
Stateless를 통한 Stateful 한계 극복
그림4. 다중 서버에서의 Stateless
클라이언트(어플리케이션)에서 이전에 자신이 요청한 정보를 저장해놓고 해당 메세지를 함께 보내는 것이다. "2개 구매" 앞에 "안마의자"까지 포함해서 보냄으로써 서버100은 나머지 서버에 클라이언트가 이전에 어떤 요청을 하였는지 다른 서버를 조회할 필요가 없게 된다. 따라서 서버가 많아지던 말던 다른 서버를 조회하지 않고 서버는 그 클라이언트가 보낸 조회에 대한 응답만을 하면 된다. 각 서버가 메세지를 독립적으로 처리할 수 있게 되면서 서버의 개수에 비례해서 성능이 올라갈 수 있게 된다.
Connectionless
HTTP 통신은 연결(Connection)을 유지하지 않는 것을 기본 동작으로 가진다. 기본 동작으로는 Connection을 유지하지 않지만 별도의 옵션을 두면 일정기간동안 유지하게 할 수도 있긴 하다.
Connection을 유지하지 않는 것을 기본 동작으로 가지는 이유는 Connection을 유지하게 되면 지속적으로 리소스가 사용되기 때문이다. 따라서 Connection 유지는 최소화하는 것이 좋다.
Connection을 유지하는 것이 나은 경우도 있다
HTTP 통신이 생긴 초기에는 서버는 응답한 후 클라이언트(사용자)의 Connection을 곧바로 끊어버렸으나, 최근에는 성능상의 이유(Connection을 맺고 끊는 비용이 비싸다)로 Keep Alive 옵션을 통해 일정 기간 동안 클라이언트와 Connection을 유지하는 방식으로 통신이 가능해졌다.
자주 데이터를 요청해야 하는 경우에는 Connection을 맺었다가 끊는 것보다 Connection을 일정 기간 유지하는 것이 비용이 절감된다.
