[CS] CS 면접 질문 정리

윤경·2022년 1월 20일

CS DBIndex Deadlock Java OS OSI계층 PCB Paging REST Sort Thread UDP dbtransaction http network process segmentation tcp 동기화 면접질문 자료구조

CS

목록 보기

4/6

🐶〰️

이 글은 질문에 대한 답을 찾아 정리 해놓은 것으로 참고한 글들은 가장 아래 [📌출처] 에 링크 달아놓았습니다.

✔️ HTTP

HTTP VS HTTPS

HTTP
: Hyper Text Transfer Protocol

서버/클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜
인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있다.
HTTP 서버가 80번 포트에서 요청을 기다리고, 클라이언트는 80번 포트를 통해 요청한다.

애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 동작한다.
HTTP는 상태를 가지지 않는 stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

암호화되지 않은 평문 데이터를 전송하는 프로토콜로 비밀번호와 같은 중요한 정보를 전송하면 제 3자가 정보를 조회할 수 있어 위험하다.
그래서 HTTPS가 등장하게 되었다.

HTTPS
: Hyper Text Transfer Protocol Secure

HTTP에 데이터 암호화가 추가된 프로토콜
443번 포트가 사용되며 네트워크 상에서 제 3자가 정보를 훔쳐볼 수 없도록 암호화를 지원한다.

대칭키 암호화 vs 비대칭키 암호화

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용한다.

대칭키 암호화
: 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화 진행
키가 노출되면 매우 위험하지만 연산 속도가 빠름
비대칭키 암호화
: 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용
키가 노출되어도 비교적 안전하지만 연산 속도 느림

* 공개키: 모두에게 공개 가능한 키
* 개인키: 나만 가지고 알고 있어야 하는 키

각각 장점

공개키 암호화
: 공개키로 암호화하면 개인키로만 복호화가 가능하다.
➡️ 개인키는 나만 가지므로 나만 볼 수 있다.
개인키 암호화
: 개인키로 암호화하면 공개키로만 복호화가 가능하다.
➡️ 공개키는 모두에게 공개되어 있어 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS 동작 과정

: HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용해 빠른 연산 속도와 안정성을 모두 얻는다.

Hand-Shaking 과정에서는 먼저 서버와 클라이언트간 세션키를 교환한다.
여기서 세션키는 주고받는 데이터를 암호화하기 위해 사용되는 대칭키이다.
데이터 간 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.

처음 연결을 성립해 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용된다.
이후 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용된다.

연결 흐름

클라이언트가 서버로 최초 연결 시도
서버는 공개키를 브라우저에게 넘김
브라우저는 인증서의 유효성을 검사하고 세션키 발급
브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화해 서버로 전송
서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행

HTTP 1.1 vs 2.0 vs 3.0

1.x (표준 프로토콜)

Header + Body 구성

Header에는 URI, Request method, 여러 header 정보가 포함

사람이 읽을 수 있는 문자열 그대로 전송

TCP 커넥션 이용 (3-way-handshake 사용)

커넥션 재사용

파이프라이닝 추가 (요청에 대한 응답이 끝나기 전 다음 데이터를 미리 요청)
...

2 (성능 향상 버전)

사실 1.1보다 많은 (아래와 같은) 문제를 가짐

바이너리가 아닌 텍스트로 데이터를 전송

TCP 사용

여전히 요청 데이터가 🔗동기적으로 진행 (1개 요청, 대기 .. 도착하면 그 다음 데이터 요청, 대기 ..)

헤더에 중복된 데이터

그래서 차이는?

HTTP Body가 이진 데이터
기존 HTTP는 Body가 문자열로 이루어져 있지만 2.0부터는 binary framing layer이라는 공간에 이진 데이터로 전송된다.
멀티플렉싱
1.1에서는 HOL blocking 문제가 발생한다.
(*HOL Blocking: 패킷의 순서를 보장하기 위해 패킷이 도착할 때까지 다른 패킷은 전송되지 못하는 것)
2.0부터는 스트림을 이용해
- 여러 요청/응답 병렬처리 (하나의 TCP 연결에 여러 스트림)
- TCP 연결이 1개이므로 3-way-handshake 오버헤드 X
- 네트워크 가용성 증가로 속도 상승, 이미지 스프라이트 등이 필요없어짐
...
스트림 우선순위 지정
각 스트림에 우선순위를 지정해줄 수 있게 되었다. (중요한 데이터를 먼저 보낼 수 있음)
헤더 압축
Server push
클라이언트에게 필요한 데이터가 있을 때, 직접 요청하기 전 서버가 미리 데이터를 전송하여 받아볼 수 있도록

3

HTTP/3 프로토콜은 구글(Google)에서 주도하였으며 10년 전부터 인터넷 서비스 향상을 위해 웹 페이지 반응 속도 개선, TCP 성능 개선 등 다양한 표준화 연구 개발을 진행하였다.

그 후 여러 검증된 인터넷 서비스 개선 기술을 지속적으로 발표하는 동시에 HTTP-over-QUIC의 명칭을 HTTP/3로 바꾸었다.

*QUID
: 2.0에서 TCP+TLS(3-Way-Handshake 과정)에 해당
보안 및 향상된 성능을 제공하는 UDP기반 전송 계층 프로토콜

상당히 가볍고 성능과 보안성을 모두 고려해 설계
암호화된 전송을 통해 멀티 플렉싱된 스트림을 제공

RESTful

: Representation State Transfer

자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든것을 의미한다.
1. HTTP URI를 통해 자원(resource)를 명시하고
2. HTTP Method(POST, GTE, PUT, DELETE)를 통해
3. 해당 자원에 대한 CRUD Operation을 적용하는 것

REST 구성 요소

자원(Resource): HTTP URI
자원에 대한 행위(Verb): HTTP Method
자원에 대한 행위의 내용(Representations): HTTP Message Pay Load

📌 Payload 페이로드

: 전송되는 데이터를 의미

데이터를 전송할 때 헤더와 메타 데이터, 에러 체크 비트 등과 같은 다양한 요소들을 함께 보내 데이터 전송의 효율과 안정성을 높이게 된다.

이때, 보내고자 하는 데이터 자체를 의미하는 것이 페이로드이다.

예를 들어 책을 택배로 보낸다고 생각해보자.
책이 페이로드이다. 책을 감싼 완충재와 송장, 박스 이것들은 부가적인 요소로 페이로드라고 할 수 없다.

페이로드는 메시지 프로토콜 중 프로토콜 오버헤드와 원하는 데이터를 구별할 때 사용된다.
{
	"status": "",
    "from": "",
    "to": "",
    "method": "",
    "data": { "username" : "dbsrud" }
}
(status, from, to, method의 내용은 생략했다.)
여기서 data에 해당하는 부분만이 페이로드이다.

REST 특징

Server-client 구조
Stateless (무상태)
Cacheable (캐시 처리 가능)
Layered System (계층화)
Uniform Interface (인터페이스 일관성)

장단점

장점

HTTP 프로토콜의 인프라를 그대로 사용해 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없음
HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있음
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
Hypermedia API의 기본을 충실히 지키면서 범용성 보장
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악 가능
여러가지 서비스 디자인에서 생길 수 있는 문제 최소화
서버와 클라이언트의 역할을 명확하게 분리

단점

표준 자체가 존재하지 않아 정의가 필요
사용할 수 있는 메소드가 4가지뿐
HTTP Method 형태가 제한적
브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URI보다 Header 정보의 값을 처리해야 하므로 전문성 요구
구형 브라우저에서 호환되지 않아 지원해주지 못하는 동작이 많음 (Ex. 익스플로어)

RESTful

: REST 원리를 따르는 시스템

하지만 REST를 사용했다고 모두 RESTful한 것은 아니다.
REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다고 할 수 있다.

모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 지키지 않은 API는 REST API를 사용하였지만 RESTful하지 못한 시스템이라고 할 수 있다.

🔗 참고하면 좋을 포스트
🔗 참고하면 좋을 포스트

✔️ 웹 브라우저 동작 과정

예전에 다른 분 포스트 보고 공부한건데 출처가 기억 안 남😢

✔️ OS Thread vs Process

Thread

: 프로세스 내 실행되는 여러 흐름의 단위
프로세스의 특정한 수행 경로
프로세스가 할당ㅂ다은 자원을 이용하는 실행의 단위라고 할 수 있다.

특징

thread는 프로세스 내 각 stack만 따로 할당받고 code, data, heap 영역은 공유한다.
thread는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내 주소 공간이나 자원들을 같은 프로세스 내 thread끼리 공유하며 실행된다.
같은 프로세스 안에 있는 여러 thread들은 같은 힙 공간을 공유하는 반면 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다.
각 thread는 별도의 레지스터와 스택을 가지고 있지만, 힙 메모리는 서로 읽고 쓸 수 있다.
한 thread가 프로세스 자원을 변경하면, 다른 이웃 thread(sibling thread)도 그 변경 결과를 즉시 볼 수 있다.

Process

: 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램
메모리에 올라와 실행되고 있는 프로그램의 인스턴스(독립적은 개체)
os로부터 시스템 자원을 할당받는 작업의 단위
라고 할 수 있는데 즉, 동적인 개념으로는 실행된 프로그램을 의미한다.

특징

프로세스는 각 독립된 메모리 영역(code, data, stack, heap)을 할당받는다.
기본적으로 프로세스당 최소 1개의 thread(main thread)를 가진다.
각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다.
한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC)을 사용해야 한다. (Ex. 파이프, 파일, 소켓 등을 이용한 통신 방법)

📌 IPC

: Inter-Process Communication
프로세스들 사이 서로 데이터를 주고받는 행위 또는 그에 대한 방법이나 경로

Multi Process vs Multi Thread

Multi Process

: 하나의 응용 프로그램을 여러개의 프로세스로 구성하여 각 프로세스가 하나의 작업(task)을 처리하도록 하는 것

장점

여러개의 자식 프로세스 중 하나에 문제가 발생하면 그 자식 프로세스만 죽고 다른 것에 영향을 미치지 않는다.

단점

Context Switching에서의 오버헤드
(*Context Switching: CPU에서 여러 프로세스를 돌아가며 작업을 처리하는데 이 과정을 Context Switching이라고 함)
- 이 과정에서 캐시 메모리 초기화 등 무거운 작업이 진행되고 많은 시간이 소모되는 등의 오버헤드가 발생한다.
- 프로세스는 각각의 독립된 메모리 영역을 할당받았기 때문에 프로세스 사이 공유하는 메모리가 없어, Context Switching이 발생하면 캐시에 있는 모든 데이터를 모두 리셋하고 다시 캐시 정보를 불러와야 한다.
프로세스 사이 어렵고 복잡한 통신 기법(IPC)
- 프로세스는 각각의 독립된 메모리 영역을 할당받았기 때문에 하나의 프로그램에 속하는 프로세스들 사이의 변수를 공유할 수 없다.

Multi Thread

: 하나의 응용 프로그램을 여러 개의 스레드로 구성하고 각 스레드로 하여금 하나의 작업을 처리하는 것
웹 서버가 대표적인 멀티 스레드 응용 프로그램

장점

시스템 자원 소모 감소 (자원의 효율성 증대)
- 프로세스를 생성해 자원을 할당하는 시스템 콜이 감소해 자원을 효율적으로 관리
시스템 처리량 증가 (처리 비용 감소)
- 스레드 간 데이터를 주고 받는 것이 간단해지고 시스템 자원 소모 감소
- 스레드 사이 작업량이 작아 Context Switching이 빠름
간단한 통신 방법으로 인한 프로그램 응답 시간 단축
- 스레드는 프로세스 내 stack 영역을 제외한 모든 메모리를 공유하기 때문에 통신의 부담이 적음

단점

주의깊은 설계가 필요
디버깅 까다로움
단일 프로세스 시스템의 경우 효과를 기대하기 어려움
다른 프로세스에서 스레드를 제어할 수 없음 (즉, 프로세스 밖에서 스레드를 각각 제어할 수 없음)
멀티 스레드의 경우 자원 공유의 문제 발생 (동기화 문제)
하나의 스레드에 문제가 발생하면 전체 프로세스가 영향을 받음

그래서 멀티 프로세스 대신 멀티 스레드를 사용하는 이유

프로그램 여러 개(멀티 프로세스) vs 하나의 프로그램 안에서 여러 작업(멀티 스레드)

우선, 프로세스를 생성해 자원을 할당하는 시스템 콜이 줄어들기 때문에 자원의 효율성을 높일 수 있다.
멀티 프로세스일 때는 프로세스 간 Context switching시 단순히 CPU 레지스터 교체 뿐만 아니라 RAM과 CPU 사이의 캐시 메모리에 대한 데이터까지 초기화되므로 오버헤드가 크다.
하지만 스레드는 프로세스 내 메모리를 공유하기 때문에 독립적인 프로세스와 달리 스레드 간 데이터를 주고 받는 것이 간단해지고 시스템 자원 소모가 줄어든다.

또한 처리 비용 감소되고 응답 시간이 단축된다.
프로세스 간 통신(IPC)보다 스레드 간 통신 비용이 적어 작업들 간의 통신 부담이 줄어든다. (스레드는 stack 영역을 제외한 모든 메모리를 공유하기 때문)
프로세스 간 전환 속도보다 스레드 간 전환 속도가 빠르다. (context switching시 스레드는 stack 영역만 처리하기 때문)

하지만 스레드 간 자원 공유는 전역 변수 (데이터 세그먼트)를 이용하므로 함께 상용할 때 충돌이 발생할 수 있다는 점을 주의해야 한다.

✔️ PCB

: Process Control Block

운영체제가 프로세스를 제어하기 위해 정보를 저장해 놓는 곳
즉, 프로세스의 상태 정보를 저장하는 자료구조

운영체제에서 프로세스는 PCB로 표현된다.
프로세스가 생성될 때마다 고유 PCB가 생성되고 프로세스가 완료되면 PCB도 함께 제거된다.

이는 프로세스 상태 관리와 Context Switching을 위해 필요하다.

OS에 따라 PCB에 포함되는 항목이 다를 수 있지만 일반적으로 포인터, 프로세스 상태, 프로세스 번호, 프로그램 카운터, 레지스터, 메모리 제한,열린 파일 목록...이 있다.

OS는 빠르게 PCB에 접근하기 위해 프로세스 테이블을 사용해 각 프로세스의 PCB를 관리한다.

✔️ DB Transaction

Transaction: 쪼개질 수 없는 업무처리의 단위
commit: 모든 부분 작업이 정상적으로 완료되면 이 변경사항을 한번에 DB에 반영
rollback: 부분 작업이 실패하면 트랜잭션 실행 전으로 되돌림

트랜잭션의 개념

DB 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위
DB 시스템에서 복구 및 병행 수행 시 처리되는 작업의 논리적 단위
한꺼번에 수행되어야 하는 일련의 연산

특징 (ACID)

원자성(Atomicity)
: 트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 한다.
일관성(Consistency)
: 트랜잭션의 작업 처리 결과는 항상 일관성을 가져야 한다.
독립성(Isolation)
: 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다. (하나의 특정 트랜잭션이 완료될 때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.)
영속성(Durability)
: 트랜잭션이 성공적으로 완료 되었다면 결과는 영구적으로 반영되어야 한다.

✔️ Deadlock (교착상태)

: 프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태
시스템적으로 한정된 자원을 여러 곳에서 사용할 때 발생

Deadlock 발생 조건

교착 상태는 한 시스템 내에서 다음 네 가지 조건이 동시 성립될 때 발생한다.

상호 배제(Mutual exclusion)
자원은 한 번에 한 프로세스만이 사용할 수 있어야 한다.
점유 대기(Hold and wait)
최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 있어야 한다.
비선점(No preemption)
다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 빼앗을 수 없어야 한다.
순환 대기(Circular wait)
프로세스의 집합 {P0, P1, ... Pn}에서 P0은 P1이 점유한 자원을 대기, P1은 P2가 점유한 자원을 대기 ... Pn-1은 Pn이 점유한 자원을 대기하며 Pn은 P0이 점유한 자원을 요구해야 한다.

✔️ 동기화

임계 구역(Critical Section)

: 프로세스 간 공유 자원을 접근하는 데 있어 문제가 발생하지 않도록 한 번에 하나의 프로세스만 이용해 다른 프로세스들의 접근을 제한하는 영역

임계 구역 문제를 해결하기 위한 방법

상호 배제(Mutual Exclution) - 스핀락, 뮤텍스
: 하나의 프로세스가 임계 구역에 들어가 있다면 다른 프로세스는 들어갈 수 없어야 한다.
진행(Progress)
: 들어가려는 프로세스가 여러 개라면 어느 것이 들어갈지 결정해주어야 한다.
한정된 대기(Bounded Waiting)
: 다른 프로세스의 기아(Starvation)를 막기 위해 한 번 임계 구역에 들어간 프로세스는 다음번 임계 구역 접근에 제한이 생겨야 한다.

스핀락 Spinlock

: 특정한 자원을 획득(Lock) 또는 해제(Unlock)를 통해 공유 자원에 대한 접근 권한을 관리하는 방법

권한을 획득하기 전까지 CPU는 무의미한 코드를 수행하는 Busy Waiting 상태로 대기하고 있다가 접근 권한을 얻게되면 내부 코드를 수행하고 종료 후 권한을 해제한다.

상태가 획득, 해제 뿐이기 때문에 공유 영역에서는 하나의 컴포넌트만 접근이 가능하다.
(획득, 해제의 주체는 동일해야 한다.)

하나의 작업이 빠르게 수행될 수 있다는 장점이 있지만, 선점 기간 동안에는 다른 프로세스의 작업이 지연될 수 있는 오버 헤드가 존재한다.
그래서 짧게 수행할 수 있는 작업에 주로 사용된다.

뮤텍스 Mutex

: MUTual EXclusion으로 상호 배제라고도 한다.

획득(Lock), 해제(Unlock) 상태가 있으며 스핀락과 같이 접근 권한을 획득할 때까지 BusyWating 상태에 머무르지 않고 Sleep 상태가 되며 Wakeup이 되면 권한 획득을 시도한다.

뮤텍스의 경우엔 Locking 메커니즘으로 오직 하나의 스레드만이 동일 시점에 뮤텍스를 얻어 임계 구역(Critical Section)에 접근할 수 있다.
(마찬가지로 획득, 해제의 주체는 동일해야 한다.)

세마포어 Semaphore

: 스핀락과 뮤텍스와는 다르게 하나 이상의 스레드가 공유 자원에 접근할 수 있도록 함
(예전에 많이 사용되던 방식)

표현형은 정수로 표현하며 획득, 해제가 아닌, 값을 올리고 내리는 방식을 사용한다.

컴포넌트가 특정 자원에 접근할 때 semWait이 먼저 호출되어 임계 구역에 들어갈 수 있는지 확인한다.
조건에 만족한다면 semWait을 빠져나와 임계 구역에 들어가게 되고 이후 semSignal이 호출되어 임계 구역을 빠져나오게 된다.

semWait연산: 세마포어의 값을 감소시킴
만약 값이 음수가 되면 semWait을 호출한 스레드는 블록되지만 음수가 아니라면 스레드는 작업을 수행

semSignal연산: 세마포어의 값을 증가시킴
만약 값이 양수가 아니라면 semWait 연산에 의해 블록된 스레드들을 wake 시킴

세마포어 vs 뮤텍스

세마포어의 경우 여러 개의 스레드가 접근할 수 있는 반면 뮤텍스는 오직 한 개의 스레드만 접근 가능

세마포어는 현재 수행 중인 스레드가 아닌 다른 스레드가 세마포어 해제를 할 수 있지만 뮤텍스의 경우 획득하고 해제하는 주체가 동일해야 함 (lock을 획득한 프로세스가 unlock까지)

모니터 Monitor

: 상호배제 락에 의해 보호되는 일련의 루틴
락을 획득하기 전까지는 스레드에서 모니터에 속하는 어떤 루틴도 실행시킬 수 없다.

모니터 안 항상 하나의 프로세스만이 활성화 되도록 보장하여 프로그래머들은 동기화 제약 조건을 명시적으로 코딩하지 않아도 된다.
(자바 프로그램에서는 모니터에 대한 활용이 활발)

모니터는 세마포어 이후 프로세스 동기화 도구이다. 그리고 세마포어보다 고수준 개념을 담고있다.

공유자원 + 공유자원 접근함수로 구성

2개의 queues: 배터동기(Mutual exclusiton queue) + 조건동기(Conditional synchronization)

공유자원 접근함수에는 최대 한 개의 스레드만 진입 가능
➡️ 나머지 진입하지 못한 스레드들은 큐에서 대기 (Mutual exclusion queue)

진입 스레드가 조건 동기로 블록되면 새 스레드 진입 가능
➡️ wait call
들어왔던 스레드는 Conditional synchronization에 갇히게 되고 새 스레드는 진입 가능해짐

새 스레드는 조건동기로 블록된 스레드를 깨울 수 있음
➡️ notify(): 블록됨 스레드를 깨움

깨워진 스레드는 현재 스레드가 나가면 재진입 가능
➡️ 하나의 스레드만 있을 수 있으므로 그 비워진 자리에 깨워진 스레드가 들어올 수 있게 됨

자바에서는 모든 객체가 모니터가 될 수 있다.

배타동기: synchronization 키워드를 사용해 지정. 한 스레드에만 접근 가능.
조건동기: wait(), notify(), notifyAll() 메소드 사용

세마포어 vs 모니터

세마포어에 비하여 모니터 쪽이 공유자원에 접근할 수 있는 키의 획득과 해제를 모두 처리해 간단하다.
세마포어는 직접 키 해제와 공유자원 접근 처리를 해주어야 한다.

💡 모니터(Monitor)에 대한 내용은 개념을 모두 이해해 정리하여 쓴 내용이 아니기 때문에 오류가 있을 수 있음

오토믹 Atomic

✔️ Java

내용이 많아 게시물로 따로 정리해 링크 올려둘 것

✔️ TCP & UDP

: 전송 계층에서 데이터를 보내기 위해 사용하는 프로토콜

TCP

: Transmission Control Protocol
연결형 서비스를 지원하는 프로토콜

연결형 서비스로 가상 회선 방식을 제공
3-way handshaking 과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제
흐름 제어 및 혼잡 제어
높은 신뢰성 보장
속도 느림
전이중(Full-Duplex), 점대점(Point to Point) 방식
파일 전송과 같은 경우에 사용. 스트리밍 서비스에 불리.
서버-클라이언트는 1:1

UDP

: User Datagram Protocol
비연결형 서비스를 지원하는 프로토콜

각각의 패킷이 다른 경로로 전송되어 독립적인 관계를 지닌다.

handshaking과 같은 절차가 없음
헤더의 CheckSum 필드를 통해 최소한의 오류 검출
신뢰성 낮음
속도 빠름
실시간 서비스 즉, 스트리밍 서비스에 적합
소켓 대신 IP를 기반으로 데이터 전송
서버-클라이언트는 1:1, 1:N, N:M이 가능
흐름 제어가 없어 패킷이 제대로 전송되었는지 오류가 없는지 확인할 수 없음

즉, 신뢰성보단 연속성이 중요한 서비스에 이용된다.

TCP vs UDP

✔️ 세그멘테이션 & 페이징

메모리 관리 기법

연속 메모리 기법

: 프로그램 전체가 메모리에 연속적으로 할당되어야 하는 관리 기법

고정 분할 기법: 메모리가 고정된 파티션으로 분할 → 내부 단편화 발생(필요한 만큼 차지하고 나면 남는 아까운 공간들)
동적 분할 기법: 파티션들의 동적 생성, 자신의 크기와 같은 파티션에 적재 → 외부 단편화 발생 (필요한 메모리 공간은 있지만 띄엄띄엄 있어 어차피 사용할 수 없는 경우)

불연속 메모리 관리

: 프로그램의 일부가 서로 다른 주소 공간에 할당될 수 있도록 하는 기법

Page: 프로세스를 고정된 크기의 작은 블록으로 나누었을 때, 그 블록을 페이지라고 함
Frame: 페이지 크기와 같은 주 기억장치 메모리 블록
Segment: 서로 다른 크기의 논리적 단위

메모리 단편화 Memory Fragmentation

: 메모리 공간이 조각조각 나뉘게 되어 실제로는 사용 가능한 메모리가 충분한데도 불구하고 할당이 불가능한 상태
(내부 단편화, 외부 단편화)

이를 해결하기 위한 방안으로 Paging, Segmentation이 있다.

Paging

프로세스는 페이지로 나누어지며 물리 메모리는 프레임으로 나뉨
페이지 테이블에는 각 페이지 번호와 해당 페이지가 할당된 프레임의 시작 물리 주소 저장
CPU는 논리 주소로 프로그램이 설정한대로 연속적인 주소값으로 명령을 내리고 이는 메모리로 가기 전 각 페이지의 실제 메모리 주소가 저장되어 있는 테이블에서 물리 주소로 변경
만약 프로세스가 프레임의 정수배보다 살짝 작다면 할당된 마지막 프레임은 전부 사용되지 않고 남아버리는 내부 단편화가 발생 (페이지가 클수록 내부 단편화가 커짐)
가상 메모리 사용

Segmentation

사용자/프로그래머 관점의 메모리 관리 기법
Segment: 페이지 같은 개념이지만, 프로세스를 논리적 내용을 기반으로 나누어 메모리에 배치
➡️ 프로세스를 Code, Data, Stack으로 나누는 것 역시 세그멘테이션
세그먼트 테이블은 세그먼트 번호와 시작 주소(base), 세그먼트 크기(limit)을 엔트리로 가짐
가상 메모리 사용
CPU에서 해당 세그먼트의 크기를 넘어서는 주소가 들어오면 인터럽트가 발생해 해당 프로세스를 강제종료

Paging vs Segmentation

paging은 고정 크기를 가짐
segmentation은 가변 크기를 가짐
paging은 내부 단편화 발생 가능
segmentation은 외부 단편화 발생 가능

paging과 segmentation을 사용하는 이유

Memory fragmentation(메모리 단편화)을 해결하기 위함
다중 프로그래밍 시스템에서 여러 프로세스를 수용하기 위해 주기억장치를 동적 분할하는 메모리 관리 기법이 필요함

✔️ DB Index

: 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조

인덱스를 활용하면 데이터를 조회하는 SELECT 이외에도 UPDATE나 DELETE의 성능이 함께 향상된다.
(UPDATE나 DELETE 또한 해당 대상을 조회해야만 작업할 수 있기 때문)

index를 사용하지 않은 컬럼을 조회한다면 전체를 비교하여 탐색하는 Full Scan을 수행해야 하므로 처리 속도가 떨어진다.

더 자세한 내용은 🔗망나니개발자님 참고

B Tree

B Tree는 밸런스 트리 (Balanced Tree)의 대표적인 예 중 하나이다.

밸런스 트리 Balanced Tree

: 트리의 노드가 한 방향으로 쏠리지 않도록, 노드 삽입 및 삭제 시 특정 규칙에 맞게 재정렬하여 왼쪽과 오른쪽 자식 양쪽 수의 밸런스를 유지하는 트리

➡️ 최악의 경우에도 O(logN)

탐색 시간이 더 빠른 해시 대신 B Tree를 사용하는 이유

해시 테이블은 O(1) 시간 복잡도를 가진다. (해시 충돌 등 최악의 경우에는 O(N)이 될 수 있지만 편균적으로는 O(1))

하지만 이 시간 복잡도는 단 하나의 데이터를 탐색하는 시간 에서 가질 수 있다.
즉, 간단히 1~10까지 저장되어 있을 때 3을 찾는 그런 상황에서만 가진다는 것이다.

분명히 그런 상황만 존재하는 것이 아니다.
3보다 크거나 같은 경우 를 탐색할 때와 같이 부등호가 들어가면 찾기 힘들어진다.

모든 값이 정렬되어 있지 않아 해시 테이블에서는 특정 기준보다 크거나 작은 값을 찾을 수 없다.
(찾을 수야 있지만 O(1)을 보장하지 않음)

그래서 O(1)의 시간 복잡도를 가진 해시 대신 B Tree를 사용하는 것이다.

✔️ 자료구조

Map vs HashMap

Map

key-value를 가진 집합

중복 허용 X ➡️ 하나의 key에 하나의 value

jata.util 패키지에 여러 집합들을 사용하기 위한 여러 인터페이스와 클래스들이 정의되어 있음

HashMap

Map interface를 implements(구현)한 클래스

중복 허용 X

Map과 같이 key-value로 이루어짐

key 또는 value 값으로 null 허용

순서 유지 X

List vs Array

List

배열이 가진 index라는 장점을 버리고 빈틈없는 데이터 적재라는 장점을 가짐

순서가 있는 데이터 모음

리스트에서의 인덱스 → 몇 번째 데이터인가
(배열에서의 인덱스는 유일무이 식별자)

비어있는 원소 허용 X

순서를 보장하지 않아 cash hit 어려움

데이터 개수가 정해져 있고 자주 사용된다면 List보단 Array

Array

배열에서의 인덱스는 값에 대한 유일무이한 식별자

크기가 정해져있음

원소들의 인덱스 불변

인덱스를 활용한 빠른 조회 가능

cache hit의 가능성이 커 성능에 도움

하지만 인덱스 값이 불면인 만큼 삭제된 원소의 공간이 그대로 남아 메모리 낭비 발생

Stack vs Queue

Stack

LIFO (Last In First Out, 후입선출)

스택의 구현은 Array 또는 Linked List

대표적으로 프로그램을 수행할 때 사용됨
(Main 프로그램에서 함수 A를 호출하면 Main 위에 A가 쌓이고, A 수행 중 B가 호출되면 A위 B가 스택처럼 쌓임)

Queue

FIFO (First In First Out, 선입선출)

큐의 구현은 Array 또는 Linked List

여러 프로세스가 수행중일 때 새로운 프로세스가 수행되어야 하는 경우, 기존에 수행되던 프로세스 중 가장 먼저 메모리에 올라온 프로세스가 실행되고, 새로운 프로세스를 메모리에 올림 ➡️ 이런 경우 큐의 형태로 관리

✔️ Sort 정렬 종류

종류가 너무 많아 링크 대체

해당 🔗링크에 Bubble, Selection, Insertion, Quick, Merge, Heap, Radix, Counting 정렬이 정말 잘 정리되어 있으니 참고하기

✔️ OSI 계층

🔗OSI 7계층

[📌출처 ]

윤경

개발 바보 이사 중

이전 포스트

[CS][Java]

다음 포스트