클라이언트는 서버에게 Request를 보내고, 서버는 클라이언트에게 Response를 보낸다.
각기 다른 클라이언트들이 하나의 서버에 요청을 보낼 수 있는데, 모두 다른 방식으로 요청을 보내면 서버가 일일이 대응할 수가 없다. 따라서 HTTP라는 통신규약을 지정하여 모든 요청과 응답은 HTTP 양식에 맞게 보내야 한다.
HTTP의 특성
Connectionless
HTTP 통신을 하기 위해서는 클라이언트와 서버가 연결이 되어있어야 한다. 이 커넥션을 유지하는 것 자체도 부담이고, 클라이언트가 늘어나서 커넥션의 개수가 많아지면 서버에 많은 부담이 된다. 따라서 HTTP는 통신을 한 번 할 때 클라이언트와 서버를 연결하고, 통신이 끝나면 바로 연결을 끊는다. 이를 통해 서버 자원을 효율적으로 관리하고 여러 클라이언트의 요청에 대응한다. 한 클라이언트가 여러번의 요청을 보내도 커넥션은 계속 끊어졌다, 연결됐다를 반복한다. 이러한 HTTP의 특성을 Connectionless라고 한다. (HTTP 1.1부터 일정 시간동안 계속 요청을 보내면 한번의 커넥션 연결로 처리하며 이를 지속 커넥션이라 한다.)
장점
- 서버의 부하를 줄여서 더 많은 클라이언트의 요청을 처리할 수 있다.
단점
- 커넥션을 계속 끊어버리기 때문에 여러번 요청한 클라이언트와 커넥션을 계속 새로 만들어주어야 한다.
Stateless
HTTP는 이전 요청의 상태를 기록하지 않기 때문에 서버는 클라이언트를 식별할 수 없다. 커넥션이 계속 연결되어 있으면 요청을 보낸 클라이언트가 누구인지 지속적으로 파악할 수 있지만, 커넥션은 끊어지기 때문에 다음번 요청이 이전에 요청을 보낸 클라이언트인지 새로 요청을 보낸 클라이언트인지 알 수 없다. 또한 서버는 클라이언트의 상태를 보존하지 않는다. 즉, 이전 요청이 어떻게 끝났느냐에 따라 다음 요청이 영향을 받지 않고 모든 요청이 독립적이다. 따라서 클라이언트를 식별할 수 없다. 예시를 통해 Stateless를 살펴보자. 아래는 아이스 아메리카노 2잔을 주문하는 상황이다.
Stateful의 경우, 클라이언트가 여러번에 걸쳐 주문을 진행해도, 카페 직원은 여태까지의 주문 사항을 기억하고 있으므로 정상적으로 주문을 처리할 수 있다.
Stateless의 경우, 카페 직원은 클라이언트가 한 말을 바로 잊어버린다. 따라서 클라이언트가 아메리카노를 주문하고 "차가운 거요"라고 주문하면, 카페 직원은 "어떤걸 차갑게 달라는거죠?"라고 응답하게 된다. 이전 상태를 보존한다면 이전 요청의 내용을 기억하여 다음 요청에 반영할 수 있다. 그러나 Stateless는 이전 요청이 무엇이었는지 기억하지 않기 때문에 한 번의 요청에 모든 내용을 다 전달해야 한다.
서버는 여러대의 컴퓨터로 구성될 수도 있다. 마찬가지로 카페 직원도 여러 명일 수 있다.
Stateful인 경우, 카페 직원이 인수인계 없이 중간에 교체되면 주문을 정상적으로 처리할 수 없다. 마찬가지로 서버 컴퓨터끼리 요청 사항이 공유되지 않은 상태에서, 다른 서버 컴퓨터가 요청을 받으면 제대로 된 응답을 처리할 수 없다.
Stateless의 경우, 모든 주문 사항을 한번에 말하므로 어느 카페 직원이 주문을 받더라도 처리할 수 있다. 마찬가지로 요청 한번에 모든 요구사항이 들어있기 때문에 어떤 서버 컴퓨터가 요청을 받아도 제대로 응답을 처리할 수 있다.
장점
- 이전 요청을 기억할 필요가 없으므로, 이를 위한 저장 공간이 필요 없다.
- 서버 디자인을 단순하게 만든다.
- 서버가 여러 대의 컴퓨터로 구성된 경우, 어떠한 컴퓨터가 요청을 받더라도 응답이 가능하다.
단점
- 클라이언트를 식별하기 어렵다.
- 매 요청마다 추가 정보가 주어야 한다.
'TIL > 웹의 이해' 카테고리의 다른 글
CSR vs SSR 차이와 장단점 비교 (0) | 2022.11.26 |
---|---|
대표적인 렌더링의 종류 (0) | 2022.11.21 |
HTTP (0) | 2022.08.31 |
[API] RESTful API (0) | 2022.08.14 |
Software Testing (0) | 2022.08.06 |