[SPRING] 상태없는 서버는 어떻게 작동합니까?

상태없는 서버는 어떻게 작동합니까?

나는 이것을 이해하려고 노력한다. 일반적으로 사용자 로그인 시스템마다 서버 측에서 세션을 생성하고 사용자 클라이언트 측에서는 쿠키를 생성합니다. 사람들이 무국적 서버 측, 스테이트 풀 클라이언트 측에 관해 이야기 할 때, 그들은 무엇을 의미합니까? 서버 측 세션을 사용하지 않아도 세션을 추적 할 수 있습니까? 클라이언트 측의 쿠키 만 사용하여 사용자를 확인합니까? 서버를 변경하면 사용자는이를 알지 못하고 서비스를 계속 사용할 수 있습니까?

이 작업을 수행하기 위해 스프링 보안을 구성하는 방법은 무엇입니까?

해결법

1. ==============================

   1.진정한 상태 비 저장 서버 측에서는 서버에서 사용자를 추적하는 것이 까다로운 작업입니다. 대부분 로그인은 예외 인 일종의 상태 비 저장 서버입니다. 그러나 무 상태 서버의 큰 문제는 클러스터링을 매우 단순하게 만들어 수평으로 확장 할 수 있다는 것입니다.

   진정한 상태 비 저장 서버 측에서는 서버에서 사용자를 추적하는 것이 까다로운 작업입니다. 대부분 로그인은 예외 인 일종의 상태 비 저장 서버입니다. 그러나 무 상태 서버의 큰 문제는 클러스터링을 매우 단순하게 만들어 수평으로 확장 할 수 있다는 것입니다.

   Java에서는 쿠키를 사용하여 자격 증명을 저장하거나 분산 된 해시를 사용하여 상태를 변경할 수 있습니다. 일반적으로 사람들은 memcache와 같은 것을 사용하고 상태는 웹 서버 외부에 저장되기 때문에 stateless라고 말합니다. 따라서 사용자는 팜의 모든 웹 서버를 사용할 수 있으며 안전하게 인증 할 수 있습니다. 자바에서는 Spring과 함께 사용할 수있는 많은 분산 형 해시 구현을 가지고 있으므로 memcache를 사용하지 않아도됩니다.

   다른 옵션은 쿠키를 사용하여 HMAC라고하는 암호화 된 보안 해시 티켓을 저장하는 것입니다. 쿠키를 사용하면 세션 사용을 피할 수 있으므로 웹 서버는 stateless입니다. HMAC를 사용하면 제 3자가 위조하거나 생성 할 수없는 데이터 블록에 서명 할 수 있으며, 이는 사용자의 출처임을 보증합니다. 이렇게하면 사용자를 인증하기 위해 외부 서버 리소스 (캐시)가 필요 없으므로 확장 성이 뛰어날 수 있지만 사용자는주의해야 할 몇 가지 보안 문제가 있습니다. FYI Google은이 기술을 사용하여 수평으로 확장합니다. 하나의 HMAC는 SHA1이나 다른 cyrpto 해시와 다릅니다. 팜의 각 서버에 있어야하는 비밀 키가 필요합니다. 또한 대칭 암호화 키로 보호해야만 누군가가 파일을 보냈을 때 서버에 안전하게 저장되어 있는지 확인할 수 있습니다. 또한 HMACs 정보는 사용자 이름이나 전자 메일을 쿠키에 넣을 수있는 동안 실제 암호 해시를 모든 사람이 사용할 수 있도록 일반인에게 저장됩니다. 누군가가 그 쿠키를 알면 해당 사용자로 가장 할 수 있습니다. 그래서 HMAC는 대개 일정 기간 동안 만 유효합니다. 그 후에 만료되므로 다른 사람이 그 계정에 액세스하면 영원히 계정에 액세스 할 수 없습니다.

   그래서 HMAC는 이러한 약점이 있으며 어떤 애플리케이션을 사용하는지 조심해야합니다. Paypal이이 계획을 사용하는 것은 정말 나쁜 생각입니다. 왜냐하면 내가해야하는 일은 보안 쿠키를 얻은 다음 모든 금액을 나에게 이전하기 때문입니다. 커다란 단점은 앱이 진정으로 무국적이라는 것입니다.

   마지막 옵션은 자바 세션을 분산 된 해시에 저장하는 것입니다. PHP 및 다른 플랫폼은 세션을 데이터베이스에 덤프하고 빈민은 분산 캐시를 사용하거나 memcache에 덤프합니다. Java를 사용하면 동일한 작업을 수행 할 수 있습니다. 세션 객체를 분산 캐시에도 넣을 수 있습니다. 사람들이 "멋지다"고 생각하기 때문에이 옵션은 부끄럽지 않습니다. 이제는 원하는 세션을 덤프 할 수 있으며 무국적 상태가됩니다. " 그러나 모든 분산 캐시와 마찬가지로 전송 속도, 복제 시간 및 페이로드 크기에 제한이 있습니다. Java 또는 Memcache의 경우에도 마찬가지입니다. 세션을 작게 유지하면 잘 작동합니다. 세션에 모든 것을 던지면 단일 서버에서 발생하는 확장 문제로 바로 돌아갑니다. 그리고 때로는 그리드 컴퓨팅이 단일 서버보다 나빠지므로 서버를 상태 저장하게 만든 것보다 실제로는 더 나을 것입니다.

   업데이트 : 다음은이를 수행하는 데 사용할 수있는 Java 분산 캐싱 라이브러리 목록입니다.

   http://www.manageability.org/blog/stuff/distributed-cache-java

2. ==============================

   2.Stateless 서비스는 응용 프로그램 서버에 데이터를 저장하지 않는 서비스입니다. 그것은 데이터를 읽거나 데이터베이스에 쓰고, 값을 리턴하며, 그 후에는 태스크 자체에 대한 정보를 잊어 버립니다.

   Stateless 서비스는 응용 프로그램 서버에 데이터를 저장하지 않는 서비스입니다. 그것은 데이터를 읽거나 데이터베이스에 쓰고, 값을 리턴하며, 그 후에는 태스크 자체에 대한 정보를 잊어 버립니다.

   상태 저장 서비스는 트랜잭션을 수행하는 데 사용됩니다. 즉, 이전 작업 결과에 의존하는 일련의 작업입니다. 가장 쉬운 예는 장바구니에서 상품을 모으는 웹 스토어에서 주문을 보내는 것입니다. 체크 아웃하면 한 페이지에 계정 데이터를 입력하고 저장 한 다음 청구서 수신 주소를 입력하고 저장 한 다음 주문을 확인하고 거래를 완료하십시오. 각 단계는 이전 단계의 성공적인 결과에 따라 달라지며이 단계 중 마지막 단계가 완료되거나 거래가 취소 될 때까지 데이터를 보존해야합니다.이 경우 계정 잔액을 복원하려면 롤백해야합니다. 네가 체크 아웃하기 전에 그랬어.

   대부분의 경우 두 가지 방법으로 트랜잭션을 구현할 수 있지만 상태없는 서비스를 사용하려면 클라이언트 응용 프로그램이 적절한 순서와 작업 완료를 처리해야합니다. 그렇지 않으면 다른 방법으로 트랜잭션 정보를 올바르게 관리하고 롤백을 관리합니다. 당신이 전화를 걸면 그것은 진실한 클라이언트 측이 될 것입니다.

   그러나 이것 모두는 매우 일반적이며, 보안 및 / 또는 세션 처리는 각각의 경우에 고려되어야합니다. 세션 정보를 사용하여 상태 비 저장 서비스 호출을 인증 할 수 있습니다. 예를 들어 세션 ID 나 사용자 ID 또는 기타 보안 토큰을 비즈니스 데이터에 연결하는 등 각 호출을 개별적으로 인증하면됩니다.

from https://stackoverflow.com/questions/4495950/how-do-stateless-servers-work by cc-by-sa and MIT license