├── .idea ├── .gitignore ├── Tech-Interview-Question.iml ├── misc.xml ├── modules.xml └── vcs.xml ├── Database ├── DB LOCK.md ├── DB클러스터링 │ ├── active-active.png │ ├── active-standby.png │ ├── common.png │ ├── dynamic-sharding.png │ ├── entity-group.png │ ├── hash-sharding.png │ ├── replication.png │ └── sharding-partitioning.png ├── DB클러스터링_리플리케이션.md ├── ElasticSearch.md ├── Index.md ├── RDB vs NoSQL.md ├── README.md ├── Redis.md ├── Transaction.md ├── 동시성 제어.md ├── 스키마 c60952486d774377974451a653b686ef.md ├── 스키마 │ ├── 스키마 c60952486d774377974451a653b686ef │ │ ├── Untitled 1.png │ │ ├── Untitled 2.png │ │ ├── Untitled 3.png │ │ └── Untitled.png │ └── 스키마.md ├── 역정규화 │ ├── 역정규화 af409 │ │ ├── Untitled 1.png │ │ ├── Untitled 2.png │ │ ├── Untitled 3.png │ │ ├── Untitled 4.png │ │ ├── Untitled 5.png │ │ └── Untitled.png │ └── 역정규화.md ├── 정규화 │ ├── 정규화 83264 │ │ ├── Untitled 1.png │ │ ├── Untitled 2.png │ │ ├── Untitled 3.png │ │ ├── Untitled 4.png │ │ ├── Untitled 5.png │ │ ├── Untitled 6.png │ │ ├── Untitled 7.png │ │ ├── Untitled 8.png │ │ └── Untitled.png │ └── 정규화.md └── 질문정리.md ├── Network ├── CORS.md ├── HTTP와 HTTPS.md ├── LayeredArchitecture │ └── img_webbasic_10.png ├── Load Balancer.md ├── OAuth(Open Authorization).md ├── OAuth │ └── login-screen.png ├── REST and RESTFUL.md ├── cookie,session,jwt.md ├── proxy.md ├── websocket.md ├── 네트워크 보안(Network Security).md ├── 네트워크 시스템의 Layered Architecture.md ├── 네트워크보안 │ ├── Command-Injection.png │ ├── ipsec-ah.png │ ├── ipsec-esp.png │ ├── ipsec-vpn.png │ ├── xss-reflected.png │ └── xss-stored.png └── 질문정리.md ├── OperatingSystem ├── CPU 스케줄링 기법 │ └── CPU 스케줄링 기법 .md ├── RAID │ ├── RAID be8c1 │ │ ├── Untitled 1.png │ │ ├── Untitled 2.png │ │ ├── Untitled 3.png │ │ ├── Untitled 4.png │ │ ├── Untitled 5.png │ │ └── Untitled.png │ └── RAID.md ├── 가상머신.md ├── 가상머신 │ ├── cpu-vt.png │ ├── hypervisor-type.png │ ├── vm-container.png │ ├── vm-xen.png │ ├── x86-ring.png │ ├── 반가상화.png │ └── 전가상화.png ├── 교착 상태와 기아 상태.md ├── 메모리 할당과 단편화.md ├── 메모리 할당과 단편화 │ ├── 가변분할.png │ └── 고정분할.png ├── 블록_논블록_동기_비동기.md ├── 시스템콜.md ├── 운영체제 파일시스템과 RDBMS.md ├── 운영체제_메모리_구조.md ├── 운영체제와 컴퓨터 시스템 구조 │ ├── images │ │ ├── img.png │ │ └── img_1.png │ └── 운영체제와 컴퓨터 시스템 구조.md ├── 주소 바인딩과 스와핑 │ ├── 주소 바인 6e0c3 │ │ ├── Untitled 1.png │ │ ├── Untitled 2.png │ │ ├── Untitled 3.png │ │ ├── Untitled 4.png │ │ ├── Untitled 5.png │ │ └── Untitled.png │ └── 주소 바인딩과 스와핑.md ├── 질문정리.md ├── 캐시의 지역성.md ├── 캐시의 지역성 │ ├── address.png │ ├── hierarchy.png │ ├── l3-cache.png │ ├── mmu.jpg │ ├── pagetable.png │ └── speed-tier.png ├── 페이징과 세그멘테이션.md ├── 프로세스동기화.md ├── 프로세스와 스레드.md └── 프로세스와스레드 │ ├── threadpool.png │ ├── was.png │ └── 프로세스상태전이.png ├── Question ├── 네트워크_질문정리.md ├── 데이터베이스_질문정리.md └── 운영체제_질문정리.md └── README.md /.idea/.gitignore: -------------------------------------------------------------------------------- 1 | # Default ignored files 2 | /shelf/ 3 | /workspace.xml 4 | # Editor-based HTTP Client requests 5 | /httpRequests/ 6 | # Datasource local storage ignored files 7 | /dataSources/ 8 | /dataSources.local.xml 9 | -------------------------------------------------------------------------------- /.idea/Tech-Interview-Question.iml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /.idea/misc.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 9 | -------------------------------------------------------------------------------- /.idea/modules.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /.idea/vcs.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /Database/DB LOCK.md: -------------------------------------------------------------------------------- 1 | # LOCK 2 | 3 | - 데이터의 무결성을 보장하기 위한 방법 4 | - `무결성` - 데이터가 정확하고 일관된 상태를 유지하도록 하는 것 5 | - 둘 이상의 사용자가 같은 시간에 같은 데이터를 업데이트 하는 것을 방지하기 위해 존재 6 | - 락이 걸린 데이터는 락이 풀릴 때까지 다른 사용자가 조작할 수 없다 7 | - 오라클과 같이 고가의 DBMS를 사용하는 이유는 데이터의 일관성과 무결성을 유지하기 위함이다 8 | 9 | ## lock의 종류 10 | 11 | ### shared lock 12 | 13 | - 데이터를 읽을 때 사용한다 14 | - 내가 보고 있는 데이터는 다른 사용자가 볼수 있지만 변경은 할 수 없다 15 | - 다른세션에서 데이터를 읽는 것은 가능하다 16 | 17 | ### exclusive lock 18 | 19 | - 데이터를 변경할 때 사용한다 20 | - 락이 해제되기 전까지는 읽기와 쓰기가 불가하다 21 | - 하나의 트랜잭션이 끝날때 까지 유지되고 exclusive lock 이 끝날때까지 어떠한 접근도 허용되지 않는다 22 | 23 | ## lock 레벨 24 | 25 | ### ROW LEVEL 26 | 27 | - 락의 설정 대상이 ROW인 곳에만 락을 설정 28 | 29 | ### PAGE LEVEL 30 | 31 | - ROW가 있는 page에만 락을 설정 32 | - 같은 페이지에 존재하는 모든 row는 모두 잠긴다 33 | 34 | ### TABLE LEVEL 35 | 36 | - TABLE과 INDEX 모두 락을 설정 37 | 38 | ### DATABLASE LEVEL 39 | 40 | - 데이터베이스의 복구나 스키마 변경시 락을 설정 41 | 42 | ### Column Level 43 | 44 | - 컬럼 기준으로 Lock이 걸린다. 45 | - Lock 설정 및 해제에 리소스가 많이들어 잘 사용하지 않는다. 46 | 47 | ## blocking 48 | 49 | - 락의 경합으로 인한 상태 50 | - 락들이 경합이 발생하여 특정 세션이 작업을 진행하지 못하고 머춰 선 상태 51 | - 공유락과 exclusive 락 또는 익스클루시브 락과 익스클루시브 락이 경합이 발생할 수 있다 52 | ![blocking](https://user-images.githubusercontent.com/42866800/162599886-6f68922e-6a9f-4d29-bbed-a8a6ef2287bd.png) 53 | 54 | ### 블로킹 발생시 해결방안 55 | 56 | - SQL 문 리펙토링 하여 빠르게 실행되도록 한다 (속도 개선) 57 | - 트랜잭션을 짧게 정의한다 58 | - 동일한 데이터를 동시에 변경하는 작업을 진행하지 않는다 59 | - 대용략 작업이 불가피할 경우 작업단위를 쪼갠다 60 | - 락 타임아웃을 설정하여 락의 최대시간을 설정한다 61 | 62 | ## 데드락 63 | 64 | - 트랜잭션간 교착상태를 의미한다 65 | 66 | ![deadlock1](https://user-images.githubusercontent.com/42866800/162599889-5b1a0cff-7702-4ba7-87e1-cb7d9ee7db43.png) 67 | - 두개의 트랜잭션이 각각의 트랜잭션이 갖고 있는 리소스의 락을 획득하려고 할때 발생한다 68 | - 상대방 Lock이 끝나야 원하는 데이터를 가져오는데 바라보고 있는 서로의 Lock이 같은 상태가 되다보니 영원히 끝나지 않은 상황이 발생하게된다. 69 | 70 | ![deadlock2](https://user-images.githubusercontent.com/42866800/162599892-3518125e-be54-438e-af7f-474df87d73f3.png) 71 | - 두번째 예는, 1번 트랜젝션이 공유Lock을 설정하고 Sleep에 빠졌습니다. 72 | - 이때 2번 트랜젝션은 배타적Lock을 설정하려고 할때, 무기한 기다리게되는 교착상태에 빠지게 됩니다. 73 | 74 | ### 데드락 발생시 해결방안 75 | 76 | - 둘중 하나의 트랜잭션을 강제 종료한다 77 | - SET LOCK TIMEOUT 명령어를 사용하여 잠금해제 시간 설정 78 | - 락이 걸리는 최대시간을 설정 79 | 80 | ## 블로킹 vs 데드락 81 | 82 | - 블로킹은 트랜잭션이 끝나면 사라진다 83 | - 데드락은 상대의 트랜잭션이 끝나기만을 기다리기 때문에 계속 끝나지 않는다 84 | 85 | 참고 - 86 | 87 | [https://akasai.space/db/about_lock/](https://akasai.space/db/about_lock/) 88 | 89 | [Database Lock 종류 및 기능 (tistory.com)](https://centbin-dev.tistory.com/40) 90 | 91 | [[데이터베이스] 트랜잭션과 격리성 (tistory.com)](https://sabarada.tistory.com/117) 92 | 93 | [DB의 Lock/DeadLock | devlog.akasai](https://akasai.space/db/about_lock/) 94 | 95 | [블로킹(Blocking)과 데드락(Deadlock) 차이 (tistory.com)](https://datacodingschool.tistory.com/100) 96 | 97 | [https://cocoon1787.tistory.com/778](https://cocoon1787.tistory.com/778) 98 | 99 | [https://chrisjune-13837.medium.com/db-lock-락이란-무엇인가-d908296d0279](https://chrisjune-13837.medium.com/db-lock-%EB%9D%BD%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-d908296d0279) 100 | -------------------------------------------------------------------------------- /Database/DB클러스터링/active-active.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/active-active.png -------------------------------------------------------------------------------- /Database/DB클러스터링/active-standby.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/active-standby.png -------------------------------------------------------------------------------- /Database/DB클러스터링/common.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/common.png -------------------------------------------------------------------------------- /Database/DB클러스터링/dynamic-sharding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/dynamic-sharding.png -------------------------------------------------------------------------------- /Database/DB클러스터링/entity-group.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/entity-group.png -------------------------------------------------------------------------------- /Database/DB클러스터링/hash-sharding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/hash-sharding.png -------------------------------------------------------------------------------- /Database/DB클러스터링/replication.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/replication.png -------------------------------------------------------------------------------- /Database/DB클러스터링/sharding-partitioning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/DB클러스터링/sharding-partitioning.png -------------------------------------------------------------------------------- /Database/DB클러스터링_리플리케이션.md: -------------------------------------------------------------------------------- 1 | # DB클러스터링 2 | 3 | 데이터베이스 서버를 여러 개 두는 것 4 | 5 | 6 | 7 | - 한개의 DB 서버로 서버 장애시 서비스 전체 중단됨 8 | 9 | ## Active & Active Clustering 10 | 11 | 여러개의 DB 서버 전체를 active상태로 두는것 12 | 13 | 14 | 15 | - 서버 한 대가 죽어도 다른 서버가 동작하고 있어서 서비스에 문제가 발생하지 않음 16 | - 서버 스케일 아웃이 가능함 -> CPU와 메모리 이용률을 올릴 수 있음 17 | - 서버를 여러대 한꺼번에 운영하므로 비용이 더 발생 18 | 19 | ### storage 동기화 방법 20 | 21 | 클러스터링은 동기 방식으로 노드들 간의 데이터를 동기화가 필수 22 | 23 | 1. 무공유(Shared Nothing) 클러스터 24 | 25 | - 각 노드는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 노드 간에 공유하지 않음 26 | - 각 노드는 완전히 분리된 데이터의 소유권을 가지고 있으며, 데이터의 소유권을 자기는 서버가 처리함. 27 | - 요청을 받으면 처리할 데이터를 갖고 있는 노드에게 신호를 보내 데이터 처리를 요청함 28 | - 동기화 시간으로 인하여 쓰기성능 저하 29 | 30 | 2. 공유 디스크(Shared Disk) 클러스터 31 | 32 | - 데이터 파일은 논리적으로 모든 데이터베이스이 공유하여 모든 데이터에 접근할 가능함. 33 | - 데이터를 공유하려면 SAN(Storage Area Network)과 같은 공유 디스크가 필수. 34 | - 여러 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널이 필요. 35 | - 클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스가 가능 36 | - 클러스터가 커지면 디스크 영역에서 병목현상 발생 37 | 38 | ## Active & Standby Clustering 39 | 40 | 여러개의 DB 서버중 일부를 active상태로 두는것 41 | 42 | 43 | 44 | - Active 서버 하나만 운영하고 나머지 서버는 Standby 상태로 두었다가, Active 서버가 장애시에 Standby 서버를 Active로 전환 45 | - Stanby 서버를 Active 서버로 전환하는(Fail over) 시간 동안 서비스가 중단됨. 46 | - 한대만 운영하기 때문에 효율은 Active & Active의 1/2 정도. 47 | - 공유 디스크 사용시 한 대로 서버만 디스크에 접근하여 병목현상이 없음 48 | 49 | # 리플리케이션 50 | 51 | 데이터베이스 서버와 스토리지 전체를 여러 개 두는 것 52 | 53 | 54 | 55 | - 여거래의 서버를 Master와 Slave로 구분하여 구성. 56 | - DB 요청의 60~80% 정도가 읽기 작업인 것을 이용하여 읽기 작업을 Slave 서버로 분산처리하여 성능 향상. 57 | - 비동기 방식으로 운영되어 지연 시간이 거의 없다. 58 | - Master에서 Slave로 비동기 방식으로 데이터를 동기화 하기 때문에 일관성있는 데이터를 얻지 못할 수 있음. 59 | - 동기방식으로 Replication을 할 수 있지만 이럴 경우 속도가 느려짐 60 | 61 | ### 비동기 방식 처리 순서 62 | 63 | 1. Master 노드에 쓰기 트랜잭션이 수행된다. 64 | 2. Master 노드는 데이터를 저장하고 트랜잭션에 대한 로그를 파일에 기록한다.(BIN LOG) 65 | 3. Slave 노드의 IO Thread는 Master 노드의 로그 파일(BIN LOG)를 파일(Replay Log)에 복사한다. 66 | 4. Slave 노드의 SQL Thread는 파일(Replay Log)를 한 줄씩 읽으며 데이터를 저장한다. 67 | 68 | # 파티셔닝과 샤딩 69 | 70 | - 테이블에 데이터가 많은 경우 Slave DB서버를 늘리더라도 데이터를 찾는데 많은 시간이 소요됨. 71 | - 테이블을 특정 기준으로 나눠서 저장 및 검색. 72 | 73 | 74 | - 샤딩(Horizontal partitioning): 하나의 테이블의 각 행을 다른 테이블에 분할. 75 | - 파티셔닝(Vertical partitioning): 테이블의 일부 열을 빼내는 형태로 분할. 76 | 77 | ## 샤딩 78 | 79 | - 샤딩의 핵심은 Data를 어떻게 잘 분산 시켜 저장할 것인지, 그리고 어떻게 잘 읽을 것인지에 대한 결정 입니다 80 | - 어떻게 잘 분산 시켜 저장할지에 기준이 되는 것이 Shard Key 81 | 82 | ### 샤딩 분할 방법 83 | 84 | #### Hash Sharding 85 | 86 | - 샤드의 수 만큼 Hash 함수를 사용 해서 나온 결과에 따라 DB 서버에 저장하는 방식 87 | - 구현이 간단하지만 확장성이 낮음, DB 서버가 추가 될 경우 해쉬 함수가 변경되어야 하므로 기존에 저장되던 데이터의 정합성이 깨짐. 88 | 89 | 90 | 91 | #### Dynamic Sharding 92 | 93 | - 테이블 형식의 데이터를 바탕으로 샤드를 결정해서 적절히 저장 하는 방식. 94 | - 해쉬 샤딩과 달리 단순히 키만 추가해주면 되므로 확장이 쉬움. 95 | - 서비스가 단일 장애점이 됨, 서비스에 장애가 발생하면 나머지 샤드 또한 문제가 발생. 96 | 97 | 98 | 99 | #### Entity Group 100 | 101 | - 연관성이 있는 엔티티를 한 샤드에 두는 방식 NoSQL보다 RDB와 잘 어울리는 방식. 102 | - 같은 샤드에 있는 데이터를 조회할 때는 효과적이지만, 다른 샤드에 있는 데이터를 함께 조회할 때는 오히려 성능이 떨어짐. 103 | 104 | 105 | 106 | ### 그외 107 | 108 | - moduler sharding: PK를 모듈러 연산한 결과로 DB를 특정하는 방식 109 | - 데이터량이 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적용할 때 좋음. 110 | - DB를 추가 증설해야하는 상황에서 이미 적재된 데이터의 재정렬이 필요. 111 | - range sharding: PK의 범위를 기준으로 DB를 특정하는 방식. 112 | - 활성유저가 몰린 DB로 트래픽이나 데이터량이 몰릴 수 있음. 113 | 114 | ### 샤딩의 한계 115 | 116 | - 두 개 이상의 샤드에 대한 JOIN 연산불가. 117 | - auto increment 등은 샤드 별로 달라질 수 있음. 118 | - last_insert_id() 값은 유효하지 않음. 119 | - 하나의 트랜잭션에서 두 개 이상의 샤드에 접근할 불가. 120 | 121 | ## 파티셔닝 122 | 123 | - 사용이 적은 열이나 자릿수가 많은 열을 분할하여 성능을 향상. 124 | - 관계형 DB에서 3정규화된 데이터를 분리하는 과정 125 | - 하나의 테이블(엔티티)의 컬럼을 기준으로 분리하는 작업. 126 | - 큰 테이블을 제거하여 관리에 용이함 127 | - 대용량 Data Write환경에서 효율적 128 | - 테이블 간 JOIN비용 추가됨 129 | - 테이블과 인덱스를 별도로 파티셔닝 할 수 없고 함께 파티셔닝 해야함. 130 | 131 | ## QnA 132 | 133 | ## References 134 | 135 | > https://tecoble.techcourse.co.kr/post/2021-09-18-replication_clustering/ 136 | > 137 | > https://dheldh77.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81Clustering 138 | > 139 | > https://velog.io/@gkskaks1004/%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81-vs-%EB%A6%AC%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-vs-%EC%83%A4%EB%94%A9 140 | > 141 | > https://velog.io/@hyelimchoi1223/ADP-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0 142 | > 143 | > https://jordy-torvalds.tistory.com/94 144 | > 145 | > https://velog.io/@yangsijun528/%ED%8C%8C%ED%8B%B0%EC%85%94%EB%8B%9D%EA%B3%BC-%EC%83%A4%EB%94%A9 146 | > 147 | > https://seokbeomkim.github.io/posts/partition-and-sharding/ 148 | > 149 | > https://moonsbeen.tistory.com/27 150 | > 151 | > https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html 152 | -------------------------------------------------------------------------------- /Database/ElasticSearch.md: -------------------------------------------------------------------------------- 1 | - Elastic Search 2 | - 아파치 루씬(Apache Lucene) 기반의 검색 엔진 <- 루씬은 정보 검색 라이브러리 3 | - 텍스트 검색(Full Text) 인덱스 및 검색 기능을 필요로 하는 모든 응용 프로그램에 적합하며 특히, 웹 검색 엔진에 많이 쓰인다. 4 | 5 | - 사용 이유 6 | - 일반적인 RDBS의 검색 속도는 O(n)이다. 하지만, Elastic Search를 적용할 경우, O(1)까지 단축시킬 수 있다.
7 | 이러한 단축이 가능한 이유는 해시 테이블 구조의 역색인 방식으로 데이터를 구축하기 때문이다.
8 | 그럼 역색인 방식이 무엇일까?

9 | 간단히 설명하자면, 키워드를 통해서 문서를 찾아내는 방식이다. 10 | 즉, 우리가 책을 읽으면서, 궁금한 키워드가 떠올랐지만, 어느 페이지에 위치하는지 까먹어서 색인을 찾아보고, 11 | 그 키워드의 페이지 정보를 통해, 문서를 찾아낼 수 있다. 12 | 그래서 색인, 역색인을 같이 하는 셈이다. 13 | 14 | ``` 15 | select something from some where something like %anything% 16 | ``` 17 | 위 SQL은 우리가 흔히, RDBMS에서 사용하는 색인 방식이다. 그래서 모든 Row의 내용에 대해 Like를 수행해서 18 | 데이터량이 많은 수록 속도가 많이 떨어지는 단점이 있다. 19 | 하지만, 역색인은 바로 인덱스를 찾아가서 문서를 찾는 방식으로 검색하기 때문에 월등히 빠르다. 20 | ``` 21 | GET /_sql/translate 22 | { 23 | "query": "SELECT something FROM some GROUP BY anything" 24 | } 25 | ``` 26 | 위 포맷은 Elastic Search에서 사용되는 SQL문법이다. 27 | 28 | 29 | - 루씬 기반이므로, 전체 텍스트 검색 성능이 뛰어나다. 30 | - 실시간 플랫폼에 가깝기 때문에 문서가 인덱싱되고 검색 가능까지의 대기시간이 짧다. 31 | - 시간이 중요한 인프라 모니터링이나 보안 분석에 용이하다. 32 | 33 | 34 | - 검색엔진, 검색시스템, 검색서비스 35 | - 검색엔진 : 아파치 루씬 36 | - 검색시스템 : 대용량 데이터를 기반으로 신뢰성 있는 검색 결과를 제공하기 위해, 검색엔진을 기반으로 구축된 시스템을 의미 37 | - 검색서비스 : 검색 엔진을 기반으로 구축한 검색 시스템을 활용해 검색 결과를 서비스로 제공 38 | 39 | 40 | - 검색시스템 구성요소 41 | - 수집기 : 웹 사이트, 블로그, 카페 등 웹에서 필요한 정보를 수집한다. 42 | - 스토리지 : 데이터베이스에서 데이터를 저장하는 물리적인 저장소다. 검색엔진은 색인한 데이터를 스토리지에 보관한다. 43 | - 색인기 : 검색엔진이 수집한 정보에서 사용자 쿼리와 일치하는 정보를 찾으려면, 수집된 데이터를 검색 가능한 구조로 가공하고 저장해야 한다. 44 | - 검색기 : 사용자로부터 쿼리를 입력 받고, 색인기에 저장한 역색인 구조 안에서 일치하는 문서를 찾아 결과로 반환한다. 45 | 46 | 47 | - 관계형 데이터베이스와의 차이점 48 | - RDBMS는 데이터를 통합 관리하는 데이터의 집합이다.
49 | 모든 데이터는 중복을 제거하고, 정형 데이터로 구조화해 행과 열로 구성된 테이블에 저장된다.
50 | 텍스트를 여러 단어로 변형하거나, 여러 개의 동의어나 유의어를 활용한 검색은 불가능하다. 51 | 52 | - 검색엔진은 데이터베이스에서는 불가능한 비정형 데이터를 색인하고 검색할 수 있다.
53 | 형태소 분석을 통해, 사람이 구사하는 자연어의 처리가 가능해지고, 역색인 구조를 바탕으로 빠른 검색 속도를 보장한다. 54 | 55 | - 대칭 용어 56 | - ElasticSearch : RDBMS 57 | - 인덱스 (Index) = 데이터베이스 (Database) 58 | - 샤드 (Shard) = 파티션 (Partition) 59 | - 타입 (Type) = 테이블 (Table) 60 | - 문서 (Document) = 행 (Row) 61 | - 필드 (Field) = 열 (Column) 62 | - 매핑 (Mapping) = 스키마 (Schema) 63 | - QueryDSL = SQL 64 | 65 | 66 | - 엘라스틱서치 주요 API 67 | - 많고 다양한 API가 존재하지만, 밑 4개의 API가 대표적이다.
68 | 그리고 모든 API는 HTTP 방식으로 Restful하게 이용 가능하다. 69 | 70 | - 인덱스 API 71 | - 인덱스를 생성할 때는 매핑(Mapping)을 이용하여 문서에 포함된 필드 및 필드 타입등을 설정 가능하다.
72 | 단, 주의 할 점은 일단 매핑정보가 한번 생성되면, 변경이 불가능하다는 점이다. 잘못 생성했거나 변경해야 할 경우에는 데이터를 삭제하고 재색인 과정을 거쳐야 한다. 73 | 74 | - 생성은 PUT, 삭제는 DELETE 를 사용한다. 75 | - 문서관리 API 76 | - POST, GET, PUT, DELETE 를 사용하여, 데이터를 처리한다. 77 | - 검색 API 78 | - URI 형태의 방식 79 | - RESTful API 방식인 QueryDSL을 사용하여 Request Body에 내용을 추가하여 검색하는 방식 80 | - 집계 API 81 | - 버킷 집계 (Bucket Aggregation) 82 | - 문서의 필드 기준으로 버킷을 집계한다. 83 | - 매트릭 집계 (Metric Aggregation) 84 | - 문서에서 추출된 값을 이용하여 합계, 최대값, 최소값, 평균값 등을 계산한다. 85 | - 매트릭스 집계 (Metrix Aggregation) 86 | - 행렬 값을 합하거나 곱한다. 87 | - 파이프라인 집계 (Pipeline Aggregation) 88 | - 일반적 파이프 라인의 개념으로 집계에 의해 생성된 집계 결과를 이용해 또 다시 집계한다. 89 | 90 | 참고 91 | - https://www.elastic.co/kr/what-is/elasticsearch <- 1차 자료 92 | - https://cornswrold.tistory.com/556 93 | - https://velog.io/@jakeseo_me/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-4-%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%A3%BC%EC%9A%94-API-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-cpjy7x3elf 94 | - https://velog.io/@jakeseo_me/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-3-%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%9A%A9%EC%96%B4-%EB%B0%8F-%EA%B0%9C%EB%85%90-%EA%B0%84%EB%8B%A8%ED%9E%88-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0#%EB%A7%A4%ED%95%91mapping 95 | - https://12bme.tistory.com/589 96 | -------------------------------------------------------------------------------- /Database/Index.md: -------------------------------------------------------------------------------- 1 | # Index 2 | 3 | - 순차 I/O, 랜덤 I/O 4 | - 쿼리 튜닝의 목적 5 | - 인덱스 6 | - B-Tree Index, Hash Index 7 | - MySQL 에서 B-tree 를 사용하는 이유 8 | - 인덱스 레인지 스캔, 인덱스 풀 스캔 9 | - 클러스터링 인덱스, 논 클러스터링 인덱스 10 | - MySQL 에서 PK 를 인조키로 사용하고 Auto_Increment 를 사용하는 이유 11 | 12 | 13 | 14 | ## 순차 I/O, 랜덤 I/O 15 | 16 | - 순차 I/O 17 | - 순차 IO는 시작 위치에서 읽기 시작하여 데이터를 찾는 것 18 | - 원하는 데이터 찾기 위해 full scan 방식 사용 19 | - 인덱스 풀 스캔에 사용 20 | 21 | - 랜덤 IO 22 | - 여러 위치 탐색하여 원하는 데이터를 찾는 것 23 | - 인덱스 레인지 스캔에 사용 24 | 25 | ![image](https://user-images.githubusercontent.com/93963499/163703705-e408712d-4419-4ec7-8c55-bf151530909c.png) 26 | 27 | 순차 I/O 는 3개의 페이지를 디스크에 기록하기 위해서 시스템 콜을 한 번만 요청한 반면에, 랜덤 I/O 는 세 번을 요청했다. 즉, 디스크에 기록할 위치를 찾기 위해 순차 I/O 는 `디스크 헤더`를 한 번 움직였고, 랜덤 I/O 는 헤드를 세 번 움직인 것이다. 28 | 29 | 디스크에 데이터를 쓰고 읽는 데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정된다. 일반적으로 순차 I/O 가 랜덤 I/O 보다 성능이 좋다. 30 | 31 | (하지만 여기서 SSD를 사용하면 얘기가 달라진다. SSD는 HDD와 달리 플래터에 데이터를 기록하지 않고, 플래시 메모리라는 것에 데이터를 저장한다. 이는 원판을 기계적으로 회전시킬 필요가 없으므로 데이터를 매우 빠르게 찾을 수 있다. 그러므로 DBMS용 스토리지에는 SSD가 최적이라고 볼 수 있다.) 32 | 33 | ### 쿼리 튜닝의 목적 34 | 35 | 일반적으로 `쿼리를 튜닝하는 것은 랜덤 I/O 자체`를 줄여주는 것이 목적이며, `랜덤 I/O를 줄인다는 것은 쿼리를 처리하는 데 꼭 필요한 데이터만 읽도록 쿼리를 개선`하는 것을 의미한다. 36 | 37 | ## 인덱스 38 | 39 | RDBMS에서 검색 속도를 높이기 위한 기술이다. 40 | 41 | **테이블의 컬럼을 색인화(따로 파일로 저장)하여** 검색 시 해당 테이블의 레코드를 full scan하는게 아니라, **색인화 되어있는 index 파일을 검색하여 검색 속도를 빠르게** 한다. 42 | 43 | RDBMS의 인덱스의 자료구조는`SortedList`와 비슷하며, 항상 컬럼을 정렬된 값으로 유지한다. `SortedList`는 정렬 상태를 유지하므로 값을 검색할 때 빠르게 가져울 수 있으나, 데이터가 새로 저장될 때마다 항상 값ㅇ르 정렬하므로 저장하는 과정이 느리다. 44 | 45 | 다시 말하면, 46 | 47 | RDBMS에서 사용하는 인덱스는 **B-Tree를 사용해서 색인화**한다. 48 | 49 | (보통 select 쿼리의 where절이나 join 예약어를 사용했을 때,) 인덱스가 사용되며 쿼리의 검색 속도 빠르게 하는 목적이 있다. 50 | 51 | *DELETE, INSERT, UPDATE 쿼리에는 해당 사항이 없으며 INDEX 사용시 오히려 느려진다.* 52 | 53 | #### 정리 54 | 55 | 인덱스(Index) 56 | 57 | - 책의 찾아보기와 같다. 58 | - Key 와 Value 형식으로 이루어져 있다. 59 | - SortedList 로 구현되어있기 때문에 인덱스를 생성할 때 마다, 내부적으로 정렬 되어 저장되어있다. 60 | - INSERT, UPDATE, DELETE 에 대한 성능을 희생하고, READ 에 대한 성능을 높이는 기능이다. 61 | 62 | #### Index를 남발하지 말아야 하는 이유 63 | 64 | 데이터베이스 서버에 성능 문제가 발생하면, **가장 빨리 생각하는 해결책이 인덱스 추가 생성**이다. 65 | 66 | 문제가 발생할 때마다 인덱스를 생성하면서, **인덱스가 쌓여가는 것**은 하나의 쿼리를 빠르게 만들 수 있지만, 전체적인 데이터베이스 성능 부하를 초래한다. 67 | 68 | 조회 성능을 극대화하려 만든 객체인데 많은 인덱스가 쌓여서, Insert, Delete, Update 시에 부하가 발생해 전체적인 데이터베이스 성능을 저하한다. 69 | 70 | 그렇기에 인덱스를 생성하는 것보다는 sql문을 좀 더 효율적으로 짜는 방향으로 나가야 한다. 71 | 72 | **인덱스 생성은 마지막 수단**으로 강구할 문제다. 73 | 74 | ## 인덱스 저장 방식 : B-Tree Index, Hash Index 75 | 76 | B-Tree 방식(가장 일반적으로 많이 쓰임), 해시 방식, Fractal 방식 등이 있다. 77 | 78 | ### B-Tree 79 | 80 | 인덱스에 일반적으로 많이 사용하는 알고리즘이다. 81 | 82 | B-Tree Index 는 컬럼의 값을 변경하지 않고, 원래의 값을 이용해 인덱싱하는 알고리즘이다. 83 | 84 | > B-Tree 의 B 는 Binary 가 아닌 Balanced 를 의미 85 | 86 | #### 밸런스 트리 87 | 88 | - 일반 트리 89 | 90 | ![image](https://user-images.githubusercontent.com/93963499/163704589-1f90539d-dd6d-42ee-a790-49cb6ccbf1fd.png) 91 | 92 | ![image](https://user-images.githubusercontent.com/93963499/163704591-977b179c-de34-4a78-a882-c728fc054420.png) 93 | 94 | 95 | 96 | 일반 트리의 탐색 시간 복잡도는 O(logN)이며, 편향된 트리의 경우 O(N)이다. 이런 경우를 방지하기 위해 밸런스 트리를 적용한다. 97 | 98 | - 밸런스 트리란? 99 | 100 | 트리의 노드가 한 방향으로 쏠리지 않도록, 노드 삽입 및 삭제 시 특정 규칙에 맞게 재 정렬되는 트리다. 101 | 항상 양쪽 자식의 밸런스를 유지하므로 무조건 O(logN)의 시간 복잡도를 지닌다. 102 | 103 | 다만 재정렬되는 작업으로 인해 노드 삽입 및 삭제 시 일반적인 트리보다 성능이 떨어지게 된다. 그러므로 밸런스 트리는 삽입/삭제의 성능을 희생하고 탐색에 대한 성능을 높였다고 볼 수 있다. 104 | 105 | 다시말하면, 밸런스 트리는 최악의 경우에도 O(logN)이므로, 탐색시간에 매우 효율적인 자료구조며, 인덱스는 그 중 B-Tree를 선택했다. (밸런스 트리는 RedBlack-Tree, B-Tree 등이 있다.) 106 | 107 | #### B-Tree 특징 108 | 109 | ![image](https://user-images.githubusercontent.com/93963499/163704716-334ba28c-0d18-4711-825e-b8675c3dd917.png) 110 | 111 | 노드 하나에 여러 데이터가 저장될 수 있다. 각 노드 내 데이터들은 항상 정렬된 상태이며, 데이터와 데이터 사이의 범위를 이용하여 자식 노드를 가진다. 그러므로 자식 노드 개수는 (n+1)을 가진다. 112 | 113 | 항상 좌, 우 자식노드 개수의 밸런스를 유지하므로 최악의 경우에도 무조건 탐색 시간이 O(logN)을 가지게 된다. 114 | 115 | ### Hash 116 | 117 | 컬럼의 값으로 해시 값을 계산해서 인덱싱하는 알고리즘으로 매우 빠른 검색을 지원 118 | 119 | 하지만 값을 변형해서 인덱싱하므로, 특정 문자로 시작하는 값을 검색하는 등 전방 일치와 같이 **값의 일부만으로 검색하고자 할 때는 해시 인덱스를 사용할 수 없다.** 120 | 121 | 데이터 접근에 시간 복잡도가 O(1)인 해시테이블말고 B-Tree를 사용하는 이유는 select 절의 조건에 부등호연산이 포함되면 문제 발생한다. 해시테이블은 = 연산에 특화되어 있다. 그 이유는 해시 테이블은 데이터가 정렬되어 있지 않기 때문이다. 122 | 123 | ### MySQL 에서 B-tree 를 사용하는 이유 124 | 125 | 자세하게 설명되어 있어서 읽어보는 것을 추천합니다!! 126 | 127 | https://helloinyong.tistory.com/296 128 | 129 | https://steady-coding.tistory.com/558 130 | 131 | 트리 종류에는 이진 트리(Binary-Tree), 레드 블랙 트리, B-tree 등 다양한 종류들이 존재하는데 MySQL 에서 B-tree 를 사용한다. 132 | 133 | - 왜 보편적으로 레드 블랙 트리 대신 B-Tree 자료구조를 적용하는가? 134 | 135 | 레드 블랙 트리는 노드 하나에 데이터 하나만 저장하므로 어떠한 요소를 탐색하든 참조 포인터 접근이 필수적이다. 반면, B-Tree는 하나의 노드에 여러 개의 데이터를 저장하므로 각 노드의 데이터 요소를 탐색할 때 참조 포인터 접근 없이 배열의 성질을 이용하여 빠르게 탐색이 가능하다. 결론적으로 참조 포인터의 접근 수가 B-Tree가 훨씬 적으므로 B-Tree를 인덱스의 자료 구조로 사용한다. 136 | 137 | - 왜 보편적으로 해시 테이블 대신 B-Tree 자료구조를 인덱스로 사용하는가? 138 | 139 | 해시 테이블 내의 데이터는 정렬이 되어 있지 않으므로 부등호 연산이 불가능하다. 인덱스의 특성상 기준 값보다 크거나 작은 요소를 탐색하는 경우가 많은데, 이러한 이유로 B-Tree를 인덱스의 자료 구조로 사용한다. 140 | 141 | ## 인덱스 레인지 스캔, 인덱스 풀 스캔 142 | 143 | 인덱스를 이용해 데이터를 읽는 법은 레인지 스캔과 풀 스캔이 있다. 144 | 145 | ### 인덱스 레인지 스캔 146 | 147 | 가장 빠른 스캔 방법이다. 148 | 149 | **인덱스 레인지 스캔은 검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방식이다.** 150 | 151 | 주로, `<`, `>`, `IS NULL`, `BETWEEN`, `IN`, `LIKE` 등의 연산을 이용하여 인덱스를 검색할 때 사용된다. 152 | 153 | ### 인덱스 풀 스캔 154 | 155 | 인덱스의 처음부터 끝까지 스캔하는 방식을 말한다. 156 | 157 | 인덱스에 저장된 데이터만으로 모든 것을 처리할 수 있는 경우이거나, 멀티인덱스의 중간 값 부터 조건을 지정하였을 경우 발생한다. 158 | 159 | 리프 노드의 첫번째 데이터 부터 순차적으로 읽어 내려가며, 하나의 리프노드가 끝났을 경우 해당 리프노드의 링크드리스트를 통해 다음 리프노드로 넘어가 끝까지 읽는 방식이다. 160 | 161 | ## 클러스터링 인덱스 162 | 163 | 클러스터링 인덱스는 기본키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 말한다. 기본키값에 의해 레코드 저장 위치가 결정되기 때문에, 기본키 값이 변경된다면 레코드의 물리적인 저장 위치가 변경되어야 한다. 164 | 165 | InnoDB와 같이 항상 클러스터링 인덱스로 저장되는 테이블은 기본키 기반의 검색이 매우 빠른 대신, 레코드의 저장이나 기본키의 변경이 비교적 느리다. 만약 기본키가 없다면, InnoDB 스토리지 엔진은 다음 우선순위대로 컬럼을 선택한다. 166 | 167 | *1. NOT NULL 속성을 가지고 있는 유니크 인덱스 중에서 첫번째 인덱스를 클러스터 키로 선택* 168 | 169 | *2. 자동으로 유니크한 값을 가지고 증가하는 컬럼을 내부적으로 추가한 후, 클러스터 키로 선택* 170 | 171 | 2번과 같이 적절한 클러스터 키 후보를 찾지 못해서 내부적으로 자동 증가 컬럼을 추가한 경우, 사용자에게 노출되지 않고 쿼리에서 명시적으로 사용할 수 없다. 172 | 173 | ### 장단점 174 | 175 | 기본키, 즉 클러스터 키로 검색할 때 처리가 매우 빠르며 테이블의 모든 보조 인덱스가 클러스터 키를 가지고 있기 때문에 인덱스만으로 처리할 수 있는 경우가 많다. 하지만, 모든 보조 인덱스가 클러스터 키를 가지고 있기 때문에 키값의 크기가 클 경우 전체적인 인덱스 크기가 커진다. 176 | 177 | ## MySQL 에서 PK 를 인조키로 사용하고 Auto_Increment 를 사용하는 이유 178 | 179 | 예를들어, PK 가 주민등록번호로 잡혀있다고 해보자. 180 | 181 | PK 가 주민등록 번호로 잡게되면 `DB 성능 이슈`가 생길 수 있다. 왜 일까? 182 | 183 | 바로 클러스터링 인덱스의 특징을 떠올리면 되는데, 클러스터링 인덱스는 PK 의 등록, 변경에 있어 느리다고 하였다. 즉, AUTO_INCREMENT 로 되어있지 않으면 회원의 주민등록번호에 따라서 PK 위치 조정이 빈번하게 일어날 것이기 때문에 성능 이슈가 발생할 수 있다. 184 | 185 | 따라서, 주민등록번호를 유니크 키로 잡고, PK 를 인조키로 생성하는 것이 좋다. 186 | 187 | ### Reference 188 | 189 | - https://github.com/NKLCWDT/cs/blob/main/Database/Index%2C%20Hint.md 190 | 191 | - https://joont92.github.io/db/mysql-index/ 192 | 193 | - https://gyoogle.dev/blog/computer-science/data-base/Index-.html 194 | - https://helloinyong.tistory.com/296 195 | - https://steady-coding.tistory.com/558 196 | - https://lkhlkh23.tistory.com/112 197 | 198 | - https://bangsj1224.tistory.com/entry/%EA%B8%B0%EB%B3%B8%ED%82%A4%EC%99%80-AutoIncrement -------------------------------------------------------------------------------- /Database/RDB vs NoSQL.md: -------------------------------------------------------------------------------- 1 | # RDB 2 | 3 | - 관계형 데이터 모델에 기초를 둔 데이터베이스 4 | - 데이터를 2차원 테이블 형태로 표현 5 | - key와 value의 관계를 테이블화 시켰다 6 | 7 | ![RDB구조](https://user-images.githubusercontent.com/42866800/161411255-a7c32567-4bac-4e96-af05-b2e5d39a622f.png) 8 | 9 | # RDBMS 10 | 11 | - 관계형 데이터베이스를 생성하고 관리할 수 있는 소프트웨어 12 | - 개체(entity) , 관계(relationship)를 테이블로 표현 13 | - 개체 - 독립적으로 존재하는 대상 14 | - 테이블은 row와 column으로 구성된 데이터 저장 단위 15 | - `R` 16 | - 개체 또는 속성들의 관계 17 | - 여러개의 테이블을 조합해 원하는 데이터를 찾아올 수 있게 한다 18 | - 테이블 한 개로 데이터를 얻을 수 없는 경우 관계성을 이용해 더 복잡한 연산 수행 19 | - `MS` 20 | - 테이블에 데이터를 삽입 조회 수정 삭제 할 수 있도록 도와주는 소프트웨어 21 | - DBMS가 SQL을 통해 가능하다 22 | 23 | ## ER(Entity Relation) 모델 24 | 25 | - 세상의 사물을 개체(Entity)와 개체의 관계로 표현함 26 | - 개체 : 독립적인 의미를 지니고 있는 유무형의 사람 또는 사물. 개체의 특성을 나타내는 속성(attribute)에 의해 식별됨. 27 | - 개체끼리 서로 관계를 가짐. 28 | 29 | ![er모델링](https://user-images.githubusercontent.com/42866800/161411260-bb2a5b1b-8db9-4cb3-b701-dafa4a4e55c1.png) 30 | 31 | ## 관계형 데이터베이스 구조 32 | 33 | - 모든 데이터를 2차원 테이블로 표현 34 | - 테이블은 유일한 이름을 가짐 35 | - 열은 필드 , 아이템 , 컬럼 36 | - 행은 레코드 , 튜플 , 로우 37 | - `key` - 테이블에서 레코드를 유일하게 식별할 수 있는 속성의 집합 38 | - 기본키 - 레코드를 유일하게 식별할 수 있는 속성의 집합 39 | - 외래키 - 어떤 테이블의 기본 키를 다른 테이블에서 사용할때 지정할수 있는 키 40 | 41 | 42 | ![관계형 데이터베이스](https://user-images.githubusercontent.com/42866800/161411262-fd72426c-d571-4290-accb-98a5945d1856.png) 43 | 44 | ## 조인 연산 45 | 46 | - 두개 이상의 테이블을 연결시켜 필요한 데이터를 선택 47 | - 고객이 어떤 상품을 언제 가장 많이 팔았는지 알고싶을때 48 | - **이런 경우에는 상품 테이블과 고객 테이블을 같이 이용해야 하는데 이 때 조인(join) 연산 이용** 49 | 50 | ![rdb조인](https://user-images.githubusercontent.com/42866800/161411302-279d60ba-8db9-4661-851d-6a9310e99a31.png) 51 | -42fb-9d25-4326737d18ff.png) 52 | # NoSQL 53 | 54 | - 기존 관계형 DBMS가 갖고 있는 특성 + 다른 부가적인 특성을 지원 55 | - 데이터 저장및 검색을 위한 특화된 메커니즘 56 | - 최적화된 키 값 저장 기법 → 응답속도 , 처리 효율성 높음 57 | 58 | ![mongodb vs rdb](https://user-images.githubusercontent.com/42866800/161411270-079f2677-3cd7-4273-a75c-36ba0a552494.png) 59 | - mongoDB의 경우 도큐먼트에 접근하여 JSON 형식으로 CRUD 작업 진행 60 | 61 | ![rdb nosql _ 쿼리 질의방법](https://user-images.githubusercontent.com/42866800/161411272-07fc159f-c250-46c1-9916-1792ab694fe6.png) 62 | ## NoSQL- mongodb 63 | 64 | - key - value 쌍으로 데이터 저장 65 | - JSON 형식으로 데이터를 관리 66 | 67 | ![NoSQL 임베디드 방식 vs 레퍼런스 방식](https://user-images.githubusercontent.com/42866800/161411274-0d7b87f7-3d78-4291-84e4-9736b620ed1d.png) 68 | 69 | # RDB vs NoSQL 70 | 71 | - 테이블을 연결해서 조회하는 조인 기능이 없다 72 | - 데이터 조회 하기위해 직접 SQL을 작성하지 않아도 된다 73 | - 데이터의 속성값이 다양한 타입을 갖는다 74 | - 비 관계형 데이터베이스 75 | - 조인을 지원하지 않음 76 | 77 | -------------------------------------------------------------------------------------------- 78 | 79 | # RDBMS Master 와 Slave 80 | 81 | - 이중화 구성 -Replication 82 | - 데이터가 날아가는 것 방지 83 | - `Master` 84 | - 등록 / 수정 / 삭제 쿼리 요청시 BinaryLog를 생성하여 slave로 전달 85 | - `Slave` 86 | - Master 정보 복제 87 | - 조회 쿼리 요청 처리 88 | - 디비 부하 분산 89 | 90 | ![master와 slave](https://user-images.githubusercontent.com/42866800/161411363-cc0088d7-ed0c-4925-8959-ecac67646aa6.png) 91 | 92 | - (1) Client가 쓰기 쿼리 작업을 요청합니다. 쓰기 쿼리요청은 Master DB가 받는다 93 | - (2) Master는 변경사항을 Binary log 파일에 기록합니다. 이후 DB에 반영(commit)한다. 94 | - (3) Slave는 현재까지 기록한 이벤트 정보 (GTID=2)를 가지고 다음 이벤트 정보를 Master에게 요청한다. 95 | - (4) Master는 Binary log 파일에서 최신 이벤트 정보(GTID=3)를 읽어 96 | - (5) Slave에게 전송한다. 97 | - (6) Slave는 Master에게 받은 이벤트 정보(GTID=3)를 Relay log 파일에 기록한다. 98 | - (7) Slave는 최종 변경사항을 DB에 반영(commit)한다. 99 | - (4)(5) 과정에서는 Master 쓰레드, (3)(6) 과정에서는 Slave I/O 쓰레드, (7) 과정에서는 Slave SQL 쓰레드가 동작합니다. 100 | 101 | `MasterThread` 102 | 103 | - Binary Log를 읽어 Slave 쪽으로 데이터 전송 104 | - Slave가 클라이언트 , Master가 서버입장에서 응답을 하는 구조 105 | 106 | `Slave I/O Thread` 107 | 108 | - Master로 부터 Binary Log 데이터를 받아 Relay 로그 파일에 기록 109 | 110 | `Slave SQL Thread` 111 | 112 | - relay log에 반영된 내용을 읽어 DB에 반영 (커밋) 113 | 114 | 참고 - 115 | 116 | [https://jwprogramming.tistory.com/52](https://jwprogramming.tistory.com/52) 117 | 118 | [http://thecoding.kr/관계형-데이터베이스rdb/](http://thecoding.kr/%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4rdb/) 119 | 120 | [https://jwprogramming.tistory.com/70](https://jwprogramming.tistory.com/70) 121 | 122 | [https://meetup.toast.com/posts/275](https://meetup.toast.com/posts/275) 123 | 124 | [https://it-sunny-333.tistory.com/148](https://it-sunny-333.tistory.com/148) 125 | 126 | [https://intrepidgeeks.com/tutorial/02rdb](https://intrepidgeeks.com/tutorial/02rdb) 127 | 128 | [https://ko.wikipedia.org/wiki/관계형_데이터베이스](https://ko.wikipedia.org/wiki/%EA%B4%80%EA%B3%84%ED%98%95_%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4) 129 | -------------------------------------------------------------------------------- /Database/README.md: -------------------------------------------------------------------------------- 1 | r -------------------------------------------------------------------------------- /Database/Redis.md: -------------------------------------------------------------------------------- 1 | - 레디스 2 | - 레디스란? 3 | - Remote Dictionary Server의 약자이며, Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 NoSQL이며
4 | DB뿐만 아니라, Cache, Message Broker, Streaming Engine으로도 사용된다. 5 | 6 | - MessageBroker 7 | - 실시간 데이터를 처리할 때, A라는 서버는 데이터 수집 서버, B라는 서버는 수집된 데이터를 가공해서 사용하는 서버 라고 가정해보자
8 | B서버가 A 서버의 데이터를 실시간으로 조회하여 데이터를 처리할 수는 있지만, 성능이 그렇게 좋지는 않다.
9 | 그래서 MessageBroker를 이용하여 처리하면 속도를 더 빠르게 할 수 있는데 이러한 방식을 Publisher/Subscriber 라고 부른다.

10 | Publisher는 데이터를 전송하는 쪽이고, Subscriber는 데이터를 받아서 처리하는 쪽이다.
11 | 이 중간 지점의 MessageBroker는 Message Queue 안에 Publisher로부터 온 데이터를 보관하고,
12 | Subscriber는 굳이 조회 쿼리를 던지지 않고 데이터를 가져올 수 있다.

13 | 이러한 점 덕분에 조회 쿼리를 사용하는 것보다 성능이 더 빠르지만, 단점은 쿼리를 사용해서 가져오는 것이 아니기 때문에
14 | 순수 적재된 데이터를 가져와서 가공시켜서 사용하거나, 적재할 때 필터링된 데이터를 적재하거나 혹은 Logstach로 필터링해서 사용해야 한다.

15 | 16 | *Logstach = 데이터 처리 파이프라인에 사용되는 경량 오픈 소스
17 | *Apache Kafka, RabbitMQ 등이 대표적인 MessageBroker 오픈 소스다. 18 | 19 | 20 | - 특징 21 | - 인메모리 데이터 구조 22 | - 모든 데이터를 디스크가 아닌, 메모리에 저장하고 조회한다. 따라서, I/O 속도가 빠르다.
23 | 24 | - 다양한 데이터 형식 지원 25 | - value값으로 String, List, Set, Hash 등 여러 데이터 형식을 지원한다. 26 | 27 | - 트랜잭션 28 | - 레디스의 트랜잭션은 직렬화(Object -> Byte)가 되고, 순서를 보장하면서 실행한다.
29 | 따라서, 중간에 다른 트랜잭션이 추가되어도, 실행 순서는 보장된다. 30 | 31 | - 레디스는 트랜잭션의 롤백 기능을 제공하지 않는다.
32 | 그 이유는 레디스가 추구하는 간편성과 성능에 영향을 미치기 때문이다. 33 | 34 | - 센티넬 35 | - 기능 36 | - 모니터링 = 마스터/슬레이브가 문제없이 작동중인지 지속적으로 확인. 37 | - 공지 = 레디스 인스턴스에 문제가 생기면 시스템 관리자에게 공지. 38 | - 자동장애복구 = 마스터가 죽으면, 자동으로 슬레이브를 마스터로 승격시키고,
39 | 죽었던 마스터가 살아나면, 이전에 승격된 마스터의 슬레이브가 된다. 40 | 41 | - 클러스터 42 | - 기능 43 | - 샤딩 = 자동으로 데이터를 분산시켜서 저장한다. 44 | - 자동장애복구 = 센티넬과 동일하다. 45 | 46 | - 센티넬과 클러스터의 차이점 47 | - 센티넬은 하나의 마스터 구조를 가지기 때문에 데이터 사이즈가 커지면,
48 | ScaleUp(하드웨어 성능 업그레이드)을 해야 하지만, 클러스터는 ScaleOut(서버 추가)이 가능하다. 49 | 50 | 51 | - 레디스의 메모리 52 | - 물리적인 메모리보다 더 초과해서 사용할 수 없기 때문에 메모리 관리가 매우 중요하다. 53 | - 메모리가 부족할 경우, SWAP을 활용하는데 SWAP이란 간단히 말해서, 메모리 용량이 부족하여
54 | 하드디스크에 SWAP 공간을 만들어서 임시적으로 사용하는 것이다.
55 | 문제는 이러한 SWAP이 일어날 때, 레이턴시가 발생하므로, 속도가 느려진다.
56 | 즉, Redis의 속도가 느려진다는 것은 메모리 관리가 제대로 되지 않고 있다는 뜻이다. 57 | 58 | - 레디스의 장점 59 | - 리스트 형식의 경우, 입력 및 삭제 속도가 Mysql에 비해 약 10배 빠르다. 60 | - 여러 프로세스에서 동시에 같은 Key에 대한 갱신을 요청할 경우, 안정성을 보장한다.
61 | 즉, 데이터 정합성을 유지시켜주는 함수를 제공해준다. 62 | - 다중 서버 구성을 할 수 있으며, 기존 RDBMS처럼 Master와 Slave 형식으로 구성도 가능하다. 63 | 64 | - 레디스의 용도 65 | - 메인 DB로 사용하기 보다는 보조 DB로 사용한다. 66 | - 그래서 일종의 캐시DB 역할을 한다고 보면 된다. 67 | 68 | - CAP 69 | - Consistency 일관성 = 데이터의 일관성이 깨지면 안 된다. 즉, 항상 동일한 데이터를 유지해야 한다. 70 | - Availiability 가용성 = 읽기/쓰기가 가능해야 한다. 71 | - Partition Tolerance 지속성 = 데이터 손실이 발생하더라도, 서비스는 지속되어야 한다. 72 | 73 | - 레디스는 C와 P의 조합이라고 하는데, 단일 노드의 경우 일관성이 지켜져서 맞는 조합이 되지만,
74 | 분산 시스템으로 구축하면, 마스터/슬레이브로 구성되기 때문에 일관성을 완벽히 지킬수는 없다.
75 | 그리고 CA는 RDBMS의 조합이다. 일관성과 가용성을 제공하지만, 데이터 손실이 발생할 경우, 네트워크가 다운될 수 있다. 76 | 77 | 78 | 79 | 80 | - 참고 81 | - https://stackoverflow.com/questions/59511275/redis-availability-and-cap-theorem 82 | - https://redis.io/docs/manual/sentinel/ 83 | - https://redis.io/docs/reference/cluster-spec/ 84 | - https://velog.io/@always/Redis-%EC%9A%B4%EC%98%81-%EB%B0%A9%EC%8B%9D-Cluster-vs-Sentinel-%EC%96%B4%EB%96%A4-%EA%B2%83%EC%9D%84-%EC%84%A0%ED%83%9D%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C 85 | - https://zangzangs.tistory.com/72 86 | -------------------------------------------------------------------------------- /Database/Transaction.md: -------------------------------------------------------------------------------- 1 | # Transaction 2 | 3 | - 트랜잭션 4 | - 트랜잭션 사용하는 이유 5 | - ACID (트랜잭션 특징) 6 | - 트랜잭션 연산 7 | - 트랜잭션 상태 8 | - 트랜잭션 격리 수준 9 | - Isolation level 격리 수준 10 | - Isolation level 필요성 11 | - Isolation level 종류 12 | - 트랜잭션 격리 수준 설정할 때 발생하는 문제점들 13 | 14 | 15 | 16 | ## 트랜잭션 17 | 18 | | **데이터베이스의 상태를 변화시키기 위해 수행하는 논리적 작업 단위** 19 | 20 | - `상태 변화시킨다는 것` -> SQL 질의어를 통해 DB에 접근 21 | - 예를 들어, SELECT, INSERT .. 22 | 23 | - `작업 단위` -> 많은 SQL 명령문들을 사람이 정하는 기준에 따라 정해짐 24 | 25 | > 예시 : A가 B에게 만원 송금한다. 26 | > A 계좌 차감(출금 UPDATE) + B계좌 입금(입금 UPDATE) 27 | > -> 통틀어 하나의 트랜잭션이라고 함 28 | > -> 두 쿼리가 성공적으로 완료되어야 트랜잭션이 완료됨 `Commit` 29 | > -> 작업 단위의 쿼리 중 하나라도 실패하면 모든 쿼리문을 취소하고 이전상태로 돌려놓음 `Rollback` 30 | 31 | ### 트랜잭션을 사용하는 이유 32 | 33 | 트랜잭션은 하나의 논리적인 작업의 단위이기 때문에, 여러개의 작업을 하나의 논리적인 단위로 묶어서 반영과 복구를 할 수 있다. 34 | 35 | 트랜잭션을 통해 데이터베이스의 회복과 병행 제어가 가능하다. 즉, 데이터베이스에서 오류가 발생하면, 빠른 회복, 여러 사용자가 동시에 데이터베이스를 사용할 수 있도록 제어해주는 역할을 한다. 36 | 37 | ### 트랜잭션 특징 ACID 38 | 39 | - 원자성(Atomicity) 40 | 41 | > 트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 된다. 42 | 43 | - 커밋 OR 롤백 연산을 통해 원자성을 보장 44 | 45 | - 일관성(Consistency) 46 | 47 | > 트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다. 48 | 49 | - 명시적 일관성 : 기본키, 외래키 등 무결성 제약조건을 해치지 않는 데이터들 대해서만 트랜잭션 수행되어야 한다. 50 | - 비명시적 일관성 : 예) 계좌 이체에서, A 계좌에서 출금이 일어나고 그 돈이 B 계좌로 입금된다 했을 때, 트랜잭션의 전과 후 두 계좌 잔고의 합이 같아야 한다. 51 | 52 | - 독립성(Isolation) 53 | 54 | > 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다. 55 | 56 | - 지속성(Durability) 57 | 58 | > 트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다. 59 | 60 | ### 트랜잭션 연산 61 | 62 | - COMMIT 63 | 64 | 하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성있는 상태일 때 이를 알려주는 연산 65 | 66 | - ROLLBACK 67 | 68 | 트랜잭션 포함된 쿼리 중 하나라도 실패하면 모든 쿼리문을 취소하고 이전상태로 돌려놓음 -> 롤백하면 해당 트랜잭션 재시작하거나 폐기 69 | 70 | ### 트랜잭션 상태 71 | 72 | ![image](https://user-images.githubusercontent.com/93963499/162607638-61275162-752d-499f-9685-a9347518d597.png) 73 | 74 | **1. 활성화(Active)** **:** 트랜잭션이 작업을 시작하여 실행 중인 상태 75 | 76 | **2. 실패(Failed) :** 트랜잭션에 오류가 발생하여 실행이 중단된 상태 77 | 78 | **3. 철회(Aborted) :** 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태 79 | 80 | **4. 부분 완료(Partially commited) :** 트랜잭션의 마지막 연산까지 실행하고 commit 요청이 들어온 직후의 상태. 최종 결과를 데이터베이스에 아직 반영하지 않은 상태. 81 | 82 | **5. 완료(Commited) :** 트랜잭션이 성공적으로 종료되어 commit 연산을 실행한 후의 상태 83 | 84 | #### 질문 1. 트랜잭션의 Commit 연산에 대해서 트랜잭션의 상태를 통해 설명해주세요. 85 | 86 | 트랜잭션이 시작되면 Active 상태가 되고, 모든 연산이 실행되면 Partially commited 상태가 된다. 그리고 Commit 연산을 실행하면 Commited 상태가 되어 트랜잭션을 성공적으로 종료한다. 87 | 88 | #### 질문 2. 트랜잭션의 Rollback 연산에 대해서 트랜잭션의 상태를 통해 설명해주세요. 89 | 90 | 트랜잭션이 시작되면 Active 상태가 되고, 트랜잭션 중 오류가 발생하여 중단되면 실패(Failed) 상태가 된다. 그리고 Rollback 연산을 수행한 후, 철회(Aborted) 상태가 되어 트랜잭션이 종료되고 실행 이전 상태로 돌아간다. 91 | 92 | 93 | 94 | ## 트랜잭션 격리 수준 (Isolation level) 95 | 96 | ### Isolation level 97 | 98 | 트랜잭션에서 일관성 없는 데이터를 허용하도록 하는 수준 99 | 100 | ### Isolation level 필요성 101 | 102 | 트랜잭션 ACID의 독립성과 관련이 있다. 103 | 104 | 트랜잭션 독립성을 보장하기 위해 Locking을 통해, 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요하다. 105 | 106 | 하지만 무조건 Locking으로 동시에 수행되는 수많은 트랜잭션들을 순서대로 처리하는 방식으로 구현하게 되면 데이터베이스의 성능은 떨어지게 될 것이다. 107 | 108 | 그렇다고 해서, 성능을 높이기 위해 Locking의 범위를 줄인다면, 잘못된 값이 처리될 문제가 발생하게 된다. 109 | 110 | 따라서 최대한 효율적인 Locking 방법이 필요하다. 111 | 112 | ### Isolation level 종류 113 | 114 | 트랜잭션 격리(고립화) 수준이 중요한 이유는, 격리 레벨을 어떻게 설정하느냐에 따라 읽기 일관성이 달라지기 때문이다. 다시 말하면, **트랜잭션 격리 수준에 따라 데이터 조회 결과가 달라질 수 있다는 말이다.** 115 | 116 | 이처럼 트랜잭션 격리 수준에 따라 데이터 조회 결과가 달라지게 하는 기술을 `MVCC(Multi Version Concurrency Consistency)` 라고 한다. 117 | 118 | #### 레벨 0 : Read Uncommitted 119 | 120 | - 트랜잭션에서 처리 중인, 아직 커밋 되지 않은 데이터를 다른 트랜잭션에서 읽는 것을 허용 121 | 122 | > 트랜잭션1이 A라는 데이터를 B라는 데이터로 변경하는 동안 트랜잭션2는 아직 완료되지 않은(Uncommitted) 트랜잭션1이지만 데이터B를 읽을 수 있다. 123 | 124 | - 데이터베이스의 일관성을 유지하는 것이 불가능함 125 | - 발생할 수 있는 문제 126 | - `Dirty Read, Non-Repeatable Read, Phantom Read 현상 발생` 127 | - 예시에서는 Dirty Read 발생 128 | 129 | ~~~ 130 | 1. A 트랜잭션에서 10번 사원의 나이를 27살에서 28살로 바꿈 131 | 2. 아직 커밋하지 않음 132 | 3. B 트랜잭션에서 10번 사원의 나이를 조회함 133 | 4. 28살이 조회됨 -> 이를 더티 리드(Dirty Read)라고 한다 134 | 5. A 트랜잭션에서 문제가 발생해 ROLLBACK함 135 | 6. B 트랜잭션은 10번 사원이 여전히 28살이라고 생각하고 로직을 수행함 136 | ~~~ 137 | 138 | 데이터 정합성에 문제가 많으므로, RDBMS 표준에서는 격리수준으로 인정하지도 않는다. 139 | 140 | #### 레벨 1 : Read Committed 141 | 142 | - 커밋된 데이터를 다른 트랜잭션이 조회하는 것을 허용 143 | - SQL 서버가 Default로 사용하는 Isolation Level임 144 | 145 | > 트랜잭션1이 A라는 데이터를 B라는 데이터로 변경하는 동안 트랜잭션2는 해당 데이터에 접근이 불가능함 146 | 147 | - 발생할 수 있는 문제 148 | - Non-Repeatable Read, Phantom Read 현상은 여전히 발생 149 | - 예시에서는 `NON-REPETABLE READ` 부정합 문제가 발생 150 | 151 | ~~~ 152 | 1. B 트랜잭션에서 10번 사원의 나이를 조회 153 | 2. 27살이 조회됨 154 | 3. A 트랜잭션에서 10번 사원의 나이를 27살에서 28살로 바꾸고 커밋 155 | 4. B 트랜잭션에서 10번 사원의 나이를 다시 조회(변경되지 않은 이름이 조회됨) 156 | 5. 28살이 조회됨 157 | ~~~ 158 | 159 | 하나의 트랜잭션 내에서 똑같은 SELECT를 수행했을 경우 항상 같은 결과를 반환해야 한다는 REPEATABLE READ 정합성에 어긋나는 것이다. 160 | 161 | 일반적으로 큰 문제가 되지 않을 수도 있으나, 금융쪽에서는 문제가 발생할 수 있다. 162 | 163 | 예를 들어 여러 트랜잭션에서 입금/출금 처리가 계속 진행되는 트랜잭션들이 있고 오늘의 입금 총 합을 보여주는 트랜잭션이 있다고하면, 총합을 계산하는 SELECT 쿼리는 실행될 때 마다 다른 결과값을 가져올 것이다. 164 | 165 | #### 레벨 2 : Repeatable Read 166 | 167 | - **트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있는 격리수준** 168 | - MySQL InnoDB 에서 기본으로 사용 169 | 170 | > 트랜잭션1 이 읽은 데이터는 트랜잭션1이 종료될 때가지 트랜잭션2이 `갱신하거나 삭제하는 것은 불허함`으로써 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴, 하지만 삽입은 가능 171 | 172 | - 발생할 수 있는 문제 173 | - Phantom Read 현상은 여전히 발생 174 | - 이 예시는 InnoDB 에서 발생한 Non-Repeatable Read 발생 175 | 176 | ~~~ 177 | 1. 10번 트랜잭션이 500000번 사원을 조회 178 | 2. 12번 트랜잭션이 500000번 사원의 이름을 변경하고 커밋 179 | 3. 10번 트랜잭션이 500000번 사원을 다시 조회 180 | 4. 백업된 데이터 반환 181 | 5. 자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 변경된(+커밋된) 결과 조회됨 182 | ~~~ 183 | 184 | REPETABLE READ 격리수준에서는 트랜잭션이 시작된 시점의 데이터를 일관되게 보여주는 것을 보장해야 하기 때문에 한 트랜잭션의 실행시간이 길어질수록 해당 시간만큼 계속 멀티 버전을 관리해야 하는 단점이 있다. (?) 185 | 186 | #### 레벨 3 : Serializable Read 187 | 188 | - 가장 단순하고 가장 엄격한 격리수준이다. 189 | 190 | - 완벽한 읽기 일관성 모드를 제공함 191 | 192 | - 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능 193 | 194 | > 트랜잭션1 이 읽은 데이터를 트랜잭션2 이 갱신하거나 삭제하지 못할 뿐만 아니라 중간에 새로운 레코드를 삽입하는 것도 막아줌 195 | 196 | 이러한 특성 때문에 동시처리 능력이 다른 격리수준보다 떨어지고, 성능저하가 발생하게 된다. 197 | 198 | ## 트랜잭션 격리 수준 설정할 때 발생하는 문제점들 199 | 200 | 트랜잭션 격리 수준을 너무 낮게(0 레벨)하면 읽기 일관성을 제대로 보장할 수 없고, 반면 너무 높게하면, 읽기 일관성은 완벽하게 보장하지만 데이터를 처리하는 속도가 느려지게 된다. 201 | 202 | - Read Uncommitted > Read Committed > Repeatable Read > Serializable Read 203 | - ReadUncommitted 로 갈 수록 동시성은 높아지고, 일관성은 떨어진다. 204 | - Serializable Read 로 갈 수록 동시성은 떨어지고, 일관성은 높아진다. 205 | 206 | - 따라서, 트랜잭션 격리 수준은 `일관성` 및 `동시성`과도 연관이 있다는 것을 알 수있다. 207 | 208 | ### 낮은 단계 Isolation Level을 활용할 때 발생하는 현상들 209 | 210 | - **Dirty Read** 211 | 212 | 커밋되지 않은 수정중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상 213 | 214 | 어떤 트랜잭션에서 아직 실행이 끝나지 않은 다른 트랜잭션에 의한 변경사항을 보게되는 경우 215 | 216 | - **Non-Repeatable Read** 217 | 218 | 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션 값을 수정 또는 삭제하면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨진 현상 219 | 220 | - **Phantom Read** 221 | 222 | 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상 223 | 224 | 트랜잭션 도중 새로운 레코드 **삽입을 허용하기 때문에** 나타나는 현상임 225 | 226 | ![image](https://user-images.githubusercontent.com/93963499/162610051-3c4f66e6-62ff-40d9-8a10-2087b62d69dc.png) 227 | 228 | ## QnA 229 | 230 | 231 | 232 | ### Reference 233 | 234 | - https://github.com/NKLCWDT/cs/blob/main/Database/Transaction.md 235 | - https://joont92.github.io/db/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B2%A9%EB%A6%AC-%EC%88%98%EC%A4%80-isolation-level/ 236 | 237 | - https://gyoogle.dev/blog/computer-science/data-base/Transaction%20Isolation%20Level.html 238 | 239 | - https://github.com/Seogeurim/CS-study/tree/main/contents/database 240 | 241 | - https://rebro.kr/162 -------------------------------------------------------------------------------- /Database/동시성 제어.md: -------------------------------------------------------------------------------- 1 | ## 무엇 2 | 3 | 동시에 실행되는 여러 개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법이다. 4 | 5 | ## 왜씀 6 | 7 | - 다중 사용자 환경을 지원하는 데이터 베이스 시스템에서 여러 트랜잭션들이 성공적으로 동시에 실행될 수 있도록 지원하는 기능 8 | - 다중 사용자 환경을 지원하는 DB system의 경우 필수적으로 지원해야 하는 기능으로 병행제어라고도 한다. 9 | - 트랜잭션의 직렬화 수행 보장 10 | ![트랜잭션 직렬화](https://user-images.githubusercontent.com/42866800/163695862-c1d61155-d977-4dc8-8d6c-819887f463f2.png) 11 | 12 | ### 동시성 제얼르 하지 않았을때 발생하는 문제 13 | ![동시성 제어를 하지 않을 시](https://user-images.githubusercontent.com/42866800/163695775-76de4c5b-f098-4e22-9e7c-5a11cdb7081a.png) 14 | - 갱신 손실 15 | - 두개 이상의 트랜잭션이 동시에 똑같은 한개의 데이터를 수정시에 발생하는 문제 16 | - 한 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화 되는일이 발생 17 | 18 | - 현황 파악 오류 19 | - 한 트랜잭션이 수정을 하고 그 수정사항을 커밋하지 않았을때 다른 트랜잭션이 같은 데이터를 접근할때 발생하는 문제 20 | 1. Non Repeatable read 21 | 2. 한 트랜잭션에 같은 데이터를 두번이상 읽는데 그 한 트랜잭션에서 같은 데이터가 다른 값을 읽을 때 발생하는 문제이다. 22 | 23 | 24 | 25 | 1. Phantom Read 26 | 2. 한 트랜잭션이 같은 데이터를 한번 읽고 이후 같은 데이터를 읽었을때 그 데이터가 존재하지 않는것 27 | 28 | phantomRead 29 | 30 | 31 | 1. Incorrect Summary 32 | 2. 한 트랜잭션이 일부 레코드에 집계 함수를 적용하는 동안 다른 트랜잭션이 같은 데이터베이스를 업데이트하는 상황을 생각해 보자. 업데이트하는 트랜잭션의 몇개의 데이터는 변경을 했고 아직 다른 몇개의 데이터는 변경하지 못한상황에서 집계 함수는 값이 업데이트되기 전에 값을 계산하고 업데이트된 후에 값을 계산할 수 있습니다. 33 | 34 | ![https://github.com/NKLCWDT/cs/raw/main/images/incorrectSummary.png](https://github.com/NKLCWDT/cs/raw/main/images/incorrectSummary.png) 35 | 36 | 37 | ### 동시성 제어 방법 38 | ![동시성 제어 방법](https://user-images.githubusercontent.com/42866800/163695772-b4ee8789-e989-4fe8-b5e8-ac59547941e9.png) 39 | 40 | 상호 배제는 특정 트랜잭션이 데이터 항목에 대하여 잠금 (Lock) 을 설정하면, 잠금을 설정한 트랜잭션이 해제 (Unlock) 할 때까지 데이터를 독점적으로 사용할 수 있는 기법 41 | -------------------------------------------------------------------------------- /Database/스키마 c60952486d774377974451a653b686ef.md: -------------------------------------------------------------------------------- 1 | # 스키마 2 | 3 | **스키마란?** 4 | 5 | - 데이터베이스의 구조와 제약 조건을 정의한 것 6 | - 데이터의 데이터라고 해서 메타데이터라고도 한다. 7 | 8 | --- 9 | 10 | **스키마의 3계층** 11 | 12 | - 외부 스키마(= 서브 스키마) 13 | - 외부(사용자)에서 바라보는 스키마 14 | - ex) 네이버 데이터베이스는 메일 스키마, 카페 스키마, 블로그 스키마가 있을 것이다. 15 | - 개념 스키마(= 스키마) 16 | - 데이터베이스의 전체적인 논리적 구조 17 | - 개체 간 관계, 제약조건(접근 권한, 보안, 무결성 원칙) 18 | - 개념 스키마= RDB 19 | - 내부 스키마 20 | - 실제 데이터가 저장되는 구조(ex) 저장크기, 저장위치) 21 | - DB의 전체적인 물리적 구조 22 | 23 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled.png) 24 | 25 | --- 26 | 27 | **오라클에서 스키마란?** 28 | 29 | - 오라클에서 스키마란 스키마 오브젝트들의 집합 30 | - 쉽게는 스키마는 서로 연관된 표들을 그룹핑한 일종의 디렉토리이다. 31 | - 디렉토리에 여러 파일을 넣을 수 있는것 처럼 여러 테이블을 담을 수 있다. 32 | 33 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%201.png) 34 | 35 | 36 | **사용자와 스키마** 37 | 38 | - 사용자를 생성하면 사용자에 해당되는 스키마가 생성된다. 39 | - 스키마가 관리하는 것은 사용자이다. 40 | 41 | **Oracle** 42 | 43 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%202.png) 44 | 45 | - 오라클의 경우 인스턴스 아래에 데이터베이스를 한 개만 만들 수 있다는 독자적 제약이 있다. 46 | - 하나의 데이터베이스 밖엔 없기 때문에 인스턴스 바로 아래에 스키마 층이 존재하는 듯한 인상을 받기도 한다. 47 | - 즉, 스키마의 의미는 특정 database의 부분(단일 사용자에게 소유된 테이블이나 객체)를 의미한다. 48 | 49 | **MySQL** 50 | 51 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%203.png) 52 | 53 | - 스키마와 데이터베이스의 의미가 동일하다. 54 | 55 | ```sql 56 | CREATE SCHEMA test DEFAULT CHARACTER SET utf8; 57 | CREATE DATABASE test DEFAULT CHARACTER SET utf8; 58 | ``` 59 | 60 | --- 61 | 62 | **정리** 63 | 64 | - 스키마는 서로 연관된 표들을 그룹핑한 일종의 디렉토리이다. 65 | - 사용자를 생성하면 사용자에 해당되는 스키마가 생성된다. 66 | - 스키마의 본질적인 정의는 그 스키마에 속하는 표들을 정의하는 정보다. -------------------------------------------------------------------------------- /Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 1.png -------------------------------------------------------------------------------- /Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 2.png -------------------------------------------------------------------------------- /Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled 3.png -------------------------------------------------------------------------------- /Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/스키마/스키마 c60952486d774377974451a653b686ef/Untitled.png -------------------------------------------------------------------------------- /Database/스키마/스키마.md: -------------------------------------------------------------------------------- 1 | # 스키마 2 | 3 | **스키마란?** 4 | 5 | - 데이터베이스의 구조와 제약 조건을 정의한 것 6 | - 데이터의 데이터라고 해서 메타데이터라고도 한다. 7 | 8 | --- 9 | 10 | **스키마의 3계층** 11 | 12 | - 외부 스키마(= 서브 스키마) 13 | - 외부(사용자)에서 바라보는 스키마 14 | - ex) 네이버 데이터베이스는 메일 스키마, 카페 스키마, 블로그 스키마가 있을 것이다. 15 | - 개념 스키마(= 스키마) 16 | - 데이터베이스의 전체적인 논리적 구조 17 | - 개체 간 관계, 제약조건(접근 권한, 보안, 무결성 원칙) 18 | - 개념 스키마= RDB 19 | - 내부 스키마 20 | - 실제 데이터가 저장되는 구조(ex) 저장크기, 저장위치) 21 | - DB의 전체적인 물리적 구조 22 | 23 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled.png) 24 | 25 | --- 26 | 27 | **오라클에서 스키마란?** 28 | 29 | - 오라클에서 스키마란 스키마 오브젝트들의 집합 30 | - 쉽게는 스키마는 서로 연관된 표들을 그룹핑한 일종의 디렉토리이다. 31 | - 디렉토리에 여러 파일을 넣을 수 있는것 처럼 여러 테이블을 담을 수 있다. 32 | 33 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%201.png) 34 | 35 | 36 | **사용자와 스키마** 37 | 38 | - 사용자를 생성하면 사용자에 해당되는 스키마가 생성된다. 39 | - 스키마가 관리하는 것은 사용자이다. 40 | 41 | **Oracle** 42 | 43 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%202.png) 44 | 45 | - 오라클의 경우 인스턴스 아래에 데이터베이스를 한 개만 만들 수 있다는 독자적 제약이 있다. 46 | - 하나의 데이터베이스 밖엔 없기 때문에 인스턴스 바로 아래에 스키마 층이 존재하는 듯한 인상을 받기도 한다. 47 | - 즉, 스키마의 의미는 특정 database의 부분(단일 사용자에게 소유된 테이블이나 객체)를 의미한다. 48 | 49 | **MySQL** 50 | 51 | ![Untitled](%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B5%E1%84%86%E1%85%A1%20c60952486d774377974451a653b686ef/Untitled%203.png) 52 | 53 | - 스키마와 데이터베이스의 의미가 동일하다. 54 | 55 | ```sql 56 | CREATE SCHEMA test DEFAULT CHARACTER SET utf8; 57 | CREATE DATABASE test DEFAULT CHARACTER SET utf8; 58 | ``` 59 | 60 | --- 61 | 62 | **정리** 63 | 64 | - 스키마는 서로 연관된 표들을 그룹핑한 일종의 디렉토리이다. 65 | - 사용자를 생성하면 사용자에 해당되는 스키마가 생성된다. 66 | - 스키마의 본질적인 정의는 그 스키마에 속하는 표들을 정의하는 정보다. 67 | 68 | --- 69 | 70 | **참고** 71 | 72 | [https://srzero.tistory.com/entry/Oracle-용어-Instance-VS-Database](https://srzero.tistory.com/entry/Oracle-%EC%9A%A9%EC%96%B4-Instance-VS-Database) 73 | 74 | [https://techvu.dev/131](https://techvu.dev/131) 75 | 76 | [https://www.youtube.com/watch?v=Dz0xUl-PrcI&t=135s](https://www.youtube.com/watch?v=Dz0xUl-PrcI&t=135s) -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled 1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled 1.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled 2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled 2.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled 3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled 3.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled 4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled 4.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled 5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled 5.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화 af409/Untitled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/역정규화/역정규화 af409/Untitled.png -------------------------------------------------------------------------------- /Database/역정규화/역정규화.md: -------------------------------------------------------------------------------- 1 | # 역정규화 2 | 3 | **역정규화란?** 4 | 5 | - 정규화된 데이터베이스에서 **성능을 개선**하기 위해 사용되는 전략 6 | - 정규화의 단점으로 언급되었던 것이 '비용(Cost)'이다. 7 | - **데이터베이스의 비용을 최소화하기 위해 중복을 허용하며 Entity를 다시 통합하거나 분할하여 정규화 과정을 통해 도출된 DB 구조를 재조정하는 과정이다.** 8 | - Join은 비싼 작업이다! 9 | - 오해 금지! 정규화는 성능이 낮다는 것은 아니다. 10 | - 정규화 작업을 거쳐야 역정규화를 고려할 수 있는 것이다! 11 | - 참고! 정규화는 엄격한 규칙을 거쳤지만, 역정규화는 규칙이 아니다. 12 | 13 | --- 14 | 15 | **역정규화: Join 줄이기** 16 | 17 | - 중복은 발생하지만, Join을 줄일 수 있다. 18 | 19 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled.png) 20 | 21 | ```jsx 22 | SELECT 23 | tag.name 24 | FROM topic_tag_relation AS TTR 25 | LEFT JOIN tag 26 | ON TTR.tag_id= tag.id 27 | WHERE topoc_title='MYSQL'; 28 | ``` 29 | 30 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled%201.png) 31 | 32 | ```jsx 33 | SELECT tage_name FROM topic_tag_relation WHERE topic_title= 'MYSQL'; 34 | ``` 35 | 36 | --- 37 | 38 | **역정규화: 계산 작업 줄이기** 39 | 40 | - 파생 컬럼 추가 41 | - GROUP BY 비싼 작업이 될 수 있다(데이터가 1억개라면..?) 42 | 43 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled%202.png) 44 | 45 | ```jsx 46 | SELECT 47 | author_id, COUNT(author_id) 48 | FROM 49 | topic 50 | GROUP BY author_id; 51 | ``` 52 | 53 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled%203.png) 54 | 55 | ```jsx 56 | //topic insert되면 author_count update 57 | 58 | SELECT 59 | id, topic_count 60 | FROM 61 | author; 62 | 63 | ``` 64 | 65 | --- 66 | 67 | **역정규화: 표를 쪼개기** 68 | 69 | - 가정 70 | - description column 용량이 크다. 71 | - description 제외한 columns 조회와 description 포함 columns 조회가 많은 경우 72 | 73 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled%204.png) 74 | 75 | - 테이블 분리 76 | - 테이블을 분리하고, 각각의 PC에 각 테이블 쓰기/읽기 77 | - 장점: description 제외한 조회와 description 포함 조회 동시 처리 가능(= sharding, 분산처리) 78 | - 단점: 어렵다. 유지가 힘들다. 79 | 80 | ![Untitled](%E1%84%8B%E1%85%A7%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%20af409/Untitled%205.png) 81 | 82 | --- 83 | 84 | **참고** 85 | 86 | [https://www.youtube.com/watch?v=f_KCIBfEhNY](https://www.youtube.com/watch?v=f_KCIBfEhNY) 87 | 88 | [https://www.youtube.com/watch?v=67tWzoFr4BY&t=80s](https://www.youtube.com/watch?v=67tWzoFr4BY&t=80s) 89 | 90 | [https://www.youtube.com/watch?v=oIYoS--DtbI&t=275s](https://www.youtube.com/watch?v=oIYoS--DtbI&t=275s) -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 1.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 2.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 3.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 4.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 5.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 6.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 7.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled 8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled 8.png -------------------------------------------------------------------------------- /Database/정규화/정규화 83264/Untitled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Database/정규화/정규화 83264/Untitled.png -------------------------------------------------------------------------------- /Database/정규화/정규화.md: -------------------------------------------------------------------------------- 1 | # 정규화 2 | 3 | **정규화(Normalization)란?** 4 | 5 | 중복을 최소화하게 데이터를 구조화하는 프로세스 6 | 7 | --- 8 | 9 | **1NF** 10 | 11 | - atomic columns(원자성): 모든 속성은 하나의 값만 가져야 한다. 12 | - RDBMS의 조건: 릴레이션은 모든 속성이 원자성 13 | 14 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled.png) 15 | 16 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%201.png) 17 | 18 | --- 19 | 20 | **2NF** 21 | 22 | - No partial dependencies: 부분 종속 X 23 | - 기본키 전체 집합에 종속되어야 한다. 24 | - 기본키 부분 집합에 종속= 부분 종속 25 | - 1NF의 문제점: 데이터 중복(이유: 부분 종속) 26 | - 2NF 정규화 27 | - 부분 종속, 완전 종속 테이블 분리 28 | 29 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%202.png) 30 | 31 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%203.png) 32 | 33 | **부분함수 종속이란?** 34 | 35 | - 릴레이션에서 종속자가 기본키가 아닌 다른 속성에 종속되거나, 36 | - 기본키를 구성하는 여러 속성들의 부분집합 중 일부분에만 종속되어 있음을 말합니다. 37 | 38 | --- 39 | 40 | **3NF** 41 | 42 | - No transitive dependencies: 이행 종속성 X 43 | - 기본키가 아니 모든 속성 간에는 서로 종속할 수 없다. 44 | - 일반속성→ 일반속성 45 | - author_id → author_name, author_profile 46 | - 3NF 정규화 47 | - (기본키→ 일반속성A), (일반속성A→ 일반속성B) 48 | 49 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%204.png) 50 | 51 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%205.png) 52 | 53 | --- 54 | 55 | **BCNF** 56 | 57 | - 모든 결정자가 기본키여야 한다. 58 | - “ 일반속성→ 기본키” 는 BCNF를 만족하지 않는다. 59 | 60 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%206.png) 61 | 62 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%207.png) 63 | 64 | **이상현상 발생** 65 | 66 | - **삽입 이상** : 새로운 교수가 특정 과목을 담당한다는 새로운 정보를 추가할 수 없다. 적어도 한 명 이상의 수강 학생이 필요하다. 67 | - **삭제 이상** : 학번 100이 C234 과목을 취소하면, P2가 C234 과목을 담당한다는 정보도 삭제된다. 68 | - **갱신 이상** : P1의 과목이 변경되면 P1인 행을 모두 찾아 변경시켜주어야 한다 69 | 70 | ![Untitled](%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%80%E1%85%B2%E1%84%92%E1%85%AA%2083264/Untitled%208.png) 71 | 72 | 모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 강한 제3 정규형, 즉 BCNF를 만족하게 된다. 73 | 74 | --- 75 | 76 | **참고** 77 | 78 | [https://www.youtube.com/watch?v=rVxcheAkMSk](https://www.youtube.com/watch?v=rVxcheAkMSk) 79 | 80 | [https://mangkyu.tistory.com/110](https://mangkyu.tistory.com/110) -------------------------------------------------------------------------------- /Database/질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 질문 정리 2 | 3 | ### 데이터베이스 4 | 5 | - 데이터베이스는 사용하는 이유 6 | - 데이터베이스의 성능을 좋아지게 하는 방법? 7 | 8 | - 정규화는 왜 필요한지 설명해 주세요. 9 | - 제 1 정규형은 데이터베이스 정규화에서 사용하는 최소 정규형입니다. 제1 정규형에서 어떤 정규화 과정을 진행하는지 예시를 들어 설명할 수 있나요? 10 | - 제3 정규형을 '추이 종속' or '함수적 이행 종속' 단어를 사용하여 설명할 수 있나요? 11 | - **개인정보**에 관한 데이터베이스에서 수정 이상이 일어나 select로 정확한 정보 파악이 되지 않아 정규화를 진행했습니다. 하지만 이전보다 훨씬 느려졌다고 가정해봅시다. 지원자는 반정규화를 진행할것입니까? 12 | - 정규화 작업 이후, 알맞게 정규화를 했는지 검증하고 싶을땐 어떻게 할까요? 13 | 14 | ### Index 15 | 16 | - Index가 무엇인가요? 17 | - Index의 특징 18 | - Index 테이블 선정 기준 19 | - Index를 구현하는 자료구조에 대해서 말씀해주세요. 20 | - MULTI BLOCK READ가 무엇이며, 인덱스 테이블 선정기준과 연관지어 설명해보세요. 21 | - 인덱스 컬럼 선정 기준에 대해 아는대로 말해보세요. 22 | - 인덱스 설계시, 인덱스와 테이블 데이터의 저장공간이 분리되도록 설계하는 이유에 대해 설명하시오. 23 | - 순차 I/O, 랜덤 I/O 24 | - 쿼리 튜닝의 목적 25 | - B-Tree Index, Hash Index, InnoDB Adaptive Hash Index 26 | - MySQL 에서 B-tree 를 사용하는 이유 27 | - 인덱스 레인지 스캔, 인덱스 풀 스캔 28 | - 클러스터링 인덱스, 논 클러스터링 인덱스 29 | - MySQL 에서 PK 를 인조키로 사용하고 Auto_Increment 를 사용하는 이유 30 | 31 | ### RDBMS, NoSQL 32 | 33 | - RDBMS 설계 목표 34 | - RDBMS의 장단점 35 | 36 | - NoSQL의 장단점 37 | - NoSQL에서 정규화가 필요할까? 38 | 39 | - RDBMS vs NoSQL 40 | - 어떤 상황에서 RDBMS와 NoSQL을 선택하는가? 41 | - RDBMS에서 서버 확장하는 법 42 | 43 | ### 트랜잭션 44 | 45 | - 트랜잭션이란 무엇이며 왜 사용하는가? 46 | 47 | - 트랜잭션은 ACID라는 4가지 특성 48 | - A 계좌에서 B계좌로 일정 금액을 이체하는 작업에 대해 생각해봅시다. 이 때 트랜잭션은 어떻게 정의할 수 있을까요? 49 | - (위 질문과 연결) 방금 말씀해주신 쿼리문에 대해서 Commit 연산과 Rollback 연산이 일어나는 경우는 각각 어떤 상황일까요? 50 | - 트랜잭션의 Commit 연산에 대해서 트랜잭션의 상태를 통해 설명해 주세요. 51 | - 트랜잭션의 Rollback 연산에 대해서 트랜잭션의 상태를 통해 설명해주세요. 52 | - 트랜잭션 격리 수준이란? 왜 필요한가? 53 | - Isolation level의 종류 중 한 가지를 설명해주시고, 이 때 발생할 수 있는 현상 54 | 55 | ### 정규화, 반정규화 56 | 57 | - 이상 현상 58 | - 정규화와 반정규화를 간단히 설명해 주세요. 59 | 60 | ### 그 외 61 | 62 | - 스키마와 테이블의 차이점을 설명해 주세요. 63 | 64 | 65 | 66 | ## 심화 질문 정리 67 | 68 | ### ElasticSearch 69 | 70 | - ElasticSearch는 무엇인가? 71 | - 색인과 역색인이란? 72 | - ElasticSearch와 RDBMS과의 차이점 설명해 주세요. 73 | 74 | - ElasticSearch의 장단점을 설명해 주세요. 75 | 76 | - ElasticSearch의 주요 용어를 설명해 주세요. 77 | 78 | ### DB Lock 79 | 80 | - Lock 의 종류와 단위를 간단히 설명해 주세요. 81 | - 블로킹(Blocking)이란? 82 | - 데드락(Deadlock)이란? 83 | 84 | ### Redis 85 | 86 | - redis는 무엇이며, 언제 사용하는가? 87 | - redis의 특징을 설명해 주세요. 88 | 89 | ### 트랜잭션 90 | 91 | - 트랜잭션 동시성 제어를 설명해 주세요. 92 | - 동시성 제어를 하지 않을 시 발생하는 문제점? 93 | 94 | - 동시성 제어 방법을 간단히 설명해 주세요. 95 | 96 | ### DB 스토리지 97 | 98 | - 클러스터의 개념과 장점 99 | - 클러스터 구현 방법 100 | - 리플리케이션 개념과 사용하는 이유 101 | - 파티셔닝 개념 간단히 설명해 주세요 102 | - 샤딩 개념 간단히 설명해 주세요 103 | 104 | ### 커넥션 풀 (DBCP; Database Polling Service) 105 | 106 | - 커넥션 풀이란? 107 | - 커넥션 풀 동작원리 108 | - 커넥션 풀 사용하는 이유 109 | - DB Connection Pool 관리 방법 110 | 111 | - WAS에서 설정해야 하는 값 중 가장 성능에 많은 영향을 주는 부분에 대해 설명해 주세요. -------------------------------------------------------------------------------- /Network/CORS.md: -------------------------------------------------------------------------------- 1 | # CORS(Cross-Origin Resource Sharing) 2 | 3 | - CORS의 개념과 CORS로 인한 이슈 발생 구분 4 | - CORS 동작 방식 - preflight request 간단히 알면 될 것 같아요. 5 | - 심화 질문 : CORS 이슈 해결 방법 -> 필요한 분만 보시면 될 것 같습니다. 6 | 7 | ## CORS와 SOP 8 | 9 | ### CORS (Cross-Origin Resource Sharing) 10 | 11 | 교차 출처 리소스 공유는 추가 HTTP 헤더를 사용하여**, 한 출처(Origin)에서 실행 중인 웹 애플리케이션이 다른 출처(cross-origin)의 선택한 자원에 접근할 수 있는 권한을 부여**하도록 브라우저에 알려주는 정책입니다. 12 | 13 | (한마디로 서로 다른 도메인 간 자원 공유하는 것을 말합니다.) 14 | 15 | 여기서 16 | 17 | ##### origin (출처) 18 | 19 | origin은 protocol, host, port로 구성 20 | 21 | 예를 들어서, https://github.com:443 주소가 있습니다. 22 | 23 | | protocol | host | port | 24 | | -------- | ---------- | ---- | 25 | | https:// | github.com | 443 | 26 | 27 | **cross- origin** **(다른 출처)** 28 | 29 | https://a.com:80 30 | 31 | https://b.com:80 32 | 33 | protocol, host, port 중 1개라도 다르면 cross-origin입니다. 34 | 35 | ### SOP 36 | 37 | 같은 출처에서만 리소스 공유할 수 있다는 규칙 38 | 39 | ##### same-origin (같은 출처) 40 | 41 | protocol, host, port 동일하면 same-origin이다. 42 | 43 | ### CORS 등장 배경 44 | 45 | CORS, SOP 이런 정책이 존재하는 이유는 46 | 47 | 기본적으로 동일한 출처에 대해 통신하는 것을 규칙으로 합니다.(SOP) 48 | 49 | 그 이유는 서로 다른 출처 간 통신을 제약하지 않으면 보안에 문제가 생길 수 있기 때문입니다. 50 | 51 | 다른 출처의 리소스를 불러와야 하는 경우, 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해줘야 하며, CORS는 안전한 교차 출처 요청 및 데이터 전송을 지원합니다.(CORS는 최소한의 리소스 안전 장치) 52 | 53 | ### CORS와 CORS 이슈를 구분하자! 54 | 55 | CORS는 서로 다른 도메인 간 자원 공유하는 매커니즘이며, **CORS 자체가 에러는 아닙니다.** 56 | 57 | CORS 이슈는 **SOP(동일 출처 정책)에 의거해 다른 출처의 리소스를 사용할 때 경고가 생기고, 이를 해결하기 위해 CORS를 사용하여 접근을 허용하도록 설정**함으로써 해결할 수 있습니다. 58 | 59 | 60 | 61 | ## CORS 동작과 이슈 해결 방법 62 | 63 | ### CORS 동작 원리 64 | 65 | ##### Prefilght request 66 | 67 | 브라우저는 본 요청을 보내기 전에 예비 요청을 먼저 보내고, 요청의 유효성을 검사한다. 68 | 69 | > 실제 요청 보내도 안전하지 판단하기 위해 사전에 보내는 요청 70 | > 71 | > OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인 72 | > 73 | > CORS가 허용된 웹 서버라면 사용 가능한 리소스를 헤더에 담아 응답 74 | 75 | ![image](https://user-images.githubusercontent.com/93963499/158049107-f9eea86f-84dc-49af-9ba8-86f26e35f317.png) 76 | 77 | ### CORS 이슈 해결 방법 78 | 79 | CORS 정책 위반으로 에러 발생했을 때 해결 방법 80 | 81 | ##### Access- Control-Allow-Origin 응답 헤더 셋팅 82 | 83 | - 서버측 응답에서 접근 권한을 주는 헤더를 추가하여 해결 84 | 85 | ~~~javascript 86 | app.use((req, res, next) => { 87 | res.header("Access-Control-Allow-Origin", "*"); // 모든 도메인 88 | res.header("Access-Control-Allow-Origin", "https://example.com"); // 특정 도메인 89 | }); 90 | ~~~ 91 | 92 | 이런식으로 서버(서버 엔진 설정에 추가)에서 Access-Control-Allow-Origin 헤더에 알맞은 값을 셋팅하는 방법이 정석이나 불편합니다. 93 | 94 | 따라서 소소코드 내에서 셋팅하는 방법(Spring, Django 등)이 있습니다. 95 | 96 | ##### 스프링 셋팅 방법 97 | 98 | https://wonit.tistory.com/572 99 | 100 | 101 | 102 | ## QnA 103 | 104 | 105 | 106 | ### Reference 107 | 108 | https://evan-moon.github.io/2020/05/21/about-cors/ 109 | 110 | https://velog.io/@jesop/SOP%EC%99%80-CORS 111 | 112 | https://ingg.dev/cors/ -------------------------------------------------------------------------------- /Network/HTTP와 HTTPS.md: -------------------------------------------------------------------------------- 1 | # HTTP 와 HTTPS 2 | 3 | ## HTTP (Hyper Text Transfer Protocol) 4 | 5 | - html을 전송하는 프로토콜 6 | - 클라이언트와 서버간 데이터를 주고받을 때도 HTTP를 사용한다 7 | - 즉 , 클라이언트와 서버간 데이터를 주고 받기 위한 프로토콜 8 | 9 | ### HTTP 특징 10 | 11 | - HTTP는 TCP/IP 프로토콜 위에서 동작한다 12 | - 클라이언트 서버 구조 13 | - Request Response 구조 14 | - 클라이언트와 서버를 분리한다 15 | - 클라이언트는 서버에 요청을 보내고, 응답을 대기한다 16 | - 서버가 요청에 대한 결과를 만들어서 응답해 준다 17 | - 무상태 프로코콜(Stateless) 비연결성 18 | - 서버가 클라이언트의 상태를 보존하지 않는다 19 | - 클라이언트가 요청할 때 필요한 데이터를 그때그때 담아서 넘겨준다 20 | - 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다 21 | - 응답서버를 쉽게 바꿀수 있다 22 | - 서버는 상태를 보존하지 않는다 23 | - HTTP는 기본적으로 서버와 클라이언트의 연결을 유지하지 않는 모델이다 24 | - 서버 자원을 매우 효율적으로 사용할 수 있다 25 | - TCP/IP 연결을 새로 맺어야 한다 26 | - 자원을 받을 때마다 클라이언트와 서버를 연결하고 자원이 해제 되었을떄 연결을 끊는 것은 비효율 적이다 27 | - HTTP 지속연결 (Persistent Connections)로 문제를 해결한다 28 | - 서버와 클라이언트가 요청을 보내고 응답을 받는 동안에 연결되어 있는 상태를 유지 한다 29 | 30 | ![스크린샷(235)](https://user-images.githubusercontent.com/42866800/156905743-622a2da0-1732-4227-aaef-676473cc14bd.png) 31 | 32 | ### HTTP 메세지 구조 33 | 34 | HTTP 요청 메세지 35 | 36 | ```java 37 | GET /search?q=hollo&hl=ko HTTP/1.1 38 | HOST:www.google.com 39 | ``` 40 | 41 | http 요청 메세지도 본문에 필요한 body 부분을 가질수 있다 42 | 43 | HTTP 응답 메세지 44 | 45 | ```java 46 | HTTP/1.1 200 OK 47 | Content-Type: text/html;charset=UTF-8 48 | Content-Length: 3423 49 | 50 | 51 | ... 52 | 53 | ``` 54 | 55 | HTTP 메시지 구조 56 | 57 | ```java 58 | start-line 시작 라인 59 | 60 | header 헤더 61 | 62 | empty line 공백 라인 (CRLF) 63 | 64 | message body 65 | ``` 66 | 67 | ![스크린샷(237)](https://user-images.githubusercontent.com/42866800/156905756-03d6fdc6-b4d9-4653-8dba-f10bfa39cb51.png) 68 | 69 | 70 | ![HTTP메서드구조](https://user-images.githubusercontent.com/42866800/156905850-9d855a7f-1c49-432c-8608-b2f035c3a690.png) 71 | 72 | 공식 스펙 73 | 74 | ```java 75 | HTTP-message = start-line 76 | * (header-field CRLF) 77 | CRLF 78 | [message-body] 79 | ``` 80 | 81 | ### 시작라인 82 | 83 | 요청 메시지 84 | 85 | - start-line = request-line(요청) / status-line(응답) 86 | - request-line = method SP(공백) request-target SP (요청하는 대상) HTTP-version CRLF(엔터) 87 | 88 | 요청 메세지 - HTTP 메서드 89 | 90 | - 종류: GET , POST , PUT , DELETE 91 | - 서버가 수행해야 할 동작 지정 92 | - `GET` 리소스 조회 93 | - `POST` 요청 내역 처리 94 | 95 | 96 | ```java 97 | GET /search?q=hollo&hl=ko HTTP/1.1 98 | Host: www.google.com 99 | ``` 100 | 101 | 요청 메시지 - 요청 대상 102 | 103 | - absolute-path[?query] (절대경로[?쿼리]) 104 | - 절대경로 = `/` 로 시작하는 경로 105 | 106 | ```java 107 | GET /search?q=hello&hl=ko HTTP/1.1 108 | Host: www.google.com 109 | ``` 110 | 111 | 시작라인 112 | 113 | 요청 메시지 - HTTP 버전 114 | 115 | - HTTP Version 116 | 117 | ```java 118 | GET /search?q=hollo&hl=ko HTTP/1.1 119 | Host: wwww.google.com 120 | ``` 121 | 122 | 시작라인 123 | 124 | 응답 메시지 125 | 126 | - start-line = request-line / status-line 127 | - status-line = HTTP-version SP status-code SP reason-phrase CRLF 128 | 129 | - HTTP 버전 130 | - HTTP 상태 코드: 요청 성공 , 실패를 나타낸다 131 | - 200: 성공 132 | - 400: 클라이언트 요청 오류 133 | - 500: 서버 내부 오류 134 | - 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글 (상태코드에 대한 짧은 설명) 135 | 136 | HTTP 헤더 137 | 138 | - header-field = field-name `:` OWS field-value OWS (OWS: 띄어쓰기 허용) 139 | - field-name은 대소문자 구문 없음 140 | - value는 대소문자를 구분한다 141 | 142 | ```java 143 | GET /search?q=hello&hl=ko HTTP/1.1 144 | Host: www.google.com 145 | ``` 146 | 147 | ```java 148 | HTTP/1.1 200 OK 149 | Content-TYpe: text/html;charset=UTF-8 150 | Content-Length: 3423 151 | 152 | 153 | ... 154 | 155 | ``` 156 | 157 | HTTP 헤더의 용도 158 | 159 | - HTTP 전송에 필요한 모든 부가정보 160 | - 예) 메시지 바디의 내용 , 메시지 바디의 크기 , 압축 , 인증 , 요청 클라이언트(브라우저) 정보 , 서버 애플리케이션 정보 , 캐시 관련 정보 161 | - 즉 , 메시지 바디 빼고 필요한 메타 데이터가 전부 들어있다 162 | 163 | ```java 164 | HTTP/1.1 200 OK 165 | Content-TYpe: text/html;charset=UTF-8 166 | Content-Length: 3423 167 | 168 | 169 | ... 170 | 171 | ``` 172 | 173 | - 표준 헤더가 너무 많음 174 | - 필요시 임의의 헤더도 추가할 수 있다 175 | 176 | HTTP 메시지 바디 177 | 178 | 용도 179 | 180 | - 실제 전송할 데이터가 들어있다 181 | - HTML 문서 , 이미지 , 영상 , JSON 등등 byte로 표현할 수 있는 모든 데이터가 전송 가능하다 182 | 183 | ```java 184 | HTTP/1.1 200 OK 185 | Content-Type: text.html;charset=UTF-8 186 | Content-Length: 3423 187 | 188 | 189 | ... 190 | 191 | ``` 192 | 193 | HTTP 결론 194 | 195 | 단순하고 확장이 가능하다 196 | 197 | ## HTTP2.0 198 | 199 | ### HTTP1.1이 느린 이유 200 | 201 | - 클라이언트와 서버가 하나의 요청과 하나의 응답을 처리하도로 ㄱ되어 있다 202 | - 클라이언트의 Request 순서와 서버의 응답 순서를 동기화 해야 한다 203 | - http/1.1의 헤더에는 많은 메타 정보들이 저장되어 있다 204 | - 사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 도니다 205 | - 이 경우 매 요청시 마다 중복된 헤더 값을 전송하게 되며 206 | - 각 도메인에 설정된 쿠키 정보도 매 요청시 마다 헤더에 포함되어 전송한다 207 | 208 | ### HTTP2.0의 등장 209 | 210 | - HTTP/1.1이 느려서 버전을 개선 211 | 212 | ### HTTP 2.0이 빠른 이유 213 | 214 | 1. Multiplexed Streams (한 커넥션에 여러개의 메세지를 동시에 주고 받을 수 있음) 215 | 2. 요청이 커넥션 상에서 다중화 되므로 HOL(Head Of Line) Blocking 이 발생하지 않음 216 | 3. Stream Prioritization (요청 리소스간 의존관계를 설정) 217 | 4. Header Compression (Header 정보를 HPACK 압축 방식을 이용하여 압축 전송) 218 | 5. Server Push (HTML문서 상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있음) 219 | 6. 프로토콜 협상 메커니즘 - 프로토콜 선택, 예. HTTP / 1.1, HTTP / 2 또는 기타. 220 | 7. HTTP / 1.1과의 높은 수준의 호환성 - 메소드, 상태 코드, URI 및 헤더 필드 221 | 8. 페이지 로딩 속도 향상 222 | 223 | ## HTTPS(Hyper Text Transfer Protocol Secure) 224 | 225 | - HTTP에 데이터 암호화가 추가된 프로토콜 226 | - HTTP와 다르게 443 번 포트를 사용한다 227 | - 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원한다 228 | 229 | ### 대칭키 암호화 와 비대칭키 암호화 230 | 231 | - 대칭키 암호화 232 | - 클라잉언트와 서버가 동일한 키를 사용하여 암호화/복호화 진행 233 | - 키가 노출되면 매우 위험하지만 연산 속도가 빠름 234 | - 비대칭키 암호화 235 | - 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용 236 | - 키가 노출되어도 비교적 안전하지만 연산 속도가 느림 237 | - `공개키` - 모두에게 공개가능한 키 238 | - 공개키 암호화 - 공개키로 암호화를 진행하면 개인키로만 복호화 할 수 있다 239 | - 개인키는 나만 가지고 있으므로 나만 볼 수 있다 240 | - `개인지` - 나만 가지고 알고 있어야 하는 키 241 | - 개인키로 암호화 하면 공개키로만 복호화 할 수 있다 242 | - 공개키는 모두에게 공개되어 있으므로 내가 자인증한 정보임을 알려 신뢰성을 보장할 수 있다 243 | 244 | ![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/56255dd8-8292-4871-8b0c-5182dbbb4c23/Untitled.png) 245 | 246 | 247 | ### HTTPS 연결과정 248 | 249 | ![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/a90f6178-3971-4a63-b460-5643ccebb1a5/Untitled.png) 250 | 251 | 1. 클라이언트가 서버로 최초 연결 시도를 한다 252 | 2. 서버는 공개키를 브라우저에게 응답해 준다 253 | 3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급 받는다 254 | 4. 브라우저는 세션키를 보관하고 서버의 공개키로 세션키를 암호화 하여 서버로 전소앟ㄴ다 255 | 5. 서버는 개인키로 암호화된 세션키를 복호화 하여 세션키를 얻는다 256 | 6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행한다 257 | 258 | ## 결론 259 | 260 | - HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약하다 261 | - HTTPS는 안전하게 데이터를 주고 받을 수 있다 262 | - 하지만 HTTPS를 사용하면 암호화/복호화 과정이 필요하기 때무넹 HTTP 보다 속도가 느리다 263 | - HTTPS는 인증서를 발급하고 유지하기 위해 추가 비용이 발생한다 264 | - 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 사용 265 | - 노출이 되어도 괜찮은 단순한 정보 조회 등을 처리하고 있다면 HTTP를 사용 266 | 267 | 참고 - 268 | 269 | [https://mangkyu.tistory.com/98](https://mangkyu.tistory.com/98) 270 | 271 | [https://blog.wishket.com/http-vs-https-차이-알면-사이트의-레벨이-보인다/](https://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/) 272 | 273 | [https://devlog.oopy.io/bcac7b1c-130f-43b1-ad2e-e2a2db9ab738](https://devlog.oopy.io/bcac7b1c-130f-43b1-ad2e-e2a2db9ab738) 274 | 275 | [https://goldfishhead.tistory.com/26](https://goldfishhead.tistory.com/26) 276 | -------------------------------------------------------------------------------- /Network/LayeredArchitecture/img_webbasic_10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/LayeredArchitecture/img_webbasic_10.png -------------------------------------------------------------------------------- /Network/Load Balancer.md: -------------------------------------------------------------------------------- 1 | # Load Balancer 2 | 3 | - Load Balancing 4 | - Scale out, Scale up 5 | - QnA 6 | 7 | --- 8 | 9 | **로드 밸런서란?** 10 | 11 | 서버에 가해지는 부하(= 로드)를 분산(= 밸런싱) 해주는 장치 또는 기술 12 | 13 | **로드 밸런싱이란?** 14 | 15 | - 한대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 16 | 17 | 각 서버가 최적의 퍼포먼스를 낼 수 있도록 분산 시켜주는 네트워크 기법 18 | 19 | - 트래픽을 분산시켜주는 컴퓨터 네트워크 기법 20 | 21 | **트래픽 대처 방법 2가지** 22 | 23 | - 스케일 업 24 | - 스케일 아웃 25 | 26 | ![image](https://user-images.githubusercontent.com/54395509/156918810-8025e9cd-b4ca-4ef3-84cf-566420b22d7b.png) 27 | 28 | **스케일 업이란?** 29 | 30 | - 서버 자체의 성능을 향상시키는 것 31 | - 서버 CPU/RAM 등 업그레이드 32 | - 단점: 모든 부하가 한 대= 모든 데이터 한 곳에서 처리→ 장애 발생 시 위험 33 | - 데이터 갱신 빈번하게 일어나는 서버에 적합 34 | 35 | **스케일 아웃이란?** 36 | 37 | - 서버를 여러 대 추가 38 | - 여러 대의 서버로 트래픽을 균등하게 분산 즉, 로드 밸런싱이 반드시 필요 39 | - 다중화→ 서버 장애 발생해도 다른 서버에서 대응 가능 40 | - 단점: 모든 서버가 동일 데이터 가지고 있어야 함 41 | - 데이터 변화가 작은 서버에 적합 42 | 43 | **다양한 로드 밸런싱 알고리즘** 44 | 45 | - Round Robin Method 46 | - Weighted Round Robin Method 47 | - IP Hash Method 48 | - Least Connection Method 49 | - Least Response Method 50 | 51 | **Round Robin Method** 52 | 53 | - 클라이언트 요청을 로드밸런싱 대상 서버에 순서대로 할당 54 | - 순서대로 할당→ 각 서버 동일 스펙, 연결(세션) 짧은 환경에 적합 55 | 56 | **Weighted Round Robin Method** 57 | 58 | - 각 서버 가중치 설정, 가중치 높은 서버에 클라이언트 요청 우선 배분 59 | - 언제 사용? 서버 트래픽 처리 능력 상이한 경우 60 | - 예: A 서버 가중치 5, B 가중치 2 61 | - A 서버 5개 B 서버 2개 요청 전달 62 | 63 | **IP Hash Method** 64 | 65 | 클라이언트 IP를 특정 서버로 매핑하여 요청을 처리하는 방식 66 | 67 | **Least Connection Method** 68 | 69 | - 요청 들어온 시점 70 | - 가장 적은 연결 상태 서버에 우선적으로 트래픽 배분 71 | - 언제 사용? 세션이 길어지거나 서버에 분배된 트래픽들이 일정 X 72 | 73 | **Least Response Time Method** 74 | 75 | - 현재 서버 세션 상태와 응답시간 고려하여 트래픽 분배 76 | - 언제 사용? 가장 짧은 응답시간 서버에 우선 로드를 배분하는 방식 77 | 78 | **로드 밸런서 대표** 79 | 80 | - L4 81 | - L7 82 | 83 | **L4** 84 | 85 | - 전송 계층 정보 바탕으로 로드 분산 86 | - 한대의 서버에 각기 다른 포트 번호 부여 87 | - 언제 사용? 다수의 서버 프로그램 운영하는 경우 88 | 89 | ![image](https://user-images.githubusercontent.com/54395509/156918824-96140868-7407-47bb-bf0a-173175c891ce.png) 90 | 91 | **L7** 92 | 93 | - 애플리케이션 계층(HTTP, FTP, SMTP) 정보 바탕으로 로드 분산 94 | - HTTP 헤더, 쿠키 등 사용자 요청을 기준으로 특정 서버에 트래픽 분배 가능 95 | - 쉽게 말해, 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배 가능 96 | - 예: URL 따라 부하 분산, HTTP 헤더 쿠기값 따라 부하 분산 등 97 | 98 | ![image](https://user-images.githubusercontent.com/54395509/156918834-247f5147-5832-4851-b694-3b0bf28ecff1.png) 99 | 100 | --- 101 | 102 | **정리** 103 | 104 | - 로드 밸런싱에 대해 설명 105 | - 서버에 가해지는 부하를 적절하게 분산시켜주는 장치 또는 기술 106 | 107 | - 서버 확장 2가지 방법 설명(scale up, scale out) 108 | - 스케일 업은 서버의 성능 자체를 향상시켜주는 것. 서버 CPU, RAM 등 업그레이드. 109 | - 반면, 스케일 아웃은 서버를 여러 대 증설 110 | 111 | - 로드 밸런싱 알고리즘 대표(라운드 로빈, 최소 연결 방식) 설명 112 | - **라운드 로빈:** 113 | - 클라이언트 요청을 각 로드밸런싱 대상 서버에 순서대로 배분. 114 | - 여러 대 서버의 성능이 비슷하고 세션 유지가 짧은 환경 유리 115 | - **최소 연결 방식:** 116 | - 가장 연결이 적은 서버 우선 트래픽 배분 117 | - 서버 트래픽 일정하지 않고, 세션 길 때 적합 118 | 119 | - L4, L7 로드 밸런싱 설명, 차이 설명 120 | - **L4:** 121 | - 전송 계층 정보로 로드 밸런싱 122 | - 즉, TCP, UDP, IP 정보들을 바탕으로 분산 123 | - 지정된 포트로 로드 밸런싱 가능 124 | - 다수의 서버 프로그램 운영 환경에 유리 125 | - **L7:** 126 | - 어플리케이션 정보로 로드 밸런싱 127 | - HTTP Header, Cookie 등 사용자가 요청한 정보 바탕으로 분산 128 | 129 | --- 130 | 131 | **QnA** 132 | 133 | 1. 데이터 갱신이 빈번할 때, scale up이 유리한 이유는? 134 | 1. 한대의 서버에서 데이터를 관리하기 때문에, 데이터 정합성을 처리할 필요가 없다. 135 | 2. 반면에 scale out은 서버가 여러 대이기 때문에 정합성 처리가 필요하다. 136 | 137 | 2. 서버의 트래픽 처리 성능 개선을 위한 처리 방법은? 138 | 1. 스케일 업 139 | 2. 스케일 아웃 140 | 3. DNS 리다이렉션 141 | 1. DNS 서버가 URL의 호스트명에 대한 응답으로 어떤 IP 주소를 사용할지 결정하는 방법 142 | 2. 재 라우팅의 근거: 라운드 로빈 부하 균형, 회전 지연 최소화, 최단 거리 선정, ..etc -------------------------------------------------------------------------------- /Network/OAuth(Open Authorization).md: -------------------------------------------------------------------------------- 1 | # OAuth(Open Authorization) 2 | 3 | 사용자가 가입된 서비스의 API에 접근하기 위해서는 사용자로부터 권한을 위임 받기 위해서 고안된 기술 4 | 5 | - 서비스 APi 예시: Google peoples api, Gmail API, Google Calendar API, YouTube Analytics API 6 | 7 | ## 일반로그인과 다른점 8 | 9 | - 사용자로그인에 필요한 정보(아이디, 비밀번호)를 직접 저장하고 관리하지 않음 10 | - 아이디, 비밀번호 없이 어떻게? -> 다른서비스(구글, 네이버, 카카오)에서 인증(로그인) 후 다른서비스에서 사용자에 대한 정보를 제공 받음아서 사용자를 특정함 11 | - OAuth는 로그인에 필요한 인증 뿐만아니라 인가도 동시에 들어가 있는 행위 12 | 13 | | 종류 | 내용 | 14 | | -------------------- | ----------------------------------------------------------- | 15 | | 인증(Authentication) | 유저가 누구인지 확인하는 절차, 회원가입하고 로그인 하는 것. | 16 | | 인가(Authorization) | 유저에 대한 권한을 허락하는 것. | 17 | 18 | ## OAuth 버전변화 19 | 20 | ### OAuth1.0 -> OAuth1.0a 21 | 22 | OpenID등 인증만을 위한 기능이 아닌 인증과 인가를 모두 사용할 목적으로 만들어졌으나 보안적인 문제로 OAuth1.0a이 나옴 23 | 24 | - 세션 고정 공격(session fixation attack) 25 | > https://en.wikipedia.org/wiki/Session_fixation 26 | 27 | ### OAuth1.0a -> Oauth2.0 28 | 29 | 앱어플리케이션에서 사용하기 어려운점, 복잡한 절차, 구현의 어려움, 복잡한 절차로 인한 연산의 부담 등을 보완하여 OAuth2.0이 나옴 30 | 31 | - OAuth1.0a Access Token 발급 과정 32 | 33 | 34 | 35 | 1. Request Token의 요청과 발급 36 | 37 | ```http 38 | POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1 39 | Host: example.com 40 | Content-Type: application/x-www-form-urlencoded 41 | Authorization: OAuth realm="Example", 42 | oauth_consumer_key="9djdj82h48djs9d2", 43 | oauth_token="kkk9d7dh3k39sjv7", 44 | oauth_signature_method="HMAC-SHA1", 45 | oauth_timestamp="137131201", 46 | oauth_nonce="7d8f3e4a", 47 | oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3Dc2&a3=2+q" 48 | ``` 49 | 50 | 2. 사용자 인증 페이지 호출 51 | 3. 사용자 로그인 완료 52 | 4. 사용자의 권한 요청 및 수락 53 | 5. Access Token 발급 54 | 6. Access Token을 이용해 서비스 정보 요청 55 | 56 | ### Oauth2.0에서 변경된점 57 | 58 | - 웹 애플리케이션이 아닌 애플리케이션 지원 강화 59 | - HTTPS를 사용하여 HMAC-SHA1와 같은 암호화를 사용하지 않음 60 | - Siganature 단순화 정렬과 URL 인코딩이 필요 없음 61 | oauth인증중 oauth_signature이외의 파라미터를 정렬하고 base64로 인코딩 해야했음 62 | - Access Token의 Life-time(유효기간)을 지정 할 수 있도록 함 63 | 64 | - Authorization Sever: 인증을 관리하고 있는 서버 65 | 66 | ## OAuth2.0 67 | 68 | ### 관련용어 69 | 70 | | 용어 | 역할 | 71 | | -------------------------- | ---------------------------------------------------------------------------------------------- | 72 | | Resource Owner(사용자) | 보호된 리소스에 대한 액세스 권한을 을 가진 소유자, 사람인 경우 최종사용자 | 73 | | Resource Server(구글) | 액세스 토큰을 사용하여 보호된 리소스에 대한 응답하는 서버 | 74 | | Authorization Server(구글) | Client에게 Resource Server에 접근가능하도록 인증, 인가정보를 담은 access token을 발급하는 서버 | 75 | | Client(내사이트) | Resource Owner를 대신하여 권한을 받고 리소스를 요청하는 응용프로그램, 사이트 | 76 | 77 | ### 사용 과정 78 | 79 | ```bash 80 | +--------+ +---------------+ 81 | | |--(A)- Authorization Request ->| Resource | 82 | | | | Owner | 83 | | |<-(B)-- Authorization Grant ---| | 84 | | | +---------------+ 85 | | | 86 | | | +---------------+ 87 | | |--(C)-- Authorization Grant -->| Authorization | 88 | | Client | | Server | 89 | | |<-(D)----- Access Token -------| | 90 | | | +---------------+ 91 | | | 92 | | | +---------------+ 93 | | |--(E)----- Access Token ------>| Resource | 94 | | | | Server | 95 | | |<-(F)--- Protected Resource ---| | 96 | +--------+ +---------------+ 97 | ``` 98 | 99 | ### 등록(Client Registration) 100 | 101 | resource server의 자원을 사용하고자 하는 client가 사전에 승인을 받아두는 것 102 | 103 | #### 필수 항목 104 | 105 | - ClientID: 애플리케이션 식별 106 | - ClientSecret: 비밀번호 107 | - Authorized redirect URIs: 권한 부여중 Authorization code를 전달받을 Client의 주소 108 | - ClientID과 ClientSecret은 Authorization Server에서 발급 하며 Authorized redirect URIs은 client가 입력 109 | 110 | ### 인가(Authorization) 111 | 112 | - 인가를 진행하는 Grant Type에는 4가지가 있으며 가장 기본적인 Authorization Code을 중심으로 설명 113 | - `Resource Owner`가 `Resource Server`의 자원을 `Client`에서 사용하고자 할떄 `Client`를 `Authorization Server`가 인가해주는 과정 114 | 115 | ```bash 116 | +----------+ 117 | | Resource | 118 | | Owner | 119 | | | 120 | +----------+ 121 | ^ 122 | | 123 | (B) 124 | +----|-----+ Client Identifier +---------------+ 125 | | -+----(A)-- & Redirection URI ---->| | 126 | | User- | | Authorization | 127 | | Agent -+----(B)-- User authenticates --->| Server | 128 | | | | | 129 | | -+----(C)-- Authorization Code ---<| | 130 | +-|----|---+ +---------------+ 131 | | | ^ v 132 | (A) (C) | | 133 | | | | | 134 | ^ v | | 135 | +---------+ | | 136 | | |>---(D)-- Authorization Code ---------' | 137 | | Client | & Redirection URI | 138 | | | | 139 | | |<---(E)----- Access Token -------------------' 140 | +---------+ (w/ Optional Refresh Token) 141 | ``` 142 | 143 | 1. Resource Owner가 Client에게 Resource Server의 자원을 요청 144 | 2. Resource Owner가 Client의 Resource Server에 접근을 허용을 위한 주소를 Resource Owner에게 전송 145 | 146 | - Authorization Server는 Resource Owner가 로그인했는 지를 확인하여 로그인 진행 147 | - 로그인 예시 148 | 149 | 150 | 151 | 버튼의 링크 주소: https://authorization.server/?client_id=1&scopre=B,C&redirect_uri=http://client/callback 152 | 153 | 3. `Authorization Server`는 전송된 ClientID, ClientSecret, redirectURIs가 사전에 등록된 것과 일치하는지 확인 154 | 4. `Authorization Server`는 `Resource Owner`에게 `Client`에 부여하고자 하는 자원의 목록을 확인하는 메세지 전송 155 | 5. Authorization code(임시비밀번호) 전송 156 | - `Authorization Server`는 `Resource Owner`에게 header에 "Location: https://client/callback?code=3"를 전송 157 | - Location을 통하여 `Resource Owner`는 `Client`로 이동하면서 code=3이라는 Authorization code를 획득 158 | 6. `Client`는 Authorization code를 사용하여 `Authorization Server`에게 access token발급을 요청 159 | - 요청주소 예시: https://authorization.server/token?grant_type=authorization_code&code=3&redirect_uri=https://client/callback&client_id=1&client_secret=2 160 | 7. `Authorization Server`는 요청의 각 파라미터 확인 및 각 파라미터 내용이 담긴 access token을 생성하여 `Client`에게 전송 161 | 162 | ### 토큰갱신(refresh token) 163 | 164 | `access token`은 만료기간이 존재하여 만료된 이후에는 사용이 불가능 하며 `access token`을 재발급 받아야함 165 | 166 | - `access token`만 발급하는 경우도 있고, `refresh token`까지 발급하는 경우도 있음 167 | 168 | #### refresh token 포함된 프로세스 169 | 170 | ```bash 171 | +--------+ +---------------+ 172 | | |--(A)------- Authorization Grant --------->| | 173 | | | | | 174 | | |<-(B)----------- Access Token -------------| | 175 | | | & Refresh Token | | 176 | | | | | 177 | | | +----------+ | | 178 | | |--(C)---- Access Token ---->| | | | 179 | | | | | | | 180 | | |<-(D)- Protected Resource --| Resource | | Authorization | 181 | | Client | | Server | | Server | 182 | | |--(E)---- Access Token ---->| | | | 183 | | | | | | | 184 | | |<-(F)- Invalid Token Error -| | | | 185 | | | +----------+ | | 186 | | | | | 187 | | |--(G)----------- Refresh Token ----------->| | 188 | | | | | 189 | | |<-(H)----------- Access Token -------------| | 190 | +--------+ & Optional Refresh Token +---------------+ 191 | ``` 192 | 193 | #### refresh token 요청 예시 194 | 195 | ```http 196 | POST /token HTTP/1.1 197 | Host: oauth2.googleapis.com 198 | Content-Type: application/x-www-form-urlencoded 199 | 200 | client_id=your_client_id& 201 | client_secret=your_client_secret& 202 | refresh_token=refresh_token& 203 | grant_type=refresh_token 204 | ``` 205 | 206 | #### refresh token 응답 예시 207 | 208 | ```JSON 209 | { 210 | "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", 211 | "expires_in": 3920, 212 | "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", 213 | "token_type": "Bearer" 214 | } 215 | ``` 216 | 217 | ### 그밖의 인가(Authorization)방법 218 | 219 | - Implicit: Authorization code는 생략하고 바로 access token을 발급받음 220 | - Resource Owner Password Credentials: `Resource Owner`의 아이디, 비밀번호를 `Client`직접 전달 받아 access token을 발급 221 | - Client Credentials: `Resource Owner`가 `Authorization Server`에서 직접 access token을 발급 받고 `Client`에 전달 222 | 223 | #### Implicit 224 | 225 | - JavaScript와 같은언어를 사용하여 브라우저에서 구현되어 SPA와 앱에 적합함 226 | - 클라이업트는 `Authorization Server`의 요청을 수신 가능하도록 상호작용이 가능해야함 227 | - `Client` 인증과정이 없으며 리디렉션 URI에 의존 228 | - `Resource Owner`의 동일한 장치에 있는 다른 응용 프로그램에 노출될 수 있음 229 | - 발급과정 230 | ```bash 231 | +----------+ 232 | | Resource | 233 | | Owner | 234 | | | 235 | +----------+ 236 | ^ 237 | | 238 | (B) 239 | +----|-----+ Client Identifier +---------------+ 240 | | -+----(A)-- & Redirection URI --->| | 241 | | User- | | Authorization | 242 | | Agent -|----(B)-- User authenticates -->| Server | 243 | | | | | 244 | | |<---(C)--- Redirection URI ----<| | 245 | | | with Access Token +---------------+ 246 | | | in Fragment 247 | | | +---------------+ 248 | | |----(D)--- Redirection URI ---->| Web-Hosted | 249 | | | without Fragment | Client | 250 | | | | Resource | 251 | | (F) |<---(E)------- Script ---------<| | 252 | | | +---------------+ 253 | +-|--------+ 254 | | | 255 | (A) (G) Access Token 256 | | | 257 | ^ v 258 | +---------+ 259 | | | 260 | | Client | 261 | | | 262 | +---------+ 263 | ``` 264 | 265 | ### Resource Server의 자원 사용하기 위한 API요청 266 | 267 | #### http를 사용한 요청 268 | 269 | `query parameter`과 `Authorization: Bearer`두가지 방법이 있으며 Bearer를 사용하는것이 표준화되고 안전한 방법으로 권장함 270 | 271 | - access_token을 query string parameter에 담아서 요청 272 | 273 | ```http 274 | GET https://www.googleapis.com/drive/v2/files?access_token= 275 | ``` 276 | 277 | - 헤더의 Authorization: Bearer를 사용하여 access_token을 전송 278 | 279 | ```http 280 | GET /drive/v2/files HTTP/1.1 281 | Host: www.googleapis.com 282 | Authorization: Bearer 283 | https://developers.google.com/calendar/api/v3/reference 284 | ``` 285 | 286 | #### API사용시 유의사항 287 | 288 | - access token을 서버로 전송할 때는 반드시 https(TLS)를 이용. 289 | 290 | 비밀번호인 access token이 노출을 막기위해 291 | 292 | - 구글 같은 몇몇 서버스의 경우 api를 호출하기 전에 api를 활성화. 293 | - Bearer token: oauth를 위하여 고안된 인증표준으로 header, payload, signature 3가지로 구성되어 있어야함 294 | 295 | jwt를 access token으로 사용할수 있으나 bearer 표준을 준수하지 못할시 oauth에서 사용불가 296 | 297 | ## QnA 298 | 299 | ## References 300 | 301 | > https://opentutorials.org/module/3668\ 302 | > 303 | > https://opentutorials.org/course/3405 304 | > 305 | > https://datatracker.ietf.org/doc/html/rfc6749 306 | > 307 | > https://developers.google.com/identity/protocols/oauth2#scenarios 308 | > 309 | > https://datatracker.ietf.org/doc/html/rfc6750 310 | > 311 | > https://gist.github.com/egoing/cac3d6c8481062a7e7de327d3709505f 312 | > 313 | > https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jmjm223&logNo=221483149513 314 | > 315 | > https://velog.io/@aaronddy/%EC%9D%B8%EC%A6%9DAuthentication%EA%B3%BC-%EC%9D%B8%EA%B0%80Authorization 316 | > 317 | > https://oauth.net/core/diagram.png 318 | > 319 | > https://datatracker.ietf.org/doc/html/rfc5849 320 | > 321 | > https://developers.google.com/identity/protocols/oauth2/web-server#httprest_4 322 | > 323 | > https://jsonobject.tistory.com/369 324 | > 325 | > https://cheese10yun.github.io/oauth2/ 326 | -------------------------------------------------------------------------------- /Network/OAuth/login-screen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/OAuth/login-screen.png -------------------------------------------------------------------------------- /Network/REST and RESTFUL.md: -------------------------------------------------------------------------------- 1 | # Rest AND Restful 2 | 3 | ## Rest 4 | 5 | - HTTP 프로토콜로 데이터를 전달하는 아키텍처 6 | - 플랫폼에 제약 없이 데이터를 주고 받을 수 있도록 설계된 Server-Client 아키텍쳐 7 | - 각 플랫폼에 맞게 서버를 일일이 만드는 것이 굉장히 비효율 적이다 8 | - HTTP 메서드를 사용하여 어떤 플랫폼을 사용하든지 클라이언트와 서버 간 동일하게 데이터를 주고 받을 수 있는 아키텍처를 만들었다 9 | - 순수하게 데이터만 전송하겠다 10 | 11 | ## Rest 구성 요소 12 | 13 | ### Rest API 구성 요소 14 | 15 | - 자원(RESOURCE) - URI 16 | - 리소스가 URI를 통해 식별되어야 한다 17 | - 행위(Verb) - HTTP 메서드 18 | - 표현(Representations) 19 | - 표현을 활용하여 리소스 조작 20 | 21 | ## Restful 22 | 23 | `Client - Server 구조` 24 | 25 | - 클라이언트와 서버의 관심사가 명확히 분리되어 있어야 한다 26 | - 서로간 의존성이 줄어든다 27 | - 서버는 비즈니스 로직 처리에 집중하고 클라이언트는 인증 이나 세션 , 로그인 정보등을 관리하는데 집중한다 28 | 29 | `Stateless (무상태성)` 30 | 31 | - 서버가 클라이언트의 상태를 저장하지 않는다 32 | - 서버는 들어오는 요청에 대해서만 처리한다 33 | - 클라이언트가 요청을 할때 HTTP Request 헤더에 저장된 정보에 따라 처리한다 34 | 35 | `자원 식별` 36 | 37 | - REST API에서는 자원을 나타내기 위해 명사 사용 38 | 39 | `HTTP 메서드를 통해 리소스 조작` 40 | 41 | - GET/POST/PUT/PATCH/DELETE를 통하여 서버측에 데이터 전달 42 | - 이러한 기준을 적용하여 API를 설계해야 한다 43 | 44 | `Cacheable (캐시 기능)` 45 | 46 | - HTTP 웹표준을 사용 47 | - HTTP가 가진 캐싱 기능이 적용된다 48 | - Last-Modified 태그나 E-Tag를 사용하여 캐싱 구현 가능 49 | - 캐싱이 가능한 지에 대한 라벨링 필요 50 | - cacheable한 경우 동일한 요청에 대해 응답 데이터를 재사용할 수 있다 51 | 52 | `Self-descriptiveness (자체 표현 구조)` 53 | 54 | - REST API 자체 표현구조를 가짐 55 | - 데이터가 어떤 것을 의미하는가 56 | - 데이터를 어떻게 조작할 수 있는지 와 같은 내용이 포함되어 있어야 한다 57 | - 메시지만 보고 도 쉽게 이해 할 수 있음 58 | 59 | `HTTP용 REST API 처리 결과를 HTTP 상태코드로 변환` 60 | 61 | | 코드 | 상태 | 설명 | 62 | | --- | --- | --- | 63 | | 200 | OK | 요청이 정상적으로 처리됨 | 64 | | 201 | Created | 요청이 정상적으로 처리되고, 신규 리소스가 작성됨 | 65 | | 204 | No Content | 요청이 정상적으로 처리되었지만, 응답 헤더에 담아 반환해줄 정보는 없음 (HTTP Response Body가 존재하지 않는다 , 응답할 데이터가 없다) | 66 | | 400 | Bad Request | 서버가 이해할 수 없는 무효한 요청임 | 67 | | 401 | Unauthorized | 요청된 리소스는 인증이 필요함 | 68 | | 403 | Forbidden | 요청된 리소스는 거부됨 | 69 | | 404 | Not Found | 요청된 리소스는 서버에 존재하지 않음 | 70 | | 500 | Internal Server Error | 서버에서 에러가 발생함 | 71 | 72 | ### REST API 중심 규칙 73 | 74 | - URI는 자원을 표현해야 한다 75 | - 행위에 대한 정보가 들어가면 안된다 76 | 77 | ```java 78 | GET /members/delete/1 (x) 79 | ``` 80 | 81 | -올바른 표현방법 82 | - 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE)로 표현 83 | 84 | ```java 85 | DELETE /members/1 (o) 86 | ``` 87 | 88 | ### HTTP 메서드 역할 89 | 90 | `POST` 91 | 92 | - 새로운 리소스 생성 93 | 94 | `GET` 95 | 96 | - 리소스 조회 97 | - 객체에 대한 상세 정보를 가져옴 98 | 99 | `PUT` 100 | 101 | - 리소스 수정 102 | 103 | `PATCH` 104 | 105 | - 리소스의 일부분 수정 106 | 107 | `DELETE` 108 | 109 | - 리소스 삭제 110 | 111 | ### URI 설계 방법 112 | 113 | - `/` 는 계층 관계를 나타낼때 필요 114 | 115 | ```java 116 | http://restapi.example.com/houses/apartments 117 | http://restapi.example.com/animals/mammals/whales 118 | ``` 119 | 120 | - URI의 마지막 문자로 `/` 가 포함되면 안된다 121 | 122 | ```java 123 | http://restapi.example.com/houses/apartments/ (X) 124 | http://restapi.example.com/houses/apartments (0) 125 | ``` 126 | 127 | - 하이픈(-)은 URI 리소스의 단어를 여러단어로 표현하기 위해 사용한다 128 | - 밑줄(_)은 URI에 사용하지 않는다 129 | - URI 경로에는 소문자가 적합 130 | - 파일 확장자는 URI에 포함시키지 않는다 131 | 132 | ```java 133 | http://restapi.example.com/members/soccer/345/photo.jpg (X) 134 | ``` 135 | 136 | - 리소스간 관계를 표현하는 방법 (연관관계) 137 | 138 | ```java 139 | GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때) 140 | ``` 141 | 142 | ```java 143 | GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때) 144 | ``` 145 | 146 | - 자원을 표현하는 Collection과 Document 147 | - `Collection` - 문서들의 집합 148 | - `Document` - 문서 149 | - 컬럭션은 복수로 사용 가능 150 | 151 | ```java 152 | http:// restapi.example.com/sports/soccer/players/13 153 | ``` 154 | 155 | ## 참고 156 | 157 | [https://meetup.toast.com/posts/92](https://meetup.toast.com/posts/92) 158 | 159 | [https://engkimbs.tistory.com/855](https://engkimbs.tistory.com/855) 160 | 161 | [https://repo.yona.io/doortts/blog/issue/12](https://repo.yona.io/doortts/blog/issue/12) 162 | 163 | [https://jaeseongdev.github.io/development/2021/06/15/REST의-기본-원칙-6가지/](https://jaeseongdev.github.io/development/2021/06/15/REST%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EC%9B%90%EC%B9%99-6%EA%B0%80%EC%A7%80/) 164 | 165 | [https://thesoul214.github.io/server/2019/02/26/Restful-1.html](https://thesoul214.github.io/server/2019/02/26/Restful-1.html) 166 | 167 | [https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html](https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html) 168 | 169 | [https://www.whatap.io/ko/blog/40/](https://www.whatap.io/ko/blog/40/) 170 | 171 | [https://sanghaklee.tistory.com/61](https://sanghaklee.tistory.com/61) 172 | 173 | [https://pronist.dev/146](https://pronist.dev/146) 174 | 175 | [https://beenii.tistory.com/134](https://beenii.tistory.com/134) 176 | -------------------------------------------------------------------------------- /Network/cookie,session,jwt.md: -------------------------------------------------------------------------------- 1 | # 쿠키, 세션, JWT 2 | 3 | - 쿠키, 세션 4 | - 세션 인증 방식, 토큰 인증 방식 5 | - jwt 6 | 7 | ## 쿠키(Cookie)와 세션(Session) 8 | 9 | ### HTTP의 특징과 쿠키와 세션이 등장한 이유 10 | 11 | HTTP는 비연결성과 무상태성 특징으로 요청에 대한 응답을 처리하면 연결을 끊어버립니다. 12 | 13 | 연결 해제 후에 상태 정보를 저장하지 않기 때문에 서버의 자원을 아낄 수 있다는 장점이 있지만, 서버는 클라이언트를 식별할 수 없다는 단점이 있습니다. 14 | 15 | 현재 우리가 이용하는 웹사이트는 로그인 한 번 하면 그 로그인 상태를 유지할 수 있는데, 이런 HTTP의 비연결성과 무상태성을 보완한 기술이 쿠키와 세션이 있기 때문입니다. 16 | 17 | ### 쿠키 18 | 19 | 쿠키란 서버가 클라이언트의 웹 브라우저에 저장하는 데이터입니다. 20 | 21 | > 웹 서버는 쿠키를 이용해서 웹 브라우저에 정보를 전송할 수 있고 웹 서버로부터 쿠키를 전달받은 웹 브라우저는 웹 서버에 요청할 때 쿠키를 함께 전송합니다. 쿠키를 사용하면 서버와 브라우저는 데이터를 공유하고 상태 유지할 수 있습니다. 22 | 23 | ##### set-cookie : 클라이언트가 서버에 요청하면, **서버가 클라이언트로 전달**하는 쿠키 데이터 24 | 25 | ~~~http 26 | MockHttpServletResponse: 27 | Status = 200 28 | Headers = [Set-Cookie:"userName=kevin", "password=abc123"] 29 | ~~~ 30 | 31 | - 서버가 클라이언트의 로그인 요청에 대한 응답을 작성하는 경우, **응답 헤더의 set-cookie**에 담아서 전달 32 | 33 | - 쿠키는 key-value 형태 34 | 35 | ##### cookie : **클라이언트가 서버에서 받은 쿠키 저장하고, 서버로 전달**하는 쿠키 데이터 36 | 37 | ~~~http 38 | MockHttpServletRequest: 39 | HTTP Method = GET 40 | Request URI = /user/my/edit 41 | Headers = [Cookie:"userName=kevin"; "password=abc123"] 42 | ~~~ 43 | 44 | - 클라이언트는 요청을 보낼 때, 저장된 쿠키를 **요청 헤더의 cookie**에 담아서 전달 45 | - 서버는 요청 헤더의 cookie 정보를 통해 클라이언트가 누군지 식별 가능 46 | 47 | #### 쿠키 단점 48 | 49 | - 보안에 취약합니다. 50 | - 요청 시 쿠키의 값을 그대로 보냅니다. 51 | - 네트워크 트래픽을 유발합니다. 52 | - 쿠키는 항상 서버에 전송되기 때문에 최소한의 정보만 담아야 합니다.(세션 id, 인증 토큰 등) 53 | - 서버에 전송하고 싶지 않은 데이터는 쿠키 말고 웹 스토리지를 웹 브라우저에 저장하여 사용합니다. 54 | 55 | #### 쿠키 사용처 56 | 57 | - 사용자 로그인 세션 관리 58 | - 사용자 정보를 모두 쿠키에 담는 것이 아니라 로그인 성공하면, 세션 키를 만들어서 db에 저장해놓고 쿠키에 세션 키를 넣어서 클라이언트에 전달합니다. 59 | - 세션 키는 탈취당하면 안되므로 https를 사용하여 암호화하고, 세션의 생존 기간을 짧게 하는 방법이 있습니다. 60 | - 7일간 다시 보지 않기(쿠키에 체크한 날짜를 기록하여 다시 방문 했을 때의 시간과 시차를 이용하여 계산- 만료일 설정) 61 | - 최근 검색한 상품들을 광고에서 추천 62 | 63 | ### 세션 64 | 65 | 일정 시간 동안 같은 클라이언트로부터 들어오는 요청을 상태로 보고, 그 상태를 유지하는 기술이다. 66 | 67 | 쿠키만을 이용해서 로그인 상태를 유지한다고 가정하면, 아이디나 비밀번호 정보도 쿠키를 통해 전달하는 방법이 있습니다. 이 경우, 보안상 큰 문제가 되므로, 세션을 이용합니다. 68 | 69 | 세션은 비밀번호가 아니라 (클라이언트의 식별자인) 세션 키를 만들어서 쿠키에 저장하고, 세션 키를 클라이언트에 전달합니다. 개인 정보(로그인 상태, 마지막 로그인 시간, 닉네임, 만료기한 등)는 서버에 저장합니다. 70 | 71 | > 중요한 정보는 클라이언트가 아니라 서버에 저장하기 때문에 클라이언트 정보가 노출되지 않음 72 | 73 | #### 특징 74 | 75 | - 세션 아이디는 브라우저 단위로 저장되고 브라우저 종료시 소멸됩니다. (사실 잘 모르겠어요!) 76 | 77 | ## 세션 기반 인증, 토큰 기반 인증 78 | 79 | 기존의 시스템은 서버 기반 인증 방식을 사용했으나, 현재는 토큰 기반 인증 방식을 사용합니다. 80 | 81 | ### 세션(서버) 기반 인증 -> 쿠키&세션 방식 82 | 83 | 세션(서버) 기반 인증 방식은 **서버 측에서 사용자들의 정보를 기억**하는 방식으로, 세션을 통해 기억합니다. 84 | 85 | 사용자가 로그인을 하면, 세션에 사용자 정보를 저장해두고 서비스를 제공할 때 사용하곤 한다. 이러한 서버 기반의 시스템은 다음과 같은 흐름을 갖습니다. 86 | 87 | ![image](https://user-images.githubusercontent.com/93963499/156915969-95be2933-db71-4623-9a01-9a8fc0c1a6e6.png) 88 | 89 | 1. 클라이언트가 로그인 요청 90 | 2. 서버 측에서는 해당 정보를 검증 91 | 3. 정보가 맞다면, 서버측에서 set-cookie를 통해 새로 발행한 세션id를 전달 92 | 4. 클라이언트는 요청 시 마다 서버에 저장된 세션id와 클라이언트에 있는 세션id가 일치한지 확인 93 | 94 | 이러한 인증 방식은 소규모 시스템에서 사용되고 있으나, 웹/앱 애플리케이션이 발달하게 되면서 서버 확장이 어렵다는 문제점이 있습니다. 95 | 96 | #### 문제점 97 | 98 | 1. 서버 부하 99 | 100 | 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 부하가 심합니다. 101 | 102 | 2. 확장성 103 | 104 | 사용자(클라이언트)가 늘어나게 되면, 더 많은 트래픽 처리를 위해 서버를 확장해야 하는데, 105 | 106 | 확장 시 세션을 분산시키는 시스템을 설계해야 하며, 매우 복잡합니다. 107 | 108 | 3. CORS 109 | 110 | 웹 브라우저에서 세션 관리에 사용하는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 **CORS 방식(여러 도메인에 request를 보내는 브라우저)을 사용할 때 쿠키 및 세션 관리가 어렵습니다.** 111 | 112 | > 이부분은 CORS 이해가 필요 113 | 114 | ### 토큰 기반 인증 -> jwt 토큰 인증 방식 115 | 116 | 토큰 기반 인증 방식은 **인증 받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사**를 하는 방식입니다. 117 | 118 | 이러한 시스템에서는 더이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리합니다. 119 | 120 | 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 stateless한 구조를 갖습니다. 121 | 122 | ![image](https://user-images.githubusercontent.com/93963499/156916316-e579264c-f7e7-4946-8534-acb230977109.png) 123 | 124 | 1. 클라이언트가 로그인 요청 125 | 2. 서버 측에서는 해당 정보를 검증 126 | 3. 정보가 정확하다면 서버측에서 클라이언트에게 토큰을 전달 127 | 4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달 128 | 5. 서버는 토큰을 검증하고, 요청에 응답 129 | 130 | #### 장점 131 | 132 | 1. 무상태성 , 확장성 133 | 134 | 토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 무상태성이며, 서버 확장이 용이해집니다. 135 | 136 | 2. 여러 플랫폼 및 도메인 137 | 138 | 서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있습니다. 토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있습니다. 139 | 140 | 최근에는 JWT를 주로 사용합니다. 141 | 142 | ## JWT 143 | 144 | JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 토큰을 의미합니다. 145 | 146 | JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별할 수 있는 방식입니다. 147 | 148 | ### JWT 구조 149 | 150 | ![image](https://user-images.githubusercontent.com/93963499/156916623-3e12be35-67f5-4a9a-96d8-b08794ad13a0.png) 151 | 152 | JWT는 .을 구분자로 나눈 세가지 문자열의 조합 (헤더, 페이로드, 시그너처) 153 | 154 | - header : alg는 암호화할 해싱 알고리즘, typ는 토큰의 타입 지정 155 | 156 | ![image](https://user-images.githubusercontent.com/93963499/156916628-e8fd166e-2c12-4a52-bb44-04ed87043e36.png) 157 | 158 | - payload : 토큰에 담을 정보, key-value 형태로 지정 159 | 160 | ![image](https://user-images.githubusercontent.com/93963499/156916638-045f4dee-f9d4-44d1-b1b8-63733d71d0a6.png) 161 | 162 | - signature : 인코딩된 hader와 payload를 더한 뒤 비밀키로 해싱하여 생성 163 | 164 | header와 payload는 단순 인코딩된 값이기 때문에 제 3자가 복호화 가능하지만, signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 불가능합니다. 165 | 166 | signature는 토큰의 위변조 여부 확인할 때 사용됩니다. 167 | 168 | ![image](https://user-images.githubusercontent.com/93963499/156916652-380ca3d0-3f99-4fb1-a2a6-ae9cbb71ddd5.png) 169 | 170 | #### 인증 과정 171 | 172 | 토큰 기반 인증 흐름과 같습니다. 173 | 174 | #### 장점 175 | 176 | 1. 헤더와 페이로드를 가지고 시그너처를 생성하므로 **데이터 위변조를 막을 수 있습니다**. (토큰 의 위변조 여부) 177 | 2. 인증 정보에 대한 **별도 저장소가 필요 없습니다**. (토큰을 클라이언트에 저장해고 서버에 전달하기 때문) 178 | 3. JWT는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증 서명 등 필요한 모든 정보를 지니고 있습니다. 179 | 4. **서버에서 가장 피해야 할 부분은 데이터베이스 조회인데, jwt 토큰은 db 조회를 하지 않는다. 이 부분에서 성능적 이득이 크다.** 180 | 181 | #### 단점 182 | 183 | 1. 토큰은 한 번 발급되면, **유효기간이 만료될 때 계속 사용되어 탈취 당하게 되면 대처하기 어렵습니다.** 184 | 2. 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 발생할 수 있습니다. 185 | 3. Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없습니다. 186 | 187 | #### 보완 전략 188 | 189 | jwt 사용시 단점 극복을 위해 다양한 전략을 채택할 수 있으나 각각의 장단점이 상이하므로 서비스의 특성을 고려하여 결정 190 | 191 | 1. 토큰 만료시간 짧게 설정 192 | 193 | 토큰이 탈취되더라도 만료되기 때문에 피해를 최소화할 수 있습니다. 하지만 클라이언트는 자주 로그인해야 합니다. 194 | 195 | ## 정리 196 | 197 | - 세션 기반 vs 토큰 기반 198 | 199 | 200 | 201 | - 세션 기반 인증 방식 202 | 203 | 서버측에서 인증 정보 관리하는 방식 204 | 205 | 클라이언트의 요청이 있는 경우, 그 상태를 유지해놓고 사용합니다. 이것은 클라이언트가 증가함에 따라 확장성이 어렵고 성능의 문제가 생길 수 있습니다. 206 | 207 | 208 | - 토큰 기반 인증 방식 209 | 210 | 이런 단점을 극복하기 위해 등장했으며, 클라이언트에게 토큰을 발급하고, 서버측에서 토큰을 검사하여 인증받은 클라이언트인지 확인하는 방식 211 | 212 | 세션 기반(서버 기반) 방식과 달리 인증 상태를 유지하지 않으므로 stateless 한 특징이 있습니다. 213 | 214 | 215 | 216 | - JWT 217 | 218 | - JWT : 데이터 가지고 있는 위조 불가능한 문자열 219 | 220 | - JWT는 **서명이 목적** !! 그 이유는 헤더, 페이로드는 복호화가 쉬우며, 암호화보다는 서명의 목적을 지님 221 | 222 | 223 | 224 | | | 장점 | 단점 | 225 | | ----------- | ------------------------------------------------------------ | ------------------------------------------------- | 226 | | 쿠키 & 세션 | 쿠키만 사용하는 방식보다 보안 향상
서버 쪽에서 세션 통제 가능
네트워크 부하 낮음 | 세션 저장소 사용으로 서버 부하(DB 조회 부하 발생) | 227 | | JWT | 인증을 위한 저장소 필요 없음(DB조회 부하X)
확장성 우수
| 토큰의 길이가 늘어나면 네트워크 부하 발생 | 228 | 229 | ## QnA 230 | 231 | #### 시그니처의 주요 목적이 암호화가 아니라 서명인 이유? 232 | 233 | 시그니처는 인코딩한 데이터(헤더, 페이로드)에 비밀키로 해싱한 것으로 토큰의 위변조를 파악할 때 사용하는 것이다. 헤더, 페이로드는 제3자가 디코딩하면 내용을 알 수 있기 때문에, 암호화의 목적보다는 서명의 목적을 가진다고 볼 수 있다. 234 | 235 | #### 토큰 내용을 클라이언트는 수정할 수 있는가? 236 | 237 | 수정하면 안될 것이라고 생각된다. 238 | 239 | 토큰 기반 인증의 목적은 (서버에서 클라이언트의 정보를 저장하지 않고) 클라이언트의 요청 만으로 인증하기 위함이므로, 토큰의 내용을 클라이언트가 수정하여 전달한다면, 서버측에서 달라진 토큰의 정보를 전달받게 되므로 유효성 검사를 통과할 수 없을 것이다. 240 | 241 | #### 쿠키와 캐시의 차이 242 | 243 | 캐시는 이미지 같은 것을 저장하는 임시 저장소, 캐시는 웹페이지 빠르게 렌더링하는 것을 목적으로 한다. 244 | 245 | 쿠키는 로그인 정보 같은 것을 브라우저 쪽에 저장하는 데이터, 쿠키는 사용자 인증을 도와준다. 246 | 247 | 248 | 249 | ### Reference 250 | 251 | https://mangkyu.tistory.com/55 252 | 253 | https://github.com/NKLCWDT/cs/blob/main/Network/Cookie%2C%20Session%2C%20JWT.md 254 | 255 | https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/ 256 | 257 | https://cjh5414.github.io/cookie-and-session/ 258 | 259 | https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC -------------------------------------------------------------------------------- /Network/proxy.md: -------------------------------------------------------------------------------- 1 | - 프록시와 DMZ 2 | - 프록시에 대해 많이 들어봤지만, 정확히 어떻게 내부에서 동작하는지는 잘 모르는 경우가 있다. 3 | 우선, 간단히 프록시에 대한 개념을 간단히 설명하자면 아래와 같다. 4 | 5 | 중간에 연결점을 놓는 것. 6 | 7 | 그럼 연결점을 왜 놓을까? 8 | 여러 가지 이유가 있지만, 그중 하나를 들자면 9 | 우리는 유튜브를 볼 때, 느린 경우를 확인할 수 있다. 10 | 느린 이유는 간단하다. 캐시를 사용하지 않아서다. 11 | 그러면 그 캐시는 어디에 존재할까? 12 | 바로 프록시 서버에 존재한다. 13 | 14 | 프록시 서버에 캐시를 만듦으로써, 우리는 훨씬 더 빠르게 15 | 데이터를 가져올 수 있다. 16 | 다른 이유도 존재한다. 17 | 바로 보안이다. 18 | 여기서 포워드와 리버스란 개념으로 나뉜다. 19 | 20 | 포워드란 우리가 흔히 알고 있는 그 프록시다. 21 | 주목적으로는 제한적인 사용의 위함이다. 22 | 포트포워딩 개념과 유사하다고 볼 수 있다. 23 | 내부 네트워크를 설정해서 사용하면, 포트번호로 인트라넷에 접근이 가능하다. 24 | 예를 들면, 192.168.1.200이 있고, 192.168.1.201이 있다. 25 | 외부에서 내부에 접근하려면, Public IP와 포트번호로 접근할 수 있다. 26 | 만일, 인사관리 서버가 200이고 회계관리 서버가 201이라면, 27 | 외부에서는 어떻게 접근할 수 있을까? 28 | 여기서 포트번호가 필요하다. 29 | 200은 15000으로 지정하고 201은 15001로 지정하면, 30 | 외부에서는 Public IP와 포트번호로 구분이 가능해진다. 31 | 이렇게 함으로써, 외부 사용자는 약속없이는 특정 사이트에 접근이 불가하다. 32 | 33 | 34 | 반대로, 리버스는 대표적으로 로드 밸런싱에 사용된다. 35 | 사용자가 프록시 서버에 접근하면, 프록시 서버는 처리량에 따라 36 | 분산시켜서 여러 개의 웹서버들 중 알맞은 곳에 요청을 이어준다. 37 | 그래서 대량의 트래픽이 발생할 때, 리버스 프록시 서버가 38 | 적절하게 트래픽을 분산시켜 처리하기 때문에 부하에 걸릴 일이 없다. 39 | 40 | 추가로, 보안에도 용이하다. 41 | 클라이언트는 원서버의 IP를 알 수 없기 때문에 공격을 할 수 없다. 42 | 하지만, CDN 즉, 리버스 프록시 서버가 타겟이 되어 공격 받을 수는 있다. 43 | 44 | 그리고 캐시에 대한 것도 처리한다. 45 | 클라이언트가 프록시 서버에 데이터를 요청한다. 46 | 그럼 요청을 받은 리버스 프록시 서버는 클라이언트가 요청한 데이터가 존재하면, 47 | 캐시이기 때문에 원서버에 경유하지 않고 바로 응답을 내릴 수 있다. 48 | 만일 없다면, 원서버까지 경유를 하게 된다. 49 | 50 | 마지막으로 DMZ는 51 | 간단히 말하자면, 내부 네트워크가 외부 네트워크와 직접적인 통신을 하면 보안에 위배되기 때문에 52 | 중간에 서버를 두어 통신한다. 53 | 그리고 사이에 방화벽이 존재하기 때문에 비교적 더 안전하다고 볼 수 있다. 54 | 55 | 추가로, 웹 서버의 경우에는 외부에서도 접속이 가능하게 만들어야 되기 때문에 56 | 공개를 하지만, 나머지 서버의 경우 Ex) DB서버 는 외부 접속을 차단시켜야 한다. 57 | -------------------------------------------------------------------------------- /Network/websocket.md: -------------------------------------------------------------------------------- 1 | - 웹소켓과 Socket.io 2 | 3 | 웹소켓 연결 과정 4 | HTTP 프로토콜과 마찬가지로, 80번 포트를 사용하여 웹 서버에 연결하고, 5 | Upgrade: WebSocket 헤더 등과 함께 랜덤한 키를 생성해서 웹 서버에 요청한다. 6 | 이 키로 토큰을 발행하고, 브라우저에게 응답한다. 7 | 이로써, WebSocket HandShaking이 이루어진다. 8 | 9 | 그 다음부터는 Protocol Overhead 방식으로 데이터를 주고 받는다. 10 | Protocol Overhead 방식은 80번 포트의 TCP 커넥션 하나만 이용한다. 11 | 그렇기 때문에 방화벽이 있는 환경에서도 무리없이 사용이 가능하다. 12 | 13 | 그리고 스키마도 Http와 당연히 다르다. 14 | 예를 들면, 우리가 흔히 사용하는 http://www.google.com 부분에서 http를 URI스키마 라고 부른다. 15 | 여기서 WebSocket은 http가 아닌, ws를 사용한다. 따라서, 사용하려면, ws://www.google.com 이런 방식으로 선언해야 한다. 16 | 추가로, 암호화된 소켓은 ws -> wss 로 바꾸면 된다. 17 | 18 | 간단한 예제로, 19 | ``` 20 | var socket = new WebSocket(“ws://localhost:16020”); 21 | 22 | socket.onmessage = function (e) { 23 | console.log(e.data); 24 | }; 25 | 26 | socket.onopen = function (e) { 27 | console.log(“open”); 28 | }; 29 | 30 | socket.onclose = function (e) { 31 | console.log(“close”); 32 | }; 33 | 34 | socket.send(“message”); 35 | socket.close(); 36 | ``` 37 | 38 | 위 코드에서 new WebSocket("스키마://호스트:포트") 이 부분은 39 | 웹소켓을 사용을 위해 인스턴스를 생성해서 웹서버와 연결한다. 40 | 그 후에 onmessage(메시지 받았을 때), onopen(소켓 연결), onclose(소켓 연결 종료)등 여러 메소드들은 사용할 수 있다. 41 | 42 | Socket.io는 JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있으며, 43 | WebSocket, FlashSocket(Flash가 설치된 브라우즈에서 사용할 수 있는 통신 방식 = 알 필요 없음), 44 | AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling을 하나의 API로 추상화한다. 45 | 46 | - Polling = Real-Time 웹을 위한 기법 47 | - 브라우저가 일정한 주기마다 서버에 HTTP 요청을 보내는 방식 48 | 단점 : 요청 주기가 짧아지게 되면 서버에 부담이 되며, 반대로 주기가 길면, 실시간 성능이 떨어짐 49 | 50 | - Long Polling = Polling의 단점을 보완한 방식 51 | - 기본적으로 Polling 방식과 유사하지만, 이벤트 처리 기반 즉, 클라이언트가 요청을 보내면, 대기중인 서버는 그 즉시 응답을 해서 실시간성이 매우 좋다. 52 | - Response는 Event가 발생할 때 하므로, Long Polling 이라고 불린다. 하지만, 연결이 많아지면 데이터량이 증가한다. 53 | 54 | 55 | 56 | 57 | 58 | -------------------------------------------------------------------------------- /Network/네트워크 보안(Network Security).md: -------------------------------------------------------------------------------- 1 | # 네트워크 보안(Network Security) 2 | 3 | ## 보안의 3대 요소 4 | 5 | 1. 기밀성 6 | - 인가되지 않은 사용자가 정보의 `내용을 알 수` 없도록 하는 것 7 | - 스니핑(sniffing): 네트워크 패킷을 도청하는 공격 8 | 2. 무결성 9 | - 인가된 자에 의해서만 `변경` 가능한 것 10 | - 스푸핑(spoofing): 네트워크 패킷의 정보를 변조하는 공격 11 | 3. 가용성 12 | - 인가된 자에게 정보에 `사용이` 확실하게 보장되는 것 13 | - Dos(Denial of Service): 공격 대상의 자원을 소비시켜 서비스를 마비시키는 공격 14 | 15 | ## IPSec(Internet Protocol Security) 16 | 17 | - IP계층(네트워크 계층)에서 IP 패킷 암호로 보호함 18 | - 전송계층(Transport)의 개념인 TCP와 UDP를 모두 보호할 수 있음 19 | - IPsec은 VPN에서 사용되고 있다. 20 | 21 | * VPN(Virtual Private Netowrk): 두 개 이상의 물리적 네트워크(또는 장치)가 인터넷과 암호화기술을 사용한 통신 시스템 22 | 23 | 24 | ### IPSec 프로토콜 종류 25 | 26 | #### AH(Authentication Header) 27 | 28 | - IP패킷에 대한 인증을 제공하여 데이터 `무결성` 보장하지만 기밀성은 보장하지 않음 29 | - AH Header부분에서 변경을 감지하도록 되어있음 30 | - AH Transport Mode: 상위계층의 내용(data)의 무결성을 보장 31 | - AH Tunnel Mode: 상위 계층의 내용 + 헤더일부의 무결성을 보장 32 | 33 | 34 | #### ESP(Encapsulation Security Payload) 35 | 36 | - IP패킷에 대한 인증과 암호화를 제공하여 데이터 `무결성, 기밀성` 보장 37 | - AH와 동일하지만 상위계층의 내용(data)을 암호화하여 기밀성 보장 38 | - 데이터가 쉽게 노출되는 AH보다 ESP가 많이 사용됨 39 | 40 | 41 | ## TLS(SSL) 42 | 43 | 네스케이프에 의해서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다. TLS 1.0은 SSL 3.0을 계승한다. 44 | 45 | ### SSL에서 사용하는 암호화 종류 46 | 47 | - 대칭키: 암호를 만드는 행위인 암호화에 사용되는 키와 암호를 푸는 행위인 복호화에 사용되는키가 `서로다름`, 암복호화에 많은 자원이 필요 48 | - 공개키: 암호를 만드는 행위인 암호화에 사용되는 키와 암호를 푸는 행위인 복호화에 사용되는키가 `같음`, 암복호화에 적은 자원이 필요 49 | 50 | ### CA(Certificate authority) 51 | 52 | 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 하는 공인된 민간기업 53 | 54 | - 브라우저는 공인된 CA를 사전에 알고 있음 55 | - 무료 인증서 제공기관: https://letsencrypt.org/ko/ 56 | 57 | ### SSL 디지털 인증서 58 | 59 | 클라이언트와 서버간 통신을 제3자가 `보증`해주는 전자화된 문서. 서버는 CA를 통해서 구입하여 제공함. 60 | 61 | - 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다. 62 | - SSL 통신에 사용할 공개키를 클라이언트에게 제공한다. 63 | 64 | #### SSL 인증서의 내용 65 | 66 | - 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등) 67 | - 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법) 68 | 69 | ### SSL의 동작방법 70 | 71 | 1. 클라이언트 측에서 생성한 랜덤 데이터, 사용가능 암호화 방법 전송 72 | 2. 서버 측에서 생성한 랜던 데이터, 암호화 방법 선택, 인증서 전송 73 | 3. 클라이언트 인증서 CA공개키로 복호화하여 서버에서 보낸 공개키 획득 74 | 4. 두개의 랜덤 데이터로 'pre master secret' 생성하여 서버 공개키로 암호화하여 서버에 전송 75 | 5. 서버는 개인키로 'pre master secret'을 복호화하여 보유함 76 | 6. 서버와 클라이언트 모두 'session key'를 생성 보유함 77 | `pre master secret` -> `master secret` -> `session key` 78 | 7. 세션이 유지될 동안 'session key' 사용 후 세선 종료와 같이 폐기됨 79 | 서버와 클라이언트는 복호화된 이란 대칭키를 보유하게 됨 80 | 81 | ## 방화벽 82 | 83 | 허가된 사용자 외에는 접근 자체를 차단하며 특정 사용자만 단계적으로 허용하는 방식 84 | 85 | ### firewall(centos) 86 | 87 | #### zone 88 | 89 | 사용자가 요구하는 정책 허용, 특정 허용, 거부, 특정 거부 등등에 맞게 그룹으로 관리됨 90 | 91 | - Public Zone : Firewalld의 기본 영역 이며, 서비스를 제공하는 포트로 연결을 허용할 경우 사용됩니다. 92 | - Drop Zone : 들어오는(Inbound) 모든 패킷을 버리고 응답을 하지 않습니다. 93 | - Block Zone : 들어오는(Inbound) 모든 패킷을 거부하지만 응답 메세지를 전달합니다. 94 | - External Zone : 라우터를 사용하여 내부 연결에 사용됩니다. 95 | - DMZ Zone : 내부 네트워크는 제한적으로 설정하고 외부 네트워크와 접근할 경우 사용됩니다. 96 | - Work Zone : 같은 네트워크 망에 있을지라도 신뢰하는 네트워크에만 허용할 경우 사용됩니다. 97 | - Trusted Zone : 모든 네트워크를 허용할 경우 사용됩니다. 98 | - Internal Zone : 내부 네트워크에 선택한 연결만 허용할 경우 사용됩니다. 99 | 100 | #### service 101 | 102 | 방화벽 정책 변경시 용이하도록 많이 사용하는 서비스를 사전에 정의해 놓고 있음 103 | 104 | ```bash 105 | #존 목록 확인 106 | sudo firewall-cmd --get-zones 107 | sudo firewall-cmd --list-all-zones 108 | 109 | #활성화된 존 확인 110 | sudo firewall-cmd --get-active-zone 111 | 112 | #서비스 목록 확인 113 | sudo firewall-cmd --get-services 114 | 115 | #존에 서비스, 포트, 아이피 추가 116 | sudo firewall-cmd --parmanent --zone=<존 이름> --add-service=<서비스명> 117 | sudo firewall-cmd --parmanent --zone=public --add-service=http 118 | sudo firewall-cmd --parmanent --zone=<존 이름> --add-port=<포트번호> 119 | sudo firewall-cmd --parmanent --zone=public --add-port=90/tcp 120 | sudo firewall-cmd --parmanent --zone=public --add-port=80-90/tcp 121 | sudo firewall-cmd --parmanent --zone=public --add-source=<아이피번호> 122 | sudo firewall-cmd --parmanent --add-source=192.168.100.1 123 | sudo firewall-cmd --parmanent --add-source=192.168.100.1/24 124 | ``` 125 | 126 | ### iptables 127 | 128 | 네트워크 패킷의 헤더의 정보를 기반으로 허용(ACCEPT)과 차단(DROP)을 지정 할 수 있다. 129 | 130 | ### chain 131 | 132 | 논리적으로 3개의 chain이 있으며 새로운 chain 설정도 가능함 133 | 134 | - Chain INPUT : 서버로 들어오는 기본 정책 135 | - Chain FORWARD : 서버에서 forwarding 기본 정책 / 서버가 목저깆가 아닌 통과해가는 패킷을 대상으로 함 136 | - Chain OUTPUT : 서버에서 나가는 기본 정책 137 | 138 | ### packet filtering rule 139 | 140 | 들어오는 패킷을 순서대로 정의된 규칙에의해 점검하고 처음 일치되는 규칙의 정책을 적용 141 | 142 | - 규칙생성 명령어: iptables -A INPUT -s [발신지] --sport [발신지 포트] -d [목적지] --dport [목적지 포트] -j [정책] 143 | 144 | ```bash 145 | # iptable 규칙 목록 확인 146 | iptables --list 또는 iptables -L 147 | 148 | target prot opt source destination 149 | cali-INPUT all -- anywhere anywhere 150 | 151 | # 특정 기본정책을 허용하는 명령어 152 | iptables -P INPUT ACCEPT 153 | 154 | # 규칙 추가 예시 155 | # 192.168.100.100로부터 왔으며, icmp네트워크카드로 들어 왔으며, 해당패킷은 차단함 156 | iptables -A INPUT -s 192.168.100.100 -p icmp -j DROP 157 | 158 | #위에 생성된 규칙 삭제 159 | iptables -D INPUT 1 160 | iptables -D INPUT -s 192.168.100.100 -p icmp -j DROP 161 | ``` 162 | 163 | ## 웹 방확벽(Web Application Firewall, WAF) 164 | 165 | SQL Injection, XSS, Directory Traversal등 웹공격을 탐지/차단하는 시스템 166 | 167 | ### IDS(Intrusion Detectikon System) 168 | 169 | - 침입 패턴 데이터베이스와 지능형 엔진을 사용 170 | - 네트워크 실시간으로 모니터링 171 | - 불법적인 침입을 탐지 172 | 173 | ### IPS(Intrusion Prevention System) 174 | 175 | - IDS의 기능 + 차단 기능 176 | - 침임 탐지 후 자동으로 대응 및 차단 177 | - 방화벽과 함께 사용하면 효율적 178 | 179 | ## 보안을 위협하는 다양한 공격 기법 180 | 181 | ### SQL Injection 182 | 183 | 이용자의 입력값이 SQL 구문의 일부로 사용될 경우, 해커에 의해 조작된 SQL 구문이 데이터베이스에 그대로 전달되어 비정상적인 DB 명령을 실행시키는 공격 기법이다. 184 | 185 | - 클라이언트와 서버가 입력값에 대한 검증이 제대로 이루어 지지 못하는 경우에 발생함 186 | 187 | ### 쿼리 조건 무력화(Where 구문 우회) 188 | 189 | #### 인증우회 190 | 191 | 로그인 폼(Form)을 대상으로 공격을 수행한다. 정상적인 계정 정보 없이도 로그인을 우회하여 인증을 획득 192 | 193 | - 로그인 ID로 입력 값 `1234'; DELETE * USER FROM ID = '1'; --` 194 | - WHERE 싱글쿼터로 닫고 ;로 쿼리문 종료후 새로운 쿼리문 입력 195 | - 최초생성한 계정이 관리자 계정일 떄 관리자계정 삭제됨 196 | 197 | ```sql 198 | SELECT * FROM USER WHERE ID = 'abc' AND PASSWORD = '1234'; 199 | SELECT * FROM USER WHERE ID = '1234'; DELETE * USER FROM ID = '1'; --' AND PASSWORD = '1234'; 200 | ``` 201 | 202 | #### 고의적 에러 유발후 정보 획득 203 | 204 | 시스템에서 발생하는 에러 메시지를 이용해 공격하는 방법으로 에러를 통하여 데이터베이스 구조를 유추하여 해킹에 활용 205 | 206 | - 로그인 ID로 입력 값 `test' UNION SELECT 1 --` 207 | - 에러메세지 표시: "UNION, INTERSECT 또는 EXCEPT 연산자를 사용하여 결합된 모든 쿼리의 대상 목록에는 동일한 개수의 식이 있어야 합니다." 208 | 209 | ```sql 210 | Select * From Users Where UserID = 'test' UNION SELECT 1 -- And Password='1234'; 211 | ``` 212 | 213 | - 위 에러메세지를 토대로 대상 목록을 늘림 214 | - 로그인 ID로 입력 값 `test' UNION SELECT 1,1,1,1 --` 215 | - 에러메세지 표시안됨 => Users 테이블의 컬럼이 4개인것을 알 수 있음 216 | 217 | ```sql 218 | Select * From Users Where UserID = 'test' UNION SELECT 1,1,1,1 -- And Password='1234'; 219 | ``` 220 | 221 | - 로그인 ID로 입력 값 `test' UNION SELECT UserID, CardNo, 1, 1 FROM PaymentLog -- And Password='아무거나'-` 222 | - 결제로그가 담긴 PaymentLog 테이블 정보를 획득 223 | 224 | ```sql 225 | Select * From Users Where UserID = 'test' UNION SELECT UserID, CardNo, 1, 1 FROM PaymentLog -- And Password='아무거나' 226 | ``` 227 | 228 | ### Blind SQL 인젝션 229 | 230 | 쿼리 결과의 참/거짓으로부터 DB값을 유출해 내는 기법 231 | 232 | #### Boolean-based Blind 공격 233 | 234 | AND 조건에 논리식을 대입하여 참/거짓 여부를 알아내는 방식 235 | 236 | - 게시판 제목검색 입력값 `hello' AND 1=1--`, `hello' AND 1=2--` 237 | - `hello' AND 1=1--` -> 검색됨 -> hello검색어를 참으로 간주 238 | - `hello' AND 1=2--` -> 검색안됨 -> hello검색어를 참으로 간주 239 | 240 | #### Time-based Blind 공격 241 | 242 | 시간을 지연시키는 쿼리를 주입하여 응답 시간의 차이로 참/거짓 여부를 판별 243 | 244 | - 제목검색: `hello' AND sleep(5) --` 245 | 246 | ```sql 247 | SELECT * FROM TB_Boards WHERE Title = 'hello' AND sleep(5) -- 248 | ``` 249 | 250 | - 응답이 5초간 지연됨 -> 참(true) --> hello 검색어가 존재함 251 | - 응답이 즉시 이뤄짐 -> 거짓(false) --> hello 검색어가 존재하지 않음 252 | 253 | ### Command Injection 254 | 255 | 웹 애플리케이션에서 시스템 명령을 사용할 때, 세미콜론 혹은 &, && 를 사용하여 하나의 Command를 Injection 하여 두 개의 명령어가 실행되게 하는 공격 256 | 257 | 258 | 259 | - 입력값: `1 && cat /etc/passwd` 260 | - 리눅스 계정아이디 정보 획득 261 | 262 | ### XSS 263 | 264 | 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입하여 다른 웹사이트와 정보를 교환 265 | 266 | #### Stored XSS 267 | 268 | 1. 웹사이트의 게시물에 악성 스크립트 삽입 269 | 2. 사용자가 게시물 조회시 스크립트가 실행됨 270 | 3. 스크립트 내용에 따라서 쿠키나 세션 토큰 등이 정보 유출 271 | 272 | 273 | #### Reflected XSS 274 | 275 | 사용자에게 입력 받은 검색어를 그대로 보여주는 곳이나 사용자가 입력한 값을 에러 메세지에 포함하여 보여주는 곳에서 발생 276 | 277 | 1. 악성 스크립트가 포함된 URL을 사용자에게 노출 278 | 2. 악성 스크립트가 서버에 전송되고 그대로 사용자가 받음 279 | 3. 사용자는 악성스크립트가 포함되어 전송된 서버응답을 실행함 280 | 281 | 282 | ### CSRF 283 | 284 | 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청 285 | 286 | - 위조 요청을 전송하는 서비스에 사용자가 로그인 상태 287 | - 사용자가 해커가 만든 주소로 요청 288 | 289 | 1. 회사내에서 회사권한을 가진 계정으로 로그인 한다 => 쿠키발급받음 290 | 2. 해커가 생성한 사이트에 접속 또는, 아래 코드가 들어간 이메일을 조회. 291 | 292 | ```xml 293 | #get요청 예시: 이미지 사이즈가 0으로 사용자 인지하지 못함 294 | 295 | 296 | #post요청 예시 297 | #자동으로 form태그가 제출됨 298 | 299 | 300 | #type hidden으로 사용자가 인식하지 못함 301 |
302 | 303 | 304 | 305 |
306 | ``` 307 | 308 | 3. id와 pw가 해커가 설정한 값으로 변경됨 309 | 310 | ## References 311 | 312 | > https://youtu.be/ww8Rz-Se3os > https://handreamnet.tistory.com/331 313 | > 314 | > https://reakwon.tistory.com/108 315 | > 316 | > https://www.itworld.co.kr/news/220474 317 | > 318 | > https://velog.io/@choco_sister/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-IPSec-Internet-Protocol-Security 319 | > 320 | > https://musketpopeye.xyz/2021/02/04/ipsec-vpn-1/ 321 | > 322 | > https://aws-hyoh.tistory.com/163 323 | > 324 | > https://opentutorials.org/course/228/4894 325 | > 326 | > https://forum.huawei.com/enterprise/en/using-ipsec-vpn-to-implement-secure-interconnection-between-lans/thread/745727-867 327 | > 328 | > https://dany-it.tistory.com/20 329 | > 330 | > https://server-talk.tistory.com/334 331 | > 332 | > https://dejavuhyo.github.io/posts/contos-firewall/ 333 | > 334 | > https://linuxstory1.tistory.com/entry/iptables-%EA%B8%B0%EB%B3%B8-%EB%AA%85%EB%A0%B9%EC%96%B4-%EB%B0%8F-%EC%98%B5%EC%85%98-%EB%AA%85%EB%A0%B9%EC%96%B4 335 | > 336 | > https://itragdoll.tistory.com/2 337 | > 338 | > https://noirstar.tistory.com/264 339 | > 340 | > https://m.mkexdev.net/427 341 | > 342 | > https://velog.io/@yanghl98/Database-SQL-Injection 343 | > 344 | > https://noirstar.tistory.com/267?category=779215 345 | > 346 | > https://tecoble.techcourse.co.kr/post/2021-04-26-cross-site-scripting/ 347 | > 348 | > https://lucete1230-cyberpolice.tistory.com/23 349 | > 350 | > https://4rgos.tistory.com/1 351 | > 352 | > https://sj602.github.io/2018/07/14/what-is-CSRF/ 353 | > 354 | > https://zzang9ha.tistory.com/341 355 | -------------------------------------------------------------------------------- /Network/네트워크 시스템의 Layered Architecture.md: -------------------------------------------------------------------------------- 1 | # 네트워크 시스템의 Layered Architecture 2 | 3 | ## 웹의 동작 방식 4 | 5 | ![img_webbasic_10](LayeredArchitecture/img_webbasic_10.png) 6 | 7 | ①② 사용자가 웹 브라우저를 통해 찾고 싶은 웹 페이지의 URL 주소를 입력함. 8 | 9 | ③ 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색함. 10 | 11 | ④ DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달함. 12 | 13 | ⑤⑥ 웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성함. 14 | 15 | 이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송됨. 16 | 17 | ⑦ 이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환됨. 18 | 19 | ⑧ 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색함. 20 | 21 | ⑨⑩ 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성함. 22 | 23 | 이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송됨. 24 | 25 | ⑪ 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환됨. 26 | 27 | ⑫ 변환된 웹 페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 됨. 28 | 29 | ## TCP/IP 5 Layer 30 | 31 | `TCP/IP 5 Layer` 는 네트워크의 기본 구조를 5개의 계층으로 나눠서 표준화한 것이다. 32 | 33 | - 1계층 - 물리 : 물리적인 연결과 전기 신호 변환/제어를 담당 34 | - 2계층 - 데이터링크 : 네트워크 기기 간 데이터 전송 및 물리 주소를 결정 35 | - 3계층 - 네트워크 : 다른 네트워크와 통신하기 위한 경로를 설정하고 논리 주소를 결정 36 | - 4계층 - 전송 : 네트워크 계층에서 보내온 데이터 정렬, 오류 정정 등을 수행하고 신뢰할 수 있는 통신을 확보 37 | - 5계층 - 응용 : 이메일, 웹 브라우저, 파일 전송 등 통신하기 위해 필요한 서비스 제공 38 | 39 | ## OSI 7 Layer 40 | 41 | `OSI 7 Layer` 는 국제화 표준 기구인 ISO에서 개발한 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 개방형 시스템 상호 연결 모델 42 | 43 | - 1계층 - 물리 : 실제 장치들을 연결하기 위해 필요한 전기적,물리적 세부 사항들을 정의하는 계층 44 | - 2계층 - 데이터링크 : 링크의 설정과 유지 및 종료를 담당하며 노드 간의 오류 제어, 흐름 제어, 회선 제어 기능을 수행하는 계층 45 | - 3계층 - 네트워크 : 다양한 길이의 패킷을 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질을 위한 소단을 제공하는 계층 46 | - 4계층 - 전송 : 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해주면서 종단 간의 사용자들에게 신뢰성 있는 데이터를 전달하는 계층 47 | - 5계층 - 세션 : 응용 프로그램 간의 대화를 유지하기 위한 구조를 제공하고, 이를 처리하기 위해 프로세스들의 논리적인 연결을 담당하는 계층 48 | - 6계층 - 표현 : 애플리케이션이 다루는 정보를 통신에 알맞은 형태로 만들거나, 하위 계층에서 온 데이터를 사용자가 이해할 수 있는 형태로 만드는 역할을 담당하는 계층 49 | - 7계층 - 응용 : 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는 역할을 담당하는 계층 50 | 51 | ## TCP, UDP, IP, PORT 52 | 53 | ### TCP 54 | 55 | 전송 제어 프로토콜(Transmission Control Protocol) 56 | 57 | - 연결지향 - TCP 3 way handshake (가상 연결) 58 | 1. SYN(접속 요청) 59 | 2. SYN + ACK(요청 수락) 60 | 3. ACK 61 | - 데이터 전달 보증 62 | 1. 데이터 전송 63 | 2. 데이터 잘 받았음 64 | - 순서 보장 65 | 1. 패킷1,패킷2,패킷3 순서로 전송 66 | 2. 패킷1,패킷3,패킷2 순서로 도착 67 | 3. 패킷2부터 다시보내! 68 | - 신뢰할 수 있는 프로토콜 69 | - 현재는 대부분 TCP 사용 70 | 71 | 이런 것들이 가능한 이유는 `TCP 세그먼트에` 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등의 정보들이 담겨있기 때문이다 그렇기 때문에 `TCP` 를 신뢰할 수 있는 프로토콜이라고 부른다 72 | 73 | ### UDP 74 | 75 | 사용자 데이터그램 프로토콜(User Datagram Protocol) 76 | 77 | - 하얀 도화지에 비유(기능이 거의 없음) 78 | - 연결지향 - TCP 3 way handshake X 79 | - 데이터 전달 보증 X 80 | - 순서 보장 X 81 | - 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름 82 | - 정리 83 | - IP와 거의 같다. + PORT + 체크섬 정도만 추가 84 | - 애플리케이션에서 추가 작업 필요 85 | 86 | ### IP 87 | 88 | - 지정한 IP 주소(IP Address)에 데이터 전달 89 | - 패킷(Packet)이라는 통신 단위로 데이터 전달 90 | 91 | #### IP 프로토콜의 한계 92 | 93 | - 비연결성 94 | - 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 95 | - 비신뢰성 96 | - 중간에 패킷이 사라지면? 97 | - 패킷이 순서대로 안오면? 98 | - 프로그램구분 99 | - 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면? 100 | 101 | `IP 프로토콜` 만으로는 문제점들을 해결할 수 없다 그래서 이런 문제점들을 해결해주는게 `TCP 프로토콜` 이다 102 | 103 | ### PORT 104 | 105 | 같은 IP 내에서 프로세스 구분 106 | 107 | `IP가 아파트라면 PORT는 몇동 몇호이다` 라고 생각하면 편하다 108 | 109 | - 0 ~ 65535 110 | - 할당 가능 111 | - 0 ~ 1023 112 | - 잘 알려진 포트, 사용하지 않는 것이 좋음 113 | - FTP 114 | - 20,21 115 | - TELNET 116 | - 23 117 | - HTTP 118 | - 80 119 | - HTTPS 120 | - 443 -------------------------------------------------------------------------------- /Network/네트워크보안/Command-Injection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/Command-Injection.png -------------------------------------------------------------------------------- /Network/네트워크보안/ipsec-ah.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/ipsec-ah.png -------------------------------------------------------------------------------- /Network/네트워크보안/ipsec-esp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/ipsec-esp.png -------------------------------------------------------------------------------- /Network/네트워크보안/ipsec-vpn.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/ipsec-vpn.png -------------------------------------------------------------------------------- /Network/네트워크보안/xss-reflected.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/xss-reflected.png -------------------------------------------------------------------------------- /Network/네트워크보안/xss-stored.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/Network/네트워크보안/xss-stored.png -------------------------------------------------------------------------------- /Network/질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 내용 질문 2 | 3 | ### **OSI 7 layer** 4 | 5 | - 프로토콜 6 | - osi 7 layer이란? 7 | - tcp/ip layer이란? 8 | - osi 7 layer와 tcp/ip layer에서 계층화하는 이유 9 | - OSI 7계층을 택하면 좋은점 10 | - 많은 직장인들이 아웃룩을 이용하여 회사 메일을 관리하고 있습니다. 아웃룩과 관련된 계층과 프로토콜을 말해 주세요. 11 | - 이전에 저희 회사의 서비스를 제공받는 모든 고객의 pc에서 서비스 중단 이 일어났습니다. OSI 7계층의 관점으로 몇번째 계층의 문제임을 예상할 수 있을까요? 12 | - 서버에 문제가 생겼는데, Ping Test 시 문제는 없었습니다. 그렇다면 어느 계층에서 문제가 있다는 것을 유추할 수 있나요? 13 | - 유튜브와 같은 스트리밍 서비스를 제작해보려합니다. 이때 어떤 프로토콜로 구현할 것인지 관련 계층과 연관지어 말해 주세요. 14 | - 웹 서버 소프트웨어(Apache, Nginx)는 OSI 7계층 중 어디서 작동하는지 설명해 보세요. 15 | - 웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디서 작동하는지 설명해 보세요. 16 | 17 | ### **TCP, UDP** 18 | 19 | - TCP의 특성에 대해서 말씀해 주세요. 20 | - UDP의 특성에 대해서 말씀해 주세요. 21 | - 3-Handshaking과 4-Handshaking의 과정을 설명해 주세요. 22 | - 3-way handshaking 과정에서 클라이언트가 서버가 보낸 ACK+SYN을 받지 못하면? 23 | - 4-way handshaking 과정에서 클라이언트가 마지막에 ACK를 굳이 보내는 이유? 24 | - 만약 Server에서 FIN 세그먼트를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까? 25 | - TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유? 26 | - 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유? 27 | 28 | ### **웹 통신 흐름** 29 | 30 | - 인터넷에 www.naver.com을 쳤을 때, 브라우저의 렌더링 과정에 대해 설명해 주세요. 31 | - 브라우저가 전송한 request 메시지를 웹 서버까지 전송하고 그 응답을 받기까지의 과정을 설명해 주세요. 32 | - 프로토콜 스택은 어떤 역할을 하나요? 33 | - 프록시 서버는 어떤 기능을 하나요? 34 | - 그럼 두 번 이상 요청된 내용은 프록시 서버 캐시로부터 다운로드받게 될텐데 페이지의 값이 바뀐다면 어떻게 처리할 수 있나요? 35 | - 서로 다른 프로토콜을 사용하는 두 네트워크를 연결하기 위한 방법은 무엇이 있을까요? 36 | - CORS 문제가 무엇이고 경험해본적 있는가요? 37 | 38 | ### **HTTP와 HTTPS** 39 | 40 | - HTTP와 HTTPS를 설명해 주세요. 41 | - HTTP 특징을 설명을 해주세요. 42 | - HTTP의 단점을 설명해 주세요. 43 | - HTTP1.1와 HTTP2.0 차이점은 무엇인가요? 44 | - HTTP는 왜 비연결성인가? 45 | - HTTP 비연결성의 단점과 해결책 46 | - 모든 웹 페이지에서 HTTPS 를 사용하지 않는 이유를 설명해 주세요. 47 | - 비대칭키 또는 공개키 암호화 방식은 무엇인가요? 48 | - HTTP REQUEST 방식 중 GET과 POST의 차이을 설명해 주세요. 49 | - GET, POST를 제외하고 다른 방식들을 설명해 주세요. 50 | - HTTP 프로토콜을 사용하여 개발한 경험 51 | - 웹 애플리케이션 제작 시 조회/삭제/수정의 업무를 하려고 합니다. 각각을 어떤 방식으로 설계할 것인지 말해주세요. 52 | - HTTP또는 암호화 되지 않은 프로토콜의 문제점은 무엇이 있나요? 53 | - 이러한 문제를 해결하기 위한 다양한 방안이 존재하는데 대표적으로 HTTPS 가 있습니다. HTTPS에 대해 설명 해주시겠어요? 54 | - HTTP 와 HTTPS 중 어떤 프로토콜이 더 많이 사용 된다고 생각하는지와 그 이유에 대해서 말씀해 주세요. 55 | 56 | ### 로드밸런서 57 | 58 | - 로드밸런싱에 대해 설명해 주세요. 59 | - 서버에서 트래픽이 주어졌을 때 어떻게 응답속도를 개선할 수 있는가? (힌트 : 스케일 업과 스케일 아웃) 60 | - 로드 밸런싱의 대표 알고리즘은 어떤 것이 있을까요? (힌트 : 라운드 로빈, 최소 연결 방식) 61 | - L4 로드밸런싱과 L7 로드밸런싱에 대해 설명하고 차이를 말씀해 주세요. 62 | 63 | - 데이터 갱신이 빈번할 때, scale up이 유리한 이유는? 64 | 65 | ### **IP, 도메인, DNS** 66 | 67 | - 도메인과 DNS가 무엇인지 설명해 주세요. 68 | - DNS 서버는 무슨 역할을 하나요? 69 | - 도메인과 ip 주소에 대해서 설명해 주세요. 70 | - Domain Name 구조와 recursive query 과정을 설명해 주세요. 71 | - DHCP 서버의 역할을 간단히 설명해 주세요. 72 | - Domain Name System 동작과정을 설명해 주세요. 73 | - DNS round robin 방식과 문제점과 해결방법을 설명해 주세요. 74 | 75 | ### REST API 76 | 77 | - REST의 핵심 3가지 요소를 포함하여 REST가 무엇인지 설명해 주세요. 78 | 79 | - REST의 기본 원칙을 3개 이상 설명해 주세요. 80 | 81 | - 응답 상태 코드 종류별로 설명해 주세요. 82 | 83 | ### Cookie, Session, JWT 84 | 85 | - HTTP의 특징과 쿠키와 세션이 등장한 이유를 설명해 주세요. 86 | - 쿠키와 세션에 대해 설명해 주세요. (차이, 특징, 사용처) 87 | - 세션 기반 인증 방식 vs 토큰 기반 인증 방식에 대해 설명해 주세요. 88 | 89 | - JWT에 대해 설명해 주세요. (특징, 장단) 90 | 91 | ### CORS 92 | 93 | - CORS와 CORS로 인한 이슈에 대해 설명해 주세요. 94 | - CORS 동작 방식을 간단히 설명해 주세요. 95 | 96 | ### OAuth 97 | 98 | - OAuth 적용한 경험 99 | - OAuth 인증 방식을 간단히 설명해 주세요. 100 | - OAuth1.0 과 OAuth2.0의 차이를 설명해 주세요. 101 | 102 | ### 그 외 질문 103 | 104 | - 웹 서버와 WAS 차이 105 | - Authentication and Authorization 106 | - 공개키 암호, 대칭 키 암호 107 | 108 | ## 심화 내용 질문 109 | 110 | ### 프록시 111 | 112 | - 프록시를 간단히 설명해 주세요. 113 | 114 | - 포워드 프록시와 리버스 프록시의 차이, 특징을 설명해 주세요. 115 | 116 | ### 네트워크 보안 117 | 118 | - 보안의 3대 요소를 설명해 주세요. 119 | - IPSec이란? 120 | - SSL과 TLS? 121 | 122 | - CSRF? -------------------------------------------------------------------------------- /OperatingSystem/CPU 스케줄링 기법/CPU 스케줄링 기법 .md: -------------------------------------------------------------------------------- 1 | # Scheduling 2 | 3 | **다중 프로그래밍(multi-prgramming)** 4 | 5 | - 여러 프로세스가 시스템에 존재 6 | - 자원을 할당 할 프로세스 선택= 스케줄링 7 | - 자원 관리 8 | 9 | **자원 관리** 10 | 11 | 1. 시간 분할(time sharing) 관리 12 | 13 | - 하나의 자원을 여러 스레드들이 번갈아 가며 사용. 예) 프로세서(CPU). CPU에는 한번에 하나의 프로세스 14 | - ex) process scheduling 15 | 16 | 2. 공간 분할(space sharing) 관리 17 | 18 | - 하나의 자원을 분할하여 동시 사용 19 | - ex) memory 20 | 21 | **스케줄링의 목적** 22 | 23 | - 성능 향상 24 | - 목적에 맞는 지표를 고려하여 스케줄링 기법 선택 25 | 26 | **성능의 지표** 27 | 28 | - reponse time: 작업 요청으로부터 응답을 받을 때까지의 시간 29 | - throughput(작업 처리량): 단위 시간 동안 완료된 작업의 수 30 | - resource utilization(자원 활용도): 주어진 시간 동안 자원이 활용된 시간 31 | 32 | **스케줄링 기준(Criteria)** 33 | 34 | - 기준= 스케줄링 기법이 고려하는 항목(지표?) 35 | - 프로세스의 특성: I/O-bounded or compute-bounded 36 | - 시스템 특성: Batch or Interactive system 37 | - 프로세스 긴급성(urgency) 38 | - 프로세스 우선순위(priority) 39 | 40 | **CPU burst vs I/O burst** 41 | 42 | - burst time은 스케줄링의 중요 기준 중 하나 43 | - CPU burst= CPU 사용 시간 44 | - I/O burst= I/O 대기 시간 45 | - 프로세스 수행=CPU 사용+ I/O 대기 46 | - I/O-bounded= I/O burst > CPU burst. I/O burst가 프로세스 성능 결정 47 | - compute-bounded= CPU burst > I/O burst. CPU burst가 프로세스 성능 결정 48 | 49 | ![https://blog.kakaocdn.net/dn/Qaz0k/btrszlI3VcS/W0oROd5viBTKrZiGj1D6yk/img.png](https://blog.kakaocdn.net/dn/Qaz0k/btrszlI3VcS/W0oROd5viBTKrZiGj1D6yk/img.png) 50 | 51 | --- 52 | 53 | **CPU 스케줄러란?** 54 | 55 | 준비 큐에 있는 프로세스에 대해 CPU할당하는 방법 56 | 57 | **Scheduling Policy(정책)** 58 | 59 | 1. 선점 vs 비선점 60 | 61 | preemptive scheduling, Non-preemptive scheduling 62 | 63 | 2. 우선순위 64 | 65 | priority 66 | 67 | **Non-preemptive scheduling(= 자원을 뺏을 수 X)** 68 | 69 | - 할당 받을 자원을 스스로 반납할 때까지 사용. 70 | - 장점: context-switching이 적음 71 | - 단점: 평균 응답 시간 증가, 우선순위 역전 현상(우선순위가 높아도 앞에서 끝날 때까지 대기) 72 | 73 | **Preemptive scheduling(= 자원을 뺏을 수 O)** 74 | 75 | - 장점: 응답성 높다. 76 | - ex) time-sharing system, real-time system 등에 적합 77 | - 단점: 빈번한 context-switching-> overhead가 큼 78 | 79 | **Priority** 80 | 81 | 프로세스의 중요도 82 | 83 | 1. static priority(정적 우선순위) 84 | 85 | - 프로세스 생성시 우선순위 결정되고 불변 86 | - 구현 쉽고, overhead 적음 87 | - 시스템 환경 변화 대응 어려움 88 | 89 | 2. dynamic priority(동적 우선순위) 90 | 91 | - 프로세스 상태 변화에 따라 우선순위 변경 92 | - 구현이 복잡. 우선순위 재계산-> overhead가 큼 93 | - 시스템 환경 변화 유연 대응 94 | 95 | 스케줄링 5가지 96 | 97 | - FCFS 98 | - SJF 99 | - SRT 100 | - Round Robin 101 | - Priority Scheduling 102 | 103 | --- 104 | 105 | **1. FCFS(First Come First Service)= 선착순 알고리즘** 106 | 107 | - Non-preemptive scheduling 108 | - 스케줄링 기준: 도착시간(ready queue 기준). 먼저 도착 프로세스 먼저 처리 109 | - scheduling overhead가 낮다. CPU가 계속 일할 수 있다. 110 | - Batch sysytem(일괄처리)에 적합, interactive system에 부적합 111 | - 단점: . 긴 평균 응답시간 112 | 113 | Convoy effect 114 | 115 | 116 | **convoy effect** 117 | 118 | 하나의 수행시간이 긴 프로세스에 의해 다른 프로세스들이 긴 대기시간을 갖게 되는 현상(대기시간>>실행시간) 119 | 120 | ![https://blog.kakaocdn.net/dn/ZlUeL/btrsqC0b9ku/LSCdjgbwx9EeqpK47wDuxk/img.png](https://blog.kakaocdn.net/dn/ZlUeL/btrsqC0b9ku/LSCdjgbwx9EeqpK47wDuxk/img.png) 121 | 122 | --- 123 | 124 | **SPN(Shorest Process Next)= burst time이 가장 작은 프로세스 먼저 처리하자!** 125 | 126 | - Non-preemptive scheduling. 자원 뺏길 수 X 127 | - 스케줄링 기준: burst time 128 | - burst time이 가장  프로세스 먼저 처리 129 | 130 | 작은 131 | 132 | - SJF(Shortest Job First) scheduling 133 | - ex) 소량 상품 전용 계산대 134 | 135 | ![https://blog.kakaocdn.net/dn/c6nkYf/btrsveLhyeX/PLOuE0qXb3YC591ppQCdx1/img.png](https://blog.kakaocdn.net/dn/c6nkYf/btrsveLhyeX/PLOuE0qXb3YC591ppQCdx1/img.png) 136 | 137 | **장점:** 138 | 139 | - 평균 대기시간(WT) 최소 140 | - 시스템 내 프로세스 수 최소화 141 | - 스케줄링 부하 감소. 메모리 감소-> 효율 향상 142 | - 많은 프로세스 빠른 응답 시간 제공 143 | 144 | **단점:** 145 | 146 | - starvation(기아) 현상 발생= 무한대기 147 | - BT가 긴 프로세스는 자원을 할당 받지 못 할 수 있음(Aging으로 해결. HRRN) 148 | - 정확한 실행시간 알 수 없음. BT 예측 기법 필요 149 | 150 | --- 151 | 152 | **SRTN(Shortest Remaining Time Next)= 남은 시간 적은 프로세스 먼저!** 153 | 154 | - SPN 변형 155 | - preemtive scheduling. 잔여 실행 시간이 더 적은 프로세스가 ready 상태가 되면 선점 됨. 156 | - 장점: SPN 극대화(평균 대기시간 최소화, 시스템 내 프로세스 최소화) 157 | - 단점: 158 | 159 | 1. 프로세스 생성 시, BT 예측 필요 160 | 161 | 2. 잔여 실행 시간 추적 필요-> overhead 162 | 163 | 3. context switching overhead 164 | 165 | 4. 구현 비현실적 166 | 167 | --- 168 | 169 | **RR(Round-Robin)= 돌려가며 사용** 170 | 171 | - preemptive scheduling 172 | - 스케줄링 기준: 도착시간. 먼저 도착한 프로세스 처리(FCFS와 동일) 173 | - 174 | 175 | 자원 사용 제한 시간(time quantum)이 존재 176 | 177 | - 프로세스는 할당 시간이 지나면 자원 반납 178 | - 특점 프로세스의 자원 독점() 방지 179 | 180 | monopoly 181 | 182 | - 단점: context switching overhead가 큼 183 | - interactive system, Time sharing system에 적합 184 | 185 | **Time quantum** 186 | 187 | - 시스템 성능을 결정하는 핵심 188 | - Very large(infinite)-> FCFS 189 | - Very small-> processor sharing 190 | 191 | 사용자는 모든 프로세스가 각각의 프로세서 위에서 실행되는 것처럼 느낌. High context switch overhead 192 | 193 | ![https://blog.kakaocdn.net/dn/sIZEb/btrswXbaAvt/SjVHpNc1msZPEMpYdEOHfk/img.png](https://blog.kakaocdn.net/dn/sIZEb/btrswXbaAvt/SjVHpNc1msZPEMpYdEOHfk/img.png) 194 | 195 | --- 196 | 197 | **MLQ와 MFQ** 198 | 199 | 이전 SPN, SRTN, HRRN의 단점인 BT예측 overhead를 해결 200 | 201 | **MLQ(Multi Level Queue)** 202 | 203 | - ready queue가 여러 개 가짐 204 | - 각각의 큐마다 작업 또는 우선순위 배정 205 | - 최초 배정 된 큐는 고정. 큐 이동 못함. 206 | - 각각의 큐 자신만의 스케줄링 기법 사용 207 | - 큐 사이에는 우선순위 기반의 스케줄링 사용(각각 큐가 우선순위가 다르다) 208 | 209 | **MLQ의 단점** 210 | 211 | - 우선순위 낮은 큐는 여전히 starvation 현상 발생 가능 212 | - 여러 개 큐 관리 등 스케줄링 overhead 발생 213 | - 큐 고정. 시스템 변화 적응 어려움 214 | 215 | ![https://blog.kakaocdn.net/dn/cXiv2g/btrsA6rpByI/NGB3iIQEo99FYkpnOP0mck/img.png](https://blog.kakaocdn.net/dn/cXiv2g/btrsA6rpByI/NGB3iIQEo99FYkpnOP0mck/img.png) 216 | 217 | --- 218 | 219 | **MFQ(Multi Level Feedback Queue)** 220 | 221 | - MLQ와의 차이: 프로세스의 큐간 이동이 허용 222 | - Dynamic priority 223 | - Feedback을 통해 우선순위 조정 224 | - 프로세스에 대한 사전 정보 없이 SPN, SRTN, HRRN 기법 효과 225 | 226 | **MFQ 특성** 227 | 228 | - Dynamic priority 229 | - Preemptive scheduling 230 | 231 | ![https://blog.kakaocdn.net/dn/dbzcku/btrsAcd7HUC/Iip8Yjzoq6IJk5ikIKfVs0/img.png](https://blog.kakaocdn.net/dn/dbzcku/btrsAcd7HUC/Iip8Yjzoq6IJk5ikIKfVs0/img.png) 232 | 233 | **MFQ 변형** 234 | 235 | - **각 ready queue마다 시간 할당량을 다르게 배정 가능** 236 | 237 | ex) 중요한 프로세스 time quantum= infinite, 덜 중요 time quantum= 2ms 238 | 239 | - **큐 이동 기준이 되는 정책/전략 선택 가능** 240 | 241 | ex) 입출력 위주 프로세스(I/O bounded)들은 상위 레벨 큐로 이동(우선순위 높임) 242 | 243 | - 프로세스가 block될 때 상위 큐로 진입하게 함. 244 | 245 | - 평균 응답 시간 줄임? I/O bounded는 CPU 잠깐 쓰고 나옴. 입출력 작업 분산 시킴 246 | 247 | ex) 대기 시간이 지정된 시간 초과한 프로세스들은 상위 레벨 큐로 이동 248 | 249 | - aging 기법 250 | 251 | **MFQ의 단점** 252 | 253 | - 큐 이동, 큐 관리-> 스케줄링 overhead 큼 254 | - 여전한 starvation 문제(낮은 우선순위 큐) -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled 1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled 1.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled 2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled 2.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled 3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled 3.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled 4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled 4.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled 5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled 5.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID be8c1/Untitled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/RAID/RAID be8c1/Untitled.png -------------------------------------------------------------------------------- /OperatingSystem/RAID/RAID.md: -------------------------------------------------------------------------------- 1 | # RAID 2 | 3 | **RAID Architecture란?** 4 | 5 | - Redundant Array of Independent Disks: 복수 배열 독립 디스크 6 | - 여러 개 물리 disk를 하나의 논리 disk로 사용 7 | 8 | ![Untitled](RAID%20be8c1/Untitled.png) 9 | 10 | **RAID를 사용하는 이유** 11 | 12 | - 성능 향상 13 | - Access speed(접근 속도) 14 | - Reliability(안전성) 15 | 16 | --- 17 | 18 | **RAID0** 19 | 20 | - 접근 속도에 초점 21 | - Disk striping 22 | - block을 일정한 크기로 나누어 각 disk에 나누어 저장 23 | - 모든 disk에 입출력 부하 균등 분배 24 | - 병렬 접근(parallel access) 25 | - 접근 속도 향상 26 | - 단점 27 | - 한 disk 장애 시, 데이터 손실 발생(Low Reliability, 안전성 낮다) 28 | 29 | ![Untitled](RAID%20be8c1/Untitled%201.png) 30 | 31 | --- 32 | 33 | **RAID1** 34 | 35 | - 안전성에 초점 36 | - Disk mirroring 37 | - 동일한 데이터를 mirroring disk에 중복 저장 38 | - 최소 2개의 disk로 구성 39 | - 단점 40 | - 한 disk 장애 생겨도 데이터 손실 X 41 | - 가용량: (전체 disk 용량)/2 42 | 43 | ![Untitled](RAID%20be8c1/Untitled%202.png) 44 | 45 | --- 46 | 47 | **RAID3** 48 | 49 | - RAID0+ parity disk 50 | - Byte 단위로 분할 저장 51 | - 모든 disk에 입출력 부하 균등 분배(block A를 읽으려면 A0, A1, A2, A3 동시 접근) 52 | - 한 disk에 장애 발생 시, parity 정보를 이용하여 복구 53 | - write 시 parity 계산이 필요 54 | - 단점 55 | - disk에 write 할 때마다 parity 정보도 parity disk에 저장→ overhead가 발생 56 | - write 몰리면 병목현상 발생 가능 57 | - parity disk에 장애가 발생하면? 58 | 59 | ![Untitled](RAID%20be8c1/Untitled%203.png) 60 | 61 | **parity란?** 62 | 63 | - 디스크 장애 시 데이터를 재 구축하는데 사용할 수 있는 사전에 계산된 값 64 | - 디스크 하나가 장애가 날 경우 Parity 영역를 이용해서 장애 난 디스크의 데이터를 복구한다. 65 | 66 | --- 67 | 68 | **RAID4** 69 | 70 | - RAID3와 유사, 단 Block 단위로 분산 저장 71 | - 각 Block을 독립적으로 접근 할 수 있다. 단, Disk 간 균등 분배가 안될 수 있음. 72 | - 한 disk에 장애 발생 시, parity 정보를 이용하여 복구 73 | - write 시 parity 계산이 필요 74 | 75 | ![Untitled](RAID%20be8c1/Untitled%204.png) 76 | 77 | --- 78 | 79 | **RAID5** 80 | 81 | - RAID3, RAID4의 parity disk 장애 발생 문제 해결 82 | - 접근 속도+ 안전성에 초점. 두마리 토끼! 83 | - RAID4와 유사, 단 parity도 나눠서 저장하겠다! 84 | - 디스크의 5개 블록 중 4개는 데이터를 저장하는데 쓰고 나머지 하나는 Parity 영역으로 둔다. 85 | - parity disk의 병목현상 문제 해결 86 | - 단 디스크 2개 이상 고장나면 복구할 수 없다. 87 | 88 | ![Untitled](RAID%20be8c1/Untitled%205.png) 89 | 90 | --- 91 | 92 | **참고** 93 | 94 | [https://www.youtube.com/watch?v=omDkxSyol98](https://www.youtube.com/watch?v=omDkxSyol98) 95 | 96 | [https://anmj.tistory.com/12#--%--�%-A%A-�%-A%B-�%-D��%-D%B-�%--%--](https://anmj.tistory.com/12#--%25--%EC%25-A%25A-%ED%25-A%25B-%EB%25-D%BC%EC%25-D%25B-%ED%25--%25--) 97 | 98 | [https://hihighlinux.tistory.com/64](https://hihighlinux.tistory.com/64) -------------------------------------------------------------------------------- /OperatingSystem/가상머신.md: -------------------------------------------------------------------------------- 1 | # 가상머신 2 | 3 | - 하드웨어를 소프트웨어적으로 구현해서 그 위에서 운영체제가 작동하도록하는 기술 4 | 5 | ## 가상머신을 사용하는 이유 6 | 7 | - 다른 운영체제를 사용해야 하는 경우(맥OS에서 윈도우, 윈도우에서 리눅스) 8 | - 독립된 작업공간이 필요한 경우 (바이러스 회피, 백업) 9 | - 하나의 머신에서 여러명에게 운영체제 환경을 제공 10 | - 하나의 컴퓨터 자원을 여러 사용자에게 나누어 주는 상황에서 상호 간섭을 없애고 싶을 때 11 | 12 | ## 하이퍼바이저(Hypervisor) 13 | 14 | - 가상 머신(Virtual Machine, VM)을 생성하고 구동하는 소프트웨어 15 | - 위치와 역할에 따른 분류, 가상화 방식에 따른 분류가 있음 16 | 17 | ### 하이퍼바이저의 위치와 역할에 따른 분류 18 | 19 | 20 | 21 | #### Type1: Native, Bare Metal 하이퍼바이저 22 | 23 | - 하드웨어에 직접 설치하여 구동하는 형태 24 | - 하드웨어를 제어하는 OS 역할과 VM 들을 관리하는 역할을 모두 하이퍼바이저가 담당 25 | - 하이퍼바이저가 하드웨어 드라이버를 모두설정해야 하여 설치가 어려움 26 | - 대규모로 관리되는곳에서 주로 사용: 엔터프라이즈 데이터 센터, 서버 기반 환경, 클라우드 27 | - Type 1 제품: Xen, KVM, Microsoft Hyper-V, VMware vSphere 28 | 29 | #### Type2: Hosted 하이퍼바이저 30 | 31 | - Application 과 마찬가지로 OS 위에 설치되는 방식의 하이퍼바이저 32 | - 컴퓨터 환경(OS)을 그대로 사용하는 방식이므로 설치 및 구성이 편리하다는 장점 33 | - Type1 에 비하여 실행되는 OS의 layer가 많은것을 알수 있다. layer를 더 타야하므로 type1에 비하여 성능 떨어짐 34 | - 개인 사용자가 컴퓨터에서 여러 개의 운영 체제를 구동하기 위해 주로 사용 35 | - Type 2 제품: VMware, VirtualBox 36 | 37 | ### 하이퍼바이저의 가상화 방식에 따른 분류 38 | 39 | - 운영체제별 사용하는 CPU명령어가 상이하여 CPU명령어를 가상화하는 방법에 따라 분류됨 40 | - 과거의 분류 방식으로 현재VM제품은 다양한 기술을 사용하여 두가지 분류의 경계가 모호함 41 | 42 | #### 전가상화(Full Virtualization) 43 | 44 | 45 | 46 | - Hypervisor는 VM OS의 명령어를 하드웨어가 전달받을 수 있는 형태로 번역함. 47 | - VM OS에게 하드웨어 자원을 분배하는 역할도 함. 48 | 49 | #### 반가상화(Para Virtualization) 50 | 51 | 52 | 53 | - VM OS가 직접 하드웨어에 명령어를 전달함. 54 | - VM OS의 명령어(커널)를 수정. 55 | 56 | - CPU 명령어를 가상화하는 범위에 따라 분류됨 57 | 58 | #### 가상머신 없는 x86(인텔, AMD, arm제외) CPU 59 | 60 | 61 | 62 | - Ring 번호가 낮을수록 높은 권한을 가짐 63 | - 운영체제는 Ring 0에서 특권 명령(privileged mode)을 사용하여 필요한 컴퓨팅 자원에 접근이 가능 64 | 65 | #### x86(인텔, AMD, arm제외) CPU에서 가상머신 66 | 67 | 68 | 69 | - Vmware Binary translation 70 | 71 | - VM OS에서 전달받은 명령어를 Hypervisor에서 binary trasnlation란 기술을 통하여 일괄적인 하드웨어명령어로 변환하여 전달 72 | - VN OS의 명령어(커널)을 수정할 필요가 없음 73 | 74 | - Xen Hypercall 75 | 76 | - Hypercall 기능을 사용하여 VM OS의 명령어가 하드웨어에 전달됨 77 | - VM OS의 명령어(커널)을 수정해야함 78 | - 성능과 속도가 우수하지만 VM OS가 오픈소스가 아닐경우 적용에 어려움이 있음 79 | 80 | 81 | 82 | - CPU 차원의 가상화: Intel VT, AMD-V 83 | - VM OS에 관계없이 다양한 운영체제를 사용할 수 있다는 장점이 있음 84 | - CPU가 다시한번 하이퍼바이저에게 하드웨어 제어를 요구하기에 이에따른 오버헤드가 발생 85 | 86 | ## 가상머신 vs 컨테이너 87 | 88 | 89 | 90 | - 컨테이너는 동일한 운영 체제 커널과 패키지 애플리케이션을 실행(runtime)환경과 공유하며 프로세스만 격리하는 방식 91 | - 리눅스의 cgroups과 namespace를 을 통하여 작동하여 이러한 기능을 사용하지 않는 윈도우에서 구동이 어려움 92 | - cgroups: 프로세스들의 하드웨어 사용을 제한하고 격리시키는 리눅스 커널 기능. 93 | - 컨테이너는 애플리케이션 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 구성을 하나의 인스턴스에 패키징하는 기본적인 방법을 제공 94 | - 작동시간 이 짧고 디스크도 VM에 비하여 적음 95 | - 독립된 환경을 제공하지 않으며 보안에 취약함 96 | 97 | ## QnA 98 | 99 | ## References 100 | 101 | > https://opentutorials.org/course/173 102 | 103 | > http://cloudrain21.com/hypervisor-types 104 | 105 | > https://www.slideshare.net/rkawkxms/docker-container 106 | 107 | > https://inpages.tistory.com/86 108 | 109 | > https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor 110 | 111 | > http://bugsfixed.blogspot.com/2016/10/blog-post.html#full-virtualization-vs-para-virtualzation 112 | 113 | > https://medium.com/@ch.lee2/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3-%EC%A0%84%EA%B0%80%EC%83%81%ED%99%94%EC%99%80-%EB%B0%98%EA%B0%80%EC%83%81%ED%99%94-6f00b1f5e741 114 | 115 | > https://m.blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=220218878967&proxyReferer=https:%2F%2Fwww.google.com%2F 116 | 117 | > https://born-dev.tistory.com/39 118 | 119 | > https://www.redhat.com/ko/topics/containers/what-is-docker 120 | -------------------------------------------------------------------------------- /OperatingSystem/가상머신/cpu-vt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/cpu-vt.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/hypervisor-type.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/hypervisor-type.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/vm-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/vm-container.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/vm-xen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/vm-xen.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/x86-ring.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/x86-ring.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/반가상화.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/반가상화.png -------------------------------------------------------------------------------- /OperatingSystem/가상머신/전가상화.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/가상머신/전가상화.png -------------------------------------------------------------------------------- /OperatingSystem/교착 상태와 기아 상태.md: -------------------------------------------------------------------------------- 1 | # 교착 상태와 기아 상태 2 | 3 | - 교착 상태 4 | - 교착 상태 해결 방법 5 | - 기아 상태 6 | - 교착 상태 vs 기아 상태 7 | - QnA 8 | 9 | ## 교착 상태 (Deadlock) 10 | 11 | - 무한 대기 상태 12 | - 여러 프로세스들이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 다음 단계로 진행하지 못하는 상태 13 | 14 | > 스레드 1은 스레드2가 점유하고 있는 자원 2를 대기하고 있고, 스레드 2는 스레드 1이 점유한 자원 1을 대기하고 있다. 15 | > 각 프로세스(스레드)들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 기다리고 있다. 16 | > 이것이 **무한 대기 상태인 교착상태**라고 일컫는다. 17 | 18 | ![image](https://user-images.githubusercontent.com/38436013/131252562-21a6e783-53a9-41c2-8a2f-baf05eb0d9e0.png) 19 | 20 | - 멀티 프로그래밍에서 흔히 발생하는 문제, 이를 해결하는 방법은 아직 없다. 21 | 22 | - 멀티 프로그래밍 용어 설명 23 | 24 | > **하나의 프로세서가 (하나의 프로세스를 처리하는 과정에서) 입출력 종료 대기하는 시간을 기다리지 않고, 다른 프로세스를 수행할 수 있도록 하는 것** 25 | > 초기에는 하나의 프로세서가 하나의 프로세스를 수행하도록 설계됨, 하나의 프로세스 처리하는 과정에서 프로세서의 입출력 처리가 완료될 때까지 기다리는 시간이 생기고, 이것이 비효율적임 26 | 27 | - 프로세스, 스레드 둘다 이와 같은 상태가 일어날 수 있음 28 | 29 | - 결코 일어나지 않을 사건을 기다리는 무한 대기 -> 기아 상태가 되기도 함 30 | 31 | ### 교착 상태 발생 조건 32 | 33 | 네 가지 모두 성립하면 발생 가능하다. 34 | 35 | | 조건 | | 36 | | ---------------------------- | ------------------------------------------------------------ | 37 | | `상호배제(Mutual exclusion)` | 한번에 한개의 프로세스만이 공유 자원을 사용 | 38 | | `점유대기(Hold and wait)` | 프로세스가 자원을 점유한 상태에서 다른 프로세스가 점유한 자원을 대기 | 39 | | `비선점(No preemption)` | 자원 점유에 대한 통제권을 빼앗지 못하는 것 | 40 | | `순환대기(Circular wait)` | 공유 자원 사용하기 위해 프로세스들이 원형으로 구성되어 있어,
각 프로세스는 자원을 점유한 상태에서 앞이나 뒤에 있는 프로세스의 자원을 요구하는 형태 | 41 | 42 | 43 | 44 | ## 교착 상태 해결 방법 45 | 46 | - 교착 상태 예방 47 | - 교착 상태 회피 48 | - 교착 상태 발견 49 | - 교착 상태 회복 50 | 51 | ### 교착 상태 예방 52 | 53 | - 4가지 조건 중 하나를 제거하는 방법 54 | 55 | 1. 상호 배제 조건의 제거: 한 번에 여러 프로세스가 공유 자원에 접근 가능 56 | 2. 점유와 대기 조건의 제거: 프로세스 실행되기 전 필요한 모든 자원 할당하여 대기 상태 없앰 57 | 3. 비선점 조건 제거: 선점 가능 기법을 만들어줌 58 | 4. 순환 대기 조건 제거: 선형 순서로 나열하여 자원에 순서를 부여 59 | 60 | ### 교착상태 회피 61 | 62 | - 교착 상태가 발생할 가능성 배제하지 않고, 발생하면 피해나가는 방법으로 은행원 알고리즘이 사용된다. 63 | 64 | - 은행원 알고리즘 65 | 66 | [자세히 살피기](https://mfamcs.netlify.app/docs/ca_and_os/%EA%B5%90%EC%B0%A9%20%EC%83%81%ED%83%9C/) 67 | 68 | > 1. 다익스트라가 제안한 기법으로, 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는 기법 69 | > 2. 각 프로세스에게 자원을 할당하여 교착 상태가 발생하지 않도록 하며, 안정 상태(모든 프로세스가 완료될 수 있는 상태), 불안정 상태(교착 상태가 발생 가능한 상태)가 있다. 70 | > 3. 자원의 양과 프로세스 수가 일정해야 한다. 71 | > 4. 프로세스의 모든 요구를 유한한 시간안에 할당하는 것을 보장 72 | 73 | - 은행원 알고리즘은 교착 상태를 회피하는 기법으로, 복잡하고 오버헤드가 커서 현재 적용되지 않는 방식이다. 74 | 75 | ### 교착 상태 발견 76 | 77 | - 교착상태가 발생했는지 점검하여 교착 상태에 있는 프로세스와 자원을 발견하는 것 78 | - 교착 상태 알고리즘(?)으로 교착 상태 발생을 체크하는 방식이다. 79 | 80 | ### 교착 상태 회복 81 | 82 | - 교착 상태를 일으킨 프로세스를 종료하거나 교착상태의 프로세스에 할당 된 자원을 선점하여 프로세스나 자원을 회복하는 것 83 | 84 | 85 | 86 | ## 기아 상태 (Starvation) 87 | 88 | - 우선 순위 낮아서 원하는 자원을 할당 받지 못하는 상태 89 | - 특정 프로세스는 영원히 자원을 할당받지 못함 90 | - 우선 순위 스케줄링 알고리즘에서 주로 발생 91 | 92 | ### 기아 상태 해결 방법 93 | 94 | - `에이징 기법` 95 | - 우선 순위가 낮은 프로세스의 우선 순위를 높여줘서 문제 해결 96 | - 예 : 다단계 피드백 큐 스케줄링 기법 97 | - 요청 순서대로 fifo 기반 요청 98 | 99 | 100 | 101 | ## 교착 상태 vs 기아 상태 102 | 103 | 교착 상태와 기아 상태는 **프로세스 실행을 차단하여 지연**시키는 공통점이 있다. 104 | 105 | - `교착 상태(데드락)` 106 | - 교착상태는 여러 프로세스들이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 다음 단계로 진행하지 못하는 상태 107 | - 원인 : 제한된 자원을 할당한 결과로 일어난 부작용(한정된 공유 자원 사용으로 인한 부작용) 108 | - 해결 방안 : 운영체제가 교착상태를 해결하지 못하면 시스템 운영자나 사용자는 작업을 교체하거나 종료하는 외부 간섭으로 이를 해결해야 한다. 109 | - **교착 상태는 기아 상태가 됨, 그 역은 안됨** 110 | - `기아` 111 | - 우선순위 낮은 프로세스는 영원히 자원 할당이 안되는 경우를 주로 의미함 112 | - 원인 : 기다리는 결과를 개선하기 위해 자원 할당할때 발생한 부작용 113 | - 해결 방안 : 우선순위 높인다. 114 | 115 | 116 | 117 | ## QnA 118 | 119 | - 교착 상태란 무엇인가? 120 | - 교착 상태의 4가지 조건은 무엇이며, 각각 어떤 역할을 하는가? 121 | - 교착 상태의 해결방법에는 어떤 것들이 있는가? 122 | - 교착 상태와 기아 상태를 비교하여 설명하시오(공통, 차이) 123 | - 기아 상태를 해결하는 방법은 무엇인가? 124 | 125 | 126 | 127 | ### Reference 128 | 129 | - https://velog.io/@sdk1926/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EA%B5%90%EC%B0%A9%EC%83%81%ED%83%9C%EC%99%80-%EA%B8%B0%EC%95%84%EC%83%81%ED%83%9C 130 | 131 | - https://mfamcs.netlify.app/docs/CA_and_OS/%EA%B5%90%EC%B0%A9%20%EC%83%81%ED%83%9C 132 | 133 | - https://coding-factory.tistory.com/311 134 | 135 | - https://sorjfkrh5078.tistory.com/56 -------------------------------------------------------------------------------- /OperatingSystem/메모리 할당과 단편화.md: -------------------------------------------------------------------------------- 1 | # 메모리 할당과 단편화 2 | 3 | 멀티 프로세스 작업시 여러개의 프로세스를 메모리에 적재하기 위하여 메모리 영역을 분할하고 할당함. 4 | 5 | ## 용어 6 | 7 | - 내부 단편화(Internal Fragmentation): 프로세스가 필요한 양보다 더 큰 메모리가 할당되어서 프로세스에서 사용하는 메모리 공간이 낭비되는 상황 8 | - 외부 단편화(External Fragmentation): 할당된 메모리 사이에 작은 메모리가 생겨나게 되어, 총 메모리 공간은 충분하지만 실제로는 할당할 수 없는 상황 9 | 10 | ## 메모리 할당 방법 11 | 12 | ### 연속할당방식 13 | 14 | 분할된 메모리 공간에 프로세스를 연속되게 적재 15 | 16 | ### 고정 분할 17 | 18 | - 분할의 수와 크기가 정해져 있다. 때문에 적재되는 프로세스는 반드시 분할된 메모리공간보다 같거나 작아야한다. 19 | 20 | - 분할된 메모리공간에는 하나의 프로세스만이 적재가 되므로 프로세스의 크기가 분할된 메모리공간보다 작을 경우 사용하지 않는 메모리 공간발생. -> 내부 단편화(internal fragmentation) 21 | 22 | ### 가변 분할 23 | 24 | - 고정분할의 내부 단편화(internal fragmentation)현상을 해결 25 | - 적재되는 프로그램의 크기만큼 메모리 공간을 가변적으로 분할 후 할당하는 방식 26 | 27 | - 분할 공간 사이에 크기가 너무 작아서 하용할 수 없는 빈 공간들이 산재하게 됨. -> 외부 단편화(external fragmentation) 28 | 29 | #### 가변분할의 메모리 할당 알고리즘 30 | 31 | - 최초 적합 방법(first-fit): 프로세스를 할당 가능한 메모리 공간을 최초로 발견될 때 할당. 모든 가용 공간을 탐색하지 않아 시간적인 측면에서 효율적. 32 | - 최적 적합 방법(best-fit): 프로세스를 할당 가능한 메모리 중 가장 작은 공간에 할당. 사용가능한 모든 메모리공간을 탐색, 정렬해야하는 오버헤드가 발생. -> 큰 프로세스 적재 공간 확보 33 | - 최악 적합 방법(worst-fit): 프로세스를 할당 가능한 메모리 중 가장 큰 공간에 할당. 사용가능한 모든 메모리공간을 탐색, 정렬해야하는 오버헤드가 발생. -> 외부 단편화 최소화 34 | - 알고리즘간 효율성 비교: https://jhnyang.tistory.com/284 35 | 36 | ### 불연속할당방식 37 | 38 | 프로세스가 물리적 메모리의 여러 위치에 분산되어 적재 39 | 40 | - paging: 프로세스의 주소 공간을 동일한 크기의 페이지 단위로 나누어 물리적 메모리의 서로 다른 위치에 페이지들을 저장하는 방식 41 | - segmentation: 프로세스의 주소공간을 의미 단위의 세그먼트(segment)로 나누어 물리적 메모리에 올리는 방식 42 | - paged segmentation: 두가지의 장점을 결합한 방식 43 | 44 | ## QnA 45 | 46 | ## References 47 | 48 | > https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=wndrlf2003&logNo=220118909484 49 | > 50 | > https://ooeunz.tistory.com/97 51 | > 52 | > https://zangzangs.tistory.com/134?category=458016 53 | > 54 | > https://junyng.tistory.com/45 55 | -------------------------------------------------------------------------------- /OperatingSystem/메모리 할당과 단편화/가변분할.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/메모리 할당과 단편화/가변분할.png -------------------------------------------------------------------------------- /OperatingSystem/메모리 할당과 단편화/고정분할.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/메모리 할당과 단편화/고정분할.png -------------------------------------------------------------------------------- /OperatingSystem/블록_논블록_동기_비동기.md: -------------------------------------------------------------------------------- 1 | - 블록(Block) 2 | - 우리가 흔히 알고 있는 Block의 개념과 같다
3 | 함수를 실행했을 때, 실행할 동안 다른 함수를 호출하지 못 한다.
4 | 5 | - 함수A와 함수B가 있고, 순서가 A -> B라면,
6 | 함수B는 함수A가 끝날 때까지 호출되지 못 한다. 7 | 8 | 9 | - 논블록(Non-Block) 10 | - 접두사 Non이 붙었으므로, 부정형이 된다.
11 | 따라서, 블록의 개념과 반대인 미차단이 된다. 12 | 13 | - 차단하지 않는다는 것을 의미하는 바는 아래와 같다.
14 | 함수A, B, C가 있고, 순서가 A -> B -> C라면,
15 | 메인함수가 함수A를 호출한다. 그러면 호출된 함수A는 실행되고,
16 | 바로 리턴하면서, 함수B가 실행된다.
17 | 여기서 리턴이라는 것은 함수A의 로직이 모두 끝난 후가 아닌,
18 | 시작하자마자 리턴한다는 의미다. 19 | 20 | - 동기(Synchronous) 21 | - 블록과 유사하다. 하지만 차이점은 결과를 확인한다는 것이다.
22 | 위에 나와있듯이, 함수를 실행하면 순차적으로 진행되는데,
23 | 블록의 경우에는 함수의 결과가 나왔는지 확인하지 않는 반면,
24 | 동기의 경우에는 확인을 한다. 25 | 26 | - 비동기(Asynchronous) 27 | - 우리가 흔히 알고 있는 멀티스레드의 예가 바로 비동기이다.
28 | 결과 확인과 무관하게 계속 진행된다.
29 | 이 과정에서 여러 context switching이 발생하며,
30 | 전역변수의 경우, 동기처리를 하지 않는다면, 자원이 의도치 않게 섞이게 된다. 31 | 32 | 33 | 34 | - 그림 35 | 36 | ![image](https://user-images.githubusercontent.com/76925405/160278529-d35fa8f4-d77c-4ab3-841a-89d7e31f1a0c.png) 37 | 38 | 39 | - 참고 자료 40 | - https://baek-kim-dev.site/38 41 | - https://hamait.tistory.com/930 42 | - https://suho413.tistory.com/entry/Blocking-NonBlocking-Sync-AnSync-%EC%B0%A8%EC%9D%B4 43 | - https://velog.io/@leehyunho2001/%EB%8F%99%EA%B8%B0-%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%B8%94%EB%9F%AD-%EB%84%8C%EB%B8%94%EB%9F%AD 44 | -------------------------------------------------------------------------------- /OperatingSystem/시스템콜.md: -------------------------------------------------------------------------------- 1 | # System Call 2 | 3 | - 운영체제 구조 4 | 5 | - 커널 모드와 유저 모드 6 | - 인터럽트 vs 시스템콜 7 | 8 | ## 운영체제 구조 9 | 10 | ![image](https://user-images.githubusercontent.com/93963499/160269818-1a74f271-8f02-407b-8b3e-364e224948bb.png) 11 | 12 | 13 | 14 | ### 커널 15 | 16 | 운영 체제에서 **가장 핵심이 되는 프로그램** 17 | 18 | 커널은 CPU 스케줄링, 프로세스 관리, 메모리 관리, 저장장치 관리와 같은 운영체제의 핵심적은 기능을 담당 19 | 20 | **일반 사용자는 커널에 접근할 수 없어서** 커널의 기능을 사용할 수 없는데, **OS의 시스템 콜을 이용하면 가능**하다. 21 | 22 | ### 시스템 콜 23 | 24 | **OS의 기능(커널의 기능)을 요청하기 위해 시스템 콜을 이용한다.** 25 | 26 | `시스템 콜은 커널과 사용자 사이의 인터페이스 역할`을 하며, 쉘에서 명령어나 서브 루틴 형식으로 OS의 기능을 호출한다. 27 | 28 | 보통 시스템 콜을 직접 사용X, 해당 시스템 콜을 사용해서 만든 API를 이용하고 다시 말해 시스템 콜은 운영체제의 기능을 호출하는 함수다. 29 | 30 | 31 | 32 | ## 커널 모드와 유저 모드 33 | 34 | ### 커널 모드와 유저 모드 35 | 36 | 운영체제는 커널 모드와 유저 모드로 나뉘어 구동된다. 37 | 38 | 커널 모드 : 프로세서의 모든 명령 처리하고 자원 컨트롤하는 특권모드(모든 자원에 접근, 명령을 할 수 있음) 39 | 40 | 유저 모드 : 응용 프로그램이 동작하는 비특권모드, 시스템의 자원을 직접 컨트롤 할 수 없고, 이를 하려면 **시스템 콜 사용**해야 함 (유저가 접근할 수 있는 영역을 제한적으로 두고, 프로그램의 자원에 함부로 침범하지 못하는 모드) 41 | 42 | ### 커널 모드와 유저 모드의 전환 43 | 44 | 프로세스가 실행되는 동안에 **프로세스는 수없이 유저 모드와 커널 모드를 왔다 갔다하면서 실행** 45 | 46 | **유저 모드 -> 커널 모드 요청** : 프로세스가 유저 모드에서 실행되다가 커널에 접근하고자 할 때 System call 이용하여 커널에 요청 47 | 48 | **커널 모드 -> 유저 모드 반환** : system call의 요청을 받은 커널이 그 요청에 대한 일을 하고 결과값을 system call의 리턴 값으로 전해줌 49 | 50 | - 모드가 2개인 이유? 커널이 관리하는 하드웨어(자원) 보안을 위해!! 51 | 52 | ## 시스템 콜 vs 인터럽트 53 | 54 | ### 시스템 콜 55 | 56 | os가 사용자(응용프로그램)에게 제공하는 인터페이스 57 | 58 | 인터럽트 중 하나다. -> SW 인터럽트 59 | 60 | - **왜 시스템 콜 필요한가?** 커널을 보호하기 위해, 함부로 접근하지 못하게 하려고 61 | 62 | > 시스템 콜 정리 63 | > 64 | > os가 커널을 보호하기 위해 응용프로그램에게 제공하는 인터페이스가 시스템 콜이다. 65 | > 응용 프로그램은 파일 읽고, 쓰고 등 많은 부분을 커널의 자원을 사용하게 되는데, 유저모드에서 커널모드로 전환하여 커널 기능을 사용 가능하게 도와주는 것이 시스템 콜이다. 66 | 67 | ### 인터럽트 68 | 69 | **프로그램 실행 중, 예외 상황이 발생하는 경우 CPU는 실행중인 작업을 일시 중단하고, 예외 상황을 우선 처리하고 복귀한다.** 70 | 71 | - **인터럽트 왜 필요한가?** 이벤트가 발생했을 때만 CPU에게 알려주고 처리하므로 **CPU가 이벤트 발생 여부를 감시할 필요가 없어진다** -> 다른 연산 수행이 가능하므로 효율이 증가 72 | 73 | #### 인터럽트 종류 74 | 75 | `하드웨어 인터럽트`와` 소프트웨어 인터럽트`가 있다. *하드웨어 인터럽트*는 `내부 인터럽트`와 `외부 인터럽트`로 나뉘게 되는데 *내부 인터럽트*는 프로세서에 정의되어있지 않은 명령을 실행하려 한다거나 0으로 나눗셈을 시도하는 경우를 들 수 있으며 *외부 인터럽트*의 경우 프로그램의 타이머가 지정된 시간이 경과 되었을 경우 등과 같은 이유로 호출된다. 76 | 77 | 소프트웨어 인터럽트의 경우 사용자가 임의로 인터럽트를 호출할 때 발생한다. 78 | 79 | - **하드웨어 인터럽트 (내부 인터럽트 , 외부 인터럽트)** 80 | - **외부 인터럽트** : CPU외부의 **주변 장치로부터**(입출력 장치, 타이머, 전원, 디스크 컨트롤러) **예외상황을 전기적 신호로** 알려준다. 81 | - 전원 이상 인터럽트 : 정전, 파워 이상 82 | - 기계 착오 인터럽트 : CPU의 기능적 오류(CPU는 명령 해석, 연산, 출력의 기능이 있는데, 여기서 오류가 발생하는 경우) 83 | - 외부 인터럽트 84 | - 자원이 할당된 시간이 다 끝난 경우 85 | - 키보드로 인터럽트 키를 누른 경우 (예를 들어, Ctrl + Alt + Delete) 86 | - 외부 장치로부터 인터럽트 요청이 있는 경우 87 | - 입출력 인터럽트 88 | - 입출력장치가 데이터 전송을 요구하거나 전송이 끝나 다음 동작이 수행되어야 할 경우 89 | - 입출력 데이터에 이상이 있는 경우 90 | - **내부 인터럽트** : 프로그램 실행 중, **예외 상황을 처리한다**. 이것을 trap이라고 한다.(?) 91 | - 프로그램 검사 인터럽트 92 | - 0으로 나누는 경우 (Division By Zero) -> 잘못된 명령의 경우 내부 인터럽트 발생 93 | - Overflow / Underflow 94 | - 기타 프로그램 Exception 95 | 96 | - **소프트웨어 인터럽트** : **프로그램 처리 중** **명령의 요청에 의해서** 발생하며, 대표적인 형태는 감시 프로그램 (SVC) 호출 97 | - SVC (SuperVisor Call) 98 | - 사용자가 프로그램을 실행시키거나 감시프로그램을 호출하는 동작을 수행하는 경우(시스템콜) 99 | - 복잡한 입출력 처리를 하는 경우 100 | 101 | #### 인터럽트 처리 과정 102 | 103 | `인터럽트 서비스 루틴(Interrupt Service Routine: ISR)` : 인터럽트를 처리해주기 위한 프로그램, 인터럽트 서비스 루틴은 `인터럽트 핸들러`하고도 한다. 인터럽트핸들러는 커널에 존재하고 응용 프로그램에는 넣지 않는다. 104 | 105 | CPU 에서 인터럽트가 접수되면, 해당 인터럽트 핸들러의 코드의 위치를 찾고 실행에 옮긴다. 실행 중이던 레지스터 와 PC를 보관함으로써 CPU의 상태를 보존한다. 인터럽트가 핸들링이 완료되면 이전의 상태로 복귀된다. 106 | 107 | 108 | 109 | ![image](https://user-images.githubusercontent.com/38436013/129360622-d2ee9e46-be5b-439b-bde4-9cfd8f57b155.png) 110 | 111 | 1) 인터럽트 요청 신호 발생 112 | 2) 현재 실행 중이던 명령어까지 수행하고 프로그램 실행 중단 113 | 3) 다음에 실행할 명령어의 번지 PC에 보관 114 | -> 현재 실행중인 프로그램 상태 보관 115 | 4) 인터럽트 처리 루틴 실행 116 | -> 인터럽트를 요청한 장치 식별 117 | 5) 인터럽트 서비스 루틴 처리 118 | -> 인터럽트 원인 파악 및 작업 수행 119 | -> 우선순위가 더 높은 인터럽트가 발생하면 1) ~ 5)과정 수행 120 | 6) 상태 복구 121 | -> 보관한 PC의 값을 복원 122 | 7) 중단된 프로그램 실행 재개 123 | -> PC의 값을 이용하여 수행중이던 프로그램 계속 실행 124 | 125 | ### 인터럽트와 시스템 콜의 차이는? 126 | 127 | 시스템 콜과 인터럽트는 CPU의 제어권이 특정 프로세스에서 다른 프로세스로 이동한다는 공통점이 있지만, **CPU의 제어권을 변경시키는 주체가 SW인지 HW인지에 따라 나뉜다.** 128 | 129 | ## QnA 130 | 131 | #### 핵심 132 | 133 | - 커널과 시스템 콜 구분 134 | - 유저 모드와 커널 모드에서 시스템 콜 역할 135 | - 인터럽트 개념, 필요성, 동작 흐름, 인터럽트 종류 구분 136 | - 인터럽트와 시스템 콜 차이 137 | - (심화) 인터럽트 발생 과정 예시 설명 138 | 139 | #### 문서 프로그램 작성시 발생하는 인터럽트 과정에 대해 설명해 보시오! (마우스) 140 | 141 | 마우스로 프로그램을 실행한다. 컴퓨터는 인터럽트를 통해 마우스가 움직이고 프로그램을 실행시켰다는 것을 알 수 있고, 이때 하드웨어에서 발생한 인터럽트를 하드웨어 인터럽트라고 한다. 프로그램을 더블 클릭하면, 인터럽트가 걸리고 CPU는 OS(커널)에 있는 인터럽트서비스루틴이 하드디스크를 뒤져서 프로그램을 메인메모리에 가져오고 문서 파일이 모니터에 나타나게 된다. 142 | 143 | 이 프로그램을 실행하다가 사용자가 다른 문서를 읽고 싶은 경우, 소프트웨어 인터럽트를 발생시킨다. OS내부의 인터럽트서비스루틴이 하드디스크에 가서 파일을 읽어와 메인 메모리에 가져온다. 프로그램은 유저 모드에서 실행되고 있으며, 유저 모드에서는 프로그램이 시스템 자원을 사용하려는 경우 시스템 콜을 이용해 명령을 수행한다. 시스템 콜은 커널에서 사용자 모드가 사용 가능하게 해주며, 소프트웨어 인터럽트라고 한다. 144 | 145 | 146 | 147 | ### Reference 148 | 149 | - https://velog.io/@jacob0122/interrupt 150 | 151 | - https://mfamcs.netlify.app/docs/CA_and_OS/%EC%9D%B8%ED%84%B0%EB%9F%BD%ED%8A%B8 152 | 153 | - https://jokergt.tistory.com/65 154 | 155 | - https://ddungkill.tistory.com/85 156 | 157 | - https://gyoogle.dev/blog/computer-science/operating-system/Interrupt.html 158 | 159 | -------------------------------------------------------------------------------- /OperatingSystem/운영체제 파일시스템과 RDBMS.md: -------------------------------------------------------------------------------- 1 | ## 파일 2 | 3 | - 논리적인 저장 단위 4 | - 레코드 혹은 블록 단위로 비휘발성 보조기억장치에 저장된다 5 | 6 | (전원이 끊어진 상황에서도 정보들을 영구히 보존할 수 있다 7 | 8 | 프로그램과 자료로 나누어진다) 9 | 10 | `프로그램` : 소스 프로그램 , 목적 프로그램으로 나누어 진다 11 | 12 | `자료` : 숫자 문자 이진수 등 저장할 수 있는 모든 것이 자료가 된다 13 | 14 | ### 파일의 속성 15 | 16 | - 이름 17 | - 식별자 18 | - 타입 19 | - 위치 20 | - 크기 21 | - 보호 여부 22 | - 시간 , 날짜 23 | 24 | ### 파일의 구조 25 | 26 | `필드` : 데이터 항목 27 | 28 | `레코드` : 대상과 관련된 필드들의 집합 29 | 30 | ## 파일 시스템 31 | 32 | ![파일시스템](https://user-images.githubusercontent.com/42866800/160276136-aa3af75e-0aeb-423b-ba94-149f97c4f8b3.png) 33 | 34 | - 파일 , 파일의 메타데이터 , 디렉터리 정보를 관리한다 35 | - 운영체제 , 데이터 , 프로그램이 파일을 저장하고 접근하기 위한 기법을 제공하는 시스템 36 | - 데이터나 프로그램을 디스크에 쓰고 읽을 수 있게 해주는 프로그램 37 | - 파일과 디스크 블록간 연결작업 처리 38 | - 메모리는 바이트 단위로 읽어들일수 있지만 디스크는 바이트 단위로 읽어 들일수 없는 구조이다 39 | 40 | ### 파티션 41 | 42 | - 저장공간을 독립적인 영역으로 나누어 사용할 수 있도록 정의한 규약 43 | - 하나의 물리적 디스크 안에 여러 파티션을 두는 경우가 일반적 44 | - 여러 물리적 디스크를 하나의 파티션으로 구성하기도 한다 45 | 46 | ![디렉토리와 파티션](https://user-images.githubusercontent.com/42866800/160276152-988ad836-a3b0-4cd9-8910-39edb483a6f1.png) 47 | 48 | ## 디렉토리 49 | 50 | - 하나의 파일시스템에서 서로 연관된 파일들을 한곳에 체계적으로 저장될 수 있도록 한다 51 | - 디스크에 저장되어 있는 파일들을 보다 효율적으로 관리하기 위해 사용 52 | 53 | ### 트리 구조 디렉터리 54 | 55 | ![트리 구조 디렉토리](https://user-images.githubusercontent.com/42866800/160276176-212d5759-cf37-4ca1-bb5f-e1586c0326f6.png) 56 | 57 | - DOS, Windows, UNIX 등의 운영체제에서 사용되는 디렉터리 구조이다. 58 | - 각 디렉터리는 서브디렉터리나 파일을 가질 수 있다. 59 | - 서로 다른 디렉터리 내에 동일한 이름의 파일이나 디렉터리를 생성할 수 있다. 60 | - 디렉터리의 생성과 파괴가 비교적 용이하다. 61 | - 디렉터리의 탐색은 포인터를 사용하며, 경로명은 절대 경로명과 상대 경로명을 사용한다. 62 | 63 | ## 왜 파일 시스템을 쓰지 않고 DBMS를 만들어냈을까 64 | 65 | ### 데이터의 형식이나 내용을 프로그램과 상관없이 쉽게 변형가능 66 | 67 | - 데이터의 무결성을 유지하기 어렵다 68 | - 무결성 - 데이터가 얼마나 정확한다 69 | 70 | ### 프로그램이 데이터 파일에 종속된다 71 | 72 | - 프로그램이 새로운 데이터 항목을 추가하거나 수정이 필요한 경우 73 | - 다른 프로그램도 기능과 상관없이 프로그램을 수정해야 한다 74 | - 예) 파일 경로를 바꾸면 작동이 안되는 프로그램 75 | 76 | ### 두가지 프로그램이 하나의 데이터를 공유할 수 있다 77 | 78 | - 하지만 동시 접근이 허용되지 않는다 79 | - 스케줄러를 통해 관리되어야 한다 80 | 81 | ### 참고 82 | 83 | [https://vmilsh.tistory.com/388](https://vmilsh.tistory.com/388) 84 | 85 | [https://vmilsh.tistory.com/388](https://vmilsh.tistory.com/388) 86 | 87 | [https://rebro.kr/181](https://rebro.kr/181) 88 | 89 | [https://jess2.tistory.com/86](https://jess2.tistory.com/86) 90 | 91 | [https://luv-n-interest.tistory.com/555](https://luv-n-interest.tistory.com/555) 92 | 93 | [https://luv-n-interest.tistory.com/555](https://luv-n-interest.tistory.com/555) 94 | 95 | [https://moolgogiheart.tistory.com/tag/목적코드](https://moolgogiheart.tistory.com/tag/%EB%AA%A9%EC%A0%81%EC%BD%94%EB%93%9C) 96 | 97 | [https://untitledtblog.tistory.com/59](https://untitledtblog.tistory.com/59) 98 | 99 | [https://operatingsystems.tistory.com/entry/OS-File-System-1](https://operatingsystems.tistory.com/entry/OS-File-System-1) 100 | -------------------------------------------------------------------------------- /OperatingSystem/운영체제_메모리_구조.md: -------------------------------------------------------------------------------- 1 | # 메모리 구조 2 | 3 | ## 스택 동작 과정 4 | 5 | - 함수 호출과 관계된다 6 | - 지역변수와 매개변수 , 함수의 복귀주소 , 반환값을 저장 7 | - 함수의 호출과 함께 할당되면 함수 호출이 완료되면 소멸한다 8 | - 스택은 푸시 동작으로 데이터를 저장하고 팝 동작으로 데이터를 꺼낸다 9 | - 후입선출 (LIFO) 방식에 따라 동작한다 10 | - 가장 늦게 저장된 데이터가 가장 먼저 인출된다 11 | - `stack overflow` - 재귀함수가 반복되거나 지역변수가 너무 많으면 발생 12 | 13 | ![운영체제 구성_1](https://user-images.githubusercontent.com/42866800/159283086-3c1635f3-91f9-4128-9b96-5bcaf4102025.png) 14 | 15 | ```java 16 | 1. 함수 호출 17 | 2. 호출된 함수를 푸시 18 | 3. 함수 호출이 완료되면 해당 함수를 팝 19 | ``` 20 | 21 | ## stack 과 heap 22 | 23 | `힙 영역` 24 | 25 | - 필요에 의해 동적으로 메모리를 할당 할 때 사용 26 | - 객체와 배열이 생성되는 공간 27 | - 참조타입 (배열 , 열거 , 클래스 , 인터페이스)를 힙영역에 주소 형식으로 저장한다 28 | - 크기가 정해져 있지 않은 타입이다 29 | - 프로그램을 실행할 때 메모리를 빌려 동적으로 할당한다 30 | - 자바에서는 new 키워드를 통해 동적 메모리를 할당한다 31 | 32 | `동적 메모리 할당` 33 | 34 | - new를 통해 배열의 크기를 지정하고 인스턴스를 생성하여 힙 메모리에 할당 35 | - JVM의 가비지 컬렉터가 사용하지 않는 메모리를 자동으로 분류하여 프로그램 종료시 해제해 준다 36 | 37 | `stack 영역` 38 | 39 | - 지역변수 , 매개변수 , 반환값 등이 저장되는 공간 40 | - LIFO(후입선출)을 따른다 41 | - 데이터를 push - pop 하여 사용한다 42 | - 왜? 43 | - 스택 메모리 주소가 높은 주소에서 낮은 주소 방향으로 할당되기 때문 44 | - 특별히 메모리를 수거하거나 지우는 작업은 필요하지 않다 45 | 46 | ## 프로세스와 스레드에서의 스택 47 | 48 | ### 프로세스 49 | 50 | - 실행중인 프로그램 51 | - 운영체제로 부터 주소공간 , 파일, 메모리 가 필요하다 52 | - 운영체제로 부터 이를 할당받은 프로그램 53 | 54 | `프로그램 vs 프로세스` 55 | 56 | - 프로그램 : 어떤 작업을 수행하기 위한 파일 57 | - 프로세스 : 작업을 수행하는 동적인 상태 58 | 59 | ### 프로세스 메모리 구조 60 | 61 | ![힙 스택 떨어진 구조도](https://user-images.githubusercontent.com/42866800/159283158-33eaa1d9-a2a5-4c2c-8c24-328af5794a92.png) 62 | 63 | - 코드 : 실행 가능한 명령어들이 포함된 코드가 정의되어 있다 64 | - 데이터 : 초기값이 있는 전역 변수가 정의 65 | - 힙 : 실행 시간에 동적으로 할당되는 메모리 공간 66 | - 스택 : 함수 내 사용되는 지역변수가 정의되는 공간 67 | - 함수의 호출이 완료되면 소멸 68 | - 프로그램이 사용하는 임시 메모리 영역 69 | 70 | ### 스레드 71 | 72 | - 프로세스 내에서 실행되는 흐름의 단위 73 | - CPU에 작업을 요청하는 실행 단위 74 | - 같은 프로세스에 속한 다른 스레드와 코드 , 데이터 , 파일 과 같은 운영체제 자원을 공유한다 75 | 76 | ![운영체제구성_3](https://user-images.githubusercontent.com/42866800/159283250-01087ad9-b4d5-4e79-8ab2-c2b54ef80d8b.png) 77 | - 스레드에 스택만 따로 할당하는 이유 78 | - 스레드는 독립적인 작업을 수행해야 하기 때문에 각각 스택과 PC 레지스터를 별도로 갖고 있다 79 | - 스레드 마다 독립적으로 함수 호출이 가능하기 때문 80 | 81 | 88 | 89 | - PC 레지스터를 스레드마다 독립적으로 할당하는 이유 90 | - 스레드는 CPU를 할당받았다가 스케줄러에게 다시 선점당한다 91 | - 명령어가 어디 까지 수행되었는지 기억하기 위해 각 스레드 마다 PC 레지스터를 독립적으로 할당한다 92 | 93 | ## **Q&A** 94 | 95 | ### **스택과 힙가 메모리 구조상에서 떨어져 있는 이유** 96 | 97 | ![힙 스택 전체 구조도](https://user-images.githubusercontent.com/42866800/159283312-de34a5e9-cb78-4a6e-8765-2892fbf840d1.png) 98 | 99 | - 스택 영역은 메모리의 높은 주소에서 낮은 주소의 방향으로 할당된다 100 | - 가장 아래 부터 차곡차곡 위의 방향으로 데이터가 쌓인다 101 | - 힙 영역은 메모리의 낮은 주소에서 높은 주소의 방향으로 할당된다 102 | - 위 부터 차곡차곡 아래 방향으로 데이터가 쌓인다 103 | - 힙 영역은 선입선출(FIFO) 방식으로 가장 먼저 들어온 데이터가 가장 먼저 인출 된다 104 | - 스택 영역은 후입선출(LIFO) 방식으로 가장 나중에 들어온 데이터가 가장 먼저 인출 된다 105 | 106 | ### 오버플로우 (**스택 오버플로우 vs 힙 오버플로우)** 107 | 108 | ![오버플로우](https://user-images.githubusercontent.com/42866800/159283366-1b048e07-e5ca-4dde-b8a7-6981e5bcb1d6.png) 109 | 110 | - 넘쳐 흐른다 111 | - 한정된 메모리 공간이 부족하여 메모리 안에 있는 데이터가 넘쳐 흐르는 현상 112 | - 힙 오버플로우와 스택 오버플로우가 있다 113 | - 힙은 메모리 위쪽 주소부터 할당되고 스택은 메모리 아래쪽 주소부터 할당되기 때문에 각 영역이 상대 공간을 침범하는 일이 발생할 수 있다 114 | - 힙이 스택을 침범하는 현상을 힙 오버풀로우 라고한다 115 | - 스택이 힙을 침범하는 경우를 스택 오버플로우 라고 ㅎ나다 116 | 117 | ### 가비지 컬렉터가 언제 메모리를 수거해 가는지 118 | 119 | - 자바의 경우 프로그램 실행 중 JVM의 가비지 컬렉터가 불필요한 메모리를 알아서 정리해 준다 120 | - 명시적으로 불필요한 데이터를 표현하기 위해 null 사용 121 | - 즉 더이상 참조되지 않는 객체를 주기적으로 검사하여 메모리를 청소해 준다 122 | - JVM이 종료되면 사용하던 메모리는 OS에게 반납된다 123 | 124 | ## **참고** 125 | 126 | [https://zangzangs.tistory.com/107](https://zangzangs.tistory.com/107) 127 | 128 | [https://velog.io/@nnnyeong/OS-프로세스와-스레드-Process-VS-Thread](https://velog.io/@nnnyeong/OS-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C-Process-VS-Thread) 129 | 130 | [https://narakit.tistory.com/18](https://narakit.tistory.com/18) 131 | 132 | [https://dsnight.tistory.com/50](https://dsnight.tistory.com/50) 133 | 134 | [https://junghyun100.github.io/힙-스택차이점/](https://junghyun100.github.io/%ED%9E%99-%EC%8A%A4%ED%83%9D%EC%B0%A8%EC%9D%B4%EC%A0%90/) 135 | 136 | [[자료구조] 메모리 구조와 동적 할당 - 프로그래밍 언어별로 어떻게 다를까? - C/C++/Java/Python (tistory.com)](https://meoru-tech.tistory.com/25) 137 | 138 | [메모리의 구조 (코드, 데이터, 힙, 스택 영역) (tistory.com)](https://all-young.tistory.com/17) 139 | 140 | [코딩의 시작, TCP School](http://www.tcpschool.com/c/c_memory_structure) 141 | 142 | [https://all-young.tistory.com/17](https://all-young.tistory.com/17) 143 | 144 | [https://mangkyu.tistory.com/118](https://mangkyu.tistory.com/118) 145 | 146 | [https://yaboong.github.io/java/2018/05/26/java-memory-management/](https://yaboong.github.io/java/2018/05/26/java-memory-management/) 147 | 148 | [https://yaboong.github.io/java/2018/06/09/java-garbage-collection/](https://yaboong.github.io/java/2018/06/09/java-garbage-collection/) 149 | 150 | [https://blog.wanzargen.me/15](https://blog.wanzargen.me/15) 151 | -------------------------------------------------------------------------------- /OperatingSystem/운영체제와 컴퓨터 시스템 구조/images/img.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/운영체제와 컴퓨터 시스템 구조/images/img.png -------------------------------------------------------------------------------- /OperatingSystem/운영체제와 컴퓨터 시스템 구조/images/img_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/운영체제와 컴퓨터 시스템 구조/images/img_1.png -------------------------------------------------------------------------------- /OperatingSystem/운영체제와 컴퓨터 시스템 구조/운영체제와 컴퓨터 시스템 구조.md: -------------------------------------------------------------------------------- 1 | # 2 | 3 | ![](images/img.png) 4 | 5 | **CPU** 6 | 7 | - 구성 8 | - ALU(산술논리 장치) 9 | - CU(컨트롤 장치) 10 | - Register(레지스터) 11 | - 주요 기능 12 | - 명령어를 실행하기 위해 데이터를 가져오고(fetch) 명령어를 해석하고(decode), 실행(execute) 13 | 14 | **Memory (주 기억장치)** 15 | 16 | - ROM, RAM 17 | --- 18 | 19 | ![](images/img_1.png) 20 | 21 | **Mode bit** 22 | 23 | CPU에서 실행되는 것이 OS인지 사용자 프로그램인지 구분해주는 역할 24 | 25 | - 1 사용자 모드: 사용자 프로그램 수행 26 | - 0 모니터 모드: OS 코드 수행 27 | 28 | **Timer** 29 | 30 | 정해진 시간 흐른 뒤 운영체제에게 제어권이 넘어가도록 인터럽트 발생시킨다. 31 | 32 | - CPU를 특정 프로그램이 독점하는 것 방지 33 | 34 | **Device Controller** 35 | 36 | - 해당 I/O device을 관리하는 일종의 작은 CPU 37 | - Devide Controller는 I/O가 끝났을 경우 인터럽트로 CPU에 알린다. 38 | 39 | **Local Buffer** 40 | 41 | Device Controller로부터 들어오고 나가는 데이터를 임시로 저장하기 위한 작은 메모리 공간 42 | 43 | **DMA Controller** 44 | 45 | 디바이스 작업 완료 후, local buffer의 내용을 직접 memory로 복사후 CPU에 인터럽트 46 | 47 | **DMA(Direct Memory Access)** 48 | 49 | CPU가 각각의 I/O디바이스를 통해 데이터를 읽어 메모리에 저장하는 것은 CPU 효율 떨어지기 때문에, 주변 기기 인터페이스 장치에 제어권을 주어 직접 메모리에 데이터를 주고 받는 방식으로 엑세스하여 데이터를 전송하는 방법 50 | 51 | **운영체제란?** 52 | 53 | - 응용 프로그램과 하드웨어 사이 인터페이스 역할을 하며 시스템 동작을 제어하는 시스템 소프트웨어 54 | - 즉, 시스템의 자원과 동작을 관리하는 소프트웨어 55 | - 프로세스 관리 56 | - 저장장치 관리 57 | - 네트워킹 58 | - 사용자 관리 59 | - 디바이스 드라이버 60 | 61 | **프로그램 실행 흐름** 62 | 63 | 1. **전원을 키면 메모리에 운영체제가 올라간다.** 64 | 1. 운영체제 코드 전부 올라가는 것은 아니고, 커널 코드만 올라간다. 65 | 2. 최소 시스템 실행을 목적 66 | 67 | 2. **CPU는 운영체제 실행** 68 | 69 | 3. **사용자 프로그램 실행** 70 | 1. 메모리에 프로그램 올라간다. 71 | 2. CPU는 메모리의 명령어 주소를 레지스터에 저장(PC 레지스터) 72 | 3. 이 후 각 프로그램들은 I/O 디바이스 사용이 필요할 수 있는데 이러한 요청은 운영체제에 요청 73 | 4. 이러한 요청을 시스템 콜 74 | 5. 프로그램들이 직접 I/O 디바이스 제어하지 않는 이유는? 가장 큰 이유= 보안 75 | 76 | 4. **프로그램의 요청 받은 운영체제는 I/O Device Controller에게 데이터 입출력 처리 요청** 77 | 1. 컨트롤러는 입출력 받기 되면 인터럽트 발생시켜 CPU에게 작업 완료 알리게 된다. 78 | 2. CPU는 버퍼에 가서 데이터를 읽어와 메모리에 올린다(DMA Controller가 수행) 79 | --- 80 | **CPU와 I/O 연산** 81 | 82 | - 컴퓨터 연산은 CPU가 처리 83 | - I/O 디바이스 연산은 각각의 디바이스 컨트롤러가 처리 84 | - 디바이스 컨트롤러= 디바이스의 CPU 역할 85 | - 따라서, 컴퓨터 연산 I/O 연산 동시에 처리 가능하다. 86 | 87 | **Memory와 Local Buffer** 88 | 89 | - 디바이스 컨트롤러로부터 들어오고 나오는 데이터들은 로컬 버퍼에서 관리한다. 90 | - 로컬 버퍼는 메모리와 같은 역할 91 | - 데이터가 입출력은 CPU가 처리하는게 아니라, 92 | - 각 디바이스 컨트롤러들이 연산을 하고 CPU에게 인터럽트 발생시켜 보고 93 | - CPU는 항상 메모리에 명령어를 읽어와 작업을 수행하는데, 94 | - 명령어를 읽어오기 전에 인터럽트 발생했는지 확인 95 | - 인터럽트가 발생했으면 인터럽트를 먼저 처리하고 그 이후에 명령어 처리한다. -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 1.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 2.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 3.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 4.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled 5.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/주소 바인딩과 스와핑/주소 바인 6e0c3/Untitled.png -------------------------------------------------------------------------------- /OperatingSystem/주소 바인딩과 스와핑/주소 바인딩과 스와핑.md: -------------------------------------------------------------------------------- 1 | # 주소 바인딩과 스와핑 2 | 3 | **주소 바인딩이란?** 4 | 5 | - 주소 할당 6 | - 메모리 주소를 언제 어떻게 결정하느냐!! 7 | - 3가지 방법 8 | - 컴파일 타임 바인딩(complile time binding) 9 | - 로드 타임 바인딩(load time binding) 10 | - 런 타임 바인딩(exectuion time binding) 11 | 12 | --- 13 | 14 | **컴파일 타임 바인딩** 15 | 16 | - 말 그대로, 컴파일 하면 메모리 주소 결정 됨 17 | - 쉽게 말해, 프로그램 내부 사용하는 주소= 메모리 주소(물리 주소) 18 | - 어디서 사용? 임베디드 시스템 19 | - 멀티프로그래밍 X 20 | 21 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled.png) 22 | 23 | **로드 타임 바인딩** 24 | 25 | - 로딩할 때 메모리 주소(물리 주소) 결정 26 | - 프로그램 내부 사용하는 주소≠ 메모리 주소 27 | - 멀티프로그래밍 O 28 | - 로딩 타임: 상대 주소→ 실제 주소 변환 걸리는 시간(ex) 980000 + 1000000→ 1980000) 29 | - 로딩타임이 길다→ 오버헤드 30 | 31 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled%201.png) 32 | 33 | **런 타임 바인딩** 34 | 35 | - 실행할 때 주소 결정 36 | - 프로그램 내부 사용하는 주소≠ 메모리 주소 37 | - 멀티 프로그래밍 O 38 | - 하드웨어 MMU(메모리 관리 장치)가 대신 상대 주소→ 실제 주소 변환 39 | 40 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled%202.png) 41 | 42 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled%203.png) 43 | 44 | **로딩 타임 바인딩과 런 타임 바인딩의 차이** 45 | 46 | - 로딩 타임 바인딩 47 | - 메모리에 로딩할 때 주소 변환 작업을 미리 수행 48 | - 런 타임 바인딩 49 | - 프로그램 실행해서 코드가 실행될 때마다 주소 변환 작업 수행 50 | - 미리 주소 변환하고 계속 해당 주소 access 하는게 효율적이지 않나? 로드 타임이 좋은거 아니야? 51 | - 하드웨어 성능(MMU)이 너무 좋아져서, 런 타임 실행 시 문제 없다. 52 | - 로드 타임일 경우, OS가 loading→ overhead가 크다. 53 | - 따라서, 런 타임 바인딩이 짱! 54 | 55 | --- 56 | 57 | **swap이란?** 58 | 59 | - 프로그램 전체를 메모리에 올려 두는 것이 아니라 60 | - 그때 그때 필요한 것들만 메모리에 올리고, 61 | - 필요 없어지면 디스크로 내보내는 동작 62 | 63 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled%204.png) 64 | 65 | ![Untitled](%E1%84%8C%E1%85%AE%E1%84%89%E1%85%A9%20%E1%84%87%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AB%206e0c3/Untitled%205.png) 66 | 67 | --- 68 | 69 | 참고 70 | 71 | [https://www.youtube.com/watch?v=5pEDL6c--_k](https://www.youtube.com/watch?v=5pEDL6c--_k) 72 | [https://jhnyang.tistory.com/133](https://jhnyang.tistory.com/133) -------------------------------------------------------------------------------- /OperatingSystem/질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 내용 질문 2 | 3 | ### **OS 개요** 4 | 5 | - 운영체제와 운영체제의 주요 기능을 설명해 주세요. 6 | - 7 | - 카톡 부팅 과정을 os와 연관지어 설명하시오. 8 | - 한컴 오피스 '한글'을 클릭 후 빈 화면에 커서가 깜빡인다. 이때 Hello world를 작성하면 컴퓨터 내부에 무슨 일이 일어나는가? 9 | 10 | ### **CPU 스케줄링** 11 | 12 | - 스케줄링 무엇인지와 목적을 설명 13 | - 비선점방식과 선점방식 설명 14 | - 라운드 로빈 스케줄링이란? 15 | - 스케줄링 기법 중 fcfs 의 단점과 해결 방안을 설명하시오. 16 | 17 | ### **프로세스와 스레드** 18 | 19 | - 프로그램과 프로세스, 스레드를 설명 20 | - 프로세스가 도중에 중지되는 경우, 그 원인과 다시 실행할 수 있는 방법은 무엇일까요? 21 | - 프로세스의 힙, 스택 영역에는 어떤 정보가 있나요? 22 | - 프로세스와 스레드 자세히 설명 23 | - 스레드가 메모리 공유하는 이유 24 | - 스택을 스레드마다 독립적으로 할당하는 이유가 무엇인가요? 25 | - PC Register를 스레드마다 독립적으로 할당하는 이유 26 | - 스레드와 멀티 스레드의 차이에 대하여 설명하고, 멀티 스레드의 장단점을 설명해보세요. 27 | - 멀티 스레드와 멀티 프로세스의 차이를 말해주세요. 28 | - 멀티 프로세스 대신 멀티 스레드 사용하는 이유 29 | - 멀티 스레드 적용한 어플리케이션 예시 (Multi-threaded applications example) 30 | - 컨텍스트 스위칭 설명 31 | - 컨텍스트 스위칭 비용은 프로세스와 스레드 중 어디가 더 클까? 32 | - 멀티 코어와 멀티 프로세스, 병렬 처리 용어 33 | - 컨텍스트 스위칭 발생할 때, pc 값을 레지스터에 보관하는 이유 34 | - 프로세스 메모리 구조는 코드, 데이터, 스택, 힙이 있다. 각 구역의 특징은? 35 | - 프로세스 메모리 구조에서 스택과 힙의 차이 및 특징은? 36 | - PCB에 저장되는 정보는 어떤 것이 있으며, 어떻게 관리될까? 37 | 38 | ### **커널, 인터럽트** 39 | 40 | - 커널이란? 41 | - 커널 모드와 유저 모드 구분하는 이유? (이중 모드의 특징과 장점) 42 | - 인터럽트에 대해 설명해보시오. 43 | - 인터럽트와 시스템콜(=트랩) 비교 44 | - 인터럽트 발생 원인 45 | - 문서 프로그램 작성시 발생하는 인터럽트 과정에 대해 설명해 보시오! (마우스) 46 | 47 | ### **병행성(상호배제, 동기화, 교착상태, 기아)** 48 | 49 | - DeadLock의 발생 조건과 DeadLock을 깨기 위해 어떻게 해야 하나요? 50 | - race condition(경쟁 상태)에 대하여 간단한 예시를 들어 설명해주세요 51 | - OS에서 경쟁 상태 발생하는 경우 설명 52 | - 여러 프로세스가 가 데이터를 공유하며 수행될 때, 각 프로세스에서 공유 데이터를 접근하는 프로그램 코드를 무엇이라 부르나요? 그리고 그에 대한 간단한 설명 부탁드립니다. 53 | - 임계 영역을 프로세스들이 같이 쓸 수 있는 전제 조건을 설명해주세요. 54 | - 프로세스 동기화란 무엇인가요? 55 | - 임계 구역 해결 방법을 설명하시오 56 | - Mutex Lock 과 Semaphore 의 차이 57 | - Mutex Lock 와 Monitor의 차이 58 | - Semaphore와 Monitor 차이 59 | - 교착 상태? 60 | - 교착 상태에는 어떤 기법들이 있으며 각각 어떤 역할을 하는가? 61 | - 교착상태 vs 기아상태 62 | - 운영체제에서 에이징(Aging)는 무엇입니까? 63 | - Swapping이 무엇인가? 64 | 65 | ### **메모리 관련 전략** 66 | 67 | - 메모리 구조의 순서가 어떻게 되는지 cpu에서 가까운 순서로 말해보세요 68 | - 메모리 관리란? 왜 할까요? 69 | - RAM을 늘리면 어떻게 되나요? 70 | - 컴퓨터의 속도를 빠르게 하고 싶으면 무작정 RAM 늘리면 될까요? 71 | - 만약 16GB의 메인 메모리를 가지고 있고, 운영체제의 용량이 16GB라고 해보자. 그럼 이 컴퓨터는 운영체제 외에 다른 프로그램은 실행할 수 없는 것인가? 72 | - 메모리 할당(연속 메모리, 비연속 메모리)을 설명해 주세요. 73 | - 메모리 할당 알고리즘의 각 특징을 설명해 주세요.(first-fit, best-fit, worst-fit) 74 | - 논리주소와 물리주소 75 | - 컴파일 타임 바인딩, 적재 타임 바인딩, 실행 타임 바인딩을 간단히 설명하시오 76 | - 외부 단편화와 내부 단편화를 설명하시오. 77 | - 외부 단편화 해결하기 위한 전략은? 78 | - 외부 단편화가 발생할 때마다 압축을 시행하는가? 79 | - 압축 외에 외부 단편화를 해결하는 방안은? 80 | - 페이징의 장점과 단점은? 81 | - 메모리 단편화 해결 기법에 대해 설명하시오. 82 | - 페이지 교체 알고리즘 중 3가지를 선택해서 설명해주세요. 83 | - swapping에서 swap-out 하는 경우, 프로그램 상태로 backing-store 하는가? 84 | 85 | ### **가상 메모리** 86 | 87 | - 가상메모리의 역할은 무엇인가요? 장단점은? 88 | - 가상 메모리를 효율적으로 관리하는 방법은 어떤 것들이 있을까요? 89 | - Page Fault에 대해 설명하시오 90 | - 페이지를 교체하는 방법들을 설명해보시오 91 | - Demand Paging(요구 페이징)에 대해 설명하시오 92 | - 페이지 적중율을 극대화 시키기 위한 방법은 무엇이 있는가? 93 | - Cache 메모리를 사용하는 이유 94 | - 페이지들을 할당하려고 하는데 프레임이 매우 커서 편하게 페이지가 할당될 수 있는 상황을 가정해봅시다. 이 상황이 무조건적으로 이득일까요? 만약 아니라면 어떤 상황에서 이득이 아닐지 의견을 듣고 싶어요. 95 | - 최적의 교체 알고리즘인 OPR(Optimal Page Replacement)가 현실적으로 가능할까요? 전제조건이 있어도 괜찮습니다. 또한 실생활에서 쓰일 수 있을까요? 96 | - 리눅스 운영체제에서는 어떤 페이지 교체 알고리즘을 사용할까요? 자신이 생각하는 이유와 함께 알고리즘을 설명해주세요. 97 | 98 | ### **그 외 질문들** 99 | 100 | - 함수 호출과 시스템 콜 차이 101 | - symchromized에 대해 아는 바를 전부 설명하세요 102 | - Synchronous 와 Asynchronous의 차이점 103 | - Blocking 과 Non-Blocking의 차이점 104 | - 캐시와 레지스터의 차이 105 | - Mapping Function (MMU와 관련하여 설명) 106 | - DMA 존재 이유를 설명하시오 107 | - 운영체제는 다중 유저가 하나의 컴퓨터 자원을 사용할 때 자원의 '보호'를 한다. 어떠한 '보호'를 하는지 설명하고 시나리오를 설명하시오 108 | - os에서 프로세스는 cpu와 메모리 사이에 MMU를 두어서 다른 프로세스에 접근하지 못한다. 그러나 GDB와 같은 디버거의 경우 다른 프로세스에 접근하여 절대적 메모리 주소와 값을 읽어올 수 있다. 어떻게 가능한지 동작 방식에 대해 설명하시오 109 | - 마우스로 한글 바로가기를 클릭했을 때 컴퓨터에서 일어나는 모든 일에 대해 설명하시오 ( Points: Interrupt, Process Scheduling, Disk Scheduling, Swapping, Thread). 110 | 111 | ## 심화 내용 질문 112 | 113 | ### 스레드 114 | 115 | - 멀티스레드의 특징을 자세히 설명해 주세요(공유 자원에 대한 동기화) 116 | 117 | - 자바에서의 스레드 118 | - 스레드 풀 119 | - 동시성 이슈 120 | 121 | - Thread-safe에 대하여 설명해 주세요. 122 | 123 | ### 파일 시스템 124 | 125 | - 파일시스템이 필요한 이유 126 | - 연속 할당, 연결 할당, 색인 할당 -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성.md: -------------------------------------------------------------------------------- 1 | # 캐시 2 | 3 | - 속도가 빠른 장치와 느린 장치간의 속도 차에 따른 병목현상을 줄이기 위한 메모리 4 | 5 | 6 | 7 | - 메모리에서 자주 사용하는 프로그램과 데이터를 저장해두어 속도를 빠르게 하는 메모리 8 | - 메모리보다 물리적으로 CPU에 가까움 9 | - 메모리보다 크기가 작아 탐색범위가 작음 10 | 11 | ## 캐시의 종류 12 | 13 | - L1 Cache: 프로세서와 가장 가까운 캐시. 속도를 위해 I$와 D$로 나뉜다. 14 | - Instruction Cache (IL1): 메모리의 TEXT 영역 데이터를 다루는 캐시. 15 | - Data Cache (DL1): TEXT 영역을 제외한 모든 데이터를 다루는 캐시. 16 | - L2 Cache: 용량이 큰 캐시. 크기를 위해 L1 캐시처럼 나누지 않는다. 17 | - L3 Cache: 멀티 코어 시스템에서 여러 코어가 공유하는 캐시. 18 | 19 | 20 | 21 | ## 캐시의 성능 22 | 23 | - Hit: CPU에서 요청한 데이터가 캐시에 존재하는 경우를 캐시 24 | - Hit latency: `Hit`가 발생해 캐싱된 데이터를 가져올 때 소요되는 시간 25 | - Miss: CPU에서 요청한 데이터가 캐시에 존재하지 않는 경우를 캐시 26 | - Miss latency: `Miss`가 발생해 상위 캐시에서 데이터를 가져오거나(L1 캐시에 데이터가 없어서 L2 캐시에서 데이터를 찾는 경우) 메모리에서 데이터를 가져올 때 소요되는 시간 27 | 28 | ### 캐시의 성능향상 29 | 30 | - 캐시의 크기를 줄여 `Hit latency` 줄이거나 / 캐시의 크기를 늘려 `Miss latency`를 줄임 31 | - 캐시의 크기는 적당하고 `Hit`가 높여야 함 32 | 33 | ## 캐시의 지역성 34 | 35 | - 데이터를 균일하게 액세스하는 것이 아니라, 어느 순간에 특정부분을 집중적으로 참조하는 특징 36 | - `Hit`를 높이기위해 CPU가 `자주 사용하는 특정부분`을 캐시에 저장 37 | - 시간 지역성: 최근 접근한 데이터에 다시 접근하는 경향 38 | - 공간 지역성: 최근 접근한 데이터의 주변 공간에 다시 접근하는 경향 39 | 40 | ## 캐시의 쓰기 41 | 42 | | 구분 | Write Through | Write Back | 43 | | ------------------ | ------------------------------------ | ------------------------------- | 44 | | 쓰는시점 | 캐시와 메모리에 동시에 쓰기 | 캐시에서 데이터가 삭제될때 쓰기 | 45 | | 캐시와 메모리 일치 | 불일치 없음 | 일시적 불일치 발생 | 46 | | 속도 | 느림(쓰는작업에 대해서 캐시장점없음) | 빠름 | 47 | 48 | ### Write Back의 불일치 해결 49 | 50 | - 메모리 MMU의 Page Table을 Cacheable - Non Cacheable 영역 설정 51 | - DMA와 Cache의 데이터의 불일치 발생 52 | - Cache Invalidate: cache의 데이터를 삭제하고 메모리값을 다시 불러옴 -> cache의 데이터가 잘못된 경우 53 | - Cache Flush: cache의 데이터를 메모리에 기록 -> cache의 데이터가 정상적인 경우 54 | - DMA(Direct Memory Access) Controller: 데이터 전송(쓰기) 작업을 CPU를 대싱하여 수행해주는 장치 55 | - CPU는 DMA에게 기록할 `source`(내용), `destination`(기록할 위치), 바이트수만 전달함. 56 | 57 | ## MMU(Memory Management Unit) 58 | 59 | CPU가 인지하고있는 가상 메모리 주소를 실제 물리메모리 주소로 변환해주는 장치 60 | 61 | - cache, DMA 둘은 모두 MMU를 통하여 물리적 메모리주소를 받음 62 | - Page Table: Virtual Address와 Physical Address를 연결해 주는 Table 63 | - TTB(Translation Table Base Address): Table이 존재하는 위치가 저장되어있는 레지스터 64 | 65 | ### 메모리 접근 과정 66 | 67 | 68 | 69 | 1. CPU는 Memory의 어딘가를 Access하기 위해서 Virtual Address를 발생 70 | 2. MMU는 이 Virtual Address를 받아서 Memory의 TTB에서부터 시작해서 존재하는 Page Table에 접근 71 | 3. 찾아간 Page Talbe안에 Physical 주소를 찾아내어 주소 신호를 발생 72 | 4. Memory는 해당 Physical 주소안에 Data를 출력해서 CPU에게 전달 73 | 5. Data가 CPU에 전달 됨. 74 | 75 | ### Virtual Address 76 | 77 | - 프로세스의 메모리를 page 단위로 쪼갬 78 | - 실제 physical 메모리도 page frame단위로 쪼갬 79 | - page table이 쪼개진 page끼리 매칭시킴 80 | - 물리적으로 떨어져있는 메모리도 연결된것처럼 사용이 가능함 81 | 82 | 83 | 84 | ### Hierarchy page table 85 | 86 | - 메모리가 커질수록 페이지 테이블의 영역도 증가함 87 | - 사용하지 않는 page를 제외하고 page table을 생성함 88 | 89 | 90 | 91 | - hierarchy 사용시 virtual address의 주소 구조 92 | 93 | - ex)대한민국 경기도 성남시 중원구 0000번지 94 | 95 | 96 | 97 | ## QnA 98 | 99 | ### 캐시와 DMA의 데이터 불일치시 판단기준은 무엇인가? 100 | 101 | - 캐시간, 캐시와 DMA간 등 여러 주체들 간 데이터 불일치를 해결하기 위한 프로토콜을 사용함 102 | - 일관성 유지를 위한 프로토콜: 스누핑 프로토콜, 디렉토리 프로토콜, MSI, MESI, MOESI 103 | - 스누핑 프로토콜: 프로세스가 데이터 쓰기를 진행하기 전에 데이터의 `베타적 접근`을 확보한다. `베타적 접근`은 쓰기작업 시에 다른곳에서 읽기 또는 쓰기작업이 없다는것을 보장해 준다. 104 | > https://www.crocus.co.kr/1381 105 | 106 | ## References 107 | 108 | > https://github.com/NKLCWDT/cs/blob/main/Operating%20System/%EC%BA%90%EC%8B%9C%EC%9D%98%20%EC%A7%80%EC%97%AD%EC%84%B1.md 109 | > 110 | > https://itgall.com/hardware/232948 111 | > 112 | > https://chelseashin.tistory.com/43 113 | > 114 | > https://github.com/Seogeurim/CS-study/tree/main/contents/operating-system 115 | > 116 | > https://m.blog.naver.com/sjc02183/221998493348 117 | > 118 | > http://recipes.egloos.com/5170809 119 | > 120 | > http://recipes.egloos.com/5152867 121 | > 122 | > https://jhnyang.tistory.com/247 123 | > 124 | > https://ddongwon.tistory.com/49 125 | -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/address.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/address.png -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/hierarchy.png -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/l3-cache.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/l3-cache.png -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/mmu.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/mmu.jpg -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/pagetable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/pagetable.png -------------------------------------------------------------------------------- /OperatingSystem/캐시의 지역성/speed-tier.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/캐시의 지역성/speed-tier.png -------------------------------------------------------------------------------- /OperatingSystem/페이징과 세그멘테이션.md: -------------------------------------------------------------------------------- 1 | # 페이징과 세그멘테이션 2 | 3 | - 메모리 관리 비법 4 | 5 | - 페이징 6 | - 페이징 스와핑 7 | - 세그멘테이션 8 | 9 | - 비교 10 | 11 | 12 | 13 | ## 메모리 관리 기법 14 | 15 | 물리 메모리 공간이 제한되어 있으므로, 효율적으로 메모리 할당하자! 16 | 17 | #### 연속 메모리 관리 기법 18 | 19 | 프로그램 전체가 메모리에 연속적으로 할당되어야 하는 기법 20 | 21 | - 고정 분할 기법 -> 내부 단편화 발생 22 | - 가변 분할 기법 : 메모리 할당 알고리즘 (first-fit, best-fit, worst-fit) -> 외부 단편화 발생 23 | 24 | > 내부 단편화 : 프로세스가 필요한 양보다 더 큰 메모리가 할당되어, 프로세스에서 사용하는 메모리 공간이 낭비되는 현상 25 | > 26 | > 외부 단편화 : 할당된 메모리 사이에 작은 메모리가 생겨, 총 메모리 공간은 충분하지만 실제로는 할당할 수 없는 상황 27 | 28 | #### 비연속 메모리 관리 기법 29 | 30 | 프로그램 일부가 서로 다른 주소 공간에 할당될 수 있는 기법 31 | 32 | - 페이징 33 | 34 | - 세그멘테이션 35 | 36 | 37 | 38 | ## 페이징 39 | 40 | ![image](https://user-images.githubusercontent.com/38436013/128986032-f52b7814-1c6b-42bc-b7e1-dc10cc9ffbec.png) 41 | 42 | - 프로세스와 메모리 HOLE을 작은 단위로 나누어 외부 단편화를 해결하는 기법 43 | - 프로세스는 **물리적 단위인 페이지**로 나뉘고, 물리 메모리는 **프레임**으로 나뉘어 **비연속적으로 할당**하는 메모리 기법 (잘린 프로세스 조각 = 페이지, 잘린 물리 메모리 조각 = 프레임) 44 | - 메모리 = 프레임 SET 45 | - 프로세스 = 페이지 SET 46 | - 페이지 테이블에는 (각 페이지 번호, 해당 페이지가 할당된 프레임의 시작 물리 주소)를 저장 47 | - CPU는 논리 주소로 연속적인 주소값을 주고, 이는 메모리로 가기전에 테이블에서 물리 주소로 변경 48 | 49 | #### 장점 50 | 51 | - 메모리 공간을 연속적으로 사용해야한다는 제약을 없앰 -> 외부 단편화 없다!! 52 | 53 | #### 단점 54 | 55 | - 페이지 크기보다 작은 메모리 요청하는 경우 발생 -> 내부 단편화 발생 56 | 57 | 예를들어 페이지 크기가 4KB인데 10KB의 메모리를 필요하는 프로세스는 이 페이지가 2개 + 2KB할당되는 것이 아니라 3개가 할당되어야지만 10KB메모리를 쓸 수 있다. 마지막으로 할당된 페이지는 실제로 프로세스가 2KB 만 사용하고 나머지 2KB는 사용하지 않은 메모리가 된다. -> 2KB 내부 단편화 발생 58 | 59 | #### 정리 60 | 61 | - 페이징에서 페이지 단위는 고정적 62 | - 페이지 크기가 작을수록, 63 | - 장점 : 내부 단편화는 줄어든다. 64 | - 단점 : 페이지 부재 증가(CPU에서 요청한 페이지가 메모리에 없는 경우) 65 | 66 | 67 | 68 | ## 페이징 스와핑 69 | 70 | 페이징 스와핑 : 페이지 단위로 스와핑하는 방식(프로세스 스와핑 : 프로세스 단위로 스와핑) 71 | ![image](https://user-images.githubusercontent.com/93963499/161415577-52ef6e68-5edd-4ef7-8757-1a26f0723ad4.png) 72 | 73 | #### 페이지 테이블과 TLB 74 | 75 | CPU안에 MMU와 TLB가 있다. 76 | 77 | 페이지 테이블의 경우, 주로 메모리 쪽에 있다. 78 | 79 | MMU는 TLB(Translation Lookaside Buffer) 이라는 소형 캐시를 저장하고 있다. 80 | 81 | - 가상 주소가 물리 주소로 변환되어야 할 때, `TLB에서 우선 검색` 82 | - 해당되는 물리 주소 있다면, 물리 주소 리턴하고 메모리에 접근 83 | - TLB에서 해당되는 물리 주소가 없다면, `페이지 테이블에서 맵핑이 존재하는지 탐색` 84 | - 존재한다면, 가상 주소를 이용해 물리 주소 변환하고, 메모리에 접근 85 | - 페이지 테이블에서 못찾는 경우, `디스크에서 찾아서` 그 값을 다시 페이지 테이블에서 쓰고, TLB에서 쓰고 물리주소로 변환 후 메모리에 접근 86 | - TLB 내의 각 항목은 `KEY 와 VALUE` 로 구성된다. TLB 에 페이지를 찾아달라고 요청이 들어오면 이 찾고자 하는 페이지를 동시에 여러 개의 내부 키(페이지 번호)와 비교하고, 페이지 번호가 같은 것이 발견되면 프레임 번호를 알려준다. 87 | - 정리하면, , 가상 주소를 갖고 물리 주소에 접근할 때 *TLB -> page table -> disk 순으로 접근* 88 | 89 | ![image](https://user-images.githubusercontent.com/93963499/161415890-3357715c-efab-4a27-a86d-286720781a7e.png) 90 | 91 | 92 | 93 | ## 세그멘테이션 94 | 95 | ![image](https://user-images.githubusercontent.com/38436013/128990113-f69a1e81-6d33-4b01-a907-99326fdc6871.png) 96 | 97 | - 메모리를 **서로 크기가 다른 논리적인 단위인 세그멘트로 분할하여 메모리를 할당**하는 기법 98 | - 프로그래머가 인지하는 메모리의 모습을 물리 메모리의 모습으로 변환해주는 메모리 기법 99 | - 논리적인 단위? 100 | - 세그멘테이션은 프로세스를 세그먼트의 집합으로 만든다. 101 | - 프로세스는 코드, 데이터, 스택 등이 있는데, 세그먼트도 코드, 데이터, 스택으로 나눌 수 있음 (그 중 코드내부에는 함수, 배열 등 있는데, 이것도 작은 세그먼트로 나눌 수 있음) 102 | - 물리적 크기 단위가 아니라 논리적 내용의 단위로 자르기 때문에 세그먼트는 크기가 동일하지 않음 103 | 104 | - 세그먼트 테이블은 페이징 테이블과 다르게 (세그먼트 번호, 세그먼트 시작 주소(BASE), 세그먼트 길이(LIMIT))을 저장한다. 105 | 106 | - 물리 주소는 세그먼트 테이블에 있는 BASE와 LIMIT을 이용해 구하며, 이 값이 각 세그먼트 크기를 넘어서면, 프로세스를 강제 종료시킨다 107 | - 논리 주소 표현 (세그먼트 번호, 변위) 108 | - 논리주소 (2, 100) => 물리주소 4400번지, 프로세스 메모리에 할당됨 109 | - 논리주소 (1, 500) => 인터럽트로 인해 프로세스 강제 종료(범위를 벗어남) 110 | 111 | #### 장점 112 | 113 | - 보호와 공유 면에서 효과적 114 | - 세그멘테이션이 논리적 단위이므로, 코드 영역은 코드 영역으로 잘리게 되는 방식이다. 115 | - 이때, 중요한 세그먼트와 중요하지 않은 세그먼트를 논리적 단위로 자를 수 있기 때문에 보호와 공유가 가능해진다. (페이징의 경우, 페이지 단위로 잘리므로, 코드 영역 또한 중요한 부분과 중요하지 않은 부분을 구분하지 못하고 잘릴 수 있다.) 116 | - 특히, 두 프로세스가 같은 코드를 공유할 때 용이 117 | - 프로세스들이 공유하는 코드 영역은 메모리에서 그대로 두고, 나머지 세그먼트 영역들에 대해서만 교체를 하므로 컨텍스트 스위칭 발생이 적어진다. 118 | 119 | #### 단점 120 | 121 | - 서로 다른 크기의 세그먼트들이 메모리에 적재되고 제거되는 일이 반복되다 보면, 자유 공간들이 많은 수의 작은 조각들로 나누어져 못 쓰게 될 수도 있다.(외부 단편화) 122 | 123 | 124 | 125 | ## 페이징 VS 세그멘테이션 126 | 127 | #### 공통점 128 | 129 | - 메모리 단편화 문제 해결 기법 130 | - 멀티프로그래밍에서 여러 프로세스 수용하기 위해 메모리를 동적 분할하는 메모리 관리 기법이 필요했음 131 | 132 | #### 차이점 133 | 134 | - 페이징은 고정 단위 135 | - 세그멘테이션은 가변(동적) 단위 136 | - 페이징은 내부 단편화 발생 가능, 세그멘테이션은 외부 단편화 발생 가능 137 | 138 | 139 | 140 | ## QnA 141 | 142 | - 메모리 기법 구분 143 | - 페이징 개념, 장 단 144 | - 세그멘테이션 개념, 장 단 145 | - 페이징과 세그멘테이션의 차이점 146 | 147 | 148 | 149 | ### Reference 150 | 151 | - https://github.com/NKLCWDT/cs/blob/main/Operating%20System/%EC%84%B8%EA%B7%B8%EB%A9%98%ED%85%8C%EC%9D%B4%EC%85%98%EA%B3%BC%20%ED%8E%98%EC%9D%B4%EC%A7%95.md 152 | - https://about-myeong.tistory.com/35 153 | 154 | - https://copycode.tistory.com/108 155 | 156 | - https://velog.io/@nnnyeong/OS-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%8B%A8%ED%8E%B8%ED%99%94-%ED%8E%98%EC%9D%B4%EC%A7%95-%EC%84%B8%EA%B7%B8%EB%A9%98%ED%85%8C%EC%9D%B4%EC%85%98 157 | 158 | - https://jeongmorecord.tistory.com/97 159 | - https://goodmilktea.tistory.com/31 160 | 161 | - https://velog.io/@codemcd/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9COS-12.-%EC%A3%BC%EA%B8%B0%EC%96%B5%EC%9E%A5%EC%B9%98%EA%B4%80%EB%A6%AC 162 | 163 | - http://itnovice1.blogspot.com/2019/08/blog-post_78.html -------------------------------------------------------------------------------- /OperatingSystem/프로세스동기화.md: -------------------------------------------------------------------------------- 1 | 프로세스 동기화 2 | 3 | - 동기화 4 | - 동기화는 간단히 말해서, 데이터 일관성을 유지하기 위한 메커니즘 이라고 보면 된다. 5 | 그럼 데이터 일관성은 무엇을 뜻하는 걸까? 이것은 불변하고 연관이 있기도 하고. 6 | 우리가 흔히 알고 있는 가변 및 불변은 변하는 값과 변하지 않는 값이다. 7 | 즉, 조금 더 익숙한 단어로 들어가자면, 변수와 상수가 된다. 8 | 여기서 동기화가 왜 중요할까? 바로 안정성 때문이다. 9 | 예를 들어보자. 우리는 ATM에서 입출금을 할 수 있다. 10 | 입금은 동시에 진행되어도 아무런 문제가 되지 않는다. 11 | 왜냐하면 누적되는 값이기 때문이니깐, 반면에 출금도 동시에 진행되도 괜찮을까? 12 | 물론, 잔고가 마이너스 되기 전까지는 큰 상관이 없다. 13 | 하지만, 10,000원이 남았고, 여러 사람이 동시에 10,000원을 출금하려고 하면 어떻게 될까? 14 | 여기서 동시에 출금을 허용한다면, 잔고는 -10,000원이 된다. 따라서, 안정성이 무너지게 된다. 15 | 그래서 출금의 경우에는 동기화를 시키는 것이 필수적이다. 16 | 17 | 18 | 19 | - 경쟁 상태 20 | - 데이터 무결성이 깨질 수 있는 상황을 의미한다. 21 | 이것은 위 동기화에서 설명한 출금의 예이다. 22 | 동시에 접근할 때, 결국에는 가장 마지막에 실행되는 프로세스에 의해 값이 결정된다. 23 | 24 | 25 | 26 | - 임계 구역 27 | - 여러 프로세스에서 공유 데이터를 접근하는 프로그램 코드 28 | 즉, 간단히 말하자면, 비동기로 처리하면 위험한 구역을 의미한다. 29 | 그래서 동기로 처리를 해야 하며, 자바에서는 synchronize 키워드를 사용하면, 30 | 동시에 여러 쓰레드가 접근하는 걸 제한할 수 있다. 31 | 하지만 뭐든지 Trade-Off가 있듯이, 이러한 동기 처리를 함으로써, 32 | 성능면에서 덜 효율적일 수 있다. 33 | 그래서 뭐든 상황에 맞게 써야 하므로, 안정성이 최우선이라면 34 | 동기 처리를 하는 것이 합리적이다. 35 | 36 | 37 | - 뮤텍스 38 | - 상호 배제(Mutual Exclusion)란 의미로, Critical Section에 접근하는 프로세스 혹은 쓰레드를 39 | 한 개로 제한한다. 그래서 공유자원에 접근하더라도, 안전성이 보장될 수 있다. 40 | 여기서 Lock과 Unlock이 사용되는데 41 | 현재 자원을 점유중인 쓰레드가 Lock을 걸어버린다. 42 | 그럼 그 자원은 점유중인 쓰레드만 존재하며, 작업이 다 끝나면, Unlock으로 푼다. 43 | 그렇게 Unlock이 되면, 이제 타 쓰레드들도 접근할 수 있게 된다. 44 | 45 | - 단일 쓰레드로 실행된다. 46 | 카페로 예를 들면, 여러 사람이 주문을 하려고 줄을 서있다. 47 | 하지만, 직원은 한 명이다. 따라서, 주문을 받고 난 뒤에 48 | 커피를 만들고 손님에게 내어준다. 그 다음 손님의 주문을 받고... 49 | 이런 식으로 순차적으로 하나씩 흘러간다. 50 | 51 | 52 | - 세마포어 53 | - 공유자원에 대한 여러 프로세스 혹은 쓰레드의 접근을 막는 의미로 사용된다. 54 | 55 | - 다중 쓰레드로 실행될 수 있다. 56 | 세마포어(1)이라면, 뮤텍스와 같은 효과를 본다. 57 | 다시 카페로 예를 들면, 여러 사람이 주문을 하려고 줄을 서있는데 58 | 이번에는 직원이 여러 명이다. 그럼 주문 받는 직원, 커피 만드는 직원 59 | 이런 식으로 여러 일을 동시에 처리할 수 있다. 60 | 우리가 흔히 접하는 일상생활에서 세마포어의 예를 볼 수 있다. 61 | -------------------------------------------------------------------------------- /OperatingSystem/프로세스와 스레드.md: -------------------------------------------------------------------------------- 1 | # 프로세스와 쓰레드 2 | 3 | 프로세스와 쓰레드를 정확히 이해해야 멀티 쓰레드 환경에서 왜 상태값을 갖도록 설계하면 안되는지에 대해 알 수 있다. 4 | 5 | 특히 `프로세스의 메모리 영역(Stack, Heap, Data, Text)`에 대한 이해가 중요하다. 6 | 7 | - 프로세스 메모리 영역 8 | - `Stack` : 매개변수, 지역변수 등 임시적인 자료 9 | - `Heap` : 동적으로 할당되는 메모리 10 | - `Data` : 전역 변수 11 | - `Text` : Program 의 코드 12 | 13 | 프로세스는 운영체제에서 여러개가 존재하며 동작한다 14 | 15 | ## Multi Process 16 | 17 | - 두 개 이상의 다수의 프로세서가 협력적으로 하나 이상의 작업을 동시에 처리하는 것이다 18 | - 프로세스는 실행될 때마다 각각에 고유한 메모리 영역을 할당해주어야 하기 때문에 프로세스가 많아질수록 더 많은 메모리 공간을 차지하게 된다 19 | 20 | ### 장점 21 | 22 | - 독립된 구조로 안전성이 높다 23 | - 프로세스 중 하나에 문제가 생겨도 다른 프로세스에 영향을 주지 않는다 24 | 25 | ### 단점 26 | 27 | - 독립된 메모리 영역을 가지고 있기 때문에 `Context Swithching` 을 위한 오버헤드가 발생한다 28 | 29 | ## Multi Thread 30 | 31 | 한 프로세스에서 여러 개의 쓰레드를 동시에 수행하는 것이다 32 | 33 | 멀티 쓰레드를 적용한 어플리케이션의 예시 34 | 35 | - 웹 서버 프로세스는 클라이언트 요청이 들어오면 그 요청을 처리하기 위한 별도의 쓰레드를 생성한다 36 | - 워드 프로세서는 사용자의 키 입력에 응답하기 위한 쓰레드, 백그라운드에서 맞춤법 및 문법 검사를 수행하기 위한 쓰레드를 가질 수 있다 37 | 38 | ### 장점 39 | 40 | - 응답성이 좋아진다. 단일 쓰레드를 사용하면 그 작업이 완료될 때 까지 응답을 기다려야 한다. 멀티 쓰레드를 사용함으로서 응답성을 향상시킬 수 있다 41 | - 자원을 공유할 수 있다. 쓰레드는 기본적으로 자신이 속한 프로세스의 자원을 공유하기 때문에 동일한 주소 공간 내에서 여러 쓰레드를 가질 수 있다 42 | 43 | ### 단점 44 | 45 | - 쓰레드는 프로세스 내 자원을 공유하기 때문에 쓰레드 하나에서 오류가 발생하면 같은 프로세스 내의 모든 쓰레드가 종료될 수 있다 46 | - 공유 자원에 대한 동기화 문제를 고려해야 한다 47 | 48 | ## Context Switching 49 | 50 | `Context Switching` 은 하나의 프로세스가 CPU를 사용중인 상태에서 다른 프로세스가 CPU를 사용 하기 위해, 이전의 프로세스의 상태를 보관하고 새로운 프로세스의 상태를 적재하는 작업을 말한다 51 | 52 | 한 프로세스의 문맥은 그 프로세스의 `PCB(프로세스 제어 블록)` 에 기록되어 있다 53 | 54 | 프로세스가 증가하게 되면 문맥 교환이 많아져서 오버헤드가 증가하므로 시스템 성능에 악영향을 끼칠 수 있다. 55 | 56 | `오버헤드` 란 CPU가 메모리에 적재하는 동안 아무것도 안하게 되는 현상을 의미한다 57 | 58 | ### 오버헤드의 해결 방안 59 | 60 | - 문맥 교환이 자주 발생하지 않도록 다중 프로그래밍의 정도를 낮춘다 61 | - 쓰레드를 이용하여 문맥 교환 부하를 최소화 시킨다 62 | 63 | 따라서, 이러한 멀티 프로세스의 단점 때문에 `멀티 쓰레드 환경` 을 선호하는 것이다 64 | 65 | ## PCB 66 | 67 | 특정 프로세스에 대한 정보를 담고 있는 운영체제의 자료구조이다. 작업을 진행하다가 프로세스의 전환이 발생하면 하던 일을 저장하고 CPU를 반환해야 한다. 그리고 나중에 스케줄링에 의해 재실행되었을 때 이전의 작업 68 | 정보를 알아야 한다. 그 정보가 담긴 공간이 `PCB` 이다. 프로세스의 생성과 동시에 그 프로세스의 고유한 `PCB` 도 같이 생성된다. 69 | 70 | ### 프로세스 제어 블록에 저장되는 정보 71 | 72 | - 프로세스 식별자(PID) 73 | - 프로세스 상태 74 | - new, ready, running, waiting, terminated 75 | - 프로그램 카운터 76 | - 프로세스가 다음에 실행할 명령어의 주소를 가리킴 77 | - CPU 레지스터 78 | - CPU 스케줄링 정보 79 | - 프로세스 우선순위, 최종 실행 시각, CPU 점유시간 등 80 | - 메모리 관리 정보 81 | - 계정 정보 82 | - 입출력 상태 정보 83 | 84 | ## 프로세스 상태 전이 85 | 86 | 프로세스 상태전이는 프로세스가 시스템 내에 존재하는 동안 프로세스의 상태가 변하는 것을 의미한다. 87 | 88 | ### 프로세스 상태 89 | 90 | - 생성(Create) 91 | - 사용자에 의해 프로세스가 생성된 상태 92 | - 준비(Ready) 93 | - CPU를 할당받을 수 있는 상태 94 | - 실행(Running) 95 | - 프로세스가 CPU를 할당받아 동작중인 상태 96 | - 대기(Waiting) 97 | - 프로세스 실행 중 입출력 처리 등으로 인해 CPU를 양도하고 입출력 처리가 완료되기 까지 대기 리스트에서 기다리는 상태 98 | - 완료(Complete) 99 | - 프로세스가 CPU를 할당받아 수행을 종료한 상태 100 | 101 | ### 프로세스 상태 전이 102 | 103 | ![프로세스상태전이](프로세스와스레드/프로세스상태전이.png) 104 | 105 | #### new -> ready 106 | 107 | new 상태에서 프로세스가 생성되면 OS 커널에 존재하는 Ready Queue 에 올라가게 된다 108 | 109 | #### Dispatch (준비 -> 실행) 110 | 111 | 프로세스 스케줄러에 의해 결정된 우선순위에 따라 프로세스가 CPU를 점유하게 되는 상태 112 | 113 | #### Timeout (실행 -> 준비) 114 | 115 | 프로세스가 실행중이다가 제한된 시간을 다 소비하여 CPU 점유를 빼앗기는 상태 116 | 117 | #### Wakeup (대기 -> 준비) 118 | 119 | 프로세스가 자원을 할당받는 상태 120 | 121 | ## Interrupt 122 | 123 | 인터럽트란 CPU가 특정 기능을 수행하는 도중 급하게 다른 일을 처리하고자 할 때 사용할 수 있는 기능이다 124 | 125 | ### 인터럽트 과정 126 | 127 | 1. 프로세스 A 가 실행중 -> 갑자기 저장을 위한 로직이 실행 128 | 2. 현재 CPU가 처리하고 있던 일의 진행상황을 저장한다 129 | 3. 인터럽트 코드의 실행을 위해 CPU에 기존에 할당되어 있던 작업과 인터럽트 처리 될 작업을 교환한다 130 | 4. CPU에서 교환된 인터럽트 코드의 처리를 마친다 131 | 5. 이전 작업을 CPU에 다시 할당한다 132 | 6. 이전에 중단되었던 곳부터 다시 진행한다 133 | 134 | 3번에 해당하는 과정이 `Context Swiching` 이다. 135 | 136 | ## WAS 137 | 138 | ### Web Server 139 | 140 | 웹 서버는 클라이언트로부터 HTTP 요청을 받아 HTML 문서나 각종 리소스를 응답하는 서버 141 | 142 | ``` 143 | Client -------------> Server 144 | HTTP 요청 145 | 146 | 147 | <-------------- 148 | HTTP 응답 149 | ``` 150 | 151 | 그렇다면 동적인 컨텐츠를 어떻게 제공할 수 있을까? 152 | 153 | ### WAS 154 | 155 | - Web Application Server의 약자 156 | - 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크 157 | - Web Server + Web Container 158 | - HTML 같은 정적인 페이지에서 처리할 수 없는 비즈니스 로직이나 동적인 컨텐츠를 제공 159 | 160 | ![was](프로세스와스레드/was.png) 161 | 162 | ### Web Server vs WAS 163 | 164 | 정적인 컨텐츠 vs 정적+동적인 컨텐츠 165 | 166 | ## ThreadPool 167 | 168 | ### ThreadPool을 사용하는 이유 169 | 170 | 프로세스에서 병렬 작업처리가 많아지면 쓰레드 개수가 증가하고 그에 따른 쓰레드 생성과 스케줄링으로 인해 CPU 사용량이 증가하여 메모리 사용량이 늘어난다. 따라서 시스템 성능이 저하되고, 갑작스러운 병렬 작업의 171 | 폭증에 따른 쓰레드 폭증을 막으려면 `ThreadPool` 을 사용해야 한다. 172 | 173 | 쉽게 설명하자면 쓰레드를 미리 만들어 놓은 풀장?이라고 생각하면 된다. 만약 전쟁이 일어나서 100명의 인력이 필요하다고 한다면, 그때 그때 인력을 투입하는것보다 미리 100명을 준비 시키는게 대응이 더 빠르다. 174 | 175 | ### ThreadPool의 동작 원리 176 | 177 | 우리가 만든 어플리케이션에서 사용자로부터 들어온 요청을 작업 큐에 넣고, `ThreadPool` 은 작업 큐에 들어온 `Task` 일감을 미리 생성해놓은 `Thread` 에게 일감을 할당한다. 일을 다 178 | 처리한 `Thread` 은 다시 어플리케이션에게 결과를 전달한다. 179 | 180 | ![threadpool](프로세스와스레드/threadpool.png) 181 | 182 | ### ThreadPool의 장점 183 | 184 | - 프로그램 성능 저하 방지를 위해 185 | - 매번 발생되는 작업을 병렬 처리하기 위해 `Thread` 을 생성/수거 하는데 따른 부담은 프로그램 전체적인 퍼포먼스를 저하시킨다. 그래서 미리 `ThreadPool` 을 만들어 놓는다 186 | - 다수의 사용자 요청을 처리하기 위해 187 | - 다수의 사용자 요청을 수용하고, 빠르게 처리하고 대응하기 위해 `ThreadPool` 을 사용한다 188 | 189 | ### ThreadPool의 단점 190 | 191 | - 과유불급 192 | - 많은 병렬 처리를 예상해서 1억개의 `Thread` 을 만들었다고 가정했을 때, 실제로 100개만 사용한다면 나머지 `Thread` 은 아무일도 하지 않고 메모리만 차지하는 경우가 발생할 수 있다 193 | 194 | ## 동시성 이슈란? 195 | 196 | `Thread` 은 CPU 작업의 한 단위이다. 여기서 멀티 쓰레드 방식은 멀티 테스킹을 하는 방식 중, 한 코어에서 여러 쓰레드를 이용해서 작업을 처리하는 방식이다. 멀티 쓰레드를 이용하면 공유하는 자원이 멀티 197 | 프로세스 방식보다 `Context Switching` 오버헤드가 적어, 메모리 리소스가 상대적으로 적다는 장점이 있다. 하지만 자원을 공유하는 단점도 존재한다. 198 | 199 | 여러 `Thread` 가 하나의 자원을 공유하고 있기 때문에 같은 자원을 두고 `교착상태` 같은 문제가 발생하는 것이다. 200 | 201 | ### 예제 코드 202 | 203 | ``` 204 | @Service 205 | public class UserService { 206 | 207 | private UserId userId; // 상태 값 208 | 209 | public void updateUserId(User user) { 210 | // User의 ID 를 변경하는 로직을 수행 211 | } 212 | } 213 | ``` 214 | 215 | `UserService` 는 스프링 컨테이너에서 관리하는 `Bean` 이므로 싱글톤 객체이다. 쓰레드는 프로세스의 Stack, Heap, Data, Text 영역 중 Stack 부분을 제외한 나머지를 216 | 공유하는데 `userId` 의 값은 전역변수이므로 `Data` 영역에 존재한다. 즉 수많은 쓰레드들이 상태 값을 공유하게 되는 것이다ㅓ. 그렇게 되면 다른 사람의 아이디가 나에게 공유되는 등 수 많은 오류가 발생할 217 | 수 있다. 이와 같은 문제를 해결하기 위해선 어떻게 해결해야 할까? 결국 정답은 `쓰레드` 의 구조를 생각하면 알 수 있다. 218 | `Stack` 영역은 쓰레드들이 공유를 하지 않기 때문에 전역 변수 대신 지역 변수를 사용하면 간단하게 해결 할 수 있다. 219 | 220 | 근데 만약 싱글톤 객체에서 상태 값을 가져야 하는 경우라면..? 221 | 222 | ## 동시성 이슈를 피하는 방법 (스프링에서) 223 | 224 | `ThreadLocal` 이란 해당 쓰레드만 접근 할 수 있는 특별한 저장소를 말한다. `thread-A` 와 `thread-B` 가 존재 했을 때 각각의 전용 보관소에 데이터를 안전하게 보관한다. 225 | 226 | 그래서 위의 코드는 다음과 같이 수정이 가능하다. 227 | 228 | ``` 229 | @Service 230 | public class UserService { 231 | 232 | private ThreadLocal userIdStore = new ThreadLocal<>(); // 상태 값 233 | 234 | public void updateUserId(User user) { 235 | // User의 ID 를 변경하는 로직을 수행 236 | } 237 | } 238 | ``` 239 | 240 | ### ThreadLocal을 사용시 주의할 점 241 | 242 | `ThreadLocal` 의 값을 사용 후 제거하지 않고 그냥 두면 WAS(톰캣)처럼 `ThreadPool` 을 사용하는 경우 문제가 발생할 수 있다. 243 | 244 | - 사용자A 저장 요청 245 | 246 | 1. 사용자A가 저장 HTTP를 요청한다 247 | 2. WAS는 쓰레드 풀에서 쓰레드를 하나 조회한다 248 | 3. 쓰레드 `thread-A` 가 할당되었다 249 | 4. `thread-A` 는 사용자 A의 데이터를 `ThreadLocal` 에 저정한다 250 | 5. `ThreadLocal` 의 `thread-A` 전용 보관소에 사용자 A의 데이터를 보관한다 251 | 252 | - 사용자A 저장 요청 종료 253 | 254 | 1. 사용자 A의 HTTP 응답이 끝난다 255 | 2. WAS는 사용자 끝난 `thread-A` 를 `ThreadPool` 에 반환한다. `thread` 를 생성하는 비용은 비싸기 때문에 `thread` 를 제거하지 않고, 보통 `ThreadPool` 을 256 | 통해서 `thread` 를 재사용한다 257 | 3. `thread-A` 는 아직 `ThreadPool` 에 아직 살아있다. 따라서 `ThreadLocal` 의 `thread-A` 전용 보관소에 사용자 A의 데이터도 함께 살아있게 된다 258 | 259 | 260 | - 사용자B 조회 요청 261 | 262 | 1. 사용자B가 조회를 위한 새로운 HTTP 요청을 한다 263 | 2. WAS는 `ThreadPool` 에서 `thread` 를 하나 조회한다 264 | 3. `tread-A` 가 할당되었다 265 | 4. 이번에는 조회하는 요청이다. `thread-A` 는 `ThreadLocal` 에서 데이터를 조회한다 266 | 5. `ThreadLocal` 은 `thread-A` 전용 보관소에 있는 사용자 A값을 반환한다 267 | 6. 결과적으로 사용자A 값이 반환된다 268 | 7. 사용자B는 사용자A의 정보를 조회하게 된다 269 | 270 | 결과적으로 사용자B는 사용자A의 데이터를 확인하게 되는 심각한 문제가 발생하게 된다. 271 | 272 | 이런 문제를 예방하려면 사용자A의 요청이 끝날 때 `ThreadLocal.remove()` 를 호출해서 `ThreadLocal` 에 저장된 값을 제거해주어야 한다. 273 | 274 | ## Thread Safe 하게 설계하는 방법 275 | 276 | - java.util.concurrent 패키지 하위 클래스를 사용한다 277 | - 인스턴스 변수를 두지 않는다 278 | - Singleton 패턴을 사용한다 279 | - 동기화(synchronized) 블록에서 연산을 수행한다 280 | 281 | ## Q&A 282 | 283 | ### Context Swiching 보관되는 장소 284 | 285 | `Context Switching` 이란 CPU가 이전 프로세스 상태를 `PCB` 에 보관하고, 또 다른 프로세스의 정보를 `PCB` 로 읽어 레지스터에 저장하는 과정을 말한다 PCB의 위치는 운영체제에서 커널 286 | 스택의 처음에 위치한다. (이 메모리 영역은 편리하면서도 보호를 받는 위치이기 때문) 287 | 288 | ### 보관되는 이유 289 | 290 | CPU가 어떤 하나의 프로세스를 실행하고 있는 상태에서 인터럽트 요청에 의해 다음 우선 순위의 프로세스가 실행되어야 할 때 기존 프로세스의 상태 또는 값을 유지하기 위해 291 | 292 | ## 출처 293 | 294 | https://gona.tistory.com/6 295 | https://limkydev.tistory.com/55 296 | https://www.youtube.com/watch?v=QmtYKZC0lMU&t=1121s 297 | https://github.com/NKLCWDT/cs/blob/main/Operating%20System/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80%20%EC%93%B0%EB%A0%88%EB%93%9C.md 298 | https://github.com/Seogeurim/CS-study/tree/main/contents/operating-system#%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C 299 | 300 | https://velog.io/@dyllis/%EB%8F%99%EC%8B%9C%EC%84%B1%EC%9D%B4-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C 301 | https://velog.io/@mooh2jj/%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C%EC%9D%98-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88 302 | 303 | 304 | -------------------------------------------------------------------------------- /OperatingSystem/프로세스와스레드/threadpool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/프로세스와스레드/threadpool.png -------------------------------------------------------------------------------- /OperatingSystem/프로세스와스레드/was.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/프로세스와스레드/was.png -------------------------------------------------------------------------------- /OperatingSystem/프로세스와스레드/프로세스상태전이.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/omnireader0/Tech-Interview-Question/2243e3a2b5a6dc07e5bee1b346f2f3a07892f41b/OperatingSystem/프로세스와스레드/프로세스상태전이.png -------------------------------------------------------------------------------- /Question/네트워크_질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 내용 질문 2 | 3 | ### **OSI 7 layer** 4 | 5 | - 프로토콜 6 | - osi 7 layer이란? 7 | - tcp/ip layer이란? 8 | - osi 7 layer와 tcp/ip layer에서 계층화하는 이유 9 | - OSI 7계층을 택하면 좋은점 10 | - 많은 직장인들이 아웃룩을 이용하여 회사 메일을 관리하고 있습니다. 아웃룩과 관련된 계층과 프로토콜을 말해 주세요. 11 | - 이전에 저희 회사의 서비스를 제공받는 모든 고객의 pc에서 서비스 중단 이 일어났습니다. OSI 7계층의 관점으로 몇번째 계층의 문제임을 예상할 수 있을까요? 12 | - 서버에 문제가 생겼는데, Ping Test 시 문제는 없었습니다. 그렇다면 어느 계층에서 문제가 있다는 것을 유추할 수 있나요? 13 | - 유튜브와 같은 스트리밍 서비스를 제작해보려합니다. 이때 어떤 프로토콜로 구현할 것인지 관련 계층과 연관지어 말해 주세요. 14 | - 웹 서버 소프트웨어(Apache, Nginx)는 OSI 7계층 중 어디서 작동하는지 설명해 보세요. 15 | - 웹 서버 소프트웨어(Apache, Nginx)의 서버 간 라우팅 기능은 OSI 7계층 중 어디서 작동하는지 설명해 보세요. 16 | 17 | ### **TCP, UDP** 18 | 19 | - TCP의 특성에 대해서 말씀해 주세요. 20 | - UDP의 특성에 대해서 말씀해 주세요. 21 | - 3-Handshaking과 4-Handshaking의 과정을 설명해 주세요. 22 | - 3-way handshaking 과정에서 클라이언트가 서버가 보낸 ACK+SYN을 받지 못하면? 23 | - 4-way handshaking 과정에서 클라이언트가 마지막에 ACK를 굳이 보내는 이유? 24 | - 만약 Server에서 FIN 세그먼트를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까? 25 | - TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유? 26 | - 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유? 27 | 28 | ### **웹 통신 흐름** 29 | 30 | - 인터넷에 www.naver.com을 쳤을 때, 브라우저의 렌더링 과정에 대해 설명해 주세요. 31 | - 브라우저가 전송한 request 메시지를 웹 서버까지 전송하고 그 응답을 받기까지의 과정을 설명해 주세요. 32 | - 프로토콜 스택은 어떤 역할을 하나요? 33 | - 프록시 서버는 어떤 기능을 하나요? 34 | - 그럼 두 번 이상 요청된 내용은 프록시 서버 캐시로부터 다운로드받게 될텐데 페이지의 값이 바뀐다면 어떻게 처리할 수 있나요? 35 | - 서로 다른 프로토콜을 사용하는 두 네트워크를 연결하기 위한 방법은 무엇이 있을까요? 36 | - CORS 문제가 무엇이고 경험해본적 있는가요? 37 | 38 | ### **HTTP와 HTTPS** 39 | 40 | - HTTP와 HTTPS를 설명해 주세요. 41 | - HTTP 특징을 설명을 해주세요. 42 | - HTTP의 단점을 설명해 주세요. 43 | - HTTP1.1와 HTTP2.0 차이점은 무엇인가요? 44 | - HTTP는 왜 비연결성인가? 45 | - HTTP 비연결성의 단점과 해결책 46 | - 모든 웹 페이지에서 HTTPS 를 사용하지 않는 이유를 설명해 주세요. 47 | - 비대칭키 또는 공개키 암호화 방식은 무엇인가요? 48 | - HTTP REQUEST 방식 중 GET과 POST의 차이을 설명해 주세요. 49 | - GET, POST를 제외하고 다른 방식들을 설명해 주세요. 50 | - HTTP 프로토콜을 사용하여 개발한 경험 51 | - 웹 애플리케이션 제작 시 조회/삭제/수정의 업무를 하려고 합니다. 각각을 어떤 방식으로 설계할 것인지 말해주세요. 52 | - HTTP또는 암호화 되지 않은 프로토콜의 문제점은 무엇이 있나요? 53 | - 이러한 문제를 해결하기 위한 다양한 방안이 존재하는데 대표적으로 HTTPS 가 있습니다. HTTPS에 대해 설명 해주시겠어요? 54 | - HTTP 와 HTTPS 중 어떤 프로토콜이 더 많이 사용 된다고 생각하는지와 그 이유에 대해서 말씀해 주세요. 55 | 56 | ### 로드밸런서 57 | 58 | - 로드밸런싱에 대해 설명해 주세요. 59 | - 서버에서 트래픽이 주어졌을 때 어떻게 응답속도를 개선할 수 있는가? (힌트 : 스케일 업과 스케일 아웃) 60 | - 로드 밸런싱의 대표 알고리즘은 어떤 것이 있을까요? (힌트 : 라운드 로빈, 최소 연결 방식) 61 | - L4 로드밸런싱과 L7 로드밸런싱에 대해 설명하고 차이를 말씀해 주세요. 62 | - 데이터 갱신이 빈번할 때, scale up이 유리한 이유는? 63 | 64 | ### **IP, 도메인, DNS** 65 | 66 | - 도메인과 DNS가 무엇인지 설명해 주세요. 67 | - DNS 서버는 무슨 역할을 하나요? 68 | - 도메인과 ip 주소에 대해서 설명해 주세요. 69 | - Domain Name 구조와 recursive query 과정을 설명해 주세요. 70 | - DHCP 서버의 역할을 간단히 설명해 주세요. 71 | - Domain Name System 동작과정을 설명해 주세요. 72 | - DNS round robin 방식과 문제점과 해결방법을 설명해 주세요. 73 | 74 | ### REST API 75 | 76 | - REST의 핵심 3가지 요소를 포함하여 REST가 무엇인지 설명해 주세요. 77 | - REST의 기본 원칙을 3개 이상 설명해 주세요. 78 | - 응답 상태 코드 종류별로 설명해 주세요. 79 | 80 | ### Cookie, Session, JWT 81 | 82 | - HTTP의 특징과 쿠키와 세션이 등장한 이유를 설명해 주세요. 83 | - 쿠키와 세션에 대해 설명해 주세요. (차이, 특징, 사용처) 84 | - 세션 기반 인증 방식 vs 토큰 기반 인증 방식에 대해 설명해 주세요. 85 | - JWT에 대해 설명해 주세요. (특징, 장단) 86 | 87 | ### CORS 88 | 89 | - CORS와 CORS로 인한 이슈에 대해 설명해 주세요. 90 | - CORS 동작 방식을 간단히 설명해 주세요. 91 | 92 | ### OAuth 93 | 94 | - OAuth 적용한 경험 95 | - OAuth 인증 방식을 간단히 설명해 주세요. 96 | - OAuth1.0 과 OAuth2.0의 차이를 설명해 주세요. 97 | 98 | ### 그 외 질문 99 | 100 | - 웹 서버와 WAS 차이 101 | - Authentication and Authorization 102 | - 공개키 암호, 대칭 키 암호 103 | 104 | ## 심화 내용 질문 105 | 106 | ### 프록시 107 | 108 | - 프록시를 간단히 설명해 주세요. 109 | - 포워드 프록시와 리버스 프록시의 차이, 특징을 설명해 주세요. 110 | 111 | ### 네트워크 보안 112 | 113 | - 보안의 3대 요소를 설명해 주세요. 114 | - IPSec이란? 115 | - SSL과 TLS? 116 | - CSRF? 117 | -------------------------------------------------------------------------------- /Question/데이터베이스_질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 질문 정리 2 | 3 | ### 데이터베이스 4 | 5 | - 데이터베이스는 사용하는 이유 6 | - 데이터베이스의 성능을 좋아지게 하는 방법? 7 | - 정규화는 왜 필요한지 설명해 주세요. 8 | - 제 1 정규형은 데이터베이스 정규화에서 사용하는 최소 정규형입니다. 제1 정규형에서 어떤 정규화 과정을 진행하는지 예시를 들어 설명할 수 있나요? 9 | - 제3 정규형을 '추이 종속' or '함수적 이행 종속' 단어를 사용하여 설명할 수 있나요? 10 | - **개인정보**에 관한 데이터베이스에서 수정 이상이 일어나 select로 정확한 정보 파악이 되지 않아 정규화를 진행했습니다. 하지만 이전보다 훨씬 느려졌다고 가정해봅시다. 지원자는 반정규화를 진행할것입니까? 11 | - 정규화 작업 이후, 알맞게 정규화를 했는지 검증하고 싶을땐 어떻게 할까요? 12 | 13 | ### Index 14 | 15 | - Index가 무엇인가요? 16 | - Index의 특징 17 | - Index 테이블 선정 기준 18 | - Index를 구현하는 자료구조에 대해서 말씀해주세요. 19 | - MULTI BLOCK READ가 무엇이며, 인덱스 테이블 선정기준과 연관지어 설명해보세요. 20 | - 인덱스 컬럼 선정 기준에 대해 아는대로 말해보세요. 21 | - 인덱스 설계시, 인덱스와 테이블 데이터의 저장공간이 분리되도록 설계하는 이유에 대해 설명하시오. 22 | - 순차 I/O, 랜덤 I/O 23 | - 쿼리 튜닝의 목적 24 | - B-Tree Index, Hash Index, InnoDB Adaptive Hash Index 25 | - MySQL 에서 B-tree 를 사용하는 이유 26 | - 인덱스 레인지 스캔, 인덱스 풀 스캔 27 | - 클러스터링 인덱스, 논 클러스터링 인덱스 28 | - MySQL 에서 PK 를 인조키로 사용하고 Auto_Increment 를 사용하는 이유 29 | 30 | ### RDBMS, NoSQL 31 | 32 | - RDBMS 설계 목표 33 | - RDBMS의 장단점 34 | - NoSQL의 장단점 35 | - NoSQL에서 정규화가 필요할까? 36 | - RDBMS vs NoSQL 37 | - 어떤 상황에서 RDBMS와 NoSQL을 선택하는가? 38 | - RDBMS에서 서버 확장하는 법 39 | 40 | ### 트랜잭션 41 | 42 | - 트랜잭션이란 무엇이며 왜 사용하는가? 43 | - 트랜잭션은 ACID라는 4가지 특성 44 | - A 계좌에서 B계좌로 일정 금액을 이체하는 작업에 대해 생각해봅시다. 이 때 트랜잭션은 어떻게 정의할 수 있을까요? 45 | - (위 질문과 연결) 방금 말씀해주신 쿼리문에 대해서 Commit 연산과 Rollback 연산이 일어나는 경우는 각각 어떤 상황일까요? 46 | - 트랜잭션의 Commit 연산에 대해서 트랜잭션의 상태를 통해 설명해 주세요. 47 | - 트랜잭션의 Rollback 연산에 대해서 트랜잭션의 상태를 통해 설명해주세요. 48 | - 트랜잭션 격리 수준이란? 왜 필요한가? 49 | - Isolation level의 종류 중 한 가지를 설명해주시고, 이 때 발생할 수 있는 현상 50 | 51 | ### 정규화, 반정규화 52 | 53 | - 이상 현상 54 | - 정규화와 반정규화를 간단히 설명해 주세요. 55 | 56 | ### 그 외 57 | 58 | - 스키마와 테이블의 차이점을 설명해 주세요. 59 | 60 | ## 심화 질문 정리 61 | 62 | ### ElasticSearch 63 | 64 | - ElasticSearch는 무엇인가? 65 | - 색인과 역색인이란? 66 | - ElasticSearch와 RDBMS과의 차이점 설명해 주세요. 67 | - ElasticSearch의 장단점을 설명해 주세요. 68 | - ElasticSearch의 주요 용어를 설명해 주세요. 69 | 70 | ### DB Lock 71 | 72 | - Lock 의 종류와 단위를 간단히 설명해 주세요. 73 | - 블로킹(Blocking)이란? 74 | - 데드락(Deadlock)이란? 75 | 76 | ### Redis 77 | 78 | - redis는 무엇이며, 언제 사용하는가? 79 | - redis의 특징을 설명해 주세요. 80 | 81 | ### 트랜잭션 82 | 83 | - 트랜잭션 동시성 제어를 설명해 주세요. 84 | - 동시성 제어를 하지 않을 시 발생하는 문제점? 85 | - 동시성 제어 방법을 간단히 설명해 주세요. 86 | 87 | ### DB 스토리지 88 | 89 | - 클러스터의 개념과 장점 90 | - 클러스터 구현 방법 91 | - 리플리케이션 개념과 사용하는 이유 92 | - 파티셔닝 개념 간단히 설명해 주세요 93 | - 샤딩 개념 간단히 설명해 주세요 94 | 95 | ### 커넥션 풀 (DBCP; Database Polling Service) 96 | 97 | - 커넥션 풀이란? 98 | - 커넥션 풀 동작원리 99 | - 커넥션 풀 사용하는 이유 100 | - DB Connection Pool 관리 방법 101 | - WAS에서 설정해야 하는 값 중 가장 성능에 많은 영향을 주는 부분에 대해 설명해 주세요. 102 | -------------------------------------------------------------------------------- /Question/운영체제_질문정리.md: -------------------------------------------------------------------------------- 1 | ## 기본 내용 질문 2 | 3 | ### **OS 개요** 4 | 5 | - 운영체제와 운영체제의 주요 기능을 설명해 주세요. 6 | - 카톡 부팅 과정을 os와 연관지어 설명하시오. 7 | - 한컴 오피스 '한글'을 클릭 후 빈 화면에 커서가 깜빡인다. 이때 Hello world를 작성하면 컴퓨터 내부에 무슨 일이 일어나는가? 8 | 9 | ### **CPU 스케줄링** 10 | 11 | - 스케줄링 무엇인지와 목적을 설명 12 | - 비선점방식과 선점방식 설명 13 | - 라운드 로빈 스케줄링이란? 14 | - 스케줄링 기법 중 fcfs 의 단점과 해결 방안을 설명하시오. 15 | 16 | ### **프로세스와 스레드** 17 | 18 | - 프로그램과 프로세스, 스레드를 설명 19 | - 프로세스가 도중에 중지되는 경우, 그 원인과 다시 실행할 수 있는 방법은 무엇일까요? 20 | - 프로세스의 힙, 스택 영역에는 어떤 정보가 있나요? 21 | - 프로세스와 스레드 자세히 설명 22 | - 스레드가 메모리 공유하는 이유 23 | - 스택을 스레드마다 독립적으로 할당하는 이유가 무엇인가요? 24 | - PC Register를 스레드마다 독립적으로 할당하는 이유 25 | - 스레드와 멀티 스레드의 차이에 대하여 설명하고, 멀티 스레드의 장단점을 설명해보세요. 26 | - 멀티 스레드와 멀티 프로세스의 차이를 말해주세요. 27 | - 멀티 프로세스 대신 멀티 스레드 사용하는 이유 28 | - 멀티 스레드 적용한 어플리케이션 예시 (Multi-threaded applications example) 29 | - 컨텍스트 스위칭 설명 30 | - 컨텍스트 스위칭 비용은 프로세스와 스레드 중 어디가 더 클까? 31 | - 멀티 코어와 멀티 프로세스, 병렬 처리 용어 32 | - 컨텍스트 스위칭 발생할 때, pc 값을 레지스터에 보관하는 이유 33 | - 프로세스 메모리 구조는 코드, 데이터, 스택, 힙이 있다. 각 구역의 특징은? 34 | - 프로세스 메모리 구조에서 스택과 힙의 차이 및 특징은? 35 | - PCB에 저장되는 정보는 어떤 것이 있으며, 어떻게 관리될까? 36 | 37 | ### **커널, 인터럽트** 38 | 39 | - 커널이란? 40 | - 커널 모드와 유저 모드 구분하는 이유? (이중 모드의 특징과 장점) 41 | - 인터럽트에 대해 설명해보시오. 42 | - 인터럽트와 시스템콜(=트랩) 비교 43 | - 인터럽트 발생 원인 44 | - 문서 프로그램 작성시 발생하는 인터럽트 과정에 대해 설명해 보시오! (마우스) 45 | 46 | ### **병행성(상호배제, 동기화, 교착상태, 기아)** 47 | 48 | - DeadLock의 발생 조건과 DeadLock을 깨기 위해 어떻게 해야 하나요? 49 | - race condition(경쟁 상태)에 대하여 간단한 예시를 들어 설명해주세요 50 | - OS에서 경쟁 상태 발생하는 경우 설명 51 | - 여러 프로세스가 가 데이터를 공유하며 수행될 때, 각 프로세스에서 공유 데이터를 접근하는 프로그램 코드를 무엇이라 부르나요? 그리고 그에 대한 간단한 설명 부탁드립니다. 52 | - 임계 영역을 프로세스들이 같이 쓸 수 있는 전제 조건을 설명해주세요. 53 | - 프로세스 동기화란 무엇인가요? 54 | - 임계 구역 해결 방법을 설명하시오 55 | - Mutex Lock 과 Semaphore 의 차이 56 | - Mutex Lock 와 Monitor의 차이 57 | - Semaphore와 Monitor 차이 58 | - 교착 상태? 59 | - 교착 상태에는 어떤 기법들이 있으며 각각 어떤 역할을 하는가? 60 | - 교착상태 vs 기아상태 61 | - 운영체제에서 에이징(Aging)는 무엇입니까? 62 | - Swapping이 무엇인가? 63 | 64 | ### **메모리 관련 전략** 65 | 66 | - 메모리 구조의 순서가 어떻게 되는지 cpu에서 가까운 순서로 말해보세요 67 | - 메모리 관리란? 왜 할까요? 68 | - RAM을 늘리면 어떻게 되나요? 69 | - 컴퓨터의 속도를 빠르게 하고 싶으면 무작정 RAM 늘리면 될까요? 70 | - 만약 16GB의 메인 메모리를 가지고 있고, 운영체제의 용량이 16GB라고 해보자. 그럼 이 컴퓨터는 운영체제 외에 다른 프로그램은 실행할 수 없는 것인가? 71 | - 메모리 할당(연속 메모리, 비연속 메모리)을 설명해 주세요. 72 | - 메모리 할당 알고리즘의 각 특징을 설명해 주세요.(first-fit, best-fit, worst-fit) 73 | - 논리주소와 물리주소 74 | - 컴파일 타임 바인딩, 적재 타임 바인딩, 실행 타임 바인딩을 간단히 설명하시오 75 | - 외부 단편화와 내부 단편화를 설명하시오. 76 | - 외부 단편화 해결하기 위한 전략은? 77 | - 외부 단편화가 발생할 때마다 압축을 시행하는가? 78 | - 압축 외에 외부 단편화를 해결하는 방안은? 79 | - 페이징의 장점과 단점은? 80 | - 메모리 단편화 해결 기법에 대해 설명하시오. 81 | - 페이지 교체 알고리즘 중 3가지를 선택해서 설명해주세요. 82 | - swapping에서 swap-out 하는 경우, 프로그램 상태로 backing-store 하는가? 83 | 84 | ### **가상 메모리** 85 | 86 | - 가상메모리의 역할은 무엇인가요? 장단점은? 87 | - 가상 메모리를 효율적으로 관리하는 방법은 어떤 것들이 있을까요? 88 | - Page Fault에 대해 설명하시오 89 | - 페이지를 교체하는 방법들을 설명해보시오 90 | - Demand Paging(요구 페이징)에 대해 설명하시오 91 | - 페이지 적중율을 극대화 시키기 위한 방법은 무엇이 있는가? 92 | - Cache 메모리를 사용하는 이유 93 | - 페이지들을 할당하려고 하는데 프레임이 매우 커서 편하게 페이지가 할당될 수 있는 상황을 가정해봅시다. 이 상황이 무조건적으로 이득일까요? 만약 아니라면 어떤 상황에서 이득이 아닐지 의견을 듣고 싶어요. 94 | - 최적의 교체 알고리즘인 OPR(Optimal Page Replacement)가 현실적으로 가능할까요? 전제조건이 있어도 괜찮습니다. 또한 실생활에서 쓰일 수 있을까요? 95 | - 리눅스 운영체제에서는 어떤 페이지 교체 알고리즘을 사용할까요? 자신이 생각하는 이유와 함께 알고리즘을 설명해주세요. 96 | 97 | ### **그 외 질문들** 98 | 99 | - 함수 호출과 시스템 콜 차이 100 | - symchromized에 대해 아는 바를 전부 설명하세요 101 | - Synchronous 와 Asynchronous의 차이점 102 | - Blocking 과 Non-Blocking의 차이점 103 | - 캐시와 레지스터의 차이 104 | - Mapping Function (MMU와 관련하여 설명) 105 | - DMA 존재 이유를 설명하시오 106 | - 운영체제는 다중 유저가 하나의 컴퓨터 자원을 사용할 때 자원의 '보호'를 한다. 어떠한 '보호'를 하는지 설명하고 시나리오를 설명하시오 107 | - os에서 프로세스는 cpu와 메모리 사이에 MMU를 두어서 다른 프로세스에 접근하지 못한다. 그러나 GDB와 같은 디버거의 경우 다른 프로세스에 접근하여 절대적 메모리 주소와 값을 읽어올 수 있다. 어떻게 가능한지 동작 방식에 대해 설명하시오 108 | - 마우스로 한글 바로가기를 클릭했을 때 컴퓨터에서 일어나는 모든 일에 대해 설명하시오 ( Points: Interrupt, Process Scheduling, Disk Scheduling, Swapping, Thread). 109 | 110 | ## 심화 내용 질문 111 | 112 | ### 스레드 113 | 114 | - 멀티스레드의 특징을 자세히 설명해 주세요(공유 자원에 대한 동기화) 115 | - 자바에서의 스레드 116 | - 스레드 풀 117 | - 동시성 이슈 118 | - Thread-safe에 대하여 설명해 주세요. 119 | 120 | ### 파일 시스템 121 | 122 | - 파일시스템이 필요한 이유 123 | - 연속 할당, 연결 할당, 색인 할당 124 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Tech-Interview-Question 2 | 3 | ## ✅ 요약 및 질문 정리 4 | 5 | ### **네트워크** 6 | 7 | #### 🔗 [질문 노트 바로 가기](https://github.com/omnireader0/Tech-Interview-Question/blob/main/Question/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EC%A7%88%EB%AC%B8%EC%A0%95%EB%A6%AC.md) 8 | 9 | #### ✍ 요약 10 | 11 | - 쿠키, 세션, JWT 토큰 12 | - Cookie / Session 13 | - 세션 기반 인증 / 토큰 기반 인증 14 | - JWT 15 | - 네트워크 시스템의 Layered Architecture 16 | - 웹의 동작 방식 17 | - TCP/IP 5 Layer 18 | - OSI 7 Layer 19 | - TCP, UDP, IP, PORT 20 | - HTTP 와 HTTPS 21 | - HTTP/HTTPS 22 | - HTTP 2.0 23 | - 로드 밸런서(Load Balancer) 24 | - 로드밸런싱 25 | - Scale out, Scale up 26 | - 프록시(Proxy) 27 | - 포워드 프록시, 리버스 프록시 28 | - DMZ 29 | - 네트워크 보안(Network Security) 30 | - 보안 3대요소, 웹 해킹, 방화벽 31 | - IPSec, SSL 과 TLS 32 | - SQL Injection, OS Command Injection, XSS, CSRF 33 | - 웹 소켓(Web Socket) 34 | - HTTP Polling, HTTP Long Polling 35 | - HTTP vs 웹 소켓 36 | - CORS(Cross Origin Resource Sharing) 37 | - CORS 38 | - SOP 39 | - 스프링 부트에서 CORS 해결 하는 방법 40 | - REST and RESTful 41 | - REST 구성요소와 기본 원칙 42 | - REST API 디자인 가이드 43 | - OAuth(Open Authorization) 44 | - OAuth1.0, OAuth2.0 45 | - 일반로그인과 OAuth로그인 차이 46 | - 인증 절차 종류 47 | 48 | ### **운영체제** 49 | 50 | #### 🔗 [질문 노트 바로 가기](https://github.com/omnireader0/Tech-Interview-Question/blob/main/Question/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C_%EC%A7%88%EB%AC%B8%EC%A0%95%EB%A6%AC.md) 51 | 52 | #### ✍ 요약 53 | 54 | - 운영체제와 컴퓨터 시스템 구조 55 | - 캐시의 지역성 56 | - 캐시의 종류와 쓰기 57 | - 캐시의 지역성 58 | - Mapping Function 개념 (MMU와 관련하여 설명) (Mapping Function 종류는 조사X) 59 | - 메모리 구성 60 | - 스택 동작 과정 61 | - Stack 과 Heap 62 | - 프로세스/스레드에서의 스택 63 | - 프로세스와 스레드 1 - 동일인 64 | - Multi Process, Multi Thread, PCB, 프로세스 상태 전이 65 | - Interrupt, Context Switching 66 | - 프로세스와 스레드 2 - 동일인 67 | - WAS, ThreadPool 68 | - 동시성 이슈란?, 동시성 이슈를 피하는 방법 (스프링에서) 69 | - Thread Safe 하게 설계하는 방법 70 | - 프로세스 동기화 71 | - 경쟁 상태(race condition) 72 | - 임계 구역(ciritical section) 73 | - 뮤텍스 락(Mutex Locks) 74 | - 세마포(semaphore) 75 | - 교착상태와 기아상태 76 | - 교착상태 77 | - 교착상태 해결 방법 78 | - 기아상태, Livelock 79 | - CPU 스케줄링 기법 80 | - 선점, 비선점 81 | - FIFO, SJF, STCF 82 | - Round Robin 83 | - Busy Waiting 84 | - Multi-Level Feedback Queue 85 | - 블락킹과 논블락킹, 동기식과 비동기식 86 | - 동기식과 비동기식 87 | - 블락킹과 논블락킹 88 | - System Call 89 | - 커널 모드와 유저 모드 90 | - 인터럽트 vs 시스템콜 91 | - 파일 시스템 92 | - 파일의 기본 구성 93 | - 파일 시스템이 필요한 이유 94 | - 트리 구조 디렉토리 95 | - 파일 시스템 대신 데이터베이스를 사용하는 이유 96 | - 주소 바인딩과 스와핑 97 | - 논리 주소 vs 물리 주소 98 | - 컴파일 타임 바인딩, 적재 타임 바인딩, 실행 타임 바인딩 99 | - 스와핑 100 | - 메모리 할당과 단편화 101 | - 고정 분할, 가변 분할 102 | - 메모리 할당 알고리즘(최초 적합, 최적 적합, 최악 적합) 103 | - 외부 단편화, 내부 단편화 104 | - 페이징과 세그멘테이션 105 | - 페이징, 세그멘테이션 106 | - 페이징 스와핑 107 | - 페이지 교체 알고리즘 108 | - OPT, FIFO 109 | - LRU, NUR 110 | - LFU, MFU, SCR 111 | - RAID 112 | - RAID 사용 이유 113 | - RAID 에서 쓰이는 3가지 기술 114 | - RAID 종류와 특징 115 | - 가상 머신, 가상 메모리 116 | - 가상 머신과 가상머신을 사용하는 이유 117 | - 가상 메모리 이점, 원리 118 | - 요구 페이징 119 | 120 | ### **데이터베이스** 121 | 122 | #### 🔗 [질문 노드 바로 가기](https://github.com/omnireader0/Tech-Interview-Question/blob/main/Question/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4_%EC%A7%88%EB%AC%B8%EC%A0%95%EB%A6%AC.md) 123 | 124 | #### ✍ 요약 125 | 126 | - RDBMS vs NoSQL 127 | - RDBMS 와 NoSQL 차이 128 | - RDBMS 에서 서버 확장하는 방법(Master and Slave) 129 | - ElasticSearch 130 | - 검색엔진, 검색시스템, 검색서비스 131 | - 검색시스템 구성요소 132 | - 색인과 역색인 133 | - 검색기 품질 134 | - 관계형 데이터베이스와의 차이점 135 | - 엘라스틱서치 주요 API 136 | - Transaction 137 | - 트랜잭션을 사용하는 이유 138 | - ACID 139 | - 트랜잭션 격리 수준 140 | - 트랜잭션 격리 수준을 설정할 때 발생 하는 문제점들 141 | - Redis 142 | - Redis 143 | - Look Aside Cache, Write Back 144 | - CAP 145 | - DB Lock 146 | - Lock 의 종류와 단위 147 | - 블로킹(Blocking) 148 | - 데드락(Deadlock) 149 | - 정규화, 반정규화 150 | - 이상 현상 151 | - 정규화와 반정규화 152 | - MySQL Architecture 153 | - MySQL 엔진 154 | - 스토리지 엔진 155 | - 핸들러 API 156 | - MySQL 스레딩 구조 157 | - 메모리 할당 및 사용 구조 158 | - 쿼리파서, 전처리기, 옵티마이저, 실행엔진 159 | - 스레드풀, 트랜잭션 지원 메타데이터 160 | - Index, Hint 161 | - 순차 I/O, 랜덤 I/O 162 | - 쿼리 튜닝의 목적 163 | - B-Tree Index, Hash Index 164 | - MySQL 에서 B-tree 를 사용하는 이유 165 | - 인덱스 레인지 스캔, 인덱스 풀 스캔 166 | - 클러스터링 인덱스, 논 클러스터링 인덱스 167 | - MySQL 에서 PK 를 인조키로 사용하고 Auto_Increment 를 사용하는 이유 168 | - 동시성 제어 169 | - 동시성 제어를 하지 않을 시 발생하는 문제점 170 | - 동시성 제어 방법 171 | - 스키마(Schema) 172 | - 스키마 3계층과 3계층으로 나누어 사용하는 이유 173 | - 테이블 vs 스키마 174 | - DB 클러스터링, 리플리케이션 175 | - 클러스터 사용 장점과 구현 방법 176 | - 리플리케이션, 리플리케이션 래그 177 | - 파티셔닝 178 | - 샤딩 179 | - ConnectionPool 180 | - 커넥션 풀 개수 설정 방법 181 | - 커넥션 풀 동작원리(HikariCP) 182 | - 커넥션 풀의 장점 183 | 184 | --------------------------------------------------------------------------------