두 개 이상의 테이블을 서로 연결하여 데이터를 검색할 때 사용하는 방법

두 개의 테이블을 마치 하나의 테이블인 것처럼 보여준다.

Join문은 여러 종류가 있는데, 하나씩 특징을 살펴보자.

Implicit join

• from 절에는 table들만 나열하고 where절에 join condition을 명시하는 방식
• 예전 방식의 join 문법
• 복잡해질수록 실수할 가능성이 높다

SELECT D.name 
FROM employee AS E, department AS D 
WHERE E.id = 1 and E.dept_id = D.id;

Explicit join

• from 절에 JOIN 키워드와 함께 joined table들을 명시하는 방식
• from 절에서 ON 뒤에 join condition이 명시된다
• 복잡한 join 쿼리 작성 중에도 실수할 가능성이 적다

SELECT D.name
FROM employee AS E JOIN department AS D ON E.dept_id = D.id
WHERE E.id = 1;

Inner join(join)

• 그냥 JOIN 으로 사용가능(INNER 생략 가능)
• 두 table에서 join condition을 만족하는 tuple들로 result table(결과 테이블)을 만드는 join
• join condition에 사용 가능 연산자 : =, <, >, ≠ 등 여러 비교 연산자 가능
• join condition에서 null 값을 가지는 tuple은 result table에 포함되지 않는다

SELECT *
FROM employee E INNER JOIN department D on E.dept_id = D.id;

Outer join

• LEFT, RIGHT, FULL OUTER JOIN 이 존재(OUTER 생략 가능)
  • LEFT JOIN
    • 왼쪽 table에서 join condition을 만족하지 않는 tuple들도 result table에 포함
  • RIGHT JOIN
    • 오른쪽 table에서 join condition을 만족하지 않는 tuple들도 result table에 포함
  • FULL JOIN (mysql에서는 지원X)
    • 두 table에서 join condition을 만족하지 않는 tuple들도 result table에 포함하는 join

Using

• USING 키워드를 사용하여 동일한 이름을 갖는 열에 대해 조인을 수행하는 방식
• ON 절과 같은 결과를 만들지만, 동일한 이름을 갖는 열을 명시적으로 사용할 수 있음

SELECT *
FROM employee AS E JOIN department AS D USING (dept_id);

Natural join

• 두 테이블 간 동일한 이름을 갖는 모든 열을 기준으로 조인하는 방식
• NATURAL JOIN은 동일한 이름을 갖는 열을 자동으로 인식하여 조인
• 열 이름이 동일하지 않으면 자연 조인을 사용할 수 없음

SELECT *
FROM employee AS E NATURAL JOIN department AS D;

Cross join

• 두 테이블 간의 모든 조합을 반환하는 조인 방식
• 조인 조건이 없기 때문에 카테시안 곱(Cartesian Product)라고도 함
• 조인 결과가 매우 클 수 있음

SELECT *
FROM employee AS E CROSS JOIN department AS D;

Join 종류 요약

• Implicit join: WHERE 절을 사용하여 조인 조건을 명시
• Explicit join: JOIN 키워드를 사용하여 조인 조건을 명시
• Inner join: 두 테이블 간 조인 조건을 만족하는 튜플만 반환
• Outer join: 조인 조건을 만족하지 않는 튜플도 포함
  • LEFT JOIN: 왼쪽 테이블의 모든 튜플 포함
  • RIGHT JOIN: 오른쪽 테이블의 모든 튜플 포함
  • FULL JOIN: 두 테이블의 모든 튜플 포함
• Using: 동일한 이름을 갖는 열을 기준으로 조인
• Natural join: 동일한 이름을 갖는 모든 열을 기준으로 조인
• Cross join: 두 테이블의 모든 조합을 반환

데이터베이스 정규화는 DB를 설계하는 공식적인 방법이다. DB를 설계하는 방법의 기본이 되는 함수 종속(functional dependency)과 이를 사용해 정규화하는 방법을 알아보자.

functional dependency(FD)?

FD(함수 종속)는 한 테이블에 있는 두 개의 attribute의 집합 사이의 제약이다.

이해를 위해 EMPLOYEE라는 임의의 테이블을 만들어 예로 들어보면

EMPLOYEE

이때의 { empl_id }를 집합 X, { empl_name, birth_date, position, salary }가 집합 Y 라고 가정했을 때,

두 튜플의 X 값이 같다면 Y 값도 같다는 특징이 있다. 왜냐하면 empl_id는 임직원들 개인에게 부여되는 고유값일 텐데, empl_id가 같다면 그 값에 해당하는 속성들도 같을 것이기 때문이다.

이렇듯 X 값에 따라 Y 값이 유일하게 결정될 때, ‘X가 Y를 함수적으로 결정한다’ 라고 말할 수 있고, 이러한 두 집합 사이의 제약 관계를 functional dependency(FD) 라고 부른다.

⚠️FD를 파악할 때 주의 사항

테이블의 스키마를 보고 의미적으로 파악해야 한다.

즉, 테이블의 state를 보고 FD를 파악해서는 안된다.

다시 위의 EMPLOYEE 테이블로 예를들자면

EMPLOYEE

FD를 파악할 때는 테이블의 state 즉, 테이블의 데이터를 보고 판단하면 안되는데 위의 데이터만 보면 empl_name과 birth_date 사이에 FD가 존재하는 것처럼 보인다. 하지만 empl_name에는 동명이인이 있을 수 있다. 그렇게 되면 같은 empl_name이지만 다른 birth_date를 가지게 되며 이는 더 이상 FD가 성립하지 않는 것을 보여준다.

정규화(Normalization)?

데이터베이스 정규화는 데이터베이스 내의 데이터 구조를 조직화하고 최적화하는 과정이다. 정규화의 목적은 데이터 중복을 제거하고, 효율성을 향상시키며, 데이터 무결성을 보장하기 위함이다.

이러한 정규화에는 여러 단계가 있는데 보통 3NF 또는 BCNF까지만 정규화를 진행한다.

모든 정규화는 이전 정규화 단계를 만족해야 진행 가능하다.

제 1 정규화(1NF)

제 1 정규화는 테이블의 컬럼이 원자값을 갖도록 테이블을 분해하는 것이다. 간단히 말해 모든 필드가 단일 값만을 가져야 하며, 중복된 컬럼이나 중첩된 레코드가 없어야 한다.

제 2 정규화(2NF)

제 2 정규화는 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다. 예를 들어, 두 개의 컬럼이 결합되어 기본키가 된 composite key라면 비식별자(Non-Key-Attribute)가 두 컬럼 모두에게 종속되어야지 한 컬럼에만 종속되면 안된다.

제 3 정규화(3NF)

제 3 정규화는 이행 종속성을 제거하여 데이터의 중복을 줄이는 것이다. 2NF를 만족하고, 비식별자가 다른 비식별자에게 종속되지 않아야 한다.

보이스-코드 정규화(BCNF, Boyce-Codd Normal Form)

BCNF는 3NF에서 해결되지 않는 특정 종속성을 제거하여 데이터의 중복을 방지하는 것이다. 3NF를 만족하고, 모든 결정자가 후보키가 되어야 한다.

제 4 정규화(4NF)

제 4 정규화는 다치 종속성(Multivalued Dependency)을 제거하는 것이다. BCNF를 만족하고, 다치 종속성을 갖지 않아야 한다.

제 5 정규화(5NF)

제 5 정규화는 조인 종속성(Join Dependency)을 제거하여 데이터를 완전히 분리하는 것이다. 4NF를 만족하고, 조인 종속성을 갖지 않아야 한다.

서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)은 웹 애플리케이션에서 콘텐츠를 렌더링하는 두 가지 주요 방식이다. 각각의 개념, 특징 및 차이점을 알아보자.

서버 사이드 렌더링 (Server Side Rendering, SSR)

개념

SSR은 웹 서버가 HTML 콘텐츠를 생성하여 클라이언트(브라우저)로 전송하는 방식이다. 서버에서 모든 HTML이 준비되어 전송되기 때문에 브라우저는 HTML을 받아 바로 렌더링할 수 있다.

특징

• 빠른 초기 로드 시간 : 서버에서 완성된 HTML을 전송하기 때문에 첫 페이지 로드가 빠르다.

• 검색 엔진 최적화(SEO) : 검색 엔진 크롤러가 완전한 HTML을 인덱싱할 수 있어 SEO에 유리하다.

• 낮은 코드 복잡성 : 클라이언트 측에서 복잡한 자바스크립트 코드가 필요하지 않다.

클라이언트 사이드 렌더링 (Client Side Rendering, CSR)

개념

CSR은 브라우저가 자바스크립트 코드를 다운로드하여 실행하면서 HTML을 동적으로 생성하는 방식이다. 서버는 주로 JSON 데이터를 전송하며, 브라우저는 이를 기반으로 콘텐츠를 렌더링한다.

특징

• 뛰어난 상호작용 : CSR은 사용자와의 상호작용이 많은 애플리케이션에 적합하다. 자바스크립트를 이용해 페이지 일부를 동적으로 갱신할 수 있다.
• 초기 로드 시간 지연 : 초기에는 자바스크립트 파일을 모두 다운로드하고 실행해야 하기 때문에 첫 페이지 로드가 느릴 수 있다.
• 불리한 검색 엔진 최적화(SEO) : 검색 엔진 크롤러는 자바스크립트를 실행하지 못하기 때문에, 초기 로드 시에 HTML이 비어있을 수 있어 SEO에 불리할 수 있다. (이 문제는 최근 서버에서 미리 렌더링하는 방식인 하이브리드 렌더링으로 개선 가능하다.)

차이점

초기 로드 시간

• SSR: 초기 로드가 빠르며, 서버에서 이미 렌더링된 HTML을 받는다.
• CSR: 자바스크립트를 다운로드하고 실행해야 하므로 초기 로드가 느리다.

검색 엔진 최적화(SEO)

• SSR: 검색 엔진이 완성된 HTML을 인덱싱할 수 있어 SEO에 유리하다.
• CSR: 초기 로드 시 HTML이 비어 있을 수 있어 SEO에 불리하다.

사용자 경험

• SSR: 초기 로드가 빠르지만 페이지 전환 시 서버 요청이 필요해 느릴 수 있다.
• CSR: 초기 로드는 느리지만, 한 번 로드된 이후에는 페이지 전환이 빠르다.

복잡성

• SSR: 서버 쪽에서 렌더링을 처리하기 때문에 클라이언트 측 코드가 단순하다.
• CSR: 클라이언트 측에서 렌더링을 처리하기 때문에 복잡한 자바스크립트 코드가 필요하다.

요약

• SSR: 서버에서 HTML을 렌더링하여 클라이언트에 전송. 초기 로드가 빠르고 SEO에 유리하지만, 상호작용이 적은 웹사이트에 적합하다.
• CSR: 클라이언트에서 자바스크립트를 이용해 HTML을 동적으로 생성. 초기 로드가 느리지만 상호작용이 많고 동적인 웹 애플리케이션에 적합하다.

최근에는 두 가지 방식의 장점을 결합한 하이브리드 렌더링 방식을 사용하는 경우도 많다. 예를 들어 Next.js와 같은 프레임워크는 초기에는 SSR을 사용하고, 이후에는 CSR을 사용하는 방식으로 웹 애플리케이션을 최적화한다.

대용량 데이터 처리를 위한 미들웨어(서로 다른 어플리케이션이 서로 통신하는데 사용되는 소프트웨어)이다.

메시지 브로커와 이벤트 브로커의 차이점

• 메세지 브로커: 메시지 브로커는 시스템 간의 메시지 전달을 관리하고 조정하는 소프트웨어다. 메시지를 큐에 저장하고, 메시지를 전송하거나 수신하는 시스템 간의 비동기적 통신을 지원한다. 메시지 브로커는 메시지를 일시적으로 저장하여 수신자가 사용할 준비가 될 때까지 보관한다.

• 이벤트 브로커: 이벤트 브로커는 이벤트 기반 아키텍처에서 이벤트를 관리하는 역할을 한다. 이벤트 브로커는 이벤트 소스(프로듀서)로부터 이벤트를 받아 이벤트 핸들러(컨슈머)에게 전달한다. 이벤트 브로커는 주로 이벤트 스트리밍을 지원하며, 실시간으로 데이터를 처리하고 반응하는 데 중점을 둔다.

메시지 브로커 모델의 종류와 특징

1. 포인트 투 포인트(Point-to-Point) 모델

   • 메시지 큐를 사용하여 하나의 프로듀서가 하나의 컨슈머에게 메시지를 전송한다.
   • 메시지는 한 번만 전달되며, 한 컨슈머만 해당 메시지를 처리한다.
   • 특징: 단순하고 확실한 메시지 전달 보장, 큐에 쌓인 메시지는 하나의 컨슈머에 의해 처리됨.

2. 발행/구독(Publish/Subscribe) 모델

   • 토픽을 사용하여 하나의 프로듀서가 여러 컨슈머에게 메시지를 전송한다.
   • 여러 구독자가 동일한 토픽의 메시지를 수신하고 처리할 수 있다.
   • 특징: 메시지의 광범위한 전파 가능, 여러 구독자가 동시에 메시지를 처리.

메시지 브로커의 동작 개념

메시지 브로커는 메시지가 적재되는 공간인 메시지 큐(Message Queue)를 통해 작동한다. 메시지의 그룹은 토픽(Topic)으로 묶이며, 각 구독자는 특정 토픽에 맞는 메시지만 전달받는다. 프로듀서와 컨슈머는 메시지를 전송하고 수신하는 역할을 수행하며, 메시지 큐는 이들 간의 버퍼 역할을 한다. 이러한 구조 덕분에 수신자는 자신이 원할 때 메시지를 가져갈 수 있으며, 비동기적으로 메시지를 처리할 수 있다.

기존의 데이터 전달 구조에서는 생산자와 전달자가 직접 연결되어 있어, 구독자가 불안정할 경우 데이터가 손실되는 문제가 있었다. 그러나 메시지 브로커를 사용하면 메시지가 큐에 안전하게 적재되어 구독자가 불안정한 상황에서도 메시지가 보존된다.

메시지 브로커의 대표적인 예 : RabbitMQ와 Kafka

RabbitMQ

• AMQP(Advanced Message Queuing Protocol)를 사용하여 메시지를 전송한다.
• 브로커 기반의 메시징 시스템으로, 메시지를 큐에 저장하고 소비자가 처리할 준비가 되었을 때 전달한다.
• 복잡한 라우팅 및 메시지 큐 관리 기능을 제공하며, 메시지의 신뢰성과 전달 보장을 강조한다.
• 메시지 전달 보장이 필수적이다.
• 메시지 처리 순서가 보장되지 않으며, 메시지가 큐에서 삭제되면 영속성을 보장할 수 없다.
• 작은 서비스의 메시지 브로커를 구축하는 데 적합하다.
• 메시지가 성공적으로 전달되었다고 판단하면 큐에서 삭제하기 때문에 이를 다시 재생하기 어렵다.
• 트래픽이 증가하여 메시지가 증가하면 수평적으로 확장하는 데 어려움이 존재한다.

Kafka

• 분산 스트리밍 플랫폼으로, 대용량의 실시간 데이터 스트리밍을 처리하는 데 중점을 둔다.
• 메시지를 토픽에 저장하고, 각 메시지는 오프셋을 통해 순서대로 관리된다.
• 높은 처리량과 내구성을 제공하며, 이벤트 소싱 및 로그 수집과 같은 시나리오에 적합하다.
• 메시지 처리 순서가 보장되며, 메시지의 영속성이 보장된다.
• 스케일 아웃이 중요한 경우에 적합하다.
• 이벤트 스트리밍 플랫폼으로, 메시지를 토픽에 순서대로 기록하며, 토픽을 유지하기 때문에 오류가 나도 이벤트를 다시 재생할 수 있다.
• 클러스터로 실행되며, 여러 브로커가 하나의 카프카 서버 내에서 동작한다.
• 모든 데이터 스트림 처리를 위한 중심 플랫폼 역할을 한다.

정리

RabbitMQ는 큐 기반 메시징 시스템으로 메시지의 신뢰성과 전달 보장을 강조하며, 작은 서비스에 적합하다. Kafka는 대규모 데이터 스트리밍과 이벤트 소싱에 최적화되어 있으며, 높은 처리량과 메시지의 영속성을 보장하는 데 중점을 둔다. 사용 목적과 요구 사항에 따라 두 시스템 중 하나를 선택할 수 있다.

OSI 7 계층은 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말한다. 계층을 나눈 이유는 통신이 일어나는 과정이 단계별로 파악할 수 있기 때문이다. 흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽고, 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있기 때문이다.

1. 물리 계층 (Physical Layer)

물리 계층은 네트워크의 가장 하위 계층으로, 실제 물리적 매체를 통해 데이터를 전송하는 역할을 한다. 이 계층에서는 전기 신호, 라디오 신호, 광 신호 등 다양한 형태의 신호를 사용하여 데이터를 전송한다. 주요 역할은 다음과 같다.

• 데이터 전송 매체의 종류 결정 (유선, 무선 등)
• 신호 변환 (디지털 -> 아날로그, 아날로그 -> 디지털)
• 전기적 특성 규정 (전압, 주파수 등)

2. 데이터 링크 계층 (Data Link Layer)

데이터 링크 계층은 물리 계층을 통해 전달된 데이터를 에러 없이 전달하고, 흐름을 제어하는 역할을 한다. 이 계층은 데이터를 프레임(Frame) 단위로 나누어 전송하며, 주로 다음과 같은 역할을 담당한다.

• 프레임 생성 및 해석
• MAC 주소를 사용한 물리적 주소 지정
• 오류 검출 및 수정 (CRC 등)

3. 네트워크 계층 (Network Layer)

네트워크 계층은 데이터가 다양한 네트워크를 통해 목적지까지 전달될 수 있도록 경로를 설정하는 역할을 한다. 이 계층에서 IP 주소를 사용하여 논리적 주소 지정을 한다. 주요 역할은 다음과 같다.

• 경로 설정 및 최적화 (라우팅)
• 논리적 주소 지정 (IP 주소)
• 패킷 전달 및 중계

4. 전송 계층 (Transport Layer)

전송 계층은 송신 측과 수신 측 간의 데이터 전송을 관리하고, 신뢰성 있는 데이터 전송을 보장한다. 이 계층에서는 주로 TCP와 UDP 프로토콜을 사용하여 데이터를 세그먼트(Segment) 단위로 전송한다. 주요 역할은 다음과 같다.

• 데이터 전송의 신뢰성 확보 (에러 검출, 재전송 등)
• 데이터 흐름 제어
• 포트 번호를 사용한 통신 세션 관리

5. 세션 계층 (Session Layer)

세션 계층은 통신 세션을 설정하고 관리하며, 종료하는 역할을 한다. 이 계층은 응용 프로그램 간의 대화(Dialogue)를 관리하고, 세션의 유지 및 동기화를 담당한다. 주요 역할은 다음과 같다.

• 세션 설정, 유지 및 종료
• 대화 제어 (반이중, 전이중 통신)
• 세션 복구 및 재동기화

6. 표현 계층 (Presentation Layer)

표현 계층은 데이터를 네트워크에 적합한 형태로 변환하고, 수신 측에서 이해할 수 있는 형태로 변환하는 역할을 한다. 이 계층에서는 데이터 암호화, 압축, 변환 등의 작업을 수행한다. 주요 역할은 다음과 같다.

• 데이터 형식 변환 (예: JPEG -> BMP)
• 데이터 암호화 및 복호화
• 데이터 압축 및 해제

7. 응용 계층 (Application Layer)

응용 계층은 사용자와 직접 상호작용하는 응용 프로그램들이 네트워크 서비스를 사용할 수 있도록 한다. 이 계층은 다양한 네트워크 서비스를 제공하며, 주로 다음과 같은 역할을 담당한다.

• 네트워크 프로토콜 정의 (HTTP, FTP, SMTP 등)
• 사용자 인터페이스 제공
• 응용 프로그램 간 데이터 교환

OSI 7계층의 동작 흐름

데이터가 송신 측에서 수신 측까지 전달되는 과정에서 OSI 7계층은 중요한 역할을 한다. 각 계층은 서로 다른 기능을 수행하며, 상호작용을 통해 데이터가 안전하고 정확하게 전달될 수 있도록 돕는다. 데이터가 송신 측에서 수신 측으로 이동할 때의 흐름은 다음과 같다.

1. 응용 계층 (Application Layer): 사용자가 응용 프로그램을 통해 데이터를 입력하면, 이 데이터는 응용 계층에서 시작된다.
2. 표현 계층 (Presentation Layer): 응용 계층에서 받은 데이터를 적절한 형식으로 변환한다. 예를 들어, 데이터 암호화나 압축 작업이 이뤄진다.
3. 세션 계층 (Session Layer): 변환된 데이터를 세션 계층에서 관리하며, 통신 세션을 설정하고 유지한다.
4. 전송 계층 (Transport Layer): 세션 계층에서 받은 데이터를 세그먼트로 나누고, 에러 검출 및 수정, 데이터 흐름 제어 등의 작업을 수행한다.
5. 네트워크 계층 (Network Layer): 전송 계층에서 받은 세그먼트를 패킷으로 변환하고, 목적지까지의 최적 경로를 설정한다.
6. 데이터 링크 계층 (Data Link Layer): 네트워크 계층에서 받은 패킷을 프레임으로 나누고, 오류 검출 및 수정을 수행하며, 물리적 주소를 지정한다.
7. 물리 계층 (Physical Layer): 데이터 링크 계층에서 받은 프레임을 물리적 신호로 변환하여 실제 전송 매체를 통해 데이터를 전송한다.

데이터가 수신 측에 도달하면, 물리 계층에서부터 다시 상위 계층으로 전달되며, 각 계층에서 해당 역할을 수행하여 데이터를 처리한다. 최종적으로 응용 계층에서 사용자가 이해할 수 있는 형태로 데이터를 제공한다. 이러한 과정을 통해 OSI 7계층 모델은 데이터 통신의 복잡성을 관리하고, 네트워크의 효율성을 높인다.

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간 통신 규칙 즉, 프로토콜이다. 사용자가 웹 사이트를 방문하면 브라우저가 웹 서버에 HTTP 요청을 전송하고 웹 서버는 HTTP 응답으로 요청에 대해 응답한다. 간단히 말해 HTTP 프로토콜은 네트워크 통신을 작동하게 하는 기술이다. HTTPS(Hypertext Transfer Protocol Secure)는 이름에서도 알 수 있듯이 HTTP의 확장 버전 또는 안전한 버전이다. HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정한다.

1. 보안

HTTP: 데이터를 일반 텍스트로 전송, 중간에서 데이터를 가로챌 수 있음 HTTPS: 데이터를 암호화하여 전송, 중간에서 데이터를 가로채더라도 해독이 어려움

2. 포트 번호

HTTP: 기본적으로 포트 80 사용 HTTPS: 기본적으로 포트 443 사용

3. SSL/TLS 인증서

HTTP: 인증서 필요 없음 HTTPS: 독립된 인증 기관(CA)에서 발급받은 SSL/TLS 인증서 필요

3. 브라우저 표시

HTTP: URL 옆에 특별한 보안 표시 없음 HTTPS: URL 옆에 자물쇠 아이콘 표시, 사용자는 보안 연결임을 알 수 있음

4. SEO 및 신뢰성

HTTP: 검색 엔진 순위에서 낮게 평가, 사용자 신뢰도 낮음 HTTPS: 검색 엔진 순위에서 높게 평가, 사용자 신뢰도 높음

HTTP의 동작 방식

• 클라이언트 요청: 사용자가 웹 사이트를 방문하면 브라우저가 웹 서버에 HTTP 요청을 전송

• 서버 응답: 웹 서버는 요청에 대한 HTTP 응답을 전송

• 데이터 교환: 데이터는 일반 텍스트로 전송됨

• 요청 유형(Request Methods)

  • GET
    • 리소스(데이터)를 받기 위함
    • URL(URI) 형식으로 서버 측에 리소스를 요청
  • HEAD
    • 메세지 헤더 정보를 받기 위함
    • GET과 유사하지만, HEAD는 실제 문서 요청이 아닌 문서에 대한 정보 요청
    • Response 메세지를 받았을 때, Body는 비어있고, Header 정보만 존재
  • POST
    • 내용 및 파일 전송을 하기 위함
    • 클라이언트에서 서버로 어떤 정보를 제출하기 위해 사용
    • Request 데이터를 HTTP Body에 담아 웹 서버로 전송
  • PUT
    • 리소스(데이터)를 갱신하기 위함
    • POST와 유사하나, 기존 데이터를 갱신할 때 사용
  • DELETE
    • 웹 서버측에 요청한 리소스를 삭제할 때 사용
  • CONNECT
    • 클라이언트와 서버 사이의 중간 경유를 위함
    • 보통 Proxy를 통해 SSL 통신을 하고자할 때 사용
  • OPTIONS
    • 웹 서버 측에서 지원하고 있는 메소드가 무엇인지 알기 위해 사용
  • PATCH
    • PUT과 유사하나, 모든 데이터를 갱신하는 것이 아닌 리소스의 일부분만 수정할 때 사용

• 응답 코드(Status Code)

  • 10x : 정보 확인

  • 20x : 통신 성공

  • 30x : 리다이렉트

  • 40x : 클라이언트 오류

  • 50x : 서버 오류

    HTTPS의 동작 방식

• 클라이언트 요청: 사용자가 https:// URL을 입력하여 웹 사이트를 방문

• SSL 인증서 요청: 브라우저가 서버의 SSL 인증서를 요청

• 서버 응답: 서버가 퍼블릭 키가 포함된 SSL 인증서를 전송

• 인증서 검증: 브라우저가 인증서를 검증하고, 퍼블릭 키를 사용하여 비밀 세션 키가 포함된 메시지를 암호화하여 전송

• 세션 키 교환: 서버가 개인 키로 메시지를 해독하고 세션 키를 생성, 세션 키를 암호화하여 브라우저에 전송

• 보안 통신: 브라우저와 서버가 동일한 세션 키를 사용하여 암호화된 데이터 교환

  HTTP/2, HTTP/3, HTTPS의 차이점

• HTTP/1.1: 최초의 HTTP 버전, 텍스트 형식으로 데이터 전송

• HTTP/2: 바이너리 형식으로 데이터 전송, 서버 푸시 기능 추가

• HTTP/3: 실시간 스트리밍 및 최신 데이터 전송 요구 사항을 더 효율적으로 지원

  HTTPS를 선택하는 이유

• 보안 강화: 모든 데이터가 암호화되어 전송, 민감한 정보 보호

• 신뢰성 증대: 검색 엔진 순위에서 우선, 사용자 신뢰도 높음

• 성능 향상: HTTPS 웹 애플리케이션이 더 빠르게 로드

• 정확한 분석: 추천 트래픽을 정확하게 추적 가능

Redis는 Remote Dictionary Server의 약자로, 인메모리 데이터 저장소로서 데이터를 디스크가 아닌 메모리에 저장하여 빠른 읽기 및 쓰기를 제공한다. 다양한 데이터 구조를 지원하며, 주로 캐시, 세션 저장소, 메시지 브로커 등으로 사용된다.

Redis 특징

• Key-Value 타입의 인메모리 데이터를 저장, 관리하기 위한 오픈 소스 기반의 NoSQL
  • 인메모리 (In-Memory Database)
    • 디스크가 아닌 메모리에 모든 데이터를 보유하는 DB.
    • 디스크 검색보다 자료 접근이 훨씬 빠름.
    • But, 메모리라 휘발성.
  • In-Memory 기반이라 저장 공간 제약
  • 휘발성이 특징인 메모리와 다르게 영속성 보장
• DB, Cache, Message Queue, Shared Memory 용도로 사용됨
• 쓰기 성능 증대를 위한 클라이언트 측 샤딩(sharding) 지원
  • 샤딩 (sharding)
    • 데이터를 조각내 분산 저장하는 데이터 처리 기법.
    • 일괄적 관리가 힘든 거대 데이터베이스나 네트워크를 작게 나눠서 저장 및 관리.
    • 샤딩을 통해 데이터를 분산 저장하면 노드의 무게를 줄여 데이터 처리 속도 향상.
• 다양한 데이터형 지원
  • 문자열, 리스트, 해시, 셋, 정렬된 셋과 같은 다양한 데이터 구조를 지원

어떻게 레디스는 영속성을 보장하나?

AOF, RDB 방식

➜ 인메모리 데이터 저장소가 가지는 휘발성의 특성으로 데이터가 유실될 경우를 방지하여 백업 기능을 제공

AOF (Append On File) 방식 ➜ Redis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 형태

RDB(Snapshotting) 방식 ➜ 순간적으로 메모리에 있는 내용 전체를 디스크에 담아 영구 저장하는 방식

Spring Boot에서의 Redis 사용

인메모리 저장소로서의 Redis

Spring Boot에서 Redis는 캐시 저장소로 자주 사용된다. 캐싱은 데이터베이스의 부하를 줄이고 응답 시간을 줄이는 데 매우 유용하다.

@Repository
public class RedisRepository {

    private final RedisTemplate<String, Object> redisTemplate;

    public RedisRepository(RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void save(String key, Object value) {
        redisTemplate.opsForValue().set(key, value);
    }

    public Object find(String key) {
        return redisTemplate.opsForValue().get(key);
    }
}

위 코드에서 @Cacheable 애노테이션은 exampleCache라는 이름의 캐시에 데이터를 저장한다. 이후 같은 키로 요청이 들어오면 캐시에서 데이터를 조회하게 된다.

메시지 브로커로서의 Redis 사용

Redis는 메시지 브로커로서도 사용할 수 있다. 이는 RabbitMQ나 Kafka 같은 고도화된 메시징 시스템과는 다르지만, Redis의 인메모리 특성을 활용해 단순하고 빠른 pub/sub 기능을 제공한다

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.listener.ChannelTopic;
import org.springframework.stereotype.Service;

@Service
public class RedisMessagePublisher {
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    @Autowired
    private ChannelTopic topic;

    public void publish(String message) {
        redisTemplate.convertAndSend(topic.getTopic(), message);
    }
}

위 코드에서는 RedisTemplate을 이용하여 메시지를 특정 토픽에 발행(publish)하는 방법을 보여준다.

도메인이 다른 서버끼리 리소스를 주고 받을 때 보안을 위해 설정된 정책인 CORS(Cross-Origin Resource Sharing)

CORS는 웹 브라우저가 하나의 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 하는 메커니즘이다. 웹 사이트가 다른 도메인에서 리소스를 요청할 때 보안을 유지하면서 접근할 수 있도록 도와준다.

예를들어 웹 사이트 A가 API 서버 B에서 데이터를 가져오려 할 때, API 서버 B에서 CORS 허용 설정이 되어 있지 않으면 웹 브라우저에서 API 접근이 거부될 수 있다. 이는 보안을 위해 웹 브라우저에서 자동으로 차단하는 것.

ex) React 서버(3000 포트) → Springboot 서버(8080 포트) 리소스를 주고받으려 할 때 CORS 위반 에러가 발생.

Origin (출처)란 무엇인가?

CORS를 이해하려면 우선 "출처"에 대해 알아야 한다.

• SOP (Same Origin Policy): 동일한 Origin만 리소스(데이터)를 공유할 수 있는 정책.
• Origin: Protocol, Host, Port 번호까지 모두 합친 것.
  • same-origin: 위의 3가지가 모두 같으면 동일 출처.
  • cross-origin: 위의 3가지 중 하나라도 다르면 다른 출처.

CORS 설정 방법

서버에서 CORS를 허용하려면 몇 가지 설정이 필요하다. 예를 들어, Springboot 서버에서는 다음과 같이 설정할 수 있다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:3000")
                        .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                        .allowedHeaders("content-type", "authorization", "x-requested-with")
                        .allowCredentials(true);
    }
}

registry.addMapping("/**")

• 모든 경로에 대해 CORS 정책을 적용한다는 의미이다. "/**"는 애플리케이션의 모든 URL 경로를 의미한다.

allowedOrigins("http://localhost:3000")

• http://localhost:3000 출처에서 오는 요청을 허용한다.

allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")

• GET, POST, PUT, DELETE, OPTIONS 메서드를 사용할 수 있도록 허용한다.

allowedHeaders("content-type", "authorization", "x-requested-with")

• content-type, authorization, x-requested-with 헤더를 사용할 수 있도록 허용한다.

allowCredentials(true)

• 자격 증명(쿠키, 인증 정보 등)을 요청에 포함할 수 있도록 허용한다. 이는 보안 관련 설정으로, 클라이언트가 자격 증명을 포함한 요청을 서버에 보낼 수 있도록 한다
• allowCredentials(true)로 설정하면 어떠한 허용에도 ("*")는 사용이 불가능하다.
  • 여기서 좀 고생했다.

백엔드 환경 구성

• Docker 설치 후 실행

• Ubuntu 설치

• Docker Desktop 설정 확인

  1. Docker Desktop을 열고 오른쪽 상단의 톱니바퀴(설정) 아이콘을 클릭
  2. Settings -> Resources -> WSL Integration으로 이동
  3. 사용 중인 Ubuntu 배포판이 목록에 있고, 해당 항목이 체크되어 있는지 확인

Ubuntu 접속 후 다음 명령어 입력:

sudo su (비밀번호 입력)
cd /opt
curl https://s3-eu-west-1.amazonaws.com/aws.openvidu.io/install_openvidu_latest.sh | bash

다음 명령어로 OpenVidu 설치:

1. OpenVidu 폴더로 이동

    cd openvidu

2. .env 파일 설정

    nano .env

   • 이 명령어를 사용하여 ‘.env’ 파일을 연다

   • 여기서 ‘DOMAIN_OR_PUBLIC_IP’ 와 ‘OPENVIDU_SECRET’ 값을 설정해준다 (안해도 실행은 가능)

     DOMAIN_OR_PUBLIC_IP=your.domain.com
     OPENVIDU_SECRET=your_secret_password

3. OpenVidu 시작

    ./openvidu start

추가. Docker 컨테이너 확인

• OpenVidu가 실행 중인 Docker 컨테이너들을 확인하려면 다음 명령어를 사용

docker ps

도커에서 컨테이너가 만들어져 돌아가고 있는 모습을 볼 수 있다

프론트 환경 구성

• 원하는 폴더에 clone 받는다

    git clone https://github.com/OpenVidu/openvidu-tutorials.git -b v2.19.0

• VS Code로 openvidu-tutorials\openvidu-insecure-vue 폴더 열기

• 터미널 창에

  • npm install

  • npm run serve

    • 여기서 서버 안켜지고 오류 발생시 !!

      • package.json 수정

        "scripts": {
        "serve": "export NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve"
        }

터미널에 이런 내용이 나오면 성공!

localhost:8080 으로 접속하면, 잘 작동한다 !

💡 Web Real-Time Communication은 웹 애플리케이션과 사이트가 중간자 없이 브라우저 간에 오디오나 영상 미디어를 포착하고 마음대로 스트림할 뿐 아니라, 임의의 데이터도 교환할 수 있도록 하는 기술입니다.

서버의 종류

1. Signaling 서버 (위 그림의 Mesh - P2P)

• 역할

  • 두 클라이언트 간에 P2P 연결을 설정하기 위한 초기 통신을 담당합니다.
  • Signaling 서버 자체는 미디어 데이터(비디오, 오디오)를 전달하지 않습니다.
  • 연결 설정 후, 실제 미디어 데이터는 클라이언트 간의 P2P 연결을 통해 직접 전달됩니다.

• 특징

  • Peer 간의 Offer, Answer의 session 정보 신호만을 중계합니다.
  • 초기 연결 설정 시에만 서버에 부하가 발생하고, Peer 간 연결이 완료된 후에는 서버에 별도의 부하가 없습니다.
  • 1:1 연결에 적합합니다.

• 장점

  • 서버의 부하가 적습니다.
  • Peer 간의 직접 연결로 데이터를 송수신하기 때문에 실시간성을 보장합니다.

• 단점

  • N:N 혹은 N:M 연결에서 클라이언트의 과부하가 급격하게 증가합니다.

2. SFU (Selective Forwarding Unit) 서버

• 역할

  • P2P와 달리 서버를 이용하여 클라이언트의 미디어 스트림을 중계합니다.

• 특징

  • 종단 간 미디어 트래픽을 중계하는 중앙 서버 방식입니다.
  • 클라이언트 Peer 간 연결이 아닌, 서버와 클라이언트 간의 Peer를 연결합니다.
  • 클라이언트는 연결된 모든 사용자에게 데이터를 보낼 필요 없이 서버에게만 자신의 영상 데이터를 보냅니다.
  • 1:N 혹은 소규모 N:M 형식의 실시간 스트리밍에 적합합니다.

• 장점

  • P2P 방식만큼은 아니지만 준수한 실시간성을 유지할 수 있습니다.
  • Signaling 서버를 사용하는 것보다 클라이언트가 받는 부하가 줄어듭니다 (클라이언트가 많을 경우).

• 단점

  • Signaling 서버보다 서버 비용이 증가합니다.
  • 대규모 N:M 구조에서는 여전히 클라이언트가 많은 부하를 감당해야 합니다.

3. MCU (Multi-point Control Unit) 서버

• 특징

  • SFU와 마찬가지로 서버가 중간에서 미디어 트래픽을 중계합니다.
  • 다수의 송출 미디어를 중앙 서버에서 혼합 또는 가공하여 수신측으로 전달합니다.
  • Uplink와 Downlink 둘 다 1개만 사용합니다.
  • 중앙 서버의 높은 컴퓨팅 파워가 요구됩니다.

• 장점

  • 클라이언트의 부하가 현저히 줄어듭니다.

• 단점

  • WebRTC의 최대 장점인 실시간성이 저해됩니다.
  • 실시간성이 중요한 게임 등에서는 MCU는 부적합합니다.

세 가지 주요 API

1. MediaStream (GetUserMedia API)

• 사용자의 카메라와 마이크에 접근하여 오디오와 비디오 스트림을 캡쳐합니다.

• navigator.mediaDevices.getUserMedia()를 사용하여 접근 가능합니다.

• 예시

    navigator.mediaDevices.getUserMedia({ video: true, audio: true })
      .then(stream => {
        // 스트림을 사용합니다
        videoElement.srcObject = stream;
      })
      .catch(error => {
        console.error("Error accessing media devices.", error);
      });

2. RTCPeerConnection

• 두 피어 간의 오디오, 비디오, 데이터 스트림을 전송하는 데 사용됩니다.

• ICE (Interactive Connectivity Establishment) 프로토콜을 통해 피어 간의 연결을 설정하고 유지합니다.

• 보안, 대역폭 관리, 네트워크 최적화 등을 처리합니다.

• 예시

    const peerConnection = new RTCPeerConnection(configuration);
  
    // 로컬 미디어 스트림을 연결에 추가
    stream.getTracks().forEach(track => peerConnection.addTrack(track, stream));
  
    // ICE 후보 수신
    peerConnection.onicecandidate = event => {
      if (event.candidate) {
        sendCandidateToRemotePeer(event.candidate);
      }
    };
  
    // 원격 스트림 수신
    peerConnection.ontrack = event => {
      remoteVideoElement.srcObject = event.streams[0];
    };

3. RTCDataChannel

• 피어 간에 임의의 데이터를 전송하는 데 사용됩니다.

• 게임, 파일 공유, 채팅 어플리케이션 등에서 활용됩니다.

• 예시

    const dataChannel = peerConnection.createDataChannel("myDataChannel");
  
    dataChannel.onopen = () => {
      console.log("Data channel is open");
    };
  
    dataChannel.onmessage = event => {
      console.log("Received message:", event.data);
    };
  
    dataChannel.send("Hello, World!");

WebRTC 작동원리

1. 신호 교환

• WebRTC 자체에는 신호 교환 방법이 정의되어 있지 않습니다.
• WebRTC를 사용하려면 시그널링 서버가 필요합니다.

2. P2P 연결 설정

• 두 클라이언트는 시그널링 서버를 통해 초기 통신을 시작합니다.
• Offer와 Answer를 교환하여 세션 정보를 설정합니다.
• 시그널링 서버는 미디어 데이터(비디오, 오디오)를 전달하지 않고, 단지 신호만 중계합니다.

3. 미디어 스트림 전송

• P2P 연결이 설정된 후, 실제 미디어 데이터는 클라이언트 간의 직접 연결을 통해 전송됩니다.
• MediaStream API를 사용하여 오디오와 비디오 스트림을 캡쳐하고, RTCPeerConnection을 통해 전송합니다.

4. 데이터 채널 설정

• RTCDataChannel을 사용하여 피어 간에 임의의 데이터를 전송할 수 있습니다.
• 데이터 채널은 게임, 파일 공유, 채팅 어플리케이션 등에서 활용됩니다.

현재 핀토스에서는 레벨 4 페이지 테이블(pml4)을 사용하여 가상 메모리 주소와 물리 메모리 주소 간의 매핑 정보를 저장한다. 하지만 이것만으로는 충분하지 않다. Supplemental Page Table을 구현해 페이지에 대한 추가적인 정보들을 저장하게 되면 Page Fault와 Resource Management를 수월하게 진행할 수 있다.

Supplemental Page Table

supplemental page table은 기존의 page table을 보완하기 위해 만든 것이다.

역할 크게 두 가지 역할을 수행한다.

• 페이지 폴트 시 커널이 추가 페이지 테이블에서 오류가 발생한 가상 페이지를 조회하여 어떤 데이터가 있어야 하는지 확인
• 프로세스가 종료될 때 커널이 추가 페이지 테이블을 참조하여 어떤 리소스를 free시킬 것인지 결정

struct supplemental_page_table 구현 먼저 추가 페이지 테이블의 구조체 struct supplemental_page_table을 구현한다. 그 후에 추가 테이블 구조체에 관계된 함수를 구현한다.

Supplemental page table을 구현하는 방식은 여러 가지가 있을 수 있다. 배열이나, 비트맵, 해시 테이블도 가능하다. hash table로 구현하자.

💡 frame table

frame table은 물리 메모리 내의 각 프레임의 정보를 갖고 있다.

역할 Frame table은 frame entry의 리스트로 구성되는데, 각 엔트리는 물리 메모리 프레임 테이블로 인해 eviction 정책, 즉 SWAP OUT/IN을 위한 프레임 교체 정책을 수행할 수 있게 된다.

struct frame_table 구현

• 사용 가능한 빈 프레임들의 집합
• frame_table은 리스트로 구현한다.
• frame_table은 전역적으로 구현해야한다.

구현

Supplemental Page Table

1. hash, hash_elem 구조체 추가

• include/vm/vm.h

1-1. hash.h include

#define VM_VM_H
#include <stdbool.h>
#include "threads/palloc.h"
#include <hash.h> /** Project 3-Memory Management */
...

1-2. spt_hash 추가 supplemental_page_table에 hash 구조체를 추가한다.

struct supplemental_page_table {
     struct hash spt_hash; /** Project 3-Memory Management */
};

1-3. hash_elem 추가 page 구조체에 hash_elem을 추가한다.

struct page {
    const struct page_operations *operations;
    void *va;              /* Address in terms of user space */
    struct frame *frame;   /* Back reference for frame */

    /* Your implementation */

    /* Per-type data are binded into the union.
     * Each function automatically detects the current union */
    union {
        struct uninit_page uninit;
        struct anon_page anon;
        struct file_page file;
#ifdef EFILESYS
        struct page_cache page_cache;
#endif
    };
    /** Project 3-Memory Management */
    struct hash_elem hash_elem;
};

2. supplemental_page_table_init() 구현

• vm/vm.c
• supplementary page table을 초기화한다.
• hash table을 사용하기로 했으므로 hash_init을 사용하여 초기화한다.
• hash_init에서 필요한 page_hash와 page_less는 3번과 4번에 설명되어 있다.

void
supplemental_page_table_init (struct supplemental_page_table *spt UNUSED) {
    /** Project 3-Memory Management */
    hash_init(spt, page_hash, page_less, NULL);
}

3. page_hash() 구현

• spt에 넣을 인덱스를 해시 함수를 돌려서 도출한다.
• hash table이 hash elem을 원소로 가지고 있으므로 페이지 자체에 대한 정보를 가져온다.
• 인덱스를 리턴해야하므로 hash_bytes로 리턴한다.

3-1. 선언

• include/vm/vm.h

/** Project 3-Memory Management */
uint64_t page_hash(const struct hash_elem *e, void *aux);

3-2. 구현

• vm/vm.c

/** Project 3-Memory Management */
uint64_t 
page_hash(const struct hash_elem *e, void *aux)
{
    struct page *page = hash_entry(e, struct page, hash_elem);
    return hash_bytes(page->va, sizeof *page->va);
}

4. page_less() 구현

• 체이닝 방식의 spt를 구현하기 위한 함수이다.
• 해시 테이블 버킷 내의 두 페이지의 주소값을 비교한다.

4-1. 선언

• include/vm/vm.h

/** Project 3-Memory Management */
uint64_t page_hash(const struct hash_elem *e, void *aux);
bool page_less(const struct hash_elem *a, const struct hash_elem *b, void *aux);

4-2. 구현

• vm/vm.c

/** Project 3-Memory Management */
bool 
page_less(const struct hash_elem *a, const struct hash_elem *b, void *aux)
{
    struct page *page_a = hash_entry(a, struct page, hash_elem);
    struct page *page_b = hash_entry(b, struct page, hash_elem);

    return page_a->va < page_b->va;
}

5. spt_find_page() 구현

• vm/vm.c

supplementary page table에서 va에 해당하는 구조체 페이지를 찾아 반환한다.

struct page *
spt_find_page (struct supplemental_page_table *spt UNUSED, void *va UNUSED) {

    /** Project 3-Memory Management */
    struct page *page = (struct page *)malloc(sizeof(struct page));     
    page->va = pg_round_down(va);                                       
    struct hash_elem *e = hash_find(&spt->spt_hash, &page->hash_elem);  
    free(page);                                                         

    return e != NULL ? hash_entry(e, struct page, hash_elem) : NULL;
}

6. spt_insert_page() 구현

• vm/vm.c
• supplementary page table에 struct page를 삽입한다.
• 가상 주소가 이미 supplementary page table에 존재하면 삽입하지 않고, 존재하지 않으면 삽입한다.

bool
spt_insert_page (struct supplemental_page_table *spt UNUSED,
        struct page *page UNUSED) {
    /** Project 3-Memory Management */
    return hash_insert(&spt->spt_hash, &page->hash_elem) ? false : true;
}

Frame Management

7. frame_table 구조체 추가

7-1. frame_table 추가 및 초기화

• vm/vm.c

  /* vm.c: Generic interface for virtual memory objects. */
  

#include "threads/malloc.h" #include "vm/vm.h" #include "vm/inspect.h"

/** Project 3-Memory Management */ static struct list frame_table;

/* Initializes the virtual memory subsystem by invoking each subsystem's

• intialize codes. / void vm_init (void) { vm_anon_init (); vm_file_init (); #ifdef EFILESYS / For project 4 / pagecache_init (); #endif register_inspect_intr (); / DO NOT MODIFY UPPER LINES. */

  /** Project 3-Memory Management */ list_init(&frame_table); }

  **7-2. frame_elem 추가**
  * include/vm/vm.h
  

struct frame {
    void *kva;
    struct page *page;
    /** Project 3-Memory Management */
    struct list_elem frame_elem; 
};

8. vm_get_frame() 구현

• vm/vm.c
• palloc_get_page 함수를 호출하여 사용자 풀에서 새로운 physical page(frame)를 가져온다.
• 사용 가능한 page가 없다면 swap out을 수행한다.

static struct frame *
vm_get_frame (void) {
    struct frame *frame = NULL;
    /* TODO: Fill this function. */

    /** Project 3-Memory Management */
    struct frame *frame = (struct frame *)malloc(sizeof(struct frame));
    ASSERT (frame != NULL);

    frame->kva = palloc_get_page(PAL_USER | PAL_ZERO);  

    if (frame->kva == NULL)
        frame = vm_evict_frame();  
    else
        list_push_back(&frame_table, &frame->frame_elem);

    frame->page = NULL;

    ASSERT (frame->page == NULL);
    return frame;
}

9. vm_claim_page() 구현

• vm/vm.c

• 인자로 주어진 va에 페이지를 하나 할당한다.

• 해당 페이지로 vm_do_claim_page를 호출한다.

  bool
  vm_claim_page (void *va UNUSED) {
    struct page *page = NULL;
    /** Project 3-Memory Management */
    struct page *page = spt_find_page(&thread_current()->spt, va);
  
    if (page == NULL)
        return false;
  
    return vm_do_claim_page (page);
  }

• 10. vm_do_claim_page() 구현*

• vm_get_frame() 함수를 통해 프레임 하나를 얻는다.

• 프레임의 페이지로 얻은 페이지를 연결한다.

• 프레임의 물리적 주소로 얻은 프레임을 연결한다.

• 현재 페이지 테이블에 가상 주소에 따른 frame을 매핑한다.

10-1. writable 구조체 추가

struct page {
    const struct page_operations *operations;
    void *va;              /* Address in terms of user space */
    struct frame *frame;   /* Back reference for frame */

    /* Your implementation */

    /* Per-type data are binded into the union.
     * Each function automatically detects the current union */
    union {
        struct uninit_page uninit;
        struct anon_page anon;
        struct file_page file;
#ifdef EFILESYS
        struct page_cache page_cache;
#endif
    };
    /** Project 3-Memory Management */
    struct hash_elem hash_elem;
    bool writable;
};

10-2. mmu.h include

• vm/vm.c

/** Project 3-Memory Management */
#include "threads/mmu.h"
static struct list frame_table; 
10-3. vm_do_claim_page() 구현
vm/vm.c
static bool
vm_do_claim_page (struct page *page) {
    struct frame *frame = vm_get_frame ();

    /* Set links */
    frame->page = page;
    page->frame = frame;

    if (!pml4_set_page(thread_current()->pml4, page->va, frame->kva, page->writable))
        return false;

    return swap_in (page, frame->kva);
}

10-3. vm_do_claim_page() 구현

• vm/vm.c

  static bool
  vm_do_claim_page (struct page *page) {
    struct frame *frame = vm_get_frame ();
  
    /* Set links */
    frame->page = page;
    page->frame = frame;
  
    if (!pml4_set_page(thread_current()->pml4, page->va, frame->kva, page->writable))
        return false;
  
    return swap_in (page, frame->kva);
  }

👉 OS 관점에서 스왑 디스크는 주 메모리(RAM)가 가득 찼을 때 사용되는 보조 저장 공간

• 주로 하드 드라이브나 SSD 같은 보조 저장 장치에 할당되며, 프로세스의 메모리 페이지를 입시로 저장하는 데 사용한다
• 저장된 공간은 메모리의 일부 페이지를 임시로 저장하는 데 사용되며, 이를 ‘스와핑’이라 한다

스왑 디스크의 목적

• 스왑 디스크는 메모리 관리와 시스템 성능 최적화에서 중요한 역할을 한다
• 시스템의 물리적 메모리가 부족할 때 추가적인 가상 메모리 공간을 제공한다
• 이를 통해 시스템은 더 많은 프로세스와 데이터를 동시에 처리할 수 있다

스왑 디스크 작동 방식

1. 스와핑(Swapping)
   • 메모리가 가득 차면, 운영 체제는 가장 적게 사용되는 메모리 페이지들을 스왑 디스크로 이동시킨다
   • 이 과정을 스와핑이라고 하며, 이를 통해 메모리에서 더 중요한 데이터를 처리할 수 있게 된다
2. 페이지 교체
   • 스왑 디스크에 저장된 페이지가 다시 필요할 경우, 해당 페이지를 메모리에 다시 로드 → 이 과정에서 다른 페이지가 swap disk로 밀려날 수 있다

스왑 디스크의 장점과 단점

• 장점
  • 메모리 부족 문제를 완화
  • 동시에 실행되는 프로세스의 수 증가 (더 많은 메모리를 사용하기 때문에)
• 단점
  • 디스크 기반이라 메모리보다 속도가 느리다
  • 과도한 스와핑은 시스템 성능 저하를 일으킬 수 있다

TLB(Translation Lookaside Buffer) 란?

• 최근에 일어난 가상 메모리 주소와 물리 주소의 변환 테이블 저장
• 일종의 주소 변환 캐시
• TLB 구성

- 가상 주소가 주어짐 → TLB에서 해당 가상 주소 검색
    - TLB에 존재할 경우 (TLB 히트) → 프레임 번호 추출 → 물리 주소 구성
    - TLB에 존재하지 않을 경우 (TLB 미스) → 페이지 번호를 이용해 페이지 테이블에서 해당 가상 주소 검색
- 페이지 테이블에서 유효 비트 1일 경우 (해당 페이지 메인 메모리에 존재) → 페이지 테이블의 프레임 번호 이용 → 물리 주소 구성 및 TLB 갱신
- 페이지 테이블에서 유효 비트 0일 경우 (해당 페이지 메인 메모리에 존재X) → page fault 발생

• 페이징과 TLB 동작

  

프로세스 관련 시스템 콜

halt()

void halt(){
    power_off();
}

exit()

void exit(int status){
    struct thread *curr = thread_current();
    curr->exit_status = status;
    printf("%s: exit(%d)\n", curr->name, status);
    thread_exit();
}

• 종료 시 "프로세스 이름: exit(status)" 출력
• thread 구조체에 exit_status 필드 추가
  • exit_status : 프로세스 종료 유무 확인
• 정상적으로 종료 시 status : 04

fork()

pid_t fork(const char *thread_name){
    check_address(thread_name);
    return process_fork(thread_name, f);
}

• thread_name : 새로 생성될 자식 프로세스의 이름

  • 자식 프로세스에 부모 프로세스의 레지스터 값(%RBX ~ %R15)을 복사

• f : 부모의 인터럽트 프레임

• 반환값 : 생성된 자식 프로세스의 pid

• 자식 프로세스는 부모 프로세스의 파일 디스크립터와 가상 메모리 공간을 복제해야한다

• process_fork 함수 source code 및 해석

    tid_t
    process_fork (const char *name, struct intr_frame *if_ UNUSED) {
        /* Clone current thread to new thread.*/
  
        struct thread *curr = thread_current();
  
        memcpy(&curr->parent_if, if_, sizeof(struct intr_frame)); // 전달받은 intr_frame을 parent_if필드에 복사한다.
        // ↳ '__do_fork' 에서 자식 프로세스에 부모의 컨텍스트 정보를 복사하기 위함(부모의 인터럽트 프레임을 찾는 용도로 사용)
  
        tid_t tid = thread_create(name, PRI_DEFAULT, __do_fork, curr); // __do_fork를 실행하는 스레드 생성, 현재 스레드를 인자로 넘겨준다.
        if (tid == TID_ERROR)
            return TID_ERROR;
  
        struct thread *child = get_child_process(tid);
  
        sema_down(&child->fork_sema); // 자식 프로세스가 로드될 때까지 부모 프로세스는 대기한다.
        if (child->exit_status == TID_ERROR)
            return TID_ERROR;
  
        return tid; // 부모 프로세스의 리턴값 : 생성한 자식 프로세스의 tid
    }

• __do_fork 함수 source code 및 해석

    static void
    __do_fork (void *aux) {
        struct intr_frame if_;
        struct thread *parent = (struct thread *) aux; // 부모 프로세스
        struct thread *current = thread_current (); // 새로 생성된 자식 프로세스
        /* TODO: somehow pass the parent_if. (i.e. process_fork()'s if_) */
        struct intr_frame *parent_if;
        bool succ = true;
  
        parent_if = &parent->parent_if; // process_fork에서 복사 해두었던 intr_frame
        /* 1. Read the cpu context to local stack. */
        memcpy (&if_, parent_if, sizeof (struct intr_frame));
  
        if_.R.rax = 0; // fork 시스템 콜의 결과로 자식 프로세스는 0을 리턴해야하므로 0을 넣어준다.
  
        /* 2. Duplicate PT */
        current->pml4 = pml4_create(); // 부모의 pte를 복사하기 위해 페이지 테이블을 생성한다.
        if (current->pml4 == NULL)
            goto error;
  
        process_activate (current);
    #ifdef VM
        supplemental_page_table_init (&current->spt);
        if (!supplemental_page_table_copy (&current->spt, &parent->spt))
            goto error;
    #else
        // "pml4_for_each" : Apply FUNC to each available pte entries including kernel's.
        if (!pml4_for_each (parent->pml4, duplicate_pte, parent)) // "duplicate_pte" : 페이지 테이블을 복제하는 함수(부모 -> 자식) 
            goto error;
    #endif
  
        /* TODO: Your code goes here.
         * TODO: Hint) To duplicate the file object, use `file_duplicate`
         * TODO:       in include/filesys/file.h. Note that parent should not return
         * TODO:       from the fork() until this function successfully duplicates
         * TODO:       the resources of parent.*/
        /*
         * 파일 객체를 복제하려면 'file_duplicate'를 사용하라.
         * 이 함수가 부모의 리소스를 성공적으로 복제할 때까지 부모 프로세스는 fork로 부터 리턴할 수 없다.
        */
        if (parent->next_fd == FDCOUNT_LIMIT)
            goto error;
  
        // 부모의 fdt를 자식의 fdt로 복사한다.
        for (int fd = 2; fd < FDCOUNT_LIMIT; fd++) {
            struct file *file = parent->fdt[fd];
            if (file == NULL) // fd엔트리가 없는 상태에는 그냥 건너뛴다.
                continue;
            current->fdt[fd] = file_duplicate (file);
        }
  
        current->next_fd = parent->next_fd; // 부모의 next_fd를 자식의 next_fd로 옮겨준다.
        sema_up(&current->fork_sema); // fork가 정상적으로 완료되었으므로 현재 wait중인 parent를 다시 실행 가능 상태로 만든다. 
  
        /* Finally, switch to the newly created process. */
        if (succ)
            do_iret (&if_);
    error: // 제대로 복제가 안된 상태 - TID_ERROR 리턴 
        sema_up(&parent->fork_sema);
        exit(TID_ERROR);
        // thread_exit (); // origin_code
    }

  • __do_fork 의 인자로 thread_create 를 하면서 4번째 인자로 넣은 curr (aux) 가 들어가게 된다.
  1. 자식 프로세스에 부모의 인터럽트 프레임(실행 컨텍스트)를 복사해서 넣어준다.
  2. 부모 프로세스의 페이지 테이블을 자식 프로세스의 페이지 테이블로 복제한다.(duplicate_pte _”filesys/filesys.h”) 사용
  3. 부모의 fdt와 next_fd를 복사하여 자식 프로세스에게 설정해준다.
  4. 이후, 부모 프로세스에서 자식 프로세스로의 모든 복사 과정이 완료되었으므로 sema_up 을 수행한다.
     • 반드시 process_fork 에서의 세마포어와 동일한 세마포어에 대해 Up 연산을 수행해주어야한다!
  5. do_iret (&if_); : sema_up 을 진행해서 부모 프로세스가 다시 Ready 상태가 되었으므로 컨텍스트 스위치를 수행한다.

exec()

int exec(const char *cmd_line){
    check_address(cmd_line);

    // 파일 사이즈(NULL 포함 +1)
    int size = strlen(cmd_line) + 1;
    char *fn_copy = palloc_get_page(PAL_ZERO);

    // 메모리 할당 불가 시
    if(fn_copy == NULL)
        exit(-1);
    strlcpy(fn_copy, cmd_line, size);

    if(process_exec(fn_copy) == -1)
        return -1;

    return 0;
}

• 현재 실행중인 프로세스를 cmd_line에 지정된 실행 파일로 변경하고 인수들을 전달

• process_exec 함수 source code 및 해석

    int
    process_exec (void *f_name) {
        char *file_name = f_name; // 커맨드 라인 전체가 인자로 들어온다.
        bool success;
  
        struct intr_frame _if;
        _if.ds = _if.es = _if.ss = SEL_UDSEG;
        _if.cs = SEL_UCSEG;
        _if.eflags = FLAG_IF | FLAG_MBS;
  
        int argc = 0;
        char *argv[128]; // 64bit computer(uint64_t : 8byte)
  
        /* We first kill the current context */
        process_cleanup ();
  
            /* ----- 추가 부분 ------- */
        /* 커맨드 라인을 파싱한다. */
        argument_parse(file_name, &argc, argv);
  
        /* And then load the binary */
        success = load (file_name, &_if);
  
        /* If load failed, quit. */
        if (!success){
            palloc_free_page (file_name);
            return -1;
        }
  
        argument_stack(argc, argv, &_if); // argc, argv로 커맨드 라인 파싱
        // hex_dump(_if.rsp, _if.rsp, USER_STACK - _if.rsp, true); // 메모리에 적재된 상태 출력
  
        /* Start switched process. */
        do_iret (&_if);
        NOT_REACHED ();
    }

wait()

int wait(__pid_t pid){
    process_wait(pid);
}

• pid : 대기하려는 자식 프로세스의 pid

• process_wait 함수 source code 및 해석

    process_wait (tid_t child_tid UNUSED) {
        struct thread *child = get_child_process(child_tid);
  
        if(child == NULL) // 해당 자식이 존재하지 않는다면 -1 리턴
            return -1;
  
        sema_down(&child->wait_sema); // 자식 프로세스가 종료할 때까지 대기한다.
        // 컨텍스트 스위칭 발생
  
        int exit_status = child->exit_status; // 자식으로 부터 종료인자를 전달 받고 리스트에서 삭제한다.
        list_remove(&child->child_elem);
  
        sema_up(&child->free_sema); // 자식 프로세스 종료 상태를 받은 후 자식 프로세스를 종료하게 한다.
  
        return exit_status;
    }

  • 해당 자식 프로세스가 성공적으로 종료될 때까지 부모 프로세스는 대기한다.
  • threads/thread.c -> init_thread 에서 wait_sema 의 값을 0으로 설정해줬으므로 부모 프로세스는 wait_list로 들어가게된다.
  • ⭐ 이후 자식 프로세스가 종료(process_exit)된 후, sema_up을 한 뒤에서야 해당 부모 프로세스가 Ready 상태로 전환된다!
  • 자식 프로세스가 성공적으로 종료됐다면 부모 프로세스의 자식 프로세스 리스트에서 해당 자식 프로세스를 제거한다.
  • free_sema 는 자식 프로세스의 종료 상태를 받고 자식 프로세스를 종료해야하므로 세마포어를 이중적으로 걸어줬다고 보면 된다.

파일 관련 시스템 콜

create()

bool create(const char *file, unsigned initial_size){
    check_address(file);
    return filesys_create(file, initial_size);
}

• file : 생성할 파일의 이름 및 경로 정보
• initial_size : 생성할 파일의 크기
• 파일 생성은 파일 열기X
• 파일 열기는 open 시스템 콜이 수행

remove()

bool remove(const char *file){
    check_address(file);
    return filesys_remove(file);
}

• file : 제거할 파일의 이름 및 경로 정보
• 파일은 열려있는지 닫혀있는지와 관계없이 삭제될 수 있다
  • 삭제 전 파일을 꼭 닫아줄 것!

open()

int open(const char *file){
    check_address(file);
    struct file *target_file = filesys_open(file);

    if(target_file == NULL)
        return -1;
    int fd = fdt_add_fd(target_file);

    // fdt가 가득 찼다면
    if(fd == -1){
        file_close(target_file);
    }
    return fd;
}

• file : 파일의 이름 및 경로 정보
• 콘솔용으로 예약 되어있는 파일 디스크립터
  • 0 : 표준 입력(STDIN_FILENO)
  • 1 : 표준 출력(STDOUT_FILENO)
• 하나의 파일이 한번 이상 열릴 때, 각 open 프로세스는 새로운 파일 디스크립터를 반환

filesize()

int filesize(int fd){
    struct file *target_file = fdt_get_file(fd);
    if(target_file == NULL)
        return -1;
    return file_length(target_file);
}

read()

int read(int fd, void *buffer, unsigned size){
    int read_bytes = -1;

    if(fd == STDIN_FILENO){
        int i;
        unsigned char *buf = buffer;

        for(i = 0; i < size; i++){
            char c = input_getc();
            *buf++ = c;
            if(c == '\0')
                break;
        }
        return i;
    }
    else{
        struct file *file = fdt_get_file(fd);
        if(file != NULL && fd != STDOUT_FILENO){
            // 파일을 읽는 동안 접근 못하게 락 걸기
            lock_acquire(&filesys_lock);
            read_bytes = file_read(file, buffer, size);
            // 락 해제
            lock_release(&filesys_lock);
        }
    }
    return read_bytes;
}

• fd 가 0이면 STDIN이기 때문에 키보드로 들어온 값을 읽고

• fd 가 1이면 STDOUT이다

• 그게 아닐 경우 fd로 열린 파일에서 size바이트를 buffer로 읽는다

• 실제로 읽은 바이트 수를 반환하거나 만약 파일을 읽을 수 없다면 (EOF로 인한) -1을 반환

• input_getc 함수 source code 및 해석

    uint8_t
    input_getc (void) {
        enum intr_level old_level;
        uint8_t key;
  
        old_level = intr_disable ();
        key = intq_getc (&buffer);
        serial_notify ();
        intr_set_level (old_level);
  
        return key;
    }

  • 입력 버퍼로부터 누른 키 값을 가져온다
  • 만약 입력 버퍼가 비어있으면 키를 누를 때까지 기다린다

write()

int write(int fd, const void *buffer, unsigned size){
    check_address(buffer);
    int write_bytes = -1;

    if(fd == STDOUT_FILENO){
        putbuf(buffer, size);
        return size;
    }
    else{
        struct file *file = fdt_get_file(fd);
        if(file != NULL && fd != STDIN_FILENO){
            // 파일을 쓰는 동안 접근 못하게 락 걸기
            lock_acquire(&filesys_lock);
            write_bytes = file_write(file, buffer, size);
            lock_release(&filesys_lock);    // 락 해제
        }
    }
    return write_bytes;
}

• buffer 에서 열린 파일 fd 로 size 만큼의 바이트를 쓴다
• 실제로 쓴 바이트 수를 반환
• 일부의 바이트를 쓸 수 없는 경우에는 반환값이 size 보다 작을 수 있다
• 파일 끝까지 가능한 한 많은 바이트를 쓰고, 실제 바이트 수를 반환하거나 쓸 수 없는 경우 0을 반환
• fd 1은 putbuf() 를 이용해서 콘솔에 쓴다

seek()

void seek(int fd, unsigned position){
    struct file *target_file = fdt_get_file(fd);

    if(fd <= STDOUT_FILENO || target_file == NULL)
        return;

    file_seek(target_file, position);
}

• position : 현재 위치(offset)를 기준으로 이동할 거리

• 열린 파일 fd 에서 읽거나 쓸 다음 바이트를 position으로 바꾼다

  • 즉 position 0 은 파일의 시작 위치

• 현재 파일의 끝을 지나서 읽는 것은 오류 X

  • 파일의 끝을 지나서 read를 실행하면 0을 반환

• but 파일의 끝을 지나서 쓰는 건(write) 불가능

• file_seek 함수 source code 및 해석

    file_seek (struct file *file, off_t new_pos) {
      // 파일 유효성 검사
        ASSERT (file != NULL);
        // 새로운 위치 확인 (파일의 위치는 0 이상이어야 한다)
        ASSERT (new_pos >= 0);
        // 파일 위치 업데이트 (인자값으로 받은 new_pos로 설정)
        file->pos = new_pos;
    }

tell()

unsigned tell(int fd){
    struct file *target_file = fdt_get_file(fd);

    if(fd <= STDOUT_FILENO || target_file == NULL)
        return;

    file_tell(target_file);
}

• 열린 파일 fd 에서 읽거나 쓸 다음 바이트를 반환

• file_tell 함수 source code 및 해석

    off_t
    file_tell (struct file *file) {
      // 파일 유효성 검사
        ASSERT (file != NULL);
        // 현재 위치 반환
        return file->pos;
    }

  • 현재 파일 내에서의 위치를 나타내는 파일 offset 반환

close()

void close(int fd){
    struct file *target_file = fdt_get_file(fd);

    if(fd <= STDOUT_FILENO || target_file == NULL || target_file <= 2)
        return;

    // fdt 에서 해당 fd값을 제거
    fdt_remove_fd(fd);
    // 파일을 닫음
    file_close(target_file);
}

• 파일을 닫고 fd를 제거

추가 함수

fdt_add_fd()

static int fdt_add_fd(struct file *f){
    struct thread *curr = thread_current();
    struct file **fdt = curr->fdt;

    while(curr->next_fd < FDCOUNT_LIMIT && fdt[curr->next_fd]){
        curr->next_fd++;
    }

    if(curr->next_fd >= FDCOUNT_LIMIT)
        return -1;

    fdt[curr->next_fd] = f;
    return curr->next_fd;
}

• file descriptor가 제한 범위를 넘지 않으면서 fdt의 인덱스 위치와 일치할 때 까지 다음 인덱스로 이동하는 것을 반복
• fdt가 가득 차게되면 return -1
• fdt에 인자값으로 받은 fd 삽입하고 다음 fd 인덱스를 반환

fdt_get_file()

static struct file *fdt_get_file(int fd){
    struct thread *curr = thread_current();
    if(fd < STDIN_FILENO || fd >= FDCOUNT_LIMIT)    // 실패
        return NULL;                

    return curr->fdt[fd];                            // 성공
}

• fd가 0이하 또는 512이상이면 파일 찾기 실패

fdt_remove_fd()

static void fdt_remove_fd(int fd){
    struct thread * curr = thread_current();

    if(fd < STDIN_FILENO || fd >= FDCOUNT_LIMIT)    // 실패
        return;

    curr->fdt[fd] = NULL;                            // 성공
}

• 조건은 위와 동일

get_child_process()

struct thread *get_child_process(int pid){
    struct thread *curr = thread_current();
    struct list *child_list = &curr->child_list;

    // 자식 리스트를 순회하면서 프로세스 디스크립터 검색
    for(struct list_elem *e = list_begin(child_list); e != list_end(child_list); e = list_next(e)){
        struct thread *t = list_entry(e, struct thread, child_elem);
        // 해당 pid가 존재하면 프로세스 디스크립터 반환
        if(t->tid == pid)
            return t;
    }
    // 리스트에 존재하지 않으면 NULL 반환
    return NULL;
}

• process_fork 를 통해 부모 프로세스에서 자식 프로세스를 복제하며 부모 프로세스의 child_list 에 자식 프로세스의 element 값을 넣어준다
• 이후, process_wait 과 process_fork 의 load 과정 이전에 tid 로 받은 프로세스가 실제 부모의 자식 프로세스가 맞는지 검증하는 과정을 거친다

함수 수정 및 추가

    // fdt 공간 할당
    t->fdt = palloc_get_multiple(PAL_ZERO, FDT_PAGES);
    if(t->fdt == NULL)
        return TID_ERROR;
    t->next_fd = 2;     // 0: stdin, 1: stdout
    t->fdt[0] = 1;      // STDIN_FILENO -> dummy value
    t->fdt[1] = 2;      // STDOUT_FILENO -> dummy value

• palloc_get_multiple(enum palloc_flags flags, size_t page_cnt)

  • source code (주석 포함)

      void *
      palloc_get_multiple (enum palloc_flags flags, size_t page_cnt) {
        // 사용자 영역인지 커널 영역인지 확인
          struct pool *pool = flags & PAL_USER ? &user_pool : &kernel_pool;
    
        /* 다중 스레드 환경에서 동시 접근을 방지하기 위해 해당 
           풀에 대한 락(lock) 획득 */
          lock_acquire (&pool->lock);
          /* bitmap_scan_and_flip 함수를 이용해 풀의 비트맵에서 
             연속된 'page_cnt'개의 빈 페이지를 찾는다 */
          size_t page_idx = bitmap_scan_and_flip (pool->used_map, 0, page_cnt, false);
          /* 페이지를 찾은 후에는 락을 해제 */
          lock_release (&pool->lock);
          void *pages;
    
        /* 페이지를 찾으면, 페이지의 시작 주소를 계산하여
           'pages' 변수에 저장 */
          if (page_idx != BITMAP_ERROR)
              pages = pool->base + PGSIZE * page_idx;
          else
            // 찾지 못하면 NULL로 설정
              pages = NULL;
    
          if (pages) {
            // 'PAL_ZERO' 비트가 설정되어 있으면 페이지를 0으로 초기화
              if (flags & PAL_ZERO)
                  memset (pages, 0, PGSIZE * page_cnt);
          } else {
            // 'PAL_ASSERT' 비트가 설정되어 있으면 커널을 패닉시킨다
              if (flags & PAL_ASSERT)
                  PANIC ("palloc_get: out of pages");
          }
        // 찾은 페이지의 시작 주소를 반환
          return pages;
      }

  • 연속된 여러 개의 빈 페이지를 할당하고 반환하는 함수

  • 인자값인 flags에 따라 사용자 영역이나 커널 영역에서 페이지를 할당하고, 필요에 따라 페이지를 0으로 초기화

  • STDIN(0), STDOUT(1) 은 미리 콘솔을 위해 예약된 fd이므로 next_fd 는 2부터 시작하도록 초기화한다.

  • fdt[0] 과 fdt[1] 에는 0(NULL)이 아닌 값으로 채워준다.

• enum palloc_flags

  • source code (주석 포함)

      enum palloc_flags {
          PAL_ASSERT = 001,           /* Panic on failure. */
          PAL_ZERO = 002,             /* Zero page contents. */
          PAL_USER = 004              /* User page. */
      };

    1. PAL_ASSERT (001):
       • 할당에 실패하면 패닉(Panic)을 발생
       • 할당에 실패할 경우, 프로그램이 중단되고 오류 메시지가 표시
    2. PAL_ZERO (002):
       • 할당된 페이지의 내용을 0으로 초기화
       • 즉, 페이지에 저장되는 데이터를 모두 0으로 설정
    3. PAL_USER (004):
       • 할당된 페이지가 사용자 페이지인 경우
       • 사용자 페이지는 일반적으로 사용자 프로세스에 의해 사용 커널 페이지와는 구분

  ...

  palloc_free_multiple(curr->fdt, FDT_PAGES);        // fdt 메모리 해제
    file_close(curr->running);                        // 현재 프로세스가 실행중인 파일 종료

    process_cleanup();

    // 부모 프로세스가 자식 프로세스의 종료상태를 확인하게 한다
    sema_up(&curr->wait_sema);
    // 부모 프로세스가 자식 프로세스의 종료 상태를 받을때 까지 대기한다
    sema_down(&curr->free_sema);
}

• 자식 프로세스의 종료 시, 부모 프로세스에게 자식 프로세스의 종료를 알릴 수 있게끔 세마포어 연산 수행

lock_init(&filesys_lock);

#ifdef USERPROG

    ...
    int exit_status;        // 프로세스 종료 유무 확인
    struct file **fdt;      // file descriptor table의 시작주소(프로세스당 개별적으로 존재)
    int next_fd;            // 다음 file descriptor의 인덱스
    struct file *running;   // 현재 실행 중인 파일

    struct intr_frame parent_if;    // 부모 프로세스의 인터럽트 프레임
    struct list child_list;         // 자식 프로세스 리스트
    struct list_elem child_elem;    // 자식 프로세스 리스트의 element

    struct semaphore fork_sema;     // fork가 완료될 때 sema_up 수행
    struct semaphore free_sema;     // 자식 프로세스가 종료될 때까지 부모 프로세스는 대기
    struct semaphore wait_sema;     // 자식 프로세스가 종료될 때까지 대기, 종료 상태 저장
        ...

#endif

...
    t->exit_status = 0;
    t->running = NULL;
    // 자식 리스트 및 세마포어 초기화
    list_init(&t->child_list);
    sema_init(&t->wait_sema, 0);
    sema_init(&t->fork_sema, 0);
    sema_init(&t->free_sema, 0);
 }

• 수정한 thread 구조체에 대한 초기화 작업 수행
• 이때 세마포어 값은 0
  • 부모 프로세스에서 먼저 호출하기 때문에 부모 프로세스를 대기(wait 상태) 시키기 위해서 0으로 만들어야함

static bool
load (const char *file_name, struct intr_frame *if_) {
    struct thread *t = thread_current ();
    struct ELF ehdr;
    struct file *file = NULL;
    off_t file_ofs;
    bool success = false;
    int i;

    ...

    t->running = file;

    file_deny_write(file); // 현재 오픈한 파일에 접근 못하게 함

    ...

    return success;
}

• exec를 통해 파일을 실행하게 되면 해당 프로세스에 해당하는 파일은 열린 상태로 있으므로 struct thread 의 running 필드에 해당 파일을 추가한다.
  • process_exit 에서 해당 파일에 대해 닫아주는 작업을 수행한다.
    • 또, 현재 실행하기위해 오픈한 파일에 대해 접근하지 못하게 하기 위해 file_deny_write를 이용해 접근 제한을 걸어준다.

시스템 콜을 구현하기 위해 유저의 가상 주소 공간에 접근할 수 있는 방법을 제시해줘야 한다

void check_address(void* uaddr) {
    struct thread *cur = thread_current();
    if (uaddr == NULL || is_kernel_vaddr(uaddr) || pml4_get_page(cur->pml4, uaddr) == NULL) {
        exit(-1);
    }
}

• NULL pointer(유효하지 않은 포인터)이거나
• 커널 메모리에 대한 포인터를 가리키거나
• 맵핑되지 않은 vm에 대한 포인터라면
• 프로세스 종료

System Call

• 시스템 콜(halt, exit, create, remove 등)을 구현하고 시스템 콜 핸들러를 통해 호출
• %rax 는 system call number
• 네 번째 argument는 %rcx가 아니라 %r10 이다
• 따라서 syscall_handler() 가 제어권을 잡으면, system call number는 %rax 안에 있게 되고, arguments들은 %rdi, %rsi, %rdx, %r10, %r8, %r9 순서로 전달

pintOS의 시스템 콜 호출 과정

• 유저 프로그램에서 write() 시스템 콜 호출
• pintos/lib/user/syscall.c 에서 write() 함수 호출

int
write (int fd, const void *buffer, unsigned size) {
    return syscall3 (SYS_WRITE, fd, buffer, size);
}

• SYS_WRITE는 include/lib/syscall-nr.h 에 enum으로 정의(SYS_WRITE = 10)
• 이 시스템 콜 번호와 받아온 인자값들을 가지고 syscall3을 호출
  • 이때의 syscall 뒤에 붙는 숫자는 인자(argument)의 개수
• syscall3 은 syscall을 호출
• 레지스터에 인자값을 넣고, 어셈블리어로 syscall을 호출 → syscall-entry.s 로 이동

• rsp(stack pointer) 값을 바꿔줌으로써 커널 스택으로 진입

• syscall_handler로 이동 후 시스템 콜 함수 호출

int write(int fd, const void *buffer, unsigned size) {
    check_address(buffer);
    int bytes_write = 0;
    if (fd == STDOUT_FILENO) {
        putbuf(buffer, size);
        bytes_write = size;
    } else {
        if (fd < 2)
            return -1;
        struct file *file = process_get_file(fd);
        if (file == NULL)
            return -1;
        lock_acquire(&filesys_lock);
        bytes_write = file_write(file, buffer, size);
        lock_release(&filesys_lock);
    }
    return bytes_write;
}

시스템 콜 write함수 호출 완료 !!

• pintOS는 프로그램과 인자를 구분하지 못하는 구조이다. ex) ls -a (pintOS 는 'ls-a'를 하나의 프로그램명으로 인식)

• 프로그램 이름과 인자를 구분하여 스택에 저장, 인자를 응용 프로그램에 전달하는 기능을 구현하자.

과제를 해결하기 위해서는?

• 응용 프로그램 실행 흐름을 추적하여 프로그램 파싱 시점을 파악
• 문자열 파싱을 담당하는 함수 이용
• 함수 호출 규약에 따른 인자 전달 메커니즘 이해 및 이를 저장하는 인터페이스 구현

함수 호출 규약이란?

유닉스 64비트 x86-64 구현에 있는 몇 가지 중요한 호출 규약들은 다음과 같다.

유저-레벨 어플리케이션은 %rdi, %rsi, %rdx, %rcx, %r8, %r9 시퀀스들을 전달하기 위해 정수 레지스터를 사용합니다. 호출자는 다음 인스트럭션의 주소(리턴 어드레스)를 스택에 푸시하고, 피호출자의 첫번째 인스트럭션으로 점프합니다. CALL 이라는 x86-64 인스트럭션 하나가 이 두 가지를 모두 수행합니다. 피호출자가 실행됩니다. 만약 피호출자가 리턴 값을 가지고 있다면, 리턴 값은 레지스터 RAX에 저장됩니다. 피호출자는 x86-64 인스트럭션인 RET 를 사용해서, 스택에 받았던 리턴 어드레스를 pop하고 그 주소가 가리키는 곳으로 점프함으로써 리턴됩니다.

우리는 userprog 디렉토리의 process.c 파일을 수정할 것이다.

커널은 유저 프로그램이 실행되기 전에, 레지스터에 올라가 있는 초기 함수를 위한 인자를 반드시 넣어줘야 한다. (이 인자들은 일반적인 호출 규약과 동일한 방식으로 전달)

👉 /bin/ls -l foo bar 와 같은 명령이 주어졌을 때, 인자들을 어떻게 다뤄야 하는지 생각해보자.

1. 명령어를 띄어쓰기 단위로 쪼갠다 -> /bin/ls, l, foo, bar
2. 이 단어들을 스택에 넣는다. 순서는 상관 X (포인터에 의해 참조될 예정이기 때문)
3. 각 문자열의 주소 + 경계조건을 위한 널포인터를 스택에 오른쪽→왼쪽 순서로 푸시

**이들은 argv의 원소가 된다. 널포인터 경계는 argv[argc] 가 널포인터라는 사실을 보장해준다. 그리고 이 순서는 argv[0]이 가장 낮은 가상 주소를 가진다는 사실을 보장해준다. 또한 word 크기에 정렬된 접근이 정렬되지 않은 접근보다 빠르므로, 최고의 성능을 위해서는 스택에 첫 푸시가 발생하기 전에 스택포인터를 8의 배수로 반올림 해준다.

// userprog/process.c/argument_stack()

...

int padding = (int)*rsp % 8;
    for (int i = 0; i < padding; i++)
    {
        (*rsp)--;
        **(uint8_t **)rsp = 0;        // rsp 직전까지 값 채움
    }

 ...

4. %rsi 가 argv 주소(argv[0]의 주소)를 가리키게 하고, %rdi 를 argc 로 설정한다.
5. 마지막으로 가짜 “리턴 주소”를 푸시 : entry 함수는 절대 리턴되지 않겠지만, 해당 스택 프레임은 다른 스택 프레임들과 같은 구조를 가져야 하기 때문에.

Argument Passing(인자 전달) 구현

구현 할 때 크게 두 부분으로 나눠서 구현한다

• 받은 문자열을 parsing후 argv, argc에 저장
• stack에 인자 넣기

유저 프로그램을 실행시키는 전체적인 흐름은 다음과 같다

Todo

• command line을 parsing해서 스레드의 이름을 식별한다.
• 해당 파일 이름을 갖는 프로그램을 찾는다.
• user stack에 인자를 push한다.

유저 스택에 파싱된 토큰을 저장하는 함수 구현

void argument_stack(char **parse ,int count ,void **esp)

• parse : 프로그램 이름과 인자가 저장되어 있는 메모리 공간
• count : 인자의 개수
• esp : 스택 포인터를 가리키는 주소

코드의 흐름

init.c → int main(void) → run_actions(argv) → run_task(char **argv) → process_create_initd(task) → thread_create (file_name, PRI_DEFAULT, initd, fn_copy) → initd→process_exec → load, do_iret

1. Argument Passing (인자 전달)
2. User Memory Access (유저 메모리 접근)
3. System Calls (시스템 콜)
4. Process Termination Message (프로세스 종료 메세지)
5. Deny Write on Executables (실행 파일에 쓰기 거부)
6. Extend File Descriptor (파일 식별자 확장하기 | Extra)

Intro

지난번까지의 과제에서 실행한 모든 코드는 커널의 일부로서 시스템에 중요한 부분에 접근 할 수 있는 특권을 가지고 실행되었다. 하지만 유저 프로그램을 실행하기 시작하면 더 이상 그런 특권은 갖지 못한다. 지금부터의 과제는 이런 상황을 다뤄야 한다.

pintOS에서의 프로세스는 하나의 스레드만을 가질 수 있다.(멀티스레드 프로세스 지원 X) 이러한 상황에서 우리는 한번에 하나 이상의 프로그램이 실행될 수 있도록 할 것이다. 이는 우리가 한번에 여러 프로세스들을 로드하고 실행할 때 메모리, 스케쥴링, 그 외 다른 상태들을 모두 관리해야 한다는 것을 의미한다.

Source Files

우리는 userprog 디렉토리에서 작업할 것이다.

process.c, process.h

• ELF binaries를 불러와 프로세스를 시작할 것이다.

  ELF binaries : 리눅스에서 실행 가능(Executable)하고 링크 가능(Linkable)한 file의 Format을 ELF(Executable and Linkable Format)라고 한다. 즉, 실행 가능한 바이너리 또는 오브젝트 파일 등의 형식을 규정한 것 !

syscall.c, syscall.h

• 여러 시스템 콜을 수행하는 코드로 이루어진 파일.

  유저 프로세스가 일부 커널 기능에 접근하려 할때마다 시스템 콜이 호출된다. 현재 상태에서는 단지 메세지를 출력하고 유저 프로세스를 종료시키게 되어있다.

syscall-entry.S

• 시스템 콜 핸들러를 부트스트랩하는 어셈블리 코드로 이루어져 있다.

  부트스트랩 프로그램 : 전원을 켜거나 재부팅을 할 때 적재되는 프로그램

exception.c, exception.h

• 유저 프로그램이 특별한 접근 권한을 필요로 하거나 금지된 연산을 수행할 때, exception 혹은 fault로 커널에서 오류를 띄우는데, 이런 오류를 다루는 코드의 파일이다.

  응용프로그램이 시스템 콜을 호출하면 하드웨어는 '트랩 핸들러'를 실행하여 하드웨어 특권 수준을 커널모드로 격상시킨다. 커널모드에서 운영체제는 시스템 하드웨어를 자유롭게 접근할 수 있다.

gdt.c, gdt.h

• x86-64는 segmented architecture이다. Global Descriptor Table(GDT)는 사용중인 세그먼트들을 알려주는 표이고, 이 파일은 GDT를 셋업한다.

  segmentation 기법 : 프로그램을 논리적 의미 단위인 세그먼트의 집합으로 구성하는 방식

tss.c, tss.h

• Task-State Segment(TSS)는 x86 아키텍쳐의 context switching에 사용된다. 하지만 x86-64에서 context switching은 지원이 중단된 기능이다. 그래도 TSS는 여전히 ring switching 동안 스택 포인터를 찾아내기 위해 사용되고 있다.

  유저 프로세스가 인터럽트 핸들러에 진입할 때, 하드웨어는 TSS에게 커널의 스택 포인터를 찾아 달라고 요청한다.

Virtual Memory Layout

pintOS에서 가상 메모리는 두 영역으로 나눌 수 있다

• User Virtual Memory
  • 유저 가상 메모리는 가상 주소 0부터 KERN_BASE까지의 범위를 갖는다. (KERN_BASE : 0x8004000000)
• Kernel Virtual Memory
  • 유저 가상 메모리를 제외한 나머지 주소 공간을 차지한다.

하나의 프로세스는 하나의 유저 가상 메모리는 갖는다. 프로세스 context switching이 일어날 때, 커널은 유저 가상 주소 공간 또한 바꿔준다. 스레드 구조체는 하나의 프로세스의 페이지 테이블을 가리키는 포인터를 가지고 있다.

pintOS에서 커널 가상 메모리는 물리 메모리와 일대일 대응으로 매핑되는데, 이는 KERN_BASE에서 시작한다. 즉, 가상 주소 KERN_BASE가 물리 메모리 0에 접근하고, 가상주소 KERN_BASE + 0x1234 가 물리주소 0x1234에 접근한다.

유저 프로그램은 자신의 유저 가상 메모리에만 접근할 수 있다. 만약 커널 가상 메모리에 접근하려 시도하면 page fault를 일으키고 프로세스는 종료된다.

반면, 커널 스레드는 커널 가상 메모리와 동작 중인 프로세스의 사용자 가상 메모리에도 접근 가능하다. 하지만 커널 안에서도 매핑되지 않은 주소에 접근하면 page fault를 일으킨다.

WebSocket은 서버와 클라이언트 간의 메시지 교환을 위한 통신 규약(프로토콜)이다. HTTP 프로토콜이 요청-응답 방식인 것과 달리, WebSocket은 한 번 연결이 성립되면 클라이언트와 서버가 자유롭게 데이터를 주고받을 수 있는 것이 특징이다.

WebSocket의 특징

• 양방향 통신
  • 클라이언트와 서버가 양방향으로 동시에 데이터를 주고받을 수 있다
• 실시간 데이터 전송
  • 연결이 성립된 후에는 실시간으로 데이터를 주고받을 수 있어, 지연 시간이 적다
• 낮은 오버헤드
  • HTTP 프로토콜보다 헤더 정보가 적어, 데이터 전송 시 오버헤드가 적다
• 연결 유지
  • 한 번 연결이 성립되면 연결을 유지하면서 지속적으로 데이터를 주고받을 수 있다. 재연결이 필요 없다

웹 소켓이 나오기 전까지의 통신 방식

웹 소켓이 등장하기 전에는 주로 다음과 같은 방식으로 클라이언트와 서버 간의 통신이 이루어졌다

HTTP 폴링 (HTTP Polling)

HTTP 폴링은 클라이언트가 주기적으로 서버에 HTTP 요청을 보내고, 서버가 새로운 데이터를 가지고 있으면 응답을 통해 전달하는 방식이다.

특징

• 클라이언트가 일정 간격으로 서버에 요청을 보낸다.
• 실시간성이 낮고, 많은 불필요한 요청이 발생한다.
• 서버 부하가 높아질 수 있다.

롱 폴링 (Long Polling)

롱 폴링은 클라이언트가 서버에 요청을 보내고, 서버는 새로운 데이터가 생길 때까지 응답을 지연시킨 후 전달하는 방식이다. 데이터가 준비되면 즉시 응답을 보내고, 클라이언트는 다시 요청을 보낸다.

특징

• 실시간성은 HTTP 폴링보다 높다.
• 클라이언트와 서버 간 연결이 오래 유지되므로 HTTP 연결의 오버헤드가 줄어든다.
• 서버 부하가 다소 줄어들지만, 여전히 연결 관리가 필요하다.

HTTP 스트리밍 (HTTP Streaming)

HTTP 스트리밍은 서버가 클라이언트와의 HTTP 연결을 끊지 않고 지속적으로 데이터를 푸시하는 방식이다. 클라이언트는 하나의 긴 HTTP 요청을 보내고, 서버는 응답을 끊지 않고 여러 데이터를 지속적으로 전송한다.

특징

• 지속적인 연결
  • 클라이언트가 연결을 열어두고, 서버가 데이터가 준비될 때마다 전송한다.
• 실시간성
  • 데이터가 준비되는 즉시 전송되므로, 실시간 통신에 적합하다.
• 단방향 통신
  • 서버에서 클라이언트로의 데이터 전송만 가능하다.
• HTTP 기반
  • HTTP 프로토콜을 사용하므로, 방화벽 및 프록시 서버를 통과하는 데 유리하다.

WebSocket 동작 과정

1. Handshake

WebSocket 연결은 HTTP 요청을 통해 시작된다. 클라이언트가 서버에 WebSocket 연결을 요청하는 HTTP 업그레이드(Upgrade) 요청을 보낸다. 이 요청은 일반적인 HTTP 요청과 비슷하지만, 몇 가지 특별한 헤더가 포함된다.

클라이언트의 요청 예시:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

• Upgrade: websocket: HTTP 연결을 WebSocket으로 업그레이드하도록 요청.
• Connection: Upgrade: 연결을 업그레이드할 것임을 명시.
• Sec-WebSocket-Key: 클라이언트가 생성한 임의의 키. 서버는 이 키를 이용해 응답을 생성.
• Sec-WebSocket-Version: WebSocket 프로토콜의 버전.

서버 응답 예시:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• 101 Switching Protocols: 성공적으로 프로토콜이 업그레이드되었음을 나타냄.
• Sec-WebSocket-Accept: 클라이언트의 Sec-WebSocket-Key를 기반으로 생성된 응답 키.

2. 데이터 전송 (Data Transfer)

WebSocket은 데이터를 프레임 단위로 전송한다. 각 프레임은 데이터의 조각을 담고 있으며, 여러 종류의 프레임이 존재한다.

프레임 종류

• 텍스트 프레임: 텍스트 데이터를 전송.
• 바이너리 프레임: 바이너리 데이터를 전송.
• 닫기(Close) 프레임: 연결을 종료.

데이터 프레임 구조

WebSocket 프레임은 헤더와 페이로드(Payload)로 구성된다. 헤더는 프레임의 메타데이터를 포함하고, 페이로드는 실제 전송되는 데이터를 포함한다.

3. 연결 종료 (Connection Closure)

연결을 종료하려면 클라이언트나 서버 중 하나가 닫기(Close) 프레임을 전송해야 한다. 닫기 프레임은 종료 코드와 선택적인 종료 이유를 포함할 수 있다.

• 연결 종료 절차
  • 클라이언트나 서버가 닫기 프레임을 전송.
  • 상대방이 닫기 프레임을 수신하고 응답으로 닫기 프레임을 전송.
  • 양측의 연결이 종료되고, 더 이상 데이터가 전송되지 않음.