네트워크_COOKIE/SESSION

Cookie & Session

• 사용하는 이유 : HTTP 프로토콜의 특징이자 약점을 보완하기 위해
• Connctionless 프로토콜(비연결지향)-> 클라이언트가 서버에 요청(request)을 했을 때, 요청에 맞는 응답을 보낸 후 연결을 끊어 버리는 처리방식
• Stateless 프로토콜 (상태정보 유지 안함) -> 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식, 클라이언트와 첫번째 통신에서 데이터를 주고 받았다 해도, 두번째 통신에서 이전 데이터를 유지하지 않는다.
  하지만 매번 페이지를 이동할 때마다 로그인을 유지하는 등 실제 데이터 유지를 필요한 경우가 많아 쿠키와 세션을 사용
  

Cookie

• HTTP 일종으로 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일
• 동작방법 : 클라이언트에서 페이지 요청 - > 웹 서버는 쿠키 생성 - > 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 쿠키 정보도 같이 클라이언트에게 돌려줌 - > 넘겨받은 쿠키를 클라이언트가 가지고 있다가 다시 서버에서 요청할 때 쿠키를 전송

Session

• 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술
• 동작방법 : 클라이언트에서 페이지 요청 -> 서버는 접근한 클라이언트의 Request-header 필드인 Cookie를 확인하여,클라이언트가 해당 session-id를 보냈는지 확인한다. ->session-id가 존재 하지 않는다면,서버는 session-id 생성해 클라이언트에게 돌려준다. -> 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다. -> 클라이언트 재접속시 이 쿠키를 이용해 session-id 값을 서버에 전달(화면이 이동해도 로그인이 풀리지 않음)
• 세션을 사용하면 되는데 굳이 쿠키를 사용하는 이유: 세션이 보안이 쿠키보다 좋으나 세션은 서버에 저장되고,서버 자원을 사용하기 때문에 사용자가 많을 경우 소모되는 자원이 상당하여 쿠키와 세션을 적절한 요소에 병행 사용한다.

세션 사용시 단점

• 세션 저장소의 문제가 발생하면 인증 체계가 무너져 이전에 다른 인증된 유저 또한 인증이 불가능 해진다.
• Stateful 하기 때문에 http 장점을 발휘하지 못하고 scale out에 걸림돌이 생긴다.
• 세션 저장소가 필수적으로 존재하기에 이를 사용하기 위한 비용이 듦
• 세션 ID가 탈취되었을 경우 대처는 가능하지만 클라이언트 인척 위장하는 보안의 약점이 있을 수 있다.
• 사용자가 많아질수록 메모리를 많이 차지하게 된다.
• 매번 요청 시 세션 저장소를 조회해야하는 단점이 있다.

JWT

• 세션 사용시 요청을 진행할 때 마다 세션 저장소에서 세션 ID를 조회하는 작업을 통해서 DB접근 로직이 한번 더 수행된다는 점에서 등장 (인터넷 표준 인증 방식)
  -> 인증에 필요한 정보들을 토큰에 담아 암호화시켜 사용하는 토큰(인증 진행 구조는 쿠키와 크게 다르지 않음)
• JWT 구성요소 :Header ,Payload ,Signature (.(온점)으로 구분됨)

1. Header : 보통 토큰 타입이나, 서명 생성에 어떤 알고리즘이 사용되었는지 저장
   

2. Payload : 보통 Claim(토큰에서 사용할 정보의 조각)이라는 사용자에 대한 혹은 토큰에 대한 property를 key-value의 형태로 저장
   

3. Signature : 암호화가 되어있으며 서버에 있는 개인키로만 암호화를 풀 수 있으므로 다른 클라이언트는 임의로 Signature를 복호화 할 수 없다.

JWT 장점

• 이미 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 인증 저장소가 “필수적”으로 필요하지 않는다.
• 세션과 다르게 클라이언트의 상태를 서버가 저장해 두지 않아도 된다.
• Signature를 공통키 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보완성이 늘어난다.
• 다른 서비스에서 이용할 수 있는 공통적인 스펙으로써 사용가능하다.

JWT 단점

• 쿠키,세션 때와는 다르게 base64 인코딩을 통한 정보를 전달하므로 전달량이 많아 네트워크 전달 시 많은 데이터양으로 부하가 생길 수 있다.
• Payload에는 암호화가 되어있지 않기 때문에 민감 정보를 저장할 수 없다.
• 토큰이 탈취당하면 만료될 때까지 대처 불가능하다.

※ Load Balancing

• 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량,속도저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스
  
• Client가 한 두명인 경우에는 서버가 여유롭지만 수천만명이라면 과부화가 오게된다.
• 때문에 Scale-up(server가 더 빠르게 동작하기 위한 하드웨어 향상) 혹은 Scale-out(하나의 Sever보다는 여러 대의 Server가 나눠서 일을 하는 방법)으로 해결 가능하며 Scale-out에서 여러 대의 sever에게 균등하게 Traffic을 분산시켜주는 역할을 하는 것이 Load Balancer이다.

로드 밸런싱 알고리즘

• 라운드로빈 방식(Round Robin Method)
  서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식/ 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결이 오래 지속되지 않는 경우에 활용하기 적합
• 가중 라운드로빈 방식(Weighted Round Robin Method)
  각각의 서버마다 가중치를 메기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분합니다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용
• IP 해시 방식(IP Hash Method)
  클라이언트 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식
• 최소 연결 방식(Least Connection Method)
  요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽 배분/자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우 적합한 방식
• 최소 리스폰타임(Least Response Time Method)
  서버의 현재 연결 상태와 응답시간을 모두 고려하여 트래픽을 배분 (가장 적은 연결 상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 로드를 배분하는 방식)