🙌 이전 포스팅 참고
📕 HTTP는 클라이언트-서버 구조이다.
📖 클라이언트-서버 구조 == Request-Response
HTTP 는 Request-Response 구조를 따른다.
- Request : 클라이언트가 서버에 요청을 보내며 응답을 대기
- Response : 서버는 요청에 대한 결과를 만들어 제공
단순하다 느낄순 있겠지만, 위 구조의 핵심은
클라이언트와 서버를 분리시켰다 라는 점이다.
예전에는 클라이언트와 서버가 분리되어있지않았기에, 한 공간에서 모든작업을 하였다. 현재는 아래처럼 클라이언트와 서버가 분리되어 각자 맡은 바를 열심히한다.
1. 서버 : 비즈니스 로직이나 데이터는 모두 서버가 관리한다.
2. 클라이언트 : UI와 사용성에 집중한다.그 결과 클라이언트와 서버가 독립적으로 발전할 수 있게 되었다.
📕 HTTP는 Stateless 를 선호한다.
📖 stateful과 stateless의 차이
stateful과 stateless를 구분짓는 방법은 서버가 클라이언트의 상태를 보존하는가? 이다.
여기서 클라이언트의 상태란 클라이언트가 서버에게 보낸 데이터의 결과물로 만약 상태를 유지한다고하면, 사용자가 홈페이지에 계정과 비밀번호를 입력한후 로그인을 하면 로그인 상태가 유지되는것과 같다.
stateful은?
1.클라이언트의 상태를 보존
2.항상 같은 서버가 유지되어야 함
3.중간에 서버가 장애가나면? 큰일남
4.서버가 변경될경우 보존하였던 상태를 전달해주어야함 stateless는?
1.클라이언트의 상태를 보존하지않음
2.아무서버나 호출하면 됨
3.중간에 서버가 장애가 나도 다른 서버에서 처리하면 됨
4.서버가 변경되어도 문제 없음📖 HTTP는 stateless를 선호한다.
HTTP를 stateless로 할 수 있는게 있고 할 수 없는게 있다.
stateless의 특징
- 장점 : 서버 확장성이 높음 (스케일 아웃)
- 아무 서버나 응답을 해주면 되기 때문에
- 단점 : 클라이언트가 추가 데이터 전송을 해줘야한다.
- 예) 옷 3개를 신용카드로 구매한다. (옷은 한제품만있다)
- stateful이라면 상태를 보존하므로 요청을 세번하면된다. (옷 / 3개 / 신용카드)
- stateless는 상태를 보존하지않으므로 요청할 때 한번에 줘야한다. (옷+3개+신용카드)
실무에서의 stateless
모든것을 stateless로 설계할수는 없다. (불가능한 경우 존재)
하지만, stateful은 최소한으로 사용하도록 하자.
- stateless : 로그인필요없는 단순 소개화면
- stateful : 로그인
📚Reference
본 포스팅은 인프런-김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 내용을 토대로 작성하였습니다. 진짜 강의도 너무 좋고 강의 타임도 짧은데다, 저렴하니 들어보면 좋을거같습니다.
유능한 개발자가 되고 싶은 헬린이