ERD(Entity Relationship Diagram)와 UML(Unified Modeling Language)은 모두 시스템 설계를 위한 다이어그램이지만, 각각 다른 목적과 관점에서 시스템을 표현합니다.

ERD (Entity Relationship Diagram)

정의

ERD는 데이터베이스 설계를 위한 다이어그램으로, 데이터베이스 내의 엔티티(Entity), 속성(Attribute), 관계(Relationship)를 시각적으로 표현합니다.

주요 구성 요소

1. 엔티티 (Entity)

• 데이터베이스에 저장될 실제 객체나 개념
• 예: 사용자, 주문, 상품, 게시글
• 표기: 사각형으로 표현

2. 속성 (Attribute)

• 엔티티의 특성이나 특징
• 예: 사용자의 이름, 이메일, 전화번호
• 표기: 타원형 또는 엔티티 내부에 나열

3. 관계 (Relationship)

• 엔티티 간의 연관성
• 예: 사용자와 주문 간의 "주문한다" 관계
• 표기: 다이아몬드 또는 선으로 표현

4. 관계의 카디널리티 (Cardinality)

• 1:1 (One-to-One): 한 엔티티가 다른 엔티티와 하나씩만 관계
• 1:N (One-to-Many): 한 엔티티가 여러 엔티티와 관계
• N:M (Many-to-Many): 여러 엔티티가 여러 엔티티와 관계

ERD 예시

[사용자] ----<주문한다>---- [주문]
  |                           |
  |                           |
[이름]                    [주문번호]
[이메일]                  [주문일자]
[전화번호]                [총액]

ERD의 특징

• 데이터 중심: 데이터 구조와 관계에 집중
• 정적 모델: 데이터베이스 스키마를 표현
• 구현 지향: 실제 데이터베이스 설계에 직접 활용
• 단순성: 비교적 간단한 표기법

사용 시나리오

• 데이터베이스 스키마 설계
• 데이터 모델링
• 데이터베이스 정규화/반정규화 설계
• 데이터 관계 분석

UML (Unified Modeling Language)

정의

UML은 소프트웨어 시스템 전체를 모델링하기 위한 표준화된 시각적 표기법으로, 객체 지향 설계를 중심으로 다양한 다이어그램을 제공합니다.

주요 다이어그램 유형

1. 구조 다이어그램 (Structure Diagrams)

시스템의 정적 구조를 표현

클래스 다이어그램 (Class Diagram)

• 클래스, 인터페이스, 속성, 메서드, 관계를 표현
• ERD와 유사하지만 메서드(동작)도 포함

컴포넌트 다이어그램 (Component Diagram)

• 시스템의 물리적 구성 요소 표현

배치 다이어그램 (Deployment Diagram)

• 하드웨어와 소프트웨어의 배치 구조 표현

2. 행위 다이어그램 (Behavior Diagrams)

시스템의 동적 동작을 표현

시퀀스 다이어그램 (Sequence Diagram)

• 객체 간 상호작용을 시간 순서로 표현

활동 다이어그램 (Activity Diagram)

• 워크플로우나 프로세스 흐름 표현

상태 다이어그램 (State Diagram)

• 객체의 상태 변화 표현

유스케이스 다이어그램 (Use Case Diagram)

• 시스템의 기능과 사용자 간의 상호작용 표현

UML 클래스 다이어그램 예시

┌─────────────┐
│   User      │
├─────────────┤
│ - userId    │
│ - name      │
│ - email     │
├─────────────┤
│ + login()   │
│ + logout()  │
└─────────────┘
       │
       │ 1
       │
       │ *
       ▼
┌─────────────┐
│   Order     │
├─────────────┤
│ - orderId   │
│ - orderDate │
│ - totalAmount│
├─────────────┤
│ + create()  │
│ + cancel()  │
└─────────────┘

UML의 특징

• 시스템 전체 모델링: 데이터뿐만 아니라 동작, 프로세스까지 표현
• 객체 지향: 클래스, 객체, 상속, 다형성 등 OOP 개념 반영
• 표준화: 국제 표준(ISO/IEC 19505)으로 정의
• 다양성: 14가지 이상의 다이어그램 유형 제공
• 복잡성: 다양한 표기법과 규칙

사용 시나리오

• 소프트웨어 아키텍처 설계
• 객체 지향 설계 및 분석
• 시스템 요구사항 분석
• 개발자 간 의사소통 도구
• 시스템 문서화

ERD vs UML 비교

목적과 관점

구성 요소 비교

관계 표현 비교

ERD의 관계

• 1:1, 1:N, N:M: 카디널리티 중심
• 관계의 의미보다는 데이터 연결에 집중

UML의 관계

• 연관 (Association): 일반적인 관계
• 상속 (Inheritance): IS-A 관계
• 집합 (Aggregation): HAS-A 관계 (약한 소유)
• 합성 (Composition): HAS-A 관계 (강한 소유)
• 의존 (Dependency): 사용 관계
• 구현 (Realization): 인터페이스 구현

복잡도와 학습 곡선

사용자 및 활용 분야

언제 무엇을 사용할까?

ERD를 사용하는 경우

1. 데이터베이스 설계 단계

   • 새로운 데이터베이스 스키마 설계
   • 기존 데이터베이스 구조 분석
   • 데이터 정규화/반정규화 설계

2. 데이터 중심 프로젝트

   • 데이터 웨어하우스 구축
   • 데이터 마이그레이션 계획
   • 데이터 관계 분석

3. 간단한 표현이 필요한 경우

   • 비개발자와의 소통
   • 빠른 프로토타이핑
   • 데이터 구조 중심의 논의

UML을 사용하는 경우

1. 소프트웨어 설계 단계

   • 객체 지향 설계
   • 시스템 아키텍처 설계
   • API 설계

2. 복잡한 시스템 개발

   • 대규모 소프트웨어 프로젝트
   • 여러 팀 간 협업
   • 시스템 문서화

3. 동작과 프로세스 표현이 필요한 경우

   • 비즈니스 로직 설계
   • 워크플로우 분석
   • 사용자 시나리오 정의

함께 사용하는 경우

많은 프로젝트에서 ERD와 UML을 함께 사용합니다:

1. ERD: 데이터베이스 스키마 설계
2. UML 클래스 다이어그램: 애플리케이션 레이어의 클래스 구조 설계
3. UML 시퀀스 다이어그램: 비즈니스 로직 흐름 설계

실제 예시 비교

사용자-주문 시스템을 ERD로 표현

┌──────────┐         ┌──────────┐
│  User    │         │  Order   │
├──────────┤         ├──────────┤
│ userId   │◄───1:N──│ orderId  │
│ name     │         │ userId   │
│ email    │         │ orderDate│
│ phone    │         │ totalAmt │
└──────────┘         └──────────┘

특징:

• 데이터 구조만 표현
• 속성(컬럼) 중심
• 관계의 카디널리티만 표시

사용자-주문 시스템을 UML로 표현

┌──────────────────┐
│      User        │
├──────────────────┤
│ - userId: int    │
│ - name: string   │
│ - email: string  │
│ - phone: string  │
├──────────────────┤
│ + login()        │
│ + logout()       │
│ + createOrder()  │
└──────────────────┘
        │
        │ 1
        │
        │ *
        ▼
┌──────────────────┐
│      Order       │
├──────────────────┤
│ - orderId: int   │
│ - orderDate: Date│
│ - totalAmount:   │
│   decimal        │
├──────────────────┤
│ + create()       │
│ + cancel()       │
│ + calculateTotal()│
└──────────────────┘

특징:

• 데이터 + 메서드(동작) 포함
• 접근 제어자 표시 (-: private, +: public)
• 데이터 타입 명시
• 객체 지향 개념 반영

도구 추천

ERD 도구

• dbdiagram.io: 웹 기반, 간단하고 직관적
• MySQL Workbench: MySQL 전용, 무료
• ERwin: 전문 데이터 모델링 도구
• Lucidchart: 다양한 다이어그램 지원

UML 도구

• PlantUML: 텍스트 기반, 버전 관리 용이
• StarUML: 무료, 다양한 UML 다이어그램 지원
• Enterprise Architect: 전문 모델링 도구
• draw.io (diagrams.net): 무료, 웹 기반

결론

ERD와 UML은 서로 다른 목적을 가진 모델링 도구입니다:

• ERD: 데이터베이스 설계에 특화된 데이터 중심 모델링
• UML: 소프트웨어 시스템 전체를 표현하는 객체 지향 모델링

프로젝트의 성격과 목적에 따라 적절한 도구를 선택하거나, 두 가지를 함께 활용하여 시스템을 다각도로 설계할 수 있습니다.

핵심 차이점 요약:

1. ERD는 데이터 구조에 집중, UML은 데이터 + 동작에 집중
2. ERD는 단순하고 직관적, UML은 복잡하지만 표현력이 풍부
3. ERD는 데이터베이스 설계자에게, UML은 소프트웨어 개발자에게 더 친숙
4. ERD는 정적 모델, UML은 정적 + 동적 모델 모두 표현 가능

참고

• ERD (Entity Relationship Diagram) 개념 및 표기법
• UML (Unified Modeling Language) 표준 사양
• 데이터베이스 설계 방법론
• 객체 지향 설계 원칙
• 소프트웨어 아키텍처 패턴

개요

반정규화는 정규화된 데이터베이스 구조에서 성능 향상이나 특정 목적을 위해 의도적으로 정규화 규칙을 완화하는 데이터베이스 설계 기법입니다.

반정규화의 목적

1. 성능 최적화

• JOIN 연산 감소: 여러 테이블을 조인하는 대신 하나의 테이블에서 데이터를 조회
• 쿼리 속도 향상: 자주 조회되는 데이터를 중복 저장하여 조회 시간 단축
• 읽기 성능 개선: 읽기 중심의 애플리케이션에서 특히 효과적

2. 비즈니스 요구사항 충족

• 보고서 생성 최적화: 복잡한 집계 쿼리 대신 미리 계산된 값 저장
• 실시간 통계: 자주 변경되는 통계 데이터를 별도 컬럼으로 관리
• 데이터 접근 패턴 반영: 실제 사용 패턴에 맞춘 데이터 구조 설계

정규화 vs 반정규화

반정규화 기법

1. 컬럼 추가 (Column Addition)

설명: 다른 테이블의 데이터를 현재 테이블에 중복 저장

예시:

-- 정규화된 구조
Orders 테이블: order_id, customer_id, order_date
Customers 테이블: customer_id, customer_name, customer_email

-- 반정규화: Orders 테이블에 customer_name 추가
Orders 테이블: order_id, customer_id, customer_name, order_date

장점: 주문 조회 시 JOIN 없이 고객명 바로 조회 가능
단점: 고객명 변경 시 Orders 테이블도 업데이트 필요

2. 테이블 병합 (Table Merging)

설명: 자주 함께 조회되는 테이블을 하나로 합침

예시:

-- 정규화된 구조
Users 테이블: user_id, username, email
UserProfiles 테이블: user_id, address, phone, birth_date

-- 반정규화: 두 테이블 병합
Users 테이블: user_id, username, email, address, phone, birth_date

장점: 사용자 정보 조회 시 JOIN 불필요
단점: NULL 값 증가 가능, 테이블 크기 증가

3. 파생 컬럼 추가 (Derived Column)

설명: 계산된 값을 미리 저장하여 조회 시 계산 비용 절감

예시:

-- 정규화된 구조
OrderItems 테이블: order_id, product_id, quantity, unit_price
-- 총액은 매번 계산: SUM(quantity * unit_price)

-- 반정규화: 총액 컬럼 추가
Orders 테이블: order_id, customer_id, total_amount, order_date

장점: 집계 쿼리 성능 향상
단점: OrderItems 변경 시 Orders.total_amount도 업데이트 필요

4. 중복 테이블 생성 (Duplicated Table)

설명: 동일한 데이터를 다른 구조로 저장하여 다양한 조회 패턴 지원

예시:

-- 원본 테이블 (정규화)
Transactions: transaction_id, user_id, amount, created_at

-- 반정규화: 보고서용 테이블
DailyReports: date, user_id, total_amount, transaction_count

장점: 보고서 생성 속도 향상
단점: 데이터 동기화 로직 필요, 저장 공간 증가

5. 집계 테이블 (Summary Table)

설명: 자주 조회되는 집계 데이터를 미리 계산하여 저장

예시:

-- 반정규화: 집계 테이블
ProductStats: 
  product_id, 
  total_sales, 
  average_rating, 
  review_count,
  last_updated

장점: 복잡한 집계 쿼리 대신 단순 SELECT로 조회
단점: 원본 데이터 변경 시 집계 테이블 갱신 필요

반정규화 시 고려사항

1. 데이터 일관성 관리

• 트리거 활용: 원본 데이터 변경 시 자동으로 반정규화된 데이터 업데이트
• 애플리케이션 로직: 업데이트 시 관련된 모든 반정규화 데이터 동기화
• 배치 작업: 주기적으로 데이터 일관성 검증 및 수정

2. 업데이트 비용 증가

• 여러 테이블에 동일한 데이터가 존재하므로 업데이트 시 여러 곳 수정 필요
• 트랜잭션 범위가 넓어질 수 있음

3. 저장 공간 증가

• 데이터 중복으로 인한 저장 공간 증가
• 대용량 데이터의 경우 비용 증가 가능

4. 복잡도 증가

• 데이터 모델이 복잡해져 유지보수 어려움
• 새로운 개발자 온보딩 시간 증가

반정규화 적용 시나리오

적합한 경우

• 읽기 중심 애플리케이션: 조회가 업데이트보다 훨씬 많은 경우
• 복잡한 JOIN 쿼리: 자주 실행되는 복잡한 JOIN이 성능 병목인 경우
• 보고서 생성: 대용량 데이터 집계가 필요한 경우
• 실시간 통계: 실시간으로 집계 데이터가 필요한 경우
• 읽기 성능이 중요: 마이크로초 단위 성능이 중요한 경우

부적합한 경우

• 쓰기 중심 애플리케이션: 업데이트가 빈번한 경우
• 데이터 일관성이 중요: 금융, 의료 등 정확성이 중요한 도메인
• 저장 공간 제약: 저장 공간이 제한적인 환경
• 단순한 쿼리: JOIN이 단순하고 성능 문제가 없는 경우

반정규화 구현 전략

1. 단계적 적용

1. 성능 측정: 현재 쿼리 성능 및 병목 지점 파악
2. 작은 범위 테스트: 특정 테이블/컬럼부터 반정규화 적용
3. 성능 비교: 반정규화 전후 성능 비교 및 모니터링
4. 점진적 확장: 효과가 검증되면 다른 영역으로 확장

2. 데이터 동기화 전략

• 트리거 기반: 데이터베이스 레벨에서 자동 동기화
• 애플리케이션 로직: 서비스 레이어에서 동기화 처리
• 이벤트 기반: 메시지 큐를 통한 비동기 동기화
• 배치 작업: 주기적으로 데이터 일관성 검증 및 수정

3. 모니터링 및 유지보수

• 성능 모니터링: 쿼리 성능 지속적 모니터링
• 데이터 일관성 검증: 주기적인 데이터 무결성 검사
• 문서화: 반정규화 적용 이유 및 동기화 로직 문서화

예시: 주문 시스템 반정규화

정규화된 구조

-- Orders 테이블
CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATETIME,
    FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

-- Customers 테이블
CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100)
);

-- OrderItems 테이블
CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY,
    order_id INT,
    product_id INT,
    quantity INT,
    unit_price DECIMAL(10,2),
    FOREIGN KEY (order_id) REFERENCES Orders(order_id)
);

반정규화 적용

-- Orders 테이블에 고객 정보 및 총액 추가
CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    customer_name VARCHAR(100),  -- 반정규화: 고객명 중복 저장
    customer_email VARCHAR(100),  -- 반정규화: 고객 이메일 중복 저장
    total_amount DECIMAL(10,2),   -- 반정규화: 총액 미리 계산
    order_date DATETIME,
    FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

-- 집계 테이블 생성
CREATE TABLE ProductStats (
    product_id INT PRIMARY KEY,
    total_sales INT,              -- 총 판매량
    total_revenue DECIMAL(10,2),  -- 총 매출
    average_rating DECIMAL(3,2),  -- 평균 평점
    last_updated DATETIME
);

동기화 로직 예시

-- 트리거: OrderItems 변경 시 Orders.total_amount 업데이트
CREATE TRIGGER update_order_total
AFTER INSERT OR UPDATE OR DELETE ON OrderItems
FOR EACH ROW
BEGIN
    UPDATE Orders
    SET total_amount = (
        SELECT SUM(quantity * unit_price)
        FROM OrderItems
        WHERE order_id = NEW.order_id
    )
    WHERE order_id = NEW.order_id;
END;

결론

반정규화는 성능과 일관성 사이의 트레이드오프를 다루는 기법입니다.

• 적절히 사용하면: 조회 성능을 크게 향상시킬 수 있음
• 남용하면: 데이터 일관성 문제와 유지보수 비용 증가

핵심 원칙:

1. 성능 문제가 명확히 확인된 경우에만 적용
2. 데이터 동기화 전략을 반드시 수립
3. 지속적인 모니터링과 검증 필요
4. 문서화를 통한 팀 내 공유

참고

• 데이터베이스 정규화 (Normalization)
• 데이터베이스 인덱싱 전략
• 읽기/쓰기 분리 (Read/Write Splitting)
• 캐싱 전략 (Caching Strategy)

6. hello world 출력 1) npx 로 직접 출력

   

   2) package.json에 start 스크립트 추가 후 실행

   

ai에게 추천 받은 다음 정리할 것들

• tsconfig.json 주요 옵션 설명 target, module, strict, esModuleInterop 등 자주 쓰는 옵션이 무엇을 의미하는지 예시와 함께 설명
• 타입스크립트 컴파일 방법 tsc 명령어로 컴파일하는 방법 컴파일 결과물이 어디에 생기는지(outDir 옵션 등)
• 타입스크립트와 자바스크립트 차이점 타입 시스템, 인터페이스, 타입 추론 등
• 타입 정의 파일(.d.ts)과 @types 사용법 외부 라이브러리 사용할 때 타입 정의가 왜 필요한지 DefinitelyTyped와 @types의 역할
• ESLint, Prettier 등 코드 스타일 도구 연동 코드 품질 관리와 자동 포맷팅 설정 방법
• 간단한 모듈화/파일 분리 예시 여러 파일로 코드를 나누고 import/export 사용하는 방법
• npm 패키지 설치와 관리 dependencies vs devDependencies 차이 패키지 업데이트 방법
• 실행 환경별(로컬/배포) 설정 분리 환경 변수(.env) 사용법, cross-env 등
• 테스트 도구 연동 Jest, Mocha 등 테스트 프레임워크와 타입스크립트 연동
• 빌드 후 실행/배포 방법 빌드된 js 파일 실행, 배포 폴더 구조 등

• Java의 jar 옵션을 이용해 생성된 압축 파일로 애플리케이션을 배포하고 동작시킬 수 있다록 관련 파일을 패키징한 것

JAR (Java Archive)

• 자바 프로젝트를 압축한 파일
• 클래스, 라이브러리 포함
• JRE만 있어도 실행 가능하다.

WAR (Web Application Archive)

• Servlet / Jsp 컨테이너에 배치할 수 있는 웹 애플리케이션(Web Application) 압축파일 포맷
• 웹 관련 자원을 포함함 (JSP, Servlet, JAR, Class, XML, HTML, Javascript)
• 사전 정의된 구조를 사용함 (WEB-INF, META-INF)
• 별도의 웹서버(WEB) or 웹 컨테이너(WAS) 필요
• JAR파일의 일종으로 웹 애플리케이션 전체를 패키징 하기 위한 JAR 파일이다.

spring boot

내장톰캣이 있기때문에 jar로 실행 가능하다.

java -jar your-application.jar

lcs

• 같으면 대각선 전것 +1 / 아니면 옆 아래 중 큰 값

if (str1.charAt(i - 1) == str2.charAt(j - 1)) {
    dp[i][j] = dp[i - 1][j - 1] + 1;
}
else {
    dp[i][j] = Math.max(dp[i - 1][j], dp[i][j - 1]);
}

sort 재정의

 Arrays.sort(files, new Comparator<String> () {
           @Override
            public int compare(String o1, String o2) {
                String head1 = o1.split("[0-9]")[0];
                String head2 = o2.split("[0-9]")[0];

                int result = head1.toLowerCase().compareTo(head2.toLowerCase());
                //head가 같을경우 
                if(result == 0) {
                    result = compareNumber(o1, head1) - compareNumber(o2, head2);
                }
                return result;
            }

Collections.sort(people, new Comparator<Person>() {
            @Override
            public int compare(Person p1, Person p2) {
                return Integer.compare(p1.age, p2.age);
            }
        });

HashMap

• put 넣기
• get 가져오기
• containsKey() 있는지 확인

  Map<String, Integer> map = new HashMap<>();
  

for (int i = 0; i < participant.length; i++) { if (map.containsKey(participant[i])) { map.put(participant[i], map.get(participant[i]) + 1); } else { map.put(participant[i], 1); } }

for (Map.Entry<String, Integer> entry : map.entrySet()) { String key = entry.getKey(); Integer value = entry.getValue(); }

## priority queue
```java
PriorityQueue<Integer> minHeap = new PriorityQueue<>();
PriorityQueue<Integer> minHeap = new PriorityQueue<?>(Collections.reverseOrder()); // 내림차순

minHeap.add(i); // 넣기
minHeap.peek(); // 값 확인
minHeap.poll(); // 빼기

프로세스의 실행 순서를 제어하고 동시에 접근할 수 없는 자원에 하나의 프로세스만 접근하게 하여 데이터의 일관성을 유지하는 과정

Race Condition(경쟁 상태)

여러 프로세스들이 동시에 데이터에 접근하는 상황에서 어떤 순서로 데이터에 접근하냐에 따라 결과 값이 달라질 수 있는 상황

공유 데이터의 동시 접근은 데이터의 불일치를 발생시킬 수 있다. 따라서 일관성을 유지하기 위해서는 협력 프로세스 간의 실행 순서를 정해주는 동기화가 필요하다.

Critical Section(임계 영역)

동일한 자원에 동시에 접근하는 경우가 발생하는 코드의 영역

접근 순서에 따라 실행 결과가 달라지는 구역으로 멀티 프로세스 환경에서 둘 이상의 프로세스가 동시에 접근하면 안되는 영역이다. 하나의 쓰레드가 임계 영역에 접근하기 위해서 요청->(대기)->임계영역 처리->완료의 순서로 이루어진다.

임계영역 문제를 해결하기 위한 3가지 조건

1. Mutual Exclusion (상호배타) : 하나의 프로세스가 임계 영역에 있으면 다른 프로세스는 못들어감
2. Progress (진행) : 임계영역에 없으면 어떤 프로세스가 들어갈 것인지 선택
3. Bounded Waiting (유한 대기) : 한번 들어간 프로세스는 제한을 준다.

Mutex vs Semaphore

Mutex

• mutual exclusion에서 나온 용어로 '상호배제'의 의미를 가진다. 공유 불가능한 자원의 동시 사용을 막기 위해 Lock를 가진 쓰레드만 임계 영역에 접근할 수 있고 작업이 끝난 쓰레드는 Unlock하여 Lock을 반환한다.

• 정의: 뮤텍스는 Mutual Exclusion의 줄임말로, 상호 배제를 보장하는 동기화 객체이다. 한 번에 하나의 스레드만 자원을 사용할 수 있게 한다.

• 소유권: 뮤텍스는 소유권 개념이 있다. 한 스레드가 뮤텍스를 획득하면, 그 스레드만이 뮤텍스를 해제할 수 있다. 다른 스레드는 뮤텍스가 해제될 때까지 대기해야 한다.

• 사용 목적: 주로 단일 자원의 동기화에 사용된다. 예를 들어, 임계 구역(critical section)을 보호하기 위해 사용된다.

• 생성 및 해제: 뮤텍스를 생성한 스레드와 해제하는 스레드가 동일해야 한다. 이는 뮤텍스의 소유권 개념 때문이다.

Semaphore

• 두 개의 원자적 함수로 조작되는 정적 번수로 멀티 프로그래밍에서 공유자원 접근을 제한하는 방법으로 사용 S는 정수값을 가지는 변수이고 자원을 할당하는 P연산과 해제하는 V연산이 있다. P는 들어가기 전에 수행, V는 나올때 수행된다.

  S는 화장실의 열쇠이고 S는 사람이 들어갈 때 열쇠의 수가 줄어드는 것, V는 나올때 열쇠가 늘어나는 것과 같다. 열쇠가 3개 있다면 화장실에 접근 할 수 있는 프로세스는 3명인 것이다.

• 정의: 세마포어는 여러 스레드가 동시에 접근할 수 있는 자원의 개수를 제어하는 동기화 객체다. 카운팅 세마포어와 바이너리 세마포어가 있다.

• 카운팅 세마포어: 여러 개의 스레드가 자원에 접근할 수 있게 허용한다. 세마포어의 카운트는 동시에 접근 가능한 스레드의 수를 나타낸다.

• 바이너리 세마포어: 뮤텍스와 유사하게 동작하며, 카운트가 0 또는 1인 세마포어다. 뮤텍스와의 차이점은 소유권이 없다.

• 소유권: 세마포어는 소유권 개념이 없다. 한 스레드가 세마포어를 획득하고, 다른 스레드가 해제할 수 있다.

• 사용 목적: 여러 자원을 관리할 때 사용된다. 예를 들어, 일정 수의 스레드만이 접근할 수 있는 풀(pool)을 관리하는 데 유용

차이

• 뮤텍스는 상호 배제를 보장하며, 한 번에 하나의 스레드만 자원을 사용할 수 있게 한다. 소유권 개념이 있어 뮤텍스를 획득한 스레드만 해제할 수 있다.
• 세마포어는 여러 스레드가 동시에 접근할 수 있는 자원의 수를 제어한다. 소유권 개념이 없으며, 카운팅 세마포어와 바이너리 세마포어로 나뉜다.

Thread(쓰레드)

쓰레드는 CPU 수행의 기본 단위 또는 프소세스 안에서 제어권의 흐름이다.

구성

• Thread ID
• Program counter
• Register set
• Stack space

각각의 쓰레드는 최소한 자신의 레지스터 상태, 스택을 주로 갖는다. Code, Data, 운영체제 자원은 쓰레드끼리 공유한다.

싱글 쓰레드 : 한 프로세스가 하나의 스레드를 이용하여 한 번에 한 작업만 수행하는 것 멀티 쓰레드 : 한 프로세스가 여러 쓰레드로 동시에 여려 작업을 수행하는 것

Multi-threading(멀티쓰레딩)

프로세서가 여러개인 경우 멀티 쓰레드를 통해 병렬성을 높일 수 있다. 프로세서가 하나인 경우 멀티 쓰레드를 통해 동시성을 높일 수 있다.

멀티쓰레딩의 장점

1. 응답성 : 작업을 분리하여 실행하므로 실시간으로 사용자에게 응답할 수 있다.
2. 자원공유 : 쓰레드는 자신이 속한 프로세스 내의 쓰레드와 자원을 공유 하여 효율적이다.
3. 경제성 : 프로세스를 새로 생성하는 것 보다 쓰레드를 생성하는게 효율적이고 경제적이다.
4. 확장성 : 멀티 쓰레드의 경우 한 프로세스를 여러 프로세서에서 수행 할 수 있다.

User-level / Kernel-level Thread

유저쓰레드 : 커널위에서 커널의 지원 없이 유저 수준의 쓰레드 라이브러리가 관리하는 쓰레드 커널 쓰레드 : 커널이 지원하는 쓰레드

커널 쓰레드는 안정적이지만 성능이 저하, 유저 쓰레드는 안정성은 떨어지지만 성능 저하가 없다.

두 쓰레드의 관계를 설계하는 방법

1. Many-to-One Model : 하나의 커널 쓰레드에 여러 유저 쓰레드를 연결하는 모델 한 유저 쓰레드만 커널에 접근할 수 있기에 멀티 프로세서 시스템에서 병렬적 수행이 어렵다.

2. One-to-One Model : 하나의 커널에 하나의 유저가 대응하는 모델 동시성을 높여주나 유저를 늘리면 커널도 늘어나기에 성능 저하가 발생 가능함

3. Many-to-Many Model : 여러 유저에 적거나 같은 수의 커널이 대응하는 모델 Many-to-one Model에 비해 더 높은 동시성을 갖고, One-to-One Model의 단점이었던 커널 스레드 생성의 오버헤드도 걱정할 필요 없다. 

4. Two-level Model : Many-to-Many Model에서 확장된 개념 특정 유저 스레드를 위한 커널 스레드를 별도로 제공하는 모델

동기(Synchronous)

동시에 일어난다는 뜻을 가짐

요청을 하면 시간이 얼마나 걸리던 요청한 자리에서 결과가 나와야한다. 작업이 직렬로 배치되어 작업의 실행 순서가 정해져있다.

장점 : 설계가 간단하고 직관적이다. 단점 : 결과가 주어질 때까지 대기해야한다.

비동기(Asynchronous)

동시에 일어나지 않는다는 뜻을 가짐

요청한 결과가 동시에 일어나지 않는다. 먼저 시작된 작업의 완료 여부와는 상관없이 새로운 작업을 시작하는 방식이다. 작업이 병렬로 배치되어 실행되며 작업의 순서가 확실하지 않아 나중에 시작된 작업이 먼저 끝나는 경우도 발생한다.

장점 : 요청의 결과가 반환되는 동안 다른 작업이 가능하다. 단점 : 설계가 복잡하다.

블록과 논블럭

블록

동기의 개념에서 파생되었다. 브라우저 실행 시간을 10분으로 가정하면 다른 브라우저는 결과가 나올 때 까지 대기해야 하는 상태를 블록상태라고 한다.

논블록

비동기의 개념에서 파생되었다. 같은 가정에서 대기없이 자유롭게 사용할 수 있는 상태를 논블록 상태라고 한다.

import java.util.*;

scanner

Scanner sc = new Scanner(System.in);
int n = sc.nextInt();

BufferReader

 BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
 String[] input = br.readLine().split(" ");

GCD 최대 공약수

public static long GCD(long a, long b){
    if(b == 0) return a;
    return GCD(b, a % b);
}

LCM 최소 공배수

private static int lcm(int a, int b) {
        return a * b / gcd(a, b);
    }

문자열 뒤집기

String str = "hello";
String reverse = new StringBuffer(str).reverse().toString();
// reverse = "olloeh"

Ready 상태의 프로세스 중에서 어떤 프로세스에게 CPU를 할당할 지 결정한다.

목적

CPU 스케줄링의 목적은 모든 프로세스가 적당히, 공평히, 효율적으로 자원을 할당 받는 것이다.

• 공평성 : 프로세스에게 자원을 배분하는 과정이 공평해야함
• 효율성 : 시스템 자원이 쉬는 시간이 없어야 함
• 안정성 : 중요 프로세스들은 우선권을 주어야 하고, 프로세스가 증가해도 안정적으로 돌아가야함
• 확장성 : 시스템 자원이 늘어나는 경우 이 혜택이 시스템에 반영되야함
• 반응 시간 보장 : 프로세스의 요구가 있을 경우 적절한 시간 안에 반응을 해줘야 함
• 무한 연기 방지 : 특정 프로세스의 작업이 무한정 연기되면 안 됨

고려사항

1. 선점형 / 비선점형

• 선점형 스케줄링

  1. 실행상태에 있는 프로세스의 작업 중단하고 새로운 작업 시작 가능
  2. Context Switch로 인한 오버헤드 발생할 수 있다.
  3. 저수준 스케줄러에 사용됨

• 비선점형

  1. 프로세스가 CPU반환 시 까지 다른 프로세스는 CPU 점유 불가능
  2. 효율적일 수 있으나 전체 처리율이 떨어질 수 있다.

2. 프로세스 우선순위

• 프로세스간에도 우선순위가 존재할 수 있다.
• 프로세스는 커널 프로세스와 일반 프로세스로 나뉜다.
• 커널 프로세스가 보통 우선순위가 높다.
• 우선순위가 높다는 것은 일반적으로 빨리 자주 실행된다는 것이다.
• 일반 프로세스 간에도 우선순위가 존재한다.

3. CPU bound process / IO bound process

• CPU 작업을 CPU버스트, 입출력 작업을 I/O버스트 라고한다.
• CPU 버스트가 많은 프로세스를 CPU bound process, IO버스트가 많은 프로세스를 IO bound process 라고 한다.
• IO는 금방 대기로 빠지고 CPU는 해당 시간을 대부분 사용하는 경우가 많다.
• 따라서 IO bound process의 우순위를 높이는 것이 효율적이다.

4. 전면 프로세스 / 후면 프로세스

• 전면 프로세스는 GUI를 사용하여 화면 맨 앞에 놓인 프로세스이다.
• 후면 프로세스는 사용자와 상호 작용이 없다.
• 따라서 즉각 반응해야 하는 전면 프로세스를 우선 처리하는 것이 합리적이다.

사이트 간 요청 위조를 뜻한다. 공격자가 사용자가 로그인한 웹사이트에서 사용자가 원하지 않는 동작을 수행하게 하는 보안 취약점이다.

CSRF 공격 개요

1. 사용자가 로그인 : 사용자가 로그인하면 브라우저에 사용자의 정보가 담긴 쿠키를 저장한다.
2. 악성 사이트 방문 시 : 악성 사이트는 사용자의 쿠키를 이용해 로그인 한 사이트에 요청을 보낸다.
3. 서버 처리 : 해당 사이트는 방문자의 요청으로 알고 해당 요청을 수행한다.

Security config에서 csrf를 끄는 이유

api서버를 구축할 때 csrf를 자동으로 방어해주는 기능을 끈다.

그 이유는 해당 기능을 사용 하면 CSRF 토큰을 검사해야한다. 그러나 api서버는 무상태성이고, 권한이 필요한 요청을 위해서 인증(OAuth2, jwt토큰 등)을 포함시키고 있기에 csrf를 위한 설정을 하기 보다 기능을 끄는 편이라고 한다.

무상태성(Stateless) 서버가 클라이언트의 상태를 저장하지 않는다.

어떤 프로세스에게 자원을 할당할지를 결정하는 운영체제 커널의 모듈을 지칭한다.

스케줄러 종류

단기 스케줄러

메모리 내의 준비하고 있는 작업 중 실행 할 프로세스 선택하여 CPU할당

• CPU와 메모리 사이의 스케줄링을 담당한다
• 프로세스의 상태 변화 ready > running > waiting > ready
• CPU 스케줄러라고도 함
• 일반적으로 생각하는 스케줄러

중기 스케줄러

너무 많은 프로세스에게 메모리를 할당하면 시스템의 성능이 저하될 수 있기에 이를 해결하기 위해 메모리에 있는 프로세스의 수 관리

• 메모리의 여유공간을 마련하기 위해 프로세스를 디스크로 보내는 swapping (프로세스의 메모리를 통째로 빼앗아 디스크 스왑 영역에 저장하는 스왑 아웃을 하고 여유가 생기면 스왑 인을 하는 행위)
• 프로세스의 상태 변화 ready > suspended

장기 스케줄러

어떤 프로세스를 ready queue에 넣을 것인지 결정

• 메모리와 디스크 사이의 스케줄링을 담당
• 하드 디스크에 있는 프로그램을 메모리에 로드
• 몇개의 프로그램이 올라갈 것인지 제어
• 프로세스 상태의 변화 new > ready

스케줄링 알고리즘

비선점 스케줄링

• CPU할당을 받으면 작업 종료까지 다른 프로세스는 CPU점유가 불가능한 스케줄링 방식

1. FIFO

가장 먼저 들어온 프로세스가 먼저 실행됨

• 장점

1. 간단하다

• 단점

1. 비선점식으로 대화식 프로세스에 적합하지 않다
2. 긴 작업이 짧은 작업 앞일 때 대기시간이 길어진다.

2. SJF(Shortest Job First)

실행시간이 짧은 프로세스에게 자원을 할당

• 장점

1. 평균 대기시간이 짧다.

• 단점

1. 긴 작업은 오래 기다려야한다.
2. CPU할당이 공평하지 않다.

3. 우선순위(비선점)

프로세스마다 우선순위를 부여하여 높은 우선순위가 먼저 자우너 할당

• 장점

1. 프로세스의 중요도를 명시할 수 있다.
2. 실시간 시스템에 유리

• 단점

1. 낮은 프로세스는 계속 기다려야한다.

선점 스케줄링

• 현재 프로세스가 종료되지 않아도 다른 프로세스에게 CPU할당하는 방식

• 1. 우선순위(선점)*

  하나의 프로세스가 CPU를 차지하고 있어도 우선순위가 높은 다른 프로세스가 대기하는 경우 현재 프로세스를 중단 시키고 우선순위가 높은 프로세스에게 CPU를 할당하는 스케줄링 방식

• 장점

1. 응답이 빠르다.

• 단점

1. 처리시간 예측이 어렵다.
2. 계속 들어오는 경우 오버헤드 발생

2. RR(Round Robin)

동일한 할당시간을 갖고, 실행 후 맨끝으로 가서 기다림

• 장점

1. 모든 프로세스가 공정하다.

• 단점

1. 타이머가 필요하다.
2. 시간이 짧을경우 오버헤드 발생

문제상황

회원가입시 createDate와 modifiedDate가 작동하지 않았다.

@Entity
@NoArgsConstructor(access = PROTECTED)
@AllArgsConstructor(access = PROTECTED)
@Builder
@Getter
public class Member extends BaseTime {
    @Column(unique = true)
    private String username;
    private String password;
    @Column(unique = true)
    private String refreshToken;
    @Transient
    private Boolean _isAdmin;
    private String nickname;
}

Member 엔티티가 BaseTime을 상속하고

@MappedSuperclass
@Getter
@EntityListeners(AuditingEntityListener.class)
public class BaseTime extends BaseEntity {
    @CreatedDate
    private LocalDateTime createdDate;
    @LastModifiedDate
    private LocalDateTime modifiedDate;
}

BaseTime에는

@CreatedDate와 @LastModifiedDate는 Spring Data JPA의 Auditing 기능을 사용하여 엔티티가 생성 및 수정될 때 자동으로 값을 설정하는 어노테이션이 달려있는데..

GPT의 명료한 해결

결과 - 성공

좀 더 꼼꼼히 하자...

문제상황

Spring으로 백을 만들고 react로 프론트를 만들기 위해 연결 테스트를 하던 중 cors문제가 발생했다.

해결과정

부트캠프에서 프로젝트로 했던 조합이었기에 우리 대장님이 만들어준 코드를 보며 복습하고 모르는 점을 정리하기로 했다.

학습

CORS란?

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

React 프론트(3000)와 Spring(8090) 이기 때문에 포트가 달라 서로 다른 CORS 위반 에러가 발생한다.

다른 Origin을 갖고있는 react와 spring이 통신해주기 위해 설정이 필요함을 알았다.

Spring 설정

webConfig만들어주기

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("http://localhost:3000/")
                .allowedMethods("*")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }

}

1. @Configuration : 어노테이션을 이용해 설정 파일로 등록한다.
2. implements WebMvcConfigurer : WebMvcConfigurer 인터페이스를 구현하여 SpringMVC에 대한 추가 설정 제공
3. addCorsMappings : CORS 매핑을 추가하는 메서드
4. addMapping("/api/**") : CORS를 적용할 URL패턴을 정의한다. (/api/~ 로 들어오는 URL에 적용한다)
5. .allowedOrigins("http://localhost:3000/") : 자원 공유를 허락할 Origin설정(현재는 프론트 서버만 허락)
6. .allowedMethods("*") : 모든 HTTP메서드를 허용한다.
7. .allowedHeaders("*") : 모든 HTTP헤더를 허용한다.
8. .allowCredentials(true) : 쿠키와 인증 정보를 포함한 크로스 도메인 요청을 허용한다.
9. .maxAge(3600); : CORS설정이 캐시되는 시간을 3600초(1시간)으로 설정

React 설정

axios 설정, HttpGet 함수화

import axios from "axios";

const apiInstance = axios.create({
  baseURL: "http://localhost:8090",
  headers: {
    "Content-Type": "application/json",
  },
  // timeout: 10000,
  withCredentials: true,
});

• http 요청을 쉽게해주는 axios의 기본 설정을 정의하였다.

1. apiInstance라는 axios인스턴스 만들기
2. baseURL 백엔드 서버 포트로 맞추기
3. header의 요청 타입을 json으로 설정
4. withCredentials로 쿠키와 인증정보를 포함한 요청 허용

export const HttpGet = async (url, params = null) => {
  try {
    const response = await apiInstance.get(url, { params });
    // console.log("GET request sent to:", response.config.url);

    return response.data;
  } catch (error) {
    console.error("Error in HttpGet:", error);
    throw error;
  }
};

1. URL과 선택적param을 통해 GET요청하기
2. url에는 엔드포인트가 들어간다(/api/~), param에는 쿼리 파라미터가 들어간다 HttpGet('/api', { id: 1 })는 http://localhost:8090/api?id=1로 요청이 간다.
3. 성공하면 data에 내용이 저장된다.
4. 실패하면 catch에서 오류를 처리한다.

사용

import { HttpGet } from "./service/httpService";
import React from "react";
import { useState, useEffect } from "react";

function App() {
   const [hello, setHello] = useState('')

    useEffect(() => {
        HttpGet("/api/hello").then((data)=>{
            if(data) {
                setHello(data);
            }
        });
    }, []);

    return (
        <div>
            데이터 가져오기 = {hello}
        </div>
    );
}

export default App;

@RestController
public class MemberController {
    @GetMapping("/api/hello")
    public String test() {
        return "Hello, world!";
    }
}

성공

가져와 졌다. 성공....

실행중인 프로그램을 의미하며, 운영체제에 의해 관리되고 독립적으로 실행되어 자원을 할당 받을 수 있는 단위

구조

프로세스는 각각의 독립된 메모리(Code, Data, Stack, Heap)영역을 할당 받는다.

1. code

• 작성한 코드가 저장되는 공간, 코드는 0과 1로 변환된 기계어가 저장됨

2. data

• 코드에서 선언된 전역변수, static변수, 상수 등이 저장됨
• 초기화된 변수와 아닌 변수가 나누어 저장됨
• 프로그램 시작 시 초기화, 프로세스 끝날 때까지 유지

3. stack

• 지역변수, 매개변수, return 주소들을 저장
• 함수가 호출되면 stack공간이 생기고, 함수가 종료되면 제거

4. heap

• 동적으로 생성되는 데이터 구조, 객체들 저장
• 프로세스의 주소 공간의 나머지 영역에 위치하며, 크기는 동적으로 확장 가능

프로세스의 상태

1. 프로세스 생성(new) : 생성되었지만 자원을 할당 받지 못한 상태
2. 실행 가능(Ready) : 자원을 모두 할당받았지만 CPU를 할당받지 못한 상태, Queue에서 대기
3. 실행 상태(Running) : 프로세서를 차지하여 명령들이 실행중
4. 대기(Blocked) : 이벤트가 발생하여 잠시 멈춘 상태, CPU를 사용하지 않는다.
5. 종료(Terminated, exit) : 메모리 공간은 운영체제에 반환

쓰레드(Thread)

프로세스의 실행 단위로 실제 작업을 수행하는 주체, CPU에 작엽 요청하는 실행 단위

특징

1. stack만 할당받고 나머지 영역은 공유한다.
2. 프로세스 내의 주소 공간이나 자원들을 같은 프로세스 내 쓰레드끼리 공유하며 실행
3. 쓰레드가 프로세스 자원을 변경하면 다른 쓰레드도 그 결과를 즉시 볼 수 있다.

장점

1. 응답성 향상 : 병렬처리로 인해 사용자가 응용 프로그램을 사용할 때 빠른 응답성을 제공
2. 자원 공유 효율성 향상 : 프로세스 내부 자원을 공유하기에 별도 메모리 공간 할당이 필요 없다.
3. 동시성 : 어러 쓰레드를 동시에 실행 할 수 있다.
4. 간결성 : 작업을 분리할 수 있어 코드가 간결함

단점

1. 스레드 간의 간섭 : 서로에게 영향을 미치기에 예상하지 못한 이슈 발생 가능
2. 성능 저하 : 쓰레드를 많이 생성하면 컨텍스트 스위칭이 빈번하게 발생하여 성능 저하가 일어날 수 있다.
3. 동기화 이슈 : 동시에 접근할 대 동기화 문제가 발생할 수 있다.
4. 자원 소비 : 개별적 흐름을 갖기에 쓰레드 마다 stack자원을 소비한다.

프로세스 vs 쓰레드

• 쓰레드는 프로세스 안에 포함되어 있다.
• 운영체제가 프로세스에게 code,data,stack,heap 영역을 할당해주고,쓰레드는 프로세스 안에서 stack을 제외한 다른 영역을 공유된다.
• 프로세스는 다른 프로세스와 정보 공유를 위해 IPC와 같은 과정이 필요하지만 쓰레드는 기본적으로 자원을 공유한다.

멀티 프로세스 vs 멀티 쓰레드

멀티 프로세스 하나의 응용프로그램을 여러개의 프로세스로 구성하여 각 프로세스가 하나의 작업을 처리하도로 하는 방식

• 장점 : 자식 프로세스에 문제가 생겨도 다른 자식에게 영향이 없다.
• 단점 :

1. Context Switching에서 자원이 공유 되어있지 않기에 오버헤드(추가적으로 시간,메모리,자원이 사용되는 현상) 발생
2. 복잡한 IPC: 프로세스는 독립된 영역을 할당 받았기에 변수를 공유할 수 없다.

멀티 쓰레드 하나의 응용프로그램을 여러 개의 쓰레드로 구성하여 하나의 작업을 처리하는 방식

• 장점 :

1. 시스템 자원 소모 감소 : 프로세스 생성보다 자원 할당이 적다.
2. 처리 비용 감소 : 쓰레드는 Context Switching이 빠르다
3. 응답시간 단축 : stack을 제외한 메모리 영역을 공유하기에 응답이 빠르다.

• 단점 :

1. 디버깅이 까다롭고, 주의 깊은 설계 필요
2. 단일 프로세스 시스템은 효과가 없다.
3. 동기화 문제
4. 하나의 쓰레드 문제는 전체가 영향을 받는다.

쓰레드를 이용하는게 효율적이기 때문에 대부분의 경우 멀티 쓰레드를 사용한다.

www(world wide web)의 약자로 인터넷으로 연결된 컴퓨터를 통해 정보를 공유할 수 있는 공간이다.

인터넷과 웹의 차이

인터넷 - TCP/IP 기반의 네트워크가 세계적으로 확대되어 연결된 네트워크들의 네트워크 웹 - HTML이라는 문서 형태와 HTTP라는 문서 전송 프로토콜, URL로 문서의 위치를 표시하는 시스템

웹보다 인터넷이 더 광범위한 범주이며, 인터넷으로 여러 기능을 할 수 있는데 그 중에서 HTTP 프로토콜을 사용하는 웹이 있는 것이다.

Web 통신

클라이언트 : 사용자가 서버에 접속하기 위해 사용하는 프로그램이나 서비스 등 서버: 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 시스템

과정

1. 사용자가 웹 브라우저를 통해 URL을 입력한다.
2. 입력된 URL 중 도메인 네임을 DNS 서버에서 검색
3. DNS 서버에서 해당 도메인 네임에 해당하는 IP주소를 찾아 입력한 URL정보와 함께 전달
4. 웹 페이지 URL정보와 전달받은 IP주소를 이용해 HTTP요청 메시지 생성
5. TCP를 통해 서버로 전달
6. 서버는 클라이언트의 요청을 받고 응답 전송

웹 통신의 큰 흐름 - www.google.com을 치면 일어나는 일

• 브라우저

1. www.google.com을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사
2. HTTP Request 메시지를 만듬
3. 만들어진 메시지를 웹 서버로 전송

• 프로토콜 스택, LAN 어댑터

1. 브라우저로 부터 받은 메시지를 패킷속에 저장하고, 이 패킷을 LAN 어댑터에 넘김
2. LAN 어댑터는 이걸 전기신호로 변환시켜 송출

• 네트워크

1. 패킷이 스위칭 허브, 라우터, 통신사 인터넷 순서로 전달된다.

• 방화벽

1. 패킷이 웹서버측 LAN에 도착
2. 방화벽이 패킷 검사
3. 캐시서버에서 얻을 수 있는 지 검사, 없으면 웹 서버로

• 웹 서버

1. 웹 서버 프로토콜 스택은 패킷을 추출하여 메시지 복원 후 웹 서버 애플리케이션으로 전달
2. 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송
3. 왔던 방식대로 응답 메시지가 클라이언트에게 전달

www.xxxxx.com처럼 사람이 읽을 수 있는 도메인 이름을 12.34.56.78과 같은 IP주소로 바꿔서 컴퓨터가 통신할 수 있게 도와주는 분산형 데이터베이스 시스템이다.

• 인터넷용 전화번호부이다. 이름으로 전화번호를 저장하면 번호를 일일이 외울 필요가 없기 때문이다.

구성 요소

• 도메인 네임 스페이스 : DNS가 저장 관리하는 계층적 구조
• 네임서버 : 권한이 있는 DNS 서버, 해당 도메인 이름의 IP 주소를 찾는다
• 리졸버 : 권한 없는 DNS 서버, DNS 클라이언트 요청을 네임서버로 전달하고 찾은 정보를 클라이언트에게 제공하는 기능을 수행

과정

1. 브라우저가 www.xxx.com을 입력하면 DNS 리졸버는 자신의 캐시에 있는지 확인하고 있다면 반환한다. 없다면 DNS 서버에 요청한다.
2. DNS 리졸버는 Root DNS Server에 요청하면 TLD DNS Server의 IP 주소를 전달
3. .com TLD DNS Server(www.xxx".com" 이기때문)는 해당 도메인 이름의 Authoritative DNS Server의 주소를 전달
4. Authoritative DNS Server는 실제 IP 주소를 반환
5. 리졸버는 해당 주소를 캐싱한다.

ROOT -> COM -> xxx.com 서버를 차례대로 질의해서 답을 찾는 과정을 Recursive Query라고 한다.

DNS Round Robin

DNS 서버 구성 방식 중 하나이다.

원리

• 웹 서비스를 담당할 여러 대의 웹 서버는 자신의 공인 IP를 각각 가짐
• 접속을 위해 브라우저에 도메인 주소를 입력하면 DNS는 정보를 조회하는데 이때 IP 주소를 여러대의 서버 IP리스트 중 랜덤하게 하나 또는 여러개를 선택해 알려준다.
• 사용자는 복수의 웹 서버에 나뉘어 접속 되며 자연스럽게 부하가 분산된다.

단점

1. 서버의 수 만큼 공인 IP 주소가 필요하다. 2. 균등하게 분산 되지 않는다.

• 모바일 사이트의 경우 프록시 서버는 이름변환 결과가 일정 시간 동안 캐싱되어 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속된다. 또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않습니다.

3. 서버가 다운되도 확인이 불가능 하다.

• 다운이 되었는지 접속 수 가 꽉찾는지 상황에 따라 질의 결과를 제어할 수 없다.

해결법

1. 다중 구성화 방식(Synchronous Time-Division Multiplexing)

• AP 서버에 VIP를 부여하여 다중화를 구성하면 각 AP서버를 체크한 후 이상이 감시되면 VIP를 정상 AP 서버로 인계 하는 방식이다. 서버 상태를 확인하여 우회루트 제공 또는 에러를 전송하는 방식이다.

2. 가중치 편성 방법(Weighted round robin)

• 각각의 서버에 가중치를 두어 분산 비율을 정한다. 예를 들면 처리 능력이 좋은 서버에 가중치를 높게 두어 많은 접속을 처리하는 방법이 있다.

3. 최소 연결 방식(Least connection)

• 접속 수가 가장 작은 서버를 선택한다.

텍스트 기반의 통신규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜 클라이언트가 요청을하면 서버가 응답을 하는 형태로 동작한다.

특징

• HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석됨
• TCP/IP를 이용하는 응용 프로토콜
• 비연결성 프로토콜이다. ( Cookie와 Session 등장의 이유 )
• 요청/응답 방식으로 동작

일반적인 HTTP요청과 응답

요청 Http 요청은 HTTP 프로토콜을 따르는 일련의 텍스트다. Get 요청 예시)

응답 서버는 HTTP 요청을 받으면 요청과 유사한 응답을 보낸다. 응답 예시)

출처 : 링크텍스트

이 요청과 응답은 사용자가 아니라도 누구든 읽을 수 있다. 이것은 중요한 정보를 다루기에는 적합하지 않다.

HTTPS(Hypertext Transfer Protocol Secure)

HTTP에 보안을 뜻하는 Secure이 추가된 프로토콜이다. 보안을 위해서 HTTPS는 SSL(Secure Socket Layer)나 TLS(Transport Layer Security Protocol)을 사용하여 데이터를 보호한다.

SSL/TLS

TLS는 SSL에서 발전하며 이름이 변경 되었는데 SSL이라는 명칭으로 계속 사용되기도 하며 SSL/TLS로 합쳐서 부르기도 한다.

작동 방식

SSL 프로토콜은 SSL 인증서를 사용해 작동한다.

1. SSL 인증서에는 서비스 정보, 서버키가 들어있고 CA(Certificate Authority, 공개키를 저장해주는 신뢰성이 검증된 민간 기업)에 의해 암호화 된다.

2. 브라우저는 내부적으로 CA리스트를 갖고 있고 각 CA의 공개키를 갖고 있다. 서버는 클라이언트에게 인증서를 제공하고 자신이 갖고있는 CA리스트에 있는 지 확인후 해당 공개키를 이용해 복호화 한다.

3. 복호화가 성공했다면 CA의 비공개키로 암호화 된 것이기 때문에 보안성 검증 완료

4. 신뢰할 수 있으므로 TLS/SSL Handshake를 통해 세션키를 생성하고 통신을 시작

암호화 방식

• 공개키 방식

공개키, 개인키를 한쌍으로 각각 암호화/복호화에 사용한다. 일반적으로 공개키로 암호화 한 것을 개인키로 복호화 하는데, 개인키를 먼저 만들고 공개키를 만들기 때문에 같은 쌍이 아니면 암호화 복호화가 불가능하다. 비대칭키라고 불림

장점 : 키 분배가 필요 없다. 단점 : 속도가 느리다. 대표 알고리즘 : 디피-헬만, RSA

• 대칭키 방식

하나의 키를 통해 암호화와 복호화를 진행한다. 하나의 키를 클라이언트와 서버가 같이 사용한다.

장점 : 속도가 빠르다. 단점 : 보안이 약하다. 대표 알고리즘 : SEED, DES, 3DES, AES, ARIA

TLS/SSL Handshake

1. 클라이언트가 서버에 접속해 말을 건다. (client hello) 아래의 정보를 서버에 보낸다.

• 브라우저의 SSL/TLS 버전
• 지원하는 암호화 방식 모음
• 임의의 난수
• 이전에 handshake를 했다면 그때의 세션 id
• 기타 확장 정보

2. 응답 및 정보 제공 (server hello)

• 브라우저의 방식중 서버가 선택한 암호화 방식
• 서버의 공개키가 담긴 SSL인증서(CA의 비밀키로 암호화 된 상태)
• 서버가 생성한 난수

3. 서버의 SSL 인증서 확인 브라우저에 내장 된 CA공개키로 복호화 하고 성공한다면 성공

4. 브라우저는 자신의 난수와 서버의 난수를 사용해 premaster secret 만들기 웹 서버 인증서에 포함된 서버 공개키로 암호화하여 전송한다.

5. 서버는 자신의 비밀키로 브라우저의 premaster secret 복호화 복호화 한 값을 master secret으로 저장 후 Session key생성 세션키는 대칭키 암호화에 사용. 이것으로 데이터를 암호화, 복호화 한다.

6. HTTPS 통신 시작

HTTPS 장단점

장점

• 웹사이트의 무결성을 보호해준다.
• 검색엔진최적화(SEO)에서 키워드 검색시 상위 노출되는 기준이다.

단점

• 녹음, 위치 등 사용자의 명시적 권한 허락 필요
• HTTP에 비해 느리다.

TCP, UDP는 네트워크 계층 중 전송 계층(OSI 4계층, TCP/IP 3계층)에서 사용하는 프로토콜이다. 전송계층은 송신자와 수신자를 연결하는 통신 서비스로 데이터의 전달을 담당한다.

따라서 데이터 통신을 표현한 OSI 7계층과 TCP/IP4계층을 먼저 알아보도록 하겠다.

둘 다 데이터 통신을 표현하였지만 OSI는 계층과 역할을 정확하게 표현한 모델이고, TCP/IP는 현재 인터넷에 사용되는 프로토콜로 실무적이며 단순화된 모델이다.

OSI

Open System Interconnection으로 다른 컴퓨터간의 통신 시 네트워크 구조에 상관없이 통신할 수 있도록 만든 모델. 물리, 데이터링크, 네트워크, 전송, 세션, 표현, 응용으로 7개의 레이어로 구성되어있다.

1계층 - 물리계층(Physical Layer) 전기적,기계적, 기능적인 특성을 이용하여 통신 케이블로 데이터를 전송. 이계층에서는 데이터를 전송만 할 뿐, 데이터가 무엇인지, 에러가 있는지 신경쓰지 않음 대표적 장비로 통신 케이블, 리피터, 허브 등이 있다.

2계층 - 데이터 링크계층(DataLink Layer) 물리계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행 통신의 오류찾기, 재전송 기능이 있다. 맥(media access control) 주소를 갖고 통신을 한다. 대표적 장비로 브릿지, 스위치 등이 있다.

3계층 - 네트워크 계층(Network Layer) 라우팅(데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능) 하는 계층 주소부여(IP), 경로설정(Route)을 한다.

4계층 - 전송 계층(Transport Layer) 통신을 활성화 하기 위한 계층 보통 TCP프로토콜을 이용한다. 만약 데이터가 왔다면 4계층에서 해당 데이터를 하나로 합쳐 5계층으로 전달한다. 패킷 생성 및 전송에 해당한다.

5계층 -세션 계층(Session Layer) 데이터가 통신하기 위한 논리적 연결 세션 설정, 유지, 종료, 복구 등의 기능이 있다. 통신하는 사용자들을 동기화하고 오류복구 명령을 일괄적으로 다룸

6계층 - 표현 계층(Presentation Layer) 데이터 표현이 상이한 응용 프로세스의 독립성을 제공, 암호화 사용자의 명령어를 완성 및 결과 표현화는 계층

7계층 - 응용 계층(Application Layer) 사용자의 데이터와 직접 상호작용하는 계층 HTTP뿐 아니라 SMTP(이메일 통신을 가능하게 하는 프로토콜)도 포함이다.

TCP/IP

L1 - 네트워크 연결 계층(Network Access Layer) 물리적인 데이터의 전송을 담당하는 계층으로, 여기서는 인터넷 계층과 달리 같은 네트워크 안에서 데이터가 전송된다. 노드 간의 신뢰성 있는 데이터 전송을 담당하며, 논리적인 주소가 아닌 물리적인 주소인 MAC을 참조해 장비간 전송을 하고, 기본적인 에러 검출과 패킷의 Frame화를 담당한다.

L2 - 인터넷 계층(Internet Layer) 네트워크 상에서 데이터의 전송을 담당하는 계층으로 서로 다른 네트워크 간의 통신을 가능하게 하는 역할을 수행한다

L3 - 전송 계층(Transport Layer) 통신 노드간의 데이터 전송 및 흐름에 있어 신뢰성을 보장 전송계층에 사용되는 대표적 프로토콜로 TCP, UDP가 있다.

L4 - 응용 계층(Application Layer) 사용자와 가장 가까운 계층으로 사용자-소프트웨어의 소통을 담당하는 계층 웹 프로그래밍을 하면서 흔히 접하는 여러 서버나 클라이언트 관련 응용 프로그램들이 동작하는 계층 응용 프로그램들끼리 데이터를 교환하기 위한 계층

TCP(Transmission Control Protocol)

TCP는 패킷 사이의 순서를 보장하고 연결지향 프로토콜을 사용하여 신뢰성을 구축한다.

• 가상회선 패킷 교환 방식(순서 보장) 각 패킷에는 가상회선 식별자가 포함되며 모든 패킷을 전송하면 가상 회선이 해제되고 전송된 순서대로 도착하는 방식이다.

• 3-way handshaking(신뢰성 확보) 1단계 : SYN 단게 = 클라이언트가 서버에게 연결을 요청 2단계 : SYN + ACK 단계 = 클라이언트의 연결 요청을 수락하고 서버도 클라이언트에게 연결 요청 3단계 : ACK 단계 = 클라이언트도 연결 요청 수락

이렇게 3단계를 거쳐 신뢰성 있는 데이터 전송을 시작한다.

특징

• 연결형 서비스로 가상 회선 방식을 제공한다.
• 3-way handshaking을 통해 연결을 설정한다.
• 흐름 제어 및 혼잡을 제어한다.
• 높은 신뢰성을 보장한다.
• UDP보다 속도가 느리다.
• 전이중(양방향으로 전송이 동시에 일어날 수 있음), 점대점 방식(연결이 2개의 종단점을 가지고 있음)이다.

패킷 추적 및 관리

데이터는 패킷 단위로 나누어 같은 목적지(IP계층)로 전송 각 패킷에 번호를 붙여 분실 확인 및 패킷을 추적하고 조립함. ex) A,B,C 패킷에 1,2,3번호를 부여하여 A,C만 왔으면 2번이 비었기에 분실을 확인 할 수 있다.

느린 이유

UDP(User Datagram Protocol)

UDP는 순서를 보장하지 않고 수신여부를 호가인하지 않으며 단순히 데이터만 주는 방식이다.

• 데이터그램 패킷 교환 방식

패킷이 독립적으로 이동하며 최적의 경로를 선택하여, 하나의 메시지에서 분할된 여러 패킷은 서로 다른 경로로 전송될 수 있으며 순서가 다를 수 있다.

특징

• 비연결형 서비스로 데이터그램 방식을 사용
• 정보를 주고 받을 때 신호 절차를 거치지 않음
• 최소한의 오류만 검출
• 신뢰성이 낮다.
• 속도가 빠르다.

빠른 이유

TCP vs UDP

TCP/IP 프로토콜을 이용해서 통신하는 응용프로그램은 데이터를 주고받기 전에 먼저 연결을 진행한다. 3-Way Handshake는 이 연결 과정을 의미한다.

TCP란

TCP (Transmission Control Protocol) 인터넷에서 데이터를 메세지 형식으로 보내기 위해 IP와 함께 사용하는 프로토콜이다. TCP는 패킷의 추적 및 관리 / IP는 배달을 하게된다.

TCP 특징

• 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
• 흐름 제어 및 혼잡 제어.
• 높은 신뢰성을 보장한다.
• UDP보다 속도가 느리다.
• 전이중(Full-Duplex), 점대점(Point to Point) 방식.

3-Way-Handshake 에서 사용되는 TCP 헤더 필드

- Sequence Number

• Segment에 있는 첫번째 바이트의 바이트 스트림 번호이다. ex) 0 ~ 999 > 0 / 1000 ~ 1999 > 1000
• TCP 종료시에는 임의의 랜덤값으로 설정해야 노출이 되지 않는다.

- Acknowledgement Number

• 받고 싶은 다음 바이트의 번호 ex) 0 ~ 999를 받았으면 ack# = 1000

- Control bits

• ACK
  • acknowledgment '승인'의 약자.
  • 패킷을 받았다는 응답을 할 때 사용한다.
  • Acknowledgement Number가 유효한지를 나타낸다.
  • 최초 연결의 첫 번째 세그먼트를 제외한 모든 Segment의 ACK 비트는 1로 설정한다. (최초는 응답할 요청이 없기 때문)
• SYN
  • synchronize '동시에 발생하다'의 약자.
  • 연결을 요청할 때 SYN bit를 사용한다.
  • 연결을 요청하는 경우 1로 설정한다. SYN bit=1 이면 TCP 연결 요청하는 과정이다.
  • 다른 모든 경우는 0으로 설정한다.

3-Way-Handshake 과정

일반적으로 클라이언트 / 서버 둘 다 먼저 요청 할 수 있기 때문에 먼저 요청 한 쪽을 클라이언트 받은 사람을 서버라고 칭함.

1. 클라이언드 ---- (SYN) ---- > 서버 클라이언트가 서버에게 연결을 요청하는 SYN segment를 보낸다.

• Segment Header의 SYN bit를 1로 설정
• PORT Client : CLOSE - SYN_SENT로 변경 SERVER : LISTEN

2. 클라이언트 < ---- (ACK + SYN) ---- 서버

1. 서버가 클라이언트의 SYN segment에 대한 ACK segment 전송
2. 동시에 서버가 클라이언트에게 연결을 요청하는 SYN segment를 전송 (SYN bit을 1로 설정)
3. SYN/ACK 를 전송하고 SYN RCVD(Received)의 상태로 클라이언트의 ACK 기다린다.
4. 클라이언트는 ACK segment를 받고 연결이 완료 된 ESTAB 상태가 된다.

3. 클라이언트 ---- (ACK) ---- > 서버 클라이언트는 서버의 SYN에 대하여 ACK를 전송한다.

• 연결 요청이 아니므로 SYN bit는 0

서버는 ACK를 받고 ESTAB가 된다.

4-Way-Handshake 과정

4-Way Handshake은 연결을 해제 (Connecntion Termination)하는 과정이다. FIN 플래그(세션을 종료시키는데 사용되며, 더 이상 보낸 데이터가 없음을 의미)를 사용한다.

1. 클라이언드 ---- (FIN) ---- > 서버 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다.

• FIN패킷에는 실질적으로 ACK도 포함되어있다.

2. 클라이언트 < ---- (ACK) ---- 서버 서버는 FIN을 받고 확인했단는 ACK를 보내고 자신의 통신이 끝날 때 까지 기다린다 (TIME_WAIT 상태)

3. 클라이언트 < ---- (FIN) ---- 서버 데이터를 모두 보냈다면 FIN을 클라이언트에게 보낸 후 승인을 기다리는 LAST_ACK상태로 들어감

4. 클라이언드 ---- (ACK) ---- > 서버 클라이트는 FIN을 받고 ACK를 보낸다. 뒤늦게 도착하는 패킷을 대비하기 위해 클라언트는 일정시간을(디폴트 240초)기다린 후 소켓을 닫는다. < (TIME_WAIT)