10월

10/2

Rust

Use Rust to supercharge your JavaScript, one module at a time. Publish to npm, bundle with webpack, and you’re off to the races.

Predictable performance. Tiny resource footprint. Rock-solid reliability. Rust is great for network services.

writing web apps, working on servers

어셈블리 명령은 cpu에 물리적으로 코딩되어있다.

asm명령어를 통해 c++중간에 assembly를 작성할수있다.

정말 time critical한것은 asm으로 수행하면 반드시 정해진 시간안에 수행된다.

rust에서도 inline assembly를 작성할 수 있다. 하드웨어, 컴퓨터 메모리를 직접 접근가능

gpu제어에 웹어셈블리가 강해짐

10/3

32비트 레지스터에서 8바이트(64비트) 데이터를 읽어오려면 두 개의 32비트 레지스터를 사용해야 합니다. 첫 번째 레지스터는 데이터의 상위 32비트를 저장하고, 두 번째 레지스터는 하위 32비트를 저장하게 됩니다. 이렇게 하면 64비트 데이터를 처리할 수 있습니다.

20바이트짜리 객체의 멤버를 가져올 때는 32비트 레지스터를 사용하여 멤버를 나눠서 읽어와야 합니다. 32비트 레지스터는 4바이트를 저장할 수 있으므로, 20바이트의 객체의 멤버를 가져오려면 필요한 만큼의 레지스터를 사용하여 데이터를 나누어 읽어와야 합니다.

10/4

이더리움 요청

curl  https://eth.llamarpc.com\
--request POST 

--header "Content-Type: application/json" 

--data '{ "jsonrpc":"2.0", "method":"eth_blockNumber","params":[],"id":1}'
{"jsonrpc":"2.0","id":1,"result":"0x12a7d9f"}
Bash
복사

이 코드는 Ethereum 블록체인에 요청을 보내는 cURL 명령어입니다. 자세히 설명하자면:

URL: https://eth.llamarpc.com - Ethereum RPC(원격 프로시저 호출) 서버에 요청을 보냅니다.

HTTP 메서드: POST - 데이터를 서버에 전송합니다.

헤더: "Content-Type: application/json" - 전송되는 데이터의 형식이 JSON임을 명시합니다.

데이터:

{ "jsonrpc":"2.0", "method":"eth_blockNumber", "params":[], "id":1}
JSON
복사

•

jsonrpc: JSON-RPC 프로토콜 버전.

•

method: 호출할 메서드 이름, 여기서는 현재 블록 번호를 요청하는 eth_blockNumber.

•

params: 메서드에 필요한 매개변수, 이 경우는 없음.

•

id: 요청의 식별자.

응답:

{"jsonrpc":"2.0","id":1,"result":"0x12a7d9f"}
JSON
복사

•

result: 현재 블록 번호를 나타내며, 0x12a7d9f는 10진수로 변환 시 19721183을 의미합니다.

따라서 이 요청은 현재 Ethereum 블록체인의 블록 번호를 조회하는 것입니다.

RPC와 REST의 차이점

원격 프로시저 호출(RPC)과 REST는 API 설계의 2가지 아키텍처 스타일입니다. API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. 소프트웨어 개발자는 이전에 개발된 구성 요소나 서드 파티 구성 요소를 사용하여 함수를 실행하므로 처음부터 모든 것을 작성할 필요가 없습니다. RPC API를 사용하면 개발자가 외부 서버의 원격 함수를 마치 해당 소프트웨어 로컬에 있는 것처럼 직접적으로 호출할 수 있습니다. 예를 들어 다른 채팅 애플리케이션에서 메시징 함수를 원격으로 직접 호출하여 해당 애플리케이션에 채팅 기능을 추가할 수 있습니다. 반면 REST API를 사용하면 원격 서버에서 특정 데이터 작업을 수행할 수 있습니다. 예를 들어 애플리케이션은 REST API를 사용하여 원격 서버에 직원 데이터를 삽입하거나 수정할 수 있습니다.

RPC와 REST의 유사점은 무엇인가요?

원격 프로시저 호출(RPC)과 REST는 둘 다 API를 설계하는 방법입니다. API는 현대적 웹 설계 및 기타 분산 시스템에서 필수적인 요소입니다. API를 사용하면 2개의 개별 분산 애플리케이션 또는 서비스가 상대의 애플리케이션 또는 서비스의 내부 작동 방식을 몰라도 통신할 수 있습니다. 이 두 애플리케이션 또는 서비스는 소규모 데이터 교환을 제외하고는 서로 거의 하는 일이 없을 수 있습니다.

API는 프로그램의 백엔드(로직 구성 요소)에서 프로그램의 프런트엔드(디스플레이 구성 요소)와 통신하기 위한 일반적인 메커니즘이기도 합니다. 긴밀하게 결합된 통합 대신 API를 사용하여 웹 페이지와 웹 애플리케이션을 설계하면 코드를 다시 작성하지 않고도 규모를 조정하고 변경할 수 있습니다.

다음으로 RPC와 REST API 간의 다른 유사점에 대해 살펴보겠습니다.

추상화

API의 주요 목표는 네트워크 통신이지만 하위 수준 통신 자체는 API 개발자와 별개로 추상화됩니다. 따라서 개발자가 기술적 구현보다 기능에 집중할 수 있습니다.

통신

REST와 RPC 모두 HTTP를 기본 프로토콜로 사용합니다. RPC와 REST에서 가장 많이 사용되는 메시지 형식은 JSON과 XML입니다. JSON은 가독성과 유연성 때문에 선호됩니다.

언어 간 호환성

개발자는 원하는 언어로 RESTful 또는 RPC API를 구현할 수 있습니다. API의 네트워크 통신 요소가 RESTful 또는 RPC 인터페이스 표준을 준수하기만 하면 모든 프로그래밍 언어로 나머지 코드를 작성할 수 있습니다.

아키텍처 원칙: RPC와 REST

원격 프로시저 호출(RPC)에서 클라이언트는 서버에서 원격 함수(메서드 또는 프로시저라고도 함)를 직접적으로 호출합니다. 일반적으로 직접 호출 중에 하나 이상의 데이터 값이 서버에 전달됩니다.

반면 REST 클라이언트는 서버에 특정 서버 리소스에 대한 작업을 수행할 것을 요청합니다. 작업은 생성, 읽기, 업데이트 및 삭제(CRUD)로만 제한되며 HTTP 동사 또는 HTTP 메서드로 전달됩니다.

RPC는 기능이나 작업에 초점을 맞추고 REST는 리소스 또는 객체에 초점을 맞춥니다.

RPC 원칙

다음으로 RPC 시스템이 일반적으로 따르는 몇 가지 원칙에 대해 살펴보겠습니다. 그러나 이러한 원칙이 REST처럼 표준화된 것은 아닙니다.

원격 간접 호출

클라이언트는 원격 서버의 함수에 대해 RPC를 직접적으로 호출하는 데, 마치 클라이언트에 로컬로 호출된 것처럼 호출합니다.

파라미터 전달

클라이언트는 일반적으로 로컬 함수와 같은 방식으로 서버 함수에 파라미터를 전송합니다.

스텁

함수 스텁은 클라이언트와 서버 모두에 존재합니다. 클라이언트 측에서는 함수를 직접적으로 호출합니다. 서버에서는 실제 함수를 간접적으로 호출합니다.

REST 원칙

REST 원칙은 표준화되어 있습니다. REST API는 이러한 원칙을 따라야 RESTful로 분류됩니다.

클라이언트-서버

REST의 클라이언트-서버 아키텍처는 클라이언트와 서버를 분리합니다. 각각을 독립적인 시스템으로 취급합니다.

무상태

서버는 클라이언트 요청 사이에 클라이언트의 상태를 기록하지 않습니다.

캐싱 가능

클라이언트 또는 중개 시스템에서는 클라이언트에서 응답의 캐시 가능성을 지정하는지 여부에 따라 서버 응답을 캐시할 수 있습니다.

계층형 시스템

클라이언트와 서버 사이에 중개자가 존재할 수 있습니다. 클라이언트와 서버 모두 이를 알지 못하며 마치 직접 연결된 것처럼 작동합니다.

균일한 인터페이스

클라이언트와 서버는 표준화된 명령 및 메시징 형식 세트를 통해 REST API와 통신합니다. 리소스는 해당하는 URL로 식별되며 이 URL을 REST API 엔드포인트라고 합니다.

작동 방식: RPC와 REST

원격 프로시저 호출(RPC)에서 클라이언트는 HTTP POST를 사용하여 특정 함수를 이름으로 직접 호출합니다. RPC가 작동하려면 클라이언트 측 개발자가 미리 함수 이름과 파라미터를 알고 있어야 합니다.

REST에서 클라이언트와 서버는 GET, POST, PATCH, PUT, DELETE, OPTIONS와 같은 HTTP 동사를 사용하여 옵션을 수행합니다. 서버 리소스 URL을 알기만 하면 개별 함수 이름에 신경 쓸 필요가 없습니다.

다음 표에는 클라이언트가 RPC와 REST에서 유사한 작업을 수행하는 데 사용하는 코드 유형이 나와 있습니다.

작업	RPC	REST	의견
제품 목록에 새 제품 추가	POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"}	POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"}	RPC는 함수에 POST를 사용하고 REST는 URL에 POST를 사용합니다.
제품 세부 정보 검색	POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”}	GET /products/123 HTTP/1.1 HOST: api.example.com	RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 GET을 사용하고 URL로 파라미터를 전달합니다.
제품 가격 업데이트	POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"}	PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"}	RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 PUT을 사용하고 URL 및 JSON 객체로 파라미터를 전달합니다.
제품 삭제	POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""}	DELETE /products/123 HTTP/1.1 HOST: api.example.com	RPC는 함수에 POST를 사용하고 JSON 객체로 파라미터를 전달합니다. REST는 URL에 DELETE를 사용하고 URL로 파라미터를 전달합니다.

주요 차이점: RPC와 REST

원격 프로시저 호출(RPC)과 REST는 모두 인터넷 통신을 위해 해당하는 클라이언트와 서버 시스템 인터페이스를 설계하는 방법입니다. 그러나 구조, 구현 및 기본 원칙은 다릅니다. REST를 사용하여 설계된 시스템을 RESTful API라고 하는 반면, RPC로 설계된 시스템은 단순히 RPC API입니다.

다음으로 몇 가지 차이점을 더 살펴보겠습니다.

개발 시기

RPC는 1970년대 후반부터 1980년대 초에 개발되었으며, REST는 2000년에 컴퓨터 사이언티스트 Roy Fielding이 처음 만든 용어입니다.

작업 형식

REST API에는 HTTP 메서드 때문에 표준화된 서버 작업 세트가 있지만 RPC API는 그렇지 않습니다. 일부 RPC 구현은 표준화된 운영을 위한 프레임워크를 제공합니다.

데이터 전달 형식

REST는 동일한 API 내에서 모든 데이터 형식과 JSON 및 XML 같은 여러 형식을 전달할 수 있습니다.

하지만 RPC API의 경우 서버가 데이터 형식을 선택하고 구현 중에 수정합니다. 특정 JSON RPC 또는 XML RPC를 구현할 수 있지만 클라이언트 유연성은 없습니다.

사용 시기: RPC와 REST

원격 프로시저 호출(RPC)은 일반적으로 서버에서 작업 결과가 필요한 원격 함수를 호출하는 데 사용됩니다. 복잡한 계산이 필요하거나 프로세스를 클라이언트에 숨긴 상태로 서버에서 원격 프로시저를 트리거하려는 경우에 사용할 수 있습니다.

RPC가 적합한 작업은 다음과 같습니다.

•

원격 디바이스의 카메라로 사진 찍기

•

서버의 기계 학습 알고리즘을 사용하여 사기 행위를 식별

•

원격 뱅킹 시스템에서 한 계좌에서 다른 계좌로 자금 이체

•

원격으로 서버 재시작

REST API는 일반적으로 서버의 데이터 객체에 대한 생성, 읽기, 업데이트 및 삭제(CRUD) 작업을 수행하는 데 사용됩니다. 따라서 REST API는 서버 데이터와 데이터 구조를 균일하게 노출해야 하는 경우에 적합합니다.

REST API가 적합한 작업은 다음과 같습니다.

•

데이터베이스에 제품 추가

•

음악 재생 목록의 콘텐츠 검색

•

사용자 주소 업데이트

•

블로그 게시물 삭제

REST가 RPC를 대체한 이유는 무엇인가요?

지금은 REST 웹 API가 일반적이지만 원격 프로시저 호출(RPC)이 사라진 것은 아닙니다. REST API가 애플리케이션에 일반적으로 사용되는 이유는 개발자가 이해하고 구현하기가 더 쉽기 때문입니다. 하지만 RPC는 여전히 존재하며 사용 사례에 더 적합하다면 RPC가 사용됩니다.

이제는 gRPC와 같은 RPC의 현대적 구현이 더 많이 사용되고 있습니다. 일부 사용 사례에서는 gRPC가 RPC 및 REST보다 성능이 더 좋습니다. gRPC를 사용하면 요청 및 응답 데이터 교환 패턴 대신 클라이언트-서버 통신을 스트리밍할 수 있습니다.

차이점 요약: RPC와 REST

	RPC	REST
무엇인가요?	원격 클라이언트에서 서버의 프로시저를 마치 로컬인 것처럼 직접적으로 호출할 수 있게 하는 시스템입니다.	클라이언트와 서버 간의 정형 데이터 교환을 정의하는 일련의 규칙입니다.
용도	원격 서버에서 작업을 수행합니다.	원격 객체에 대한 생성, 읽기, 업데이트 및 삭제(CRUD) 작업을 수행합니다.
가장 적합한 사용 사례	복잡한 계산이 필요하거나 서버에서 원격 프로세스를 트리거하는 경우	서버 데이터 및 데이터 구조를 균일하게 노출해야 하는 경우
상태 유지 여부	상태 유지 또는 무상태	무상태
데이터 전달 형식	서버에서 정의하고 클라이언트에 적용되는 일관된 구조	서버에 의해 독립적으로 결정되는 구조. 동일한 API 내에서 여러 형식을 전달할 수 있습니다.

tRPC는 typescript only rpc이다

rpc는 클라이언트에서 서버함수 호출할수도 있고 일반적으로 마이크로서비스에서 server to server communication으로 쓰인다

클라이언트에서 gRPC를 사용하는것과 rest 사용하는것에 큰 차이는 없다

rest graphql grpc trpc websocket

RPC(원격 프로시저 호출)의 원리는 네트워크를 통해 다른 컴퓨터에 있는 프로그램의 함수를 호출하는 것입니다. 즉, 클라이언트가 요청을 보내면 서버에서 해당 요청을 처리하고 결과를 다시 클라이언트에게 반환하는 방식입니다.

RPC는 일반적으로 소켓 통신을 기반으로 하여 구현됩니다. 소켓은 네트워크 통신을 가능하게 하는 프로그래밍 인터페이스로, 클라이언트와 서버 간의 데이터 교환을 담당합니다. RPC 프레임워크는 이러한 소켓 통신을 추상화하여 개발자가 함수 호출처럼 쉽게 사용할 수 있도록 도와줍니다.

즉, RPC는 네트워크 통신의 복잡성을 감추고, 프로그래머가 마치 로컬 함수처럼 원격 함수를 호출할 수 있게 해주는 기술입니다.

이더넷 = 광케이블 통해서 데이터 패킷을 받고 프로토콜에 따라서 전송 및 처리해서 컴퓨터간 통신. 소켓은 운영체제에서 제공하는 추상적인 개념 네트워크 간 데이터 전송

웹소켓은 자체 프로토콜 사용하면서http요청을 통해 연결읈 시작하지만 이후에는 ws 프로토콜

gRPC는 http/2위에 구축됨

rest api는 http를 최대한 활용한 api

원래 jsp등은 웹페이지 자체를 구성해서 전송했다

하지만 컴퓨터 브라우저가 아닌 휴대폰, 태블릿 등으로 데이터를 보내는 서버를 일일이 만드는것은 비효율적이다

그래서 json과같은 클라이이너트에서 바로 객체로 치환 가능한 데이터 형태의 통신을 지향각 자원을 URI로 구분

REST API의 method가 crud

10/8

HTTP

HTTP/1.1

•

Persistent Connection 추가

◦

HTTP/1.0을 보완하여 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 일정 시간동안 연결 상태를 유지

Persistent Connection 도식화

•

Pipelining 추가

◦

TCP의 특성상 요청 후 응답을 기다려야하는 문제를 보완

◦

클라이언트는 앞 요청의 응답을 기다리지 않고 순차적으로 요청 전송, 서버는 요청이 들어온 순서대로 응답

Pipelining 도식화

•

HOL Blocking (Head Of Line Blocking) 문제

◦

앞의 요청(패킷)에 대한 응답이 늦어지면 뒤의 모든 요청들은 모두 blocking되어 응답이 지연됨

•

연속된 요청 간에 헤더의 많은 중복이 생긴다는 문제

HTTP/2.0

•

HTTP/1.x의 시간 지연 문제를 해결

•

Multiplexed streams (멀티플렉싱)

◦

HTTP/1.1의 Pipelining은 한번의 연결에서 여러 요청을 보낼 수는 있었지만 동시에 여러 요청을 처리하진 못했음

◦

하나의 커넥션 내에 여러개의 스트림(stream, 양방향 데이터 흐름)을 사용하여 송수신

◦

메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 스트림(stream)을 통해 전달

◦

프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해짐

◦

스트림(stream)을 통해 각 요청의 응답 순서가 의미가 없어져 HTTP/1.x의 HOL Blocking 문제 해결

Multiplexing 도식화

•

Header Compression (헤더 압축)

◦

요청과 응답 헤더의 메타데이터를 압축해서 기존의 연속된 요청에서의 중복 헤더로 인한 오버헤드 문제를 해결

◦

이전에 표시된 헤더를 제외한 필드를 허프만 코딩을 활용해서 압축

•

Server Push (서버 푸시)

◦

클라이언트가 서버에 요청하지 않아도 클라이언트에게 필요한 리소스를 서버가 추가적으로 push해주는 기능

•

각 요청마다 stream으로 구분해 병렬적으로 처리함에도 불구하고 TCP 고유의 HOL Blocking이 여전히 존재하는 문제

◦

서로 다른 stream이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생

HTTP/3.0

•

TCP 위에서 돌아가는 HTTP/2.0와는 달리 QUIC라는 계층 위에서 돌아가며 TCP기반이 아닌 UDP 기반

•

HTTP/2.0의 장점(멀티플렉싱 등)의 기능을 가지고 있음

•

초기 연결 설정 시 지연 시간 감소라는 대표적 특징 (UTP기반)

◦

초기 연결(통신 시작) 시 3-way handshaking 과정을 거치지 않아 1-RTT만 소요

◦

클라이언트와 서버거 한번 신호를 주고받은 후 바로 통신 시작

•

TCP의 stream은 하나의 chain으로 연결되는 것과 달리 각 stream당 독립된 stream chain을 구성하여 TCP의 HOL Blocking을 해결

10/9

.idea

.idea 폴더는 JetBrains의 IDE(통합 개발 환경)인 IntelliJ IDEA와 관련된 설정 파일들이 저장되는 폴더입니다. 이 폴더는 프로젝트에 대한 구성 정보, 코드 스타일 설정, 실행 설정 등 다양한 메타데이터를 포함하고 있습니다.

주로 Git과 같은 버전 관리 시스템에 포함되기도 하며, 팀원 간의 일관된 개발 환경을 유지하는 데 도움이 됩니다. 하지만 개인적인 설정이 포함될 수 있으므로, 팀 프로젝트에서는 .gitignore 파일에 추가하여 제외하는 경우도 많습니다.

.env.base 파일은 .env변수들의 기본 형식을 제공함 .env.base파일을 보고 .env파일을 구성하면 된다.

config-overrides.js

config-overrides.js 파일은 주로 Create React App(CRA)에서 사용되는 설정 파일로, Webpack 설정을 변경하거나 추가할 수 있게 해줍니다. CRA는 기본적으로 Webpack 설정을 숨기기 때문에, react-app-rewired와 같은 도구를 사용하여 이 파일을 통해 설정을 오버라이드할 수 있습니다.

주요 기능

•

Webpack 설정 변경: 기본 Webpack 설정을 수정하거나 추가할 수 있습니다.

•

플러그인 추가: 필요한 Webpack 플러그인이나 로더를 추가할 수 있습니다.

•

환경 설정: 개발 및 프로덕션 환경에 따라 다른 설정을 적용할 수 있습니다.

10/11

수학에서 s.t.는 subject to 즉 '~에 대하여'라는 뜻이다. 수학에서 s.t.는 such that 즉, 뒤에 있는 것을 만족하는'이라는 뜻이다.

10/12

옵션 제외

rm -r -- -Myfile

여기서 -r은 재귀적으로 폴더와 그 안의 내용을 삭제하는 옵션이고, --는 이후에 오는 항목이 옵션이 아님을 나타냅니다.

//package.json proxy설정
{
  "name": "frontend",
  "version": "0.1.0",
  "proxy": "http://localhost:5001",
  "private": true,
  "dependencies": {
},
JSON
복사

테스트넷

테스트넷(Testnet)은 블록체인 개발 및 테스트를 위한 별도의 네트워크입니다. Ethereum 블록체인에도 여러 가지 테스트넷이 존재합니다. 테스트넷은 실제 Ether(ETH)와는 다른 가상 화폐를 사용하여 개발자들이 안전하게 스마트 계약 및 DApp을 테스트할 수 있도록 해줍니다.

테스트넷의 특징

가상 화폐: 테스트넷에서는 실제 가치가 없는 가상 화폐를 사용합니다. 이를 통해 개발자는 비용 걱정 없이 여러 번의 테스트를 수행할 수 있습니다.환경 분리: 실제 메인넷과는 별도의 환경이기 때문에, 오류나 버그가 발생해도 실제 자산에 영향을 미치지 않습니다.다양한 테스트넷: Ethereum에는 여러 종류의 테스트넷이 있습니다:Ropsten: 이더리움 메인넷과 유사한 구조로, 실제 Ether를 사용하는 것과 비슷하게 테스트할 수 있습니다.Rinkeby: 권한 기반의 테스트넷으로, 빠른 트랜잭션 속도를 제공합니다.

•

가상 화폐: 테스트넷에서는 실제 가치가 없는 가상 화폐를 사용합니다. 이를 통해 개발자는 비용 걱정 없이 여러 번의 테스트를 수행할 수 있습니다.

•

환경 분리: 실제 메인넷과는 별도의 환경이기 때문에, 오류나 버그가 발생해도 실제 자산에 영향을 미치지 않습니다.

•

다양한 테스트넷: Ethereum에는 여러 종류의 테스트넷이 있습니다:

◦

Ropsten: 이더리움 메인넷과 유사한 구조로, 실제 Ether를 사용하는 것과 비슷하게 테스트할 수 있습니다.

◦

Rinkeby: 권한 기반의 테스트넷으로, 빠른 트랜잭션 속도를 제공합니다.

10/13

터미널 줄바꿈

터미널에서 npm install hardhat \에서 사용된 \는 명령어를 여러 줄로 나누어 입력할 때 사용되는 줄 바꿈 기호입니다. 즉, \를 입력하면 다음 줄로 이어서 명령어를 계속 입력할 수 있음을 나타냅니다.

예를 들어, 긴 명령어를 여러 줄로 나누어 작성할 수 있습니다:

npm install hardhat \
    --save-dev
Solidity
복사

10/14

React에서 Outlet을 포함하는 layout은 layout폴더를 따로 두고 관리하는게 편하다

10/17

전방 선언: struct NodeType;는 NodeType이라는 이름의 구조체가 존재할 것이라는 것을 알리는 선언입니다. 이 구조체의 실제 구현은 후에 작성됩니다.

10/21

IaaS, PaaS, SaaS

클라우드 컴퓨팅의 세가지 모델은 IaaS, PaaS, SaaS가 있다.

IaaS는 infrastructure as a service로 제공업체가 storage, disk,cpu자원을 가상화해서 제공하고 사용량에 따라서 요금을 지불하는 서비스이다. 제공업체가 사용자를 대신해 데이터센터를 유지관리하고 사용자는 필요에 따라 유연하게 사용량을 늘리거나 줄일 수 있다.

PaaS는 platform as a service로 사용자에게 런타임, 개발도구, 데이터베이스 등의 미들웨어를 제공해서 애플리케이션을 쉽게 개발하고 배포할 수 있는 플랫폼을 제공한다.

SaaS software as as service로 모든 애플리케이션을 제공업체가 관리하며 웹 브라우저를 통해서 서비스 자체를 제공하는 형태이다.

OpenStack

openstack은 협의의 클라우드 컴퓨팅 서비스로 kvm이라는 hypervisor를 제공한다.

host os위에 hypervisor를 올리고 hypervisor는 여러대의 VM을 실행시킨다.

hypervisor는 vm에 코어를 하나이상 할당하며 하드웨어 자원을 분배하고 각 vm은 할당받은 리소스를 기반으로 guest os를 실행한다.

cpu, disk, network가 더 필요할 경우 cloud의 hostOS위에서 hypervisor를 통해 vm의 숫자를 늘리거나 줄이며 scaling하는 방식을 사용한다.

IaC

Infrastructure as Code, IaC는 서버, 데이터베이스, 네트워크 등 자원을 코드로 정의하고 관리하여 배포 및 구성 과정을 빠르고 일관되게 만들 수 있습니다. 이를 통해 구성의 일관성을 유지하고, 불변(immutable) 인프라를 구현하며, 하드웨어 플랫폼에 독립적으로 운영할 수 있는 장점이 있기 때문에 DevOps 환경에서 널리 사용되고 있다.

Linux over Linux Problem

예를 들어 openstack을 통해서 협의의 클라우드 컴퓨팅 방식을 사용할 경우 가상머신을 늘리고 가상머신에 자원을 할당하여 vm위에 guest os를 올리고 그 위에 앱을 올려야한다.

하지만 어플리케이션을 필요할때 늘려서 실행하는 것이 목적이지 컴퓨터를 빌리는 것 자체가 목적이 아니다. 서버의 호스트 os도 리눅스이고 그 위 올라가는 vm의 guest os도 리눅스로 올리는 linux over linux문제가 발생하면 비효율적으로 자원을 많이 차지하며 애플은 이로인해 운영 비용이 30퍼센트 더 발생하는 경우가 있었다. 이를 virtualization tax라고 부른다.

virtualization tax로 인한 linux over linux problem은 퍼블릭 클라우드에서는 문제가 되지 않는데, 예를들어 퍼블릭 클라우드 제공자인 아마존은 사용량에 따라서 비용을 받기 때문에 빌려준 인프라에서 운영되는 앱의 효율성에 관심이 없다. 효율이 나빠져서 자원을 더 많이 사용하더라도 비용을 더 받으면 되기 때문이다.

예를 들어 애플의 클라우드는 애플 디바이스 뒤에서 imessage등을 주고받거나 사진을 저장하는 용도로 사용되는데, 이 비용은 아이폰과 같은 자사 제품에 포함되어있고 따라서 자사의 프라이빗 클라우드에서는 비용을 줄이는게 중요하다. linux over linxu문제로 cloud운영 비용이 증가하는 경우 virtualization tax가 늘어나기 때문에 문제가 된다.

CI, CD, DevOps

개발 및 배포 프로세스는 코드를 작성하고, 컴파일 빌드를 수행하고, 소스코드를 레포지토리에 올리고, 서버를 올리고, 실행파일을 생성하고, 테스팅을 수행하고, 프로덕션에 배포하는 과정을 거친다.

integration은 새로운 코드와 자원을 기존의 것과 통합하는 과정으로 개발자가 코드를 변경했을 때 코드를 빌드하고 테스트해서 기존 코드에 통합하는 프로세스이고, 이후 프로그램을 프로덕션 환경에 배포하는 deploy과정을 거쳐서 서비스가 제공된다.

CI/CD는 continuous integration, continous deployment의 약자로 코드를 변경하면 소스코드를 pull하고 컴파일 및 빌드를 수행하고 테스트모듈을 돌리고 프로덕션에 배포하는 과정을 자동화하는것이다.

자동화를 통해 개발과 운영 프로세스를 통합해서 서비스 운영에 인간의 개입을 최소화하고 빠르고 효율적이고 에러없이 자연스롭게 연결되도록 하는것이 DevOps이다.

Docker cli, docker desktop gui, docker server

도커 엔진 안에는 도커 클라이언트와 도커 서버가 있다.

도커 클라이언트에는 command line을 통한 인터페이스를 제공하는 도커 cli가 있고, GUI로 편리하게 cli의 역할을 하도록 구축해놓은 도커 데스크탑이 있다.

도커 서버는 백그라운드에서 돌아가며 허브에서 이미지를 다운받고 실행하는 등의 작업을 수행하며 도커 데몬이라고도 한다. 도커 클라이언트와 도커 서버는 rest api기반으로 정보를 주고받으며 내 클라이언트로 다른 컴퓨터의 데몬을 원격으로 통제하는것도 가능하다.

Dockerfile에 포함되는 주요 명령

FROM은 FROM:ubunut:20.24처럼 빌드할 이미지의 베이스 이미지와 버전을 지정한다. latest로 하면 가장 최근의 버전을 사용한다.

maintainer는 이미지의 유지보수자의 정보를 정의한다. 필수가 아니며 이제는 잘 사용되지 않는다.

COPY는 host의 파일 시스템에서 컨테이너의 파일 시스템으로 디렉토리를 복사하는 작업을 수행한다.

COPY ./app /app처럼 copy src dest형태이며 관례적으로 dest는 /app으로 많이 설정한다.

WORKDIR는 작업할 디렉토리를 지정하며 해당 디렉토리에서 명령어들이 수행된다.

EXPOSE는 컨테이너의 공개 포트번호를 지정한다. 이 명령 자체가 포트를 실행해서 리스닝시키는 것이 아니기 때문에 컨테이너를 시작할때 -p옵션을 줘야한다.

CMD는 컨테이너 실행시 default로 실행되는 명령이나 파라미터를 설정한다. ENTRYPOINT와 함께 사용되며 CMD는 ENTRYPOINT에 전달할 인자를 설정한다. ENTRYPOINT가 설정되지 않았으면 cmd가 단독으로 실행된다.

ENTRYPOINT는 컨테이너가 시작될 때 실행할 기본 명령을 설정하고 컨테이너의 기본 동작을 정의한다

Container의 Life Cycle

도커 컨테이너의 lifecycle은 리눅스의 프로세스 상태와 유사하다.

docker run을 통해 이미지로부터 컨테이너가 생성된 이후 실행되어 running상태가 된다.

pause는 운영체제 위에서 실행되는 상태에서 멈추며 메모리 상태는 유지되고 cpu자원을 점유하지 않는다.

실행 중에 pause한 이후 그대로 이미지로 만드는것도 가능하다.

stop은 신SIGTERM호를 보내서 컨테이너를 정상적으로 종료하는 것으로 데이터 손실 없이 종료된다.

[16] Docker Compose는 무엇이고, 어떤 용도로 사용하는지 설명합니다.

Docker Compose: 두 개 이상의 컨테이너를 쉽게 관리하고 띄우기 위한 도구이다. 처음에는 도커와 분리된 프로그램이었으나, 현재는 도커 데스크탑에 포함되어 있습니다.

docker-compose.yml 파일: 이 파일을 통해 각 컨테이너의 설정, 네트워크, 볼륨 등을 구성할 수 있습니다. YAML 형식으로 작성되어 각 서비스의 설정을 정의합니다.

컨테이너 실행: 예를 들어, 웹 서버와 데이터베이스를 함께 실행해야 할 경우, docker-compose up 명령어를 통해 두 컨테이너를 동시에 띄우고, 가상의 네트워크를 통해 서로 연결된다. 쿠버네티스에서는 이 가상의 네트워크를 pod이라고 부른다.

컨테이너 종료: docker-compose down 명령어를 실행하면, 생성된 네트워크를 지우고 모든 컨테이너를 종료합니다.

Docker bind mount와 volume

Bind Mount는 host 운영체제의 특정 디렉토리를 컨테이너에 매핑하여 이미 존재하는 데이터를 컨테이너가 사용하고 기록할 수 있도록 하는 방법이다.

어떤 디렉토리를 사용할지 매핑하는 것을 bind라고 하며, 디스크를 운영체제가 인식하고 사용할 수 있게 하는 과정을 mount라고 부른다. 이를 통해 호스트의 데이터를 컨테이너와 공유할 수 있고 원격 스토리지와 연결할 수 있다.

컨테이너가 종료되어도 호스트의 데이터는 사라지지 않으며, 컨테이너는 Bind Mount로 연결된 스토리지를 자신의 디스크처럼 인식합니다.

Volume은 Docker가 관리하는 스토리지의 일종으로, 컨테이너가 종료되어도 데이터가 남아 있습니다.

Volume은 Docker 엔진이 관리하는 docker area에 저장됩니다. 이 공간은 호스트 머신의 디스크 내부에 위치하며, 개발자나 운영자가 직접 접근하는 것은 권장되지 않습니다.

여러 컨테이너가 동시에 접근할 수 있습니다.

데이터의 전후 관계가 있는 경우, 한 컨테이너가 Volume에 데이터를 기록하고 다른 컨테이너가 그 데이터를 기반으로 작업하도록 파이프라인을 구성할 수 있습니다.

Volume에 데이터를 기록하는 방법은 Docker CLI와 데몬 간의 HTTP 통신을 통해 이루어지므로, 원격으로도 데이터를 기록할 수 있다.

WSL

windows subsystem for linux 리눅스 돌리는거 윈도우에서

윈도우는 리눅스 실행해주는 인터페이스 역할만 함 수천수만의 cpu를 동시다발적으로 쓴다

멀티프로세스 멀티스레드 코루틴

플랫폼 엔지니어링 = 데브옵스 서버 잘 돌아가게 하는 환경 운용

컴퓨터 네트워크

ip address

socket위에 http프로그램이 존재

ip주소는 컴퓨터의 주소 port번호가 필요 사실 ip는 줄에 주는거임 포트 = 운영체제의 구멍

IMAP 이메일 클라이언트가 이메일 서버로부터 이메일 가져오고 보내는 프로그램

프로그램의 정식명칭

HTTP는 애플리케이션 계층의 프로토콜이며, 실제 데이터 전송은 소켓을 통해 이루어집니다. 소켓이 네트워크 통신의 기본적인 단위이기 때문에, HTTP와 같은 프로토콜은 소켓을 기반으로 작동합니다.

IP를 사용하는것이 4계층이고 거기에 tcp/udp가 해당한다

도메인 이름 검색하면 dnsresolver를 통해서 ip adress를 받아옴

네이버는 인증 서버 날씨 서버 증시 서버 쇼핑 서버 뉴스 서버 등등..

개당 한개씩 팀이 있고 agile으로 운영한다

필요할때 필요한만큼의 cpu를 활용 서버들은 잘게 쪼개짐 굳이 하나로 만들 이유가 없음 cpu가 많으니까

주고받아야하면 통신을 하면 됨 굳이 하나로 만들 이유가 없다 잘게 쪼개진 애들끼리 request response를 받음

로그인 서버의 cpu가 부족하면 늘리고 줄인다. 모든 cpu의 부하가 한계치일때 프로그램이 자동으로 cpu를 더 돌리는게 orchestrator 운영팀은 상관이 없음 뭘 주든 통신으로 하는 프로그램이니 각자 컴파일하고 실행. 언어를 통일할 필요가 없다 어떤 팀은 파이썬을 쓰고 어떤 팀은 다른걸 쓰고.. polyglot이라고 부름

ip주소를 누가 줘야함 dhcp서버 dynamic host configuration protocl 아이피를 자동으로 설정하는 프로토콜

와이파이 유무선 공유기가 할당하는것 쿠버네티스에는 dhcp기능이 있다

ec2같은것을 애플은 제공하지 않음 애플은 퍼블릭 사업자가 아님

애플의 클라우드는 애플 디바이스 뒤에 숨어서 iMessage주고받거나 사진 주고받거나 등에서 사용되는데

이 물건값에 포함이 되는 서비스이다 이게 프라이빗 클라우드임 아마존은 앱에 관심이 없다 돈 더받는데 뭐

매킨토시는 유닉스가 AT&T에 의해서 만들어지고 유닉스 운영체제가 쓰이고 있는 컴퓨터는 매킨토시밖에 없음

소프트웨어 전공하는사람은 맥을 권한다

openStack → kubernetes 2015년

애플이라고 해도 유닉스이긴 하나 macOS로 서버 올리는건 단종됨

애플의 서버제품이 하드웨어가 불안함 애플조차도 서버는 리눅스임

물리적인 서버를 구동하기 위해서 hostOS를 리눅스 쓴다 구글이

서비스를 지원하는 guestOS도 리눅스를 쓴다

왜 openstack같은 협의의 클라우드 컴퓨팅하면 비용을 2배 내게되는지의 이유

host가 있어야 클라우드로 묶는거니까.. 그위에 뭐가 올라가는지 퍼블릭 제공자는 신경안씀 리눅스 위에 리눅스 올라가는게 제정신 아니다

p-core= 성능코어 e-core = 효율코어

영화, 애니메이션 제작하려면 스튜디오가 필요함 거기에 쓰이는게 맥 스튜디오

어떤 프로그램을 p코어에 올리고 어떤 프로그램을 e코어에 올리나

neural engine 머신러닝을 위한 엔진

내 앱이 용량이 엄청 늘어나다가 엄청 줄어드나? 그럼 컨테이너를 쓰는게 맞다 컨테이너 기반으로 간다 = 프로그램을 부숴야함 단점 스태프 재교육 re architecturing

웹 어셈블리 2015년에 웹어셈블리가 있으면 도커를 안만들었을것이다.

쿠버네티스에 웹어셈블리 연결한다 wasm은 컨테이너없는 docker

rust는 mozila foundation이 있어서 쉽게 죽지 않음

rust는 class가 없음

윈도우는 개발 플랫폼에서 밀려나고 있다

쿠버네티스는 원래 도커와 하나였음 점점 분리됨 도커 대체재도 있다 podman 등 오픈소스 무료

docker desktop은 돈 내야함 수익창출을 하면

오픈스택 2010 프라이빗 클라우드

갑자기 파이썬이 개발자 1언어되고

파이썬 컨퍼런스가서 도커 데모를 했다

go는 c보다 쉬우면서 안정적인 서버프로그래밍언어

멀티스레드도 쉽고 standard로 http2를 지원하는 유일한언어 근데 이게 4,5년전

go는 서버를 짜기 위한 언어라서 서버짜기는 정말 편하다

병렬처리 멀티스레드 편하게 되어있다

hello 세계라고 적어놓은 이유는 기본 베이스가 유니코드라는 뜻

중국이 관심도 1등 미국이 무역전쟁을 중국에게 걸어서 서버기술 고도화 os도 자국화, 모바일os도

webassembly설명도 똑같다 컨테이너는 무겁다 flexible하지 않다 등..

우분투는 오리지널 리눅스 커널 위에 쌓아올린 것이다.

우분투가 지원하는 file structure, 하드디스크 ssd어떻게 쓰는지 루트나 폴더들 네이밍 등

우분투가 통째로 올라가는게 아니라 명령을 받아주기 위해서 미니멈이 들어가는것

파이썬 poetry = venv등을 편하게 해준다 버전관리해주고 등 npm, yarn같은거임

알파인은 작지만 보안상의 문제가 있어서 안쓰는게 좋다는 레포트도 있다

python같은 언어 다운로드하면 밑에 우분투가 깔려있다

컨테이너란 밑에있는 인프라 cpu상관없이 동작한다고 햇으나 추가작업이 필요하다 macOS에서 빌드하면 macos에서만 돌아가는 컨테이너다 멀티 cpu운영체제 위에서 돌리고 싶으면 추가작업하면 완전히 독립적으로 만들 수 있다.

최신버전으로 지정은 안좋은것 immutable하게 유지해야하기 때문에

마이크로서비스프로그램이란 특정 request에 대한 프로그램 1000줄정도 짜는거

Docker

the -t flag tags your image. Think of this as a human-readable name for the final image.

d flag (short for --detach) runs the container in the background.

docker ps command in a terminal to list your containers.

docker run -dp 127.0.0.1:3000:3000 getting-started

The docker build command uses the Dockerfile to build a new image.

Docker 이미지 리스트에서 <none>으로 표시되는 이미지는 "dangling image"라고 합니다. 이는 태그가 없는 이미지로, 주로 이미지가 업데이트되거나 빌드될 때 이전 이미지가 남아 있을 때 발생합니다.

docker build -t getting-started를 수행하면 기존의 getting-started 이미지가 새로운 이미지로 대체됩니다. 이 과정에서 이전 이미지가 태그가 없어져 <none>으로 표시됩니다.

Dockerfile에서 EXPOSE 명령어를 사용하여 컨테이너가 사용할 여러 포트를 선언할 수 있습니다.

EXPOSE 8000 5000

이렇게 하면 해당 포트들이 컨테이너에서 사용 가능하다는 것을 나타내지만, 실제로 외부와 연결하기 위해서는 docker run 명령어에서 포트를 매핑해줘야 합니다. EXPOSE는 문서화의 역할을 하며, 포트를 자동으로 개방하지는 않습니다.

컨테이너는 여러 개의 포트를 사용할 수 있습니다. 각 포트는 컨테이너 내에서 실행되는 다양한 서비스나 애플리케이션에 할당될 수 있습니다.

Docker를 사용하여 여러 포트를 노출하려면 docker run 명령에서 -p 플래그를 여러 번 사용하면 됩니다.

docker run -dp 127.0.0.1:3000:8000 명령어에서 8000은 컨테이너 내부의 포트 번호입니다. 즉, 컨테이너 내에서 실행되는 서버는 8000번 포트에서 리슨해야 합니다.

이 설정은 호스트의 3000번 포트를 컨테이너의 8000번 포트에 매핑하는 것입니다. 따라서 컨테이너에서 실행하는 서버가 8000번 포트에서 실행되고 있어야만 호스트의 3000번 포트로 접근할 수 있습니다.

이전 컨테이너가 실행 중일 때 새 컨테이너를 시작할 수 없기 때문에 발생했습니다. 이유는 이전 컨테이너가 이미 호스트의 포트 3000을 사용하고 있고 머신의 프로세스 하나만(컨테이너 포함) 특정 포트를 수신할 수 있기 때문입니다. 이를 수정하려면 이전 컨테이너를 제거해야 합니다.

dockerfile의 maintainer는 이제 사용하지 않는다

expose 9000 통신포트 9000연다

외부의 8090포트를 9000포트와 연결 -p 8090:9000

보여지는것과 저장된 데이터가 독립적으로 동작할수있게

워드프레스는 홈페이지 만들때 본인이 선택하는 모양에 따라 보여주고 데이터는 별도 저장된다 컨텐츠는 유지가 되고 보여지는 형태에 대한 제어는 독립적으로 하는 cms

지금은 wordpress가 nginx를 내장하고 있다

pyYAML과 같이 파이썬 이용해서 yaml파일을 생성할수도 있다

시험 docker compose로 yaml파일안에 두개이상 컨테이너 나열하는 문제

C++에서 main 함수의 인자 argc와 argv는 프로그램이 실행될 때 커맨드 라인에서 전달된 인수를 처리하는 데 사용됨

argc (Argument Count):

•

argc는 "argument count"의 약자로, 프로그램에 전달된 인수의 개수를 나타냄

•

이 값은 항상 1 이상의 정수입니다. argc가 1인 경우는 프로그램 이름만 전달된 경우이다.

argv (Argument Vector):

•

argv는 "argument vector"의 약자로, 각 인수를 문자열로 담고 있는 배열.

•

argv[0]는 항상 실행된 프로그램의 이름을 포함. 이후의 인수들은 argv[1], argv[2]와 같이 인덱스를 통해 접근.

•

argv는 char* 타입의 포인터 배열로, 각 요소는 C 스타일의 문자열

두개의 도커파일 만들어서 돌리면 별도의 공간으로 생긴거다

docker compose 위에서 두개 컨테이너 띄우지 도커파일 여러개 만들지마라!!

빅데이터때문에 nosql, 분산데이터베이스로 간거다 분산파일시스템 하둡 카산드라 등 동시다발적으로 메세지 보내려고 message queue 카프카 메모리가 요새 너무 커지니까 다시 duckDB같이 돌아오는거옛날에는 하드디스크가 너무 느려서 메모리에 DB를 올렸던거

맥, 윈도우 개행문자

맥과 윈도우 텍스트가 다르다

프로그램 argument로 os에 맞는 파일이름 입력받기

개행문자를 cr을 윈도우는 cr lf이니까 바꿔주기

main함수가 파라미터를 가지면 comand line argument

개행할때 한바이트가 두바이트로 늘어나서 txt파일 윈도우에서 더 커짐

char **argv == char *argv[]

string이 여러개 넘어오는것은 아는데 몇개가 넘어오는지는 모른다

몇개가 넘어오는지 알려주는게 argc다

인수 1번은 arg[0] 그다음 argv[1] argv[2]

내가 실행하는 프로그램 이름은 argv[0]

argv[0] 출력하면 자기실행파일이름

character array라서 숫자넣어도 string이다

그래서 string을 정수로 바꿔줘야한다

atoi로 바꿈 ascii to integer

컴파일러는 파일 각각 컴파일하고 obj파일 생성하고 링커가 exe로 만들어준다

C로 짰는데 윈도우에서는 돌고 맥에서는 안돌고 이럼 안되는데 근데 dependency가 존재할수밖에 없다 운영체제에 접근할때 다른부분을 어떻게 관리하나 파일이름을 나눠서 win mac관리해야하나 여러개로 나눠져있으면 관리하기가 어렵다 그래서 전처리 명령어 사용하는것이다.

캐시

캐시의 구조

•

L1 캐시: CPU 코어 내부에 가장 가까운 캐시로, 가장 빠르지만 용량이 작습니다. 일반적으로 데이터와 명령어 각각에 대해 별도의 L1 캐시가 존재합니다.

•

L2 캐시: L1 캐시보다 크고 약간 느리며, CPU 코어와 가까운 위치에 있습니다. L1 캐시가 미스(miss)할 경우 L2 캐시에서 데이터를 찾습니다.

•

L3 캐시: 여러 CPU 코어가 공유하는 캐시로, L1 및 L2 캐시보다 더 큰 용량을 가지고 있지만, 상대적으로 느립니다. L3 캐시는 CPU 코어 간의 데이터 공유를 돕습니다.

캐시의 역할

캐시는 CPU가 메모리에서 데이터를 읽고 쓰는 시간을 줄여줍니다. 자주 사용되는 데이터나 명령어를 미리 캐시에 저장함으로써, 메모리 접근 속도에 따른 병목 현상을 최소화합니다.

Public, Protected, Private

•

Public 상속: 부모의 public과 protected 멤버는 그대로 유지됨.

•

Protected 상속: 부모의 public과 protected 멤버는 protected로 변경됨.

•

Private 상속: 부모의 public과 protected 멤버는 private로 변경됨.

멀티프로세싱/스레딩

멀티프로세싱 (Multiprocessing)

정의: 여러 개의 프로세서(또는 코어)를 사용하여 동시에 여러 프로세스를 실행하는 방식입니다.특징:각 프로세스는 독립적인 메모리 공간을 가집니다.프로세스 간의 통신은 상대적으로 느리며, 보통 IPC(Inter-Process Communication) 메커니즘을 사용합니다.시스템 자원을 더 많이 소모할 수 있지만, 안정성이 높고 한 프로세스가 실패해도 다른 프로세스에 영향을 주지 않습니다.예시 작업:웹 서버가 여러 클라이언트 요청을 동시에 처리하는 경우.데이터베이스 서버가 여러 쿼리를 동시에 실행하는 경우.대규모 계산 작업을 여러 프로세스에 분산시키는 경우.

•

정의: 여러 개의 프로세서(또는 코어)를 사용하여 동시에 여러 프로세스를 실행하는 방식입니다.

•

특징:

◦

각 프로세스는 독립적인 메모리 공간을 가집니다.

◦

프로세스 간의 통신은 상대적으로 느리며, 보통 IPC(Inter-Process Communication) 메커니즘을 사용합니다.

◦

시스템 자원을 더 많이 소모할 수 있지만, 안정성이 높고 한 프로세스가 실패해도 다른 프로세스에 영향을 주지 않습니다.

•

예시 작업:

◦

웹 서버가 여러 클라이언트 요청을 동시에 처리하는 경우.

◦

데이터베이스 서버가 여러 쿼리를 동시에 실행하는 경우.

◦

대규모 계산 작업을 여러 프로세스에 분산시키는 경우.

멀티스레딩 (Multithreading)

정의: 하나의 프로세스 내에서 여러 스레드를 사용하여 동시에 작업을 수행하는 방식입니다.특징:모든 스레드는 같은 메모리 공간을 공유하므로, 데이터 공유가 쉽고 빠릅니다.스레드 간의 통신이 빠르지만, 하나의 스레드에서 오류가 발생하면 전체 프로세스에 영향을 줄 수 있습니다.더 낮은 시스템 자원을 소모하고, 스레드를 생성하고 관리하는 비용이 적습니다.예시 작업:GUI 애플리케이션에서 사용자 인터페이스가 반응성을 유지하면서 백그라운드에서 데이터 처리를 하는 경우.게임에서 물리 엔진, AI, 렌더링 작업을 각각의 스레드에서 처리하는 경우.웹 크롤러가 여러 페이지를 동시에 요청하고 처리하는 경우.

•

정의: 하나의 프로세스 내에서 여러 스레드를 사용하여 동시에 작업을 수행하는 방식입니다.

•

특징:

◦

모든 스레드는 같은 메모리 공간을 공유하므로, 데이터 공유가 쉽고 빠릅니다.

◦

스레드 간의 통신이 빠르지만, 하나의 스레드에서 오류가 발생하면 전체 프로세스에 영향을 줄 수 있습니다.

◦

더 낮은 시스템 자원을 소모하고, 스레드를 생성하고 관리하는 비용이 적습니다.

•

예시 작업:

◦

GUI 애플리케이션에서 사용자 인터페이스가 반응성을 유지하면서 백그라운드에서 데이터 처리를 하는 경우.

◦

게임에서 물리 엔진, AI, 렌더링 작업을 각각의 스레드에서 처리하는 경우.

◦

웹 크롤러가 여러 페이지를 동시에 요청하고 처리하는 경우.

쿼드코어 CPU는 네 개의 프로세서 코어가 하나의 칩에 통합된 것입니다. 각 코어는 독립적으로 작업을 수행할 수 있어 멀티태스킹과 병렬 처리가 가능해집니다. 이를 통해 CPU는 더 많은 작업을 동시에 처리할 수 있어 성능이 향상됩니다.

메모리 인식률

메모리 한 칸은 1byte의 크기를 갖고 이를 가지키는 주소값은 32bit 운영체제에선 32개의 비트로 표현됩니다. 즉 메모리 한 칸은 4바이트 길이의 주소를 갖습니다. 4바이트는 232가지 경우의 수를 가지기 때문에 4,294,967,296 개의 주소를 가르킬 수 있습니다. 이는 1바이트 메모리를 4,294,967,296 개까지 인식할 수 있다는 것이고 이를 계산하면 메모리의 최대 크기는 4,294,967,296 * 1byte = 4GB (메모리 인식률이라고도 합니다.)

모뎀

라우터는 모뎀과 유선으로 연결되어있고 모뎀은 벽뒤에 설치되어있음

모뎀은 광케이블을 통해서 SKT,LG U+와 같은 ISP의 데이터센터와 연결되어있고 거기서 데이터를 받아온다 ISP의 데이터센터는 해외의 다른 데이터센터와 해저케이블을 통해서 연결되어있다