[읽은 것들] 20.12.21 ~ 20.12.27

해당 컨텐츠는 주간동안 읽은 아티클 중 일부를 정리한 내용입니다.

목차

• [독서] DevOps와 SE를 위한 리눅스 커널 이야기 chapter 1 ~ 10
• performance effect of joining tables from different databases
• 소켓 프로그래밍. (Socket Programming)
• Refresh token은 필요한가?

[독서] DevOps와 SE를 위한 리눅스 커널 이야기 chapter 1 ~ 10

지난 주말부터 읽기 시작한 책이다. 12 챕터중 10챕터까지 읽었는데 내용이 매우 흥미롭다. 프로세스 상태와 Load Average, 커널에서의 메모리 관리방법, TCP 등 학교에서 배운 전공지식들의 실습 또는 확장판이다.

특히 Load Average와 TCP Time wait에 대한 내용 설명이 좋았다. 사내에서 스트레스 테스트를 진행할 때, 프로세스를 늘리면서 성능이 떨어지는 이슈가 있었는데 당시에는 리눅스와 Load Average에 대한 개념이 부족했기에, 단순 CPU 경쟁으로만 생각했는데 해당 책은 이를 구체적으로 검증하는 내용들이 포함되어 있어 인상 깊었다. 관련 내용은 시간이 된다면 포스팅 해볼 생각인다.

또 TCP Keep Alive 챕터에서 로드밸런서 idle time으로 인한 connection time out 케이스 스터디 내용이 있는데 이 부분도 상당히 인상깊었다. 내용을 간단히 요약하면 아래와 같다

• 로드 밸런서를 사용하게 되면 요청은 로드 밸런서를 통해 들어오게 되는데 이 때 어떤 서버에 요청을 할당했는지 테이블에 기록하고 응답은 서버에서 직접 클라이언트로 나가게 된다.

• 자원은 항상 무한하지 않기 때문에 적절한 idle time이 지나도 클라이언트 요청이 없으면 로드밸런서는 클라이언트와 서버를 맵핑한 레코드를 날리게 되는데, 이 때 클라이언트와 서버 입장에서는 본인의 연결이 삭제됬음을 인지할 수 없다.

• 따라서 TCP 컨넥션이 살아있는 상태에서 로드밸런스가 테이블에서 맵핑 내용을 삭제하게 되면, 로드밸런스는 확률에 따라 맵핑된 서버가 아니라 새로운 서버로 요청을 줄 수 있게 되고, 요청을 받은 서버는 본인과 TCP 컨넥션이 맺지 않은 클라이언트 패킷이 날라왔음으로 RST 패킷을 주게 된다. 이 패킷을 받은 클라이언트는 다시 TCP 컨넥션을 맺고자 하는데 이 과정이 어플리케이션에서 설장한 time out보다 클 경우 time out이 발생 할 수 있다.

performance effect of joining tables from different databases

탈퇴회원은 주로 다른 데이터베이스로 구성하는데, 이 때문에 회원의 같은 필드를 가져오는 쿼리가 달라진다. 그래서 서로 다른 데이터베이스에 있는 테이블들을 하나의 쿼리에서 수행하는 것에 대한 성능적 이슈가 어떤지 궁금해 해당 글을 찾아보게 되었다.

해당 글에서는 같은 서버에 있다는 전제하에 성능적인 관점에서는 큰 차이가 없으나, 외부키를 쓰지 못한다는 단점이 있는 반면 권한을 유연하게 가져 갈 수 있는 장점 정도가 있다는 답글을 확인했다.

다른 참고 글 : Cross database queries, joins advantages and disadvantages

소켓 프로그래밍. (Socket Programming)

DevOps와 SE를 위한 리눅스 커널 이야기를 읽던 중, Keep alive 옵션을 줄 경우, 컨넥션이 유지되는데 소켓 하나당 클라이언트 하나라면 서버는 동시에 한 클라이언트의 컨넥션만 유지 할 수 있지 않나라는 의문이 들었다.

TCP Keep alive vs HTTP Keep alive
TCP Keep alive가 60초라면 60초 간격으로 연결이 유지되었는지 패킷을 보내고, 응답을 받으면 연결을 유지하는 반면 HTTP Keep alive가 60초라면 60초 이후 연결을 끊는다.

네트워크 수업에서 TCP 통신은 요청을 듣고 있는 리스닝 소켓이 있고 요청이 accept 되면 소켓을 새로 만들어 클라이언트 요청을 할당함을 배웠는데, 내용이 가물가물해서 해당 포스팅을 통해 리마인드했다.

TCP 컨넥션은 리스닝 소켓이 아니라 accept 되어 새로 만들어진 소켓과 클라이언트와 연결된다. 때문에 하나의 서버는 여러 클라이언트와 컨넥션을 유지 할 수 있다.

리스닝 소켓은 들어온 요청이 저장되어 있는 큐에서 요청을 꺼내 해당 요청을 수신하는 역할뿐이며 accept가 되어 새로운 소켓이 생성되어야 establish state가 된다.

Refresh token은 필요한가?

Refresh token이 정말로 필요한가에 대한 흥미로운 글이다. 해당 글쓴이와 의견이 다른점을 조금 정리해보고자 한다.

access 토큰이 노출되는 만큼, refresh 토큰도 노출되어 있으며, 한 단계를 더 거치긴 하지만 공격자 입장에서는 refresh 토큰으로 access 토큰을 얻을 수 있다. 토큰의 유효기간이 1회성 사용 이라면 모를까, 공격자도 사용자 만큼이나 똑같은 조건으로 토큰을 사용할 수 있다.

글쓴이 의견처럼 완벽히 막는 것은 불가능하나 Refresh Token은 토큰 갱신에만 사용함으로 네트워크 탈취 가능성을 낮추는데 의미가 있다 생각한다. 공격자는 Refresh Token 탈취를 위해 계속해서 네트워크를 스누핑해야하며, 유저가 토큰을 갱신하지 않고 끝나는 경우도 꽤 흔하다.

유저의 로그인(세션)을 막는 방법은 토큰으로만 가능한게 아니다. 아이디나 이메일로 막을 수도 있다.(그렇게 구현 하기만 하면 된다). 어차피 토큰으로 유저를 블럭 시키거나, 특정인이 발행한 토큰을 무효화 시키려고 할 때, 블랙리스트를 만들거나, 혹은 다른 방식으로 구현해야만한다. 토큰을 사용하면 로직을 구현하는데 특별히 더 쉬운것도 아니다.

이건 상황이나 요구사항에 따라 다를 수 있을 거 같다. 그러나 Refresh Token을 사용한다면, 이미 발급된 토큰들은 유효한 상태에서 더 이상 갱신되지 않게 막는 옵션 정도는 추가로 가져 갈 수 있을 거 같다.