로컬 로그인을 구현하지 않고, Oauth2.0을 통해 간편한 로그인만 구현하고 싶다는 생각이 들었다. 인터넷에는 Oauth2.0이 훨씬 쉽고, 보안 측면에서도 좋다고 한다. 막상 하다 보면 어렵다. 이 글은 지난 1달 동안 Oauth2.0에 관련하여 삽질한 것에 대한 이야기를 담은 것이며, 제 경험을 공유하여 Oauth2.0 입문자들이 조금 더 쉽게 이해하길 원하며 적고 있다. 물론 누군가에게 검증받은 글이 아님으로 모든 것이 맞다고는 볼 수 없다. 먼저 JWT가 무엇인지 알아보고, JWT를 이용하여 지칭한 AccessToken과 refreshToken을 알아본다. 그 후 직접적으로 사용하는 JWT 이용을 알아본다. 그 후 우리가 진정으로 하고 싶은 SNS에서 제공해주는 Oauth2.0에 대해 알아본다...
재귀 함수를 이용한다는 것은 맹목적 믿음이 필요하다. 이전 글에서 재귀 함수를 완전히 이해했나 싶었지만, 하노이의 탑을 만나고 다시 좌절했다. 재귀함수는 큰 문제를 작은 문제로 나누어서 작은 문제에만 신경을 쓰면 되기 때문에 재귀는 가독성도 좋고, 코드도 짧아지고, 각 단계의 변수 상태 또한 스택 프레임에 저장되기 때문에 너무나 좋다. 어렵게 느껴지는 하노이의 탑을 현 문장의 장점에 맞춰 생각해보려고 한다. 1. 큰 문제를 작은 문제로 나누기 먼저 우리가 해결해야하는 첫번째 목적(문제)는 제일 하단에 있는 것을 목적지로 옮기는 것이다. 그리고 두번째 목적은 최하단 위로 있는 모든 원반(n-1)개를 목적지가 아닌 다른 곳에 두어야한다. 이렇게 부분 문제가 있다. 2. 원반이 2개있는 경우 여기서 파란색과 ..
가상 메모리 관리자의 입장에서 비어 있는 메모리가 많을 수록 일은 쉬워진다. 페이지 폴트가 발생하면 빈 페이지 리스트에서 비어 있는 페이지를 찾아서 폴트를 일으킨 페이지에게 할당하면 된다. 만약 빈 메모리 공간이 없다면? 그런 경우 OS는 memory pressure을 해소하기 위해 다른 페이지들을 강제적으로 paging out하여 활발히 사용 중인 페이지들을 위한 공간을 확보한다. evict(내보낼) page 선택은 os의 replacement policy안에 집약되어 있다. replacement policy가 중요하다. 그렇다면 ↓ Q. How to decide which page to evict? 1. Cache Management policy에 대해서 말하기 전에 문제에 대해 좀 더 상세하게 알아..
지금까지 가상 주소 공간이 비현실적으로 작아서 모두 물리 메모리에 탑재가 가능한 것으로 가정하였다. 사실 실행 중인 프로세스의 전체 주소 공간이 메모리에 탑재된 것으로 가정하고 있었다. 이제 !! 가정을 없어지는 순간!!! 우리는 이를 위해서 메모리 계층에 레이어의 추가가 필요하다. 지금까지는 모든 페이지들이 물리 메모리에 존재하는 것을 가정하였다. 하지만 큰 주소 공간을 지원하기 위해서 운영체제는 주소 공간 중에 현재는 크게 필요하지 않는 메모리 일부를 보관해둘 공간이 필요하다. 보통 HDD, SDD가 이용된다. 한 가지 짚고 넘어가야하는 것, 왜 프로세스에게 굳이 큰 주소 공간을 제공해하는가? → 편리함과 사용 용이성, 주소 공간이 충분히 크면, 프로그램의 자료구조들을 위한 충분한 메모리 공간이 있는..
세그멘테이션을 사용하지 않고 페이지 테이블을 줄이는 방법을 생각해보자. 멀티 레벨 페이지 테이블은 선형 페이지 테이블을 트리 구조로 표현한다. → 매우 효율적이기 때문에 현대 시스템에서 사용되고 있다. 멀티 레벨 페이지의 기본 개념: 페이지 테이블을 페이지 크기의 단위로 나눈다. 페이지 테이블의 페이지가 유효하지 않는 항목만 있으면, 해당 페이지를 할당하지 않는다.(할당하지 않는다 → PTE를 만들지 않는다) 3.Page directory란 자료구조를 사용하여 페이지 테이블 각 페이지의 할당 여부와 위치를 파악한다. 페이지 디렉터리는 페이지 테이블을 구성하는 각 페이지의 존재 여부와 위치 정보를 가지고 있다. 좌측 그림은 전형적인 선형 페이지 테이블이다. 페이지 테이블의 중앙부에 해당하는 주소공간을 사용..
Bigger Pages 페이지 테이블의 크기를 간단하게 줄일 수 있는 방법이 한 가지 있다. 페이지 크기를 키우면 된다. 32비트 주소 공간에서, 이번에는 16KB 페이지를 가정해보자. 이 때 Offset은162^10 = 2^42^10 =2^14 즉, offset은 14bit가 필요하다. 자연스럽게 나머지 32-14= 18비트가 VPN을 표현하는데 사용한다. 이렇게 18비트의 VPN과 14비트의 offset을 갖게 된다. Page Table은 VPN수에 의해 정해진다. 각 PTE가 4byte이면 42^18 = 2^20byte = 1MB 즉, Page Table은 1MB가 된다. 기존 테이블 대비 크기가 1/4로 감소된다.( 테이블의 크기가 1/4로 감소한 것은 페이지 크기가 4배 증가했기 때문이다.) !..
Faster Translations(TLBs) Paging은 상당한 성능 저하를 가져올 수 있다. ↑은 프로세스 주소 공간을 작은 고정된 크기, page로 나누고 각 page의 실제 위치(mapping information)을 메모리에 저장한다. 그리고 mapping information을 저장하는 자료구조를 page table이라 한다. mapping intormaion을 저장을 위해 큰 memroy space를 요구된다. Address-translation cashe(Translation-lookaside buffer) TLB는 Memory-management unit, MMU의 일부이다. 자주 참조되는 가상 주소-실주소 변환정보를 저장하는 하드웨어 캐시이다. address-translation ch..
BNF를 확장시킨 것이 EBNF이다. Extended BNF 그래서 EBNF다. 일반적으로 3가지 확장 사항이 포함된다. 1. 선택: '[', ']'로 표현한다. 예시: ::= if( ) [ else ] 위 예제를 보고 else 부분이 선택되지 않는 경우 if( ) 란 것을 우린 알 수 있다. 2. 반복: '{', '}'으로 표시하고, 무한정 반복되거나 생략될 수 있음을 나타낸다. 선택이란 다른 점이 별로 없어보이지만, 선택은 반복이 아닌란 것을 명심하자. 예시: ::= { , } 위 예시를 지금은 이해가 되지 않을 수 있지만, 조금 있다 볼 예제를 보고 알 수 있다. 3. 다중 선택: '(', ')'로 표시하고 OR란 것을 알 수 있다. 소괄호로 표현하기 때문에 어휘항목인 터미널이랑 혼동될 수 있으니 ..