반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

 

Address 종류

  • Logical address (= Virtual address)
    • 프로세스마다 독립적으로 가지는 주소 공간
    • 각 프로세스마다 0번지부터 시작
    • CPU가 보는 주소
  • Physical address
    • 메모리에 실제 올라가는 위치
  • 주소 바인딩 : 주소를 결정하는 것
    • Symbolic Address → Logical Address —(T)—> Physical address
      • Symbolic Address? → 프로그래머 입장에서 사용하는 숫자가 아닌 변수, 함수 등
    • T가 언제인가?

 

주소 바인딩 (Address Binding)

  • Complie time binding → 비효율적, 요즘은 잘 쓰지 않음 (프로그램을 하나만 실행하던 예전에만 사용)
  • Load time binding → 실행 시 메모리 주소 결정
  • Run time binding → Load time binding처럼 실행 시 주소 결정 → 실행 도중 바뀔 수 있음

 

Memory Management Unit (MMU)

  • MMU : Logical address를 Physical address로 매핑해주는 Hardware device
  • MMU scheme : CPU에서 수행되는 모든 주소값에 base register(=relocation register) 값을 더한다.
  • User program은 logical address만 다루고, physical address를 볼 수 없고 알 필요도 없다.

  • Limit register는 보안 문제도 해결 → 다른 프로그램 주소 요청은 에러

 

용어 설명

  • Dynamic Loading
    • Loding : 메모리로 올리는 것
    • 프로세스 전체를 메모리에 미리 다 올리는 것이 아니라, 불려지는 루틴에 대해서만 메모리에 load
    • 대개 프로그램 자체에서 구현 (라이브러리 활용)
  • Dynamic Linking
    • Linking을 실행 시간까지 미루는 기법
    • Static Linking
      • 라이브러리가 프로그램의 실행 파일 코드에 포함됨 → 실행 파일의 크기가 커짐
      • 동일 라이브러리를 각각의 프로세스가 메모리에 올려 메모리 낭비 (eg. printf 함수의 라이브러리 코드)
    • Dynamic Linking
      • 라이브러리가 실행 시 연결됨
      • 라이브러리 호출 부분에 라이브러리 루틴의 위치를 찾기 위한 stub이라는 작은 코드를 둠
      • 라이브러리가 이미 메모리에 있으면 그 루틴의 주소로, 없으면 디스크에서 읽어옴
      • 운영체제의 도움이 필요
  • Overlays
    • 프로그래머가 수작업으로 구현
    • 프로세스에서 실제 필요한 정보만 Loading
  • Swapping
    • 프로세스를 일시적으로 메모리에서 Backing store(=swap area)로 쫓아내는 것
    • Backing store : 디스크

 

Allocation of Physical Memory

 

Contiguous allocation

  • 전체를 밀기 보다는, 최소한의 이동만으로 적당히 큰 hole을 만드는 것도 방법일 수 있음
  • 현대 운영체제에서 사용하는 방식은 Noncontiguous allocation

 

Paging

  • Page의 주소는 바뀌지만, Page 내부에서 할당된 상대적 주소는 바뀌지 않는다.

  • TLB : 자주 사용되는 Page table의 내용을 가지고 있는 Cache의 일종

  • TLB(Associative register) 사용을 안했다면 → Memory cycle time x 2 = 2 였을 것
  • 입실론은 알파에 비해 매우 작은 값이라, 실제 주소 접근 시간은 많이 감소한다.

 

Two-Level Page Table

  • 시간, 공간적 손해이지만, 사용되지 않는 주소 공간에 대한 Outer page table의 엔트리 값이 NULL이므로, Outer page table은 전체 길이에 대해 생기지만, Inner page table이 상당 부분 생성되지 않아 메모리 효율이 좋다!

 

Memory Protection

 

Inverted Page Table

 

Shared Page

 

Segmentation

  • Paging에서는 보안이 쉽지 않았음

 

메모리 관리에서 운영체제의 역할은?

  • 대부분의 내용은 주소 변환 → OS의 역할은 없음, 모두 하드웨어가 해줘야 할 일
    • 주소 변환할 때마다 OS가 개입한다면 비효율적

다음 강의에서 배울 가상 메모리에서는 운영체제의 역할이 확실히 있다!

 

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

 

 

The Deadloc Problem

  • Deadlock
    • 프로세스들이 서로가 가진 자원을 기다리며 block된 상태
  • Resource
    • 하드웨어, 소프트웨어 등을 포함하는 개념
      • I/O device, CPU cycle, Memory space, Semaphore 등
    • 프로세스가 자원을 사용하는 절차는 Request, Allocate, Use, Release

 

Deadlock 발생의 4가지 조건 (&조건)

  • Mutual exclusion (상호 배제)
    • 매 순간 하나의 프로세스만이 자원을 사용할 수 있음
  • No preemption (비선점)
    • 프로세스는 자원을 스스로 내어놓을 뿐 강제로 빼앗기지 않음
  • Hold and wait (보유 대기)
    • 자원을 가진 프로세스가 다른 자원을 기다릴 때 보유 자원을 계속 가지고 있음
  • Circular wait (순환 대기)
    • 자원을 기다리는 프로세스 간에 cycle이 형성되어야 함
    • P0 → P1 → P2 … Pn-1 → Pn → P0

 

Resource-Allocation Graph (자원 할당 그래프)

  • P→R 화살표 : 요청
  • R→P 화살표 : 할당
  • Cycle이 없으면 deadlock이 아니다
  • Cycle이 있으면 (No preemption, Hold and wait 가정)
    • 하나의 리소스에 하나의 인스턴스만 있다면 (cycle에서 사용하는 점이 하나라면) → Deadlock
  • 왼쪽 그림
    • Cycle 2개가 각각 Mutual exclusion을 만족 → 남은 Resource가 없음
  • 오른쪽 그림
    • P2에게 할당되어 있는 R1, P4에게 할당되어 있는 R2 → P2, P4가 R1 또는 R2를 반납하면 Deadlock이 해소됨 → Deadlock이 아님

 

Deadlock의 처리 방법

  • Deadlock Prevention
    • 자원 할당 시 Deadlock의 4가지 필요 조건 중 하나가 만족되지 않도록 하는 것
  • Deadlock Avoidance
    • 자원 요청에 대한 부가 정보를 통해 deadlock 가능성이 없을 때만 자원 할당
    • 시스템 state가 원래 state로 돌아올 수 있는 경우에만 자원 할당
  • Deadlock Detection and recovery
    • Deadlock 발생은 허용하되, 그에 대한 detection 루틴을 두어 발견 시 recover
  • Deadlock Ignorance
    • Deadlock을 시스템이 책임지지 않음
    • UNIX를 포함한 대부분의 OS가 채택
      • 미연에 방지하는 것이 손해!
    • 작동 안 하면 사람이 알아서 프로세스를 종료하든 한다!

 

Deadlock Prevention

  • Mutual Exclusion
    • 공유해서는 안되는 자원의 경우 만족할 수밖에 없음
  • Hold and Wait
    • 프로세스가 자원을 요청할 때 다른 자원을 가지고 있지 않게 한다
    • 방법 1 : 프로세스 시작 시 필요한 모든 자원 할당
    • 방법 2 : 자원이 필요할 경우 보유 자원을 모두 놓기;
  • No Preemption
    • 프로세스가 자원을 기다릴 때, 이미 보유한 자원이 선점됨
    • 모든 필요한 자원을 얻을 수 있을 때 프로세스 다시 시작
    • State를 쉽게 save, restore할 수 있는 자원에서 주로 사용 (CPU, Memory)
  • Circular Wait
    • 모든 자원 유형에 할당 순서를 정한다.
      • 순서가 3인 Ri를 보유 중인 프로세스가, 순서가 1인 자원 Rj를 할당 받기 위해서는 Ri를 우선 release해야 한다

→ Utilization 저하, Throughput 감소, Starvation 문제

발생하지 않을 Deadlock을 위해 제약 조건을 달아놓아야 해서 비효율적이다.

 

Deadlock Avoidance

  • Available이 Max보다 큰 프로세스에 대해서만 자원을 할당해준다
  • P1 → P3 → P4 → P2 → P0 순서로 수행가능하므로 deadlock이 절대 생기지 않음 (다른 순서도 가능)
  • 작은 Deadlock 가능성만 가지고도 할당을 하지 않으므로 비효율적

 

Deadlock Detection and Recovery

  • Recovery
    • Process termination
      • Deadlock에 연루된 프로세스를 모두 종료
      • Deadlock cycle이 소멸될 때까지 프로세스를 하나씩 종료
    • Resource Preemption
      • 비용을 최소화 할 victim 선정
      • Safe state로 rollback하여 프로세스를 재시작
      • Starvation 문제
        • 동일한 프로세스가 계속 victim으로 선정되는 경우
          • Cost factor에 rollback 횟수도 같이 고려

 

Deadlock Ignorance

  • Deadlock은 매우 드물게 발생 → 조치 자체가 더 큰 Overhead일 수 있음
  • Deadlock 발생 → 시스템 비정상 작동 사람이 감지 → 직접 Process 종료 등
  • UNIX, Windows 등 대부분의 범용 OS가 채택

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

 

데이터 접근

만약 연산 주체(E-Box)가 여러 개라면?

 

Race Condition(경쟁 상태)

  • S-box를 공유하는 E-box가 여럿 있는 경우
    • 메모리 주소공간(S-box), CPU 프로세서(E-box) → Multiprocessor system
    • 공유메모리를 사용하는 프로세스들
    • 커널 내부 데이터를 접근하는 루틴들 간(예: 커널모드 수행 중 인터럽트로 커널모드의 다른 루틴 수행 시)

 

Race condition 1 - OS에서 Interrupt handler vs kernel

  • kernel 명령 수행 중, interrupt 차단
  • 커널모드 running 중 interrupt가 발생하여 인터럽트 처리 루틴이 수행
    • 양쪽 다 커널 코드이므로, kernel address space 공유

 

Race condition 2 - 프로세스가 시스템 콜을 하여 커널 모드로 수행 중인데, context switch가 일어나는 경우

  • u : user mode / k : kernel mode
  • 해결책 : 커널 모드에서 수행 중일 때는 CPU를 선점(preempt)하지 않고, 사용자 모드로 돌아갈 때 선점

 

Race condition 3 - Multiprocessor에서 shared memory 내의 kernel data

  • 방법 1) 한 번에 하나의 CPU만이 커널에 들어갈 수 있게 하는 방법 (커널 전체에 대해 lock / unlock) → 비효율
  • 방법 2) 커널 내부에 있는 각 공유 데이터에 접근할 때마다 그 데이터에 대해 lock / unlock을 하는 방법

 

Process Synchronizatino 문제

  • 공유 데이터의 동시 접근(Concurrent access)은 데이터의 불일치 문제(Inconsistency) 발생 가능성
  • 일관성(Consistency) 유지를 위해 협력 프로세스 간 실행 순서 정해주는 메커니즘 필요
  • Race condition
    • 여러 프로세스들이 동시에 공유 데이터를 접근하는 상황
    • Race condition을 막기 위해 → Concurrent process는 동기화(Synchronize)되어야 한다.

 

The Critical-Section Problem

  • Critical-Section : 공유 데이터를 접근하는 코드
  • n개의 프로세스가 공유 데이터를 동시에 사용하기 원하는 경우
  • 각 프로세스의 code segment에는 공유 데이터를 접근하는 코드인 critical-section이 존재
  • Problem : 하나의 프로세스가 critical section에 있을 때, 다른 모든 프로세스는 critical section에 들어갈 수 없어야 한다

 

Critical-Section 문제를 해결하기 위한 초기의 시도

  • 아래는 프로세스들의 일반적인 구조
do {
    entry section
    critical section
    exit section
    remainder section
} while (1);
  • 프로세스들은 Synchronize를 위해 몇몇 변수를 공유할 수 있다 → Synchronization variable

아래에서 문제 해결을 알아보자

 

프로그램적 해결법의 충족 조건

  • Mutual Exclusion (상호 배제)
    • 한 프로세스가 Critical-section 부분을 수행 주이면, 다른 모든 프로세스들은 각자의 Critical-section에 들어가면 안 된다.
  • Progress
    • 아무도 Critical-section에 있지 않은 상태에서 critical section에 들어가고자 하는 프로세스가 있다면 들어가게 해주어야 한다.
  • Bounded Waiting (유한 대기)
    • 프로세스가 critical section에 들어가려고 요청한 후부터 허용될 때까지, 다른 프로세스들이 critical section에 들어가는 횟수에는 한계가 있어야 한다.

 

** 두 개의 프로세스 P1, P2가 있다고 가정

Algorithm 1

  • Synchronization variable : turn 사용
  • P0 프로세스의 코드
int turn = 0; // => Pi는 turn == i일 때 critical section에 들어갈 수 있음

do {
    while (turn != 0); // 자기 차례가 아니면 while문에서 대기
    critical section
    turn = 1;
    remainder section
} while (1);

→ Bounded waiting을 지키지 못함

 

Algorithm 2

  • Synchronization variables
    • boolean flag[2];
    • initially flag[all] = false;
    • flag[i] == trun → Pi가 CS에 들어갈 준비가 되었다.
  • Process Pi
do {
    flag[i] = true;
    while (flag[j]) ; // Pj가 CS에 있으면 while문에서 대기;
    critical section
    flag[i] = false // CS에서 나갈 때 flag를 false로
    remainder section
} while (1);
  • Mutual Exclusion을 만족하지만, Progress를 만족하지 않음
  • 두 프로세스가 모두 2행까지 수행 후, 끊임 없이 양보하는 상황이 발생할 수 있음

 

Algorithm 3 (Peterson’s Algorithm)

  • Algorithm 1, 2의 synchronization variables를 합친 알고리즘
  • Process Pi
do {
    flag[i] = true;
    turn = j;
    while (flag[j] && turn == j); // 상대가 CS에 들어가려하고, 상대 턴이면 대기
    critical section // 상대가 CS에 들어갈 의사가 없거나, 의사는 있지만 상대 차례가 아니면 진입
    flag[i] = false;
    remainder section
} while (1);
  • 3가지 충족 조건을 모두 만족; 2개의 프로세스에 대한 Critical-Section 문제를 해결
  • Problem : Busy Waiting!(=Spin lock) (계속 CPU와 Memory를 쓰면서 wait)
    • while문을 계속 돌면서 lock을 건다.

 

Synchronization Hardware

  • 하드웨어적으로 Test & modify를 atomic하게 수행할 수 있도록 지원한다면, 앞의 문제는 간단히 해결

  • 읽기와 쓰기가 하나의 Instruction으로 실행 → 도중에 CPU를 뺏기지 않음
  • a가 0이면 → 0을 읽어오고 1로 수정
  • a가 1이면 → 1을 읽어오고 1로 수정
  • Mutual Exclusion with Test & Set
// Synchronization variable:
boolean lock = false;

// Process Pi
do {
    while (test_and_set(lock));
    // lock이 0이면 -> 아무도 CS에 있지 않음 -> while문을 통과하고 1로 수정
    // lock이 1이면 -> while문에서 대기
    critical section
    lock = false;
    remainder section
} while (1);
  • 여전히 Busy waiting 문제 발생

 

Semaphores

  • 앞의 방식들을 추상화시킴
    • 추상 자료형을 사용 → 컴퓨터 내부에 구현된 실제 자료구조와 별개로, Object와 연산을 가지고 있는 자료형
  • Semaphore S
    • Integer variable
    • 아래의 두 가지 atomic 연산에 의해서만 접근 가능
      • P(S) → 공유 데이터를 획득하는 과정
        • while(S≤0) do no-op; → wait / 여전히 busy waiting
        • S—;
      • V(S) → 사용 후 반납하는 과정
        • S++;
  • Critical Section of n Processes
// Synchronization variable;
Semaphore mutex; // initially 1: 1개가 CS에 들어갈 수 있다

// Process Pi
do {
    P(mutex); // 양수면 감소시키고 CS 진입, 아니면 wait
    critical section
    V(mutex); // Semaphore 증가
    remainder section
} while (1);

 

Block / Wakeup Implementation

  • CS 진입 차례가 아닌 프로세스를 block해 Busy waiting 문제 해결
  • Semaphore를 아래와 같이 정의
  • typedef struct { int value; // semaphore struct process *L; // process wait queue } semaphore;
  • block : 호출한 프로세스를 suspend 시키고, 해당 프로세스의 PCB를 semaphore에 대한 wait queue에 넣음
  • wakeup(P) : 블록된 프로세스 P를 wakeup / 해당 프로세스의 PCB를 Ready queue로 옮김

  • P(S)
  • S.value--; // prepare to enter if (S.value < 0) // 음수면 block { add this process to S.L // block(); }
  • V(S)
  • S.value++; if (S.value <= 0) { remove a process P from S.L; wakeup(P); }
  • 추상 자료형에서 S는 자원의 개수를 나타냈지만, 지금 S.value는 기다리는 프로세스의 개수를 나타내는 값(음수로)

Busy-wait vs Block/Wakeup

  • Critical section의 길이가 긴 경우 Block/Wakeup이 적당
  • Critical section의 길이가 매우 짧은 경우 → Block/Wakeup 오버헤드가 Busy-wait 오버헤드보다 더 커질 수 있음
  • 일반적으로는 Block/Wakeup 방식이 더 좋음

 

Semaphore의 종류

  • Counting Semaphore
    • 도메인이 0 이상인 임의의 정수값
    • 주로 자원이 여러 개일 때, Resource counting에 사용
  • Binary Semaphore (=mutex)
  • 0 또는 1 → 자원이 1개
  • 주로 Mutual exclusion(lock/unlock)에 사용

 

Deadlock and Starvation

  • Deadlock(교착 상태) : 둘 이상의 프로세스가, 서로 상대방의 의해 충족될 수 있는 event를 무한히 기다리는 현상
    • S, Q가 1로 초기화된 Semaphore라 하자
     

  • Starvation
    • 프로세스가 suspend된 이유에 해당하는 Semaphore 큐에서 빠져나갈 수 없는 현상

 

Bounded-Buffer Problem

  • mutex, empty, full 은 각각의 Semaphore
  • mutex는 전체 lock/unlock을 관장

 

Readers-Writers Problem

  • 한 프로세스가 DB에 write 중일 때, 다른 프로세스가 접근하면 안됨
  • Read는 여럿이 동시에 해도 됨
  • readcount(Shared data) : 현재 DB에 접근 중인 Reader의 수
  • mutex(Synchronization variable) : readcount 접근(critical section)의 mutual exclusion 보장을 위해 사용
  • db : Reader와 Writer가 공유 DB 자체를 올바르게 접근하게 하는 역할
  • 처음 읽을 때 db에 P, 다 읽고 나갈 때 더이상 Reader가 없다면 V(db)
  • Reader가 다 빠져나가야만 Writer가 DB에 접근 가능
    • → Starvation 발생 가능!

 

Dining-Philosophers Problem

  • Philosopher의 행동
    • 밥 먹기 (양쪽 젓가락을 잡고)
    • 생각하기 (양쪽 젓가락을 놓고)
  • 위의 Solution의 문제점 : Deadlock의 가능성이 있음
    • 모두가 왼쪽 젓가락을 잡게 되면 → 오른쪽 젓가락을 잡는 코드를 모두가 기다리게 됨
    • 해결 방안
      1. n-1명의 철학자만 테이블에 동시에 앉을 수 있도록 한다.
      2. 젓가락을 두 개 모두 집을 수 있을 때만 젓가락을 집게 한다.
      3. 비대칭 : 짝수 철학자는 왼쪽, 홀수 철학자는 오른쪽 젓가락부터 집도록
  • 2번 해결 방안에 대한 코드

 

Semaphore의 문제점

  • 코딩하기 힘들다
  • 정확성의 입증이 어렵다
  • 자발적 협력이 필요하다
  • 한 번의 실수가 모든 시스템에 치명적 영향

→ Monitor 도입

 

Monitor

  • 프로그래밍 언어 레벨에서 제공하는 High-level synchronization construct
  • 동시 수행 중인 프로세스 사이에서 Abstract data type의 안전한 공유를 보장
  • 내부의 프로시저를 통해서만 공유 데이터에 접근할 수 있게 만듦

  • Monitor는 그 자체가 하나의 프로세스만 접근할 수 있음 (lock을 따로 걸 필요가 없다)
  • Synchronization 제약 조건을 명시적으로 코딩할 필요 없음
  • 프로세스가 모니터 안에서 기다릴 수 있도록 Condition variable 사용
    • condition x, y;

 

Problems solved by Monitor

 

 

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

[운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net](http://www.kocw.net/home/cview.do?cid=3646706b4347ef09)

프로그램은 CPU burst와 I/O burst가 번갈아서 진행된다.

Burst : 연속적으로 실행하고 있는 단계

  • I/O bound job : I/O burst가 잦은 프로그램
    • 짧은 CPU burst가 많은 수로 존재
  • CPU bound job : CPU burst 지속시간이 긴 프로그램
    • 긴 CPU burst가 적은 수로 존재
  • 여러 종류의 Job(=process)이 섞여 있기 때문에 CPU 스케줄링이 필요하다
  • Interactive job에게 적절한 response 제공 요망
  • CPU와 I/O 장치 등 시스템 자원을 골고루 효율적으로 사용
  • 공평하게보다는 효율적으로 CPU 자원을 분배할 필요성 (사람과의 상호작용 고려)

 

CPU Scheduler & Dispatcher

  • CPU Scheduler
    • Ready 상태의 프로세스 중에서 CPU를 넘겨줄 프로세스를 고른다
    • 운영체제 안의 코드로 존재
  • Dispatcher
    • CPU의 제어권을 넘기는 역할
      • 이 과정을 Context switch(문맥 교환)라고 한다.
    • 운영체제 안의 코드로 존재
  • CPU 스케쥴링이 필요한 경우는 다음과 같은 상태 변화가 있는 경우이다.
    1. Running → Blocked(eg: I/O 요청하는 시스템 콜)
    2. Running → Ready(eg: 할당시간 만료로 Timer interrupt)
    3. Blocked → Ready(eg: I/O 완료 후 인터럽트)
    4. Terminate2, 3 등 그 외 모든 스케줄링 → Preemptive (강제로 빼앗음)
    5. 1, 4 → Nonpreemptive (자진 반납)

 

성능 척도 (Scheduling Criteria)

  • CPU 입장에서
    • CPU utilization (이용률)
      • CPU가 가능한 바쁘게 유지하기
    • Throughput(처리량)
      • 단위 시간 당 완료하는 실행
  • 프로세스 입장에서
    • Turnaround time (소요시간, 반환시간)
      • 특정 프로세스를 실행하는 데에 걸린 시간 (Ready queue에 들어와서 실행을 마치고 나가기까지)
    • Waiting time (대기 시간)
      • 순수하게 기다린 시간(in ready queue)
      • CPU burst 동안에 생기는 대기까지 모두 포함
    • Response time (응답 시간)
      • Ready queue에 들어와서 처음 CPU를 얻기까지 걸린 시간
  • 위 얘기들은 프로세스가 실행되어 종료되기까지를 얘기하는 것이 아니라
  • → 한 번의 CPU burst에 있어서를 얘기하는 것!

 

FCFS (First-Come First-Served)

  • 프로세스 도착 순서대로 CPU 할당

  • P1 = 0 / P2 = 24 / P3 = 27 (Waiting time)
  • Average : 17

  • P2 = 0 / P3 = 3 / P1 = 6 (Waiting time)
  • Average : 3
  • 앞에 도착한 프로세스의 사용시간이 긴 경우 → 평균 Waiting time이 길어짐 (Convoy effect라고 함)
  • → 좋은 알고리즘이 아님

 

SJF (Shortest-Job-First)

  • 각 프로세스의 다음번 CPU burst time을 가지고 스케줄링에 활용
  • CPU burst time이 가장 짧은 프로세스를 제일 먼저 스케줄
  • Two schemes
    • Nonpreemptive : 일단 CPU를 잡으면, CPU burst 완료 시까지 CPU를 선점(preemption) 당하지 않음
    • Preemptive : 현재 수행 중인 프로세스의 남은 burst time보다 더 짧은 CPU burst time을 가지는 새로운 프로세스 도착 시 → CPU를 빼앗김 (SRTF : Shortest-Remaining-Time-First)
  • SJF is optimal for Waiting time
    • 주어진 프로세스들에 대해 Minimum average waiting time을 보장 (SRTF)

 

Nonpreemptive SJF 예제

  • P1 도착 후 바로 실행 → 나머지 모두 도착했으니, Burst가 짧은 P3 실행
  • Average waiting time = (0 + 6 + 3 + 7(순서대로)) / 4 = 4

 

Preemptive SJF(SRTF) 예제

  • 도착한 프로세스의 Burst time과 실행 중인 프로세스의 Remaining burst time을 비교
  • Average waiting time = 3
    • P1 = 9
    • P2 = 3
    • P3 = 0
    • P4 = 2

 

SJF의 문제점

  1. Starvation(기아 현상)
    1. → CPU burst time이 긴 프로세서는 너무 오래 실행되지 않을 가능성이 있음
  2. CPU Burst time 예측이 불가능함
    1. branch, user input 등이 있기 때문 
    2. 추정만이 가능 → 과거의 CPU burst time을 이용해서 추청 (exponential averaging)

 

Priority Scheduling

  • 각 프로세스에 우선 순위가 할당됨
    • 높은 우선 순위(작은 Integer)의 프로세스에게 CPU 할당
    • Preemptive와 Nonpreemptive
  • SJF는 일종의 Priority scheduling이다.
    • 우선 순위 → 다음 CPU burst time의 예측값이 낮은 순
  • 문제점 : Starvation(기아 현상) → Low priority 프로세스가 실행되지 않을 수 있다.
    • 해결 : Aging(노화) ㅍ 시간이 지남에 따라 Priority를 높인다.

 

Round Robin (RR)

  • 현대 운영체제 스케줄링은 RR에 기반
  • 각 프로세스는 동일한 크기의 할당 시간(time quantum)을 가짐
    • 일반적으로 10~100ms
  • 할당 시간이 지나면 프로세스는 선점(preempted)당하고 ready queue의 제일 뒤에 가서 다시 줄을 선다
  • n개의 프로세스가 ready queue에 있고 할당 시간이 q time unit인 경우, 각 프로세스는 최대 q time unit 단위로 CPU 시간의 1/n을 얻는다.
  • → 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다.
  • Performance
    • q large → FCFS(First-Come First-Served)
    • q small → Context switch 오버헤드가 커진다

  • 일반적으로 SJF보다 Average turnaround time이 길지만, response time은 더 짧다.

 

Multilevel Queue

  • Ready queue를 여러 개로 분할
    • 각 큐는 독립적인 스케줄링 알고리즘을 가짐
    • Foreground (interactive) : RR
    • Background (batch - no human interaction) : FCFS
  • 큐에 대한 스케줄링이 필요
    1. Fixed priority scheduling
      • Foreground 먼저 제공하고 Background 제공
      • Starvation 가능성
    2. Time slice
      • 각 큐에 CPU time을 적절한 비율로 할당
      • Eg., 80% to foreground in RR, 20% to background in FCFS

 

Multilevel feedback queue

  • 프로세스가 다른 큐로 이동 가능

 

Multiple-Processor Scheduling

  • CPU가 여러 개인 경우 스케줄링은 더욱 복잡해짐
  • Homogeneous processor인 경우 (균일한 프로세서)
    • Queue에 한 줄로 세워서 각 프로세서가 꺼내가게 할 수 있음
    • 특정 프로세서에서만 수행되어야 하는 프로세스가 있는 경우 → 문제가 복잡해짐
  • Load sharing
    • 일부 프로세서에 job이 몰리지 않도록 부하를 적절히 공유하는 메커니즘이 필요
    • 별개의 큐를 두는 방법 vs 공동 큐를 사용하는 방법
  • Symmetirc Multiprocessing (대등한, 대칭 CPU)
    • 각 프로세서가 각자 알아서 스케줄링 결정
  • Asymmetric Multiprocessing (비대칭 CPU)
    • 하나의 프로세서가 시스템 데이터 접근, 공유를 전담
    • 나머지 프로세스는 거기에 따름

 

Real-Time scheduling

  • Hard real-time systems : Task를 정해진 시간 안에 반드시 끝내도록 스케줄링
  • Soft real-time systems: 해당 Task의 Priority를 일반 프로세스에 비해 높게 설정

 

Thread Scheduling

  • Local Scheduling
    • User level thread의 경우 사용자 수준의 thread library에 의해 어떤 thread를 스케줄할지 결정
  • Global Scheduling
    • Kernel level thread의 경우 일반 프로세스와 마찬가지로 커널의 단기 스케줄러가 어떤 thread를 스케줄할지 결정

 

Algorithm Evaluation

 

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

 

프로세스 생성 (Process Creation)

  • 부모 프로세스가 자식 프로세스를 생성
  • 프로세스의 트리 형성(계층 구조)
  • 프로세스에게 필요한 자원
    • 운영체제로부터 받는다
    • 부모와 공유한다
  • 자원의 공유 방식 → 가능하면 공유하다가 COW(Copy-on-Write)
    • 부모와 자식이 모든 자원 공유하는 모델
    • 일부를 공유하는 모델
    • 전혀 공유하지 않는 모델
  • 수행(Execution)
    • 부모와 자식이 공존하며 수행되는 모델
    • 자식이 종료(Terminate)될 때까지 부모가 기다리는 모델
  • 주소 공간(Address space)
    • 자식은 부모의 공간을 복사함(+ OS data)
    • 그 공간에 새로운 프로그램을 올림
  • 유닉스의 예
    • fork() 시스템 콜이 새로운 프로세스를 생성
      • 부모를 그대로 복사
      • 주소 공간 할당
    • fork 다음에 이어지는 exec() 시스템 콜을 통해 새로운 프로그램을 메모리에 올림

 

프로세스 종료 (Process Termination)

  • 프로세스가 마지막 명령을 수행한 후 운영체제에게 이를 알려주는 경우(exit 시스템 콜)
    • 자식이 부모에게 output data를 보냄 (via wait)
    • 프로세스의 각종 자원들이 운영체제에게 반납됨
  • 부모 프로세스가 자식의 수행을 종료시키는 경우(abort 시스템 콜)
    • 자식이 할당 자원의 한계치를 넘어섬
    • 자식에게 할당된 Task가 더이상 필요하지 않음
    • 부모가 종료(exit)하는 경우
      • 운영체제는 부모 프로세스가 종료하는 경우 자식이 더이상 수행되도록 두지 않는다
      • 단계적인 종료

 

fork() 시스템 콜

  • 프로세스는 fork() 시스템 콜에 의해 생성된다
    • 생성된 새로운 주소 공간은, caller의 복제이다.
int main() {
    int pid;
    pid = fork();
    if(pid == 0) printf("\n Hello, I am child!\n");
    else if(pid > 0) printf("\n Hello, I am parent!\n");
}
  • fork() 메서드가 실행되면, 새로운 프로세스가 생성된다.
    • 이때, 생성된 프로세스는 부모 프로세스의 문맥을 그대로 이어 받아, fork() 메서드 실행 이후의 코드부터 실행한다.

 

exec() 시스템 콜

  • 프로세스는 exec() 시스템 콜을 통해 다른 프로그램을 실행한다.
    • 새로운 프로그램으로 caller의 메모리 이미지를 대체한다.
int main() {
    int pid;
    pid = fork();

    if(pid == 0) {
        printf("\n Hello, I am child!\n");
        execlp("/bin/date", "/bin/date", (char *) 0);
    }

    else if(pid > 0) {
        printf("\n Hello, I am parent!\n");
    }
}

/* date */
int main() {
    ...
}
  • fork()를 통해 복제된 자식 프로세스라면(if pid == 0) → execlp() 함수를 실행한다.

 

wait() 시스템 콜

  • 프로세스 A가 wait() 시스템 콜을 호출하면
    • 커널은 child가 종료될 때까지 프로세스 A를 sleep 시킨다(blocked 상태)
    • Child process가 종료되면 커널은 프로세스 A를 깨운다 (ready 상태)
int main {
    int childPID;
    S1;

    childPID = fork();

    if(childPID == 0)
        ...
    else {
        wait();
    }

    S2;
}

 

exit() 시스템 콜

  • 프로세스의 종료
    • 자발적 종료
      • 마지막 문장 수행 후(혹은 exit() 시스템 콜이 명시되어 있을 때) exit() 시스템 콜을 통해 이루어짐
      • main 함수 리턴 위치에 묵시적으로 컴파일러가 넣어줌
    • 비자발적 종료
      • 부모 프로세스가 자식 프로세스를 강제 종료시킴
        • 자식 프로세스가 한계치를 넘어서는 자워 ㄴ요청
        • 자식에게 할당된 태스크가 더이상 필요하지 않을 때
      • 키보드로 kill, break 등을 친 경우
      • 부모가 종료하는 경우
        • 부모 종료 전에 자식들이 먼저 종료됨

 

프로세스 간 협력

  • 독립적 프로세스 : 프로세스는 각자의 주소 공간을 가지고 수행되므로, 원칙적으로 다른 하나의 프로세스는 다른 프로세스의 수행에 영향을 미치지 못함
  • 협력 프로세스 : 프로세스 협력 메커니즘을 통해 영향을 미칠 수 있음
  • 프로세스 간 협력 메커니즘(IPC: InterProcess Communication)
    • 메시지 전달(Message passing) : 커널을 통해 메시지 전달
    • 주소 공간 공유(Shared memory) : 서로 다른 프로세스 간에도 일부 주소 공간 공유
    • ** Thread는 사실상 하나의 프로세스이므로 프로세스 간 협력으로 보기 어렵지만, 동일한 Process를 구성하는 Thread들 간에는 주소 공간을 공유하므로 협력이 가능

 

Message Passing

  • 프로세스 사이에 공유 변수를 일체 사용하지 않고 통신하는 시스템
  • Direct Communication : 통신하려는 프로세스의 이름을 명시적으로 표시

  • Indirect Communication : Mailbox(또는 Port)를 통해 메시지를 간접 전달

 

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

 

프로세스의 개념

  • “Process is a program in execution”
  • 프로세스의 문맥
    • 현재 프로세스를 규정하는 모든 정보
    1. 하드웨어 문맥
      • Program Counter
      • Register가 어떤 값을 가지고 있었는가
    2. 프로세스의 주소 공간
      • Code, Data, Stack
    3. 프로세스 관련 커널 자료 구조
      • PCB(Process Control Block)
      • Kernel stack

 

프로세스의 상태(Process State)

→ 프로세스는 상태가 변경되며 수행된다

  • Running
    • CPU를 잡고 Instruction을 수행 중인 상태
  • Ready
    • CPU를 기다리는 상태
    • 메모리 등 다른 조건은 모두 만족한 상태여야 함
  • Blocked(wait, sleep)
    • CPU를 주어도 당장 Instruction을 수행할 수 없는 상태
    • Process 자신이 요청한 event(예: I/O)의 수행을 기다리는 상태
      • 예) 디스크에서 file을 읽어와야 하는 경우 / 물리적 메모리에 주소 공간이 올라오지 않은 경우
  • New : 프로세스가 생성 중인 상태
  • Terminated : 수행(Execution)이 끝난 상태

 

Process Control Block(PCB)

  • 운영체제가 각 프로세스를 관리하기 위해 프로세스마다 가지고 있는 정보
  • 구성 요소는 아래와 같다(구조체로 유지)
    1. OS가 사용하는 정보
      • 프로세스 상태, 프로세스 ID
      • 스케쥴링 정보, 우선순위
    2. CPU 수행 관련 하드웨어 값
      • PC, Registers
    3. 메모리 관련
      • Code, Data, Stack의 위치 정보
    4. 파일 관련
      • 오픈하고 있는 파일들이 어떤 것인지

 

문맥 교환(Context Switch)

  • CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
  • CPU가 다른 프로세스에게 넘어갈 때
    • CPU를 내어주는 프로세스의 상태를 해당 프로세스의 PCB에 저장
    • CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴

  • 시스템 콜이나 인터럽트 발생 시, 반드시 문맥 교환이 일어나는 것은 아님

  • (1)의 경우에서 CPU 수행 정보 등 Context 일부를 PCB에 저장해야 하지만, 문맥 교환을 하는 (2)의 경우 부담이 훨씬 크다 (eg. Cache memory flush)

 

스케쥴러(Scheduler)

  • 숏텀 스케쥴러(CPU Scheduler)
    • 어떤 프로세스에 CPU를 줄지(어떤 프로세스를 다음번에 running시킬지) 결정
    • 충분히 빨라야 함(ms 단위)
  • 롱텀 스케쥴러(Job Scheculer)
    • 프로세스에 Memory(및 각종 자원)를 주는 문제
    • 시작 프로세스 중 어떤 것들을 Ready queue로 보낼지 결정
    • Degree of Multiprogrammimng을 제어(메모리에 올라가 있는 프로세스 수를 제어)
    • 우리가 사용하는 Time sharing system에서는 보통 롱텀 스케쥴러가 없음 (무조건 Ready)
      • 그럼 Degree of Multiprogramming을 어떻게 제어? → 미디엄텀 스케쥴러
  • 미디엄텀 스케쥴러(Swapper)
    • 여유 공간 마련을 위해 일부 프로세스를 통째로 메모리에서 디스크로 쫓아냄
    • 프로세스에게서 Memory를 뺏는 문제
    • Degree of Multiprogramming을 제어
      • 그럼 Swap된 프로세스는 Ready, Running, Blocked 중 어떤 상태인가?
    • → 새로운 상태 Suspended(stopped)

 

Suspended vs Blocked

  • Suspended(stopped)
    • 외부적인 이유로 프로세스의 수행이 정지된 상태
    • 프로세스 통째로 디스크에 Swap out 된다
    • 예시)
      • 사용자가 프로그램을 일시 정지
      • 시스템이 여러 이유(메모리가 가득참 등 → 미디엄텀 스케쥴러)로 프로세스를 잠시 중단
  • Blocked : 자신이 요청한 event가 만족되면 Ready
  • Suspended : 외부에서 resume해주어야 Active(Running, Ready, Blocked의 상태)

  • 시스템 콜이 있으면 → OS가 Running이라고 표현하지 않는다
    • 프로세스가 스스로의 코드를 동작하고 있으면 user mode
    • 프로세스가 시스템 콜을 하면 monitor mode(커널 모드) 상태라고 한다.

 

Thread(쓰레드)

  • Thread는 CPU 동작의 가장 기초가 되는 단위이다.
  • 프로세스의 하위 개념으로, 동일한 동작을 하는 프로세스를 하나로 묶어놓은 것
  • Thread의 독자적인 구성 → 실행을 위한 것들
    • Program Counter
    • Register Set
    • Stack Space
  • Thread가 동료 Thread와 공유하는 부분 (= Task)
    • Code section
    • Data section
    • OS resources
  • 전통적인 개념의 프로세스(Heavyweight process)는 하나의 Thread(Lightweight process)를 가지고 있는 Task로 볼 수 있다

 

Thread의 장점

  • 하나의 Thread가 blocked 상태인 동안에도, 동일한 Task 내의 다른 Thread(동료 Thread)가 running되어 빠른 처리를 할 수 있다.
    • eg) Multi-threaded Web : 웹 페이지 → HTML 받아오고 → HTML 안에 렌더링할 이미지를 받아오는 동안(별도의 Thread) + 텍스트라도 먼저 Display(별도의 Thread)
  • 메모리 공간을 절약할 수 있다.
    • Binary code, Data, Resource of the process를 공유할 수 있음
  • 경제성(빠른 속도)
    • 프로세스를 만드는 것보다 Thread를 추가하는 것, 프로세스 문맥 교환보다 Thread 스위칭이 훨씬 빠름
    • Solaris의 경우 두 가지 Overhead가 각각 30배, 5배
  • 병렬성을 높일 수 있다. (CPU가 여러 개라면 → 각 CPU에 다른 Thread를 할당!)

 

커널 쓰레드, 유저 쓰레드

  • Kernel Threads → 커널이 쓰레드의 존재를 알고 직접 관리
  • User Threads → 커널은 쓰레드의 존재를 모르고, 프로세스 본인이 내부에서 쓰레드를 생성하고 관리
    • 제약이 있음

 

 

 

 

 

 

반응형
반응형

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

http://www.kocw.net/home/cview.do?cid=3646706b4347ef09

 

운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net

컴퓨터 시스템 구조

  • 우측 장치들은 I/O 장치
  • CPU : 명령을 처리
  • Memory : CPU의 작업 공간
  • Interrupt : 특정 이유로 작업권을 넘김 (I/O 장치의 입력, 처리 완료 등)
  • Timer : CPU를 점유하는 시간을 측정하고, 너무 길면 멈추게 하는 하드웨어
    • Time sharing 구현에 이용
  • I/O 장치들은 각각의 Controller(일종의 작은 CPU)가 관리하고 처리한다
  • 초기에는 OS가 CPU를 사용하고, 이후에는 순차적으로 사용자 프로그램과 OS가 CPU를 사용한다

 

Mode bit

  • 1 : 사용자 모드 → 사용자 프로그램 수행
  • 0 : 모니터 모드(커널 모드) → OS 코드 수행
  • 사용자 프로그램은 나쁜 짓을 할 수 있기 때문!
  • 보안을 해칠 수 있는 중요 명령어는 모니터 모드에서만 수행 가능한 ‘특권 명령’으로 규정

 

Interrupt

  • 인터럽트 당한 시점의 레지스터와 Program counter를 save한 후, CPU의 제어를 인터럽트 처리 루틴에 넘긴다.
  • 하드웨어 인터럽트 : 하드웨어(I/O 장치 등)가 발생시킴
    • Timer, I/O장치의 Controller 등
  • 소프트웨어 인터럽트(Trap) : 넓은 의미로 포함되는 개념 / Exception, System call(사용자 프로그램이 커널 함수 호출)
  • 인터럽트 벡터 : 해당 인터럽트 처리 루틴 주소를 가지고 있음
    • 인터럽트 처리 루틴(인터럽트 핸들러) : 해당 인터럽트를 처리하는 커널 함수
  • 현대의 운영체제는 인터럽트에 의해 구동됨!

 

 

입출력(I/O)의 수행

  • 모든 입출력 명령은 특권 명령 → 사용자 프로그램은 어떻게 I/O를 하는가?
    • System call(Trap의 일종) → 운영체제에 I/O 요청
    • 올바른 요청인지 OS가 확인 후 수행

 

동기식/비동기식 입출력

  • 동기식 입출력(Synchronous I/O)
    • I/O를 요청하고, 입출력 작업이 완료된 후에 사용자 프로그램에게 제어가 넘어감
      • 구현 방법 1 : I/O 끝날 때까지 CPU 낭비
      • 구현 방법 2 : I/O 완료될 때까지(해당 프로그램을 I/O 처리를 기다리는 줄에 세워 놓고) 다른 프로그램에게 CPU를 줌
  • 비동기식 입출력(Aynchronous I/O)
    • I/O 요청 직후 제어가 사용자 프로그램에 넘어감(입출력 요청과 입출력이 별도의 싸이클)

  • 두 경우 모두 I/O 완료는 인터럽트로 알려준다.

 

DMA(Direct Memory Access)

  • 입출력 장치를 빠르게 처리하기 위함
  • CPU 중재 없이, Device controller가 Device buffer storage 내용을 메모리에 Block 단위로 직접 전송
  • Byte가 아닌 Block 단위로 인터럽트를 발생시킴

 

저장장치 계층 구조

  • Primary(Registers, Cache Memory, Main Memory)
    • 빠르고 비쌈 → 용량이 낮음
    • 휘발성
    • CPU에서 직접 접근 가능(Executable)
  • Secondary
    • 느리고 쌈 → 용량이 큼
    • 비휘발성
    • CPU에서 직접 접근 불가능
  • Caching이란? → 재사용을 목적으로, 하위 메모리에서 불러온 정보를 보다 빠른 메모리에 임시로 저장하는 것

 

프로그램의 실행(Memory load)

  • File System에 저장된 파일을 실행하면 → Virtual Memory를 거쳐 → Physical memory(Virtual Memory의 반대 개념)에 프로세스로 들어감
  • Virtual Memory(가상 메모리) : 특정 프로세스 할당되는, 0번지부터 시작하는 가상의 주소 공간
  • Kernel Address space를 확대하면 아래와 같다

 

 

 

 

 

 

 

 

 

 

반응형
반응형

** KOCW에서 이석복 교수님의 네트워크(2015년) 강의를 수강한 내용을 정리한 글입니다.

http://www.kocw.net/home/search/kemView.do?kemId=1169634

 

컴퓨터네트워크

인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.

www.kocw.net

 

 

Application layer에 대해 알아볼 예정

 

계층 구조 (- 각각의 대표적인 프로토콜) → 탑 다운 방식으로 살펴볼 예정

Application - HTTP

Transport - TCP / UDP

(이상은 라우터에는 존재하지 않고, 네트워크 엣지에만 존재)

Network - IP

Link - WiFi / LTE / 3G / Ethernet

Physical

HTTP에 대해서 알아보자

 

 

Client-server architecture

  • Server
    • Always-on host
    • 고정된(Permanet) IP address
  • Client
    • Server와 통신
    • 동적 IP를 가지고 있을 것임
  • 서로 다른 host(컴퓨터)에 올라와 있는 프로세스(각각 서버, 클라이언트) 사이의 통신을 애기하는 중
  • 같은 host에 올라와 있는 프로세스 간 통신은(IPC - Inter-Process Communication) OS에서 처리
  • 통신 메시지를 주고 받는 공간을 Socket이라고 함
  • 양단을 연결하려면 주소가 특정되어야 함 → IP(컴퓨터 특정) + Port(프로세스에 물린 소켓 특정)의 조합으로 특정
    • IP를 DNS(Domain Name System)에 의해 별도의 주소(이름)로 연결할 수 있음
    • port 입력 안 하면 → 자동으로 80번
    • naver.com:80 해도 연결됨, 8080은 안됨
    • 우리가 알고 있는 모든 웹 서비스들이 80번 포트를 씀 → DNS를 쓰기 때문에, port 넘버는 80번으로 통일하자는 암묵적 합의

 

App은 Transport 계층에 이런 것을 원한다

  • Data integrity : 데이터 무결성
  • Timing : 낮은 딜레이 보장
  • Throughput : 최소한의 데이터 양 보장
  • Security : 보안

하지만 TCP에서 Data integrity를 제공하지만 UDP는 그마저도 안 해주고, 나머지 기능은 제공하지 않는다 → Application layer에서 처리해야 함

 

 

App들의 프로토콜 사용 예시

 

 

HTTP란?

  • HyperText Transfer Protocol
  • 웹의 Application layer protocol
  • Client / Server model
    • Client : 웹 오브젝트를 요청, 수신, 화면에 표시하는 브라우저
    • Server : Response에 담긴 오브젝트를 요청한 곳에 전달하는 웹 서버
    • 모두 HTTP를 사용
  • 쉽게 생각하면, Reqeust를 보내고 Response를 받아오는 프로토콜(규격, 방식)

 

 

HTTP는 기저에 TCP 서비스를 사용 → TCP Connection을 생성해야 한다.

  • Client는 서버에 TCP Connection을 실행(Socket 생성) (port 80)

→ Server는 Client에서 온 TCP Connection을 수용

→ HTTP 메시지가 브라우저(HTTP Client)와 웹 서버(HTTP Server) 사이에서 교환됨

→ TCP Connection 종료

 

 

HTTP는 “stateless(무상태)” 하다

→ Server는 Client의 과거 요청 정보(state)를 가지고 있지 않는다

만약 state를 유지하는 Protocol이라면?

  • 과거 기록이 계속 유지되어야 한다
  • 만약 Server나 Client가 충돌하면 → view의 상태는 일관성이 없어지고, 반드시 조정되어야 한다.

 

HTTP Connections

HTTP는 TCP Connection을 non-persistent(비영구적) / persistent(영구적)으로 사용하는지에 따라 분류된다.

  • Non-persistent HTTP
    • 1개의 오브젝트를 전송하면 TCP Connection을 바로 닫는다
    • 실제로는 파이프라인과 결합하여, n개의 메서드를 전송하고 Connection을 닫는 방식을 사용함

 

 

 

 

 

 

반응형

+ Recent posts