프록시 세션 어피니티: 요청 하나일까, 워크플로 전체일까?

로그인, 리디렉션, 보고서 다운로드는 세 개의 요청입니다. 하지만 사용자에게는 하나의 작업입니다. 요청마다 출구를 돌리면 각 프록시가 동작하더라도 그 작업을 이해하기 어려워질 수 있습니다.

먼저 경로를 소유하는 단위를 정의합니다. 요청 수준 선택은 독립적인 작업에 적합합니다. 그러한 공개 작업에는 무료 프록시 목록이 공개 중개자가 허용될 때 후보를 제공하지만, 고정 세션 계약은 제공하지 않습니다. 워크플로 수준의 선택은 관련 단계를 의도한 경로에 유지하며, 워크플로가 끝나거나 정의된 복구 결정이 이를 대체할 때까지 계속됩니다.

쿠키와 프록시 어피니티는 서로 다른 상태입니다

애플리케이션 쿠키는 웹사이트의 세션 규칙에 속합니다. 공급자의 고정 세션 식별자는 제공될 때 그 프록시 서비스와 문서화된 연결 또는 계정 정책에 속합니다. 둘 다 세션이라는 단어를 쓴다는 이유만으로 하나의 설정이 되지는 않습니다.

일반적인 CONNECT 중개자는 웹사이트의 암호화된 Cookie 헤더를 읽을 수 없습니다그리고 이를 라우팅 키로 쓸 수 없습니다. 서비스가 쿠키 기반 동작을 약속한다면, 어느 가시적 인터페이스가 그 쿠키를 전달하는지, 그리고 TLS가 거기서 종료되는지 확인하세요. 웹사이트의 비공개 쿠키가 터널 게이트웨이에서 자동으로 사용 가능하다고 가정하지 마세요.

작은 워크플로 기록을 남기세요. 선택한 엔드포인트, 사용한 경우 공급자 세션 식별자, 애플리케이션 세션 식별자, 어피니티를 끝내는 조건입니다. 계정 비밀을 일상적인 기록 키에 넣지 마세요.

불편한 경우를 계획하세요

선택한 경로가 중간에 실패하면, 워크플로가 다른 출구에서 안전하게 계속될 수 있는지, 애플리케이션 세션을 다시 세워야 하는지, 아니면 멈춰야 하는지 결정합니다. 실패한 응답이 제출된 작업이 전혀 처리되지 않았다는 뜻은 아닙니다.

영구적인 고정도, 끊임없는 순환도 보편적으로 옳지 않습니다. 범위는 애플리케이션의 일관성 요구에서 선택하고, 그다음 요청 속도와 서비스 한도를 전체 워크플로에 적용합니다. 출구가 많다고 그 요구가 사라지지는 않습니다.