안녕하세요. 세션에 대해 제가 이해한게 맞는지 궁금해서 질문드립니다.

서버에서 처음 세션을 생성하면 서버가 jsessionid라는 매개변수를 URL에 덧붙여 클라이언트에게 전달하고 클라이언트는 다시 그 jsessionid를 이후 서버에 접속할 일이 있을때 되돌려줍니다. 이런 jsessionid라는 매개변수들을 서버에서 여러개를 관리하는데 이는 여러 세션을 관리한다는 것과 동일한 말입니다. 어떤 클라이언트가 서버에 접속했을때 접속한 URL의 jsessionid를 검사하여 서버에서 관리하는 jsessionid와 일치하는 세션을 찾습니다. 그 아이디에 속한 키-값 쌍의 자료구조가 있겠고 그게 세션 상태입니다.

마지막으로 세션의 상태인 키-값 쌍의 자료구조를 변경하거나 추가하는 작업은 서버단에서만 가능하고 클라이언트 단에서는 불가능합니다.

근데 실제 서비스에서는 로그인 구현시 세션을 사용하지 않는다는데 그럼 어떤 기술을 쓰나요? 감사합니다.

적어주신 내용은 Tomcat같은 자바 계열 웹 컨테이너에 구현한 방법입니다.

HTTP 프로토콜에 상태가 없기 때문에 로그인 한 사용자 처리 등 상태를 가지는 기능에 구현이 어렵습니다.

HTTP 스펙상 cookie는 매 요청마다 전송되기 때문에, 로그인을 하게 되면 서버에서 해당 사용자에 대한 token을 cookie로 내려주고 이때 이 cookie의 키가 jsessionid이며 해당 값이 인증된 사용자 session id입니다.

Tomcat에서는 해당 session id으로 사용자를 알아내게 됩니다.

이 방식의 장점은 웹앱 개발시에 cookie나 로그인 사용자에 대한 토큰/쿠키 관리를 투명하게 해주기 때문에 개발이 쉽다는 장점이 있으나, 웹 서버간에 세션 데이터가 공유되지 않기 때문에 확장에 단점이 있습니다.

(이를 위해서 tomcat등에는 세션 클러스터링을 지원합니다.)

웹서버는 보통 상태가 없기 때문에 프론트에 로드밸런서나 리버스 프록시를 두고 실제 서버 N대를 사용자로 부터 가리게 됩니다. 따라서 사용자가 요청할 때 마다 매번 같은 서버로 요청이 가는 것이 보장되지 않습니다.

이 경우에 A서버에 로그인한 사용자가 페이지를 새로 고침 했을 경우 B서버에서는 로그인이 풀려 있는 경우가 생깁니다.

또한 인증 처리가 Tomcat등 컨테이너에 종속되기 때문에 API를 서로 다른 컨테이너 개발하는게 어려워 집니다.

이런 이유로 요즘은 session id를 내리지 않고 인증 token을 클라이언트가 가지고 있고 매 요청시마다 token을 같이 전송하며, 이 token의 유효성을 가지고서 사용자를 구분하게 됩니다.

이럴 경우 매 요청마다 사용자를 인증해서 사용자 정보를 DB/Cache등에서 얻어오게 됩니다.

요즘은 JWT 같은걸 많이 사용합니다.