From 33b3ac43ec463ee910ff74ff66043fe7fa8c2403 Mon Sep 17 00:00:00 2001 From: jin Date: Thu, 20 Jun 2024 16:36:08 +0900 Subject: [PATCH 1/2] Fix wrong letter MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 오타 및 내용 오류를 수정했습니다. --- "django/\354\236\245\352\263\240 \353\252\250\353\215\270.md" | 2 +- ...6\245\352\263\240 \355\205\234\355\224\214\353\246\277.md" | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git "a/django/\354\236\245\352\263\240 \353\252\250\353\215\270.md" "b/django/\354\236\245\352\263\240 \353\252\250\353\215\270.md" index 7db2b9a..887b66f 100644 --- "a/django/\354\236\245\352\263\240 \353\252\250\353\215\270.md" +++ "b/django/\354\236\245\352\263\240 \353\252\250\353\215\270.md" @@ -41,7 +41,7 @@ ___ ORM은 모델이 DB와 통신할 수 있게 매핑을 진행한다. 즉, ORM은 파이썬 객체로 정의된 장고 모델을 실제 데이터베이스의 테이블과 대응 시키는 작업을 수행한다. ORM을 활용하면 파이썬 객체가 데이터베이스와 대응되며 raw query가 아닌 파이썬 메서드나 파이썬 내부의 처리를 통해 DB와 통신하는 것이 가능해진다. -이러한 형태로 통신하는 방식이 바뀐다고 생각하면 좋다. 중간에 ORM이라는 단계가 생성되며 DB와 파이썬 사이의 결합도가 낮아진 것을 확인할 수 있다. +이러한 형태로 통신하는 방식이 바뀐다고 생각하면 좋다. 중간에 ORM이라는 단계가 생성 되며 DB와 파이썬 사이의 결합도가 낮아진 것을 확인할 수 있다. ```mermaid flowchart LR diff --git "a/django/\354\236\245\352\263\240 \355\205\234\355\224\214\353\246\277.md" "b/django/\354\236\245\352\263\240 \355\205\234\355\224\214\353\246\277.md" index b039bb3..81ac838 100644 --- "a/django/\354\236\245\352\263\240 \355\205\234\355\224\214\353\246\277.md" +++ "b/django/\354\236\245\352\263\240 \355\205\234\355\224\214\353\246\277.md" @@ -348,7 +348,7 @@ pass.html에서 title만 따로 분리해 별도의 템플릿으로 정의했다 ___ ### 템플릿 상속 -실제 프로덕션 환경에서의 장고는 더욱 크고, 복잡한 구조로 동작한다. 이러다 보면 단순히 포함하는 것이 아니라 **템플릿을 약간의 수정을 해서 재정의 하고 싶다는 오버라이딩과 비슷한 욕구가 발생하게 된다. 이러한 요구를 해결하기 위해 템플릿의 상속이라는 개념**이 도입 됐다. +실제 프로덕션 환경에서의 장고는 더욱 크고, 복잡한 구조로 동작한다. 이러다 보면 단순히 포함하는 것이 아니라 **템플릿에 약간의 수정을 가해서 재정의 하고 싶다는 오버라이딩과 비슷한 욕구가 발생하게 된다. 이러한 요구를 해결하기 위해 템플릿의 상속이라는 개념**이 도입 됐다. 불합격 메일을 작성하는 예시를 보며, 템플릿 상속의 필요성을 확인해보자. 불합격 메일은 다음과 같이 작성해 볼 수 있을 것이다. @@ -364,7 +364,7 @@ ___ ``` -기존에 `include`를 사용해 처리하던 `title` 태그의 내용이 바뀜에 따라 별도의 `title` 태그를 정의해 상요하는 것을 확인할 수 있다. 태그 내부의 내용만 바꿔서 재활용 할 수는 없을까? 템플릿도 인터페이스와 같이 공통된 요소들로 추상화를 진행한 후 별개로 구현하는 방식으로 동작 시킬 수는 없을까? 이러한 요구로 인해 등장한 것이 템플릿의 상속이다. 장고 공식 문서에서는 템플릿의 상속을 아래와 같이 설명한다. +기존에 `include`를 사용해 처리하던 `title` 태그의 내용이 바뀜에 따라 별도의 `title` 태그를 정의해 사용 하는 것을 확인할 수 있다. 태그 내부의 내용만 바꿔서 재활용 할 수는 없을까? 템플릿도 인터페이스와 같이 공통된 요소들로 추상화를 진행한 후 별개로 구현하는 방식으로 동작 시킬 수는 없을까? 이러한 요구로 인해 등장한 것이 템플릿의 상속이다. 장고 공식 문서에서는 템플릿의 상속을 아래와 같이 설명한다. > The most powerful – and thus the most complex – part of Django’s template engine is template inheritance. ***Template inheritance allows you to build a base “skeleton” template that contains all the common elements of your site and defines blocks that child templates can override.*** From 7d662506070871b4206fa205a24a87bcae8d1d36 Mon Sep 17 00:00:00 2001 From: Seoneui Date: Tue, 23 Jul 2024 18:00:15 +0900 Subject: [PATCH 2/2] =?UTF-8?q?assignment=20:=20=EC=84=A0=EC=9D=98=20?= =?UTF-8?q?=EA=B3=BC=EC=A0=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit stateful VS stateless --- assignment/stateful VS stateless.md | 114 ++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 assignment/stateful VS stateless.md diff --git a/assignment/stateful VS stateless.md b/assignment/stateful VS stateless.md new file mode 100644 index 0000000..78c4a96 --- /dev/null +++ b/assignment/stateful VS stateless.md @@ -0,0 +1,114 @@ + +"클라이언트(Client)와 서버(Server)간의 통신을 상태유지(Stateful) 하느냐, 상태유지하지않음(Stateless) 으로 하느냐" + +--- +## stateful? + +클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존**함을 의미하는게 상태유지 +자세히 말하자면 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태를 말함 + +예를 들어 홈 페이지에서 한 번 로그인 하면 페이지를 이동해도 로그인이 풀리지 않고 계속 유지되는 이유가 서버가 클라이언트의 상태를 기억하고 있기 때문에 가능한 것 + +### stateful 문제점 + +위에서 상태를 유지한다는 함은, 서버에서 클라이언트의 상태 정보를 저장하고 있는 것 +그렇다면 stateful의 문제점은 **해당 서버가 멈추거나 여러 이유로 해당 서버가 못쓰게** **되어** **다른 서버를 사용해야 할때** 발생함 +왜냐하면 새로운 서버에는 이전 서버에서 가지고 있던 상태값을 가지고 있지 않기 때문 + +--- +## stateless? + +클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존하지 않음**을 의미하는게 무상태 +즉, stateless 구조에서 **서버는 단순히 요청이 오면 응답을 보내는 역할만 수행**하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것 + +클라이언트와 서버간의 **통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것**이 무상태 구조임 + +### stateless 문제점 + +무상태의 단점으로는 클라이언트의 요청에 상대적으로 Stateful 보다 **더 많은 데이터가 소모**되게 된다는 점임. 매번 요청할때마다 자신의 부가정보를 줘야함 + +물론 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버리게 됨 + +따라서 모든 것을 무상태로 설계할 수 없음. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트 + +### stateless와 token + +무상태의 특징으로 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이기에 서버는 단순히 받아서 응답만 해주기 때문에 서버에 대한 부하가 현저히 줄어듦 + +하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기기에 부담스러울 수 있음 + +그래서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 **JWT 토큰**임 +(토큰 : 토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됬음을 인증하는 방식) + +--- + +## 그래서 둘의 차이점은? + +| | Stateful | Stateless | +| --- | --------------------------------------------------- | ---------------------------------------------------------------- | +| 정의 | 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜 | 클라이언트의 요청에 따른 응답만 처리하는 네트워크 프로토콜 | +| 예시 | TCP, FTP, Telnet 등 | HTTP, UDP, DNS 등 | +| 설계 | 캐시서버가 별도로 필요할 수 있으며 서버에서 세션을 관리하기 때문에 난이도 있는 구현이 필요 | 세션정보관리를 클라이언트가 담당하므로, 경우에 따라 JWT같은 방식이 필요할 수 있으며, 비교적 간단한 설계가 가능 | +| 관리 | 서버에서 세션을 직접 저장하고 있기 때문에 확장이 까다로움 | 서버에서는 단순한 응답만을 처리하기에 추후 확장에 용이함 | + +**stateful 서버**는 클라이언트에게 요청을 받을 때 마다 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스 제공에 이용 + +**stateless 서버**는 상태를 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리 +클라이언트와 서버의 연결고리가 없기 때문에 서버의 확장성이 높아짐 + + +--- + +## (추가) Sesssion, Token + +HTTP는 본래 정보를 유지하지 않는 **statless**한 특성을 가져, 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요 + +### 쿠키 + 세션 + +쿠키에 ID, PW와 같은 중요한 정보가 아닌, 인증을 위한 별개의 정보를 세션 저장소에 저장하고, 클라이언트는 세션을 쿠키에 담아 서버에 요청 +서버는 세션 저장소에 있는 세션과 일치하는지 즉, 유효한 세션인지 확인 후 적절한 응답을 보내주게 됨 + +동작은... + +- 클라이언트가 ID/PW로 서버에 로그인 +- ID/PW로 인증 후, 사용자를 식별한 특정 유니크한 세션 ID를 만들어 마치 자물쇠처럼 서버의 세션 저장소에 저장 +- 세션 ID를 특정한 형태로 클라이언트에 다시 반환 +- 이후 사용자 인증이 필요한 정보를 요청할 때마다 세션 ID를 쿠키에 담아 서버에 함께 전달 +- 인증이 필요한 API일 경우, 서버는 세션 ID가 세션 저장소에 저장된 것인지 즉 유효한 세션인지 확인 +- 유효한 세션이라면, 인증 완료 후 적절한 응답을 보내준다. 없다면 401 에러 반환 + +이렇게 세션으로 로그인 한다면 HTTP의 가장 큰 특성 중 하나인 stateless한 특성을 위배하게 됨 +stateless 특성은 서버에서는 클라이언트의 상태를 저장하지 않아야 하지만 세션 저장소라는 곳에서 클라이언트의 상태를 저장하게 되므로 stateful 한 상태가 됨 + +### 토큰 - JWT + +동작은... + +- 사용자는 클라이언트에서 ID/PW를 통해 로그인을 요청 +- 유효한 ID/PW라면, Access token & Refresh token을 발급 +- 클라이언트는 전달 받은 토큰들은 localStorage에 저장 +- 클라이언트는 헤더에 Access token을 담아 서버에 요청 +- 서버에서는 Access token을 검증하고, 응답을 클라이언트로 보냄 + - Access token이 유효하지 않다면 Refersh token으로 Access token을 재발급한 뒤, access token을 리턴해줌 + +장점으로는... + +- 인증에 필요한 정보가 토큰에 있기에 별도의 저장소가 필요없다. + - 하지만, 보안성을 높이기 위해 Refresh Token을 사용하는 경우 별도의 저장소에 저장하면서 사용하는 경우도 있긴 하다. +- Cookie와 Session 사용 시 문제점이였던 stateful 한 특성을 JWT 토큰 사용 시에는 stateless 하게 가져갈 수 있다. 즉, 서버는 클라이언트의 상태를 가질 필요가 없다. + +### 세션과 토큰 차이점 정리 + +- stateful과 stateless 하다는 측면에서 차이점이 존재 + - 이는 토큰이 탈취됐을 때, 서버에서 능동적으로 이에 대응하여 토큰을 폐기처리할 수 있냐 없느냐에 따라 직결됨 + + +--- + +## 출처 + +[https://inpa.tistory.com/entry/WEB-📚-Stateful-Stateless-정리#stateless_무상태](https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC#stateless_%EB%AC%B4%EC%83%81%ED%83%9C) [Inpa Dev 👨‍💻:티스토리] + +https://velog.io/@cv_/Stateful%EA%B3%BC-Stateless-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0 + +https://velog.io/@ddangle/Session%EC%84%B8%EC%85%98%EA%B3%BC-Token%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%8A%94 \ No newline at end of file