데린이 성장 일지

객체 지향 설계(OOP)

컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 객체들의 상호작용(메시지 주고받기, 데이터 처리 등)으로 프로그램 로직을 구성하는 포로그래밍 패러다임

객체

대상을 나타내는 단어

현실의 모든 것을 객체라고 간주할 수 있습니다.

클래스

사람들은 일반적으로 같은 속성들을 갖고 있는데, 여기서 속성이란 눈, 코, 입, 손, 발, 등의 신체들을 의미한다고 하면,

사람같은 객체들이 공통적으로 갖는 속성들을 모아서 정의내린 것을 클래스라고 합니다.

ex) 객체: 붕어빵, 클래스: 붕어빵 틀

OOP 4가지 특징

1. 캡슐화(Encapsulation)

캡슐화란 하나의 객체에 대해 그 객체가 특정한 목적을 위해 필요한 변수나 메소드를 하나로 묶는 것을 의미합니다.

따라서 클래스를 우리가 만들 때 이후에 이 클래스에서 만들어진 객체가 특정한 목적을 가지고 사용해야할 변수와 그 변수를 가지고 특정한 메서드를 관련성 있게 클래스에 구성해야한다.

예를 들자면, 은행이라는 클래스는 잔고라는 변수가 있고 그 잔고를 조회하거나, 잔고를 수정할 수 있는 메서드등이 있다고 치는 것입니다. 

근데 캡슐화를 하는 중요한 목적은 바로 정보의 은닉화입니다.

잔고라는 변수가 만약 public 으로 선언되어있다고 치면, 200만원인 나의 잔고가 누군가 접근에 의해 0원이 될수도 있는 것입니다.

따라서 잔고라는 변수를 바로 접근할 수 없도록 private로 선언하고 데이터를 보호하는 것입니다.

이렇게 보호된 변수는 getter나 setter등의 메서드를 통해서만 간접적으로 접근이 가능하도록 하는 것이 바로 캡슐화의 중요한 목적입니다.

2. 추상화(Abstraction)

추상적으로 생각해 일단 큰 틀의 클래스를 구현하고 거기에 최소 이러한 공통적인 요소나 필수적인 요소를 추출하여 만든 것이 추상클래스입니다.

예를 들자면, 벤츠,아우디,소나타,티코,밴틀리 등등 우리가 생각하는 여러종류의 자동차이 있다. 이것을 다 클래스화하고 변수와 메서드 등을 개별적으로 만드는 것은 무모한 짓입니다.

따라서 방금 나열한 자동차들의 공통적인 요소나 특징을 추출하는 과정인 추상화를 거쳐 요소를 끄집어 내면, 바퀴,배기통,핸들,차문,유리창,등 필수적인 부품이 있고 바퀴는 굴러가야하며, 핸들은 좌우로 돌아가야하고 차문은 열려야한다는 공통적인 행동 즉 어떤 차든 필수적으로 필요한 메서드가 추출됩니다.

3. 다형성(Polymorphism)

다형성은 상속을 통해 기능을 확장하거나 변경하는 것을 가능하게 해준다. 이를 통해 코드의 재사용, 코드길이 감소가 되어 유지보수가 용이하도록 도와주는 개념입니다.

쉽게 같은 동작이지만 다른결과물을 나올때 이를 다형성이라고 생각하면 됩니다.

크게 자바프로그래밍 객체지향에서 다형성의 개념을 녹여내는 방법은 두가지인데, 바로 오버라이딩(Overriding) 과 오버로딩(Overloading) 입니다.

• 오버라이딩: 부모클래스에서 상속받은 서브클래스 즉 자식클래스에서 부모클래스,즉 상위클래스에서 만들어진 메서드를 자신의 입맛대로 다시 재창조해서 사용하는 것을 말합니다.
• 오버로딩: 하나의 클래스 안에서 같은이름의 메서드를 사용하지만 각 메서드마다 다른 용도로 사용되며 그 결과물도 다르게 구현할 수 있게 만드는 개념인데 오버로딩이 가능하려면 메서드끼리 이름은 같지만 매개변수의 갯수나 데이터타입이 다르면 오버로딩이 적용되어 메서드 이름이 같아도 문법 에러가 나지않습니다.

4. 상속성(Inheritance)

상속이란 기존 상위클래스에 근거하여 새롭게 클래스와 행위를 정의할 수 있게 도와주는 개념입니다.

기존클래스에 기능을 가져와 재사용할 수있으면서도 동시에 새롭게 만든 클래스에 새로운 기능을 추가할 수 있게 만들어 준다.

자바에선 단일 상속 밖에 안되지만, 인터페이스를 다중 상속 할 수 있게 해서 임시적인 다중 상속이 가능합니다.

하지만 인터페이스의 존재 이유가 다중 상속을 지원하기 위함이 아닙니다.

Java 특징

자바는 OS에 대해 독립적인 특징을 가지고 있습니다.

그 이유는 JVM이라는 가상 머신 위에서 자바가 동작하기 때문입니다.

자바는 객체지향 프로그래밍 언어로, 캡슐화, 상속, 다형성 등의 객체지향 개념을 지원합니다.

이 덕분에 코드의 재사용이 높아지고, 유지보수가 쉽습니다.

JVM

JVM의 역할은 자바 애플리케이션을 클래스 로더를 통해 읽어 들여 자바 API와 함께 실행하는 것입니다.

Java와 OS 사이의 중개자로써 java가 독립적으로 작동이 가능하게 합니다.

또한 가장 중요한 메모리 관리, 가비지 컬렉션(GC)를 수행합니다.

JVM 특징

• 컴파일된 바이트 코드를 기계가 이해할 수 있는 기계어로 변환
• 스택 기반의 가상 머신
• 메모리 관리와 GC를 수행

JVM 구조

JVM 구조는 크게 Garbage Collector(GC), Execution Engine, Class Loader, Runtime Data Area로 나누어져 있습니다.

• Garbage Collector(GC): 메모리 관리 기법 중 하나로, Heap 영역에 배치된 객체들을 관리하는 모듈입니다.
• Execution Engine: class파일과 같은 ByteCode를 실행 가능하도록 해석합니다.
• Class Loader: 클래스 파일을 Runtime Data Area의 메서드 영역으로 불러오는 역할을 합니다.
• Runtime Data Area: 프로그램을 수행하기 위해 OS로부터 할당받은 메모리 영역입니다.

Runtime Data Area

• Native Method Stacks: 메서드의 정보가 기계어(바이트 코드)로 저장되는 공간
• JVM stack: 메서드가 실행되는 공간(지역변수, 매개변수들이 만들어지는 공간)
• PC Register: CPU에 직접 접근하지 않고 스택에서 주소 가져와 저장되는 공간
• Heap: 객체가 생성되는 메모리 공간, GC에 의해 메모리 관리가 되는 영역
• Method Area: JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드에 대한 정보, static 변수, 메서드의 바이트 코드들이 할당되는 메모리 공간
• Runtime Constant Pool: 리터럴(Literal) 풀이라고도 하며, 상수 값이 할당되는 메모리 공간, 문자열 중 문자열 상수가 할당되는 메모리 공간

메인 클래스가 동작되는 방식

JVM이 실행할 클래스를 탐색

static 키워드가 붙어있는 멤버들을 정해진 메모리(static-zone) 위치에 한 번 자동으로 로딩

    - static 멤버들은 클래스를 사용하는 시점에서 딱 한 번 메모리에 로딩된다는 점이 중요

JVM이 static-zone에서 main() 메서드를 호출

호출된 메서드를 Call Stack Frame Area(Stack Area)에 기계어 코드를 넣은 뒤 동작을 시작

    - stack에 아무 것도 없다면 프로그램 종료

시스템 프로그래밍

운영체제, 하드웨어와의 상호작용을 프로그래밍 하는 것

커널이 제공하는 기능을 직접 제공받으며 low-level에서 동작하는 프로그램을 작성하는 것

 * 커널이 제공하는 기능 -> 시스템 콜 주로 활용

파일 디스크립터

프로세스는 운영체제로부터 파일을 할당받는데,
파일을 식별하기 위해 운영체제로부터 할당받는 정보가 파일 디스크립터

• 입출력장치, 파이프, 소켓도 파일 디스크립터로 식별

일반적으로 0 이상의 정수 형태
프로세스가 파일을 열거나 생성할 때 운영체제는 해당 파일에 대한 파일 디스크립터 할당
저수준에서 파일을 식별하는 정보

※ 고정된 파일 디스크립터 값(표준 입출력)

• 0번 : 표준 입력 (키보드)
• 1번: 표준 출력 (모니터)
• 2번: 표준 에러

파일 포인터

파일을 스트림처럼 읽고 쓰기 위한 자료형 -> 편리한 함수 기능 많음
파일 디스크립터가 저수준에서 파일 식별하는 정보라면 파일 포인터는 고수준 파일 식별 정보

하드링크와 심볼릭링크

아이노드
파일 이름을 제외한 모든 것을 가리키고 있는 색인 블록
아이노드를 사용하는 이유
외부 단편화
작업보다 많은 공간이 남아 있더라도 실제로 그 작업을 받아 들이지 못하는 경우

ex)연속적으로 파일을 a,b,c,d,e으로 할당되있고 프로세스가 끝나서 a,b,c인 파일(크기가 3)이 삭제 된 후 a,b,c,d에 새로운 파일(크기가 4)을 할당할 수 가 없어진다. 

아이노드 조회
ls -i, stat

아이노드 사용량이 100퍼로 찼을 경우 저장장치에 용량이 남아있어도 파일 생성 불가

하드링크
하드링크 생성시 같은 아이노드를 공유하는 하드 링크 파일이 생성됨
하드 링크 파일은 원본 파일과 같은 데이터 공유
원본 파일이 삭제/이동해도 하드 링크 파일은 남아있음
여러 이름으로 파일을 참조하고 싶을 때 사용

하드링크 생성하기(리눅스)
ln [원본파일이름] [하드링크파일이름]

심볼릭링크
심볼릭링크 파일(소프트링크, ex) 윈도우의 바로가기)
심볼릭링크 생성시 원본 파일을 가리키는 새로운 아이노드를 만든다
원본 파일과 같은 데이터를 공유하지 않음(원본 파일의 위치만 알 뿐)
원본 파일이 삭제/이동하면 심볼릭 링크 파일은 사용 불가
하드 링크 파일에 비해 조작이 간편
복잡한 경로에 있는 파일을 참조하고자 할 때 사용

심볼릭 링크 생성하기(리눅스)
ln -s [원본파일이름] [심볼릭링크파일이름]

파일 속성 다루기

파일 속성
파일
보조기억장치의 의미있는 정보의 집합

구성요소
이름, 실행하기 위한 정보, 부가 정보

stat -c %명령어
%명령어에 따라 stat 정보에서 원하는 것을 뽑아낼 수 있음

파일(+디렉터리) 접근 단위: 블록
섹터 단위로 접근하지 않음

파일 메모리 매핑

프로세스 메모리 영역에 파일의 내용 일부에 대응시키는 것
디스크에 있는 파일에 읽고 쓰는 것(파일 입출력)이 아니라 프로세스 메모리 영역에 읽고 쓰기
-> lseek의 번거로움 감소, 불필요한 시스템 콜 호출 횟수 감소
두 개 이상의 프로세스가 같은 영역을 매핑할 경우 다른 프로세스와의 통신 가능
매핑은 페이지 단위(페이지 배수)로 이루어짐

프로세스 다루기

프로세스란 실행 중인 프로그램 -> 같은 프로그램이라도 별도의 프로세스일 수 도 있음
포그라운드 프로세스, 백그라운드 프로세스

프로세스 제어 블록(PCB)
PID(PPID), 레지스터, 스케줄링 정보, 메모리 정보, 사용한 파일 정보, 입출력장치 정보

대표적인 프로세스 상태
생성
준비 W
실행 R
대기 S
종료 S
Z: Zombie: 프로세스 종료 후 자원이 반환되었지만 커널 영역에 프로세스가 남아있는 상태

프로세스는 계층적 구조로 되어있음
fork: 복사본 만들기 -> 부모 프로세스가 자기 복제본으로 자식 프로세스를 만듦
exec: 새로운 코드로 대체(덮어쓰기)

스레드 다루기

스레드
프로세스를 구성하는 실행 흐름의 단위
각기 다른 스레드 ID, 프로그램 카운터, 레지스터, 스택

프로세스 간에는 기본적으로 자원을 공유하지 않음
스레드 간에는 프로세스의 자원을 공유

프로세스 간에도 자원 공유가 가능하다 -> 프로세스간 통신 IPC
공유 메모리를 통한 통신, 파이프를 통한 통신, 네트워크 소켓을 통한 통신 등

공유 메모리 기반 IPC

공유 메모리
다수의 프로세스가 공유 가능한 메모리 영역
공유하는 메모리를 읽고 씀으로써 프로세스간 통신이 가능

파이프 기반 IPC

pipe란
단반향 IPC 도구
한 쪽에서는 파이프를 읽고, 한 쪽에서는 파이프에 쓴다
주로 Stream 형태의 데이터를 주고받을 때 사용
파이프는 일종의 파일: file descriptor를 기반으로 읽고 쓰기 수행
파이프에 더이상 쓸 공간이 없을 때 쓰면 block
파이프가 비어 있을 때 읽기를 시도하면 block
지나치게 큰 값(리눅스의 경우 4KB 이상) 쓰기 지양

양방향 통신 시 필요하지 않는 디스크립터는 닫아줘야한다. ex)부모에서 자식으로 갈 때는 부모의 읽기와 자식의 쓰기 디스크립터를 닫고 자식에서 부모로 갈 때는 부모의 쓰기와 자식의 읽기 디스크립터를 닫아준다.

시그널

시그널이란
소프트웨어 인터럽트
프로세스에게 특정 이벤트가 발생했음을 알리는 수단
다양한 시그널이 있고, 시그널 종류별로 번호가 할당되어 있다

대표적인 시그널
SIGCHLD: child stopped or terminated
SIGILL: illegal instruction
SIGINT : interrupt from keyboard (ctrl+c)
SIGKILL: kill signal (처리 불가능)
SIGSEGV: invalid memory reference
SIGTERM: termination signal (처리가능)
SIGUSR1: user-defined signal 1
SIGCONT: continue if stopped
SIGSTOP: stop process(처리 불가능)

시그널마다 기본 동작이 정해져 있고, 처리가 가능한 것들이 있다

소켓 프로그래밍

소켓
네트워크를 경유하는 프로세스 간 통신의 종착점

소켓의 구성 요소
TCP + IP 혹은 UDP + IP
출발지 IP 주소
출발지 포트 번호
목적지 IP 주소
목적지 포트 번호

소켓은 특별한 형태의 파일이라 볼 수 있다
파일 열기, 닫기, 쓰기, 읽기
소켓 열기, 닫기, 송신하기, 수신하기

소켓은 프로세스 간 통신 기법(IPC)의 일종이다
수신 프로세스 & 송신 프로세스

TCP 소켓, UDP 소켓
TCP -> 연결 지향형
UDP -> 비연결지향형

컴퓨터 네트워크

여러 장치들이 서로 정보를 주고받을 수 있는 통신망

인터넷
네트워크의 네트워크

컴퓨터 네트워크 구성 요소
노드, 메세지, 간선(통신 링크)

노드
종단 시스템, 호스트
메세지를 최초로 송신, 생성하는 대상
주소를 통해 위치 특정

• 유니캐스트: 1대1 통신
• 브로드캐스트: 현재 네트워크에 있는 모든 대상에게 메세지 전송
• 멀티캐스트: 네트워크 내 특정 그룹에게만 메세지 전송

클라이언트
요청을 보내는 호스트

서버
응답을 보내는 호스트

(중간) 노드
네트워크 장비
라우터, 스위치, 공유기 등
호스트와 배타적 개념은 아님

간선(통신 링크)

통신 매체
유선 케이블(트위스티드 페어 케이블, 광케이블)
무선(와이파이)

메세지
주고받는 정보
웹 페이지, 사진, 동영상 등

LAN
근거리를 연결한 네트워크
사무실, 가정 정도의 네트워크

WAN
원거리를 연결한 네트워크
ISP(KT, LG U+, SK 브로드밴드)에 의해 구축
ISP: 인터넷에 접속하는 수단을 제공해주는 주체

네트워크로 주고받는 정보

패킷 교환 네트워크
주고받는 정보를 패킷(packet) 단위로 주고받는 네트워크
패킷: 패킷 교환 네트워크에서 주고받는 데이터 단위

회선 교환 네트워크
정해진 회선(circuit)으로만 통신하는 네트워크
사전에 연결 수립 작업
다른 호스트는 도중에 끼어들 수 없음
장점: 전송률 보장
단점: 회선 이용률 저하

패킷 구성 요소
헤더(header): 패킷에 붙일 부가 정보
페이로드(payload): 패킷에 보낼 정보
(트레일러(trailer)): 패킷 뒤에 붙일 부가정보

프로토콜(protocol)
장비 간 정보를 주고받을 규칙이나 방법
호스트 간에 합의된 의사소통 규칙
헤더의 내용은 프로토콜의 영향을 받는다
포로토콜이 달라지면 헤더의 내용이 달라질 수 있다.

네트워크 참조 모델

송수신 과정에서의 정형화된 단계
네트워크 4계층
송신 4 -> 1, 수신 1 -> 4

OSI 7계층 모델(이론 구상 모델)

• 물리 계층(1 계층)
  0, 1
• 데이터링크 계층(2 계층)
  MAC 주소
• 네트워크 계층(3 계층)
  LAN 간의 통신 = IP
• 전송 계층(4 계층)
  포트
• 세션 계층(5 계층)
  연결 관계 유지 수립
• 표현 계층(6 계층)
  압축, 인코딩
• 응용 계층(7 계층)
  HTTP

TCP/IP 4계층 모델(실제 구현 모델)

• 네트워크 엑세스 계층
  OSI의 1,2 계층과 비슷
• 인터넷 계층
  OSI의 3 계층과 비슷
• 전송 계층
  OSI의 4 계층과 비슷
• 응용 계층
  OSI의 5,6,7 계층과 비슷

캡슐화(encapsulation)
상위 계층으로부터 내려받은 패킷을 페이로드로 삼아 상위 계층으로부터 받은 정보에 프로토콜에 걸맞는 헤더(혹은 트레일러)를 덧붙이는 것

역캡슐화(decapsulation)
캡슐화 과정에서 붙인 헤더(및 트레일러)를 각 계층에서 제거하는 것

PDU
각 계층에서 캡슐화된 데이터

• 응용, 표현, 세션 계층
  데이터
• 전송 계층
  TCP: 세그먼트, UDP: 데이터그램
• 네트워크 계층
  IP 패킷
• 데이터링크 계층
  프레임
• 물리 계층
  비트

와이어샤크
본인 인터넷 상에서 날라다니는 패킷들을 관찰할 수 있는 도구

트래픽

특정 시간 동안 네트워크 내 정보 흐름
얼마나 많은 패킷들이 한 순간 몰리는가
트래픽이 몰린다 -> 과부화/오버헤드

전송속도
bps(b/s, bits per second)
Mbps(Mb/s)
Gbps(Gb/s)
기대 가능한 속도

처리율(Throughput)
bps
Mbps
Gbps
단위 시간 동안 네트워크를 통해 전송되는 데이터 양

전송속도보다 현실적인 지표

대역폭(bandwidth)
네트워크 트래픽을 수용할 수 있는 용량
송수신 가능한 최대 데이터 양
전송 매체의 두께

패킷 손실
얼마나 많은 패킷이 송수신 과정에서 손실되었는가
보통 백분율로 표기
ping [주소]로 확인할 수 있음

네트워크 엑세스 계층

물리, 데이터링크의 역할을 한다고 볼 수 있음

이더넷

현대 (유선) LAN에서 가장 대중적으로 사용되는 기술
물리 계층, 데이터 링크 계층(네트워크 엑세스 계층) 케이블 스펙/프로토콜 정의

이더넷 기술
물리 계층: 이더넷으로 통신이 가능한 케이블
데이터 링크: 이더넷 프레임

이더넷은 현재까지도 발전 중인 기술
이더넷 국제 표준: IEEE 802.3
이더넷 표준 규격 버전: 802.3 뒤 알파벳
이더넷 표준 규격이 달라지면 케이블, 전송 속도 등이 달라질 수 있다

이더넷 케이블을 지칭할 때: 전송속도 BASE-추가 특성
ex) 25GBASE-LR

이더넷 프레임: 이더넷 네트워크에서 주고받는 데이터 형식

헤더에 포함된 정보

• 프리앰블
  이더넷 프레임의 시작을 알리는 비트열, 송수신간의 동기화
  첫 7바이트는 10101010, 마지막 1바이트는 10101011(SFD)
• 목적지/송신지 MAC 주소
  물리적 주소, 네트워크 장치(NIC)마다 할당된 고유한 주소
  네트워크 세상의 주민등록번호
  NIC(네트워크 인터페이스)
  연결 매체를 통해 받은 신호를 컴퓨터에게 전달
  네트워크에 연결하기 위한 하드웨어
  연결 매체와 호스트 연결(LAN에 접속하기 위한 하드웨어)
  프레임 판단, 폐기 -> 맥주소에 맞는 데이터만 받음
  속도
• 이더타입/길이
  1536 이상일 경우 이더타입(이 프레임이 무엇을 캡슐화했는지) ex) 0800 -> IPv4를 캡슐화
  1500 이하일 경우 프레임 크기
• 페이로드
  운반할 데이터

트레일러에 포함된 정보

• FCS
  오류 검출을 위한 CRC 값을 위한 필드

허브

물리 계층의 장비
MAC 주소를 사용하지 않는다(MAC 주소는 데이터 링크 계층 개념)
호스트를 연결할 수 있는 포트
주소 개념이 없기 때문에 모든 포트로 정보를 내보냄

반이중 통신(half-duplex)
송신 혹은 수신이  한 번에 한 번만 이루어지는 통신(ex 무전기)
동시에 허브로 데이터를 전송할 경우 충돌(collision) 발생

허브는 반이중

전이중 통신(full-duplex)
송신과 수신이 동시에 이루어지는 통신(ex 전화)

콜리젼 도메인
충돌이 발생할 수 있는 범위

CSMA/CD
반이중 이더넷의 충돌을 해결하기 위한 것
CS: Carrier Sense
캐리어(반송파) 감지: 메세지 전송 전 현재 전송 중인 메세지가 있는지 확인
MA: Multiple Access
다중 접근: 두 개 이상의 호스트가 동시에 네트워크에 접근(충돌 발생)
CD: Collision Detection
충돌 감지: 잼 신호를 보낸 뒤 임의의 시간 동안 대기 후 재전송

허브의 특성 정리
전달 받은 신호를 모든 포트로 내보냄
연결된 모든 호스트가 충돌 도메인
반이중 모드로 통신하는 물리 계층의 장비

스위치

전달 받은 신호를 목적지 포트로만 내보내고
목적지 호스트가 연결된 곳만 충돌 도메인에 속해 있으며
전이중 모드로 통신하는 
데이터 링크 계층의 장비 -> MAC 주소 활용

MAC 주소 학습 기능 (송신지 MAC 주소 기반으로 학습)
포트에 연결된 호스트와 MAC 주소의 관계를 기억하는 스위치 기능
MAC 주소 테이블

학습과정
1. 플러딩: 허브와 같이 모든 포트에 프레임 전송
2. 포워딩과 필터링: 어떤 포트로 내보낼지(포워딩) 내보내지 않을지(필터링) 결정
3. 에이징: 특정 시간이 지나면 MAC 주소 테이블 항목 삭제

VLAN
스위치 기능
가상의 LAN
물리적 위치에 관계 없이 특정 LAN에 속할 수 있음
다른 VLAN과 통신하려면 네트워크 이상의 장비가 필요
포트 기반 VLAN(정적 VLAN)
MAC 주소 기반 VLAN(동적 VLAN)

네트워크 계층

물리 계층과 데이터링크 계층 -> LAN에 국한된 통신
LAN을 넘어서기 위한 계층
네트워크 간 통신이 가능한 계층 -> 라우팅
단편화가 이루어지는 계층

네트워크 간 통신에 MAC 주소의 한계
도달 경로를 파악하기 어려움 (라우팅 어려움)
임의의 네트워크에 속한 호스트의 MAC 주소를 기억하기 어려움

기본적으로 MAC 주소 이전에 IP 주소를 사용
MAC 주소 ex) 수취인 -> 물리 주소
IP 주소  ex) 수취인 주소 -> 논리 주소
직접 할당
자동 할당(DHCP)

IP

IP의 두 가지 주요 기능
IP 주소 지정
단편화

패킷의 크기를 MTU(Maximum Transmission Unit)이하로 유지
MTU 크기 이하로 단편화된 패킷들은 목적지에서 재조합
MTU
일반적으로 MTU 크기는 1500
작게 유지할 경우 전송률을 보장
크게 유지할 경우 오베헤드가 적음

IPv4 헤더
송신지, 목적지 IP 주소
식별자, 플래그, 단편화 오프셋
식별자: 패킷에 할당된 번호(재조합 시 사용)
플래그: 부가 정보(미사용, Don't Fragment, More Fragment 비트)
단편화 오프셋: 단편화되기 전 데이터가 얼마나 떨어져 있는가
TTL, 프로토콜
TTL(Time To Live): 패킷의 수명, 라우터를 거칠 때마다 1감소
프로토콜: 상위 계층의 프로토콜

IPv4 주소
4바이트(32비트)로 표현 가능
한 옥텟은 0~255 범위의 네 개의 십진수로 표기
이론적으로 할당 가능한 IPv4 주소 개수 = 2^32개 <- 넉넉한 양이 아님
IP 주소 부족 문제

IPv6 주소
16바이트(128비트)로 표현 가능
이론적으로 할당 가능한 IPv6 주소 개수 = 2^128 <- 사실상 무한

IPv6 헤더
의외로 더 단순한 헤더
다음 헤더(확장 헤더), 홉 제한(TTL), 송신지 IP 주소, 수신지 IP 주소
단편화 확장 헤더
다음 헤더를 가리키기 위한 필드를 가지고 있음
식별자, 플래그, 단편화 오프셋를 포함함

ARP
IP 주소를 통해 MAC 주소를 알아내기 위한 프로토콜
동일 네트워크 내의 호스트의 MAC 주소를 알아내기 위한 프로토콜

ARP 동작 과정
1. ARP 요청
2. ARP 응답
3. ARP 테이블(ARP 캐시) 갱신
ARP 요청과 응답에서 ARP 패킷을 주고 받음

ARP 요청(브로드캐스트 메세지)
특정 IP 주소를 가진 호스트의 MAC 주소를 알아내기 위해 보내는 브로드캐스트 메시지
해당 호스트의 MAC 주소를 모르기 때문에 브로드캐스트 메세지로 전송

ARP 응답
ARP 요청 메세지에 대한 응답. 자신의 MAC 주소 포함

ARP 패킷
오퍼레이션 코드에 따라 요청인지 응답인지 정해짐

ARP 테이블 갱신
ARP 테이블(ARP 캐시): MAC 주소와 IP 주소가 매핑된 표 형태의 데이터
일정 시간이 지나면 삭제
ARP 테이블에 추가된 호스트는 브로드캐스트로 ARP 요청 보낼 필요 없음
arp -a로 볼 수 있음

다른 네트워크에 속한 호스트의 MAC 주소 알아내기
ex) 라우터에서 라우터로 패킷 전달

IP의 한계
비신뢰성: 패킷이 목적지까지 제대로 전송한다는 보장이 없는 특성
-> 최선형 전달(best-effort delivery)
비연결형: 호스트 간의 사전 연결 수립이 없는 특성

신뢰성 프로토콜, 연결형 프로토콜을 제공하는 계층은 전송 계층(TCP)

ICMP
IP의 비신뢰성과 비연결형 특성을 보완하기 위한 네트워크 계층 프로토콜
IP 패킷의 전송 과정에 대한 피드백 메세지 제공
오류 보고
네트워크 진단 정보
ICMP 메시지는 타입과 코드로 정의
ping, traceroute [주소]로 확인할 수 있음
IP의 한계를 보완할 뿐 완전히 해결하는 것은 아님
근본적인 해결은 전송 계층에서 이루어짐

IP 주소의 구성

네트워크 주소, 호스트 주소(유동적)
첫번째, 두번째 옥텟 -> 네트워크 주소
세번째, 네번째 옥텟 -> 호스트 주소
유동적이기 때문에 각 주소의 옥텟 범위는 달라질 수 있음(총합은 4로 같음)

MAC 주소의 구성

제조사 번호, 일련 번호(비트 수 24/24비트 고정)
1,2,3 번째 -> 제조사 번호
4,5,6 번째 -> 일련 번호

클래스풀 주소 체계
A 클래스
네트워크 주소 1 옥텟, 호스트 주소 3 옥텟
0 -> 0.0.0.0 ~ 127.255.255.255
B 클래스
네트워크 주소 2옥텟, 호스트 주소 2 옥텟 
10 -> 128.0.0.0 ~ 191.255.255.255
C 클래스
네트워크 주소 3 옥텟, 호스트 주소 1 옥텟
110 -> 192.0.0.0 ~ 223.255.255.255

호스트 주소가 전부 0이면 네트워크 주소
호스트 주소가 전부 1이면 브로드캐스트 주소
이 2개의 주소는 예약된 IP 주소이기 때문에 원하는 호스트로 사용할 수 없음

IP 주소가 엄청 낭비될 수 있음

클래스리스 주소체계
클래스풀 주소 체계보다 더 정교히 네트워크를 나누는 방법
오늘날 주로 사용하는 방식
네트워크와 호스트를 구분하기 위해 서브넷 마스크 이용

서브넷 마스크
IP 주소 상에서 네트워크 주소는 1, 호스트 주소는 0으로 이루어진 비트열
클래스 A: 255.0.0.0
클래스 B: 255.255.0.0
클래스 C: 255.255.255.0
클래스 A,,B,C는 예제로 들었을 뿐 1비트의 범위까지 정교하게 할 수 있음

서브넷 마스크와 IP 주소의 비트 AND 연산 -> 네트워크 주소

CIDR 표기
서브넷 마스크 상의 1의 개수를 IP주소/숫자로 표기
ex) 192.168.100.103/30

IP 주소의 분류
IP 주소는 전세계 고유한 주소? -> 그렇기도하고 아니기도 하다

공인 IP 주소와 사설 IP 주소
공인 IP 주소: 인터넷 사용할 때 사용하는 고유한 주소
사설 IP 주소: 사설 네트워크 내에서 사용하는 고유하지 않은 주소

사설 IP 주소 대역
예약된 IP 주소
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

공인 IP 주소 확인
인터넷에 검색

사설 IP 주소 확인
ipconfig, 네트워크 설정

NAT

공인 IP 주소와 사설 IP 주소 간의 변환 기능
하나의 공인 IP 주소를 여러 사설 IP 주소가 공유 가능
IP 주소 부족 문제 해결

정적 IP 주소와 동적 IP 주소
IP 주소의 할당 방법: 정적 할당과 동적 할당

정적 IP 주소:

정적 할당된 IP 주소(고정)
사용자가 IP 주소, 서브넷 마스크, 게이트웨이(네트워크 밖으로 내보내야 할때 처음으로 거쳐야하는 호스트)(기본 게이트웨이), DNS를 직접 할당하는 것 
nmtui로 할당할 수 있음

동적 IP 주소

동적 할당된 IP 주소(유동적)
DHCP
동적 IP 주소를 할당하기 위한 프로토콜
DHCP 서버에 의해 동적으로 IP 주소 할당 -> IP 주소 임대
해당 기능은 공유기, 라우터가 제공해줄 수 있음
정해진 임대 시간이 끝날 경우 임대 갱신 (자동 수행, 수동 수행)
ipconfig /all로 볼 수 있음

DHCP 과정
1. DHCP Discover
IP 주소를 빌려줘라고 브로드캐스트
2. DHCP Offer
이만큼의 IP 주소를 쓸 수 있어라고 답변
3. DHCP Request
이 IP 쓸래라고 요청
4. DHCP Acknowledgement
IP 할당

네트워크 계층 장비 -> 라우터
라우팅: 패킷이 이동할 최적 경로 설정, 해당 경로로 패킷 이동
라우팅 프로토콜: 라우팅을 수행하는 방법
홉: 라우터와 라우터 간의 패킷 이동 과정
홉 바이 홉 라우팅
traceroute [주소]로 관찰 가능

라우팅 테이블
특정 목적지까지 도달하기 위한 정보를 명시하는 표와 같은 정보
대표적인 정보: 목적지 주소. 서브넷 마스크, 게이트웨이, 인터페이스, 메트릭(비용)
롱기스트 프리픽스 매치(longest prefix match)
여러 라우팅 테이블 항목과 일치할 경우 가장 길게 일치하는 항목 선택 후 패킷 전송
디폴트 라우트
합치되는 경로가 없을 경우 기본으로 내보낼 경로(0.0.0.0/0)
route -v, netstat -rn로 볼 수 있음

라우팅 테이블이 만들어지는 방법
정적 라우팅: 수동으로 라우팅 테이블 항목 채워넣기
라우터의 부하가 적어짐, 중간 라우터에 문제가 생기면 패킷을 보낼 수가 없음
동적 라우팅: 자동으로 라우팅 테이블 항목 채워넣기(라우팅 프로토콜) -> 경로 우회 가능

라우팅 프로토콜
AS 내부 라우팅 프로토콜(IGP): RIP, OSPF
AS 외부 라우팅 프로토콜(EGP): BGP
AS: 동일한 라우팅 정책으로 운영되는 라우터들의 집단 네트워크
RIP:거리 벡터 활용(홉수)
OSPF: 링크 상태 활용(그래프 데이터베이스 활용)

전송 계층

전송 계층의 역할
응용 계층의 어플리케이션 프로세스 식별 -> 포트
네트워크 계층의 신성/연결성 확립

포트
포트 번호는 16비트로 표현 가능(65536개)
포트 범위: 0~65535
잘 알려진 포트 0~1023
등록된 포트 1024~49151
동적 포트 49152~65535

잘 알려진 포트, 웰 노운 포트, 시스템 포트
널리 알려진, 유명한 포트
 ex) 20,21 -> FTP, 22 -> SSH, 25 -> SMTP(이메일),53 -> DNS, 80 -> HTTP, 443 -> HTTPS

등록된 포트
잘 알려진 포트에 비해서는 덜 범용적이지만 흔히 사용되는 애플리케이션
ex) 8080 -> HTTP 대체, 3306 -> MySQL DB

동적포트, 사설포트, 임시 포트
사용자가 자유롭게 할당 가능한 포트
서버는 일반적으로 잘 알려진 포트와 등록된 포트로 동작
클라이언트는 일반적으로 동적 포트로 동작

netstat, ss으로 포트번호 확인 가능
둘다 많은 필터링 기능이 있음

TCP와 UDP

TCP 세그먼트
MSS: TCP 세그먼트로 보낼 수 있는 최대 크기
-> 페이로드

TCP 세그먼트 구조
출발지 포트, 목적지 포트, 순서 번호, 확인 응답 번호(Ack), 제어 비트, 윈도우 등

제어비트
ACK: 세그먼트 승인을 나타내는 비트
SYN: 연결 수립을 위한 비트
FIN: 연결을 끝내기 위한 비트
RST: 연결을 리셋하기 위한 비트

순서 번호
송수신되는 세그먼트 데이터 첫 바이트에 부여되는 번호

확인 응답 번호
순서 번호에 대한 응답(다음으로 수신받길 기대하는 바이트 번호)

윈도우
수신지 윈도우 크기
한 번에 수신 받고자 하는 양

UDP
UDP는 IP 패킷을 감싸는 껍데기일 뿐
비연결성/비신뢰성 프로토콜
TCP의 재전송/흐름 제어/혼잡 제어 등의 기능 없음

UDP 데이터그램 구조
출발지 포트, 목적지 포트, 길이, 체크섬
모두 TCP 세그먼트에 있는 정보들
체크섬 필드는 신뢰성과 연관이 없다.

하나 하나 확실히 보내는 TCP
빠르게 마구 던지는 UDP

최근 빠른 성능으로 각광받는 UDP
HTTP/3, NTP, RIP, DNS, DHCP

TCP는 연결형 프로토콜
1. 연결 설정

엑티브 오픈(처음 연결 시작하려는 호스트 A), 패시브 오픈 호스트(연결 요청을 수락하는 호스트 B)

• Three-way handshake
  1. SYN 세그먼트 (연결 시작합니다) A -> B
  2. SYN+ACK 세그먼트 (네, 확인했습니다. 연결 시작해요!) A <- B
  3. ACK 세그먼트 (네, 확인했습니다.) A -> B

2. 데이터 송수신
3. 연결 종료
액티브 클로즈(처음 연결 종료를 요청하는 호스트), 패시브 클로즈(연결 종료 요청을 받는 호스트)

• Four-way-handshake
  1. FIN 세그먼트 (연결 끊을게요) A -> B
  2. ACK 세그먼트 (네, 확인했습니다.) A <- B
  3. FIN 세그먼트 호스트 B가 연결이 끊을 준비가 되었다면 (이제 연결 끊어요/) A <- B
  4. ACK 세그먼트 (네, 확인했습니다.) A -> B
  호스트 B가 ACK 세그먼트를 받으면 종료 이때 호스트 A는 호스트 B가 종료될 때까지 기다림

액티브 클로즈 호스트는 마지막 ACK을 보낸뒤 TIME-WAIT 상태에서 일정 시간을 기다리고 연결을 종료한다
마지막 ACK 세그먼트의 유실 대비
또 다른 연결 과정에서의 패킷 혼선 방지

TCP는 스테이트풀 프로토콜이라고도 함
현재 연결 상태를 나타내기 위해 다양한 상태 활용
UDP는 스테이트리스 프로토콜

TCP의 가능한 상태 목록
아무런 연결이 없는 상태
CLOSED
연결 수립 도중 사용되는 상태
LISTEN: SYN 세그먼트를 기다리는 상태(서버 호스트)
SYN-SENT: SYN 세그먼트를 보낸 뒤 SYN+ACK 세그먼트 대기
SYN-RECEIVED: SYN+ACK 세그먼트를 보낸 뒤 그에 대한 ACK 대기
연결되어 있는 상태
ESTABLISHED
Three-way handshake 끝났을 경우
데이터 송수신 가능
연결 해제시 사용되는 상태
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING: 상대 FIN 세그먼트에 ACK 세그먼트를 보냈지만, 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못한 상태(보통 동시에 연결을 종료하려 할 때)
LAST-ACK
TIME-WAIT

TCP 재전송
TCP는 신뢰성 프로토콜
무엇인가를 확실히 전송했다는 보장이 있으려면?
재전송 기반의 오류 제어: 잘못 전송된 경우 재전송
흐름 제어: 받을 수 있을 만큼만 받기
혼잡 제어: 보낼 수 있는 상황에서만 보내기

언제 잘못 되었음을 인지할까?
1. 중복된 ACK 세그먼트를 수신했을 때
2. 타임아웃이 발생했을 때 -> 재전송 타이머

TCP 오류 제어
TCP는 재전송 기반의 오류 제어를 수행
재전송을 기반으로 잘못된 전송을 바로 잡는 것: ARQ(자동 재전송 요구)

ARQ
1. Stop-and-Wait ARQ
2. Go-Back-N ARQ
3. Selective Repeat ARQ
일반적으로  TCP에서 1번은 사용하지 않고 2,3 번을 적절하게 혼용해서 사용

Stop-and-Waite ARQ
가장 단순한 형태
제대로 보냈을 확인하기 전까지는 보내지 않음
전송하고, 확인하고, 전송하고, 확인하고,...
네트워크 이용 효율이 낮아지는 문제

이런 문제를 해결하려면?
여러 세그먼트 한 번에 전송 -> 파이프라이닝(보낼 수 있는 만큼 보냄)
Go-Back-N ARQ
올바른 세그먼트에 대해서는 확인 응답 보냄
올바르지 않은 세그먼트가 수신되면 이후 모든 세그먼트 폐기
누적 확인 응답(Cumulative ACK)

Selective Repeat ARQ
올바른 세그먼트에 대해서만 확인 응답 보냄
각 세그먼트에 대한 확인 응답: 개별 확인 응답
호스트 A는 확인 응답을 못받은 세그먼트가 무엇인지 확인하는 작업이 필요

빠른 재전송(fast retransmit)
재전송 타이머가 만료되지 않아도 중복 세그먼트가 수신되면 재전송
빠른 재전송이 없는 경우: 재전송 타이머가 만료되어야 비로소 재전송

TCP 흐름 제어
송신 버퍼와 수신 버퍼
송신 버퍼: 어플리케이션 계층에서 전송할 데이터 임시 저장
수신 버퍼: 네트워크 계층에서 수신할 데이터 임시 저장

송신 호스트가 수신 호스트가 처리할 수 있는 수신 버퍼보다 더 많은 데이터를 전송하면?
버퍼 오버플로우: 일부 데이터가 처리되지 않을 수 있음

송신 호스트가 수신 호스트 처리 속도를 고려하여 송수신 속도를 균일하게 맞추는 것
오늘날 TCP에서의 흐름 제어 -> 슬라이딩 윈도우

윈도우: 파이프라이닝 가능한 순서범호 범위
윈도우 크기: 확인 응답 받지 않고도 한번에 보낼 수 있는 최대 양

(수신) 윈도우 크기: TCP 헤더를 통해 송신지에게 알려주는 정보

수신 호스트
수신 윈도우 = 수신 버퍼 크기 - [마지막으로 수신한 바이트 - 마지막으로 읽어들인 바이트]
송신 호스트
수신 윈도우 >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트

혼잡(congestion)
많은 트래픽으로 인해 패킷 처리 속도가 느려지거나 유실될 우려가 있는 상황
혼잡 제어가 이루어지지 않는다면?
혼잡 -> 유실 -> 재전송 -> 혼잡 -> 유실 -> 재전송 -> ...
이 현상이 지속되면 마비가 됨 -> 혼잡 붕괴

TCP 혼잡 제어
혼잡이 생기지 않을 정도로만 조금씩 전송하는 방법
혼잡 윈도우: 혼잡 없이 전송할 수 있을 법한 양
송신 호스트
최소값(수신 윈도우, 혼잡 윈도우) >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트

기본 동작 형태: AIMD(Additive Increase Multicative Decrease)

혼잡 제어를 수행하는 알고리즘
1. 느린 시작
2. 혼잡 회피
3. 빠른 회복

RTT(Round Trip Time)
메세지를 전송한 뒤 그에 대한 답변을 받는 시간

느린 시작
ACK 세그먼트가 수신될 때마다 혼잡 윈도우 1 증가(RTT마다 혼잡 윈도우 2배 증가)
혼잡 윈도우가 특정 임계치(sshresh)값과 같아지면 혼잡 회피 수행

혼잡 회피
매 RTT마다 혼잡 윈도우 1씩 증가
세 번의 중복 세그먼트가 발생했을 경우 빠른 회복 수행

빠른 회복
세 번의 중복 ACK 세그먼트가 수신되었을 때 느린 시작을 건너뛰고 혼잡 회피를 수행하는 알고리즘
TCP Tahoe(빠른 회복 미수행) vs TCP Reno(빠른 회복 수행)

응용계층

DNS

사람이 기억하기 쉬운 도메인 이름과 호스트를 특정지을 주소를 매핑
도메인: 호스트에 부여되는 문자열 이름

계층적 도메인 구조
ex) .com, .kr, .edu
TLD(Top Level Domain) DNS 서버
최상위 도메인 목록(Root 바로 아래)

서브 도메인(하위 도메인)
도메인의 일부인 도메인
ex) naver.com -> maps.naver.com

각 도메인을 담당하는 도메인 서버
ROOT 네임 서버
TLD 서버
Authoritative DNS 서버: 찾고자 하는 도메인의 IP주소를 저장하는 최종 서버
local DNS 서버: 클라이언트가 가장 먼저 찾는 DNS 서버(DNS Resolver)
local DNS 서버 주소 명시적 설정 <- Public DNS
local DNS 서버 주소 자동 설정 <- ISP

반복적 질의
local DNS 서버가 root DNS server, TLD DNS server, authoritative DNS server 순으로 각각 질의하고 응답받으면서 찾고자 하는 도메인 주소의 IP를 알아냄

재귀적 질의
local DNS 서버가 root DNS server에게 질의하고 응답받고  root DNS sever는 TLD DNS server에게 질의하고 응답받고, TLD DNS server는 authoritative DNS server에게 질의하고 응답받으면서 찾고자 하는 도메인 주소의 IP를 최종족으로 local DNS 서버가 알려줌

DNS 서버는 무엇을 저장하고 있을까?
DNS 레코드(자원 레코드)
A 레코드: 도메인에 대한 IPv4 주소를 1대1로 매칭
AAAA 레코드: 도메인에 대한 IPv6 주소를 1대1로 매칭
CNAME 레코드: 도메인에 대한 별칭
NS 레코드: 네임 서버 주소
SOA 레코드: 도메인에 대한 관리자 정보

DNS 캐시
TTL 기간동안 DNS 저장

URI/URL/URN

네트워크 상에서의 자원
네트워크로 주고 받을 수 있는 모든 정보
파일, 이미지, 동영상, HTML, XML, JSON, ...

네트워크 상에서의 자원이 필요하다면 자원을 요청해야 함
자원을 요청하고 요청한 자원을 응답하려면 자원을 식별할 수 있어야 함 -> 자원의 식별자가  있어야 함

자원의 식별자 -> Uniform Resource Identifier
URI는 자원을 식별할 수 있는 문자열

URI의 분류
URI는 위치 혹은 이름으로 분류 가능하다
URL: 위치 기반 자원 식별(Locator)
URN: 이름 기반 자원 식별(Name)

URL 구성 요소
scheme: 일반적으로 프로토콜 이름 명시 ex) http://
authority: 사용자 이름을 이용한 인증 가능 - 생략 가능
호스트 이름 (도메인 이름 혹은 IP 주소)
포트 번호 - 생략가능
path: 자원이 있는 경로
query: key:value 형태로 서버에 전달할 문자 형태의 파라미터
?로 시작, &(혹은 ;)로 다수의 query 구분
fragment: 자원의 조각(fragment)를 가리키는데 사용(# 사용)

웹서버, 웹 어플리케이션 서버(WAS)

서버가 응답해야 하는 자원
정적인 자원: 언제/어디서/누가 봐도 변하지 않는 정보
동적인 자원: 언제/어디서/누가 보는지에 따라 변할 수 있는 정보(ex) 오늘의 온도) -> 주로 데이터베이스 사용

정적인 자원을 응답하는 웹 서버
동적인 정보를 생성해 응답하는 웹 어플리케이션 서버

웹 서비스는 웹 서버와 웹 어플리케이션 서버를 같이 사용함
정적인 데이터는 웹 서버가 응답, 동적인 데이터는 웹 어플리케이션 서버가 응답하여 전달 -> 과도한 부하 방지
웹서버의 보안만 잘한다면 웹 어플리케이션 서버의 보안도 할 수 있음 -> 보안 상의 이점
웹 서버는 여러 웹 어플리케이션 서버와 연동할 수 있음 -> 확장성 용이

HTTP

현재 HTTP의 기본 특성
요청-응답 기반 클라이언트-서버 구조 프로토콜
미디어-독립적 프로토콜
비연결성 프로토콜
스테이트리스 프로토콜
지속 연결 프로토콜

요청-응답 기반 클라인어트-서버 구조
HTTP 클라이언트 (HTTP 요청 메세지)
HTTP 서버 (HTTP 응답 메세지)
오해 방지: 서버 간에도 HTTP 메세지를 주고 받을 수 있음

미디어-독립적
어떤 형태의 데이터도 HTTP 메세지로 보낼 수 있음
HTML, 이미지, JSON, XML, 파일, 영상 등

비연결성 프로토콜
HTTP 1.0, HTTP 1.1, HTTP 2.0은 TCP 기반
TCP는 연결성 프로토콜
다수의 클라이언트가 연결을 시도할 경우
연결을 유지하는 동안 서버의 자원 소모가 너무 크다
HTTP 3.0부터는 비연결성 프로토콜

스테이트리스 프로토콜
서버는 클라이언트의 상태를 기억하지 않는다
왜 스테이트리스 프로토콜일까?
HTTP가 스테이트풀 프로토콜일 경우
클라이언트는 한 서버에 종속됨
여러 요청을 보내야 할 경우 한 서버에만 요청해야함

서버의 IP가 바뀐다면?
요청을 보낸 서버에 장애가 생긴다면?
서버가 여러대 있다면?

클라이언트는 한 서버에 종속될 필요가 없어짐
여러 번 요청을 보내야 할 경우 여러 서버에 요청할 수 있음
-> 서버의 확장이 용이해짐

지속 연결(Keep-Alive)
연결할 때마다 3-way handshake?
-> 혼잡 증가
-> 시간 지연 증가
하나의 연결을 사용해 여러 개의 HTTP 요청/응답 주고 받기

HTTP 버전별 특성
HTTP 0.9: 단일한 요청 방법(GET 메서드), 비지속 연결, 별다른 기능 X
HTTP 1.0: 다양한 요청 방법과 헤더 추가
HTTP 1.1: 지속 연결 기능 추가
HTTP 2.0: 요청 순서대로 응답을 반환할 필요 없음, 헤더 압축
HTTP 3.0: UDP 기반 프로토콜인 QUIC로 변경
오늘날 1.1과 2.0을 주로 사용, 3.0은 점차 증가하는 추세

HTTP 메세지
HTTP 요청 헤더 - Start line
HTTP 메서드 (공백) 요청 대상 (공백) HTTP 버전 (개행)
HTTP 메서드: 서버에게 요청할 동작(해당 자원으로 어떤 동작을 요청할지)
GET: 자원 조회
POST: 요청할 데이터 처리
PUT: 자원 덮어쓰기
PATCH: 자원 부분 변경
DELETE: 자원 삭제
이외에도 HEAD, OPTIONS, TRACE, CONNECT

GET 요청
리소스 조회에 사용
일반적으로 쿼리 문자열을 사용하되, 본문은 없음
"갖다 줘"

POST 요청
메세지 본문으로 처리할 데이터 전송
메세지 본문에 해당하는 데이터 처리하도록 요청
어떻게 처리할지는 서버가 결정 (ex 새자원 생성, 가공)

PUT 요청
자원 덮어쓰기
자원이 있다면 본문으로 보낸 데이터로 대체
자원이 없다면 본문으로 보낸 데이터로 생성
"이 자원으로 대체해줘"

PATCH 요청
자원의 일부분 변경

DELETE 요청
자원 삭제

안전: 데이터가 변하는가?
멱등성: 여러 번 동일한 요청을 보내도 첫 요청 결과와 같은가?
캐시 가능성: 응답 결과를 캐시해서 사용할 수 있는가?(GET, HEAD, POST -> o)

요청 대상
요청할 자원의 위치

HTTP 버전
HTTP 1.1, HTTP 2.0

HTTP 응답 헤더 - Start line
HTTP 버전 (공백) 응답 코드 (공백) 이유 문구 (개행)

응답 코드
2XX: 성공
3XX: 리다이렉션(이 요청을 처리하려면 추가적인 처리가 필요)
4XX: 클라이언트 오류
5XX: 서버 오류

200 OK: 요청 성공 (GET)
201 Created: 요청 성공, 새로운 자원 생성됨(POST)
202 Accepted: 요청 성공, 처리는 아직 미완료
204 No Content: 요청 성공, 응답할 데이터 없음

3XX: 리다이렉션 상태 코드
응답의 Location 헤더를 통해 특정 위치로 이동

401 Unauthorized: 미인증
403 Forbidden: 금지된 자원에 접근(자원에 접근할 권한이 없음)
404 Not Found: 요청한 자원 없음(공개한 자원이 아님)

500 Internal Server Error: 서버 오류
503 Service Unavaliable: 현재 이용 가능하지 않음

HTTP 요청-응답 확인하기
curl -X <요청 메서드> URL 으로 할 수 있음
-X <요청 메서드>가 없다면 -> 디폴트: GET
-I -> 응답 헤더만 받을 수 있음
-i -> 헤더와 본문을 같이 출력
-v -> 요청 과정 자세히 출력
-o file.txt -> 요청 결과 저장
-X PUT -d <전송할 데이터> <URL> -> 바디 데이터를 실어서 보냄
-X PUT -H <전송할 헤더> <URL> -> 헤더에 포함해서 보냄

캐시

네트워크에서 캐시란?
HTTP는 상태를 유지하지 않는다
그렇다면 자원을 요청할 때마다 자원은 새롭게 응답될까?
서버의 지연을 줄이기 위해 웹 페이지, 이미지 등의 자원 사본을 임시 저장하는 웹 기술
캐시된 자원이 저장되는 공간: 클라이언트(브라우저) 혹은 특별한 서버(캐시 서버, 프록시 서버)

cache-control 헤더
cache-control 헤더로 캐시 기능을 알린다
cache-control: max-age=숫자(초)
-> 캐시한 자원의 지속 시간
cache-control: no-cache
-> 캐시 가능한 자원이나, 항상 origin 서버에 검증하기
cache-control: no-store
-> 캐시하면 안될 자원

캐시된 자원에는 유효 기간이 있다
해당 자원이 언제 마지막으로 변경되었는지 알리는 Last-Modified 헤더

캐시된 자원의 변경 -1
클라이언트는 요청시 if-modified-sice 헤더로 특정 시점 이후 자원 변경 여부를 묻는다
만일 변경되었다면 다시 다운로드
만일 변경되지 않았다면 서버는 304 Not Modified 응답을 보낸다 -> 자원 변경 안됐으니 캐시로 리다이렉트 해라

캐시된 자원의 변경 -2
Etag를 통해 자원의 변경 여부 감지 가능
서버는 캐시된 자원이 Etag라는 식별 문자를 붙이고,
클라이언트는 If-None-Match 헤더를 통해 해당 Etag가 변경되었는지를 물어본다.
Etag와 If-None-Match가 같다면 변경 X -> 304 Not Modified

쿠키

쿠키(cookie)란?
HTTP는 상태를 유지하지 않는 프로토콜
그럼 요청을 보낼 때마다 모든 정보를 URL 쿼리, HTTP 바디로 보내야 할까?

서버로부터 받은 정보를 클라이언트 측(웹 브라우저)에 임시 저장되는 이름=값 형태의 데이터
유효기간이 있음
쿠키를 전송할 도메인과 경로가 정해져 있음

쿠키 확인해보기
브라우저 -> 개발자 도구 -> Application -> Storage -> Cookies

서버가 Set-Cookie 헤더로 쿠키를 전달하면,
클라이언트는 쿠키를 저장하여 다음 HTTP 요청의 Cookie 헤더로 활용한다.

쿠키의 도메인
Set-Cookie: domain=example.com
example.com(을 비롯한 서브 도메인)에 접근할 때 쿠키 활용

쿠키의 경로
Set-Cooke: path=/
path에 명시된 경로 하위 경로에서 쿠키 활용

쿠키의 유효 기간
Set-Cookie: expires=Wed, 10 Aug 2023 12:00:00 GMT
-> 만료되는 시간
Set-Cookie: max-age=1000
-> 유지 시간

쿠키는 보안에 민감하다

쿠키와 세션
쿠키의 저장/관리 주체가 클라이언트(브라우저)라면
세션의 저장/관리 주체는 서버

서버는 클라이언트를 식별할 수 있는 세션 ID를 제공하고,
클라이언트는 서버에게 세션 ID를 넘겨 호스트를 식별하게 할 수 있다.
세션 ID도 암호화해서 넘기는 것이 좋다

쿠키의 보안 기능
Secure
HTTPS인 경우에만 전송

HTTPOnly
자바스크립트에서 접근 불가
XSS 공격 방지

HTTPS는 HTTP를 TLS로 암호화하여 안전하게 전달하는 기술

컨텐츠 협상

클라이언트가 원하는 컨텐츠를 받을 수 있도록 서버에게 부탁하는 기능
컨텐츠 타입, 언어, 인코딩 방법 등 클라이언트 맞춤 컨텐츠 제공 기능
Accept(-X) 헤더 이용
Accept: 클라이언트가 선호하는 컨텐츠 타입
Accept-Encoding: 클라이언트가 선호하는 인코딩
Accept-Language: 클라이언트가 선호하는 언어
여러 맞춤 요청을 보낼 수 있음
여러 맞춤 요청을 보낼 때 Quality Value 값을 기준으로 우선순위를 매길 수 있음
0 <= Qualiy Value(q) <= 1 (디폴트: 1)
클수록 우선순위가 높음
ex) Accept: text/html, text/plain;q=0.9, text/*;q=0.8

운영체제

자원을 관리하고 할당하는 특별한 프로그램
프로그램 입장에서 운영체제는 자원에 접근하기 위한 인터페이스를 제공해주는 특별한 프로그램

※ 운영체제 핵심 서비스

• 프로세스 관리
• 자원 관리 접근 및 할당
• 파일 시스템 관리

리소스: 실행에 마땅히 필요한 요소

커널

운영체제의 심장부

이중 모드

• 커널 모드: 운영체제 서비스를 제공 받을 수 있는 모드 -> 커널 영역의 코드를 실행할 수 있는 모드
• 사용자 모드: 운영체제 서비스를 제공 받을 수 없는 모드 -> 커널 영역의 코드를 실행할 수 없는 모드

시스템 콜

운영체제 서비스를 제공받기 위해 커널 모드로 전환하는 소프트웨어 인터럽트

strace

시스템 콜을 추적하기 위한 도구

• -o 파일로 저장
• -t 타임스탬프
• -tt 밀리세컨드 타임스탬프
• -T 각 시스템 호출 소요 시간
• -c 요약 결과
• -e 실행 파일의 시스템 호출 결과 필터링

man
명령어 매뉴얼을 보여줌

ps
현재 실행 중인 프로세스를 보여줌

open
파일을 여는 시스템 콜

close
파일을 닫는 시스템 콜(자원 해제)

read
파일 디스크립터에서 데이터를 읽어들이는 시스템 콜

write
파일 디스크립터에 데이터를 쓰는 시스템 콜

fork
프로세스 복제하여 자식 프로세스 생성
프로세스들이 계층적으로 구성되는 원리

exec
현재 프로세스의 주소 공간을 새로운 프로세스로 덮어쓰기
자식 프로세스로 하여금 다른 코드를 실행토록 하기

getpid/getppid
현재 PID를 반환하는 시스템 콜
부모 프로세스 PID를 반환하는 시스템 콜

syslog
시스템 로그 메시지 남기기

exit
실행 중인 프로그램 종료

운영체제의 프로세스 관리

프로세스란 실행 중인 프로그램 -> 같은 프로그램도 별도의 프로세스가 될 수 있다. ex) 메모장 여러개 열 때 여러 프로세스가 동작한다.

포그라운드 포로세스

사용자와 직접적으로 상호작용하는 프로세스

백그라운드 프로세스

뒷단에서 사용자와 직접적으로 상호작용하지 않으면서 실행되는 프로세스

systemctl list-units --type service
어떤 서비스가 현재 어떤 상태인지 어떤 서비스인지 설명이 되어 있음

프로세스 제어 블록(PCB)
프로세스에 대한 식별 데이터 덩어리
들어있는 정보는 PID(PPID), 레지스터, 스케줄링 정보, 메모리 정보, 사용한 파일 정보, 입출력장치 정보 등

pidof [프로세스], pgrep [프로세스]
pid 값을 확인할 수 있다.

문맥 교환
문맥(context): 실행을 재개하기 위해 기억해야 할 정보
문맥 교환: 여러 프로세스들이 번갈아가며 실행되는 원리

사용자 영역

스택 영역, 힙 영역, 데이터 영역, 코드 영역(h->l)

코드 영역(텍스트 영역)
실행 가능한 코드; 기계어로 이루어진 명령어
Read-only

데이터 영역
프로그램이 실행되는 동안 유지할 데이터(ex 전역 변수)

BSS 영역

프로그램 실행 동안 유지할 데이터 중 초기값 없는 데이터

힙영역
사용자(개발자)가 직접 할당 가능한 공간
메모리 영역을 할당 했다면 해제하자
직접 해제 하기, 자동으로 해제 하기(가비지 컬렉션)
안해주면 메모리 누수가 생김

스택 영역
임시로 저장되는 영역(ex 매개변수, 지역변수)

힙 영역은 낮은 주소에서 높은 주소로 할당
스택 영역은 높은 주소에서 낮은 주소로 할당
(주소 중복 방지)
코드 영역과 데이터 영역은 정적 할당 영역
힙 영역과 스택 영역은 동적 할당 영역

size
text data bss 영역이 얼마나 차지하는지 볼 수 있음

top
리소스 관리할 때 자주 사용
여기서도 코드영역과 데이터영역을 조회할 수 있다

대표적인 프로세스 상태

생성 상태(new)
이제 막 PCB를 할당받아 생성된 상태 

준비 상태(ready)
지금 당장이라도 cpu를 할당받아 실행이 될 수 있지만 아직 실행될 차례가 오지않아서 실행 안되고 있는 상태

실행 상태(running)
cpu를 할당받아 실행되고 있는 상태

대기 상태(blocked)
주로 입출력 사용을 요청했을 때 대기하는 상태, 이벤트를 기다리는 상태

종료 상태(terminated)
프로세스가 종료되어 PCB가 폐기되고 자원을 반납하고 있는 상태

준비상태에서 cpu를 할당 받아 실행 상태가 되는 것을 디스패치라고 함
할당된 cpu 이용시간이 끝났다면 다시 준비상태가 되는 것을 타이머 인터럽트(타임 아웃)이라고 함
실행 상태에서 입출력 요청이 일어나면 대기 상태가 되고 입출력 완료가 되면 준비 상태가 됨

top으로 상태를 볼 수 있음

• S는 state로 상태를 나타냄
• R: Running: 실행상태
• S: Sleeping: 대기상태
• W: Waiting: 준비 상태
• S: Stopped: 종료 상태
• Z: Zombie: 프로세스 종료 후 자원이 반환되었지만 커널 영역에 프로세스가 남아있는 상태(PID가 할당 되어있음)

프로세스의 계층적 구조

fork-exec
계층적 구조로 프로세스가 생성되는 원리

pstree으로 확인 가능

스레드

프로세스를 구성하는 실행 흐름의 단위
각기 다른 스레드 ID, 프로그램 카운터, 레지스터, 스택

프로그램 카운터에 다음에 실행될 명령어의 주소가 있음
레지스터는 명령어를 가져오고 연산 결과를 저장하는 역할
스택은 변수나 주소를 저장하는 공간

프로세스 간에는 기본적으로 자원을 공유하지 않음
스레드 간에는 프로세스의 자원을 공유

프로세스 간에도 자원 공유가 가능하다 -> 프로세스간 통신(IPC)
공유 메모리를 통한 통신, 파이프를 통한 통신, 소켓을 통한 통신 등

CPU 스케줄링

프로세스 우선 순위(스레드도 포함)
모든 프로세스(및 스레드)는 실행되기 위해 자원을 필요로 한다.
운영체제가 공정하고 합리적으로 자원을 배분하는 방법을 스케줄링이라 한다.

CPU자원은 한정 되어있고 실행 중인 프로세스는 여러개가 있음
프로세스 우선순위를 고려하여 할당하는 것이 좋다

PR, NI: 낮을수록 높은 우선순위

우선순위의 차이를 보이는 대표적인 프로세스 유형

• I/O bound process: 입출력 작업이 더 많은 프로세스
• CPU bound process: CPU 사용이 더 많은 프로세스

일반적으로 I/O bound process가 CPU bound process보다 우선순위가 높음

프로세스 우선순위를 토대로 CPU 할당 받는 방법으로 CPU 스케줄링 알고리즘이 있음

스케줄링 큐

자원은 한정되어있고 실행 중인 프로세스는 여러개
프로세스들의 요구사항을 일목요연하게 관리하는 방법

※ 대표적인 스케줄링 큐

• 준비 큐: CPU 이용을 기다리는 프로세스들의 큐
• 대기 큐: 대기 상태 프로세스들의 큐 (입출력 요청)

우선순위 낮은 프로세스가 먼저 큐에 삽입되었어도 우선순위 높은 프로세스가 먼저 처리 될 수 있음

선점형 스케줄링(타임아웃 기반 문맥교환)

현재 실행 중인 프로세스의 자원을 빼앗아 해당 프로세스에게 할당

장단점
프로세스에 자원을 고루 할당 가능
문맥 교환 과정의 오버헤드

비선점형 스케줄링

현재 실행 중인 프로세스 실행이 끝날 때까지 해당 프로세스 대기

장단점
고르지 않은 자원 분배
문맥 교환 과정에서의 오버헤드 적음

CPU 스케줄링 알고리즘

전공서 기준
1. 선입 선처리 스케줄링
2. 최단 작업 우선 스케줄링
3. 라운드 로빈 스케줄링
4. 최소 잔여 시간 우선 스케줄링
5. 우선순위 스케줄링
6. 다단계 큐 스케줄링
7. 다단계 피드백 큐 스케줄링

선입 선처리 스케줄링(FIFO 스케줄링 (FCFS))

CPU를 먼저 요청한 프로세스부터 CPU 할당
준비 큐에 삽입된 순서대로 실행되는 비선점형 스케줄링
부작용

호위 효과(convey effect): 앞의 프로세스가 긴 시간을 소요할 때 그 뒤의 프로세스들이 그 시간만큼 기다려하는 현상

최단 작업 우선 스케줄링(SJF 스케줄링)

준비 큐 프로세스 중 CPU 이용 시간이 짧은 프로세스부터 실행
호위효과 방지

라운드 로빈 스케줄링(Round Robin 스케줄링)

선입 선처리 스케줄링 + 타임 슬라이스
준비 큐에 삽입된 순서로 실행하되, 타임 슬라이스만큼 실행
선점형 스케줄링

최소 잔여 시간 우선 스케줄링(SRT 스케줄링)

최단 작업 우선 스케줄링 + 라운드 로빈 스케줄링
작업 시간 짧은 프로세스부터 처리하되, 타임 슬라이스만큼 돌아가며 실행

우선순위 스케줄링

프로세스마다 우선순위 부여, 우선순위 높은 순으로 스케줄링
최단 작업 우선 스케줄링 - 작업 시간 짧은 순으로 우선순위 부여
최소 잔여 시간 스케줄링 - 남은 시간 짧은 순으로 우선순위 부여

아사(starvation) 현상
모든 우선순위 스케줄링 알고리즘의 근본적인 문제
우선순위 낮은 프로세스의 실행이 계속 연기되는 현상
우선순위 높은 프로세스 실행하느라 우선순위 낮은 프로세스 실행을 못함
해결책

에이징(aging): 대기시간이 길어지면 점차 우선순위를 높이는 방식

다단계 큐 스케줄링(MLQ)

우선순위별로 준비 큐를 여러개 사용하는 스케줄링
프로세스 유형 별로 큐 구분 가능
큐 별로 다른 스케줄링 알고리즘 적용 가능
큐 별로 다른 타임 슬라이스 적용 가능
기본적으로 프로세스는 큐 간의 이동 불가능 -> 아사 현상 발생

다단계 피드백 큐 스케줄링(MFQ)

프로세스가 큐 간의 이동 가능
높은 우선순위 큐에 삽입, 실행이 끝나지 않을 경우 낮은 우선순위 큐에 삽입
에이징 적용
CPU bound, I/O bound 프로세스 구분 가능

리눅스 스케줄링

리눅스 스케줄링 정책
실시간 정책 스케줄링(우선순위 높음)

• SCHED_FIFO
• SCHED_RR

일반 정책 스케줄링(우선순위 낮음)

• SCHED_OTHER/SCHED_NORMAL
• SCHED_BATCH
• SCHED_IDLE

CFS(Completely Fair Scheduler)
비실시간 프로세스를 대상으로 하는 스케줄링 방식

vruntime(virtual runtime)
프로세스가 그 동안 실행한 시간을 정규화한 정보
vruntime이 작은 프로세스를 다음 실행할 프로세스로 삼음
(vruntime 별 태스크를 고르는 과정에서 RB tree 사용)

타임슬라이스
nice 값에 비례해 가중치 할당, 가중치를 바탕으로 타임 슬라이스 할당

nice

사용자 영역에서 설정한 프로세스 우선순위
사용자 영역에서의 값은 -20~19
커널 영역에서의 값은 0~139

• 실시간 스케줄링되는 프로세스: 0~99
• CFS 프로세스: 100~139

nice -n [우선순위] [program]
새 프로세스를 실행할 때 해당 프로세스의 우선순위 부여 가능
기본적으로 설정된 nice 값은 0

renice [우선순위] [PID]
이미 실행 중인 프로세스의 우선순위 부여

동기화와 교착상태

프로세스 동기화
동시다발적으로 실행되는 프로세스 실행 순서와 자원의 일관성을 보장해야한다.

운영체제가 제공하는 동기화의 의미

• 실행 순서 제어: 프로세스를 올바른 순서로 실행하기
• 상호 배제: 동시에 접근해서는 안되는 자원에 하나만 접근하기 

공유 자원과 임계 구역

• 공유 자원: 공동의 자원(ex 파일, 전역 변수, 입출력장치 등)
• 임계 구역: 동시에 접근하면 문제가 발생할 수 있는 공유 자원에 접근하는 코드

레이스 컨디션(race condition)

임계 구역을 동시에 실행하여 자원의 일관성이 깨지는 현상

생산자와 소비자 문제
동기화가 이루어지지 않았을 경우 발생할 수 있는 문제를 보여주는 고전적 문제

• producer: 생산을 하는 프로세스
• consumer: 소비를 하는 프로세스

동기화 해결의 세가지 원칙

1. 상호 배제
한 프로세스가 임계 구역에 진입했다면 다른 프로세스는 대기해야 함

2. 진행
어떤 프로세스도 임계 구역에 진입하지 않았다면 진입이 가능해야 함

3. 유한 대기
한 프로세스가 임계 구역 진입을 위해 대기하고 있다면 언젠가 진입이 가능해야 함

뮤텍스 락
자물쇠 역할: 프로세스들이 공유하는 전역변수 lock
자물쇠 잠그기: acquire 함수 lock이 true인지 아닌지 확인 -> 임계 구역 진입 가기전에 쓰는 함수라 볼 수 있음 -> 바쁜 대기

• 바쁜 대기: 임계 영역(critical area)에서 작업 중인 스레드 B를 기다리는 스레드 A가 있음. 이때, A는 B가 끝날 때까지 즉, 임계 영역에 들어갈 수 있을 때까지 아무 작업도 하지 않고 임계 영역에 접근이 가능한지 무한으로 검사만 하고 있는 현상

자물쇠 열기: release 함수 임계 구역 작업이 끝나면 잠금 해제

세마포
뮤텍스 락은 기본적으로 공유 자원이 하나일 경우 상정
세마포는 공유 자원이 여러 개 있을 경우도 동기화 가능
가라는 신호를 받으면 임계 구역에 진입해도 좋다
멈추라는 신호를 받으면 임계 구역에 진입해서는 안된다
변수 S: 임계 구역에 진입할 수 있는 포르세스의 개수(사용 가능한 공유 자원의 개수)
wait 함수: 임계 구역에 들어가도 좋은지, 기다려야 할지를 알려주는 함수
signal 함수: 임계 구역 앞에서 기다리는 프로세스에게 이제 가도 좋다고 신호를 주는 함수

프로세스 상태 전이 활용
무한 반복 확인 즉 바쁜 대기를 대기 상태로 바꾼 것

실행 순서를 위한 동기화

먼저 실행할 프로세스 뒤에 signal

나중에 실행할 프로세스 앞에 wait

조건 변수와 모니터
사용이 간편한 동기화 도구, 모니터
공유 자원에 접근하기 위한 인터페이스를 따로 둠
인터페이스를 통해서만 접근(상호 배제)
실행 순서 제어를 위한 동기화를 위해 조건 변수 사용
wait(), signal() 연산이 가능한 특별한 변수
wait(): 호출한 프로세스를 대기 상태로 전환
signal(): 호출한 프로세스를 깨움

조건 변수를 활용한 실행 순서 제어
아직 실행될 조건이 되지 않았을 때에는 wait을 통해 실행 중단
실행될 조건이 충족되었을 때에는 signal을 통해 실행 재개

교착상태

일어나지 않을 사건(필요한 자원의 할당)을 기다리면 무한히 대기하는 현상 -> 데드락
ex) 식사하는 철학자 문제

교착 상태 발생 조건 (반드시 x, 확률이 높다)

• 상호 배제: 동시에 자원 사용이 불가능한 경우
• 점유와 대기: 자원을 할당받은 채 다른 자원의 할당을 기다리는 경우
• 비선점: 강제로 자원을 빼앗을 수 없는 경우
• 원형 대기: 자원을 원형으로 대기할 경우 (ex 식사하는 철학자 문제)

교착상태 해결 방법

교착 상태 예방
교착 상태 발생 조건 네 가지 중 하나를 없애는 것

교착 상태가 발생 배경 원천 차단
교착 상태가 발생하지 않음을 보장할 수 있지만, 여러 부작용이 따르는 방식

• 상호 배제 조건 없애기
  자원을 공유 가능하도록 변경
  모든 자원에 대해 적용할 수 없음
• 점유와 대기 조건 없애기
  특정 프로세스에 자원을 모두 할당, 아예 할당하지 않기
  자원의 활용률 저하
• 비선점 조건 없애기
  선점하여 사용 가능한 자원에 대해서는 효과적(ex CPU)
  모든 자원에 대해 적용 가능한 것은 아님(ex 프린터기)
• 원형 대기 조건 없애기
  자원에 번호 매기기
  오름차순으로 자원 할당
  현실적으로 쉽지 않음, 자원의 활용률 저하

교착 상태 회피
교착 상태가 발생하는 이유를 자원의 무분별한 할당으로 간주
교착 상태가 발생하지 않을 정도로만 조금씩 자원을 할당하는 방법
교착상태가 발생할 수 있는지 없는지를 판단하는 알고리즘 (ex 은행원 알고리즘)

교착 상태 검출 후 회복
교착 상태가 발생하면 그때 회복하는 방식
선점을 통한 회복
프로세스 강제 종료를 통한 회복

교착상태 무시하는 방법도 있긴하다.
ex) 타조 알고리즘(교착 상태가 될 확률이 낮으면 무시)

가상 메모리 관리

스와핑(swapping)
프로세스를 보조기억장치의 일부 영역으로 쫓아내고 당장 필요한 프로세스를 적재하는 메모리 관리 기법

스왑 아웃(swap-out)
프로세스를 보조기억장치의 일부 영역으로 쫓아내는 것

스왑 인(swap-in)
스왑 아웃된 프로세스를 메모리에 적재하는 것

스왑 영역
스왑 아웃된 프로세스가 적재되는 보조기억장치 영역
top, free로 볼 수 있음

연속 메모리 할당

메모리에 연속적으로 배치하는 방식
부작용
외부 단편화: 프로세스들이 실행되고 종료되길 반복하며 빈 공간이 생기는 메모리 낭비 현상
해결책
페이징

페이징
물리 메모리를 프레임이라는 일정한 크기로 나누고
프로세스를 페이지라는 일정한 크기로 나눈 뒤
페이지를 프레임에 매핑하는 메모리 관리 방식
페이지 아웃, 페이지 인

부작용
내부 단편화: 프로세스 내부에서 일어나는 메모리 낭비 -> 프로세스 마지막 페이지의 크기가 페이지 단위에 딱 맞아떨어지 않을 수 있음

가상 메모리
프로세스의 일부만을 적재하여 실제 물리 메모리보다 큰 프로세스를 실행하는 기술
페이징은 현대 운영체제에서 가장 대중적으로 사용되는 가상 메모리 관리 기법

세그멘테이션
프로세스를 유의미한 단위로 나누는 것->일정한 크기로 자르지 않기 때문에 외부 단편화가 발생할 수도 있음

페이지 테이블
프레임과 페이지의 매핑 정보를 담고있는 표 형태의 데이터
프로세스마다 페이지 테이블을 가지고 있음

페이지 테이블 베이스 레지스터(PTBR)
각 프로세스의 페이지 테이블 위치를 가리키는 레지스터

페이지 테이블은 어디에 있는 것이 좋을까?
TLB(Translation Look-aside Buffer)
페이지 테이블의 캐시 메모리
페이지 테이블 내 정보

• 유효 비트(valid bit)
  접근하려는 페이지가 보조기억장치에 있는가? 메모리에 있는가?
  접근하려는 페이지가 보조기억장치에 있을 경우: 페이지 폴트(page fault)
  1. 작업 내역 백업
  2. 페이지 폴트 루틴 실행 -> 접근하려는 페이지 적재
  3. 유효 비트 1로 변경
  4. 접근하려는 페이지 접근
• 보호 비트(protection bit)
  접근하려는 페이지의 권한 (rwx)
• 참조 비트(reference bit)
  접근한 적 있는 페이지인가?
• 수정 비트(modify bit/ dirty bit)
  쓰기 작업을 한 적 있는 페이지인가?

계층적 페이징

페이지 테이블 크기 줄이기
페이지 테이블의 페이지 테이블

요구 페이징
처음부터 모든 페이지를 적재하지 않고
페이지 폴트가 발생하면 그 때 페이지를 적재한다.

순수 요구 페이징
아무 페이지를 적재하지 실행
첫 명령어 실행부터 페이지 폴트 발생
적당한 페이지가 적재된 이후부터 페이지 폴트 감소

페이지 폴트는 적게 발생하는 것이 좋다

스래싱
프로세스 실행 시간보다 페이징에 더 많은 시간이 소요되는 문제
지나친 페이지 폴트로 인해 페이지 교체에 너무 많은 시간을 소요하여 성능이 저하되는 문제
-> 동시 실행되는 프로세스 수를 늘린다고 해서 반드시 CPU 이용률이 비례하여 높아지는 것이 아님

페이지 폴트를 줄이려면?
보조기억장치로 내보낼 페이지 / 메모리에 적재할 페이지를 잘 선별하면 된다.
-> 페이지 교체 알고리즘

페이지를 관찰할 수 있는 명령어: cat/proc/meminfo, top, free, vmstat

페이지 교체 알고리즘

메모리에 적재된 페이지 중 페이지-아웃시킬 페이지를 선정하는 방법
좋은 페이지 교체 알고리즘은 페이지 폴트를 적게 일으키는 알고리즘

페이지 참조율

CPU가 참조하는 페이지 중 연속된 페이지를 생략한 페이지열
ex) 참조한 페이지 2223555337 -> 페이지 참조열 23537

FIFO 페이지 교체 알고리즘

가장 먼저 메모리에 적재된 페이지부터 페이지-아웃
문제점: 초기에 적재된 페이지 중 프로그램 실행 내내 유지할 데이터가 있을 수 있음

2차 기회 FIFO 페이지 교체 알고리즘

FIFO 페이지 교체 알고리즘의 변형
기본적으로 가장 오래 메모리에 머물렀던 페이지부터 페이지-아웃
다만 참조 비트가 1일 경우, 이를 0으로 변경 후 한번 더 기회 부여
참조 비트가 0일 경우 페이지-아웃

최적 페이지 교체 알고리즘

단순하게 생각했을 때, 메모리에서 페이지-아웃되어야 할 페이지는 앞으로 쓸 일이 잘 없는 페이지
앞으로의 사용 빈도가 가장 낮은 페이지부터 교체하는 알고리즘
가장 낮은 페이지 폴트 빈도율을 보장하는 알고리즘
문제점: 앞으로 CPU가 어떤 페이지를 얼마나 참조할지 예측하기란 매우 어려움

이론적으로 페이지 교체 알고리즘의 성능을 평가할 때 주로 사용되는 알고리즘

LRU 페이지 교체 알고리즘

가장 적게 참조할 페이지는 예측하기 어려워도
가장 적게 참조한 페이지는 계산하기 쉽다
최근에 사용되지 않은 페이지를 페이지-아웃

쓰기 시 복사(copy-on-write)

복제 프로세스를 생성할 경우 이를 중복 저장하지 않고
동시에 프로세스 간의 자원을 공유하지 않게끔 하는 방법
자식이나 부모 프로세스가 쓰기를 할 때만 복사 -> 해당 페이지만 복사

쓰기 시 복사를 사용하지 않을 때
프로세스를 fork하면 동일한 프로세스 두 개가 메모리에 복제된다
그 이유는 프로세스끼리는 기본적으로 자원을 공유하지 않기 때문이다
-> 메모리 공간 낭비, 프로세스 생성 시간 낭비

파일 시스템

파일과 디렉터리를 관리하는 커널의 한 부분
다양한 파일 시스템이 있고, 여러 파일 시스템을 동시에 사용할 수 있음

파일
보조기억장치의 의미있는 정보의 집합

• 이름
• 실행하기 위한 정보
• 메타 데이터/ 속성 -> stat으로 확인 가능

속성

• 유형(확장자)
• 크기
• 생성 날짜
• 마지막 접근 날짜
• 마지막 수정 날짜
• 생성자
• 소유자
• 위치

파일(+ 디렉터리) 접근 단위: 블록(block)
섹터 단위로 접근하지 않음 -> 보조 기억 장치

디렉터리는 계층적 구조
루트 디렉터리 / 최상위 폴더
절대 경로와 상대 경로

많은 운영체제는 디렉터리를 파일과 동일하게 간주한다
디렉터리 구성 정보 -> 디렉터리 테이블

• 파일 이름
• 위치를 유추할 수 있는 정보
• (파일 속성) -> 파일 시스템에 따라 명시하는 것도 있음

파일 시스템을 이용하기 위한 준비

파일 시스템

파일과 디렉터리를 관리하는 커널의 한 부분
다양한 파일 시스템이 있고, 여러 파일 시스템을 동시에 사용할 수 있음
blkid -o list로 확인할 수 있음

보조기억장치 하나에 단일한 파일 시스템이 사용되는 것이 아니다
파티셔닝(aprtitioning): 보조기억장치의 영역을 구획하는 작업
파티션(partition): 보조기억장치에서 구획된 영역

포매팅파일 시스템을 만드는 작업
mkfs -t [파일시스템] [디바이스]

마운트(mount)
파일 시스템에 접근할 경로 결정
파일 시스템을 다른 파일 시스템에 편입

파일 시스템 만들고 연결하기

fdisk
파티션 표 조작

parted
파티션마다 어떤 파일 시스템으로 되어있는지 확인
리눅스에선 ext2 파일 시스템이 주로 쓰임

mkfs -t [파일시스템]
파일시스템 만듦
journal: 파일 시스템의 무결성을 보장하기 위한 것

mount [디바이스] [마운트할 경로]
umount [디바이스]

/etc/fstab
마운트 정보를 넣어두면 리부팅해서 마운트가 유지

파일 시스템 종류와 특성

FAT 기반 파일 시스템
FAT(File Allocation Table)를 활용하는 파일 시스템

※ FAT

• 파일이 어디에 할당되어 있는지 저장하는 표
• 메모리 캐시에 저장됨

저용량 보조기억장치용 파일 시스템으로 이용
ex) USB 메모리, SD 카드
디렉터리 엔트리에 파일 속성 표현

아이노드 기반 파일 시스템(unix기반 파일 시스템)
아이노드라는 색인 블록을 활용한 파일 시스템
※ 색인 블록

• 파일에 접근하기 위한 블록들에 대한 정보가 있는 특별한 블록

아이노드는 사실상 파일 이름 빼고 파일의 모든 것을 담고있음

아이노드의 사용량이 100%로 찼을 경우 데이터 영역에 용량이 남아 있어도 파일 생성 불가

ls -i, stat

아이노드 조회 가능
df -ih

아이노드 사용량 확인 가능

NTFS
윈도우 운영체제에서 주로 사용되는 파일 시스템

APFS
macOS, IOS, watchOS, tvOS에서 주로 사용되는 파일 시스템

ext2, ext3, ext4, xfs
리눅스 운영체제에서 주로 사용되는 파일 시스템
ext2빼고 나머지가 주로 사용됨

파일 시스템 특성을 판단하는 기준은 얼마나 큰 파일을 저장할 수 있는지 저널링 기능을 지원하는지임

저널링 파일 시스템(journaling file system)
파일 시스템에 크래쉬가 발생했을 때 빠르게 복구하기 위한 방법
1. 작업 직전 파티션의 로그 영역에 로그를 남긴다.
2. 로그를 남긴 후 작업을 수행한다.
3. 작업이 끝났다면 로그를 삭제한다.

파이썬 동작원리

파이썬은 소스 코드를 컴파일하여 바이트코드로 변환한 후, 이를 파이썬 인터프리터에 의해 실행합니다.

인터프리터는 바이트코드를 한 줄씩 읽어서 실행하며, 필요한 경우에는 C/C++로 구현된 내장 함수나 라이브러리를 호출하여 작업을 수행합니다.

파이썬은 동적 타이핑을 지원하기 때문에 실행 시에 변수의 타입을 체크하고 필요에 따라 메모리를 자동으로 관리합니다.

파이썬 인터프리터

인터프리터(Interpreter)는 컴퓨터 프로그래밍 언어로 작성된 소스 코드를 실행하는 프로그램입니다.

인터프리터는 소스 코드를 한 줄씩 읽어들여 해당 코드를 즉시 실행하며, 실행 결과를 즉시 확인할 수 있습니다.

이는 컴파일러와 대비되는 실행 방식입니다.

인터프리터의 주요 특징은 다음과 같습니다:

• 런타임 실행: 인터프리터는 소스 코드를 실행하기 위해 런타임에 코드를 해석하고 실행합니다. 이는 소스 코드를 한 줄씩 읽으며 즉시 실행되므로, 작성한 코드의 결과를 빠르게 확인할 수 있습니다.
• 소스 코드 해석: 인터프리터는 소스 코드를 직접 해석하여 실행합니다. 각 줄을 해석할 때마다 해당하는 동작을 수행하므로, 코드를 작성하고 바로 실행 결과를 확인할 수 있습니다. 이는 개발 과정에서 디버깅과 실험을 용이하게 합니다.
• 타입 체크: 인터프리터는 변수의 타입을 동적으로 체크하여 실행 중에 타입 오류를 발견할 수 있습니다. 이는 동적 타이핑 언어에서 유연한 타입 체크를 가능하게 합니다.
• 이식성: 인터프리터는 대부분의 운영 체제에서 실행될 수 있으며, 특정 운영 체제에 종속되지 않습니다. 따라서 플랫폼 간 이식성이 뛰어나며, 동일한 소스 코드를 다양한 운영 체제에서 실행할 수 있습니다.

인터프리터는 컴파일러와 대비되는 실행 방식을 가지고 있습니다.

컴파일러는 소스 코드를 기계어로 변환하여 실행 파일을 생성하는 반면, 인터프리터는 소스 코드를 직접 해석하고 실행합니다.

컴파일러는 소스 코드를 미리 전체적으로 변환하는 것이기 때문에 실행 속도가 빠르지만, 인터프리터는 코드를 한 줄씩 해석하고 실행하기 때문에 실행 속도가 상대적으로 느릴 수 있습니다.

그러나 인터프리터는 수정 및 디버깅이 용이하고, 코드의 결과를 즉시 확인할 수 있는 장점을 가지고 있습니다.

동적 타이핑

동적 타이핑(Dynamic typing)은 프로그래밍 언어의 타입 시스템 중 하나를 말합니다.

동적 타이핑 언어에서는 변수의 타입을 미리 선언하지 않고도 사용할 수 있습니다.

변수는 실행 시간(runtime)에 자동으로 타입이 결정되며, 할당된 값에 따라 동적으로 타입이 변경될 수 있습니다.

예를 들어, 파이썬에서는 다음과 같이 변수를 선언하고 사용할 수 있습니다:

x = 5  # 정수형 값으로 변수 x를 선언
x = "Hello"  # 문자열 값으로 변수 x의 타입이 변경됨
x = [1, 2, 3]  # 리스트 값으로 변수 x의 타입이 변경됨

위의 예시에서 변수 x는 처음에는 정수형으로 선언되었지만, 이후에는 문자열, 그리고 리스트로 변경되었습니다.

이처럼 동적 타이핑은 변수의 타입을 실행 시간에 결정하기 때문에, 변수에 어떤 종류의 값이 들어올지 미리 예측할 수 없는 상황에서 유연성을 제공합니다.

동적 타이핑 언어의 장점은 다음과 같습니다:

• 유연성: 변수의 타입을 미리 선언하지 않아도 되므로, 다양한 종류의 값을 할당할 수 있어 프로그램의 유연성을 높입니다.
• 생산성: 타입 선언을 생략할 수 있기 때문에 코드 작성이 간결하고 빠릅니다.
• 빠른 프로토타이핑: 미리 타입을 선언할 필요가 없기 때문에, 아이디어를 빠르게 실험하고 구현할 수 있습니다.

하지만 동적 타이핑은 몇 가지 단점도 가지고 있습니다:

• 디버깅의 어려움: 변수의 타입이 실행 시간에 결정되므로, 타입 오류를 발견하기 어려울 수 있습니다.
• 성능 저하: 타입 체크 및 변환 작업이 실행 시간에 추가되므로, 컴파일 타임에 타입을 체크하는 정적 타이핑 언어에 비해 실행 속도가 느릴 수 있습니다.

파이썬 장단점

장점은 다음과 같습니다.

• 가독성: 파이썬은 간결하고 읽기 쉬운 문법을 가지고 있어, 코드를 작성하고 이해하기 쉽습니다. 이는 개발자들이 생산적으로 작업할 수 있게 도와줍니다.
• 쉬운 학습 곡선: 파이썬은 배우기 쉬운 언어입니다. 간단하고 직관적인 문법을 가지고 있으며, 많은 자료와 커뮤니티 지원이 있어 학습 곡선을 낮출 수 있습니다.
• 크로스 플랫폼: 파이썬은 여러 운영 체제에서 동작할 수 있습니다. Windows, macOS, Linux 등 다양한 플랫폼에서 사용할 수 있으며, 이식성이 뛰어나다고 할 수 있습니다.
• 풍부한 라이브러리: 파이썬은 많은 표준 라이브러리와 서드파티 라이브러리를 제공합니다. 이러한 라이브러리들은 다양한 기능과 작업을 쉽게 처리할 수 있도록 도와줍니다.
• 동적 타이핑: 파이썬은 동적 타이핑 언어로서, 변수의 타입을 미리 선언하지 않고도 사용할 수 있습니다. 이는 빠른 프로토타이핑과 유연한 개발을 가능하게 합니다.

단점은 다음과 같습니다.

• 실행 속도: 파이썬은 인터프리터 언어이기 때문에 다른 컴파일 언어에 비해 상대적으로 실행 속도가 느릴 수 있습니다. 하지만 최적화된 라이브러리를 사용하거나 C/C++로 작성된 핵심 부분을 최적화하여 성능을 향상시킬 수 있습니다.
• 글로벌 인터프리터 락(Global Interpreter Lock): 파이썬의 CPython 인터프리터에서는 GIL이라고 불리는 글로벌 인터프리터 락이 존재합니다. 이는 동시에 여러 개의 스레드가 파이썬 바이트코드를 실행하는 것을 제한하여, 멀티스레드 프로그램의 성능을 제한할 수 있습니다.

모델은 네트워크가 어떻게 동작하는지를 나타내는 데 사용됩니다.

네트워크 모델에는 대표적인 모델이 두 가지가 있는데, 그건 바로 OSI 7계층 모델과 TCP/IP 4계층모델입니다.

계층을 나누는 이유는 통신이 일어나는 과정을 단계별로 파악하기 용이하기 때문입니다.

각 계층은 독립적이기 때문에 특정 계층에서 이상이 생겼을 때 다른 계층은 놔두고 문제가 있는 계층만 고쳐서 문제를 해결할 수 있습니다.

OSI 7계층

OSI 7계층은 아래 계층인 Physical을 시작으로 Application까지 총 7계층으로 되어 있습니다.

1. 물리 계층 (Physical Layer)
   • 전기적, 기계적, 기능적인 특성을 이용하여 통신 케이블로 데이터를 전송한다.
   • 사용되는 통신 단위는 비트(bit)이며, 0또는 1만 나타낼 수 있다.
   • 단지 데이터를 전달만 할 뿐 전송하려는, 또는 받으려는 데이터가 무엇인지는 전혀 신경쓰지 않는다.
   • 대표적인 장치로 통신 케이블, 리피터, 허브 등이 있다.
2. 데이터 링크계층 (DataLink Layer)
   • 물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 수행을 도와주는 역할을 한다.
   • 맥 주소(MAC Address)를 가지고 통신한다.
   • 전송되는 단위를 프레임(frame)이라고 하며, 대표적인 장비로는 브리지, 스위치 등이 있다.
   • 이더넷, 투 포인트 프로토콜(HDLC, ADCCP), 근거리 네트워크 프로토콜(LLC, ALOHA) 등이 있다.
3. 네트워크 계층 (Network Layer)
   • 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능(라우팅)을 한다.
   • 경로를 선택하고 주소를 정하고 경로에 따라 패킷을 전달해주는 역할을 한다.
   • 대표적인 장비로 라우터, (라우팅 기능이 포함된)스위치가 있으며, IP 주소를 사용한다.
   • 데이터를 연결하는 다른 네트워크를 통해 전달함으로써 인터넷이 가능하게 만드는 계층이다.
4. 전송 계층 (Transport Layer)
   • 통신을 활성화하기 위한 계층이다. 보통 TCP 프로토콜을 사용하며, 포트를 열어서 응용 프로그램을 전송한다.
   • 양 끝단의 사용자들이 신뢰성 있는 데이터를 주고 받을 수 있게 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 한다.
   • 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고 연결 기반이다. 전송 계층의 패킷들이 유효한지 확인하고 전송 실패한 패킷을 다시 전송함을 의미한다.
5. 세션 계층 (Session Layer)
   • 데이터가 통신하기 위한 논리적인 연결을 한다.
   • 세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.
   • 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.
   • TCP/IP 세션을 만들고 없애는 책임을 진다.
6. 표현 계층 (Presentation Layer)
   • 데이터 표현이 상이한 응용 프로세스의 독립성을 제공하고, 암호화한다.
   • 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로 덜어준다.
   • 예를 들면, EBCDIC로 인코딩된 문서 파일을 ASCII로 인코딩된 파일로 바꿔주는 것
   • 해당 데이터가 텍스트인지, 그림인지, GIF인지, JPG인지의 구분 등의 역할을 한다.
7. 응용 계층 (Application Layer)
   • 최종 목적지로서 HTTP, FTP, SMTP, Telnet 등과 같은 프로토콜이 있다.
   • 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
   • 네트워크 소프트웨어의 UI 부분, 사용자의 입출력 부분을 담당한다.

TCP/IP 4계층

네트워크 전송 시 데이터 표준을 정리한 것이 OSI 7계층이었다면, 이 이론을 실제로 사용하는 인터넷 표준이 TCP/IP 4계층입니다.

1. 네트워크 인터페이스 계층 (Network Interface, Network Access)
   • OSI 계층의 1,2 계층에 해당된다.
   • TCP/IP 패킷을 네트워크 매체로 전달하는 것과 네트워크 매체에서 TCP/IP 패킷을 받아들이는 과정을 담당한다.
   • 에러 검출 기능과 패킷의 프레임화 기능을 수행한다.
   • 네트워크 접근 방법, 프레임 포맷, 매체에 대해 독립적으로 동작하도록 설계되었다.
   • 흐름 제어(Flow Control)는 Header(MAC)에서, 에러 제어(Error Control)는 Tailer(CRC)에서 수행한다.
2. 인터넷 계층 (Internet)
   • OSI 계층에서 3계층에 해당된다.
   • 어드레싱(addressing), 패키징(packaging), 라우팅(routing) 기능을 제공한다.
   • 논리적 주소인 IP를 이용한 노드간 전송과 라우팅 기능을 처리하게 된다.
   • 네트워크상 최종 목적지까지 정확하게 연결되도록 연결성을 제공한다.
   • 핵심 프로토콜은 IP, ARP, ICMP, IGMP 등이 있다.
3. 전송 계층 (Transport)
   • OSI 계층에서 3,4 계층에 해당된다.
   • 자료의 송수신을 담당한다.
   • 어플리케이션 계층의 세션과 데이터그램 통신서비스를 제공한다.
   • TCP/UDP가 핵심 프로토콜이다. TCP/UDP에 대한 구분을 하고 데이터에 대한 제어 정보가 여기에 포함된다.
4. 응용 프로그램 계층 (Application)
   
   • 다른 계층의 서비스에 접근할 수 있게 하는 어플리케이션을 제공한다.
   • 어플리케이션들이 데이터를 교환하기 위해 사용하는 프로토콜을 정의한다.
   • TCP/IP 네트워크를 사용하거나 관리하는 것을 도와주는 프로토콜이다.

Spark란?

대규모 데이터 분석을 위한 통합 엔진입니다.

빠르고 범용적인 인메모리 기반 클러스터 컴퓨팅 엔진입니다.

분산 메모리 기반의 빠른 분산 병렬 처리가 가능합니다.

배치, 스트림 대화형 쿼리, 머신러닝 등을 지원합니다.

scala, java, python, R 기반의 api 제공합니다.

주요 특징

1. 배치/스트림 처리

배치 처리와 스트림 처리 모두 가능합니다.

2. sql 기반 분석 지원

애드훅 분석과 대시보드 등을 만들 수 있습니다.

3. 큰 규모의 데이터 사이언스

다운 샘플링을 할 필요없이 페타 사이즈의 EDA를 가능하게 해줍니다.

4. 머신러닝

다양한 머신러닝 알고리즘 지원합니다.

Spark 구성 요소

1. Spark Core API

다양한 언어를 api 기반으로 지원합니다.

2. spark sql

대화형 쿼리로 데이터를 분석합니다.

dataframe을 통해 분산 sql쿼리로 동작하여 구조화된 데이터를 처리합니다.

3. Streaming

다양한 소스의 실시간 데이터를 처리할 수 있습니다.

4. MLlib

머신러닝 라이브러리을 지원합니다.

5. GraphX

그래프 처리를 위한 다양한 라이브러리 지원합니다.

Spark 아키텍처

Spark 애플리케이션을 클러스터 매니저에게 제출하면 여러 익스큐터들이 클러스터의 워커노드상의 동작하면서 분산 처리를 수행하는 구조입니다.

애플리케이션의 실행이 완료되면 클러스터 매니저(Cluster Manager)가 익스큐터(Executor)를 종료시키고 Driver가 성공이나 실패 상태가 되면서 종료됩니다.

1. Driver Program

사용자는 Driver Program을 작성하고 Spark Context를 생성합니다.

Driver에서는 애플리케이션의 정보를 유지 관리하고 익스큐터의 작업을 분석하고 스케줄링 및 최적화를 수행합니다.

2. Spark Context

Spark에서 주요한 진입점이며, 클러스터와의 연결을 나타내는 객체입니다.

Spark에 사용할 변수 설정, 환경 설정, 리소스 설정 등을 할 수 있습니다.

3. Cluster Manager

클러스터매니저는 클러스터의 리소스의 관리와 작업 스케줄링을 담당하는 역할을 합니다.

익스큐터를 실행시키게 되면 관련 정보를 Driver에 전송합니다.

클러스터 매니저는 Standalone, YARN, Mesos, Kubernetes가 있습니다.

4. Worker Node

Driver에게 할당받은 task를 실행시키면 task 상태와 성공여부를 Driver에 전송하는 역할 수행합니다.

5. Executor

할당받은 리소스를 활용하여 task를 수행하고 다른 익스큐터와 병렬로 수행합니다.

데이터를 이동시키거나 Driver와 통신하는 역할을 합니다.