클라이밍하는 개발자

1. URL 파싱 및 HTTP 요청 생성: 브라우저가 URL을 해석하여 HTTP 요청 메시지를 생성하고, 이를 운영체제에 전송 요청합니다.
2. DNS 룩업: 도메인 이름을 IP 주소로 변환하기 위해 DNS 룩업을 수행합니다. 크롬 같은 브라우저는 먼저 로컬의 hosts 파일과 DNS 캐시를 확인합니다.
3. 프로토콜 스택을 통한 패킷 처리: 운영체제 내의 프로토콜 스택이 HTTP 요청을 네트워크 패킷으로 변환하고 제어 정보를 추가합니다.
4. LAN 어댑터를 통한 전송: LAN 어댑터가 패킷을 전기 신호로 변환하여 네트워크로 송출합니다.
5. 인터넷 접속 경로를 통한 이동: 패킷은 스위칭 허브를 거쳐 ISP를 통해 인터넷으로 전송됩니다.
6. 인터넷의 핵심부를 통한 전달: 패킷은 여러 고속 라우터를 거쳐 인터넷의 핵심부를 통과하여 목적지로 이동합니다.
7. 목적지 LAN 도착 및 검사: 패킷은 목적지의 LAN에 도착하며, 방화벽에서 검사 후 필요한 경우 캐시 서버로 이동합니다.
8. 웹 서버에서의 처리: 웹 서버는 프로토콜 스택을 통해 패킷을 추출, 메시지를 복원하고, 웹 서버 애플리케이션으로 전달합니다.
9. 응답 데이터 작성 및 회송: 웹 서버 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 다시 보냅니다. 이 응답도 동일한 경로를 통해 전송됩니다.

정의

트랜잭션(Transaction)은 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미합니다.

// 트랜잭션 시작
BEGIN TRAN

//변경할 쿼리문
UPDATE tbl_admin
SET nickname = "babo"
WHERE no= 1;

//결과 확인해 본 후
select * from tbl_admin

//성공 처리
COMMIT TRAN
//실패 처리
ROLLBACK TRAN

이론공부만 하던 시절에는 와닿지 않았던 개념이었는데, 현업에서 사용하게 되어서 CS의 주제로 선정하게 되었다.

위의 쿼리문 처럼 변경을 시작하기 전에 " BEGIN TRAN "을 실행하고, 변경하는 쿼리문을 실행한다.

잘 변경되었나 확인해보고, 잘 못 변경되었다면 ROLLBACK, 잘 되었다면 COMMIT을 실행시킨다.

주요 목적

트랜잭션의 주요 목적은 데이터의 무결성과 일관성을 보장하는 것입니다. 여러 작업을 단일 트랜잭션으로 그룹화하여 트랜잭션 내의 모든 작업이 성공적으로 실행되거나 아무 것도 실행되지 않도록 할 수 있습니다.

트랜잭션은 신뢰할 수 있고 일관된 데이터 처리를 보장하는 ACID속성을 따릅니다. 트랜잭션은 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)의 4가지 특징을 가집니다.

1. 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것을 의미
2. 일관성은 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것을 의미
3. 독립성은 둘 이상 트랜잭션이 동시 실행시, 어떤 트랜잭션이라도 다른 트랜잭션 연산에 끼어들 수 없다는 점을 의미
4. 지속성은 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점

[ "트랜잭션에서 ACID 속성을 따른다"는 것은 원자성, 일관성, 독립성, 지속성을 최대한 지키려고 노력한다는 것을 의미"]

트랜잭션의 격리 수준 4단

• 트랜잭션 격리수준(isolation level)이란 동시에 DB에 접근할 때, 그 접근을 어떻게 제외할지에 대한 설정
• 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것. 즉, 특정 트랙잭션이 다른 트랜잭션이 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것.

격리 수준 종류

1. READ UNCOMMITED
2. READ COMMITED
3. REPEATABLE READ
4. SERIALIZABLE

- 격리 수준 증가할 수록 일관성은 증가하지만 동시성은 감소

- 일반적인 DB 서비스는 READ COMMITED 또는 REPEATABLE READ 중 하나를 선택.

   (oracle = READ COMMITED, mysql = REPEATABLE READ)

1. READ-UNCOMMITED

- 변경사항을 커밋하기 전에 다른 트랜잭션에서 조회할 수 있는 수준 (일반적으로 사용되지 않음)

- Dirty Read, Repeatable Read, Phantom Read 문제도 발생할 수 있음.

2. READ-COMMITED

- 어떤 트랜잭션의 변경내용이 커밋이 완료된 데이터만 다른 트랜잭션에서 조회 가능. 트랜잭션이 이루어지는동안 다른 사용자는 해당 데이터에 접근이 불가능.

- 커밋전에 조회가 됨으로 VALUE(값)의 오류가 발생할 수 있음

- 이 격리수준은 Oracle DBMS 에서 기본으로 사용하고 있으며, 대중적으로 가장 많이 선택되는 격리수준

- 결제 기능과 같은 금전적인 처리와 연결된 기능이라면 문제가 발생할 수 있음

-  ‘Dirty Read’ 문제는 해결, 'Non-Repeatable Read’와 ‘Phantom Read’ 문제는 발생할 수 있음.

3. REPETABLE READ

- 트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있는 격리수준. 트랜잭션이 완료될 때 까지 SELECT 쿼리가 사용되는 모든 데이터에 Shared Lock(공유 락)이 걸리는 계층. (VALUE의 오류가 발생할 수 없음)

- 원래 존재하지 않았던 컬럼이 조회될 수 있음 (Phantom Read)

- 대신 나머지 현상 사라짐

4. SERIALIZABLE

- 한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 절대 접근할 수 없음.

- 트랜잭션의 ACID 성질이 엄격하게 지켜지지만, 성능은 가장 떨어짐.

- 트랜잭션이 완료될때까지 SELECT 쿼리가 사용되는 모든 데이터에 Shared Lock(공유 락) 이 걸리는 계층

- 가장 엄격한 격리수준으로, 완벽한 읽기 일관성 모드를 제공한다.

- 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능

격리수준에서 발생하는 문제

• Dirty Read: 이는 한 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션의 변경 사항을 읽는 현상을 말합니다. 예를 들어, 한 트랜잭션이 데이터를 수정했지만 아직 커밋하지 않았는데, 다른 트랜잭션이 그 변경 사항을 읽는 경우를 말합니다. 이로 인해 데이터의 일관성이 깨질 수 있습니다.
• Non-Repeatable Read: 이는 한 트랜잭션이 동일한 데이터를 두 번 읽었을 때, 그 사이에 다른 트랜잭션이 해당 데이터를 수정하고 커밋하여 두 번째 읽기에서 다른 결과를 얻는 현상을 말합니다. 이로 인해 한 트랜잭션 내에서 데이터의 일관성이 깨질 수 있습니다.
• Phantom Read: 이는 한 트랜잭션이 동일한 쿼리를 두 번 실행했을 때, 그 사이에 다른 트랜잭션이 새로운 행을 삽입하거나 삭제하여 두 번째 쿼리의 결과 집합이 첫 번째와 다른 경우를 말합니다. 이로 인해 한 트랜잭션 내에서 쿼리 결과의 일관성이 깨질 수 있습니다.

개인적으로 멀티프로세스와 멀티스레드를 한방에 이해 시켜준 사진

멀티 프로레스(크롬) VS 멀티 스레드 (익스플로어)

프로세스는 운영체제로부터 자원을 할당받는 작업의 단위

프로세스의 특징

• 프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다.
• 기본적으로 프로세스당 최소 1개의 스레드(메인 스레드)를 가지고 있다. 각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다.
• 한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC, inter-process communication)을 사용해야 한다. Ex. 파이프, 파일, 소켓 등을 이용한 통신 방법 이용

스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위 (= 프로세스 내에서 실행되는 여러 흐름의 단위)

스레드의 특징

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

멀티프로세스와 멀티스레드

멀티 프로세싱 (Multiprocessing)은 다수의 프로세서로 다수의 "프로세스"를 협력적으로 동시에 처리하는 것입니다.

멀티스레딩 (Multithreading)은 하나의 프로세스 안에서 여러 개의 실행 흐름 (스레드)을 두는 방식으로 여러 실행을 동시에 실행하도록 하나의 프로세스를 운영하는 방식입니다

[크롬]

멀티 프로세스의 장점

• 안정성 : 하나의 프로세스가 죽어도 다른 프로세스에 영향을 미치지 않습니다.
• 보안: 각 프로세스는 자신의 메모리 공간을 가지고 있어 다른 프로세스의 메모리에 접근할 수 없습니다.

멀티 프로세스의 단점

• 시스템 자원 소모: 각 프로세스는 자신만의 메모리 공간을 가지므로, 메모리를 많이 소모합니다.
• IPC(Inter-Process Communication)가 필요합니다.

[익스플로어]

멀티 스레드의 장점

• 시스템 자원 소모가 적습니다.
• IPC가 필요하지 않습니다.

멀티 프로세스의 단점

• 안정성: 하나의 스레드가 죽으면 전체 프로세스가 영향을 받습니다.
• 보안: 각 스레드는 자신이 속한 프로세스의 메모리 공간을 공유하므로, 다른 스레드가 메모리에 접근할 수 있습니다.

1. 검색 가능한 이름을 사용하기 (Use a searchable name.)
2. 함수명은 반드시 동사로. 함수는 동작 하나만. 
3. 함수의 인수는 3개이하 적당. 많을 경우에는 Object로 정리해서 param 사용.
4. 함수의 파리미터에 boolean 을 둬서 액션 2개 이상을 구현하기 보다는, 함수를 2개로 구분하는 것을 추천. 
5. 변수명은 너무 축약하지 말것. 이해할 수 있는 변수명으로~! 

[주의] 문제 해결하려는 코딩 초반부에는 우선 동작에 초점 맞춰서 작업~! 

그 후에 깔끔하게 코딩 정리(5개 팁 참고)하는 것을 추천~!

REST란?

REpresentational State Transfer의 약자,

자원을 이름으로 구분해 해당 자원의 정보를 주고 받는 모든 것을 의미 = 자원 (resource)의 표현 (representation)에 의한 상태 전달을 뜻함 (네트워크 상의 Client와 Server 사이의 통신 방식 중 하나)

• 정의
  • 자원: 해당 SW가 관리하는 모든 것 (문서, 그림, 데이터 등)
  • 표현: 그 자원을 표현하기 위한 이름 (예: 학생 정보가 자원이라면 ‘students’ 등)
  • 상태 전달: 데이터가 요청되는 시점에 자원의 상태를 전달 (JSON 혹은 XML)

• 개념
  • 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI (Resource)로 GET, POST 등의 방식 (Method)을 사용하여 요청을 보내면, 요청을 위한 자원은 특정한 형태 (Representation of Resource)로 표현
    • URI: Uniform Resource Locator로 인터넷 상 자원의 위치
    • URL : Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성 

      

• 구성 요소
  
  • 자원 (Resource) - URI
    • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재함
    • 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI 임
    • Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한조작을 Server에 요청
  • 행위 (Verb) - Method
    • HTTP 프로토콜의 Method(GET, POST, PUT, PATCH, DELETE)를 사용
    • 표현 (Representation of Resource)
      • Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있음
      • JSON, XML을 통해 데이터를 주고 받는 것이 일반적
  • Server-Client (서버-클라이언트 구조)
    • 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
      • REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임짐
        • Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임짐
    • 서로 간 의존성이 줄어듬
  • Stateless (무상태)
    • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가짐
    • Client의 context를 Server에 저장하지 않음
      • 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해짐
    • Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
      • 각 API 서버는 Client의 요청만을 단순 처리
      • 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안 됨
      • 물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용
      • Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아짐
  • Cacheable (캐시 처리 가능)
    • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능
      • 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있음
      • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능
    • 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구됨
    • 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있음
  • Layered System (계층화)
    • Client는 REST API Server만 호출한
    • REST Server는 다중 계층으로 구성될 수 있음
      • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있음
      • 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있음
    • PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있음
  • Code-On-Demand (optional)
    • Server로부터 스크립트를 받아서 Client에서 실행
    • 반드시 충족할 필요는 없음
  • Uniform Interface (인터페이스 일관성)
    • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행
    • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
      • 특정 언어나 기술에 종속되지 않음특징
        
        

• 장점
  • HTTP 프로토콜을 그대로 사용하므로 별도의 인프라를 구축할 필요가 없음
  • HTTP 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
  • Hypermedia API의 기본을 지키면서 범용성을 보장 (*hypermedia -얽혀있는 정보: 복잡한것, 바뀌는것, 확실하지 않은것을 위한 파일 구조(그래픽, 오디오, 영상, 텍스트 등))
  • 의도하는 바를 명확하게 나타내므로 쉽게 파악 할 수 있다.
  • 서버와 클라이언트의 역할을 명확하게 분리한다.
• 단점
  • 표준이 존재하지 않는다
  • Method의 형태가 제한적이다.

• 설계 기본 규칙
  • 도큐먼트 : 객체 인스턴스나 데이터베이스 레코드, 컬렉션 내의 구체적인 맴버
  • 컬렉션 : 서버에서 관리하는 디렉터리
  • 스토어 클라이언트에서 관리하는 리소스 저장소
  1. URI는 자원을 표현해야함
     • 동사보다는 명사, 대문자보다는 소문자 이용
     • 도큐먼트 이름 = 단수 명사 이용
     • 컬렉션 이름 = 복수 명사 이용
     • 스토어 이름 = 복수 명사 이용 ex) GET /Member/1 -> GET /members/1 --- members(컬렉션), 1(도큐먼트)
  2. 자원에 대한 행위는 HTTP Method로 표현
     • URI에 Method가 들어가면 안된다.
     • URI에 행위에 대한 동사 표현이 들어가면 안된다.
     • 경로 부분 중 변하는 부분은 유일 값으로 대체한다. id 등
  3. 마지막 문자로 / 를 넣지 않는다.
  4. 불가피하게 긴 경로를 사용할 경우 (-)을 사용해가독성을 높이며 (_)은 이용하지 않는다.
  5. 확장자는 URI에 포함하지 않는다.

• REST아키텍처 스타일을 따르는 API -> REST API
• REST아키텍처를 완전하게 따라 만들어진 API -> RESTful API
• REST아키텍처를 구현하는 웹 서비스 -> RESTful 웹서비스

예시코드

const express = require('express');
const app = express();
app.use(express.json());

let books = [
  { id: 1, title: 'Book 1', author: 'Author 1'},
  { id: 2, title: 'Book 2', author: 'Author 2'},
  { id: 3, title: 'Book 3', author: 'Author 3'}
];

app.get('/books', (req, res) => {
  res.json(books);
});

app.get('/books/:id', (req, res) => {
  const book = books.find(b => b.id === parseInt(req.params.id));
  if (!book) res.status(404).send('The book with the given ID was not found.');
  res.send(book);
});

app.post('/books', (req, res) => {
  const book = {
    id: books.length + 1,
    title: req.body.title,
    author: req.body.author
  };
  books.push(book);
  res.send(book);
});

app.put('/books/:id', (req, res) => {
  const book = books.find(b => b.id === parseInt(req.params.id));
  if (!book) res.status(404).send('The book with the given ID was not found.');

  book.title = req.body.title;
  book.author = req.body.author;

  res.send(book);
});

app.delete('/books/:id', (req, res) => {
  const book = books.find(b => b.id === parseInt(req.params.id));
  if (!book) res.status(404).send('The book with the given ID was not found.');

  const index = books.indexOf(book);
  books.splice(index, 1);

  res.send(book);
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on port ${port}...`));

이 코드는 REST 아키텍처 원칙을 따르는 API를 구현하고 있습니다. RESTful API의 핵심 원칙은 자원(Resource), 행위(Verb), 표현(Representation)입니다. 이 코드에서는 책(Book)이라는 자원에 대한 CRUD(Create, Read, Update, Delete) 연산을 HTTP 메서드를 통해 수행하고 있습니다.

1. 자원(Resource): 이 코드에서 자원은 책(Book)입니다. 각 책은 고유한 ID를 가지며, 이를 통해 책을 식별하고 접근할 수 있습니다.
2. 행위(Verb): HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 책에 대한 CRUD 연산을 수행합니다.
   • GET /books: 모든 책의 목록을 가져옵니다.
   • GET /books/:id: 특정 ID의 책을 가져옵니다.
   • POST /books: 새로운 책을 추가합니다.
   • PUT /books/:id: 특정 ID의 책 정보를 업데이트합니다.
   • DELETE /books/:id: 특정 ID의 책을 삭제합니다.
3. 표현(Representation): 클라이언트와 서버가 데이터를 주고받는 형태입니다. 이 코드에서는 JSON 형식으로 데이터를 주고받습니다.

또한, 이 코드는 Stateless(무상태성) 원칙도 따르고 있습니다. 각 요청은 독립적으로 처리되며, 서버는 클라이언트의 상태 정보를 저장하지 않습니다. 따라서 이 코드는 REST 아키텍처 원칙에 따라 설계된 API입니다. 이러한 방식은 클라이언트와 서버 간의 상호작용을 단순화하고, 확장성과 유연성을 제공합니다. 이것이 위의 코드가 RESTful API로 설계된 이유입니다.

동기 (Synchronous)와 비동기(Asynchronous)

• 동기는 요청을 보낸 후 응답을 받아야지만 다음 동작이 이루어지는 방식이다. 어떠한 태스크를 처리할 동안 나머지 태스크는 대기한다. 실제로 cpu가 느려지는 것은 아니지만 시스템의 전체 효율이 저하된다고 할 수 있다.

function func1(){
	console.log('1');
  func2();
}
function func2(){
	console.log('2');
  func3();
}
function func3(){
	console.log('3');
}

func1();
//결과 1,2,3

• 비동기는 요청을 보낸 후 응답의 수락 여부와는 상관없이 다음 태스크가 동작하는 방식이다. 자원을 효율적으로 사용할 수 있다. 이때, 비동기 요청시 응답 후 처리할 Callback 함수를 함께 알려준다. 하지만 비동기 처리를 위해 여러 콜백함수를 중첩시키면 콜백지옥이 발생한다. 이를 해결하기 위해 Promise를 도입하였고, Async / Await 추가로 도입되었다. (Async / Await는  JavaScript에서 비동기 처리를 동기적인 방식으로 작성하게 해주는 문법입니다)

function func1() { 
  setTimeout(function(){
  console.log('1');
  }, 1000);
  func2(); 
} 
function func2() { 
  setTimeout(function() {
    console.log('2');
  }, 500); 
  func3(); 
} 
function func3() { 
  setTimeout(function(){
    console.log('3');
  }, 1500);
}

func1();

//결과 2, 1, 3

동기가 사용되는 예시

• 데이터베이스에서 데이터를 읽어오는 작업 : DB에서 데이터를 읽은 후, 그 데이터를 다음 작업을 수행해야 하는 경우 동기처리가 필요함 (반대로 데이터 추출 작업이 빈번한 경우, 비동기식으로 하기도 함)

async createCollection(userId: number, name: string) {
try {
  const newBookmark = await this.collectionRepository.insert({
    user_id: userId,
  });
}

• 파일 시스템에서 파일을 읽는 작업: 파일을 읽은 후 해당 내용으로 작업하는 경우

비동기가 사용되는 예시

• 웹 API 호출 : API를 호출하고 기다리는 동안 다른 작업도 수행
• setTimeOut 함수 : 주어진 시간이 지난후 특정함수가 실행되는 함수로 함수가 실행되는동안 다른 작업도 수행

블로킹과 논블로킹

흐름의 차단 여부를 결정

블로킹

• 제어권을 넘겨줌 - 명령이 수행되기 시작하면 프로그램 흐름의 제어권이 명령 수행중인 함수로 넘어감

논블로킹

• 제어권을 넘겨주지 않음 - 명령을 시키고 제어권은 여전히 메인이 가지고 있음

sync-async-block-NonBlock 조합

• Sync_Block -- 위에서 설명한 동기방식과 동일
• Async_Non-Block -- 위에서 설명한 비동기방식와 동일
• Sync_Non-block -- 제어권을 메인에서 가지고 있어 다른일을 수행할 수 있지만 FuncA가 완료되어야만 다음 작업이 가능할때 사용 ex) 게임 로딩, 프로그래스바 - 둘다 제어권은 메인에서 가지고 있으며 로딩바의 작동은 지속적으로 보여지지만 데이터는 계속 로딩되고 있으며 로딩하고 있는 시스템에 계속해서 어느정도 로드 됬는지 조회한 후 로딩이 끝나야 다음 작업으로 넘어간다.
• Async_Block -- 실수나 잘못 구현한 경우가 아닌 경우 sync_block과 차이가 없기에 거의 사용되지 않음 -- node.js와 MYSQL의 경우 node.js에서 비동기 방식의 쿼리를 보냈을떄 MySQL에서 블로킹을 하기때문에 결국엔 동기처리와 다르지 않게 된다고 한다.

절차지향 프로그래밍이란 물이 위에서 아래로 흐르는 것처럼 순차적인 처리가 중요시 되며, 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법으로 대표적인 절차지향 언어는 C언어가 있습니다.

장점은 컴퓨터의 처리구조와 유사해 실행속도가 빠르지만,

단점으로 유지보수가 어렵고, 실행 순서가 정해져 있으므로

코드 순서가 바뀌면 동일한 결과를 보장하기 어려우며, 디버깅하기도 어렵습니다.

하지만 하드웨어의 발전으로, 성능에 조금 부담을 주더라도 큰 단점이 아니게 되었기에 모듈화, 캡슐화해서 개념적으로 접근하는 형태를 갖는 객체지향 프로그래밍이 탄생했습니다.

객체 지향 프로그래밍(Object-Oriented Programming, OOP)은 프로그램을 객체라는 독립된 단위들의 모임으로 보고 개발하는 것입니다. 객체는 상태와 행위를 가지며, 서로 메시지를 주고받고 데이터를 처리할 수 있습니다. 이러한 객체들이 서로 상호작용하면서 프로그램을 구성하는 것이 객체 지향 프로그래밍의 핵심입니다.

• 절차지향 프로그래밍: 프로그램의 순서와 흐름을 먼저 세우고 필요한 자료구조와 함수들을 설계하는 방식
• 객체지향 프로그래밍: 자료구조와 이를 중심으로 한 모듈들을 먼저 설계 후 이들의 실행순서와 흐름을 짜는 방식

절차지향 vs 객체지향

• 절차지향 프로그래밍 (Procedural Programming)
  • 프로시저(루틴, 하위 프로그램, 서브루틴, 메서드, 함수 등)를 이용하여 작성하는 프로그래밍 방식
  • 프로시저 콜(함수 호출)의 개념을 바탕으로 한 프로그래밍 패러다임
  • 기능 중심으로, ‘어떤 기능을 어떤 순서로 처리할 것인가?’의 관점을 사용
  • C, Visual Basic, Fortran, Pascal 등
  • 특징
    • 하나의 큰 기능을 처리하기 위해 작은 단위의 기능들로 나누어 처리하는 Top-Down 접근 방식으로 설계 = 큰 틀부터 설계
    • 데이터와 함수를 별개로 취급 → 함수가 많아질 수록 데이터의 변경 사항을 추적하기 어려워짐
    • 모든 함수는 데이터 공유가 가능
    • 정해진 순서대로 입력해야 하므로 순서가 바뀌면 결과를 도출하기 어려움
    • 프로그램이 커질수록 구조가 복잡해져 유지보수가 어려움 (소형 프로젝트에 적합)
      
      

      ---

• 객체지향 프로그래밍 (Object-Oriented Programming)
  • 우리가 실생활에서 쓰는 모든 것을 객체라고 하며, 프로그램 구현에 필요한 객체를 파악하고 각각의 객체들의 역할이 무엇인지를 정의하여 객체 간의 상호작용을 통해 프로그램을 만드는 것. 객체는 클래스라는 틀에서 생겨난 실체(Instance)
  • 객체가 중심이 되며, ‘누가 어떤 일을 할 것인가?’의 관점으로 바라보는 방식
  • C++, C#, Java, Python 등
  • 객체지향 프로그래밍의 주요 특징 4가지
    • 추상화 (Abstraction): 구체적으로 정의하는 것이 아니라 필요한 정보만을 중심으로 간소화 하는 것. 지하철 노선도 처럼 실제 지형도보다 지하철역 간의 상대 위치가 중요하게 정리된 것이 추상화의 대표적인 예.
    • 캡슐화 (Encapsulation): 객체가 독립적인 역할을 할 수 있도록 데이터와 기능을 하나로 묶어서 관리하는 것. 실제로 구현되는 부분을 외부에 드러나지 않도록 하여 정보를 은닉 가능.
    • 상속성 (Inheritance): 하나의 클래스가 가진 데이터나 기능을 다른 클래스가 그대로 물려받는 것. 기존 코드를 재사용하여 확장 가능.
    • 다형성 (Polymorphism): 하나의 클래스나 메서드가 다양한 방식으로 동작이 가능한 것. 오버라이딩과 오버로딩이 있음. (오버라이딩 - 상속받은 메소드를 서브클래스에서 재정의 하는것 & 오버로딩 - 같은 이름의 메소드가, 받는 파라미터(매개변수)에 따라 다르게 동작하는 것)
  • 장점
    • 상속, 캡슐화, 다형성의 특징으로 코드를 재사용하거나 확장하기 좋아서 유지보수가 쉬움
    • 관련이 많은 객체의 상호작용을 생각해 실세계에 대한 모델링을 좀 더 쉽게 해줌
    • 캡슐화 특징으로 실제로 구현되는 부분을 외부에 드러나지 않도록 은닉하여 보안성이 높음
  • 단점
    • 캡슐화와 격리구조 때문에 절차지향 프로그래밍보다 실행 속도가 느림
    • 객체 단위의 구성으로 필요한 절차지향 프로그래밍보다 메모리 비용이 큼

요약

• 절차지향은 데이터 중심, 객체지향은 기능 중심
• 절차지향의 반대는 객체지향이 아니고 객체지향의 반대는 절차지향이 아님

대칭키 암호화는 암호화와 복호화에 같은 키를 사용하는 암호화 방식

비대칭키 암호화는 암호화와 복호화에 다른 키를 사용하는 암호화 방식

1. 대칭키(비밀키) 암호화

• 장점: 데이터를 암호화하기 위한 연산이 빨라 대용량 Data 암호화에 적합, 구현이 용이, 기밀성을 제공
• 단점: 키를 교환해야하는 문제, 탈취 관리 걱정, 사람이 증가할 수록 키 관리가 어려움, 확장성 떨어짐

• 하나의 비밀키를 서버&클라이언트 모두 함께 사용
• 암호화와 복호화에 같은 키를 사용하는 방식
• 비밀키 하나만 알아내면 암호화된 내용 해킹 가능
• 속도가 빠르다는 장점이 있지만, 키를 교환해야 한다는 문제가 있어서 중간에 탈취 당해 해킹당할 수 있다.
  ( 위험한 이유 : 처음 상대방에게 대칭키를 전송하는 과정에서 탈취당하면 통신내용 모두 해킹 가능)
• 서로 키를 보관해야 하기 때문에 관리해야 할 키가 방대해질 수 있다.

  

2. 비대칭키(공개키) 암호화

• 장점: 키분배 및 키 관리 용이, 기밀성/인증/부인 방지 기능 제공
• 단점: 속도가 느림, 상대적으로 키의 길이가 길다

• 공개키와 개인키(비밀키), 두개를 가지고 있음
• 공개키는 모든 사람이 접근 가능한 키
• 개인키는 각 사용자만이 가지고 있는 키
• 공개키는 누구나 알 수 있지만, 그에 대응하는 개인키(비밀키)는 키의 소유자만이 알 수 있다. 특정 비밀키를 가 사용자만이 내용을 열어볼 수 있도록 하는 방식.
  (안전한 이유: 공개 키로 누구든지 암호화 해서 보낼 순 있지만, 복호화가 가능한건 개인키를 가진 사람뿐 - 반대상황도 가능)