끈적 끈적하고 비 스틱 세션


255

끈적 끈적한 세션과 끈적 거리지 않은 세션의 차이점을 알고 싶습니다. 인터넷에서 읽은 후 이해 한 내용 :

고정 : 단일 세션 개체 만 있습니다.

고정되지 않은 세션 : 각 서버 노드에 대한 세션 객체

답변:


612

웹 사이트가 하나의 웹 서버에서만 제공 될 때 각 클라이언트-서버 쌍에 대해 세션 개체가 만들어지고 웹 서버의 메모리에 남아 있습니다. 클라이언트의 모든 요청은이 웹 서버로 이동하여이 세션 객체를 업데이트합니다. 상호 작용 기간 동안 일부 데이터를 세션 오브젝트에 저장해야하는 경우이 데이터는이 세션 오브젝트에 저장되며 세션이 존재하는 한 계속 유지됩니다.

그러나로드 밸런서 뒤에있는 여러 웹 서버에서 웹 사이트를 제공하는 경우로드 밸런서는 각 요청에 대한 실제 (물리적) 웹 서버를 결정합니다. 예를 들어,로드 밸런서 뒤에 3 개의 웹 서버 A, B 및 C가있는 경우 www.mywebsite.com/index.jsp는 서버 A에서 제공 될 수 있습니다. www.mywebsite.com/login.jsp는 서버 B와 www.mywebsite.com/accoutdetails.php는 서버 C에서 제공됩니다.

이제 (물리적으로) 3 개의 서로 다른 서버에서 요청이 제공되는 경우 각 서버는 사용자를 위해 세션 객체를 생성했으며이 세션 객체는 3 개의 독립적 인 상자에 있기 때문에 세션 객체에 무엇이 있는지 알 수있는 직접적인 방법은 없습니다. 다른 사람의. 이러한 서버 세션간에 동기화하려면 DB와 같이 모든 세션에 공통 인 계층에 세션 데이터를 쓰거나 읽어야 할 수 있습니다. 이제이 사용 사례에 대해 DB에 데이터를 쓰고 DB에서 데이터를 읽는 것은 좋은 생각이 아닙니다. 이제 여기 sticky-session 의 역할이 있습니다.

로드 밸런서가 고정 세션을 사용하도록 지시받은 경우 다른 서버가 있더라도 모든 실제 상호 작용은 동일한 물리적 서버와 이루어집니다. 따라서이 웹 사이트와의 전체 상호 작용에 걸쳐 세션 개체가 동일합니다.

요약하면, Sticky Sessions의 경우 모든 요청이 동일한 실제 웹 서버로 보내지는 반면, Sticky 이외의로드 밸런서는 요청을 처리 할 웹 서버를 선택할 수 있습니다.

예를 들어 Amazon의 Elastic Load Balancer 및 고정 세션에 대한 내용은 여기 ( http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html)를 참조 하십시오.


4
@ TJ- 하나의 노드를 사용할 수 없으면 어떻게됩니까?
gstackoverflow

20
대부분의 경우 세션이 손실됩니다. 의 경우 AWS ESB 인스턴스가 실패하거나 건강에 해로운 될 경우,로드 밸런서 대신 기존의로드 밸런싱 알고리즘을 기반으로 새로운 건강한 인스턴스를 선택하고, 해당 인스턴스에 요청을 라우팅 중지합니다. 로드 밸런서는 세션을 이제 새로운 정상 인스턴스에 "고착 된"것으로 처리하고 실패한 인스턴스가 다시 돌아 오더라도 해당 인스턴스로 요청을 계속 라우팅합니다.
TJ-

8
LoadBalancer는 어떤 정보에 따라 HTTP 세션을 고정합니까? 특히 HTTPS 연결에서이 문제는 흥미로워집니다. SSL 연결을 끊고 HTTP 세션을 페치 할 수 있도록 웹 서버 개인 키로 LB를 공급합니까? 아니면 LB가 단순히 클라이언트 IP 주소를 사용합니까? 이 경우 여러 클라이언트가 동일한 IP 주소를 사용하는 프록시 서버는 어떻습니까? 또는 IP 주소가 자주 바뀌는 모바일 클라이언트? 아니면 더 나은 기술이 있습니까? 감사합니다
g000ze

6
예, 당신은 절대적으로 맞습니다. 이 문맥에서 "x-forwarded-for"헤더 또는 고정 쿠키를 사용하려면 SSL 종료 를 사용해야하므로 요청을 LB에서 해독해야합니다.
TJ-

4
@ g000ze 인터넷에 직접 제공되지 않는 응용 프로그램을 다룰 때 가장 바깥 쪽 프록시 서버에서만 TLS를 사용하는 것이 일반적이라고 생각합니다. (로드 밸런서는 여러 유형의 서버로 요청을 전달할 수있는 특수 유형의 프록시 서버로 단순화 될 수 있습니다.)로드 밸런서와 다른 서버 간의 트래픽은 로컬 보안 네트워크에서 발생합니다. 따라서 암호화 할 필요가없는 경우가 많거나 암호화해야 할 경우 자체 서명 된 인증서로 충분할 수 있습니다 (프록시가 신뢰하도록 구성 할 수 있으므로).
jpmc26

106

자세한 내용은 https://stackoverflow.com/a/11045462/592477 에서 답변을 작성했습니다.

또는 거기에서 읽을 수 있습니다 ==>

로드 밸런싱을 사용하면 여러 Tomcat 인스턴스가 있고로드를 분할해야 함을 의미합니다.

  • 고정 세션없이 세션 복제를 사용하는 경우 : 웹 앱을 사용하는 사용자가 한 명이고 Tomcat 인스턴스가 3 개 있다고 가정합니다. 이 사용자는 여러 요청을 앱에 전송 한 다음로드 밸런서는 이러한 요청 중 일부를 첫 번째 tomcat 인스턴스로 보내고이 요청 중 일부를 두 번째 인스턴스로 보내고 다른 요청을 세 번째 인스턴스로 보냅니다.
  • 복제없이 고정 세션을 사용하는 경우 :웹 앱을 사용하는 사용자가 한 명이고 톰캣 인스턴스가 3 명 있다고 가정합니다. 이 사용자는 앱에 여러 요청을 보낸 다음로드 밸런서는 첫 번째 사용자 요청을 3 개의 tomcat 인스턴스 중 하나로 보내고 세션 중에이 사용자가 보낸 다른 모든 요청은 동일한 tomcat 인스턴스로 보내집니다. 이러한 요청 중에이 Tomcat 인스턴스 (사용 된 Tomcat 인스턴스)를 종료하거나 다시 시작하면로드 밸런서는 나머지 요청을 여전히 실행중인 다른 Tomcat 인스턴스로 보냅니다. 그러나 세션 복제를 사용하지 않는 다른 Tomcat 인스턴스는 수신합니다. 나머지 요청에는 사용자 세션의 사본이 없으므로이 Tomcat의 경우 사용자가 세션을 시작합니다. 사용자가 세션을 느슨하게하고 웹 앱이 여전히 실행 중이지만 웹 앱과 연결이 끊어졌습니다.
  • 고정 세션 WITH 세션 복제를 사용하는 경우 :웹 앱을 사용하는 사용자가 한 명이고 톰캣 인스턴스가 3 명 있다고 가정합니다. 이 사용자는 앱에 여러 요청을 보낸 다음로드 밸런서는 첫 번째 사용자 요청을 3 개의 tomcat 인스턴스 중 하나로 보내고 세션 중에이 사용자가 보낸 다른 모든 요청은 동일한 tomcat 인스턴스로 보내집니다. 이러한 요청 중에이 Tomcat 인스턴스 (사용 된 Tomcat 인스턴스)를 종료하거나 다시 시작하면로드 밸런서는 세션 복제를 사용할 때 나머지 요청을 여전히 실행중인 다른 Tomcat 인스턴스로 보냅니다. 나머지 요청을 수신하는 인스턴스 Tomcat은 사용자 세션의 사본은 사용자가 세션을 유지합니다. 사용자는 연결을 끊지 않고 웹 앱을 계속 탐색하며 Tomcat 인스턴스의 종료는 사용자 탐색에 영향을 미치지 않습니다.

8
흠 .. 나는 이것을 읽는다 : 네 번째 옵션 인 Non-Sticky WITH Session replication? 또는 다르게 말하면, 세션을 다른 인스턴스에 복제하는 경우 고정 세션을 사용하면 어떤 이점이 있습니까? 인스턴스 전체에서 세션을 복제하는 경우 요청을 서버로 전달할 수도 있습니다. 내가 무엇을 놓치고 있습니까?
dingalapadum

@dingalapadum 당신이 맞습니다. 이론적으로는 고정 세션없이 세션 복제를 할 수 있습니다. 그러나 큰 클러스터의 경우 네트워크 성능이 나쁩니다. 그런 다음 tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) 과 같은 고정 세션으로 세션 복제를 사용하는 몇 가지 전략이 있습니다. 모든 노드 세션 복제를 유지하는 백업 관리자라고 함).
Nico

그런 다음 고정 세션을 사용하면 하나의 세션 복제본 만 가질 수 있으며 이는 대규모 클러스터에서 가장 좋습니다.
Nico

2
Ah I see-올바르게 이해하면 전체 클러스터에서 모든 세션을 복제하면 클러스터가 내부적으로 넘치게됩니다. 문제가 있습니다. 오, 그리고 지금 당신의 대답을 자세히 살펴보면, 나는 이것이 실제로 당신이 묘사 한 첫 번째 사건이라는 것을 알았습니다 ... 'duh me'..
dingalapadum

@dingalapadum 귀하의 질문은 답변을 개선 할 수 있습니다.
Nico
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.