[Codesquad] 네트워크 - 상태&무상태, 쿠키, 세션, 로그인 과정, 스프링으로 로그인 구현, 세션DB, 웹소켓

오늘의 호눅스 수업

상태(stateful)와 무상태(stateless)의 차이?

무상태 : 주문하시겠어요? - 제육덮밥 하나 주세요.

상태 유지 : 주문하시겠어요? - 늘 먹던 걸로 주세요.

쿠키 Cookie

클라이언트가 누구인지 식별하기 위해, 웹 서버가 사용자의 컴퓨터에 설치하는 작은 정보 파일.

''쿠키''는 헨젤과 그레텔에서 유래한 표현이다.

웹 서버는 무상태(stateless)이기 때문에, 현재 접속한 사용자가 이전에 접속한 사용자인지 아닌지 알 수 없다.

• 로그인과 같이, 한 번 로그인한 상태값을 유지할 수 없다.

그래서 서버는..

• 서버 : 클라이언트로부터 요청을 받았을 때, Set - Cookie header값으로 유지하고 싶은 값을 클라이언트에 전송(response)한다.

• 클라이언트 : 이후 발생하는 모든 요청에 서버로부터 받은 Cookie header값을 함께 보낸다.

• 서버 : 클라이언트로부터 받은 요청의 Cookie header값을 보고 이전에 접속한 사용자인지 식별한다.

세션 Session

: 방문자가 웹 서버에 접속해 있는 상태(state)를 하나의 단위로 보고, 그 단위를 세션이라고 한다.

일정 시간 동안 같은 사용자가 보내는 요청을 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.

(일정 시간 : 웹 브라우저를 통해 웹 서버에 접속한 시간부터 - 웹 브라우저를 종료해 연결을 끝내는 시간까지)

세션 = 임시저장소.

로그인한 사용자 1명당 1개씩 생기며, 그 사용자 전용 저장소이다.

• 세션은 Map이라고 볼 수 있다. 키, 값으로 유저를 추가한다.
• 키 = sessionedUser, 값 = User
• 세션에는 사용자 데이터 처리에 필수적인 정보만 담는다. id(필수), name, 등등

※ 세션을 거치면 보통 redirect:/main 처리한다.

• 세션은 서버 중에서도 메모리에 저장된다 (기본적으로). 사용자가 많아지면 세션DB를 만들어 저장한다(Redis).

세션에는 만료시간이 있다.

• 만약 없다면? - 메모리 폭발 및 해킹 가능.

• 세션이 만료되면 로그아웃된다.

• 요즘은 세션 만료시간 대신 refresh토큰, Auth토큰을 만들어 refresh토큰은 길게, Auth토큰은 짧게 만료시간을 정한다.

---

✅ 더 공부하기 : 쿠키와 세션 및 차이점. 여기 엄청나게 정리가 잘 되어 있다! 👍👍

---

스프링으로 로그인 구현하기

UserController

@RestController
@RequestMapping("/login")
public class UserController {

    //세션. <sessionId, userId>
    private Map<String, String> session = new HashMap<>();

    @GetMapping
    public MyResponse welcome() {
        return new MyResponse("ok", "Kite");
    }
    //이 상태에서 앱을 실행 후 `localhost:8080`에 접속하면 `{"status" : "ok", "message" : "Kite"}` 와 같은 JSON형식(정확히는 Jackson)의 데이터가 출력된다.

    @GetMapping("/check")
    public MyResponse check(HttpServletRequest req) {
        // Cookie값은 Http 요청에 들어 있다. 따라서 HttpServletRequest
        String key = "sid";
        String uid = "Null";
        Cookie[] cookies = req.getCookies();
        for(Cookie c : cookies) {
            if (c.getName().equals(key)) {
                uid = session.getOrDefault(c.getValue(), "Null");
                sout("chcek: " + c.getValue() + ": " + uid);
            }
        }
        return new MyResponse("ok", "login id: " + uid);
    }

    @PostMapping
    public MyResponse login(String id, HttpServletResponse response) {
        sout(id);
        Random r = new Random(); 
        String sid = Integer.toString(r.nextInt());// 세션ID : 해쉬값 대신 간단히 랜덤숫자로 넣는다
        session.put(sid, id);
        sout("login: " + sid + ": " + session.get(sid));
        response.addCookie(new Cookie("sid", sid)); // 쿠키를 셋팅한다
        return new MyResponse("ok", "sid : " + sid)
    }
}

MyResponse

public class MyResponse{
    private String status;
    private String message;

    public MyResponse(String status, String message){
        this.status = status;
        this.message = message;
    }
}

로그인 과정 설명

①이 로그인 과정, ②가 로그인 이후 상태이다.

① 로그인

POST / login (DTO로 전달)

Controller : @PostMapping("/login")

• 원래 id, pw는 HTTP Request에 들어있다. 하지만 우리가 직접 제어하지 않고 추상화된 것을 사용한다.

• DB에 있는 해당 유저와 비교한다.

• id, pw 등을 전달할 때 DTO객체에 넣어 전달하는 게 좋다.

세션 아이디 sessionId

• 로그인 과정에서 브라우저와 사용자가 교환하는 것은 'sessionId'뿐이다. (민감정보가 없어 보안에 유리하다)

• 실제 sessionId는 매우 길고 복잡한 값(4byte정도). sessionId를 바꿔서 다른 사용자로 로그인할 가능성은 있지만 그러기가 어렵다(거의 불가능)

② 로그인 이후

로그인된 사용자는 세션 아이디 (sessionId, sid)를 저장해 보내서 구별한다.

브라우저는 세션 정보 전체가 아닌 세션 아이디만 저장한다. (보안, 성능 때문에) - 쿠키에 저장한다!

③ 로그아웃

로그아웃 = 세션 정보 삭제.

로그아웃은 보통 POST /logout로 요청한다. (정답은 없지만 습관적으로)

• 클라이언트 : 쿠키에 세션아이디를 담아 서버로 보낸다.
  • 세션id가 유효(valid)하면 로그아웃이 되고, 유효하지 않으면 HTTP Status Code를 리턴한다. (보통 401 - Unauthorized)

로그아웃과정 :

• 세션 삭제
• 쿠키에 만료시간=현재시간으로 담아서 클라이언트로 보내기
• 클라이언트에서 쿠키가 만료되므로 삭제됨

HTTP session은 자바 서블릿에 속해 있다.

현업에서는 서블릿 대신 Spring Security를 사용한다 - 매우 어려우니 나중에 과정 끝나고 해보기

옛날에는..

• 클라이언트가 쿠키에 id, pw를 담아? 서버에 보낸다.
  • 쿠키는 브라우저에 저장되어 있다
• 쿠키에 담겨진 id, pw를 보고 서버가 DB와 비교해 로그인을 처리했다.
• 중요한 정보는 절대로 클라이언트에 넣으면 안 되는데, id pw를 다 넣어 보냈기 때문에 보안에 매우 취약했다.

세션DB (Session DB, SDB)

세션은 서버 중에서도 메모리에 저장된다 (기본적으로).

하지만 사용자가 많아지면 세션도 많아지므로 메모리가 터질 수 있다.

따라서 사용자가 많아지면 세션DB를 만들어 저장한다(Redis 같은).

세션정보가 서버의 메모리에 저장되면, 서버가 여러대일 경우 다른 서버와 세션 정보를 나누기 힘들 것 같습니다. 이럴 때 세션 디비를 쓰는건가요? -> YES.

• 세션DB가 있으면 그걸 사용하고, (세션DB방식)

• 세션DB가 없으면 별도의 채널channel을 만들어 모든 서버들끼리 세션정보를 공유한다.

Case1. Sticky session

로드밸런서L7 - SessionDB가 필요없다. 개발자가 추가 코드를 작성할 필요가 없다.

각 사용자마다 사용하는 전용 서버?가 있다.

Case2. SDB (세션DB)

로드밸런서L4 - 세션DB

모든 세션정보는 세션DB에서 관리된다.

Redis같은 DB는 LRU (Least Recently Used)라는 만료수명이 있다.

(SDB용량보다 더 많은 사용자가 접속할 경우 가장 옛날에 접속했던 세션을 만료시킨다=로그아웃된다)

로드밸런서는 HTTP헤더를 읽는 능력이 있어야 한다. 그래야 요청을 알아보고 트래픽을 목적지로 분산해 준다 (L7 로드밸런서는 이 능력이 있고, L4는 없다. 그래서 L7이 더 비싸다)

웹소켓 WebSocket

HTTP는 기본적으로 상태를 가질 수 없다 (무상태 프로토콜이다.) (=커넥션이 없다?)

하지만 요즘은 상태를 가지게 하고 싶어서(커넥션을 유지하고 싶어서) 웹소켓WebSocket이라는 것이 나왔다.

웹소켓은 시작은 HTTP로 하지만, TCP/IP위에서 돌아간다. (성능을 위해)

궁금한게 저는 stateless 의 가장 큰 장점이, 한정된 connection pool 로도 굉장히 많은 사용자에게 서비스를 제공할 수 있는 점이라 생각하고 있는데, 다시 웹 소켓으로 커넥션 유지하면 대규모 커넥션을 어떻게 관리하나요?

그래서 요즘은 서버가 굉장히 무거워졌다. 대규모 트래픽은 서비스는 서버가 오천대.

❗ 오늘 내용이 어려웠다면 HTTP, TCP/IP 키워드 중심으로 공부하면 된다. (얇은 책부터 보자)