[HTTP Network] Session

🚀 Session 방식

 

session 방식

위 작업은 최초 요청 시 이뤄지게 되는 것이에요. 그 다음 요청 부터는 Session ID를 가지고, 용청을 하고, 응답(반환) 시 동일 값을 전달하여 해당 Session ID가 없으면 처음 방문한 것으로 Web Server는 판단하는 것이에요.

악의적인 이용자가 탈취할 위험을 막기 위해 Session ID와 별개로 목록에 어떤 값을 넣고, 최초 요청시 Header에 Session ID와 목록에 저장한 값을 Client에게 전달 해 주고, Client는 브라우저 내부에 이것들을 저장을 한 뒤 그 다음 요청 시 Session ID와 목록에 저장된 값을 같이 전달하고, Server는 해당 값을 비교하여 동일한 값이 있으면 인증을 허용하고, 없으면 새로운 값을 만들어 그 값을 Server 내부에 저장하고, Client에 전달하는 방식인 것이에요.

 

    🔽  Session ID가 사라지는 경우

1. Server 쪽에서 Session 값을 날려 버리는 경우
2. Client가 브라우저를 종료하는 경우 브라우저 내 저장소가 초기화 되며, Server에서는 보통 30분이 지나면 해당 정보가 사라진다.
3. 특정 시간( 보통 30분 )이 지나면 Server에서 Session Value가 사라진다.

 

 

    🔽  Session 사용 예시

세션은 인증을 위해 많이 사용되는 것이에요.

Session 구동 방식

Session을 이용하여 인증 처리하고, Client가 다음 요청 시에 민감 정보를 요청하면 Session ID를 확인하는 작업을 통해 Server는 응답 작업을 하는 것이에요.

 

    🔽  Session 단점

각각 다른 이용자 즉, 동시 접속자 수가 어마무시하게 많을 때, Session 방식은 처리 속도가 느린 것이 단점인 것이에요.
이를 해결하기 위해 Web Server를 여러 대 추가를 하고, Load Balancing을 통해 부하를 분산하여 Web Server에 과부하를 막는 작업을 하게 되는데, 여러 대의 Web Server 중 Client가 'A' Server에 Login을 한 뒤 두번째 요청 시에 'B' Server에 요청을 하게 되면 'B' Server 입장에서는 당연히 "처음 뵙겠습니다! 고객님!"을 할 수 밖에 없는 것이에요.

이런 상황을 막기 위해 추가 작업을 해주어야 하는데, 각 Web Server가 이용자 정보가 담긴 DB Server 한 개를 동시에 바라보고 있다면 그리고, 그 곳에 Session ID와 같은 값을 저장한다면 "처음 뵙겠습니다! 고객님"은 하지 않을 것이에요. 하지만 문제는 DB는 HDD를 사용하여 Data를 저장하고 있고, Web Server가 요청을 하게 되면 I/O (Input / Output)이 발생하게 되는데, 이는 엄청난 속도 저하를 초래하게 되는 것이에요.

이러한 상황을 막기 위해 요즘 Back End 쪽에서 유명한 Redis와 같은 Memory DB를 사용하여 속도가 떨어지지 않게 구축을 하는데, 이 모든 것은 비용이 발생한다! 라는 단점이 있는 것이에요.

반응형

 

 

그래서 이러한 단점을 가진 Session을 보완하기 위해 우리는 JWT라는 것을 사용하게 되는데, 이것에 대해서도 공부를 하여 작성해 보도록 할 것이에요!