테스트 주도 개발 (TDD, Test Driven Development)

• 정의 : TDD는 개발 과정에서 테스트를 먼저 작성하고, 이 테스트를 통과할 수 있는 코드를 작성하는 방식

• 목적 : 코드의 신뢰성과 유지 보수성을 높이는 것

• 프로세스 :

  1. 실패하는 단위 테스트를 먼저 작성

     @Test
     public void testAddition() {
      Calculator calculator = new Calculator();
      int result = calculator.add(5, 3);
      assertEquals(8, result);
     }

  2. 테스트를 통과하기 위한 최소한의 코드를 작성

     public class Calculator {
      public int add(int a, int b) {
          return a + b;
      }
     }

  3. 코드를 리팩토링하여 개선

• 장점 :

  1. 요구사항 이해도 향상
  2. 기존 기능 정상 동작 확인 가능
  3. 코드 리팩토링

• 단점 :

  1. 코드량 증가
  2. 진입장벽
  3. 주객전도

도메인 주도 개발 (DDD, Domain Driven Desing)

도메인(Domain) : 사전적 의미로 영역, 집합, 유사한 업무의 집합

• 정의 : 데이터 중심의 접근법을 탈피하여 순수한 도메인의 모델과 로직에 집중하여 개발에 접근 (도메인을 서비스 별로 분리, MicroService)

• 목적 : 도메인의 복잡성을 관리하고, 소프트웨어가 비즈니스 요구 사항을 충족시키도록 하는 것

• 특징 :

  • 도메인 모델을 중심으로 소프트웨어를 설계

  • 보편적인 언어의 사용을 추구하여, 도메인 전문가와 개발자 간의 긴밀한 협력을 강조

    public class Order {
    
    private OrderId id;
    private Customer customer;
    private List<OrderLine> orderLines;
    private OrderStatus status;
    
    public Order(Customer customer) {
        this.customer = customer;
        this.orderLines = new ArrayList<>();
        this.status = OrderStatus.NEW;
    }
    
    public void addOrderLine(Product product, int quantity) {
        OrderLine line = new OrderLine(product, quantity);
        orderLines.add(line);
    }
    
    ...
    }

행동 주도 개발 (BDD, Behvior Driven Development)

• 정의 : BDD는 소프트웨어의 기능이 사용자의 행동에 초점을 맞추도록 하는 시나리오 기반 개발 방법론
• 목적 : 사용자 중심의 소프트웨어 개발을 촉진하고, 명확한 커뮤니케이션을 통해 개발과 요구 사항 간의 간극을 줄이는 것
• 특징 :
  • 사용자의 행동과 요구 사항을 명확하게 이해하는데 중점
  • Given - When - Then 과 같은 언어를 사용하여 행동을 설명

    @Given("I have a calculator")
    public void i_have_a_calculator() {
    calculator = new Calculator();
    }
    

@When("I add {int} and {int}") public void i_add_and(int a, int b) { result = calculator.add(a, b); }

@Then("the result should be {int}") public void the_result_should_be(int expected) { assertEquals(expected, result); } ```

• 의존성 주입(DI, Dependency Injection)이란 메인 모듈(main module)이 '직접' 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자(dependency injector)가 이 부분을 가로채 메인 모듈이 '간접'적으로 의존성을 주입하는 방식

• 이를 통해 메인 모듈과 하위 모듈간의 의존성을 조금 더 느슨하게 만들 수 있으며 모듈을 쉽게 교체 가능한 구조로 만듬

의존한다

• A가 B에 의존한다 = B가 변하면 A에 영향을 미치는 관계 = A -> B 를 의미
• 코드로는 이러한 것을 A가 B에 의존한다고 함

class B {
    public void go() {
        System.out.println("B의 go() 함수");
    }
}

class A {
    public void go() {
        new B().go();
    }
}

public class main {
    public static void main(String args[]) {
        new A().go();
    }
}
// B의 g() 함수

자바 - Project에 DI를 적용하지 않은 사례

class BackendDeveloper {
    public void writeJava() {
        System.out.prinln("Java Server Developer");
    }
}

class FrontendDeveloper {
    public void writeJavascript() {
        System.out.println("React Developer");
    }
}

public class Project {
    private final BackendDeveloper backendDeveloper;
    private final FrontEndDeveloper frontEndDeveloper;

    public Project(BackendDeveloper backendDeveloper, FrontEndDeveloper frontEndDeveloper) {
        this.backendDeveloper = backendDeveloper;
        this.frontEndDeveloper = frontEndDeveloper;
    }

    public void implement() {
        backendDeveloper.writeJava();
        frontEndDeveloper.writeJavascript();
    }

    public static void main(String args[]) {
        Project a = new Project(new BackendDeveloper(), new FrontEndDeveloper());
        a.implement();
    }
}

자바 - 자바 - Project 의 DI 적용한 사례

• DI를 적용한 모습
• 여러명의 개발자를 추가할 수도 있으며 다른 IOS 개발자 등으로 교체도 쉽게 할 수 있는 구조임을 보여줌
• 의존적인 화살표가 '역전'된 것을 볼 수 있음
• DI를 하게 되면 의존관계역전원칙(Dependency Inversion Principle)이 적용되는 것

interface Developer {
    void develop();
}

class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        writeJava();
    }

    public void writeJava() {
        System.out.println("Java Server Developer");
    }
}

class FrontendDeveloper implements Developer {
    @Override
    public void develop() {
        writeJavascript();
    }

    public void writeJavascript() {
        System.out.println("React Developer");
    }
}

public class Project {
    private final List<Developer> developers;

    public Project(List<Developer> developers) {
        this.developers = developers;
    }

    public void implement() {
        developers.forEach(Developer::develop);
    }

    public static void main(String args[]) {
        List<Developer> dev = new ArrayList<>();
        dev.add(new BackendDeveloper());
        dev.add(new FrontendDeveloper());

        Project a = new Project(dev);
        a.implement();
    }
}

의존관계 역전 원칙 (DIP, Dpendency Inversion Principle)

• 의존성 주입을 할 때는 의존관계 역전 원칙(DIP)이 적용 됨
• 상위 모듈과 하위 모듈의 관계 : 상위 모듈(고수준 모듈)은 하위 모듈(저수준 모듈)에 의존해서는 안 됨. 대신, 두 모듈 모두 추상화에 의존해야 함.
  • 이는 상위 모듈이 하위 모듈의 구현 세부 사항에 직접적으로 의존하지 않게 함으로써 모듈 간의 결합도를 낮춤
• 추상화와 세부 사항의 관계 : 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 함.
  • 즉, 인터페이스(추상화)는 구현 세부 사항(하위 모듈)에 의존하지 않아야 하며, 구현은 인터페이스에 맞춰져야 함

    의존성 주입의 장점

• 모듈 교체 용이성 : 외부에서 모듈을 생성하고 주입하는 구조는 모듈 교체를 쉽게 할 수 있게 해줌. 이를 통해 코드의 재사용성과 유지보수성이 향상됨
• 단위 테스팅 용이성 : 의존성 주입을 사용하면 테스트를 위한 목(mock) 객체나 스텁(stub) 객체를 쉽게 주입할 수 있어 단위 테스팅이 용이해짐
• 마이그레이션 용이성 : 다양한 환경(예: 다른 데이터베이스)으로의 마이그레이션 시 필요한 변경 사항을 적용하기 쉬워짐
• 코드의 일관성 : 의존성 방향이 일관되어 코드를 이해하고 추론하기 쉬워짐

의존성 주입의 단점

• 복잡도 증가 : 의존성 주입을 위한 추가적인 코드와 모듈이 필요하게 되어 전반적인 시스템의 복잡도가 증가할 수 있음
• 런타임 에러의 가능성 : 의존성 주입은 주로 런타임에 이루어지므로, 컴파일 타임에는 이러한 의존성 문제를 발견하기 어려울 수 있음

참고 및 출처 : 인프런 - CS 지식의 정석 | 디자인패턴, 큰돌 https://www.inflearn.com/course/lecture?courseSlug=%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95&unitId=118490&tab=curriculum

JSON

JSON (JavaScript Object Notation)은 데이터를 교환하는 데 사용되는 경량의 데이터 포맷

• Javascript 객체문법

• 키(key) : 값(value)으로 구성

• 이미 존재하는 키를 중복선언하면 나중에 선언한 해당 키에 대응한 값이 덮어쓰이게 됨

    a.json
    {
        "name" : "lee"
        "name" : "kim"
        "job" : "developer"
    }
  
    name == kim
    job == developer

• 데이터 + 교환 형식

  • 데이터는 추상적인 아이디어에서부터 시작해 구체적인 측정에 이르기까지 다양한 의미로 쓰임
  • 실험, 조사, 관찰 등으로 부터 얻은 사실이나 자료등을 의미

• 여러언어에서의 쓰임

  • javascript -> Object
  • java -> map
  • Python -> dict
  • 해시테이블

• 단순배열, 문자열 표현

    b.json
    [1, 2, 3, 4]
  
    c.json
    "가나다라마바사"

• JSON의 타입

  • javascript object와 유사하지만 undefined, 메서드 등을 포함할 수 없음
  • 수(Number)
  • 문자열(String)
  • 참/거진(Boolean)
  • 배열(Array)
  • 객체(Object)
  • null

• JSON의 활용

  • 프로그래밍 언어와 프레임워크 등에 독립적이므로, 서로 다른 시스템간에 데이터를 교환하기 좋음
  • 주로 API 반환형태, 시스템을 구성하는 설정파일에 활용

직렬화 / 역직렬화

직렬화 : 데이터 구조나 객체 상태를 다른 환경으로 저장하거나 전송할수 있는 형식(문자열/바이트 스트림)으로 변환하는 과정

• 객체 -> 문자열
• JSON.stringify()

역직렬화 : 직렬화된 데이터를 원래의 데이터 구조나 객체 상태로 복구하는 과정

• 문자열 -> 객체
• JSON.parse()

XML

XML(Extensible Markup Language)은 마크업 형태 를 쓰는 데이터교환형식

• 마크업(markup)형태로 태그 등을 이용하여 문서나 데이터의 구조를 나타내는 방법(속성부여도 가능)
• 구성
  • 프롤로그 : 버전, 인코딩
  • 루트요소(단 하나만)
  • 하위 요소들

    <?xml version="1.0" encoding="UTF-8"?>        // 프롤로그
    <bookstore>                                 // 루트요소
    <book>                                      // 하위 요소
        <title>Learning XML</title>             // 더 작은 요소
        <author>Jane Doe</author>
    </book>
    <book>
        <title>XML Simplified</title>
        <author>John Smith</author>
    </book>
    </bookstore>

• sitemap.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
        <url>
            <loc>http://www.example.com/foo.html</loc>
            <lastmod>2018-06-04</lastmod>
        </url>
        <url>
            <loc>http://www.example.com/abc.html</loc>
            <lastmod>2018-06-04</lastmod>
        </url>
    </urlset>

  • 서비스 내의 모든 페이지들을 리스트업한 데이터
  • 사이트가 매우 크거나 서로 링크가 종속적으로 연결되지 않은 경우 크롤러가 일부 페이지를 누락하는 일이 발생, 이를 sitemap.xml이 방지하고 모든 페이지들을 크롤링할 수 있도록 해줌
  • XML은 대표적으로 sitemap.xml에 사용

HTML vs XML

• HTML의 용도는 데이터를 표시 / XML은 데이터를 저장 및 전송
• HTML에는 미리 정의된 태그 사용 / XML에서는 사용자가 고유한 태그를 만들고 정의 가능
• HTML은 대소문자를 구분하지 않음 / XML은 대소문자를 구분

JSON vs XML

• XML은 닫힌 태그가 존재하기에 JSON보다 무거움

    JSON
    {
        "bookstore": {
            "book": [
                {
                    "title": "Learning XML",
                    "author": "Jane Doe"
                },
                {
                    "title": "XML Simplified",
                    "author": "John Smith"
                }
            ]
        }
    }
  
  

XML
<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
    <book>
        <title>Learning XML</title>
        <author>Jane Doe</author>
    </book>
    <book>
        <title>XML Simplified</title>
        <author>John Smith</author>
    </book>
</bookstore>
```

• Javascript Object로 변환하기 위해 JSON보다 많은 노력이 필요
  • JSON은 JSON.parse()로 끝

출처 및 참고 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95#

서버 과부하

• 서버가 리소스를 소진하여 들어오는 요청을 처리하지 못할 때 발생
• 이 때, 서버는 사용자의 웹요청을 처리하지 못해 응답없음이 뜸

해결방법

모니터링을 통한 자원 할당

"자원의 한계점 도달"로, 보통 서버의 CPU 사용량이 80-90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부하 상태가 됨

• AWS 오토 스케일링

  • 서비스 이용불가능 상태 발생 이전 cloud watch가 계속해서 모니터링하여 서버 대수를 늘려주는 방법
  • AWS Auto Scaling은 애플리케이션을 자동으로 모니터링하고 자원의 용량을 자동으로 조정

• netdata를 이용한 모니터링

• 모니터링을 하는 이유

  • 어떤 페이지에 어떤 트래픽이 얼마나 발생했냐
  • 어떤 네트워크에서 병목현상이 일어났냐
  • 활용도가 낮은/높은 페이지를 파악 -> 서비스 개선

로드밸런서

• AWS 오토스케일링은 빠르지만 구성에 시간이 걸리기 때문에 앞단에서 로드밸런서를 통해 트래픽을 분산해야함
• 로드밸런서는 한 서버에 장애가 발생하면 로드 밸런서는 트래픽을 다른 기능 서버로 리디렉션하여 시스템 중단을 방지할 수 있음

서킷 브레이커

• MSA에서 과부하를 방지하기 위해 사용되는 패턴, 시스템의 일부가 과부하되었을 때 자동으로 해당 부분을 차단하는 역할
  • 감지 : 특정 서비스나 리소스에 대한 요청 실패율이 설정된 임계값을 초과하면 감지
  • 차단 : 임계값을 초과하면 자동으로 해당 서비스나 리소스에 대한 요청을 일시적으로 차단
  • 복구 시도 : 설정된 시간이 지난 후, 서킷 브레이커는 자동으로 차단을 해제, 서비스 상태 확인
  • 장점 : 연속적인 에러 발생을 막아주며, 일부 서비스가 종료되더라도 다른 서비스들은 이상 없이 동작하게 만들 수 있으며, 사용자 경험을 높임

블랙스완 프로토콜

• 예상치 못한 큰 이벤트나 요청이 서버에 과부하를 일으킬 때, 이를 감지하고 대응하는 시스템
  • 감지 : 시스템은 트래픽 패턴, 메모리 사용량, CPU 사용량을 지속적으로 모니터링
  • 대응 : 이상 징후가 감지되면 자동으로 트래픽을 조절하거나, 필요한 경우 일부 서비스를 일시적으로 중단
  • 복구 : 문제가 해결되면 서비스는 자동으로 정상 상태로 돌아감

구글의 블랙스완 대응 수칙

컨텐츠 관리

• 불필요한 컨텐츠 제거
  • 조회쿼리 개선
• CDN을 통한 컨텐츠 제공
  • CDN을 통해 사용자 가까이, 그리고 분산된 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 메인 서버에 대한 부하를 줄임

CDN(Content Delivery Network) : 전 세계에 분산된 서버 네트워크를 사용하여 사용자에게 웹 콘텐츠를 제공, 이 네트워크는 사용자에게 가까운 위치에 서버를 두어 콘텐츠 접근 속도를 향상시킴

• 컨텐츠 캐싱
  • 네트워크 트래픽을 해결하는 가장 좋은 방법은 해당 트래픽이 발생하지 않는 것
  • 브라우저 캐시(쿠키, 로컬저장소, 세션저장소)를 통해 해당 요청에 관한 항목을 캐시에서 읽어 네트워크 요청에 관한 비용을 모두 제거

• 컨텐츠 압축
  • gzip/Brotli를 통해 70% 정도까지 압축
  • 압축을 풀기위해 서버에서 자원을 사용하는 양까지 고려해야함
  • 보통은 압축하면 좋음

• 컨텐츠의 우하한 저하(미리 준비된 응답)
  • 정적 텍스트 페이지를 제공
  • 검색 비활성화 or 더 적은 수의 검색 결과를 반환
  • 필수적이지 않은 기능 비활성화

출처 및 참고 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95#

HTTP에 TLS(Transport Layer Security) 암호화 계층이 추가된 형태

• HTTPS의 목적은 인터넷 상에서 데이터를 안전하게 전송하기 위함
• 클라이언트와 서버 간 통신의 도청, 데이터 변조, 메시지 위조로부터 보호

암호화

• 암호화는 승인된 사용자만 정보를 이해할 수 있도록 데이터를 스크램블한 방법
• 이를 복호화하려면 송/수신자가 서로 동의한 key가 필요
• 또한 이를 만들기 위해 key가 쓰이기도함
• ciphertext = plaintext + key

1. 스크램블

각 단어나 문자를 패턴에 따라 암호화하는 것이 아니라 무작위 방식으로 개별 데이터 비트를 섞는 것

• 공통 128bit AES(Advanced Encryption Standard)으로 암호화된 파일의 경우, 구성하는 비트는 약 10회 스크램블되며 다른 컴퓨터가 키없이 해독하려면 아주 오랜 시간이 걸림
• 비트가 높아질수록 스크램블을 많이 하게 되고 더 복잡해짐
• 128bit가 AES의 가장 약한 버전. 192bit, 256bit 키 크기도 제공

2. 대칭 암호화

키를 하나만 사용하는 암호화

• hello라는 텍스트를 키로 암호화
• 동일한 키로 암호를 해독해서 hello를 반환
• 일반적으로 사용되는 대칭 암호화 알고리즘은 DES, AES

• Plaintext + key = ciphertext -> hello + 2jd8932kd8 = X5xJCSycg14
• Ciphertext + key = plaintext -> X5xJCSycg14 + 2jd8932kd8 = hello

3. 비대칭 암호화

비대칭 암호화는 공개키 암호화라고도 함
두 개의 다른키(공개키, 개인키)로 데이터를 암호화 하거나 서명하고 키 중 하나인 공개 키를 누구나 사용할 수 있도록 하는 방법

• 공캐키로 암호화된 데이터는 개인키로만 복호화할 수 있음
• 일반적으로 사용되는 비대칭 암호화 알고리즘은 RSA, DH(Diffie-Hellman)
• HTTPS를 가능하게 하는 프로토콜인 TLS는 부분적으로 비대칭 암호화 사용(TLS1.3)
• 비대칭 암호화로 인증 후, 대칭 암호화로 보안적 통신 시작

TLS HandShacke 과정에서 처음 인증할 때 비대칭 암호화 사용 후, 클라이언트와 서버는 세션키라고 하는 키를 기반으로 대칭 암호화를 기반으로 암호화된 통신을 합니다.

4. 암호화의 필요성

• 암호화는 의도한 송/수신자를 제외하고는 통신을 Hijacking(하이재킹)하여 읽을 수 없게 함
• 민감한 데이터의 유출을 방지하고 데이터의 무결성을 보장

• Hijacking : 데이터를 중간에 가로채는 공격
• 데이터 무결성 : 데이터의 정확성과 일관성

TLS (Transport Layer Security)

TLS는 데이터를 안전하게 전송하기 위한 전송 계층의 암호화 프로토콜

• SSL(Secure Socket Layer) 후속 버전으로, HTTPS에서 데이터 암호화를 위해 주로 사용

1. TLS HandShake

• Client Hello
  • 클라이언트가 TLS 버젼, 사이퍼슈트, 클라이언트 랜덤값, 임시 DH 매개변수를 서버에게 송신
• Server Hello (EncryptedExtensions, Certificate, CertificateVerify)
  • 서버가 클라이언트로부터 받은 옵션을 확인
  • 서버/클라이언트가 둘 다 지원하는 가장 높은 TLS 버전을 식별하여 결정
  • 사이퍼슈트 지원 여부 확인
  • SSL 인증서, 서버 랜덤값, 임시 DH매개변수를 보냄
  • 클라이언트, 서버가 서로 교환한 매개변수를 사용해 임시 암호키(세션키) 생성
• Finished
  • 클라이언트와 서버가 세션키를 기반으로 대칭 암호화된 통신 시작

• DH(Diffie-Hellman) : 서로 공개값 공유, 비밀값과 혼합, 혼합값과 공유, 각자 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘
• 사이퍼 슈트 : 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 말하며, 암호제품군이라고도 불림. TLS 1.3 버전에는 5개가 있음
• AEAD 사이퍼 모드 : AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘, AES_128_GCM이라는 것은 128비트의 키를 사용하는 표준 블록 암호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻함

그 외

1. 인증서

• 주체(인증서를 발급한 CA, 도메인, 웹사이트 소유자, 인증서 소유자)와 공개키(공개키, 암호화방법)를 포함하는 데이터 파일
• 자신의 웹사이트 안에서 SSL 인증서를 만들 수도 있지만 보통은 인증기관인 CA에서 발급한 SSL 인증서를 기반으로 인증작업을 수행
• 주체는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 확인할 때 쓰이고 공개키는 처음 인증작업을 수행할 때 쓰임

2. CA (Certificate Authority)

• 인증서를 발급하는 기업들

출처 및 참고 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95#

HTTP/1.0

• HTTP/1.0은 수명이 짧은 연결, HTTP 요청은 자체 요청에서 완료
• 각 요청당 TCP Handshakerk 발생되며 한 연결당 하나의 요청을 처리하도록 설계
• 문제점 :
  • 연결할 때마다 TCP 연결로 인해 RTT의 증가

RTT(Round Trip Time, 왕복 지연시간) : 신호를 전송하고 해당 신호의 수신확인이 걸린 시간을 더한 값이자 어떤 메시지가 두 장치 사이를 왕복하는데 걸린 시간

HTTP/1.1

• HTTP/1.0의 단점을 보완한 프로토콜, 크게 3가지 차이점

  1. keep-alive default

• TCP 연결을 매 요청마다 하지 않고, 한번 해놓고 계속해서 요청을 주고 받을 수 있음
• 이는 keep-alive 옵션을 기본옵션으로 하면서 가능해짐

keep-alive header : TCP연결을 유지하는 것을 알려주는 헤더로 연결유지시간인 timeout과 최대 요청수 max를 정함

2. 호스트 헤더

• HTTP/1.0은 서버가 하나의 호스트만 상대한다고 가정하기에 호스트 헤더를 포함하지 않음
  • 이 때문에 HTTP/1.0은 하나의 IP에 하나의 호스트만 가질 수 있었음
• 서버는 여러개의 호스트를 가질 수 있기에 HTTP/1.1에서는 요청시 호스트 헤더를 포함하도록 함

3. 대역폭 최적화

• HTTP/1.0은 파일은 다운로드 받다 연결이 끊기면 이어서 다운로드하는 것이 불가능

  10KB 파일을 다운로드 할 때, 5KB 까지 받고 나중에 다시 이어받기 불가능

• HTTP/1.1에서는 Range:bytes=5000- 라는 헤더를 추가해서 다운로드 재개 요청을 할 수 있음

4. 그 외 요청을 줄이기 위한 기술

• 이미지 스프라이트 (image sprite)
  • 수 많은 이미지를 하나의 이미지로 만들어 다운받고, 이를 통해 많은 이미지를 다운 받은 것 같은 효과
• 코드 압축
  • 코드를 압축해서 서빙
• 이미지 Base64 인코딩
  • 이미지 파일을 64진법으로 이루어진 문자열로 인코딩해 이미지 서버에 대한 HTTP요청을 없앰
  • 인코딩시 파일크기가 평균적으로 약 37% 커지는 단점

5. HTTP/1.1의 고질적인 문제

• 무거운 헤더
• HOL(Head Of Line Blocking) : 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상

HTTP/2

• 2009년 구글이 HTTP/1.1의 한계를 극복하기 위해 SPDY 프로토콜 개발
• 2015년 SPDY 기반 HTTP/2 프로토콜 개발

1. 바이너리 포맷 계층

• 애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가
• HTTP 1.0은 일반 텍스트 메세지를 전송하고 줄바꿈으로 데이터를 나눴다면 2.0은 0/1로 이뤄진 바이너리 데이터로 변경하고 더 작은 메세지가 프레임으로 캡슐화 돼서 전송

2. 멀티 플렉싱

• 단일 TCP연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낼 수 있음, 이를 통해 HOL을 해결
• 2.0에서는 리소스를 작은 프레임을 나누고 이를 스트림으로 프레임을 전달
  • 각각의 프레임은 스트림ID, 해당 크기를 나타내는 프레임이 추가
  • 때문에 작게 나눠서 다운로드 되더라도 결과적으로 응답데이터는 올바른 순서로 재조립 가능

3. 서버 푸시

• 서버가 리소스를 클라이언트에 푸시 가능
• html을 요청했을 때, css가 포함되어야한다면 서버가 알아서 css도 같이 보내줌

4. 헤더 압축

• HTTP/1.1에는 무거운 헤더가 있음
• 2.0에서는 중복되는 헤더를 제외하고 공통 필드로 헤더를 재구성하며 중복되지 않은 헤더값은 허프만 인코딩 압축 방법으로 압축해 전송

  허프만 인코딩 : 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트수를 사용해 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 전체 데이터 표현에 필요한 비트양을 줄이는 알고리즘

  5. 우선 순위

• 서버에서 원하는 순서대로 우선순위를 정해 리소스를 전달할 수 있음

HTTP/3

• HTTP/2는 여전히 TCP를 사용하므로 초기 연결에 대한 RTT로 인한 지연시간이 존재

• HTTP/3은 QUIC라는 계층 위에서 돌아가며, TCP기반이 아닌 UDP 기반으로 돌아가며, HTTP/2에서 장점이었던 멀티플렉싱 등을 가지고 있으며 초기 연결 설정시 지연시간 감소라는 대표적 특성을 지님

  QUIC(Quick UDP Internet Connections) : 구글에 의해 개발된, 새로운 인터넷 전송 프로토콜

• HTTP/2는 3-RTT가 필요했지만, HTTP/3은 QUIC로 인해 1-RTT만 필요하다는 장점을 지님

• HTTP/2의 경우 TCP 3-handshake 1-RTT, TLS1.2-handshake 2-RTT가 필요

• HTTP/3의 경우 TLS1.3-handshake로 한번에 클라이언트와 서버간의 연결로 1-RTT, 암호화 통신 모두 다 구축

• 전송된 패킷이 손실 되었다면 수신측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑하는 순방향 오류 수정 메커니즘(FEC, Forward Error Correction)이라는 특징을 지님

출처 및 참고 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95#

모놀리식 아키텍쳐 (Monolithic Architecture)

각 서비스들이 강하게 결합되어 하나의 전체 시스템으로 통합되어 있는 구조

특징 :

• 단일 코드베이스 : 전체 어플리케이션은 하나의 코드베이스에서 관리
• 간단한 개발 및 배포 : 초기 개발과 배포가 상대적으로 간단
• 단일 언어 및 프레임 워크 사용 : 보통 하나의 프로그래밍 언어와 프레임워크로 구성
• 수직적 확장(스케일업) : 서능 향상을 위해 하드웨어를 업그레이드하는 방식을 취함

장점 :

• 개발 초기 용이성 : 초기 개발과 테스트가 비교적 간단
• 간소화된 디버깅 및 테스트 : 모든 구성 요소가 한 곳에 있어 디버깅과 테스트가 용이

단점 :

• 유연성 부족 : 새로운 기술이나 언어로의 이전이 어려움
• 확장성 제한 : 큰 트래픽에 대응하기 어렵고, 수직적 확장에 한계가 있음
• 배포 복잡성 : 작은 변경사항도 전체 애플리 케이션을 재배포해야 함

MSA (MicroService Architecture)

서비스를 비지니스 경계에 맞게 세분화 하고, 서비스 간 통신은 네트워크 호출을 통해 진행하여, 확장 가능하고 회복적이며 유연한 어플리케이션을 구성하는 것

특징 :

• 분산된 서비스 : 각 서비스는 독립적으로 개발, 배포, 운영됨
• 언어 및 기술의 다양성 : 서비스마다 다른 프로그래밍 언어와 기술 스택을 사용할 수 있음
• 수평적 확장(스케일아웃) : 서비스를 여러 서버에 분산시켜 확장

장점 :

• 유연성 및 확장성 : 개별 서비스를 독립적으로 확장 및 개선할 수 있음
• 기술적 다양성 : 다양한 기술과 언어의 조합이 가능
• 장애 격리 : 하나의 서비스에 문제가 생격도 전체 시스템에 영향을 미치지 않음

단점 :

• 복잡한 관리 및 운영 : 서비스가 많아질수록 관리가 복잡해짐
• 네트워크 지연 : 서비스 간 통신이 네트워크를 통해 이루어지기 떄문에 지연이 발생할 수 있음
• 데이터 일관성 유지 : 분산된 서비스에서 데이터 일관성을 유지하는 것이 어려울 수 있음
• 서비스 간의 복잡한 통신 : 서비스가 서로 의존하게 되면 통신이 복잡해질 수 있으며, 이는 시스템의 전체적인 복잡도를 증가시킴

Monolithic vs MSA

• 개발 및 유지 관리 : 모놀리식은 초기 개발과 유지 관리가 비교적 간단하지만, 시스템이 커지면 복잡해짐. 반면, MSA는 초기에 구축 및 관리가 복잡하지만, 장기적으로 더 유연하고 확장 가능

• 확장성 : 모놀리식은 주로 수직적 확장(스케일 업)에 의존하지만, 이는 비용과 성능의 한계를 가질 수 있음. MSA는 수평적 확장(스케일 아웃)을 통해 트래픽 증가에 더 잘 대응할 수 있음

• 부하 분산 : MSA는 각 서비스가 독립적으로 부하를 관리할 수 있어, 특정 서비스에 문제가 발생해도 전체 시스템에 영향을 미치지 않음 모놀리식 구조에서는 한 부분의 문제가 전체 시스템에 영향을 줄 수 있음

• 기술 스택 : MSA는 다양한 기술, 언어, 데이터베이스 시스템을 혼합하여 사용할 수 있어 기술적 유연성을 제공. 반면, 모놀리식은 일반적으로 단일 기술 스택에 제한

선택 기준

• 프로젝트 규모와 복잡성 : 작고 단순한 프로젝트의 경우 모놀리식이 더 적합할 수 있음. 반면, 대규모 및 복잡한 시스템은 MSA로 이점을 얻을 수 있음
• 팀 구조 : 분산된 팀이나 여러 팀이 협업하는 경우, MSA가 각 팀이 독립적으로 작업할 수 있는 유연성을 제공
• 비지니스 요구사항 : 빠른 시장 출시와 빈번한 업데이트가 필요한 경우 MSA가 더 적합할 수 있음

출처 : https://www.youtube.com/watch?v=8d4h7K_Fq-0 https://www.youtube.com/watch?v=ZRpsB3ODr6M

< 그림 1 : https://velog.io/@dldydrhkd/모놀리식-아키텍처 > < 그림 2 : YouTube - Naver Cloud Platform : [Talk&Talk] 누구나 쉽게 이해할수 있는 마이크로서비스 아키텍처(MSA) > < 그림 3 : YouTube - 코딩애플 : 마이크로서비스가 뭔데 유행임 >

React 앱 빌드

• 목적 : 프로덕션 환경에 배포하기 위해 React 앱을 최적화하고, 모든 필요한 파일을 하나의 디렉토리에 모으는 것
• 방법 :
  • 이 명령은 코드를 최소화(minification)하고, 모든 정적 파일을 build 디렉토리에 모음

    npm run build # or yarn build

• 주의사항 :
  • 환경 변수 (예: API 엔드포인트)는 프로덕션 환경에 맞게 설정해야 함

Java Spring Boot 앱 패키징

• 목적 : Spring Boot 앱을 자가 실행 가능한 JAR 또는 WAR 파일로 패키징하여 배포 준비
• 방법 :
  • 패키징 과정에서 필요한 모든 의존성을 포함하는 실행 가능한 JAR 파일이 생성

    mvn package # Maven 사용 시
    gradle build # Gradle 사용 시

• 주의사항 :
  • 프로덕션 환경에 맞는 데이터베이스 설정, 포트 설정 등의 환경 설정이 필요

배포 지원 도구 : AWS, Heroku, Docker

AWS (Amazon Web Services)

배포를 위한 공간만 대여, 프로젝트에 관한 모든 셋팅을 직접 해야함 -> IaaS

• 장점 :
  • 높은 확장성과 유연성
  • EC2, S3, RDS 등 다양한 서비스 제공
  • 비용이 저렴
• 단점 :
  • 설정과 관리가 복잡함

Heroku

완성형 서버 배포 플랫폼, 코드만 있다면 도메인(URL)과 기타 자원들을 제공 -> Paas

• 장점 :
  • 사용이 간편하고 빠른 배포 가능
  • 무료 티어 제공
• 단점 :
  • 확장성과 커스터마이징에 제한 (패키지 버젼 ...)
  • 비용이 비쌈

Docker

소프트웨어 컨테이너화 플랫폼, 어떤 환경이든 일관된 동작을 보장, 클라우드 서비스 모델보다는 개발 및 배포의 효율성을 높이는 기술

• 장점 :
  • 환경 일관성 보장
  • 여러 환경에서 쉽게 배포 가능
• 단점 :
  • 컨테이너 관리에 대한 추가 지식 필요
  • 보안 설정에 주의 필요

CI/CD 파이프라인: Jenkins, GitHub Actions

CI/CD (Continuous Integration, 지속 통합 / Continuous Deployment, 지속배포)

Jenkins

Java로 작성된 오픈소스 자동화 서버이며, CI/CD 파이프라인을 구축하는 데 널리 사용

• 장점 :
  • 강력한 자동화와 커스터마이징 가능
  • 다양한 플러그인 제공
• 단점:
  • 설정과 관리가 복잡함
  • 초기 설정에 시간 소요

GitHub Actions

GitHub의 CI/CD 플랫폼으로, GitHub 저장소를 기반으로 소프트웨어 개발 워크플로우를 자동화

• 장점 :
  • GitHub 저장소와 통합 용이
  • 간단하고 빠른 설정
• 단점 :
  • 복잡한 워크플로우에 한계
  • Jenkins에 비해 대규모 시스템에서 제한적

목적

• 캐시는 웹 리소스를 로컬에 저장하여 빠르게 접근할 수 있게 하는 기술
• 이를 통해 네트워크 트래픽을 줄이고, 로딩 시간을 단축

동작 방식

• 클라이언트가 웹 리소스를 요청할 때, 캐시된 버전이 있는지 먼저 확인
• 캐시된 버전이 최신이면, 서버에 다시 요청할 필요 없이 즉시 해당 리소스를 제공

캐시가 없을 떄

1. 클라이언트가 서버에 이미지를 요청
2. 서버는 이미지의 HTTP 헤더(0.1M) + 바디(1.0M)를 합쳐 1.1M정도 용량의 데이터를 응답
3. 클라이언트는 이미지 응답을 받아 사용
4. 클라이언트가 이미지를 또 요청하면 1~3번 반복

• 문제점

  • 동일한 이미지를 요청하는데 네트워크를 통해 같은 데이터를 또 다운받는다
  • 용량이 클 수록 비용이 커지고 브라우저의 로딩속도가 느려진다
    • 인터넷 네트워크는 매우 느리고 비쌈

캐시 적용

1. 클라이언트가 서버에 이미지를 요청
2. 서버가 헤더에 cache-control:max-age=60 속성을 넣어주어 이미지를 응답
3. 클라이언트가 이미지 응답을 받아 사용
4. 클라이언트가 다시 요청할 떄, 캐시를 조회
5. 캐시가 존재하는 60초 이내의 경우 해당 캐시에서 자료를 가져옴

• 장점

  • 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
  • 비싼 네트워크 사용량을 줄일수 있음
  • 브라우저 로딩 속도가 매우 빠름

2. 검증 헤더와 조건부 요청

캐시 시간 초과

• 캐시 유효 시간이 초과해서 서버에 다시 요청
  1. 서버 데이터가 변경 됨
  2. 데이터가 변경 되지 않고 기존과 같음

검증 헤더

• 캐시 만료후에 서버 데이터가 변경되지 않았다면 저장했던 캐시를 재사용 가능
• 이 때, 클라이언트/서버의 데이터가 바뀌지않고 같다는것을 확일 할 때 사용하는 것이 검증 헤더

Last-Modified 와 if-modified-since

동작 방식

• 클라이언트가 서버에 데이터 요청
• 서버가 Last-Modified: 2023년 11월 16일 10:00:00를 헤더에 추가해서 데이터 응답
• 클라이언트가 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 같이 저장
• 캐시 만료 후, 다시 요청할 때 if-modified-since: 2023년 11월 16일 10:00:00 를 요청헤더에 담아서 서버에 요청
• 서버에서 상태코드는 304 Not Modified로 변경된것이 없다는 것을 알림
  • Body가 없으므로 헤더만 전송해서 네트워크 비용 부담이 줄어듬
• 데이터가 변경 되었다면 200 OK 와 새로운 Last-Modified 그리고 Body를 함께 보냄

단점

• 1초 미만 단위 캐시 조정 불가
• 날짜 기반 로직 사용
• 데이터를 수정해 날짜가 다르지만, 같은 데이터를 수정해 데이터 결과가 똑같은 경우
  • test.txt 파일의 내용을 A → B로 수정했지만, 다시 B → A로 수정한 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  • 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag 와 If-None-Match

서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag 를 사용하면 된다

ETag (Entity Tag)

• ETag: "v1.0", ETag: "kmskmskms"
• 데이터가 변경되면 이 이름을 바꾸어서 변경한다 (Hash를 다시 생성)
• ETag:"aaaa" → ETag:"bbbb"
• 단순하게 ETag만 보내서 같으면 유지하고 바르면 다시 받는다

동작 방식

• 클라이언트가 서버에 데이터 요청
• 서버가 헤더에 ETag를 추가해서 응답
• 클라이언트에 ETag도 함게 캐시에 저장
• 캐시 만료후 If-None-Match:aaaa 를 요청 헤더에 작성해서 요청
• 서버에서 데이터가 변경되지 않았을 경우 ETag는 동일, If-None-Match는 실패로 304 Not Modified를 응답
  • 이 때, Body는 없다
• 클라이언트는 응답 결과를 재사용하고 헤더 데이터를 갱신해 캐시에 저장

목적과 중요성

• HTTP 헤더는 웹 통신에서 필수적인 역할. 이들은 클라이언트와 서버 간의 통신을 매개하고, 데이터 전송에 필요한 정보를 제공
• HTTP 헤더를 통해 클라이언트는 요청의 세부 사항을 서버에 전달하고, 서버는 응답의 성격과 콘텐츠를 클라이언트에게 전달할 수 있음. 이러한 헤더는 웹의 성능, 보안, 그리고 사용자 경험에 직접적인 영향을 미침

헤더의 유형 소개

HTTP 헤더는 크게 네 가지 주요 유형으로 구분

1. 일반 헤더 (General Header): 요청과 응답 양쪽 모두에 공통적으로 적용되는 헤더로, 메시지의 전반적인 속성과 통신 세션 관리에 관련된 정보를 담
2. 표현 헤더 (Representation Header): HTTP 메시지의 본문(페이로드)에 대한 정보를 제공하며, 본문의 타입, 언어, 인코딩 등을 설명
3. 요청 헤더 (Request Header): 클라이언트가 서버로 보내는 요청에 특화된 정보를 담습니다. 이 헤더는 요청의 종류, 클라이언트의 선호도 등을 서버에 알림
4. 응답 헤더 (Response Header): 서버가 클라이언트에게 보내는 응답에 특화된 정보를 담습니다. 이 헤더는 응답의 상태, 서버 정보 등을 클라이언트에 제공

2. 헤더 유형의 상세 설명

2.1 일반 헤더 (General Header)

일반 헤더는 요청과 응답 모두에 적용되며, 메시지의 전체적인 속성과 통신 세션을 관리하는 데 사용

• Cache-Control: 캐싱 메커니즘을 지정
  • ex : no-cache, max-age=3600.
• Connection: 현재의 연결에 대한 옵션을 지정
  • ex : keep-alive, close.
• Date: 메시지가 생성된 정확한 날짜와 시간을 나타냄

2.2 표현 헤더 (Representation Header)

표현 헤더는 요청과 응답 모두에 적용되며, 메시지의 본문의 내용과 데이터 형식을 표현 (Entity Header)

• Content-Type: 메시지 본문의 미디어 타입을 지정
  • ex : Content-Type:text/html, application/json, image/png.
• Content-Encoding: 메시지 본문이 어떻게 인코딩되었는지 나타냄, 압축과 압축 해제
  • ex : Content-Encoding:gzip, deflate.
• Content-Language: 메시지 본문의 자연 언어를 지정
  • ex : Content-Languauge: ko, en, fr.
  • Content-Length: 메시지 본문의 길이
  • ex : Content-Length: 5

2.3 요청 헤더 (Request Header)

요청 헤더는 클라이언트가 서버에 보내는 HTTP 요청에 대한 정보를 포함

• Host: (필수) 요청이 전송되는 대상 서버의 이름과 포트를 지정
• User-Agent: 클라이언트의 애플리케이션, 운영 체제, 브라우저 및 버전 정보를 제공
• Accept: 클라이언트가 처리할 수 있는 미디어 타입을 명시
  • Accept-Charset, Accept-Encoding, Accept-Language
• Authorization: 클라이언트가 인증 토큰을 서버로 보낼 때 사용
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장, 요청 시 서버로 전달
• Referer: 클라이언트의 이전 웹 페이지 주소, 유입 경로 등을 분석 가능

2.4 응답 헤더 (Response Header)

응답 헤더는 서버가 클라이언트에게 보내는 HTTP 응답에 대한 정보를 포함

• Server: 응답을 보내는 서버의 소프트웨어 및 버전 정보를 제공
  • ex : Server: nginx
• Location: 페이지 리다이렉션, 상태코드 3XX에서 사용
• Allow: 응답을 보내는 서버의 지원 가능한 HTTP 메서드 리스트
  • ex : Allow : GET, POST
• Status-Line: 응답의 상태를 나타내는 코드와 상태 메시지를 포함
  • ex : 200 OK, 404 Not Found.
• Set-Cookie: 클라이언트 브라우저에 쿠키를 설정하기 위한 지시어를 포함

OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

즉, 애플리케이션이 사용자가 사용하는 타사 애플리케이션 정보에 접근하기 위해 권한을 타사에게 받는 것

2. 등장 배경

가장 간단 한 방법은 사용자가 A Service를 통해 B service의 기능을 사용하고 싶을 때, 사용자는 A Service에게 B Service의 ID/PW 를 알려주는 것이지만, 이는 사용자와 B Service 모두 불만족스러운 방식이다.

이후, 구글은 AuthSub, 야후는 BBAuth 등 각각 기업에서 개발한 인증 방법을 사용했지만, 표준화 되어있지 않았기 때문에 구글이나 야후 등과 연동하려면 개별적으로 개발하고 유지보수 해야했다

이를 위해 등장한 것이 바로 OAuth 이다. 최초 1.0 버전은 2006년 트위터와 Ma.gnolia 가 주도적으로 개발하였다. 이후 1.0버전이 개선된 1.0a 버전이 출시되었으나 모바일 어플리케이션 등에서 안전하게 사용될 수 없는 사례가 존재했다. 이런 사례를 보완하고 기존 버전보다 조금 더 단순화한 OAuth 2.0 버전이 2012년에 등장하게 되었다

용어정리 :
사용자 : Resource Owner
B Service : Client
A Service : Resource Server, Authorization Server
Access Token : B Service가 필요로 하는 부분적인 기능만 허가

3. 동작원리

1. Client가 Resource Server에 사전 허가(등록)를 받는다.

• Client ID : 애플리케이션 식별자, 외부에 공개해도 됨
• Client Secret : ID에 대한 비밀번호, 절대 노출되면 안됨
• Authorized redirect URIs : 권한을 부여하는 과정에서 Authorized Code를 전달 받는 주소
• 

2. Resource Owner가 Resource Server의 기능을 원하면 Client는 Owner에게 인증을 받는다(로그인 등)

• https://url/?client_id=1&scope=A&redirect_uri="..." 으로 로그인 유도
• Server가 위 주소의 Client ID를 확인하고 있으면 진행, 없으면 무시
• 

3. Server가 Owner에게 Client에게 권한 위임 할 것인지 묻고 저장

4. Resource Server가 Owner에게 redirect uri를 통해 Authorization code를 전달한다

• Owner는 redirect uri로 옮겨지고 Client에게 Code를 전달한다
• 

5. Client가 Code, ID, Secret, redirect_uri의 조합으로 Resource Server에게 인증하고 Access Token을 발급받는다

6. Client가 발급받은 Access Token으로 Resource Server의 API를 사용하여 기능을 사용한다

7. Client는 Access Token을 발급 받을 때, Refresh Token을 함께 발급 받고, 모두 저장 해둔다

• 이후 Access Token이 만료되어 401 에러가 발생하면, Refresh Token을 보내 새로운 Access Token을 발급 받는다

참조 : https://ko.wikipedia.org/wiki/OAuth
생활코딩 Youtube

SOLID 란?

• 클린코드로 유명한 Robert C.Martin이 좋은 객체 지향 설계의 5가지 원칙(Software desing principls)을 정의

SRP : 단일 책임 원칙

Single Responsibility Principle

• 한 클래스는 하나의 책임만 가져야 한다
• 클래스를 수정할 때에는 오직 하나의 이유로 수정해야 한다
• 변경이 생겼을 떄 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

// SRP 위반
public class User {
  public User() {
    // User 생성자 로직
  }

  public saveUser {
    // 데이터베이스 저장 로직
  }
}

// SRP 준수
public class User {
  public User() {
    // User 생성자 로직
  }
}

public class UserDatabase {
  public saveUser {
    // 데이터베이스 저장 로직
  }
}

OCP : 개방 - 폐쇄 원칙

Open/closed Principle

• 가장 중요한 원칙이다

• 소프트웨어 개체는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
• 즉, 기존 코드를 변경하지 않으면서도 시스템의 기능을 확장 할 수 있어야 함
• 다형성을 활용

// override를 사용하여 기존 calculateArea()를 변경하지 않는다 (다형성)
public interface Shape {
    double calculateArea();
}

public class Rectangle implements Shape {
    public double length;
    public double width;

    @Override
    public double calculateArea() {
        return length * width;
    }
}

public class Circle implements Shape {
    public double radius;

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

LSP : 리스코프 치환 원칙

Liskov Substitution Principle

• 프로그램에서 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체해도 프로그램의 정확성이나 실행에 영향을 주지 않아야 한다
• 즉, 자식 클래스는 부모 클래스의 행동 방식을 완벽하게 모방할 수 있어야 하며, 자식 클래스의 객체는 부모 클래스의 객체로 예상되는 모든 역할을 수행할 수 있어야 한다
• 다형성에서 하위(자식) 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다

// LSP 위반
public class Bird {
    public void fly(){
    }
}

public class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ostrich can't fly.");
    }
}

Bird bird = new Ostrich();
bird.fly(); // 런타임 에러 발생, LSP 위반




// LSP 준수
public abstract class Bird {
    // 공통 기능
}

public class FlyingBird extends Bird {
    public void fly(){
        System.out.println("This bird can fly.");
    }
}

public class NonFlyingBird extends Bird {
    // 비행하지 않는 새를 위한 기능
}

public class Sparrow extends FlyingBird {
    // 참새는 날 수 있음
}

public class Ostrich extends NonFlyingBird {
    // 타조는 날 수 없음
}

FlyingBird sparrow = new Sparrow();
sparrow.fly(); // 문제없음

Bird ostrich = new Ostrich();
// ostrich.fly(); // 이 코드는 존재하지 않음. LSP 준수

ISP : 인터페이스 분리 원칙

Interface Segregation Principle

• 클라이언트는 사용하지 않는 메소드에 의존하면 안된다
• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
• 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
• 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
• 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
• 인터페이스가 명확해지고, 대체 가능성이 높아진다

// 운전 인터페이스
interface DrivingService {
    void drive();
}

// 정비 인터페이스
interface MaintenanceService {
    void fixEngine();
}

// 운전자 클라이언트
class Driver implements DrivingService {
    public void drive() {
        // 운전 기능 구현
    }
}

// 정비사 클라이언트
class Mechanic implements MaintenanceService {
    public void fixEngine() {
        // 엔진 수리 기능 구현
    }
}

DIP : 의존관계 역적 원칙

Dependency Inversion Principle

• 고수준 모듈이 저수준 모듈에 의존하지 않으며, 둘 다 추상화에 의존해야 한다
• 추상화에 의존해야지, 구체화에 의존하면 안된다
• 즉, 구현 클래스에 의존하지 말고, 인터페이스에 의존해라

// 추상화 인터페이스
interface Switchable {
    void turnOn();
    void turnOff();
}

// 저수준 모듈
class LightBulb implements Switchable {
    public void turnOn() {
        // 전구를 켬
    }

    public void turnOff() {
        // 전구를 끔
    }
}

// 고수준 모듈
class ElectricPowerSwitch {
    private Switchable device;

    public ElectricPowerSwitch(Switchable device) {
        this.device = device;
    }

    void press() {
        if (device != null) {
            device.turnOn();
        } else {
            device.turnOff();
        }
    }
}

정리

• 단일 책임 원칙은 코드를 간결하게 유지하는 데 도움
• 개방-폐쇄 원칙은 확장성을 부여
• 리스코프 치환 원칙과 인터페이스 분리 원칙은 코드의 유연성을 제공
• 의존관계 역전 원칙은 결합도를 낮추어 시스템의 독립성을 강화

1. 　3 & 4 Way HandShake 란?

• 클라이언트와 서버가 연결성립 및 연결해제를 하기위해 거치는 과정

2. 　TCP의 연결 성립

3 way handshake

• TCP는 신뢰성을 위해, 논리적인 접속을 성립시키기 위한 3단계의 과정을 거친다

  

1. SYN : 클라이언트가 서버에게 자신의 ISN을 담은 SYN 패킷을 보낸다

2. SYN + ACK : SYN을 수신한 서버는 서버의 ISN을 담은 SYN과 ACK(client SYN + 1)을 응답한다

3. ACK : 서버의 응답을 받은 클아이언트가 ACK(server SYN + 1)을 응답한다

• 위 세 단계를 거쳐 클라이언트와 서버의 연결이 성립된다

LISTEN : 서버는 CLOSED 상태에서 서버가 열린 상태 즉 LISTEN 상태여야 클라이언트의 요청을 받을 수 있다. ISN : TCP 기반 데이터 통신에서 각각의 새 연결에 할당된 고유한 32bits Sequence num
SYN : synchronization의 약자, 연결 요청 플래그
ACK : acknowledgement의 약자, 응답 플래그

3. 　TCP의 연결 해제

4 way handshake

• 모든 통신이 끝났다면 연결을 해제하기 위해 4단계의 과정을 거친다

  

1. 클라이언트가 서버에게 FIN 세그먼트를 보내고 FIN_WAIT_1 상태로 서버의 응답을 기다린다

2. FIN을 수신한 서버가 ACK 세그먼트를 응답하고 CLOSE_WAIT 상태가 된다.

　　 ACK를 받은 클라이언트는 FIN_WAIT_2 상태가 된다

3. 서버는 LAST_ACK 상태가 되었다가, 데이터를 모두 보낸 후 FIN 세그먼트를 보낸다

4. FIN을 수신한 클라이언트가 ACK를 서버에게 응답하고 TIME_WAIT의 상태로 남은 데이터를

　　기다리다가 Closed가 된다. 그리고 서버는 ACK를 수신한 즉시 Closed가 된다

위 네 단계를 거쳐 클라이언트와 서버의 연결이 해제된다

TIME_WAIT : 지연 패킷 등이 발생했을 때 데이터 무결성을 위해 패킷을 기다리는 시간. 2*MSL(최대 패킷 수명)

이미지 출처 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95#

1. TCP/IP 란?

TCP/IP는 "Transmission Control Protocol/Internet Protocol"의 약자로, 인터넷 네트워크 통신을 위한 프로토콜 집합입니다. 이 규칙들은 데이터가 인터넷을 통해 어떻게 전송되어야 하는지를 정의하며, 우리가 웹사이트에 접속하거나 이메일을 체크하는 등의 일상적인 온라인 활동을 가능케 합니다.

2. TCP/IP의 주요 구성요소

TCP/IP 모델은 크게 4개의 계층으로 구분됩니다. 각 계층은 특정한 목적을 가지고 있으며, 데이터 전송 과정을 단계적으로 나눠 처리합니다.

1. 네트워크 액세스 계층 (Network Access Layer)

• 이 계층은 하드웨어적인 영역입니다. 데이터 링크 계층(Data Link Layer)과 물리 계층(Physical Layer)으로 나뉘며, 네트워크 하드웨어와 네트워크 매체(예: 케이블, 스위치 등)에 대한 규격을 정의합니다.
• 이를 통해, 데이터가 네트워크를 통해 물리적으로 전달될 수 있는 경로를 만듭니다.

2. 인터넷 계층 (Internet Layer)

• 이 계층에서는 패킷이 생성되고, IP 주소를 이용하여 다른 네트워크로 전송할 수 있도록 라우팅을 합니다. 주요 프로토콜로는 IP (Internet Protocol), ARP (Address Resolution Protocol), ICMP (Internet Control Message Protocol) 등이 있습니다.
• IP 프로토콜은 패킷을 올바른 목적지로 전달하는 데 필요한 기능을 제공합니다.

3. 전송 계층 (Transport Layer)

• 이 계층에서는 통신을 활성화하기 위한 다양한 프로토콜을 사용합니다. 대표적으로 TCP (Transmission Control Protocol)와 UDP (User Datagram Protocol)가 있습니다.
• TCP를 통해 데이터가 정확하고 안전하게 전달되며, UDP는 데이터를 빠르게, 하지만 전송 확인 없이 보내는 데 사용됩니다.

4. 응용 계층 (Application Layer)

• 사용자가 네트워크에 접근할 수 있도록 인터페이스를 제공하는 계층입니다. 이메일, 파일 전송, 원격 로그인 등의 서비스를 사용자에게 제공합니다.
• 이 계층의 프로토콜 예로는 HTTP, FTP, SMTP, DNS 등이 있습니다.
  
  

Tip. OSI 7계층

TCP / IP 4계층은 OSI 7계층 모델로 설명하기도 합니다.

OSI 계층은 TCP / IP 애플리케이션 계층을 세 개로 쪼개고 링크 계층을

데이터 링크, 물리 계층으로 표현하고 인터넷 계층을 네트워크 계층으로

부른다는 차이점만 있을 뿐 기능은 동일합니다.

3. TCP와 UDP?

TCP와 UDP의 주요 차이점

TCP와 UDP의 다양한 사용 사례

이 표로 볼 때, TCP는 신뢰성이 중요한 상황에서, UDP는 실시간 서비스가 필요한 상황에서 각각 필요한 프로토콜임을 알 수 있습니다. 각 프로토콜은 인터넷 환경의 다양한 요구를 충족시키기 위해 설계되었습니다.

4. 알아두면 좋은 Ports

* 프로토콜(Protocol) : 컴퓨터나 네트워크 장비가 서로 통신하기 위해 따라야 하는 규칙이나 절차

클라우드 서비스는 인터넷을 통해 제공되는 인프라, 플랫폼, 또는 소프트웨어를 말함
다른 회사의 공급자가 호스팅하여 사용자는 자체 인프라나 하드웨어 설치 없이 서비스를 이용할 수 있

1. 배포 방식의 변화

1.1. 전통적 배포방식

• 하나의 물리적 컴퓨터에 하나의 OS 설치
• 여러명의 사용자가 계정을 나눠 사용 가능
• 여러 프로그램 설치 가능, 하지만 상호 영향 존재

1.2. 가상화 배포방식

• 가상머신(VM): 하드웨어를 소프트웨어적으로 구현
• 계정을 나눈 것이 아니라 여러 개의 OS 구동
• CPU, RAM을 물리적으로 갈아끼는 것이 아니라 설정만으로 더 나은 자원 분리와 관리 제공
  

Hypervisor : 하나의 시스템 상에서 가상 컴퓨터를 여러 개 구동할 수 있도록 해 주는 중간 계층을 의미하며 이 위에 여러개의 가상머신을 구축할 수 있고 가상머신 위에 OS와 그 위에 앱이 올라가는 형태로 가상머신을 독립적으로 수행할 수 있음

1.3.오프프레미스 vs 온프레미스

• 오프프레미스 (off-premise): 클라우드 서비스를 통해 인프라 관리 부담 감소
  • 전력, 위치, 서버 세팅, 확장성을 고민하지 않고 서비스 운영에만 집중이 가능
• 온프레미스 (on-premise): 자체 시설에서 직접 인프라를 관리
  • 직접 유지 관리하는 프라이빗 데이터 센터(IDC)
  • ex) 네이버 데이터 센터

2. 클라우드 서비스 모델

• IaaS (Infrastructure-as-a-Service)

  • 가장 기본적인 클라우드 서비스 모델
  • 사용자는 제공된 인프라 위에 원하는 소프트웨어를 자유롭게 설치, 관리
  • 플랫폼에 종속 되지않아, 유연성/이식성이 높지만 운영비 효율이 낮음
  • 예시: AWS EC2, Google Compute Engine

• PaaS (Platform-as-a-Service)

  • 인프라와 함께 플랫폼 제공
  • 사용자는 애플리케이션 개발에 집중, 나머지 관리는 클라우드가 수행
  • 플램폿에 종속되어, 유연성/이식성이 낮지만 운영이 효율이 좋다
  • 모니터링, CI/CD가 제공 됨
  • 예시: Heroku, Google App Engine

    CI/CD (Continuous Integration/Delivery & Deployment)

    • 코드 변경 사항을 지속적으로 합치고 자동으로 배포하는 프로세스
    • 개발 생산성 및 배포의 신뢰성 향상

• SaaS (Software as a Service)

  • 완전한 소프트웨어 솔루션을 클라우드 서비스로 제공
  • 사용자는 서비스를 바로 사용할 수 있음
  • 예시: Google Docs, Microsoft 365

3. 컨테이너와 도커

3.1. 컨테이너

• 코드와 종속성을 함께 패키징하여 다양한 컴퓨팅 환경에서 빠르고 안정적이게 실행 가능
• OS를 공유하여 경량화와 빠른 실행을 제공
• OS에 문제가 생기면 다른 앱에도 영향을 미칠 수 있음

3.2. 도커 (Docker)

• 컨테이너의 생성, 배포, 실행을 도와주는 플랫폼

• 도커파일로부터 도커이미지를 생성, 이를 통해 도커컨테이너 실행

• 서버 환경 구성을 이미지로 관리, 빠르고 일관된 배포 가능

  1. 도커파일 : 패키지, 환경변수설정 등을 기록한 파일. 이를 빌드해 도커이미지로 변환
  2. 도커이미지 : 컨테이너 실행에 필요한 파일과 설정값, 데이터 등을 포함된 상태값이며 불변. 하나의 이미지에서 여러개의 컨테이너를 생성할 수 있으며 컨테이너의 상태와는 무관하게 이미지는 그대로 존재. 예를 통해 1대의 서버에 환경설정해야 한다면 미리 만들어 놓은 이미지를 다운받아서 이를 통해 컨테이너만 만들면 끝
  3. 도커컨테이너 : 컨테이너가 실행시키면 도커이미지에 설정된 프로그램, 데이터 등이 실제 컴퓨팅자원과 연결

도커의 활용

• 대규모로 운영되는 서비스에서 컨테이너를 통한 배포가 일반화
• 구글은 매주 약 20억 개의 컨테이너를 도커를 통해 관리 (2014년도)

참조 : https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95/dashboard

1. 기본 개념

* 클라이언트 (Client)

• 서비스나 리소스를 요청하는 컴퓨터나 소프트웨어를 의미. 웹 브라우징을 할 때 사용하는 브라우저(예: Chrome, Firefox)는 웹 서버에 페이지를 요청하는 클라이언트 역할

• 기능

  • 용자 인터페이스 제공
  • 사용자의 요청을 서버에 전송,
  • 서버로부터 받은 데이터나 리소스를 사용자에게 표시

* 서버 (Server)

• 클라이언트의 요청에 따라 데이터나 리소스를 제공하는 컴퓨터나 소프트웨어를 의미

• 기능

  • 클라이언트의 요청 처리
  • 필요한 데이터나 리소스 제공
  • 다수의 클라이언트 요청 관리

* 클라이언트-서버 상호 작용

클라이언트는 서버에 특정 정보나 서비스를 요청하고, 서버는 해당 요청에 대한 응답을 클라이언트에게 전송한다. 이러한 요청-응답 메커니즘이 클라이언트-서버 모델의 기본 구조다.

* 정적 컨텐츠 (Static Content)

서버에 저장된 그대로의 형태로 전달되며, 사용자의 요청이나 입력에 따라 그 내용이 변경되지 않는 데이터나 파일을 의미

HTML, CSS, JavaScript 파일 같이 컴퓨터에 저장된 파일 등

• 특징
  • 사용자마다 다르게 표시되지 않는다.
  • 웹 서버만으로 처리 가능하다.

* 동적 컨텐츠 (Dynamic Content)

사용자의 요청, 입력, 서버의 로직에 따라 실시간으로 생성되거나 변경되는 컨텐츠를 의미

뉴스 웹사이트의 기사 목록, 온라인 쇼핑몰의 재고 정보, 사용자 프로필 페이지 등

• 특징
  • 사용자의 요청이나 상황에 따라 내용이 바뀐다.
  • 데이터베이스와의 연동이 필요할 수 있다.

클라이언트의 요청 - 웹 서버 처리 - WAS 처리 - 응답 - 클라이언트의 출력

2. Web Server

웹 서버는 클라이언트로부터 HTTP 요청을 받아 정적 컨텐츠(HTML, CSS, 이미지, 자바스크립트 파일 등)를 반환하는 서버

• 기능
  • 정적 컨텐츠 제공
  • HTTP 프로토콜을 기반으로 클라이언트의 요청에 대해 응답
• 대표적인 웹 서버 소프트웨어
  • Apach, Nginx, Microsoft's IIS

3. Web Application Server (WAS)

WAS는 동적 컨텐츠를 처리하기 위해 필요한 비즈니스 로직을 실행하는 서버.

데이터베이스와의 통신, 복잡한 계산 등을 처리하며, 그 결과를 웹 서버를 통해 클라이언트에게 전달.

• 기능
  • 동적 컨텐츠 처리 및 제공
  • 비즈니스 로직 수행
  • 데이터베이스 연결 및 데이터 처리
• 대표적인 WAS 소프트웨어
  • Tomcat, JBoss, WebSphere

4. Web Server vs WAS

4.1. 유사점

• 클라이언트-서버 모델: 둘 다 클라이언트-서버 모델을 기반으로 클라이언트의 요청을 처리하고 응답
• HTTP 프로토콜: 대부분의 웹 서버와 WAS는 HTTP 또는 HTTPS 프로토콜을 사용하여 통신

4.2. 차이점

• 컨텐츠 처리 방식: 웹 서버는 주로 정적 컨텐츠를 처리하며, WAS는 동적 컨텐츠를 처리
• 웹 서버는 파일 시스템에서 컨텐츠를 읽어 클라이언트에게 전달하는 것이 주 기능. 반면, WAS는 애플리케이션 로직을 실행하고 데이터베이스와 통신하는 등의 복잡한 작업을 수행
• 자원 사용량: 일반적으로 WAS는 웹 서버에 비해 더 많은 자원(CPU, 메모리 등)을 사용

4.3. 사용예시

• 웹 서버

  • 정적 웹사이트나 애플리케이션에서는 웹 서버만으로 충분 (빠르다)
  • 콘텐츠 전송 네트워크(CDN) 같은 환경에서는 주로 웹 서버가 사용
  • 로드 밸런싱 및 리버스 프록시로 동작하는 경우에도 웹 서버를 사용

• WAS

  • 동적 컨텐츠를 처리해야 하는 웹 애플리케이션에서는 WAS가 필요 (비교적 느리다)
  • 사용자의 입력을 기반으로 데이터베이스에서 정보를 가져와서 페이지를 생성해야 하는 경우 WAS를 사용
  • 로그인, 쇼핑카트, 게시판 기능 등의 동적 기능이 포함된 사이트나 애플리케이션에서 WAS를 사용
  • 대부분의 현대 웹 애플리케이션 환경에서는 웹 서버와 WAS가 협업하여 서비스를 제공. 웹 서버는 정적 컨텐츠를 처리하고, 동적 컨텐츠 요청은 WAS로 전달하여 처리

5. 중요성

• 마이크로서비스 아키텍처: 웹 서버와 WAS의 역할 분리가 더욱 중요해진 이유
  • 확장성, 결함 격리, 유지보수, 기술 스택 자유도
• 서버리스 아키텍처: WAS의 발전과 관련된 최신 기술 트렌드
  • 자동 확장, 비용 효율성, 운영 부담 감소

0. 스케줄링이란 무엇인가?

• 처리 해야 할 일(프로세스)들 사이에 순서를 정해서 CPU(중앙처리장치)를 사용할 수 있는 시간을 정해주는 것.
• 즉, 여러 프로세스 중 어느 것을 먼저 실행할지 결정하는 방법론

프로세스의 상태

1. 왜 운영체제에서 스케줄링이 중요한가?

• 다중 프로그래밍 환경에서는 여러 프로세스가 동시에 메모리에 있기 때문에, 효과적인 CPU 사용을 위해 어떤 프로세스를 언제 실행할지 결정하는 기능이 필요
• 스케줄링은 시스템 성능, 공정성, CPU 사용률, 응답 시간 등 다양한 요소를 최적화하는데 큰 역할

2. 스케줄링의 목적

• 시스템의 성능 향상 (오버헤드 ↓ / 사용률 ↑ / 기아 현상 ↓)
  • 성능 지표
    1. 자원 활용도 (resource utilization) : 주어진 시간동안 자원이 활용된 시간
    2. 작업처리량 (throughput) : 단위 시간 동안 완료된 작업의 수
    3. 응답시간 (respoinse time) : 작업 요청으로부터 응답을 받을때 까지의 시간

3. 스케줄링 알고리즘 소개

• 비선점(nonpreemeptive) : CPU 제어권을 뻇을 수 없음

  • FCFS (First Come, First Served)

    • 가장 먼저 온 프로세스를 먼저 처리 (= Queue)
    • 장점: 구현이 간단
    • 단점: 짧은 작업이 긴 작업 뒤에 대기할 경우, 평균 대기 시간이 증가 (Convoy effect)

  • SJF (Shortest Job First)

    • 원리: 실행 시간이 가장 짧은 프로세스부터 실행
    • 장점: 평균 대기 시간이 가장 짧음
      • 실제로는 알 수 없기 떄문에 과거의 실행했던 시간을 토대로 추측
    • 단점: 실행 시간 예측이 어려움, Starvation 문제 발생 가능

  • 우선순위 (Priority)

    • 원리: 각 프로세스에 우선순위를 부여하고 높은 우선순위를 가진 프로세스부터 실행
    • 장점: 중요한 작업을 먼저 처리 가능
    • 단점: 낮은 우선순위의 프로세스가 무한정 대기하는 Starvation 문제 발생 가능

• 선점(preemeptive) : CPU 제어권을 뻇을 수 있음 (현대 운영체제가 쓰는 방식)

  • 라운드 로빈 (Round Robin)

    • 원리: 각 프로세스에 동일한 시간 할당 (Time Quantum) 후 순환
    • 장점: 공정하게 모든 프로세스에 CPU 시간 할당
    • 단점: Time Quantum 설정에 따라 성능이 크게 달라짐

  • SRF (Shortest Remaining Time First)

    • 원리 : 실행 중인 프로세스의 남은 실행 시간과 새로 도착한 프로세스의 실행시간을 비교하여 짧은 것 부터 실행
    • 장점 : 응답 시간 최적화, 대기 시간 최소화, Starvation 현상 감소
    • 단점 : 잦은 Context Switching, 예측 가능성 감소, Starvation 여전히 발생 가능

  • 다단계 큐(Multilevel Queue)

    • 원리: 여러 개의 큐를 사용하고 각 큐마다 다른 스케줄링 전략 적용, 큐 끼리는 우선순위와 라운드 로빈 방식 적용
    • 장점: 다양한 종류의 프로세스들을 효율적으로 관리 가능
    • 단점: 큐 설정과 스케줄링 전략 결정이 복잡

4. 스케줄링과 현대 운영체제

• 현대 운영체제에서의 스케줄링 방식
  • 현대의 운영체제, 특히 서버 환경에서는 여러 사용자와 태스크를 동시에 처리해야 하므로, 스케줄링의 중요성이 더욱 강조
• 클라우드 컴퓨팅, 가상화 기술과 스케줄링
  • 클라우드 환경에서는 여러 클라이언트의 요청을 동시에 처리해야 하며, 가상화 기술을 사용하여 물리적 자원을 최대한 효율적으로 활용해야 함. 이러한 환경에서 스케줄링은 리소스 할당과 가상 머신간의 작업 분배에 큰 역할을 함

용어 정리 

기아 현상(Starvation) : 특정 프로세스가 자원을 얻지 못하고 무한히 대기하는 상태
시간 할당량(Time Quantum) : 각 프로세스에 할당되는 고정된 시간 단위, 프로세스는 이시간동안만 CPU사용
문맥 교환(Context Switching) : CPU를 사용하는 프로세스의 전환이 발생할 떄 하는 작업

1. 프로세스 (Process)

👉🏻 컴퓨터의 메모리에 올라와 실행되고 있는 프로그램, 작업(task)와 같은 의미

• 프로그램이 메모리에 올라가면 프로세스가 되는 인스턴스화가 일어나고, CPU의 스케쥴링 대상이 됨
• 싱글스레드 프로세스, 멀티스레드 프로세스로 나뉨

프로세스 제어 블록(Process Control Block, PCB) :

• PCB 는 특정 프로세스에 대한 중요한 정보를 저장 하고 있는 운영체제의 자료구조이다. 운영체제는 프로세스를 관리하기 위해 프로세스의 생성과 동시에 고유한 PCB 를 생성 한다. 프로세스는 CPU 를 할당받아 작업을 처리하다가도 프로세스 전환이 발생하면 진행하던 작업을 저장하고 CPU 를 반환해야 하는데, 이때 작업의 진행 상황을 모두 PCB 에 저장하게 된다. 그리고 다시 CPU 를 할당받게 되면 PCB 에 저장되어있던 내용을 불러와 이전에 종료됐던 시점부터 다시 작업을 수행한다.

👉🏻 프로세스의 데이터 구조

2. 스레드 (Thread)

👉🏻 프로세스 내에서 실행되는 가장 작은 흐름의 단위

• 스레드 ID, 프로그램 카운터(PC), 레지스터 집합 그리고 스택으로 구성
• 프로세스는 여러개의 스레드를 가질수 있음
• 메모리 영역을 각각 생성하는 프로세스와는 달리 스레드는 코드, 데이터, 힙은 스레드끼리 서로 공유, 스택 영역은 각각 생성됨.

🤔 스택을 스레드마다 독립적으로 할당하는 이유

• 스택은 함수 호출 시 전달되는 인자, 되돌아갈 주소값 및 함수 내에서 선언하는 변수 등을 저장하기 위해 사용되는 메모리 공간이므로 스택 메모리 공간이 독립적이라는 것은 독립적인 함수 호출이 가능하다는 것이고 이는 독립적인 실행 흐름이 추가되는 것이다. 따라서 스레드의 정의에 따라 독립적인 실행 흐름을 추가하기 위한 최소 조건으로 독립된 스택을 할당한다.

3. 멀티프로세싱 & 멀티스레딩

🖥️ 멀티프로세싱

여러 개의 프로세스를 사용하여 여러 작업을 동시에 처리하는 기술, 프로세스는 독립적인 메모리 영역과 시스템 리소스를 가지고 있음

👍🏻 장점

• 안정성 : 하나의 프로세스에 문제가 생겨도 다른 프로세스에 영향을 미치지 않음
• 보안 : 각 프로세스는 자신의 메모리 공간을 가지므로, 하나의 프로세스가 다른 프로세스의 메모리에 접근하는 것이 기본적으로 제한
• CPU 활용 : 멀티코어 또는 다중 프로세서 시스템에서, 멀티프로세싱은 여러 CPU/코어에서 프로세스를 병렬로 실행할 수 있게 해서 자원을 효율적으로 활용할 수 있습니다.

👎🏻 단점

• 자원 소비 : 각 프로세스는 독립적인 메모리 공간과 시스템 리소스를 가지고 있기 때문에, 많은 양의 시스템 리소스를 소비할 수 있음
• 통신 복잡성 : 프로세스 간 통신(IPC)을 통해 수행되며, 이는 상대적으로 복잡하고 큰 비용을 지불 함

IPC(Inter-Process Communication) :

• 프로세서스끼리 데이터를 주고받고 공유데이터를 관리하는 메커니즘. 공유메모리, 파일, 소켓, 파이프, 메세지 큐가 있음
  • ex) 서버와 HTTP 통신해서 html 등의 파일을 가져오는 것도 IPC 라고 함

🖥️ 멀티스레딩

하나의 프로세스 내에서 여러 스레드를 사용하ㅕ 작업을 동시에 처리하는 기술, 모든 스레드는 프로세스의 메모리 영역을 공유

👍🏻 장점

• 자원 공유 : 스레드들은 메모리와 파일 등의 리소스를 공유하기 때문에, 시스템 리소스 요구량이 상대적으로 낮음
• 빠른 컨텍스트 스위칭 : 스레드 간의 컨텍스트 스위칭은 프로세스 간의 스위칭보다 훨씬 빠르며, 자원을 덜 사용함.
• 향상된 응답성 : 한 스레드가 블록되거나 긴 작업을 처리하는 동안, 프로세스는 다른 스레드를 계속 실행할 수 있어 응용 프로그램의 응답성이 향상됨

👎🏻 단점

• 동기화 : 스레드들이 리소스를 공유하기 때문에, 동기화 문제를 처리해야 함
• 안정성 문제 : 한 스레드에서 문제가 발생하면 전체 프로세스에 영향을 줄수 있음

⭐️ 프로세스 vs 스레드

0. 운영체제란 무엇인가 ??

운영체제(OS, Operating System)

하드웨어를 관리하고, 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 응용 프로그램과 하드웨어
간의 인터페이스로써 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공해줌

1. 운영체제의 종류

운영체제는 앞단의 어떤 인터페이스를 두느냐에 따라 GUI와 CUI로 나눌 수 있음

• GUI(Graphical User Interface)

  • '그래픽 사용자 인터페이스'를 의미
  • 아이콘, 버튼, 메뉴 등을 마우스, 터치스크린 등의 포인팅 장치로 조작함으로써 상호작용
  • windowOS, macOS등 현대의 OS가 이를 대표

    

• CUI(Character User Interface)

  • CLI(Command Line Interface)와 비슷하지만 CLI는 특정 명령어를 직접 입력하여 상호작용
  • '문자 사용자 인터페이스'를 의미
  • GUI처럼 그래픽 요소를 사용하지 않고, 사용자가 키보드만을 사용하여 문자를 기반으로 컴퓨터와 상호작용하는 인터페이스
  • MS-DOS가 대표적, 1994년 단종

    

2. 운영체제의 역할

운영체제의 커널이 담당

• 프로세스 관리
  • 프로세스, 스레드
  • 스케쥴링
  • 동기화
  • IPC 통신
• 저장장치 관리
  • 메모리 관리
  • 가상 메모리
  • 캐싱과 버퍼링
  • 파일 시스템
• 네트워킹
  • 프로토콜
• 보안과 엑세스
  • 사용자 인증
  • 접근권한 관리
• 장치 드라이버와 하드웨어 제어
  • 하드웨어
  • 입출력

3. 운영체제의 구조

• 유저 프로그램

• 인터페이스(GUI, CUI)

  • 위 설명으로 대체

• 시스템 콜 (system call)

  • 시스템 콜은 운영체제가 제공하는 프로그램이나 사용자에게 시스템 서비스를 요청하기 위한 인터페이스
  • 소프트웨어가 운영 체제의 커널 기능에 접근할 수 있는 수단을 제공함
  • 파일을 읽거나 쓰기, 프로세스를 생성하거나 종료하기, 메모리를 할당하거나 해제하기 등의 작업을 요청할 때 시스템 콜을 사용

• 커널 (Kernel)

  • 커널은 운영체제의 핵심 부분으로, 하드웨어와 직접적으로 상호 작용하며 시스템의 모든 중요한 관리업무를 수행
  • I/O 드라이버 : 입출력 드라이버를 통해 하드웨어 장치와 통신. 드라이버는 각 장치와 데이터를 주고받기 위한 특수코드를 포함
  • 파일 시스템 : 이는 디스크나 기타 저장 매체에 데이터를 어떻게 저장하고 관리할 것 인지를 결정하는 시스템의 일부임,
    파일 시스템은 파일 및 디렉토리의 생성/수정/삭제 등을 관리함
  • 하드웨어

🌟 Commit message를 규칙에 맞게 작성 해야 할 이유

• 더 좋은 commit log 가독성

• 더 나은 협업과 리뷰 프로세스

• 더 쉬운 코드 유지보수

🌟 Commit message 구조

Commit message는 제목, 본문, 꼬리말로 구성 제목은 필수 사항이며, 본문과 꼬리말은 선택사항

<type 타입>: <subject 제목>

<body 본문, 생략가능>

<footer 꼬리말, 생략가능>

ex) docs: Add ProcessThread.md
ex) fix(함수이름): ...

🌟 Type의 종류

• "type"은 프로젝트나 팀에서 사용하는 규칙이나 관례에 따라 달라집니다. 많은 오픈 소스 프로젝트나 팀들이 특정 커밋 메시지 규칙을 가지고 있으며, 이러한 규칙을 따르는 것이 좋습니다.
• 하지만 개인 프로젝트나 정해진 규칙이 없는 프로젝트에서는 원하는 대로 "type"을 정의하고 사용할 수 있습니다.

🌟 Commit message 7가지 규칙

1. 제목과 본문을 한 줄 띄어 구분해준다
2. 제목은 50자 이내로 작성한다
3. 제목 첫 글자는 대문자로 작성한다 (type이 아닙니다)
   • readme file modification ❌
   • Readme file modification ⭕️
4. 제목 끝에 마침표를 사용하지 않는다
   • Open the door. ❌
   • Open the door ⭕️
5. 제목은 명령문으로, 과거형을 사용하지 않고 간결하게 작성한다
   • I fixed the bug ❌
   • Fix the bug ⭕️
6. 본문의 각 행은 72자 이내로 작성한다 (줄 바꿈 사용)
7. 본문은 어떻게 보다 무엇을, 왜에 대하여 설명한다

예시