<목차>
1. HTTP 프로토콜
2. 서버/클라이언트 모델
3. 상태 유지(Stateful), 무상태(Stateless)
4. 비연결성(Connectless)
HTTP 프로토콜
HTTP(Hyper Text Transfer Protocol)는 웹 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 기반으로 동작하는 프로토콜이다. 즉, 클라이언트가 서버에 요청(Request)을 보내면 서버는 응답(Response)을 보내는 형태로 동작한다.
팀 버너스 리에의해 만들어 졌으며, 이를 통해 최초의 웹 브라우저와 웹 서버가 만들어 졌다.
이로 인해 월드 와이드 웹의 기초가 세워졌고, HTTP는 웹 상에서 데이터를 주고받기 위한 표준 프로토콜이 되었다.
서버/클라이언트 모델
서비스 요청자인 `클라이언트`와 서비스 자원의 제공자인 `서버` 간에 작업을 분리해주는 분산 애플리케이션 구조이자 네트워크 모델이다.
서버 : 데이터를 저장하고 관리하는 역할을 하며, 클라이언트의 요청에 응답한다.
클라이언트 : 서버에 요청을 보내고, 서버로부터 데이터를 받는 역할을 한다.
HTTP는 무상태성, 비연결성이라는 특징을 가지고 있다.
무상태성...?, 비연결성...? 잘 모르겠다.
무상태성을 알려면 그 반대 개념인 상태 유지에 대해서도 알아야 이해가 쉬울것 같았다.
상태유지(Stateful), 무상태(Stateless)
Stateful(상태 유지)
상태 유지는 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다.
클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태이다.
예시
고객 : 사과 하나에 얼마인가요?
점원 : 1500원 입니다. (사과를 사려한다는 것을 기억한다.)
고객 : 2개 주세요.
점원 : 3000원 입니다. 결제는 현금으로 할까요 카드로 할까요? (사과를 사려한다는 것을 기억하고 있다.)
고객 : 카드로 해주세요.
점원 : 3000원 결제 되었습니다. (고객이 요구했던 사항을 모두 기억하고 있다.)
점원이 고객의 말을 기억하고 있어야지만 위의 예시와 같은 대화가 가능하다. 3000원을 결제하려면 사과를 구매한다는 사실과 2개를 주문했다는 사실을 기억하고 있어야 한다는 뜻이다.
위 예시와 같이 서버에서 클라이언트가 요구한 무언가를 기억하고 있다가 응답해 준다는 것.
상태 유지(Stateful)의 문제점
상태 유지의 문제점은 상태를 기억하고 있는 서버가 멈추거나 여러 이유로 사용이 불가능해지게 되어 다른 서버를 이용해야 할 때 발생한다.
새로운 서버는 이전 서버에서 가지고 있던 상태값들에 대한 정보가 없기 때문이다.
유저가 로그인을 하고 게시판 페이지에 들어가서 글을 쓰기 위해 [글쓰기] 를 눌렀더니 다시 로그인 하라는 화면이 뜨는 것이다. 이는 클라이언트의 로그인 정보를 들고 있는 서버가 어떠한 문제로 인해 다운되어 다른 서버가 대신 역할을 이어 받았는데 해당 클라이언트의 로그인 정보가 없기 때문에 일어난 것이다. (만약, 기존서버에서 새로운서버로 이전 데이터를 모두 전달해준다면 문제가 없을 수 있다)
즉, 서버 1이 내 정보를 갖고 있기 때문에 중간에 서버 1에 장애가 생기면 클라이언트 A는 일을 처음부터 다시 해야된다.
또한 상태 유지 방식은 하나의 서버가 1만 명의 클라이언트를 처리할 능력이 있을 때 그보다 많은 수의 클라이언트가 몰리면, 이미 연결된 1만 명의 클라이언트 중 일부가 빠져야 다음 클라이언트가 처리된다는 한계가 있다.
클라이언트 상태들을 가지고 있으니 용량 한계가 존재하기 때문이다.
무상태(Stateless)
무상태는 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다.
무상태에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 상태 관리는 전적으로 클라이언트에게 책임이 있다는 것이다.
즉, 통신에 필요한 모든 상태 정보들을 클라이언트가 가지고 있다가 서버와 통신할 때 데이터를 실어 보내는 것이 무상태 이다.
예시
고객 : 사과 하나에 얼마인가요?
점원 : 1500원 입니다. (아무것도 기억하지 않는다.)
고객 : 사과 2개 주세요.
점원 : 3000원 입니다. 결제는 현금으로 할까요 카드로 할까요? (아무것도 기억하지 않는다.)
고객 : 사과 2개 카드로 결제해 주세요.
점원 : 3000원 결제 되었습니다. (아무것도 기억하지 않는다.)
이번에는 점원이 고객의 말을 기억하고 있지 않아도 대화가 가능하다. 고객의 말에 필요한 정보가 모두 담겨있기 때문이다.
서버는 단순히 받아서 응답만 해주기 때문에 상태 유지에 대한 부하가 현저히 줄어들게 된다.
또한, 상태를 보관하지 않아 서버 1에 문제가 생겨 서버 2가 이어 받아도 응답하는데 있어 문제도 없다.
대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다는 장점도 있다. (stateful과 달리 서버가 바뀌어도 정확한 응답에 문제가 없기 때문)
이러한 Stateless 프로토콜에도 한계점이 존재한다. 웹 서비스를 설계할 때 무상태로 설계할 수 없을 서비스가 존재하기 때문이다. 로그인이 필요 없는 단순한 서비스 소개 화면이라면 무상태로 설계할 수 있지만, 로그인을 제공하는 서비스라면 사용자가 로그인했다는 상태를 서버에 유지해야만 한다.
하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기게 된다. 따라서, 특별한 일이 없다면 무상태를 지향해야하며 정말 필요한 경우에만 상태 유지를 해야한다.
무상태 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술중 하나가 JWT 토큰이다.
비연결성(Connectless)
비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클 라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말한다.
즉, 서버가 클라이언트와의 연결을 계속 유지하는 것이 아니라, 하나의 요청에 대한 응답이 끝나면 연결을 끊는것을 말한다.
비연결성의 필요성
HTTP 프로토콜은 왜 비연결성이 필요했을까?
HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 불특정 다수가 연결을 계속 지속하고 있다면 굉장히 많은 비용이 발생하게 될 것이다. (연결이 되어있다는 것은 서버의 자원을 계속 소비하고 있다는 뜻이기 때문이다.)
비용을 최소화 하기 위해서 비연결성이 필요해진 것.
비연결성의 문제점
연결을 유지하지 않기 때문에 요청이 있을 때마다 TCP의 3way 핸드쉐이크 과정이 일어난다는 것을 의미하는데 3way 핸드쉐이크는 상대적으로 시간이 오래 걸리는 연결이다. 이러한 연결을 요청이 발생할 때마다 새로 해줘야 하는 것은 비효율적일 수밖에 없다.
또한, 웹 브라우저에서 웹 사이트를 하나 요청하면 HTML 뿐만 아니라, CSS, JavaScript, 추가 이미지 등 수많은 자원이 함께 다운로드되는데 이는 한 번 사이트를 요청할 때 각각의 자원을 따로따로 처리해야 한다는 의미이다.
이러한 단점을 극복하기 위해서 HTTP 지속 연결(Persistent Connections)이 등장했다.
지속 연결 또한 문제점을 가지고 있지만 그것은 추후에 살펴보도록 하자.
갑자기 떠오른 궁금한점1
왜 HTTP를 사용하지? TCP를 사용하면 되지 않나?
개발자 입장에서 웹에서 tcp 통신을 사용할 경우 transport계층보다 상위 계층들의 모든 header와 연결 처리를 직접 구현해야한다.
(HTTP를 사용할 경우 브라우저에서 알아서 처리한다.)
또한, TCP는 연결을 유지하는 통신이다보니, 데이터 통신 속도는 HTTP보다 빠를지 몰라도 유지하는 만큼 자원의 소비가 더 크다.
결론적으로, 웹과 같이 단순한 데이터 교환을 위한 연결은 HTTP가 좋다.
그리고 게임과 같이 실시간 통신이 필요하다면 TCP 혹은 UDP통신이 좋다.
참고자료
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC
https://rob-coding.tistory.com/18
https://victorydntmd.tistory.com/286