[HTTP] HTTP의 특징

대부분의 내용은 인프런 김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식을 참고했습니다.

---

 

HTTP의 특징

HTTP의 특징으로는 크게 아래의 3가지가 있습니다.

1. 클라이언트 - 서버 구조

2. 무상태 프로토콜

3. 비연결성

 

하나씩 알아봅시다.

 

---

클라이언트 - 서버 구조

---

 

클라이언트와 서버

클라이언트와 서버에 대해 간략한 개념을 말하자면 아래와 같습니다.

클라이언트(client) : 서버로 요청을 보내고, 요청에 대한 응답을 받아서 처리하는 역할입니다.

서버(server) : 클라이언트의 요청에 따라 로직을 실행하고 적절한 응답을 다시 클라이언트에게 전달하는 역할을 말합니다.

 

이런 클라이언트 - 서버 구조는 HTTP를 사용하는 웹 애플리케이션에서 활용됩니다.

웹 브라우저 (클라이언트) - 웹 서버 (서버)라고 생각하면 됩니다.

 

클라이언트와 서버는 서로 HTTP를 통해 통신을 합니다.

클라이언트가 서버에 HTTP 요청을 보내고 서버 또한 클라이언트에서 HTTP 응답을 보냅니다.

---

클라이언트 - 서버 구조의 장점

이렇게 클라이언트 - 서버 구조로 분리하면 각자 자신의 역할에 집중해서 구현할 수 있습니다.

클라이언트는 복잡한 데이터나 비즈니스 로직을 다룰 필요 없이 UI만 어떻게 그릴지에만 집중할 수 있고,

서버는 비즈니스 로직에 집중할 수 있기 때문입니다.

 

그리고 서버와 클라이언트가 분리되어 있으므로, 시스템의 각 구성 요소를 독립적으로 확장할 수 있습니다.

예를 들어 사용량이 증가할 때 서버를 추가하는 등의 작업이 수월해집니다.

---

 

 

---

무상태 프로토콜

---

 

 

Stateless와 Stateful

Stateful은 서버가 클라이언트의 상태를 보존하는 것을 말하고, Stateless는 상태를 보존하지 않는 것을 말합니다.

 

HTTP에서는 통신이 끝나면 클라이언트의 상태를 보존하지 않기 때문에 HTTP는 무상태 프로토콜의 특징을 가집니다.

---

무상태 프로토콜의 특징

무상태 프로토콜은 각각의 요청이 독립적으로 처리됩니다.

 

마트에서 노트북을 구매한다고 해봅시다.

손님 : 이 모니터 얼마에요 ?
점원 : 100만원 입니다.
손님 : 1개 구매할게요 !
점원 : 결제는 어떻게 하시겠어요 ?
손님 : 신용카드로 3개월 할부할게요.
점원 : 결제되셨습니다.

일반적으로 우리가 마트에서 노트북을 구매할 때는 이렇게 구매하는데, 이건 Stateful과 동일합니다.

점원은 손님의 상태 (구매하려는 모니터, 구매 수량 등)을 기억하고 있기 때문에 이러한 대화가 가능합니다.

 

하지만 Stateless에서는 위처럼 한다면 아래와 같습니다.

손님 : 이 모니터 얼마에요 ?
점원 : 100만원 입니다.
손님 : 1개 구매할게요 !
점원 : 어떤 물건을 1개 구매하실건가요 ?
손님 : 어... 모니터 1개 구매할게요.
점원 : 모니터 1개는 어떻게 결제하실건가요 ?
손님 : 신용카드로 3개월 할부할게요.
점원 : 어떤 물건 몇 개를 신용카드 3개월 할부로 결제하실건가요 ?
손님 : 아... 모니터 1개 신용카드 3개월 할부로 결제할게요..
점원 : 결제되셨습니다.

점원이 Stateless로 대화한다면 위처럼 될 것 입니다.

점원은 손님의 상태를 기억하고 있지 않기 때문에 한 번에 필요한 정보를 모두 점원에게 알려야 합니다.

---

무상태 프로토콜을 사용하는 이유

클라이언트의 요청이 서버가 감당할 수 있는 수준이라면 괜찮겠지만, 클라이언트가 많아진다면 서버에 부하가 생기고 새로운 서버를 증설해 클라이언트의 요청을 분산시켜야 할 것입니다.

 

이때 Stateful 상태의 서버라면 새로 증설한 서버는 클라이언트의 상태를 알지 못하므로 제대로 클라이언트의 요청을 처리할 수 없게 됩니다. 증설한 서버에서도 요청이 제대로 처리되게 하기 위해서는 기존 서버에 있는 클라이언트의 상태까지 전부 다 옮겨줘야 하는 작업을 해야 합니다. 이런 방법으로는 서버를 증설할 때 시간과 비용이 많이 들어가게 됩니다.

 

위 마트의 예시에서 Stateless에서는 필요한 정보를 모두 점원에게 알려야 한다고 했습니다.

이건 역으로 필요한 정보를 모두 점원에게 알려준다면 어떤 점원에게 말해도 상관없다는 말이 됩니다.

그렇다면 서버를 증설만 해주면 클라이언트 입장에서는 어떤 서버에 요청을 해도 동일한 응답을 받을 수 있게 됩니다.

 

이처럼 클라이언트의 상태와 관계없이 서버가 동작하므로 스케일링에서 유리하다는 장점이 있습니다.

(스케일링 : 클라이언트가 집중되는 경우 서버의 부하 발생을 완화시키기 위해서 서버의 개수를 늘리거나 스펙을 변경하는 것)

---

실무적인 한계

모든 것을 무상태로 설계할 수 있다면 좋겠지만 실제로는 그렇게 하는 못하는 것들이 많습니다.

랜딩페이지와 같이 로그인이 필요없는 화면들은 무상태로 설계가 가능하지만,

사용자의 인증정보가 필요한 서비스들은 어쩔 수 없이 상태를 계속 유지해야만 합니다.

---

 

 

---

비연결성

---

 

 

 

비연결성

클라이언트와 서버가 연결을 한 번 하고 종료하기 전까지 계속해서 연결이 되어있다면 서버의 자원을 계속해서 잡아먹을 것 입니다.

그래서 HTTP는 요청을하고 응답을받으면 바로 연결을 끊어버리는 특징을 가지고 있습니다.

이렇게하면 연결하고 응답할 때까지만 자원을 할당하면 되므로 낭비를 막을 수 있습니다.

---

한계점

요청마다 TCP/IP 연결을 새로 맺어야 하므로 3way-handshake하는 시간이 추가되서 속도가 매우 느려진다는 단점이 있습니다.

이는 HTTP의 지속연결 기능으로 문제를 해결했습니다.

지속연결에 대한 설명은 이 글에 적어두었습니다.