Disk를 사용하는 두가지 주요 이유

1. 메모리의 휘발성 특성 => 파일 시스템 필요

• RAM과 같은 메모리는 전원이 꺼지면 그 안의 데이터가 모두 사라지는 휘발성 메모리
• 따라서 데이터를 영구적으로 보관하기 위해서 비휘발성 저장장치인 Disk가 필요하며, 여기에 데이터를 저장하기 위한 구조가 파일 시스템이다.
• 예시: 문서 저장, 사진 저장 등

2. 실행 중인 프로그램의 메모리 공간 부족 => 스왑 공간(Swap Space)활용

• 시스템의 메모리가 부족할 경우, 운영체제는 디스크의 일부를 가상메모리로 사용한다.
• 이는 RAM이 부족할 때 디스크를 임시로 메모리처럼 사용하는 방식으로, 성능은 떨어지지만 시스템이 계속 동작할 수 있도록 보조 역할을 한다.
• 예시:여러 개의 프로그램을 동시에 실행할 때

++

• RAM(작고 빠른 휘발성 메모리)

  • 작고 빠르지만 전원 꺼지면 사라짐

• Disk(SSD나 HDD와 같은 비휘발성 저장장치)

  • 느리지만 커다랗고 전원을 꺼도 데이터가 유지됨

  Swap-space 관리에 대하여

  

• 디스크는 파티셔닝(물리적인 디스크 => 논리적 디스크로 나눈다) 을 통해 여러 개의 logical disk로 나눌 수 있다. .

• swap area에는 파일 시스템과 달리 데이터가 빠르게 들어오고,나가기 때문에 속도 효율성이 중요하다.

• 따라서 스왑 영역에는 한 번에 대용량 데이터를 빠르게 처리할 수 있도록 설계된다.

RAID

RAID(Redundant Array of Independent Disks)

• 저렴한 디스크를 묶어서 같이 사용
  • 여러 디스크에 데이터를 중복 저장하거나 (신뢰성 향상)
  • 분산 저장한다. (속도 향상)

• sector 0은 부팅과 관련됨

• 디스크의 최소 단위 : sector

  • sector는 디스크 내부에서 데이터를 관리하는 가장 작은 단위이며, 데이터의 읽기/쓰기 요청은 디스크 컨트롤러가 직접 처리한다.

• 디스크 외부에서 접근하는 단위 : logical block

  • logical block은 운영체제나 파일 시스템이 디스크에 접근할 때 사용하는 단위이며, sector에 매핑되어 저장된다.

Disk Scheduling

Disk Management

1. Physical Formattaing

• 디스크를 컨트롤러가 읽고 쓸 수 있도록 sector 단위로 나누는 과정을 의미한다.
• 일반적으로 각 sector는 header + 실제 data + trailer 로 구성된다.
• header와 trailer에는 다음과 같은 정보가 포함된다.
  • sector number: 해당 섹터의 번호
  • ECC(Error-Correcting Code): 데이터 오류를 검출하고 수정하는 코드
• 이 정보들이 저장됨으로써 디스크 컨트롤러가 직접 데이터에 접근하고 운영할 수 있음.

2. Partitioning

• 디스크를 하나 이상의 실린더 그룹으로 나누는 과정을 의미한다.
• 이렇게 나뉜 각각의 영역을 OS는 독립적인 논리 디스크로 인식 하여 관리한다.
• ex) 디스크 하나를 사서, c드라이브, d드라이브로 파티션을 나누면 각각이 서로 다른 logical disk가 된다.
  • 각각의 파티션을 파일 시스템 용도, swap area 용도로도 사용 가능

3. Logical Formatting

• 위에 생성한 파티션에 파일 시스템을 설치하는 것. !
• 파일 시스템을 생성하는 과정을 의미한다.
• 논리적 포맷팅을 하면 다음과 같은 파일 시스템의 구조가 생성된다.
  • FAT(file alloacation table): 파일 시스템에서 데이터 저장 위치를 관리하는 테이블
  • inode: 파일의 메타데이터(파일 크기, 권한, 위치 정보 등)를 저장하는 구조체
  • free space: 사용되지 않은 공관을 관리하는 영역

4. Booting (부팅 과정)

• ROM에 있는 small bootstrap loader가 실행됨 => 이 부트스트랩 로더는 os를 로드하는 역할을 함.
• sector 0에서 부트로더를 로드하고 실행 => 부팅 시 가장 먼저 읽히는 영역.
• sector 0에는 full Bootstrap loader program이 포함=> 이 프로그램이 OS를 로드하는 역할을 함.
• OS가 디스크에서 로드되면서 실행됨.

Disk Scheduling Algorithm

FCFS(First Come First Service)

• 헤드의 이동거리가 너무 길어짐
• 비효율적

SSTF(Shortest Seek Time First)

• 현재 헤드 위치에서 제일 가까운 요청을 가장 먼저 처리한다.
• starvation 문제가 생긴다. (헤드가 멀리있는 곳으로 안가게 될 수 있음)

SCAN

• 가장 간단하면서도 획기적임
• 엘리베이터 스케쥴링이라고 불리기도 함.
• disk head 이동 거리도 짧아지고
• starvation 문제도 안생김

• 그런데 실린더 중간에 있으면 대기 시간이 평균적으로 짧은데, 끝에 있으면 대기 시간이 평균적으로 길다는 문제점이 생김.

C-SCAN

• circular scan임.
• 이동거리는 좀 길어질 수 있지만, 가운데 쪽 요청이나 가장자리 쪽 요청이나 평균적으로 기대할 수 있는 시간이 균일하다.

Other Algorithms

• 디스크 스케쥴링은 보통 scan에 기반함

• n-scan : 이동하는 동안에 큐에 들어온 요청은 다음 이동때 처리

• LOOK and C-LOOK
  • scan하고 c-scan의 약간의 비효율적인 측면을 개선
    • 요청이 있든 없든간에 항상 끝에서 끝으로 이동. 끝까지 다 찍고 나서 turn하고 들어오는 방식
    • 그런데 그쪽 방향으로 요청이 없으면 갈 필요 없잖아.
  • 더이상 그 쪽 방향으로 요청이 없으면, 거기서 방향을 바꿔버려.

Disk-Scheduling Algorithm의 결정

1. error detection & correction
2. 채널 공유

채널 공유

• 주파수 분할 (FDMA)

• 시 분할 (TDMA)

• 코드 분할 (CDMA)

• ~DMA: Division Multiple Access

우리는 원래 burst 통신을 한다. (확 땡겨씀)

• 단점: burst 통신이 쉽지 않다.

  • <=> Carrier Sense Multiple Access(CSMA)
    • : Carrier를 아무도 쓰지 않을 때 통신. burst 통신에 적합하다는 뜻.
    • 문제) 충돌
    • 해결책) 무작위의 시간과 기다림
      • 충돌이 잦으면, 무작위의 window 시간을 늘린다 (0초3초 => 0초5초)

• 절충안: 토큰 방식

  • 토큰을 갖고 있다면 말할(?) 수 있고, 더이상 이야기 하지 않는다면 토큰을 돌리는 방식이다. 따라서 충돌을 방지한다.

• 링 형태로 연결된 네트워크에서 하나의 토큰을 이용해 데이터 전송을 제어한다.

• 토큰이 왔을 때, 할 얘기가 없으면 그냥 토큰을 넘기고, 할 얘기가 있다면 토큰에 붙여서 넘기면 되는 간단한 방식이면서 고속 통신이였음.

옛날 dummy Hub vs 현재 switching Hub

• 
  • dummy hub는 단순히 받은 신호를 네트워크의 모든 포트에 브로드캐스트하는 역할
• 
  • switching hub는 데이터 패킷을 목적지 MAC 주소 기반으로 전송
  • 각 포트가 독립된 통신 채널을 가지며, 다른 장치의 트래픽에 영향받지 않음
  • Full-Duplex 지원 : 송신과 수신을 동시에 수행 가능

1)FDMA:

• 주파수를 나눠쓰는 방식
• Guard band: 서로 다른 주파수 채널 간 간섭을 방지하기 위해 확보하는 보호 구간

2)TDMA:

• Guard Time이 필요하다: TDMA는 하나의 주파수를 여러 사용자가 시간적으로 나눠서 사용하는 방식이다. 각 사용자는 정해진 시간 슬롯에서만 데이터를 전송한다. 그런데, 송신자가 멀리있는지, 가까이 있는지에 따라 전파 도착시간이 다르다. 이 시간 차이를 고려하지 않으면 먼 사람의 데이터가 늦게 도착하면서 다른 사용자의 데이터와 겹쳐 충돌이 발생할 수 있다. 그래서 Guard Time을 둬야함.

• 같은 주파수와 시간을 줬을 때, 한명이 쓰는 것보다 훨씬 손해본다의 의미 : 만약 한명이 독점적으로 주파수를 쓴다면 Guard Time이 필요 없겠지만, 여러 명이 TDMA 방식으로 나눠쓰면 각 슬롯마다 Guard Time을 확보해야 해서 실제로 쓸 수 있는 데이터 전송 시간이 줄어든다. 따라서 Guard Time 때문에 더 큰 손실이 발생할 수 있다.

3)CDMA:

• 특정한 코드(확산 코드, Spreading Code)를 사용하여 원하는 신호를 곱하는 방식으로 데이터를 전송한다.
• 모든 사용자가 같은 주파수와 시간대를 공유한다.

신호 전송과정) 1. 각 사용자에게 고유한 확산 코드를 할당

2. 데이터 신호와 해당 코드를 곱해서 송신

• 원하는 신호에 고유한 확산 코드를 곱함
• 이렇게 하면 신호가 넓은 주파수 대역으로 확산됨

3. 수신자는 해당 코드로 필터링해서 원래 신호 복원

• CDMA 시스템에서는 수신자가 할당된 코드와 같은 코드로 연산을 수행하여 자신의 신호만 복원하고, 다른 사용자의 신호는 무시할 수 있음.

이더넷

사실상 LAN하고 동일어임.

• 규모의 경제학 (가격 경쟁력으로 이김 => 나중에 기술 개발로 따로잡고)

• 90년대 중반까지도 CSMA/CD 방식으로 모든 NODE를 wire로 연결했다.
  • 최대 이슈
    • propagation delay
    • node 수가 증가할 수록, 속도가 떨어진다.

Switch vs Router

1) Switch

• Link layer 에서 동작
• ip 주소(x) => ip 계층을 다루지 않고, MAC 주소 기반으로 통신
• 이더넷 네트워크에서만 사용
• 같은 네트워크 내에서 장치들 간 데이터를 빠르게 전달
• MAC 주소 테이블을 이용해 패킷을 목적지로 전달

2) Router

• Network layer 에서 동작
• IP 주소 기반으로 패킷을 전달 => 서로 다른 네트워크 간 데이터 전송
• IP 계층 뿐만 아니라 그 이상의 계층까지 관여 가능
• 네트워크 간 라우팅을 수행하여 인터넷 통신 가능

Switch vs Router (포트 관점)

1) Switch

• 같은 네트워크(서브넷) 내에서 동작하기 때문에 모든 포트가 동일한 네트워크에 속함.
• MAC 주소를 기반으로 동작하며, 포트별 구별이 필요 없음.
• 같은 네트워크 안의 컴퓨터 들이 연결되면, 스위치는 MAC 주소 테이블을 참고하여 목적지 MAC 주소를 가진 장치로 데이터를 전달함.
• 즉, 모든 포트가 같으 네트워크에 속하고, 특별히 구별할 필요가 없음.

2) Router

• 서로 다른 네트워크 간 통신을 담당하므로, 각 포트가 서로 다른 네트워크에 연결될 수 있음.
  • 예를 들어, WAN(인터넷)과 LAN(내부 네트워크)을 연결하는 라우터라면, WAN 포트와 LAN 포트가 구별됨.
• 각 포트는 서로 다른 네트워크를 구별하는 역할을 하기 대문에, 포트별 설정이 다를 수 있음.
• 즉, 라우터는 네트워크 간 데이터를 전달하기 위해 포트를 구별해야함.

네트워크 계층별 데이터 단위 명칭

1. 이더넷 => Frame

• 이더넷은 데이터 링크 계층 에서 동작하며, 하드웨어와 밀접하게 연결되어 있기 때문
• 구성: MAC 주소(출발지/목적지) + 데이터 + CRC(오류 검출 코드)

2. 네트워크 계층 (IP)=> Packet

• IP 계층에서는 데이터를 전송할 때, 출발지 IP/ 목적지 IP 정보를 추가하여 네트워크 간 라우팅이 가능하도록 만듦.
• 구성: IP 헤더(출발지 IP, 목적지 IP) + 데엍

3. 전송 계층 (TCP/UDP)=> Segment / Datagram

• TCP => Segment : 신뢰성이 필요한 전송은 데이터를 작은 단위로 나누어 흐름 제어 및 오류 제어를 수행

• UDP => Datagram: 신뢰성보다 빠른 전송이 중요한 경우는 패킷 단위로 데이터를 전송하며, 이를 데이터그램이라고 한다.

3. 전송 계층 => Segment / Datagram

Frame 형식

1. Preamble

• 무의미한 1과 0의 반복 후 마지막은 11로 !
  • 워밍업
  • 타이밍 sync를 맞추기 위함
    • 즉, 새로운 frame이 시작됐다는 것을 알리면서 속도도 알면서 ~

2. 주소

3. 그 외

Ethernet

HW 주소 (HW addr, MAC addr)

• 6BYTE 주소(48bit)
• 원칙적으로 전세계 유일 (주민번호 개념)
  • 일부업체는 재사용함 (어처피 LAN 안에서 사용되니까 문제 발생하기 어려움)

Switch

• 원래 wire로 연결되어있던 것을 switch로 바꾼 것임: 원래는 모든 포트가 듣던 것(브로드캐스트 방식)을, switch를 통해 특정한 node한테만 데이터 전달(유니캐스트 방식)
• MAC 주소 기반의 포워딩 : 각 포트에서 학습한 MAC 주소 테이블 기반임.
• switch는 자체 ID가 없음. : IP주소를 할당받는 라우터와 다르다.

Ethernet

• 컴퓨터 네트워크에서 가장 널리 사용되는 유선 LAN 기술로, 장치 간 데이터 전송을 위한 프로토콜을 제공한다.

주요개념

1. ARP : IP 주소를 이용해 해당하는 MAC 주소를 찾는 프로토콜이다.
2. Subnet: 하나의 네트워크를 작은 네트워크 그룹으로 나눈 방식

이더넷 프레임 구조

• 이더넷에서 데이터 전송 시 프레임이라고 한다.

이더넷 네트워크의 기본 동작

• MAC 주소 기반 통신: 스위치 등의 네트워크 장비는 목적지 MAC 주소를 기반으로 프레임 전달
• 브로드캐스트: ARP 요청과 같은 패킷은 네트워크 내 모든 장치에 전송된다.
• 게이트웨이를 통한 인터넷 연결내부 네트워크에서 인터넷으로 나가기 위해 GateWay를 거쳐야 한다.

서브넷과 IP 주소

• IP 주소: 네트워크 내 장치 식별 주소
• 서브넷 마스크: 네트워크와 호스트를 구분
• 게이트웨이 주소: 다른 네트워크로 나갈 때 사용하는 라우터의 IP

스위치

• 프로토콜이 없고, 경험을 통해 학습한다.

• 프로토콜 없이 동작: 특정 네트워크 프로토콜 없이도 작동하며, 네트워크 트래픽을 분석하여 학습한다.
• MAC 주소 학습: 처음에는 목적지 MAC 주소 모름 => 패킷을 모든 포트로 전송(플러딩) => 응답을 통해 해당 MAC 주소가 연결된 포트를 학습.
• 포트와 MAC 주소 매핑: 학습한 정보를 MAC 주소 테이블(MAC 주소 + 연결된 포트)로 저장하여, 이후 같은 목적지의 트래픽은 해당 포트로만 전달한다.
• 네트워크 효율성 증가: 학습된 정보를 기반으로 필요 없는 포트로의 전송을 차단하여 네트워크 트래픽을 줄인다.

네트워크 구성해보기

윈도우 pc 4 MAC 1 서버 2 프린터 1 Macbook 1

• pc는 nat router 뒤쪽에 숨기는게 좋아

  • 물론 해커들이 nat router 뚫을 수 있지만, 방화벽 뒤에 어떻게든 숨겨 ip가 드러나지 않게 하는게 좋음.

• server는 nat router 뒤에 숨기면 안돼. global ip를 가져야 하기 때문임

  • switch에 연결하자

• nat router는 기본적으로 무선연결을 하고 있으니 wifi를 통해 노트북 연결한다.

• 프린터는 두가지 방법이 있음

  • 1) nat router 쪽
    • 프린터가 이용하는 출력 포트를 nat router에 강제로 포트 매핑한다. 테이블에다가 static 매핑을 한다. 그럼 nat router 자체가 프린터처럼 보인다. 그럼 server가 nat router 자체를 프린터로 보면서 프린트 할 수 있게 된다.
  • 2) server 쪽
    • 그런데 이건 프린터를 위해 global ip달라고 하는건 좀 무리

링크계층과 이더넷을 소개한다.

라우터 (네트워크 계층)

• Router : 네트워크 장치로, IP 패킷을 수신하여 적절한 목적지로 전송하는 역할
• 무선 공유기는 Nat Router의 역할을 한다.
• Nat: 공인 ip 주소와 사설 ip 주소 간에 변환 역할을 한다.

네트워크 다이어그램

• 링크 계층과 네트워크 계층의 프로토콜 흐름과 구성 요소를 설명
• ip계층에서 어느 link를 써야하는지 정해지면, 그 link 헤더를 붙여서 보내주는 간단한 역할임
  • 단순한 계층인데, 왜 중요하냐? : 전체적인 망의 효율성을 담보해줄 수 있음 !
  • 원래 와이파이가 1mbps였음. 요즘엔 기가까지 보내. 네트워크가 10년새 1000배가 빨라진거임
  • 이더넷도 마찬가지 5,10mbps 였던 것이 1000배가 됨. 속도가 ! => 이 속도는 링크 계층과 물리계층 덕에 빨라진 것임 !

결론: 링크계층은 1개의 링크를 연결하는 역할을 한다 ~

데이터 링크 계층의 서비스

01. Error Detection(오류 검출)

• CRC (Cyclic Redundancy Check)
• TCP Checksum을 사용하여 입력 데이터 T를 검증 예: 𝑇(100𝐵)→𝑇′(150𝐵)
• 심각하게 error detection을 함.
  • 비트들이 정말 많이 깨지기 때문임.

02. Error Correction(오류 수정)

• 터보 코드 (Turbo Code), LDPC (Low-Density Parity-Check) 코드 등 사용

• 그냥 역함수를 해주는건데, 작은 noise에서 복원이 잘된건지, 큰 NOISE가 섞이면서 복원이 잘 안된건지 자체는 알 수 없다.

요약)

• 데이터 통신에서는 오류 검출을 통해 전송 중 문제를 발견하고, 오류 수정을 통해 복원 가능한 데이터를 재구성합니다.
• 함수 𝑓와 𝑓−1는 데이터 변환과 복원에 중요한 역할을 하며, 노이즈의 강도가 복원 가능성을 결정짓는 중요한 요소로 작용합니다.

Checksum vs CRC 오류 검출 정리

01. Checksum

특징)

• 소프트웨어(SW) 방식으로 구현
• 데이터의 Word 단위로 덧셈(+)연산을 수행하여 오류를 검출

장단점)

• 간단한 방식으로 구현이 가능
• 하지만 검출 성능(detection performance)이 낮음

02. CRC (Cyclic Reducdancy Check)

특징)

• 하드웨어 방식으로 구현
• 데이터의 비트 단위로 연산하여 더 정밀한 오류 검출 가능

장단점)

• 높은 성능(perforamance)을 제공
• 하지만 하드웨어의 의존성이 큼

링크 계층(Link Layer)와 TCP/IP에서의 오류 검출 방식

• 링크 계층(Link Layer)

  • 오류 검출 방식: CRC (Cyclic Redundancy Check)를 주로 사용
  • 이유: 링크 계층의 대부분은 하드웨어 기반 장치에서 구현되므로, 하드웨어적으로 처리할 수 있는 CRC가 적합. CRC는 비트 단위의 정밀한 오류 검출을 지원하므로, 데이터의 무결성을 보장하는 데 효율적.

• TCP/IP

  • 오류 검출 방식: Checksum (체크섬)을 사용
  • 이유: TCP/IP는 소프트웨어(SW)에서 실행되는 프로토콜 스택의 일부로, 하드웨어보다는 소프트웨어 기반의 간단한 방식인 Checksum이 적합. Checksum은 Word 단위 연산으로 구현이 간단하며, 이미 하드웨어 기반 링크 계층에서 CRC를 통해 1차적인 오류 검출이 이루어졌기 때문에, 추가적인 간단한 검증을 목적으로 사용.

Error correction

1. CRC와 연산 속도

• CRC (Cyclic Redundancy Check) 는 오류 검출을 위한 기법이며, 연산 속도가 빨라야 하므로 하드웨어에서 처리하는 경우가 많다.
• Error Correction 또한 CRC를 사용하여 수행되는 경우가 있다.

2. Physical Layer와 Link Layer의 차이

• Link Layer (데이터 링크 계층)
  • 데이터를 0과 1로 처리한다. (디지털 관점)
• Physical Layer (물리 계층)
  • 데이터를 아날로그 신호로 본다.
  • 무선의 경우 전파를 이용하여 데이터를 전송한다.
  • 유선망(이더넷 등)은 데이터를 전압(볼트)으로 변환하여 전송한다.

3. Physical Layer의 전압 표현 방식

• 이더넷과 유선망: 데이터를 전압으로 변환하여 전송
  • 단순한 0V, 5V의 두 단계만 사용하면 높은 속도를 지원하기 어려움.
  • 따라서 여러 개의 전압 레벨을 사용하여 데이터를 전송한다. (ex: 이더넷에서는 5개의 전압 단계 활용)

4. SSD와 오류 정정

• SSD의 저장 용량 증가에 따라 Physical Layer에서의 데이터 표현 방식 변화
  • 한 비트를 직접 저장하는 것이 아니라, 여러 개의 비트를 한 셀에 저장하여 신뢰성을 높임.
  • 이를 통해 에러 발생을 줄이고 저장 효율성을 높이는 방식을 사용함.

5. Physical Layer에서의 오류 판단

• Link Layer 관점
  • 데이터가 0과 1로 구분됨.
  • 원래 1이었던 값이 0이 되면 오류로 판단.
  • Physical Layer 관점
  • 데이터는 아날로그 전압 신호로 표현됨.
  • 신호가 크거나 작으면 명확하게 0 또는 1로 인식.
  • 하지만 애매한 중간값에 위치하면 오류 발생 확률이 높아짐.
  • 즉, 경계에 가까운 값일수록 오류 확률이 높아지므로 오류 정정 코드(ECC)가 개입함.

6. 최근 오류 정정 방식의 변화

• 최신 오류 정정 기법에서는 0과 1 사이의 애매한 값을 에러일 확률이 높다고 판단하여 자동으로 보정하는 경향이 강함.
• 즉, 에러 발생 가능성이 높은 신호 값을 감지하여 오류 정정을 수행함.

데이터 링크 계층의 서비스

1. Error detection, correction
2. 채널 공유 프로토콜

• 채널: 동시에 한명만 사용할 수 있는 미디어의 단위

FDMA (주파수 분할)

Frequency Division Multiple Access - 주파수 분할 방식 분할 기준: 주파수를 나눠서 사용 방식: 각 사용자가 고유한 주파수 대역 할당받음 특징: 연속적인 전송 가능, 간섭 적음

TDMA (시간 분할)

Time Division Multiple Access - 시분할 다중 접속 분할 기준: 시간을 나눠서 사용 방식: 동일한 주파수를 시간 단위로 나누어 사용 특징: 시간 동기화 필요

대표적인 예: 2G GSM, 일부 3G 네트워크

CDMA (코드 분할)

Code Divistion Multiple Access - 코드 분할 다중 접속 분할 기준:코드를 나눠서 사용 방식: 동일한 주파수를 코드로 구별 특징: 여러 사용자가 동시에 같은 주파수 사용 가능

대표적인 예: 3G 이동통신 (W-CDMA, CDMA2000)

서브넷과 NAT 개념을 배운다.

• 주소개념
• 라우팅(경로)
  • DV Routing : 인접 라우터와 정보 교환
  • LS Routing : 전체 네트워크의 링크 상태 정보 수집

라우팅이란 목적지가 주어질 때, 각각의 중앙 장비들이 패킷을 받으면 NEXT HOP으로 보낸다. 최종적으로 목적지에 도착!

• IP랑 다 연결되어있음 단점)
• IP를 잘 못바꿈

IP

• IPv6: 128bit로 표현
  • 8bit를 16진수로 16개!
    • 2A:38:58 ... 16개로 ~
• IPv4: 32bit로 표현
  • 8bit를 10진수로 4개!
    • 192.64.162.45

라우팅 테이블 (포워딩 테이블)

• 목적지 IP 주소를 넣었을 때 Next hop을 알 수 있어야 함
• 그러려면 라우팅 테이블에 전세계 ip 주소에 해당하는 next hop이 적혀있어야 함
• 그런데 전세계 ip 주소는 몇십억개 일 것임.
• 그렇게 되면 기가 엔트리 메모리가 필요해짐. => 이때, 어느 비슷한 ip 주소들은 next hop이 같을 것이란 아이디어가 생김 => subnet으로 묶자

subnet

ip 여러개 묶어서 하나의 entry로 생각할 수 있는 개념

• 지역적으로, 장비적으로 몰려있다.
• 표현법 : 134.64.0.0 / 10(bit)

예시

아래 상황과 같을 때 각각의 라우터들의 라우팅 테이블은 어떻게 되는지 알아보자.

우리가 상식적으로 생각한 subnet

• 이것이 일종의 gateway 역할
• 우리가 일반적으로 네트워크를 쓸 때 gateway가 존재한다.
• gateway까지 가는 경로는 하나밖에 없게 된다.
• 라우팅 테이블을 복잡하지 않게 만들기 위함이다

각각의 노드는 자신의 이웃이든, 전체에게든 정보를 공유해야 한다. 각 gateway는 자기의 subnet을 대표해야 한다.

• 9.3.6.5는 아래와 같이 표현 가능하다.
  
  • 위쪽 표현이 좀 더 적절하다.
    • 단순하게 표현할 수록 다른 노드에서 볼 때 entry가 단순해짐.

IP 패킷

특정 layer 알기 위해서는 특정 layer가 갖고 있는 패킷의 구조를 알고 있으면 도움이 된다.

오늘은, IP 패킷에 대해 알아보자 ~

이렇게 쌓아나간 헤더들 + HTML 본문이 수신측에 도착하면, 아래 사진과 같이 해당 Layer에 도착하면, 해당 header를 양파 까듯이 벗긴다.

IP Header

• 32비트를 한 줄로 표현한다.
• TTL: 패킷이 루프를 돌게되면, 네트워크를 죽이게 된다, 그걸 막기 위해서 라우터들은 1hop 마다 TTL 값을 -1씩 한다. 0이 되면 버린다. 네트워크 장비 죽이지 않기 위해서임.

IP의 기초 및 라우팅 기법을 배운다.

라우팅 프로토콜 방식

Distance Vector(DV) 라우팅

DV 라우팅 프로토콜은 네트워크 내의 각 라우터가 자신의 라우팅 테이블을 이웃 라우터들과 주기적으로 교환하는 방식이다. 각 라우터는 이웃으로부터 받은 정보를 기반으로 자신이 알고 있는 경로의 거리를 업데이트한다.

• 예시 프로토콜: RIP(Routing Information Protocol)
• 특징
  • 각 라우터는 네트워크 내의 모든 목적지까지의 거리 정보를 가지고 있다.
  • 네트워크의 모든 경로에 대한 정보는 이웃 라우터와만 교환된다.
  • 루프 방지 메커니즘이 필요하며, 각 라우터는 자신의 테이블을 주기적으로 업데이트한다.

    Link State(LS) 라우팅

    LS 라우팅 프로토콜은 네트워크의 전체 토폴로지를 모든 라우터가 알고 있도록 하는 방식이다. 각 라우터는 자신의 직접 연결된 링크 상태 정보를 이웃 라우터들에게 전파하고, 네트워크 전체의 상태 정보를 수집하여 최단 경로를 계산한다.
• 예시 프로토콜: OSPF(Open Shortest Path First), IS-IS(Intermediate System to Intermediate)
• 특징
  • 라우터는 자신의 링크 상태 정보를 네트워크 내 모든 라우터에게 전파한다.
  • 각 라우터는 전체 네트워크의 링크 상태 정보를 바탕으로 최단 경로를 계산한다.
  • 보다 신속한 라우팅 테이블 업데이트와 보다 정확한 경로 계산이 가능하지만, 초기 전파와 링크 상태 정보를 업데이트하는 과정이 복잡할 수 있다.

정리

근래에는 LS 라우팅 프로토콜이 DV라우팅 프로토콜보다 더 많이 사용된다. 이유)

1. 느린 업데이트 속도

• 문제: DV 라우팅 프로콜은 주기적으로 라우팅 테이블을 이웃 라우터와 교환한다. 네트워크 상태가 변경되었을 때, 정보가 전체 네트워크에 퍼지는 데 시간이 걸리기 때문에 업데이트 속도가 상대적으로 느릴 수 있다.

2. 루프 문제와 counting to infinity 문제

• 문제: DV 프로토콜은 라우팅 테이블의 거리 값을 주기적으로 갱신하기 때문에 루프가 발생할 수 있따. counting to infinity는 라우팅 루프가 생길 때 거리 값이 무한히 증가하는 현상이다. 예를 들어, 두 라우터가 서로의 경로를 잘못 인식하여 거리가 계속 증가하는 문제가 발생할 수 있다.
• 결과: 네트워크의 성능 저하와 패킷 손실을 유발할 수 있다. 이를 방지하기 위해 다양한 루프 방지 기술이 필요하다.

LS 라우팅 프로토콜의 장점)

1. 빠른 업데이트 속도

• LS 프로토콜은 각 라우터가 네트워크의 전체 토폴로지를 알고 있으며 링크 내의 변화가 발생할 때 즉시 이를 전체 네트워크에 전파한다. 따라서 네트워크 변화에 대한 반응 속도가 빠르다.

2. 정확한 경로 계산

• 각 라우터가 네트워크의 전체 상태를 알고 있기 때문에, 최단 경로 알고리즘을 사용하여 정확한 최적 경로를 계산할 수 있다.

3. 루프 방지

• LS 프로토콜은 네트워크의 전체 토폴로지를 이용하여 경로를 계산하므로, 루프문제와 counting to infinity문제를 자연스럽게 방지할 수 있다.

ISP

ISP(Internet Service Provider) : 인터넷 서비스 제공자를 의미한다. 인터넷 접속 서비스를 제공하는 회사나 기관을 말한다. ISP는 개인 사용자, 기업, 기관 등에게 인터넷 연결을 제공한다.

DV와 LS 라우팅은 ISP 내부 네트워크에서 라우팅을 관리하는 방식을 의마한다. ISP의 내부 네트워크는 여러 라우터와 스위치로 구성되어 있으며, 이들 장비간의 효율적인 데이터 전송을 위해 라우팅 프로토콜을 사용한다.

즉, ISP 내부 네트워크에서는 DV와 LS 프로콜을 사용하여 네트워크 내 데이터 흐름을 효율적으로 관리하고, 고객에게 안정적인 서비스를 제공한다.

ISP 간의 라우팅, 즉 AS간의 라우팅은 경제적 논리가 큰 역할을 한다. 기술적인 최적화보다는 금전적인 최적화를 추구함. 이 과정에서 BGP가 핵심적인 역할을 한다.

BGP(Border Gateway Protocol)

• 설명: BGP는 인터넷의 핵심 라우팅 프로토콜로, 서로 다른 AS(Autonomous Systems) 간의 라우팅을 관리한다. 각 AS는 BGP를 사용하여 자사의 네트워크와 다른 AS간의 경로를 교환하고, 최적의 경로를 선택한다.

DV는 intra ISP이고, BGP는 inter ISP이다.

1. DV- Intra-ISP 라우팅 Intra-AS 라우팅은 하나의 자율 시스템(AS) 내에서 이루어지는 라우팅을 의미한다. 자율 시스템(AS)는 단일 조직이나 ISP가 관리하는 네트워크 집합이다.

• DV 프로토콜 역할
  • 예시: RIP(Rounting Information Protocol)와 같은 DV 프로토콜은 하나의 AS 내에서 네트워크의 라우팅을 관리한다. DV 프로토콜은 라우터가 이웃과 거맂 어보를 교환하여 최적의 경로를 결정한다.

2. BGP - Inter-ISP 라우팅 Inter-AS 라우팅은 서로 다른 자율 시스템 간의 라우팅을 의미한다. 이는 다양한 네트워크 간의 연결을 관리하며, 인터넷의 전역적인 데이터 흐름을 조정한다.

• BGP의 역할
  • 설명: BGP는 서로 다른 AS 간의 라우팅 정보를 교환하고, 최적의 경로를 결정하는 데 사용된다. ISP간에 데이터가 이동할 때 BGP를 통해 경로를 조정하고, 상호 연결된 네트워크의 효율적인 데이터 전송을 보장한다.
  • 특징: BGP는 라우팅 정책과 경제적 고려사항을 반영하여 경로를 선택한다. 이는 각 AS의 비즈니스 모델과 전략을 기반으로 하며, 복잡하고 확장성이 높은 인터넷 환경에서 필수적인 역할을 한다.

• IP 주소 체계는 아주 정적이지 않음.
  • 예를 들어 MIT가 AT&T의 서비스를 받다가 너무 비싸서 다른 타회사의 서비스로 옮길 수 있음.
  • 동일한 IP주소를 쓰지만, 어제까지는 미국에 연결되어 있는 기계가 오늘은 일본에 연결될 수 있다는 뜻.
    • 왜냐? ISP를 바꾼다는 것은, 라우팅의 체계를 완전히 바뀐다는 뜻과 같음.

• IP 패킷에 적혀있는 주소는 MIT 주소다.
• 패킷 안에는 최종 목적지만 써있다.
  • 최종 목적지를 보고 어느 Gateway로 가야하는지 유추를 해야 한다.
  • 즉, 라우팅 테이블 안에는 전세계 ip 중 특정 ip를 썼을 때 어떻게 가야하는지에 대한 정보가 적혀있어야 함.

• 현재 내 위치에서 MIT로 가려면, Next hop이 어딘지 알려줘야만 그쪽으로 간다.
• 그냥 대한민국 => 미국 이런식이 아님.

오늘 배울 것

어떻게 하면 라우팅 테이블의 목적지 주소 안에다가 전세계의 ip를 커버하도록 할 수 있을까?

• ip 주소 체계

IP 주소 체계

1. 주민등록번호 처럼? => 컴퓨터가 생기면 그때 IP 주소 부여 문제)

• IP 주소 횟수 부족
  • 만일 충분하다면? : 라우팅 테이블에 기기를 일일히 등록해야 한다.
    • MIT 내 기계 일일이 다 라우팅 테이블에. 그럼 라우팅 테이블은 수십억개 기계 정보 작성 ;; => 개별 등록 엔트리수가 너무 많다.
• 전화시스템은 이 방식을 사용한다.
  • 일일히 SKT 중앙 서버가 해당 휴대폰 번호의 기계를 찾아서 연결을 해주느라 시간 지연이 있는 것임.
  • 하루에 몇통밖에 안하니까 중앙 서버가 감당 가능 (Curcuit Switching)
  • VS : 그런데 인터넷은 패킷마다 길을 찾아야 함. 컴퓨터 한대가 하루에 패킷은 수십만개, 수천만개 왔다 갔다 한다. 그렇기 때문에 각 네트워크 안의 노드마다 라우팅 테이블을 관리하고, 직접 패킷의 내용을 까보고, 어디로 보낼지 직접 결정한다. (패킷 스위칭)

2. 우편주소체계 처럼?

• ip가 ISP에 따라 바뀔 수 있다.
• 고정 IP의 경우 모든 컴퓨터 설정을 바꿔야 함.
• IP 개수가 모자람 (넉넉한 IP 할당이 요구된다)

3. Classless Inter-Domain Routing (CIDR)

• class가 없다는 뜻 ~
  • 옛날에는 classA, classB 이런식으로 ip 안에도 class를 할당했었음. ip 개수 부족 현상이 심해졌음.

특징)

• 계층적임 (우편주소 같음 대한민국 ~ 서울 ~ 마포구 ~ 상암동)
  • 라우팅도 점점 좁혀감
• 계층 예외 가능
  • 완전히 계층적이지 않다는 것임. kt 서비스는 무조건 이 ip 주소로 시작해 ~ 이런것이 없다는 뜻.
• subnet

  subnet

ip가 이렇게 길게 있으면, ip주소의 32비트는 두가지 part로 구분된다

• subnet part
• host part

//단말 컴퓨터의 경우를 말하는 것임.

• 라우팅시, subnet이 동일하지 않은 컴퓨터는 subnet 단위로 라우팅을 한다
• subnet이 동일한 컴퓨터는 단말 단위로 라우팅을 한다.

• subnet이 다르면, 라우팅 테이블 안에 목적지가 있을 수 없음. => 이 패킷은 자동으로 GateWay로 간다.
• 라우팅 테이블이 아주 크지 않더라도 목적지를 찾아갈 수 있음.
• 전세계 모든 컴퓨터로 갈 수 있게 됨.
• 결론: 기본적으로 라우팅을 할 때는 subnet이 동일한지 안한지를 확인한다.

GateWay의 라우팅

• 조직에서 IP를 할 경우

  • subnet을 할당받는다.
  • ex) 173.23.226.xxx kau ip
  • => 표현을 다르게 173.23.226.0/24

  

• 라우팅 테이블 안에 모양이 이렇게 됨

• 비트 수가 많으면 많을 수록 우선순위가 높음

  • 그래야 gateway로 안감 subnet 같은데, 저 조건에도 맞게되니까

• subnet 조각화 : 만약 학교가 제주도에도 있어? 그러면 subnet을 새로 할당 받는 것이 아니라 subnet을 조각해 일부를 가져다 쓰는 것이 가능 : ip가 부족하니까 최대한 쥐어짜도록 설계해둠 즉, ip의 대부분은 고양에서 쓸거고, ip의 일부는 제주도에서 쓸 것임. 그것을 subnet 형태로 표현이 가능해야 라우팅이 가능할 것임

-만약 01로 시작한다면 그러면 64부터 시작하는 것이기 때문에 제주로 간다는 것임

• 64~127까지는 제주에서 쓰겠다는 것임
  • 잘생각해봐 1바이트는 8비트다. 01000000 => 숫자 64임, 10000000 => 숫자 128임 즉, 01111111 => 숫자 127 여기까지만 일치하기 때문에 ~~ 128번 부터는 고양에 mapping된다.

시스템 자체는 ip를 여기저기서 분할해서 쓸 수 있도록 subnet을 계층화시키고 예외를 두는 것이 가능하도록 만들어놧지만, 하지만 전세계 라우팅 테이블이 지저분해진다. 엔트리 수가 너무 많아지니까 !

1. 패킷 유실

• 패킷화 => 1기가를 한꺼번에 보낼 수 있는 네트워크 X
• Sequence Number, ACK, 타이머
  • Sequence Number 1bit가 필요하다. (패킷 유실 o, 패킷전송순서 보장일 때) : 1비트로 충분한 경우: 패킷이 손실되지 않고 순서가 보장되는 환경에서는 패킷의 확인 응답을 단순하게 구현할 수 있습니다. 이 경우, 단순히 "도착했다/안 했다"를 표시하는 데 1비트로 충분할 수 있습니다.
  • 패킷 순서가 보장되지 않을 때는 무한의 bit가 보장되어야 한다. : 패킷 순서가 보장되지 않는 환경에서는 모든 패킷의 순서를 고유하게 추적할 필요가 있습니다. 이는 많은 수의 비트가 필요하다는 것을 의미합니다. TCP에서 32비트 Sequence Number를 사용하는 이유도, 패킷이 도착 순서가 뒤섞일 수 있는 상황에서도 데이터의 순서를 정확히 재구성하기 위해서입니다.

2. 내용 변조
3. 패킷 전송 순서

복습

Sequence Number

• Sequence Number는 TCP 세그먼트의 데이터가 전체 데이터 스트림에서 어디에 위치하는지를 나타낸다. 송신 측에서는 이 번호를 이용해 각 바이트가 데이터 스트림의 어디에 위치하는지를 표시한다.
• 역할
  • 데이터 순서 보장: TCP는 순차적으로 데이터를 전송하지만, 네트워크 환경에서는 패킷이 도착 순서가 바뀔 수 있다. 수신 측에서는 Sequence Number를 사용해 패킷이 올바른 순서로 조립되도록 한다.
  • 중복 패킷 처리: 네트워크 환경에서는 중복 패킷이 발생할 수 있다. Sequence Number를 통해 수신 측에서는 중복된 데이터를 무시할 수 있다.
• *비트 수 *
  • TCP에서 Sequence Number는 32비트 크기이다. 이는 매우 큰 숫자 범위 (0부터 4,294,967,295까지)를 제공하며, 이 범위는 TCP 연결에서 송수신되는 데이터의 바이트 수를 충분히 처리할 수 있다.
  • 16비트는 0부터 65,535까지의 숫자만 다룰 수 있어, 대량의 데이터를 전송하는데 문제가 생길 수 있음.

    ACK

• ACK는 수신 측에서 송신 측으로 보내는 확인 응답으로, 송신 측이 전송한 데이터가 제대로 도착했음을 알린다.
• 역할
  • 신뢰성 보장: 수신 측은 데이터의 올바른 수신을 확인하게 위해 ACK를 송신 측에 보낸다. 이 ACK에는 수신한 데이터의 다음 예상 Sequence Number가 포함된다.
  • 손실 처리: 송신 측에서 기대했던 ACK가 오지 않으면, 이는 데이터 손실로 간주되고 해당 데이터를 재전송하게 된다.
• 비트 수
  • ACK Number도 32비트 크기이다. 송신 측에서는 이 번호를 통해 수신 측이 다음에 받을 것으로 예상되는 바이트의 위치를 확인한다.

    Timer

• 타이머는 TCP에서 데이터를 재전송할 시점을 결정하는 데 사용된다.
• 역할
  • 재전송 타이머: 송신 측에서 패킷을 전송한 후, 해당 패킷에 대한 ACK가 지정된 시간 내에 도착하지 안으면, 해당 패킷이 손실된 것으로 판단하고 재전송을 시도한다.
  • RTT 측정: 타이머는 또한 네트워크의 왕복 시간을 측정하여, 이후 전송에 사용될 타이머 값을 조정하는데 사용된다.

내용 변조

데이터 전송 중에 내용 변조(데이터의 무결성 손상)가 발생했는지 감지하기 위해 다양한 방법이 사용됩니다. 이 과정에서 트레일러(trailer)에 체크섬(checksum)을 추가하는 방법이 일반적인 방법 중 하나다.

데이터 무결성 검사란?

데이터 무결성 검사란 전송된 데이터가 손상되지 않고 원래의 내용과 동일하게 수신되었는지 확인하는 과정이다. 데이터 전송 중에 노이즈, 간섭 또는 해커의 공격 등으로 인해 데이터가 변조될 수 있다.

체크섬(Checksum)이란?

체크섬(Checksum)은 전송되는 데이터 블록에 대해 계산된 값으로, 데이터의 무결성을 확인하는 데 사용된다. 송신 측에서 데이터를 전송하기 전에 체크섬 값을 계산하여 데이터에 추가하고, 수신 측에서 데이터를 받은 후 같은 방식으로 체크섬을 계산하여 송신 측에서 받은 체크섬과 비교한다. 만약 두 체크섬 값이 일치하면 데이터가 무사히 전달되었다고 판단할 수 있다. 반대로, 일치하지 않으면 데이터에 변조가 발생했음을 감지할 수 있다.

트레일러에 1바이트 체크섬 추가

트레일러(trailer)는 전송되는 데이터의 끝부분에 추가되는 정보다. 트레일러에는 체크섬과 같은 무결성 검사 정보를 포함할 수 있다.

1바이트 체크섬: 체크섬의 크기를 1바이트로 제한한 경우, 이 체크섬은 데이터의 각 바이트의 합 등을 단순한 방식으로 계산할 수 있습니다. 예를 들어, 데이터를 구성하는 각 바이트의 값을 모두 더한 뒤, 1바이트(8비트)로 결과를 저장할 수 있습니다.

계산 예시: 데이터: 0x12, 0x34, 0x56, 0x78 각 바이트를 더한 결과: 0x12 + 0x34 + 0x56 + 0x78 = 0x114 1바이트로 표현할 때: 0x14 (결과의 하위 1바이트만 사용) 이 값 0x14가 체크섬으로 트레일러에 추가됩니다.

체크섬으로 변조 탐지 과정

송신 측: 데이터를 준비한 후, 이 데이터의 체크섬을 계산하고, 계산된 체크섬을 데이터의 끝에 트레일러로 추가하여 전송한다. 수신 측: 데이터를 받은 후, 수신한 데이터에서 체크섬을 분리합니다. 받은 데이터로 동일한 방식으로 체크섬을 계산합니다. 계산된 체크섬과 트레일러에서 분리한 체크섬을 비교합니다. 만약 두 값이 일치하면 데이터가 변조되지 않았다고 판단하고, 일치하지 않으면 변조가 발생했다고 판단합니다. 5. 1바이트 체크섬의 한계와 보완책 1바이트의 한계: 1바이트 체크섬은 매우 간단한 형태의 무결성 검사 방법입니다. 1바이트(8비트)는 256개의 고유한 값을 가질 수 있지만, 이 크기는 충돌 가능성이 높습니다(즉, 서로 다른 데이터가 같은 체크섬 값을 가질 수 있습니다). 따라서 1바이트 체크섬은 변조 감지에 약할 수 있습니다.

보완책:

더 큰 체크섬: 2바이트, 4바이트, 또는 16비트, 32비트 등 더 큰 크기의 체크섬을 사용하면 충돌 가능성을 줄일 수 있습니다. 해시 함수 사용: MD5, SHA-256과 같은 암호학적 해시 함수는 체크섬보다 훨씬 더 복잡하고 충돌 가능성이 낮은 값을 제공합니다. CRC (Cyclic Redundancy Check): 데이터 전송에서 자주 사용되는 오류 감지 코드로, 체크섬보다 더 강력한 오류 탐지가 가능합니다.

결론 1바이트 체크섬은 간단하고 빠르게 무결성을 검사할 수 있는 방법이지만, 그 자체로는 변조 탐지에 충분히 강력하지 않을 수 있습니다. 더 안전한 무결성 검사 방법으로 더 큰 체크섬 또는 암호학적 해시 함수를 사용하는 것이 좋습니다. 특히 보안이 중요한 경우에는 이러한 보완책을 고려해야 합니다.

page cache

• page cache는 메모리 관리의 중요한 개념으로, 운영체제가 효율적으로 메모리를 사용하기 위해 페이지 프레임을 관리하는 방식과 관련이 있다.
• 운영체제는 메모리에 페이지 프레임(page frame)을 할당하여, 프로세스가 당장 필요로 하는 데이터를 메모리에 올려둔다. 당장 필요하지 않은 데이터는 메모리에서 쫓아내고, 필요한 경우 다시 불러온다.
• 프로세스의 주소 공간을 구성하는 각 페이지는 두가지 상태 중 하나다.
  • swap area: 메모리에서 쫓겨난 페이지가 디스크이 swap area로 내려가 있는 상태. 페이지가 다시 필요해지면 스왑영역에서 메모리로 다시 로드된다.
  • page cache:메모리가 올라가 있는 상태로, 최근에 사용된 페이지가 캐싱되어 있어 빠르게 접근할 수 있다.
• page cache는 디스크 i/o를 줄이고 메모리 접근 속도를 높이기 위해 사용되며, 효율적인 메모리 활용을 통해 시스템 성능을 최적화한다.

buffer cache

• 프로그램이 실행될 때, 파일 입출력을 수행하는 경우가 발생할 수 있다.
• 프로그램이 파일을 읽기 위해 read 시스템 호출을 하면, 운영체제는 디스크에 있는 파일 데이터를 파일 시스템을 통해 읽어온다.
• 이 데이터는 먼저 버퍼 캐시에 저장된 후, 사용자 프로그램에 전달된다.
• 이후 동일한 데이터 요청이 발생하면, 디스크에 접근하지 않고 버퍼 캐시에서 데이터를 바로 제공하여 성능을 향상시킨다

비교

핵심

• page cache는 process의 주소 공간을 구성하는 page가 swap area에 내려가있는가? page cache에 올라가 있는가?에 대한 내용
• buffer cache는 파일 데이터가 file system storage에 저장되어 있는가? 운영체제의 buffer cache에 올라가 있는가?에 대한 내용

단위

• page cache의 단위는 page단위가 될 수 밖에 없음. 4KB(킬로 바이트) 단위의 page 사용 중.
• buffer cache의 단위는 디스크에서 어떤 파일의 block을 읽어와라 ~ 하는데, block이라는 것은 논리적인 block, 디스크에서는 이 sector 단위를 이야기함. 이 sector나 논리적인 블록이 옛날엔 512 byte였음. 그래서 4KB의 page에 비해서 다소 작은 단위임.
• 하지만 최근에는 buffer cache가 page cache와 통합이 되면서 (특히 리눅스) 그래서 buffer cache에서 사용하는 단위도 똑같은 4KB의 page 단위를 쓴다는 것.

Memory-Mapped I/O

파일 입출력을 효율적으로 처리하기 위해 메모리를 사용하는 기법이다. 이 기법에서는 프로세스의 주소 공간의 일부를 파일에 매핑하여, 파일에 대한 입출력을 메모리 접근처럼 수행할 수 있도록 한다.

• 주소 공간의 매핑 :
  • 프로세스의 주소 공간 일부를 파일 시스템의 특정 파일에 매핑한다. 이 매핑을 통해, 해당 메모리 영역에 접근하는 것이 곧 파일의 특정 부분에 접근하는 것과 동일해진다.
• 메모리 접근을 통한 파일 입출력 :
  • 매핑이 완료되면, 프로세스는 파일에 데이터를 쓰거나 읽는 대신, 마치 메모리에 데이터를 쓰고 읽는 것처럼 파일에 접근할 수 있다.
  • 예를 들어, 파일의 내용을 읽기 위해 별도의 read 시스템 호출을 사용할 필요 없이, 매핑된 메모리 영역에서 직접 데이터를 읽으면 된다.

    Page Cache and Buffer Cache

    기존의 read, wirte 시스템 콜을 쓰는 방식에 대해서 이 그림을 통해 먼저 설명한 후 그리고, Unified Biffer Cache때 어떻게 구조가 바뀌었는지 이야기해보자.

기존

기존의 파일 데이터를 읽고 쓰는 방법은, 두가지 interface가 있는 것.

파일 입출력 하는 방법

• 1. file을 open 한 다음에 read() wirte() 시스템 콜을 하는 것. 그러면 운영체제가 해당하는 파일의 내용이 buffer cache에 있으면 바로 전달, 없으면 디스크 파일 시스템에서 읽어와서 전달.
  • 이것이 read/write 시스템 콜을 이용하는 경우에 i/o를 하는 경로임
    • file system => buffer cache : 운영체제가 file system에 있는 내용을 buffer cache에 읽어오고 , 그런 다음에 사용자 프로그램한테 전달.
    • 전달받은 사용자 프로그램은 자신의 주소 영역이 있는 page에 buffer cache에 있는 내용을 copy 해서 사용한다.
• 2. memory mappend i/o
  • 이것도 처음에 시스템 콜을 한다.
  • 자신의 주소공간 중에 일부를 file에다가 mapping을 한다.
  • 이렇게 mapping을 해놓더라도 어처피 디스크에 있는 파일을 buffer cache에 읽어오는 것은 똑같음.
  • 그 내용을 page cache에 copy를 한다.
  • 그럼 그 내용이 파일의 mapped된 내용이 된다.
  • 지금부터는 사용자 프로그램이 자신의 page cache에다가 데이터를 메모리에 읽고 쓰듯이 요청하게되면, 그것이 read/write가 된다.

차이점 정리

1. read/write 시스템 콜을 사용할 때

• 해당 내용이 buffer cache에 있든 없든 항상 운영체제한테 요청해서 받아와야 한다.

2. memory-mapped I/O 사용할 때

• 일단 page cache에 올라온 내용은, 운영체제의 도움을 받지 않고, 자기 영역에 접근하는 방식. 장점: 이미 메모리에 올라와있는 내용에 대해서는 커널의 도움을 받지 않고, 자신이 직접 접근할 수 있다.

기존의 buffer cache 환경

• 파일 입출력을 할 때는 buffer cache를 통과해야 한다.
  • buffer cache에 있는 내용을 자신의 page cache에다가 한번은 복사해야 하는 오버헤드가 있음.

최근의 unified buffer cache

• 필요에 따라 page cache에서 공간을 할당해서 사용한다. (따로 buffer cache x)

프로그램의 실행

• 장점: Memory-mapped I/O를 사용하면 파일의 내용이 가상 메모리에 올라온 후, 시스템 콜 없이 CPU가 직접 접근할 수 있다. 즉, 캐시에 적재된 데이터를 별도의 복사 과정 없이 애플리케이션의 주소 공간에서 바로 사용할 수 있어 성능 오버헤드를 줄일 수 있다.

• 단점: Memory-mapped I/O는 페이지 캐시(즉, 버퍼 캐시)를 가상 메모리에 매핑하는 방식이므로 데이터 일광성 문제에 주의해야 한다. 특히, 동일한 파일을 여러 프로세스가 공유하는 경우, 한 프로세스에서 변경한 내용이 다른 프로세스에서 즉시 반영되지 않을 수 있다.

storage 데이터에 접근하는 방법

• 순차적인 접근
• 임의적인 접근 매체에 따라서 다름
• tape => 순차적 접근
• 하드디스크, 플래시메모리, cd => 임의적 접근

직접 접근이 가능한 매체라 하더라도, 데이터를 어떻게 관리하느냐에 따라서 순차적 접근만 허용되는 경우, 직접 접근이 가능한 경우가 있다. => 오늘, 그 이유에 대해 알아보자.

디스크에다가 파일을 저장하는 방법 3가지

• 파일은 크기가 균일하지 않다.
• 디스크에다가 파일을 저장할 때는 동일한 크키의 sector 단위로 나누어서 저장하고 있다.
• 파일 시스템이나, 디스크 외부에서 볼 때는 각각의 동일한 크기의 저장단위를 논리적인 block이라고 부른다.
  • 실제로 디스크 내부에는 각각이 sector 단위로 데이터를 저장하고 있음.
    • 어떤 임의의 크기의 파일을, 동일 크기의 block 단위로 나누고 있다는 뜻.
  • 메모리기법의 paging 기법과 유사함 => 저장하는 방법이 아래 3가지
• 1. Contiguous Allocation* : 연속 할당 방법
• 2. Linked Allocation* : link를 둔 연결 할당 방법
• 3. Indexed Allocation* : index를 둔 할당 방법

Allocation of File Data in Disk

• 디스크에다가 파일을 저장할 때는 동일한 크키의 sector 단위로 나누어서 저장하고 있다.
• 파일 시스템이나, 디스크 외부에서 볼 때는 각각의 동일한 크기의 저장단위를 논리적인 block이라고 부른다.
  • 실제로 디스크 내부에는 각각이 sector 단위로 데이터를 저장하고 있음.
    • 어떤 임의의 크기의 파일을, 동일 크기의 block 단위로 나누고 있다는 뜻.
  • 메모리기법의 paging 기법과 유사함

1. Contiguous Allocation

하나의 파일이 디스크 상에 연속해서 저장이 되는 방법

전시간에)

• 디렉토리라는 파일은 그 디렉토리 밑에 있는 파일들의 meta data를 내용으로 한다.

장점

*- 1. 빠른 i/o가 가능 *

• 특히 하드디스크 같은 매체는 대부분의 접근 시간이 head가 이동하는 시간이다. 바깥쪽 트랙 => 안쪽 트랙 이동 시간. 데이터를 읽거나 쓰는 크기는 별로 상관이 없음. 어떤 파일을 통째로 읽고 싶을 때, 한번의 seek로 많은 데이터의 내용을 받아올 수 있다.
• 연속할당은 파일 시스템 용도 말고, 또 다른 용도로 쓰는데, process의 swap area로도 쓴다. (파일을 저장하는게 아니라 process 주소 공간 중 일부를 물리적인 메모리에서 쫓아내고 , 나중에 필요할 때 올려놓는 용도로 씀) => 파일 시스템은 연속적인 공간이다. 전원이 나가더라도 내용이 유지되어야 하는데, swap area는 그런게 아니다. process가 끝나면 의미가 없는 정보이기 때문에 임시로 저장하고 process의 주소 공간 많은 양의 크기를 빠르게 디스크로 쫓아냈다가, 다시 메모리에 올리고 처럼 swapping의 용도는 공간 효율성보다 속도 효율성이 중요한 데이터에 속한다. 빠른 i/o를 위해서 연속 할당을 해주는 것이 좋다. 특히, realtime file은 빠른 속도가 중요하기 때문에 contiguous 할당이 참 좋음 ~~

*- 2. 직접 접근이 가능 * ex) main 이름의 파일 데이터의 길이는 6인데, 이 파일의 5번째 block을 읽고 싶을 때, => 앞의 4개의 블록을 다 접근할 필요가 없다. (연속적으로 저장되어 있기 때문임)

단점

• 외부조각 발생

• 파일의 크기는 계속 바뀌는데, 파일의 크키를 키우는데 대해 제약이 생긴다.
  • 미리 더 할당하더라도 크기 제약이 있기도 하고, 당장 사용하지도 않으니 => 내부조각 발생

2. Linked Allocation

하드디스크임에도 불구하고 직접접근이 불가능하다.

• 파일의 데이터를 디스크에다가 연속적으로 배치하지 않고, 빈 위치면 아무데나 들어갈 수 있도록 배치한다.

장점

• 외부 조각 발생안함.

단점

• 직접접근이 안됨

  • 4번째 blcok 가려면 1block => 2block => 3block을 거쳐야함

• block 각각의 경우에 head가 이동해야함. (seek에 의한 시간이 오래걸림)

• Reliability 문제

  • 디스크의 sector들이 bad sector가 간혹남. (중간에 하나 bad sector가 나면 다음 위치는 다 접근 불가능) => pointer가 유실

• Pointer를 위한 공간이 block의 일부가 되는 문제 (디스크에서 하나의 sector는 512byte로 구성되어 있음. 그리고, 또 디스크의 바깥쪽, 컴퓨터에서 디스크에 접근할 때 디스크의 data를 저장하려는 단위가 512byte의 배수로 저장이 된다. 근데, 512byte 배수를 디스크에 저장하라고 하는데, 다음 위치를 가리키는 pointer를 위해서 4byte가 소요된다면, 하나의 데이터를 디스크에 저장하는데 두개 sector 사용되어야 함)

변형

Linked Alloctaion을 약간 변형해서 굉장히 효율적으로 바꾼 파일 시스템 => FAT 파일 시스템 (File-allocation table)

3. Indexed Allocation

Indexed Allocation은 파일의 직접 접근을 가능하게 하기 위해 사용되는 파일 할당 방식입니다. 이 방식에서는 디렉토리에 파일의 위치 정보를 바로 저장하지 않고, 인덱스를 가리키게 합니다.

• 디렉토리 구조: 파일의 위치 정보 대신 인덱스 블록을 가리키도록 되어 있습니다.
• 인덱스 블록 (Index Block): 실제 파일의 데이터를 담고 있는 블록들의 주소를 열거해둔 블록입니다. 인덱스 블록 자체는 실제 데이터를 담고 있지 않지만, 해당 파일이 저장된 블록들의 위치 정보를 가지고 있습니다.

장점)

• 직접접근 가능하다.
• 중간중간 hole 생기는 문제도 해결

단점)

• 아무리 작은 파일이여도 block이 두개가 필요하다.
  • index block 하나, 데이터 저장하는 block 하나. => 파일이 아주 작은 경우에 공간낭비가 있다는 뜻.
• 너무 큰 파일도 index block 하나로 표시할 수 없음.
  • 한 block 크기가 512 byte이고, 포인터가 4byte라고 할 때, 이것도 제한적임.

linked scheme

• 이렇게 큰 파일 같은 경우에는 index block이 여러개가 된다.

multi-level index

• index가 데이터를 바로 가리키는게 아니라, 두번 거쳐서 가리키게 되는 등의 방식
  • 굉장히 큰 파일 표현 가능
  • index를 위한 공간 낭비

+ 지금까지.

디스크에 저장하는 파일의 기본적인 방법 3가지, 이론적으로 이런 할당이 가능하다고 설명. 앞으로는, 실제 파일 시스템에서 어떤 할당 방법을 어떻게 쓰고, 변형해서 쓰는가 알아보자

UNIX 파일시스템의 구조

• UNIX 는 역사가 오래된 운영체제이다.
• 지금 설명할 UNIX 파일 시스템 구조는 가장 기본적인 파일 시스템 구조임.
  • UNIX나 linux의 파일 시스템이 기본적인 파일 시스템에서 => Fast file system => EXT2,EXT3등 굉장히 많은 파일 시스템으로 발전해왔음.
    • 이 과정에서 기본 구조를 효율적으로 저장하고 ,시간을 줄이는 방법이 발전. 하지만 이 수업에서는 기본적인 파일 시스템 구조로 이야기 할 것임.

• 논리적인 디스크에다가 UNIX 파일 시스템을 설치해둔 것임.

UNIX 파일 시스템은 저장되는 구조가 크게 4가지로 구성 1. Boot block

• unit 파일 시스템 뿐만 아니라 모든 파일 시스템이 첫번째로 Boot block이 나온다. : 0번 block에 저장.
  • 올려놓고, Boot block이 시키는대로 하면, 이 전체 파일 시스템에서 운영체제의 커널의 위치가 어디인지를 찾아서 메모리에 올려서 정상적인 부팅이 이뤄지게 됨.
• 부팅에 필요한 정보를 담고 있음 = (bootstrap loader)

2. Super block :

• 파일 시스템의 관한 총체적인 정보를 담고 있다.
  • 어디가 빈 block이고, 어디가 파일이 저장된 사용중인 block인지 관리
  • 어디까지가 Inode list가 있고, 어디부터 실제 Data block이 있는지 총체적 관리

3. Inode list 파일의 메타데이터는 그 파일을 가지고 있는 디렉토리에 가면 있다. 근데, 실제 파일 시스템 구현에서는 디렉토리가 메타데이터를 다 가지고 있진 않다. 특히, unix 파일시스템에서 디렉토리는 지극히 일부만 가지고 있고, 파일의 메타데이터들은 별도의 위치에다가 빼서 보관하고 있다. 그 위치가 Inode list라는 부분이다.

• Inode라는게 index node 인 것임.
• Inode라는 것들이 빨간색으로 표시된 것처럼 하나씩 저장될 수 있는 위치가 있음.
• 빨간색으로 표시된 이 inode 하나가, 파일 하나당 할당 되는 것임.
• 그리고 그 inode는 그 파일의 메타데이터를 가지고 잇는 구조다.
  • 메타데이터: 파일 소유주, 접근권한, 최종 수정된 시각, 위치정보 등
• unix 파일 시스템에서 파일의 meta data를 전부 inode가 갖고 있는 건 아니고, 파일의 이름은 directory가 갖고 있다.
• 디렉토리에 가면, 디렉토리 파일의 메타데이터가 저장.
• 파일의 이름은 디렉토리가 가지고 있고, 나머지 메타데이터는 inode에 저장되어있기 때문에 inode 번호가 저장되어 있는 것임.
  • ex) inode 10번이다 하면 Inode list의 10번 째에 그 파일의 메타데이터가 저장되어 있는 것임.

그러면, 파일의 위치정보는 어떻게 저장하고 있는가?

• UNIX 파일 시스템은 기본적으로 Index Allocation을 변행해서 사용하고 있다.
  • 각 파일당 Inode 크기가 고정되어 있다.
  • 여기서 표시될 수 있는 위치정보를 나타내는 pointer 개수도 유한하다.
  • 그렇지만 가급적 작은 inode를 가지고 굉장히 큰 파일을 표현할 수 있어야 한다.

• unix는 indexed allocation 중에서 4가지로 그 파일의 위치 정보를 구성한다.

파일 크기가 굉장히 작으면 direct index 만 가지고 그 파일의 위치를 표현할 수 있다. 파일 크기가 커지면 indirect 사용

• single indirect
• double indirect
• triple indirect 이게 왜 효율적인가?
• 대부분의 파일은 크기가 작다.
• 작은 파일들은 한번에 pointer 접근으로 파일의 위치를 바로바로 알 수 있다.
• 굉장히 큰 파일들은 indirect block을 이용해서 index를 디스크에서 추가적으로 접근해서 위치를 찾는다. => 굉장히 큰 파일을 이 한정된 크기의 inode로 지원할 수 있다.

FAT File System

• ms사가 ms-dos를 만들었을 때 처음 만든 파일 시스템
• 최근에도 윈도우즈 계열에서도 FAT File-system을 사용하는 경우가 있다.
• 모바일 기기 경우에도 사용하기도 함.

1. Boot block

• 어떤 파일 시스템이든 마찬가지로 부팅과 관련된 정보

2. FAT

• 파일의 메타데이터 중에 일부를 FAT에 보관하고 있다.
  • 지극히 제한적인 위치정보만 FAT에 !

• 나머지 메타데이터는 directory가 가지고 있다.
  • 파일의 이름
  • 접근권한
  • 소유주
  • 파일 사이즈
  • 그 파일의 첫번째 위치가 어딘지
    • 만약 217번 블록이다
    • 그러면, 217번 블록에 그 파일의 첫번째 내용이 있다.
    • 이 상황에서 Linked allocation을 생각해보면, 다음 문제가 있다. 첫번째로는 중간에 베젝스터? 가 나면 다음꺼를 다 찾지 못하고, 두번째로는 약간의 크기가 줄어듬으로써 512byte 를 다 활용할 수 없는 것. => FAT 파일 시스템은 217번 block의 다음 block이 뭔지를 FAT이라는 별도의 테이블에 담고 있다. (Data block이나 directory file에 안담고 있음.)
      • FAT이라는 배열의 크키는 디스크가 관리하는 Data block의 개수만큼 있다. 그 배열에는 숫자를 하나 담을 수 있는데 그 숫자는 그 블록의 다음 블록이 어딘지를 담고 있다.

예시 정리)

• 이 file의 경우에는 첫번째 block이 217번이였다.

• 217번 block은 Data block에 있고,

• 두번째 block은 FAT을 본다.

• 217번 entry를 가면 618이라고 써져있다.

• 그러면 이 파일의 두번째 block은 Data block의 618번에 있구나

• 그다음 파일은 FAT의 618번 entry에 가본다 339라고 써져있음.

• ...

• EOF는 이 파일이 끝났다는 약속의 숫자를 뜻함.

  개념 정리)

  • Linked Allocation을 활용한 것.
  • 하지만, 다음 위치를 찾기위해 block을 접근하는 것이 아님.
  • FAT만 확인해보면, 그 다음 위치를 알 수 있음.
  • FAT 파일 시스템은 직접 접근이 가능하다는 장점이 있다.
    • (linked allocation은 파일의 중간위치를 보려면 디스크 헤드를 이동해서 따라가야지만 가능했던 것과는 대조적이다.)
  • FAT 파일 시스템은 linked allocation의 단점을 모조리 극복한다.
    • random access 가능하고,
    • reliability 해결한다.
      • pointer 하나가 유실되더라도 (bad sector가 나더라도) FAT에 내용이 있기 때문에 이 Data block의 내용하고 FAT의 내용하고는 분리가 되어있음.
    • FAT은 데이터의 위치를 담고 있는 대단히 중요한 정보이다.
      • FAT은 한 copy만 두지 않고, 디스크에 두 copy이상을 두고 있다.
    • 512 byte 공간을 다 사용가능하게 한다.
      • pointer의 역할을 FAT이 하니까.

Free-Space Management

• 그동안, 논리적인 디스크에서 파일에 할당된 데이터들을 어떻게 관리할까? 에 대해서 이야기 했음
• 이제, 비어있는 block들은 어떻게 관리할지 이야기해보자.

비어있는 block 관리하는 방법

• 1. Bit map을 두기(또는 bit vector)
• 2. Linked list로 관리
• 3. Grouping 하는 방법
• 4. Counting 하는 방법

1. Bit map or Bit vector

각각의 block 별로 번호가 있으면, unix 같은 경우에는 Super block에다가 bit를 둬서 첫번째 block이 사용중이냐 , 비어있느냐를 0과 1 로 표시한다.

• bit map의 크기는 data block에 있는 block 개수만큼이다.

• 0 => 비어있는 block

• 1 => 파일에 할당된 block

• 파일 시스템이 어떤 파일이 새로 만들어지거나 , 파일 크기가 커지면 => 비어있는 block 중에 할당

• 파일이 삭제되면 1로 표시되어 있던 bit map을 0으로 바꾼다.

• Bit map은 부가적인 공간을 필요로 한다.

  • 그렇게 많은 공간을 차지하진 않음. block 하나당 1 bit 필요함.

• 연속적인 빈 block을 찾는데 효과적이다.

  • 파일이 여러개의 block으로 구성되니까, 가능하면 연속적인 빈 공간에 할당하면 좋긴 하겠음. 디스크 이동을 최소화해서 많은 양을 한꺼번에 읽어올 수 있기 때문임.

2. Linked list

• 비어있는 block을 연결한다.
• 어처피 비어있기 때문에, pointer로 다음 위치 저장한다.
• bit map에 비해서 추가적인 공간 낭비가 없음.
• 그렇지만 연속적인 빈 공간을 찾기 어려움.
  • 디스크 헤드가 seek 해서 다 찾아야 함.
• 이론적으론 가능하지만, 실제로는 비효율적이라 안씀

3. Grouping 하는 방법

• Indexed Allocation을 활용한 방법임. => Grouping 방법
• 비어있는 block을 한꺼번에 찾기에는 Linked list보단 효과적이지만, 연속적인 빈 block을 찾기에 썩 효과적이지 않음.

4. Counting 하는 방법

• 빈 block을 연속적으로 찾는데 효과적임.
• 빈 block을 가리키기만 하는게 아니라,
• 거기서부터 몇개가 비어있다~ 이런식으로 관리. # of contiguous free blocks
  • 연속적으로 free block이 몇개인지 써있는 것을 찾으면 됨

Directory Implementation

• 디렉토리를 어떻게 구현하는지에 대한 것을 이야기해보자.
• 디렉토리란? 디렉토리 밑에 있는 file의 metadata를 관리하는 특별한 파일.
• 디렉토리 파일의 내용을 어떻게 저장할 것이냐?

  1. Linear list 방식

• file의 이름
• file의 metadata들 순차적 저장
  • : 접근권한, 사이즈, 소유주...
• 크기를 고정시켜서 관리 (몇비트, 몇바이트로 정보를 차지하기)
• 디렉토리에 대한 연산이 주어질 때 (ex. 그 디렉토리 밑에 어떤 file이 있는지 찾아라)
  • 파일 이름에 대한 필드가 어떤 단위로 구성됐는지 알기 때문에 파일 이름을 쭉 찾아보면 된다. => 구현은 간단하지만, 연산에 대해서 시간이 많이 필요함. 비효율적임.

2. Hash Table 방식

• 파일의 이름을 그냥 저장하는게 아니라 hash 함수를 적용한다.
  • hash 함수라는 것은 어떤 input 값을 넣더라도 결과괎이 특정 범위 안의 숫자로 한정된다.
  • F 함수를 적용했을 때 1부터 n 사이의 값이 나오도록 할 수 있다.
  • 파일의 해시 함수 결과값에 해당하는 entry에다가 그 파일의 meta data를 저장한다.
• 파일이 있는지 찾아라 ! 연산할 때,
  • 순차적으로 탐색하는 것이 아니라
  • 그 파일 이름을 해시함수로 적용하고 그 다음에 적용된 결과괎에 해당하는 entry만 확인해보면 된다. => 서로 다른 파일 이름에 대해서 해시함수 결과괎이 같은 entry로 mapping되는 Collision 발생 가능.

File의 metadata 보관위치 정리

디렉토리에다가 파일의 메타데이터를 직접 구현할 수 있지만, 메타데이터를 디렉토리가 전부 가지고 있는 것이 아니라

• 일부는 직접 가지고 있고,
• 일부는 파일 시스템에서 다른 곳에 별도로 저장
  • unix에서는 inode에 대부분의 metadate를 가지고 있었고,
  • Fat 파일 시스템에서는 FAT이라는 곳에 파일의 다음 위치 정보를 가지고 있었음.

Long file name의 지원

긴 파일 이름을 지원하는 방식에 대해 이야기해보자.

VFS and NFS

VFS (Virtual File System)

• 개별 파일 시스템 윗 계층에 VFS를 둔다.
• 사용자가 파일시스템에 접근할 때는 종류와 상관없이 VFS 인터페이스를 사용한다.
• 다양한 파일 시스템이 있지만, 사용자 입장에서는 동일한 API, 동일한 시스템콜을 이용해서 파일 시스템에 접근한다.

NFS (Networdk File System)

• 파일 시스템이 자기 스토리지, 즉, 로컬 스토리지에 저장될 수도 있지만, 원격에 저장되어있는 파일 시스템에 접근할 수도 있음 => NFS 인터페이스를 활용해서 접근해야함.

• 두대의 컴퓨터가 Network로 연결되어 있는 상황

• client가 어떤 파일 시스템이든 상관없이 VFS를 통해서 접근하는데 그 파일 시스템 중에는 자기 로컬 컴퓨터에 있는 파일 시스템에도 접근이 가능하고, 원격의 다른 컴퓨터의 파일 시스템에 접근할 수 있는 인터페이스도 지원이 된다는 뜻. => NFS
• 마찬가지로 로컬 사용자가 원격의 파일 시스템에 접근하려면 VFS interface를 통해서 시스템 콜을 해서 접근하면 됨.
• NFS를 지원하려면 server 쪽에도 , client 쪽에도 NFS 모듈이 있어야 한다. 같은 약속을 가지고 접근을 하는 것임 !

Page Cache and Buffer Cache

Page Cache

page cache는 가상 메모리 관리 챕터에서 이야기 했었음.

• page들을 특히, 물리적인 메모리에 있는 page frame들을 page cache라고 부른다. 왜냐하면 swap area보다 물리적인 메모리 page frame이 빠르다.
• caching 관점에서 이야기해보자면, paging system에서의 page frame들을 page cache라고 부르는 것임.
• 운영체제한테 주어지는 정보가 지극히 제한적이였음.
  • cache hit가 나면, 즉, 이미 메모리에 존재하는 데이터에 대해서는 하드웨어적인 주소 변환만 하기 때문에 정확한 접근 시간을 알 수 없음. clock 알고리즘 사용햇음.

Buffer Cache

파일의 데이터를 사용자가 요청햇을 때, 그걸 디스크에 읽어서 운영체제가 그 내용을 자기 영역 일부에 저장하고, 똑같은 파일 데이터를 또 요청 받으면 디스크까지 안가고 바로 데이터를 주는 것임.

• file system 관점에서 Buffer Cache라고 한다.
• 이미 파일 데이터가 메모리에 올라와 있든, 디스크에 있든 간에 어처피 파일을 접근할 때는 시스템 콜을 해야 하기 때문에 cpu 제어권이 운영체제한테 넘어오고 , 그 파일에 대한 요청이 언제 일어났는지를 cache hit이든 cache miss가 나든. 그 정보를 이용해서 LRU 알고리즘을 사용할 수 있음.

Unified Buffer Cache

• 최근에는 Page Cache하고, Buffer Cache를 합쳐서 같이 관리하는 운영체제가 많다.
  • linux
• 합쳐져 있다는 거가 buffer cache도 page 단위로 관리를 한다는 뜻.
• 운영체제에서 page frame들, 물리적 메모리를 관리하는 루틴에 page cache, buffer cache를 같이 관리한다는 뜻인 것임.

Memory-Mapped I/O

파일 접근하는 방법

• read나 write를 이용한 즉 buffer cache 같은
• memory-mapped 이용
  • 파일을 접근할 때 원래는 파일 접근할 때 그 파일을 open 하고 read systemp call이나 wirte system call로 접근을 했다. 근데 그런 방법을 안쓰고,
  • 파일의 일정 부분을 그 프로세스의 메모리에다가 mapping 해놓고 쓰는 것임.
  • read나 write system call을 하는 것이 아니라 메모리에다가 읽고 쓰는 것처럼.

• 왼쪽그림은 물리적인 메모리다

• 커널 메모리 영역
  • 원래는 buffer cache가 존재했었음.
  • 파일의 내용을 읽어와라 => buffer cache에 먼저 가져오고 => 사용자한테 전달
  • block하나는 보통 512 byte 구성
    • 그런데 최근에는 page cache하고 buffer cache 랑 합쳐졌기 때문에 buffer cache에서도 4kbyte 즉, page 크기로 이 block들을 관리하고 있다. (Unified Buffer Cache 특징)
• 사용자 영역
  • page 단위로 필요한 데이터가 올라가고 내려가고 했엇음.
  • page는 보통 4kbyte 단위

• 빠르게 데이터를 내려놓고, 올려야 되기 때문에 여러개의 block을 모아서 4kbyte 단위로 올려놓거나 내려놓는것이 기본

TCP 및 UDP 구조를 배운다.

지난 시간

1. 어떻게 신뢰도 있는 네트워크를 보장 하는가?

• 패킷 유실 때,
• 패킷 순서 바뀔 때, 복구하는 방법에 대해 알아봄

2. 어떻게 Port와 Socket을 TCP에서 지원을 하는가?
3. 어떻게 내용이 변조됐을 때 탐지하는가?

• 잡음이나 기타 interference 등
  • 이 내용은 어떻게 버리는가?
• 보안 공격 때 x

4. receiver가 더이상 패킷을 받아들일 공간이 없을 때, transmitter가 이를 인지하고 패킷 전송을 중단하는 방법은? => 흐름 제어에 관한 것.

이번 시간

이제 혼잡 제어에 대해 알아보자.

혼잡제어란? : 네트워크가 혼잡한 상황에서 tcp가 이를 인지하고 제어하는 것. (전체 사회를 돕는 느낌)

tcp를 언제 사용하는가?

• 파일 교환
  • 커다란 동영상 파일을 주고 받을 때, 최대한 많은 대역폭, 즉, 네트워크에서 제공하는 자원을 많이 사용할수록 데이터를 더 빨리 받는다.

• 병목 현상 더 가중됨
• 네트워크에 많은 부하가 걸렸을 때, 송신측에서 송신량을 조절해서 부하를 제어 해야 함. => 컴퓨터에서는 혼잡을 제어할 수 있는 프로토콜을 설계해야함.

이 혼잡상황을 tcp에서 제어하는 것에 대해 말해보자 !!

혼잡 제어

1.혼잡 인지

전체 맥락

패킷 유실이 발생하면 => 혼잡 상황이라고 인지. => 패킷 전송률을 낮춘다.

(처음에는 패킷 전송률을 나누기 2로 낮춘다.)

패킷 전송 원활(유실 x) => 비혼잡 상황이라고 판단. => 패킷 전송률을 증가시킨다.

(현재 전송률 + C(상수))

Additive Increase Multiplicative Decrease => AIMD : 증가시킬 때는 선형적으로, 줄일 때는 기하급수적으로

패킷 유실

• 패킷유실이란 ACK 신호가 Timeout 내에 오지 않는 것.
  • Timeout은 너무 길거나 너무 짧아서는 안된다.
    • 너무 길 때: 재송신 지원 많아짐
    • 너무 짧을 때: false alarm (정상적으로 패킷이 갔는데도 유실로 판단)

Timeout 어떻게 설정하나?

• 패킷 유실을 판단하는 Timeout은 즉, 재전송을 결정하는 것임. => Retransmission Timeout (RTO) RTO를 판단하려면 기본적으로 네트워크 지연시간이 어떤 분포를 따르는지 알아야 한다. EX) 미국과 통신할 땐, 장거리에 많은 장비를 거침
  • 기본적으로 지연시간 김
  • 이럴 땐 timeout이 너무 짧으면 패킷 대부분이 걸림 EX) 가까운 곳과 통신할 땐 금방 됨.
  • 가까운 거리일 땐 Timeout이 너무 길면 패킷 유실 때도 한참 기다림

실제로 내가 패킷을 보내고, ACK 받을 때까지 시간이 얼마나 걸리는지 샘플링해서 통계적으로 접근한다.

• RTT를 계속 측정하다보면 분포가 생긴다. => Retransmission Timeout 기준을 잡으면 ACK이 그 안에는 들어오겠다 ~

그런데 chatgpt는 RTO를 Recovery Time Objective라고 표현함.

• RTO = RT 평균값 + 4 * DevRT(RT 표준편차)
• 대신 1초보다 짧음

RT이 여러가지 값을 가지게 되는 이유 분석

• 네트워크 장비의 전송지연이 많은 부분을 차지함.

• 각각의 장비에서 걸리는 큐잉 시간은 임의의 분포를 따른다

  • ex) 포아송 분포, uniform한 분포, 아주 임의의 분포가 될 수 있다.
  • 각 네트워크 장비는 이런 다양한 분포를 따를 수 있으며, 목적지까지 도달하는 데 여러 장비를 거쳐야 한다.
  • 각각의 장비가 어떤 분포를 따르든, 여러 장비의 지연 시간을 합산한 값의 분포는 통계적으로 정규 분포(Normal Distribution), 즉 표준 분포를 따르는 경향이 있습니다.

  

• RTT(라운드 트립 타임)의 평균에 표준편차의 4배를 더한 값 (빨간선) 보다 큰 RTT가 나올 확률이 0.9999보다 작다. : RTT 값이 평균 + 표준편차의 4배를 넘지 않을 확률이 매우 높다는 것을 의미합니다. 즉, RTT가 평균보다 훨씬 더 큰 값이 나올 가능성은 극히 적다는 것 => 99.99 퍼센트 패킷들이 RTO 안에 통과를 한다는 뜻.

RTO = max(RTT 평균 + RTT 표준편차 * 4, 1초)

이것보다 더 크게 만들면 너무 긴 재전송 지연 문제가 생김.

그러면 문제는 아래 두개 값을 어떻게 구할 것인가?

• 평균과
• 표준편차를!

RTT 을 구하는 평균값을 구하는 공식은 일반적인 평균값을 구하는 공식과는 다르다.

• 네트워크 상황 변화에 더 빠르게 반응하도록 최근 측저값을 가중치를 더 둔다. (가중 이동 평균)
• 가중 이동 평균은 방식 (Weighted Moving Average,WMA)

  RTT 평균값 구하기

• 가중 이동 평균은 방식 (Weighted Moving Average,WMA) 을 사용함. : 굉장히 중요한 기법임. 프로그래밍 코딩할 때 평균을 구할 때 효과적이고, 값의 의미도 좋음 !

RTTn : Round trip Time의 n번째 측정값
RTT_n : n번째 sample 후 판단한 RTT 평균

(N=1)  RTT_1 = RTT_1 (RTT1까지의 평균은 RTT1 그차제가 됨.)

(N>1)  RTT_n = (1-α) * RTT_(N-1) + α * RTT_N

• TCP에서의 알파값은 0.125다. (1/8 정도임)

정리

혼잡인지를 하기 위한 것은 => 패킷 유실이 되었는지 판단해야 하고, => Retransmission Timeout (RTO) 을 결정할 때, => Round Trip Time (RTT)을 이용한다. => RTT의 평균값을 이용할 때 Weighted Moving Average 기법을 사용한다.

혼잡제어

본격적으로 어떻게 혼잡제어를 하는지 이야기해보자 ~

• AIMD : Additive Increase Multiplicative Decrease

  Additive Increase

  잘 전송이 됐을 때 어떻게 패킷을 한개씩 전송하는지 ?

• 단위 (Increase의 단위) : MSS (Maximum Segment Size)

  • 실제로 두개의 노드가 TCP 커넥션을 맺은 다음에 협의에 의해서 결정하는 단위임

  • 결정하는 기준은 중간 네트워크 장비들이 packet size를 어느것으로 쓰느냐에 따라서 결정한다.

    • 중간에 인터넷 장비 등이 경로를 하나 만든다음에 경로에 segment size를 proving 하는 프로토콜이 있음 . 그러면 중간에 packet size 설정을 알 수 있음. segment size가 중간에 네트워크 장비들이 쓰는 packet size보다 큰걸 사용하면 프로토콜이 복잡해짐. segment size는 사실 얼마가 되든 상관없어. tcp 통신 단위가 기본적으로 byte이기 때문에 사실 상관은 없으나, 효율의 문제가 있는 것임. 크게 정할 수록 좋지만 중간의 장비가 segment size 를 처리하지 못하면 segment size를 다시 쪼개야 함. 한번 정해진 segment size로 통신하면 중간의 장비가 쪼개지 않는 것이 제일 효율적임.

  • 보통 1KB ~ 4KB : 이 Maximum Segment Size를 정하게 되면은 tcp 패킷을 보낼 때 이 MSS보다 크게 보내지 않는다. 만약 더 큰 내용을 application이 보내달라 하더라도 이 MMS 사이즈로 잘라서 통신한다.

  • 네트워크 장비들

• 성공하면, window size를 1MSS 만큼 증가시킨다.
• congestion window size가 1 증가됨
• 1mss 보내고 ack이 안와도 또 1mss를 보낸다.

• 2MSS => 3MSS 로 증가

• 3MSS로 증가함
• 아직 ACK 하나 안온게 있으니까 2개 Packet 보낼 여력이 있는 것임

• 하나 ACK 받자마자 1개 Packet을 보낸다. 결론) RTT가 하나씩 성공할 때마다 동시에 보낼 수 있는 Segment size가 1MSS씩 증가한다.

Congestion window를 증가시키는 판단을 하는 것은, congestion window를 증가시키자마자 바로 다음에 보내는 패킷이 돌아올 때 다음 congestion window를 판단한다. 한번의 RTT이 지나갈 때마다 판단을 하는 것이기 때문에, 그 사이사이 보내는 추가적으로 보내는 패킷의 ACK은 Additive Increase에 영향을 주진 않는다.

Multiplicative Decrease

• 패킷유실시 congestion window 크기를 절반으로 줄인다.
• 패킷 유실이 네트워크 이상을 반영할 때는 CW(congestion window)를 1MSS로 대폭 줄인다.

패킷이 단순히 유실된 case vs 네트워크가 이상해서 유실된 case

• 네트워크 이상시: 모든 전송 세그먼트가 동시 유실
  • 모든 ACK이 도착하지 않는다. => RTO가 Trigger된다는 뜻.
• 단순 패킷 유실시: 유실된 네트워크 이후에 보낸 다른 세크먼트의 ACK이 도착

네트워크 이상시

위급 상황이니 1MSS로 단번에 줄인다.

단순 패킷 유실시

• 빠른 재전송이라고 함. 원래는 timeout 이 발생해야 재전송 했는데, 동일한 ACK이 여러개 오면 해당 SQ 세그먼트가 사라졌다는 것을 알 수 있기 때문에 빨리 재전송 해버림

• Fast Recovery: 반으로만 줄이기 때문에 훨씬 복구가 빨리된다.

Slow Start

네트워크 이상시 CW => 1이 된다. 문제: CW의 증가가 너무 느리다.

• 실제로 문제가 생겼던 장비가 다시 좋아질 수도, 더 좋은 경로를 찾을 수 있는데, CW =1로 두고, Additive Increase를 하면 너무 속도가 느리다.

만약 기존 CW = 100인 경우였다면? => Round Trip을 100번해야 cw가 100이 됨 ;; => CW 가 50이 될 때까지는 Muliplicative Increase를 하자.

• 전송할 때마다 하나씩 cw를 증가시킨다. (원래는 한번의 round trip 때 cw를 증가시킨 것과는 대조됨) => 이 결과는 결국 한번의 round trip 때마다 cw가 2배로 증가되게 한다. 사실상 Multiplicative Increase 하는 것임.

TCP 및 UDP 구조를 배운다.

검증 방법2가지

• 신뢰성 보장하기 위해 한단계, 한단계 패킷을 보낼 때마다 검증
• 처음부터 끝까지 보낸 다음에 검증 (END TO END) => 전송계층은 end to end 프로토콜임.
  • 중간단계 네트워크 장비들에 간섭하지 않음
  • 양 끝단 장비에만 설치 및 검증 함.
    • tcp 계층은 양 끝단에서 검증함.
• 전송계층에서 이야기하는 모든 서비스는 양 끝단에 해당하는 서비스임.

신뢰성

1. TCP

• 내용 유실이 없다.
• 내용상의 이빠짐이 없다.
  • 패킷을 보내는 도중에 네트워크 끊김(와이파이 없는 곳으로 이동)으로 인해 패킷이 끊긴다면 1,2,3,4번,...7번 패킷까지 가고, 5,6,번 패킷아 안가는 등의 경우는 없단 뜻.

2. UDP
   • 내용 유실이 있다.

속도

1. TCP

• 고의적인 지연이 존재할 수 있다.
  • 왜 ? : 경우에 따라서 필요함.
    • 1,2,3,4 패킷까지 받고, 6번 패킷 받아도, 6번 패킷을 applictation 에 안알려줌. (순차적으로 패킷을 보내는게 중요하기 때문임)

2. UDP

• 고의적인 지연이 없다.
  • 보내달라하면 무조건 즉각적으로 보내고, 받는 단에서 받자마자 application 한테 보냄
  • 네트워크 불안, 네트워크 패킷을 멀리 보내야 하는 지연은 있을 수 있음.

혼잡제어

1. TCP

• 네트워크 혼잡이 심하면, 모든 사람이 서비스 못 받는 상황이 생길 수 있음. => 패킷을 보낼 수 있음에도 참음.
• 네트워크는 혼잡이 많아지면, 각 장비에 패킷이 쌓이되면, 버려지는 패킷이 생김 => 신뢰성 하락 => 네트워크 더 복잡해짐. => 방지하기 위해 혼잡제어

2. UDP

• 네트워크 혼잡해도 보냄.

전송단위

1. TCP

• 내용 유실 자체가 아예 없음. => 내가 보낸 패킷의 단위를 그대로 기억할 필요가 없음.
• byte를 전송단위로함.
• 굳이 내가 몇번 send를 호출해서 이 데이터를 어느 단위로 끊어서 보냈는지 기억하지 않는다.

2. UDP

• 내용이 너무 잘게 쪼개진 단위로 패킷이 유실되면 골치아파짐. 내용이 유실 될 수 있지만, 의미적 단위로만 유실 할 수 있게 한다.
• 패킷을 보낸다고 할 때, send라는 함수를 통해 하나의 데이터 덩어리를 보내게 됨.

• tcp는 byte 단위로 전송하기 때문에, send(), recv() 단위상의 일치 관계가 성립하지 않는다.
• udp에서는 send 함수에서 보낸 데이터 내용 자체가 recv()에 받는 데이터가 대응관계다.

• 실제로 A가 데이터를 던졌는데 B가 못받을 수 있음 (패킷 유실)
• 순서 보장 X
• 빨리 보내줌
• 단위는 공으로 뭉쳐서 보내기 때문에, 그 통신의 단위는 데이터 그램이다.

TCP의 구현

• 1. Reliable Network
  • 패킷 유실 x , 순서 보장
• 2. 내용 변조 탐지 기능
  • 패킷이 중간에 잡음등 때문에 (보안 공격을 탐지하는 건 아님)
• 3. 혼잡제어
  • 네트워크 혼잡이 심한 것 같으면, 보내지 않고 기다렸다가 보냄
• 4. 흐름제어
  • 패킷을 수신하는 쪽에도 buffer가 있는데, 꽉차서 넘치는 상황이 생길 수 있는데, 수신하는 쪽에 있는 응용이 지금까지 받은 내용 줘봐봐. recv 함수를 통해서 요청을 운영체제한테 할 수 있는데 요청을 아예 안하게 되면 위에있는 운영체제에서 지금까지 받은 패킷을 계속 잡고 있을 수밖에 없어. 창고에 쌓아두는데 위에 응용계층에서 달라고 안하면, 창고가 꽉차면 송신측에서 보내는 내용을 쌓을 수 없는 경지에 이르게 된다. 그렇게 되면 수신측에서 더이상 보내지 말라고 이야기한다.

UDP의 구현

• 패킷 보내라 하면, 보내고, 달라하면 위로 주고
• 하는게 거의 없음. 속도가 빠른 프로토콜임

TCP 패킷 구성

1. 응용계층에서 HTML 문서를 보내면,
2. 세션계층 즉, HTTP가 받는다.

• HTML에다가 세션계층 header를 붙인다. (문자열 형태 header)
  • http req, get (http 1.1 ok) => 결과적으로, body로는 HTML 문서, header로서 http 헤더를 붙인다.

3. 전송계층에 전송

1. 전송계층에서는 응용계층에서 받은 문서가 payload가 된다.

• 최종적인 내용은 html이지만, http header까지 붙인게 내용으로 취급

2. 받은 내용에다가 tcp header를 추가한다.

1. 네트워크 계층에서는 ip 헤더를 붙인다.

• 목적지까지 보내려면 주소를 써야겠지.

1. 링크 layer는 와이파이, LTE, 이더넷 등이 된다.
2. 이더넷 헤더를 붙인다.
3. 물리계층으로 보낸다.

물리계층은 헤더를 붙이는 것이 아니라, 내용을 전기적 신호로 바꾼다. 수신측에서 다시, 데이터 형태로 바꾼다.
마지막으로 수신측에서 각 계층에서 각각에 해당하는 header를 해체시키고, 위 계층으로 올려보낸다.

• 헤더에는 그 계층에서 필요로 하는 데이터들이 들어가있다.

그 헤더에 어떤 내용이 들어가는지 공부해보자.

TCP 헤더 구성

• tcp 헤더는 convention이 있다. http 헤더와는 다르게 문자열이 아닌 binary 형태

  • 커널 계층에서 빨리 처리해야 되기 때문임.

• 각각의 몇번째 바이트는 어떤 의미다 라는것이 고정

• 32bit로 구성

• 각각 16bit 씩

• tcp의 주요 기능으로 포트(사서함) 기능을 지원한다.

  • port 번호는 응용 프로그램을 구분한다.
  • ip 번호는 각 기계를 구분한다.

• socket : 응용 안에서 port를 구분하는 개념으로 사용하는 것

Socket vs Port

• socket 여러개가 하나의 port에 연결될 수 있다.
• socket과 port는 네트워크 통신에서 중요한 역할을 한다. 개념은 서로 다르지만, 함께 작동하여 client와 server간의 데이터 교환을 가능하게 한다.

  socket

• 소켓은 네트워크 통신의 종착점을 나타내는 추상화된 개념이다.
• 소켓은 ip 주소와 port 번호로 구성된다.
• 소켓은 네트워크 상에서 데이터를 송수신하는데 사용되며, 프로그램 통신을 가능하게 한다.
• 예를 들어, client sw(브라우저 등)가 특정 서버에 연결할 때 소켓을 사용한다.

port

• 포트는 ip 주소에서 특정 프로세스를 식별하는 역할을 한다.
• 네트워크 통신에서 한 컴퓨터에서 실행되는 여러 프로그램 간의 데이터를 구분하는데 사용된다.
• 포트번호는 0번부터 65535 까지의 범위를 가지며, 특정 서비스와 연관되어 있다.
  • http는 포트 80, https 443

관계

• 소켓은 ip주소와 포트 번호의 조합이다.
  • ex) 192.168.11:80 이라는 소켓은 ip주소와 포트번호로 구성된다.
• 여러 소켓이 동일한 포트 번호를 사용할 수 있다. => 여러 클라이언트가 동일한 서버의 동일한 서비스에 연결할 수 있음을 의미한다.

예시 : 클라이언트와 웹 서버

• 클라이언트: 클라이언트는 소켓을 사용하여 서버에 연결한다. 예를 들어, 웹 브라우저가 웹 서버에 연결할 때 클라이언트 소켓을 사용한다.
• 웹 서버:웹 서버는 특정 포트에서 수신 대기한다. 일반적으로 http는 포트 80을, https는 포트 443을 사용한다.

통신과정

1. 클라이언트 소켓 생성: 클라이언트가 서버에 연결하기 위해 소켓을 생성한다. 2. 서버 포트에 연결: 클라이언트 소켓은 서버의 ip 주소와 지정된 포트 번호에 연결 요청을 보낸다. 3. 연결 수락: 서버는 포트 번호를 통해 연결 요청을 수락하고, 클라이언트와의 통신을 시작한다.

포트- 소켓 관계 예제

• 네이버 web server 응용 프로그램이다.

  • 가장 먼저 하는 것은 80 번 포트로 server socket을 연다.
    • server socket으로 제일 먼저 하는 것은 listen() (누가 접근하는지)

• 기계가 두개가 있다.

  • 그 기계 안에는 web client 프로그램이 떠있다. (사파리, 크롬)

• 사파리에서 web server로 먼저 접근을 한다. => web server 소켓에서 accept

• 사파리와 web server를 연결해주는 소켓이 web server 안에 생성 => 사파리에서도 역시 소켓 하나 연다. port 하나를 열게 되는데, client 포트번호는 지정을 안한다. 12345 포트 번호로 운영체제가 임의로 할당 => 이것이 80번 port와 연결되게 된다.

  • 예를 들어)
    • 기계1 ip가 3.4.5.6이고, 네이버의 ip가 1.2.3.4 일 때의 경우를 살펴보면, 3.4.5.6 에 있는 12345 포트에서 1.2.3.4 기계의 80번 포트랑 연결된다. 그것이 하나의 소켓을 열게 되는 것이다.

정리)

상황) 똑같은 기기의 크롬을 통해서 네이버 웹서버에 접속한다고 하자.

• 1. 크롬을 위한 포트 설정
  • 23456번 포트 client 프로그램의 경우는 일반적으로 하나의 포트가 하나의 소켓에 mapping이 된다.
• 2. 23456 포트가 => 80번 포트에 접근 하면
• 3. 80번 포트가 listen을 한다.
• 4. chrome을 담당하는 소켓이 네이버 웹 server에 추가적으로 하나 생김
  • 이 소켓 객체가 이 크롬을 담당한다.

정리) 사파리와 크롬 두개의 client는 동일한 서버의 동일한 80번 포트에 접근한다. 하지만 실제로 응용 프로그램 안에 있는 소켓 객체는 서로 다르다.

• 포트 하나를 가지고 3개의 소켓이 나눠서 쓰고 있다.
• 웹 서버 안에서는 각각의 client를 구분할 방법이 필요해짐. => TCP 헤더 안에 있는 src port 번호, dest port 번호로 구분함 => TCP 헤더를 감싸고 있는 IP 헤더 (src IP 번호, des IP 번호)로 구분함 => 4가지를 페어로 해서 각각 어느 소켓에 해당하는 패킷인지 판단하는 기준 근거로 삼는다.
  • 동일한 포트로 들어오는 연결이라 할지라도 각각의 소켓으로 넘겨줄 수 있다.

예시1) 사파리에서 web server로 접근하는 (data packet), http request packet이 있다고 치자.

TCP 헤더의 2번째, 3번째 줄의 32 bit에 대해 알아보자

• Seq 넘버

• Ack 넘버

• reliable 네트워크과 관련있음

  • 어떻게 TCP로 신뢰성 있는 통신을 제공할 것인가?

우리가 지난 시간에 배운 것.

• 실제로 보내는 packet과 ack packet은 구별되는 packet이다. 그런데 tcp에서는,
• seq number와 ack number가 같은 packet에 적히게 된다.

우리가 지금까지 배운것.

• seq number와 ack number는 packet의 번호였음. 하지만 tcp 헤더에서는,
• 몇번째 byte 번호인가에 해당하는 번호다.
  • 100 byte를 보내면, seq number가 100 증가됨
  • packet마다 번호 x, byte마다 번호 o

• 나는 42번 문자 부터 보내고 있다.
• 나는 77번 byte 받을 차례다 ex) H=> 42번 문자, e=> 43번 문자, l => 44번 문자, l=> 45번 문자, o=> 46번 문자

답변 ex) h => 77번 문자, i => 78번 문자

• 나는 77번 byte부터 보내고 있다.

• 나는 47번 byte 받을 차례다.

• tcp에서의 내용 송수신 단위는 byte다.

• tcp에서는 보내는 단위는 segment라고 한다.

• packet은 그 자체로서 의미있는 내용의 단위 vs segment는 조각임.

• 만약 여기에 대해서 A가 별 할말이 없었다? => 그냥 ACK만 보내면됨.
• TCP 안에는 아무 내용이 없는 문자열 패킷도 보낼 수 있음.

• 네트워크 통신양을 아끼기 위해서 0.5초 기다리게 된다.
• 혹시나 응용이 응답을 만들어내면, 첨부해서 답장을 하고,
• 0.5 초가 지나도 응용이 아무런 이야기도 하지 않으면, 아무 내용도 담지 않은 내용을 보내면 된다.

*TCP가 *

• Go-back-N 기법을 사용하게 될지
• Selective-repeat을 사용하게 될지 고민할 필요가 있다. 답: Go-back-N기법에 기반한다. 이유)
• 1. Selective Repeat
  • 수신자가 현재 몇 번째 패킷을 받았는지 알려야 한다.
  • 수신자는 각 패킷의 상태를 개별적으로 관리하고, 손실된 패킷만 재전송 요청한다.
  • 이는 수신자가 많은 상태 정보를 유지해야 하고, 더 복잡한 구현을 요구한다.
• 2. 그러나 TCP는,
  • TCP는 수신자가 현재 몇 번째 패킷을 받을 차례인지 ACK 번호만 알려준다.
  • 구체적으로 몇 번째 패킷을 받았고, 못받았는지를 상세히 이야기하지 않는다.
  • 수신자는 연속된 패킷만 ACK를 통해 확인하고, 중간에 손실된 패킷이 있으면 그 이후의 모든 패킷을 다시 요청한다

결론: TCP는 연속적인 패킷의 ACK만을 전달하는 Go-back-N기법에 기반한다. 따라서 TCP는 수신자가 현재 받을 차례인 패킷의 번호만을 알려주는 방식으로 동작한다.

TCP 의 네번째 32bit는 어떤 내용일까?

1. tcp 헤더 길이 정보

• tcp 헤더의 길이는 고정되어 있지 않다.
• 뒤에 optional한 정보를 채울 수도 있고, 안채울 수도 있는 가변적 특성

2. flag 정보

• 이것이 혹시 전체 tcp connection을 맺고 끊는 제어 패킷이냐 아니냐 의 정보
  • hand shaking 이런 제어 패킷이 주고 받아지면, tcp 연결이 맺고, 끊겨짐.
  • 이것이 맺으려고 하는지, 끊으려고 하는지 정보가 필요하니 그 bit들을 세팅하냐 안하냐 할 수 있음.

3. Receive Window

• 수신 가능한 Buffer 크기
• buffer 크기가 크면, 나한테 마음껏 보내라는 뜻.
• buffer가 0이면, 송신 쪽에다가 받을 수 없다고 이야기 하는 것.

• 송신측 응용계층에서 send()실행하면,

• 송신측 전송계층에서 데이터를 수신측에 보낸다.

• 수신측 전송계층에서 해당 데이터를 buffer에 저장했다가.

• 수신측 응용계층에서 receive()를 실행하면,

• 그때 데이터를 응용계층으로 올려보낸다.

• 수신측 응용계층에서 receive 함수를 실행하지 않았는데, 전송계층에서 올려보내지 않는다.

  • 대부분 운영체제에서 지원하지 않아.

• 그런 과정에서, 송신측은 계속 데이터를 보내고, 수신측은 buffer에 데이터를 계속 쌓는다.

• 그러다가, buffer가 꽉 차면 이제 패킷을 버리게 된다. => 네트워크 낭비

• 이를 막기 위한 필드가 Receive Window임. [흐름제어 관련 내용임]

  • Receive Window가 자꾸 줄어들면 송신측에서는 이 window가 넘치지 않을 정도만 수신측에 패킷을 보낸다.
  • => 더이상 보내지 않을 때 송신측에 buffer를 두고 거기다가 패킷을 저장하고 있는다
  • => 그 buffer도 꽉찼는데, 응용계층이 전송계층한테 또 보내!! 라고 하면?
  • => 전송계층이 응용계층에게 error로 응답

checksum

• 내용 변조 탐지를 위해 존재하는 tcp 전송계층에 있는 기법임.
• tcp에도 있고, udp에도 있음
  • udp가 내용이 유실될 수도 있고, 순서도 바뀔 수 있지만, 내용 변조되는건 막아줌.

• 만약 밑에 payload 까지 있으면, 하나의 segment가 완성되는 것.

• tcp segment를 16 bit로 만들어보자
• 그리고, 이진수로 표현해보자.
• checksum 더하기를 하는 것.
  • checksum 더하기란?

checksum 더하기란?

• 이진수 더하기

일반 이진수 더하기

checksum 더하기

• 여기선 두개의 답이 동일하다.
• 올림이 없기 때문임. (캐리(carry)는 이진수 덧셈에서 자리 올림을 의미)

올림이 있는 경우를 보자.

일반 이진수 더하기

checksum 더하기

• 캐리가 생길 경우 캐리를 한번 더 더하는 것이다
• checksum 더하기를 하면 무조건 4자리 수가 나올 수밖에 없음.

다시, checksum 으로 돌아가서 ,,,

checksum

• checksum이 하는 역할
  • segment의 이진수 전체 모든 값을 더했을 때, 최종 값이 1111111111111111이 되도록 조작을 하는 것임.
  • 예를 들어, checksum 을 제외한 모든 값을 checksum 더하기 했을 때 값이 1100101110000110이라면 그 값의 반전 시킨 것이 checksum이 된다. 그 둘을 더하면 1111111111111111이 되니까 !!!! checksum은 0011010001111001 이 된다.
  • 만약, 중간에 데이터가 변조된다면 마지막 결과값이 1111111111111111 이게 깨진다. => 중간에 0이 섞이면, 이 데이터를 버린다.
  • 물론, 내용 변조가 고의적인 보안 공격이면, 실제로 checksum 까지 바꿔버리니까, checksum이 고의적인 내용 변조까지는 못 알아냄.
  • 노이즈나 잡음에 의한 변조는 알아낼 수 있음. => 그럴 때는 digital signature 전자 서명 방법을 써야함.

• ERD 다이어그램 (Entity Relationship Diagram)

목차

개요

DB 설계를 위한 고수준의 개념적 데이터 모델 사용

• DB 구축의 결과 => DB 스키마

데이터베이스 응용 예제

• DB 요구사항 분석

개념적 설계의 결과 - ERD

• ER 다이어그램은 Visual Language이다.
  • visual한 도구를 사용해서 db 구조를 표현

개체, 개체 타입, 애트리뷰트, 키

• Entity : 개체
  • 회사, 직원, 부서
• Attribute: 속성
  • 이름, 주소, 나이, 휴대폰 번호

동일한 속성을 가지고 있는 개체들이 여러개 모이면, => 개체 집합, 개체 type

• key : 개체 하나를 구분할 수 있는 속성
  • 직원의 사원번호 , 주민등록번호

• 복합 속성: 주소와 같음
• 단순 속성: 나눌 수 없는 속성 (Number)
• 단일 값 속성: 어떤 직원의 Address가 하나만 있을 때
• 다치 속성: 어떤 직원의 주소가 여러군데 있을 때
• 유도된 속성: age는 birthdate만 있으면 값을 낼 수 있다.
• 저장된 속성: birthdate

• 개체 속성에 널 값을 가질 수 있다.
• 널은 값이 없다. 값을 모른다는 뜻 두개다 의미.
• 복합 속성은 중첩 괄호를 사용해서 표현할 수도 있다.
  • 앞에서 그래프로 표현한 것을 괄호로 표현한 것임.

• 개체 타입은 동일한 속성을 갖는 개체들의 집합이다.
• EMPLOYEE가 모여있으면 EMPLOYEE 개체 집합
• COMPANY가 모여있으면 COMPANY 개체 집합

• 차도 개체집합이다

• Key 속성: 각 개체마다 서로 다른 값을 가지는 속성
• 도메인(값 집합): age 속성의 도메인은 (16살 ~ 70살)로 범위 제한

관계, 관계 타입, 구조적 제약조건

개체들 사이 관계에 대해 이야기해보자.

• 관계는 개체와 개체 사이의 관계를 말함.

• r1은 e1이 d1에 다니고 있다는 관계를 나타냄.
• 이런 관계들을 다 모으면 관계 타입 (관게 집합) 이라고 함.
• n:1 관계

• 3진 관계도 있다.
• 공급자, 부품, 프로젝트
• 관계: 공급자가 어떤 프로젝트에 어떤 부품을 공급한다.
• ex) r1은, s1이라는 공급자가 p1이라는 부품을 j1이라는 프로젝트에 공급한다.

• 어떤 employee가 어떤 부서를 관리하다는 관계임/

• ex) r1은, e2가 d1의 매니저임을 나타낸다.

• 1:1 관계라고 할 수 있음.

• r1은, e1이 p1 프로젝트에 참여한다고 말할 수 있음.

• m:n 관계

이런 관계를 ER 모델에서 어떻게 표현할 것이냐? 이런 것도 중요한 과제다. 고것에 대해 살펴보자 ~

• 동일한 3개의 Entity 타입에 대해서 하나의 삼진관계로 모델링할 수 있고, 2개의 이진관계로 모델링할 수도 있다.

• 다이아몬드 하나가, 두개의 entity type 을 연결하고 있으면 => 2진관계

• 다이아몬드 하나가, 세개의 entity type 을 연결하고 있으면 => 3진관계

• 2진관계는 몇대 몇이냐는 것을 적을 수 있다.

  • 한 공급자가 하나의 part만을 공급한다. 1대 1이냐, 1대 n이냐, n:m이냐 관계에 대해서 고민

• 3진관계는 이 3entity type이 서로 관련이 있을 때, 즉, 어떤 공급자가 어떤 부품을 어떤 프로젝트에 공급할 때 ! , 그때 이 관련성 정보가 3가지 entity를 전부 엮어주는 역할을 한다.

• 3진관계가 2진관계보다 더 엄격하다.

  • ex)

전송게층 신뢰성 확보 방법론을 배운다.

어떻게 end-to-end, 두 단말간의 통신에서 신뢰성 있는 커뮤니케이션을 할지가 주된 내용이다. 그 이후에는, 어떻게 전체 네트워크 자체가 과부하 걸리지 않게 하는지를 배울 것.

Reliable Networking (EndtoEnd)

• 이상적인 네트워크
• 두 단말기 사이에 파이프가 존재해서 bit, byte의 흐름을 모두 보낼 때, 견고하게 순서대로 다 전달 되는 네트워크

• 현실적인 네트워크
• 두 단말기의 네트워크는 구름 모양,,,
  • 문제)
    • 1. 무한한 흐름 x (bit가 끊임 없이 보내야되는데, 한번에 보낼 수 있는 전송양이 패킷이라는 크기로 정해져 있음. (비트를 쪼개서 패킷으로 전송하기 때문임))
    • 2. 패킷유실
    • 3. 패킷의 순서가 바뀔 수 있음.
    • 4. 패킷 변조
  • 해결) 여러가지 통신 기법을 도입한다.

무한한 흐름 지원 => 데이터 패킷화 패킷 유실 확인하기 위해=> ACK 기법 도입

timeout이 지나도 ACK이 오지 않는 3가지 CASE

• A => B 중 패킷 유실
• B => A 중 패킷 유실
• 패킷이 제대로 도착했으나 , timeout이라서 => 이 3가지 경우를 고려해서 어떻게 ACK을 보내고, 어떻게 packet을 보낼지 결정을 해야한다.

이 경우에, 문자열을 받는 단말기에서 의문이 생김.

• ABCD 받았던거 또 보낸건가?
• ABCD 이후에 ABCD가 또 오는 건가? => 그러니, 이것을 분별하기 위해 추가 조치가 필요함

• 전송하는 단말기에서 몇 번 패킷인지 써줘야 한다.
• 전달받는 단말기에서 몇번째 ACK인지 보내야 한다.

문제) 무한히 큰 자연수를 패킷 번호로 설정하기 어려움

• 몇 bit, 몇 byte를 Sequence Number에 할당을 해야하나? => 패킷의 순서가 바뀌지 않으면 1bit로도 충분하다. ex)0번째, 1번째, 0번째, 1번째

=> 패킷의 순서가 바뀐다면?

• sequence number가 0번 ~21억 번이 되든 충분하지가 않아진다. => ACK이 한참 늦게 도착하는 경우가 있기 때문이다.

  

이것은 성능이 좋지 않다. 이유)

• 전송률 이 정말 높다.
• 지연시간

web server 할 때 배운 pipeline 기법을 활용해서 성능을 향상시킨다.

Pipelining

Reliable Networking의 성능향상 기법인 pipielining에 대해 알아보자 ~

정의

• 연속된 대량의 작업이 순차성은 갖고 있으나, 앞의 일이 종료하지 않고도, 다음 일을 시작할 수 있는 병렬성을 가진 경우 성능 향상 기법이다.
• 병렬성 x
• 병렬성 o

reliable network를 전송계층에서 구현하기 위해 pipeline을 어떻게 이용하는가?

• application이 pipeline 이용하기 유리함
  • 1번 패킷 보내고, 2번 패킷 보내는 것이 사실 독립적인 사건임.

• 패킷이 순차성을 가짐
• 각각의 작업이 독립성을 가지고 있음
  • 순차적으로 패킷을 보내고 ACK이 안오면 골라서 다시 보낸다.

이처럼, 파이프라인 아이디어는 간단한데 구현하는데 서로다른 2가지 방법이 있음

구현방법 1. Go-back-N

N개의 패킷에 대해서 파이프라인 하는 방법

• 최대 N개의 packet을 병렬적으로 처리
  • 송신측에서는 N개의 packet을 buffering (재전송하기 위함)
  • 수신측에서는 순차적으로 잘 수신된 packet에 대하여 ACK을 송신하고 packet의 payload를 응용계층으로 올려 보낸다.
  • 송신측에서는 buffer에 여유가 생기면 (1번 패킷의 ACK을 받으면 1번 패킷을 버리니까 여유가 생기는 것) 그만큼 추가로 pipeline을 한다.

Buffering의 의미 : 수신이 확실하지 않는 packet에 대하여 재전송을 위하여 보관하는 것.

상황)

• 2번 패킷 보내고,
• 수신측에서 2번 패킷 잘 받고,
• 수신측에서 2번 패킷을 응용계층으로 올려보냄
• 그런데 ACK2가 중간에 유실됨

• 송신측에서 3번 패킷 보내고,
• 수신측에서 3번 패킷 잘받고,
• 수신측에서 3번 패킷을 응용계층에 올리고,
• ACK3번도 송신측에서 받음. => 자동적으로 2번 패킷도 잘 받았다는 뜻이 됨. => 2번 패킷도 Buffer에서 지울 수 있음. 이유)
• Go-back-N에서 수신측에서는 순차적으로 잘 수신된 packet에 대하여 ACK을 송신하기 때문이다.
• Buffer에 4,5번 packet만 있게 됨.
• Buffer에 6,7번 packet 저장 가능해짐.
• 송신측에서 packet 6,7번을 송신한다.

장점)

• ACK을 받지 않아도 재전송하지 않아도 되는 효율성이 있다.

상황)

• 4번 패킷을 못 받음
• 5번 패킷은 잘 받음. => 수신측에서 순서에 맞지 않는 (이빨이 빠진) 패킷이 온경우 반응
  • 가만히 있는다.
  • 잘 받은 마지막 packet에 대한 ack을 전송
    • ex)너 보내는거 알겠는데 ~ 나 3번까지만 잘 받았어 ~~

상황)

• 잘받은 마지막 packet에 대한 ack 전송에 따른 그림이다.
• 보내도 되고 안보내도 된다.

Go-back-N에서의 재전송 정책 위 상황에서 어떻게 4번 packet으로 보낼 것인가??

1. timer 관련 정책.

• 각 packet 전송 시에 packet을 위한 timeout 설정 => ACK을 받으면 해당되는 packet timer 뿐만 아니라 앞의 packet timer 들도 소멸한다.
• timer event 발생시, 해당 packet 부터 재전송

2. 추가 재전송 정책.

• k번째 packet에 대한 ACK이 반복적으로 올 경우, k+1 packet의 유실을 함축함. => ex) 3번정도 k packet ACK이 오면, timer와 무관하게 k+1번째 packet부터 재전송한다.
• 이 그림에서 4번 패킷부터 7번패킷까지 재전송한다. 이유)
  • buffer 크기는 4이고,
  • packet 4번이 안 갔다는게 확실하니까.
  • 그렇다면, 5번부터는 다 잘 가도 수신측에서 버렸을 것이 확실하니까.

Go-back-N 장점

• 단순하다 (특히 수신측이 단순함.)
• 간명하게 시스템의 상태가 추상화 (잘 받은 패킷을 함축적으로 표현 가능)
• Go-back-N 단점*
• 패킷 유실시 복구 비용 많이 든다.(5,6,7 패킷은 잘가도 4번 패킷 빠졌다면 그 이후 모두 재전송)

구현방법 2. Selective Repeat

• Go-back-N 단점 보완(패킷 유실시 모두 재전송하는 문제)
  • 수신측에 buffer를 둠으로써 해결
    • 1) 빠진 packet이 있을 경우 그 뒤쪽의 잘 도착한 packet은 buffer에 보관
    • 2) 빠진 packet이 추후 도착하면, buffer에 저장한 이후 packet들까지 순차적으로 응용에 전달

상황) 1번, 3번, 4번 packet 잘 받았다고 ACK를 보낸다.

상황)

• 1번 packet 잘 왔다고 ACK 받음
• 송신 BUFFER에서 1번 packet 삭제한다.
• 5번 packet 전송한다.
• 송신 buffer에 5번 packet 보관한다.

상황)

• ACK3, ACK4를 송신측에서 받는다.
• BUFFER에서 packet3, packet4를 삭제한다.
• buffer에 자리가 남는다고 packet6,7을 보관하지 않는다. (buffer는 연속적인 packet으로 존재해야 하기 때문임)

• 송신측에서 보낸 5packet을 수신측에서 잘 받음
• 수신측에서 5packet으로 buffer에 보관한다.
• 그런데 ACK5가 중간에 유실됨.
• 그래서 송신측에서는 BUFFER에서 ACK5를 삭제할 수 없음.

• 2번 packet timer가 timeput 된다.
• 2 packet을 재전송한다.
• 수신측에서 2packet을 잘 받는다.
• 2번 packet으로 수신측 buffer에 넣는다
• 2,3,4,5packet을 응용 계층으로 올린다.

상황)

• ACK2를 보낸다.
• 송신 측 BUFFER에서 2번 packet을 삭제한다.
• 송신측에서 6,7,8 packet으로 새로 보관한다. 문제) 5번 ACK를 안보냈는데 어떻게 해야함?

상황)

• 위의 상황을 다시 그려놧음
• 6,7,8 packet을 송신한다.

상황)

• 수신측에서 6,7,8 packet을 잘 받음
• 바로, packet들을 application layer로 올려보냄.
• ACK6,7,8을 보냄
• 송신측 buffer에서 packet 6,7,8을 삭제함.
• 하지만, ACK 5를 받지 않은 상황에서 packet 9번을 전송할 수 없음.

상황)

• 5번 timer가 time out 된다.
• 5번 packet 재전송
• 수신측의 buffer는 8번 packet까지 잘 완료했다는 정보를 가지고 잇음.
• 5번 packet을 받고 무시한다.
• 그래도, ACK5는 보낸다.
• 송신측에서 packet5를 드디어 삭제할 수 있다.
• 이제, packet9번부터 전송 가능해진다.

Selective Repeat 장점

• 성능향상: 실패한 packet만 재전송

Selective Repeat 단점

• 시스템 추상화 복잡: 어떤 packet을 잘받았고, 못받았는지에 대한 정보를 유지해야 한다.
• 수신측에도 buffer가 필요하다.

SQL에서 뷰의 개념

• 데이터베이스 속에는 수많은 테이블들이 있다.
• DBMS를 쓰면 SQL을 쓸 수 있다.
• SQL을 이용해서 뷰를 만든다.
  • 충무과 일에 적합한 뷰를 보여준다. (뷰의 역할)
• 뷰를 정의할 때 SQL을 사용한다.
  • SQL을 만족하는 결과를 뷰로 정의해서 충무과, 인사과..에 전달을 한다.
• 뷰는 다른 테이블에서 유도된 단일 테이블이다. (질의 결과란 뜻임.)
  • 뷰는 SQL 명령어를 통해서 만들어진 질문의 결과다 ~
• 뷰는 가상적인 테이블이다.
  • 사용자는 뷰가 테이블처럼 보이지만 실제로 데이터베이스에 저장되는 테이블이랑은 차이가 있음.
  • 물리적으로 DB에 저장 X
• 사용자는 뷰에 대해서 질의할 수 있다. (뷰는 또 다른 테이블이기 때문에 가능하다)
  • 테이블에 대해서 또 다른 SQL을 실행할 수 있음.
  • 이 SQL은 RDBMS에 비해서 닫혀있다. 테이블에 대해서 SQL을 적용하면 테이블이 나오고, 이 테이블에 대해서 또 다른 SQL을 적용하면 또 다른 테이블이 나오는 것을 닫혀있는 연산~이라고 한다.
• 갱신은 제한적으로만 가능하다.

SQL에서 뷰의 명시

뷰의 생성

• SQL 조건에 맞는 결과를 찾아서 4개의 필드로 구성되는 결과 TABLE의 이름을 WORKS_ONI로 짓겠단다는 뜻.

• 이런식으로 필드 이름을 설정할 수 있다.

  • DNAME => "DEPT_NAME"
  • COUNT(*) => "NO_OF_EMPS"
  • SUM(SALARY) => "TOTAL_SAL"

• SQL에서 뷰는 하나의 테이블처럼 사용될 수 있다.

• 세개의 테이블로부터 뷰가 만들어짐

• 세개 테이블 중에 하나라도 삭제되면 뷰가 유효하지 않아짐.

• sql에서 뷰를 사용하면 질의 작성이 단순해진다.

  뷰의 최신성

  • 뷰는 항상 최신 정보를 가진다.
    • 이유) 세테이블의 튜플의 데이터가 바뀌면 뷰의 데이터도 바로 바뀜

      뷰의 특성

      

• 뷰를 최신 정보로 유지키시는 것은 사용자가 아니라 DBMS의 책임이다.

  • 뷰가 질의에서 사용될 때, 그때 바로 DBMS에서 데이터를 만들어서 사용하기 때문이다.
  • 뷰는 정의할 때 튜플들로 생성되지 않는다.
    • 뷰의 정의시기가 메타 data에 등록이 된다. ex) v1이 sql1에서 정의가 됐다 할 때, 요것을 meta data에 등록을 한다. => 나중에 v1이 다른 sql한테 사용될 때 이 sql문이 dbms에 의해서 실행이 돼서 그 결과가 v1으로 전달이 된다. 결론) 뷰를 정의할 때 튜플을 생성하는 것이 아니다. 질의에서 뷰를 사용할 때 바로 개선이 되어서 생성된다. 그 대신에 뷰를 정의할 때는 메타데이터에 뷰 정의식을 잘 보관을 해야한다.

      뷰의 삭제

• 뷰가 더이상 필요하지 않다면 DROP VIEW 명령으로 제거함

• 뷰는 보안기법의 일종으로 사용될 수 있다.

  • EX) 사용자한테 뷰만 보고 일을 해라. 뷰를 벗어난 데이터는 보지마라.

뷰의 구현

데이터베이스에서 뷰는 하나 이상의 테이블로부터 유도된 가상 테이블이다. 뷰는 실제로 데이터를 저장하지 않으며, 데이터를 조회하는데 사용되는 SQL 쿼리로 정의된다.

질의수정 방식

정의: 뷰는 SQL로 정의가 된다. 이 쿼리는 기본 테이블들로부터 데이터를 가져오는 방식으로 작성된다. 처리방식: 뷰가 포함된 SQL쿼리를 실행할 때, DB 시스템은 뷰 정의를 사용하여 쿼리를 수정한다. 즉, 뷰가 포함된 원래의 SQL 쿼리를 뷰 정의로 대체하여 실제 테이블에 대한 쿼리로 변환한다. 예시: CREATE VIEW view_name AS SELECT ... FROM table_name;로 정의된 뷰를 포함하는 쿼리가 있을 때, 데이터베이스 시스템은 SELECT ... FROM view_name을 SELECT ... FROM table_name으로 변환하여 실행한다.

결론: SQL 쿼리 내에 뷰가 포함되어 있으면, 데이터베이스 시스템은 뷰의 정의를 사용하여 해당 뷰를 실제 테이블을 대상으로 하는 SQL 쿼리로 대체한다.

뷰의 실체화 방식

• 뷰에 대한 요구가 있을 때 임시 뷰 테이블을 생성하고 , 이 임시 테이블로 처리하는 방식

정의: 실체화된 뷰는 일반 뷰와 달리 데이터를 실제로 저장하는 뷰다. 이는 뷰의 결과를 물리적으로 저장해서 이후의 조회를 빠르게 한다. 처리 방식: 뷰에 대한 요구가 있을 때 임시 뷰 테이블을 생성하고, 이 임시 테이블을 사용해서 쿼리를 처리한다. 실체화된 뷰는 주기적으로 또는 특정 이벤트에 따라 갱신된다. 장점: 데이터 조회 성능이 향상된다. 특히, 자주 조회되거나 계산 비용이 높은 뷰의 경우 유리하다. 단점: 데이터를 저장하고 갱신하는 추가 비용이 발생한다. 예시: CREATE MATERIALIZED VIEW view_name AS SELECT ... FROM table_name;로 정의된 실체화된 뷰는 정의 시점에 데이터를 저장하며, 이후 조회 시 저장된 데이터를 사용합니다.

결론: 실체화된 뷰는 뷰의 결과를 물리적으로 저장하여 조회 성능을 향상시키며, 갱신이 필요한 경우 갱신 작업을 수행합니다.

뷰의 갱신

• 뷰에 대한 질의는 언제나 할 수 있지만, 뷰의 갱신은 제한적으로 한다.
• 기본 릴레이션에 대한 갱신으로 변환하는 것이 모호하면, 갱신이 제한적이다.
• 이 부분은 어렵기 때문에 생략함.

• 이 경우에는 뷰의 갱신이 가능하다.
  • 뷰의 각 튜플과 기본 릴레이션의 튜플이 정확하게 대응하기 때문임.

그러나, 집단함수(AVERAGE, COUNT)를 사용해서 정의한 뷰는 갱신이 제한적이다.

• 요약정보이기 때문임.

기타 기능들

주장으로 제약 조건

• 이렇게 만들어서 등록해두면, 항상 월급을 비교해서 역전이 일어나는 경우를 방지한다.
  • 만약 INSERT, UPDATE 할 때 그런 경우가 생기면, DB 관리자한테 통보를 한다.

SQL 부가적인 기능들

요약

HTTP의 예를 통한 응용계층 최적화 및 DNS 등 추가 응용계층 프로토콜을 배운다.

패킷 스위칭

: 디지털 네트워킹에서 데이터를 전송하기 위해 더 작은 패킷으로 분할하는 방법. 각 패킷은 독립적으로 전송될 수 있고, 다른 경로를 통해 목적지에 도달한다. 목적지에서는 이 패킷들을 원래의 메시지로 재조립한다.

• 네트워크 자원을 더 잘 활용한다.
• 하나의 경로가 실패해도 패킷을 재라우팅할 수 있다.
• 잠재적인 지연이 발생할 수 있다.
• 일부 패킷 손실 가능성이 있어 재전송이 필요하다.
• 현대 데이터 네트워크에 사용

회로 스위칭

: 통신 세션 동안 두 지점 간에 전용 통신 경로를 설정한다.

• 일관되고 예측 가능한 성능 제공
• 전용 경로를 사용해서 지연이 적다.
• 전용경로를 설정하므로 자원이 비효율적으로 사용될 수 있음.
• 전통적인 음성 통신에 주로 사용
• 연결을 끊으면은 id =33 할당된걸 끊어야 한다.

중첩질의는 외부참조를 하는경우와 그렇지 않은경우를 나눠서 다르게 처리한다.

중첩질의

• 중첩질의는 시간이 많이 걸린다.
• 특히 외부 참조를 하는 경우에 바깥쪽 테이블의 각 튜플에 대해서 내부질의가 한번씩 실행되기 때문에 내부 질의의 실행 횟수는 바깥쪽 Employee 테이블의 튜플 수만큼 실행된다. 내부 질의가 몇번 실행되느냐 ? 외부질의의 튜플 수 만큼 실행된다.

SQL에서 명시적 집합과 널

재명명 애트리뷰트와 조인된 테이블

SELECT E.LNAME AS EMPLOYEE_NAME,
S.LNAME AS SUPERVISOR_NAME

E.LNAME을 EMPLOYEE_NAME로 이름을 바꾸고, S.LNAME을 SUPERVISOR_NAME로 이름을 바꾼다.

재명명 애트리뷰트와 조인된 테이블

16절과 16-1 은 똑같음.

외부조인(outer join)

그동안 우리가 배운 join은 innter join으로 생각

• 그 외에 LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN 이 존재한다.

outer join 의 요약

• 일반적으로 join 되는 경우에, 조건이 있는데 두 필드의 값이 같다" 와 같은 조건임. 근데 조건이 matching이 되는 튜플이 있고, 없는 튜플도 있다. join에 참여하는 튜블과 , join에 참여하지 않는 튜플로 구분한다. A1(A튜플 중 JOIN 참여), A2(A튜플 중 JOIN 참여X), B1(B튜플 중 JOIN 참여), B2(B튜플 중 JOIN 참여X)

1. Inner Join

• 우리가 흔히 알고있는 join임.
• join 조건에 만족하는 튜플들만 붙여서 결과를 만들어낸다.
• 2. Left Join*
• A 테이블 중 join에 참여하지 않는 튜플을 포함해서 넣는다.
• 3. Right Join*
• B 테이블 중 join에 참여하지 않는 튜플을 포함해서 넣는다.
• 4. Full Outer Join*
• • A 테이블 중 join에 참여하지 않는 튜플을 포함해서 넣는다.
• B 테이블 중 join에 참여하지 않는 튜플을 포함해서 넣는다.

집단함수와 그룹화

• 집단함수 = 집단화함수 = 집계함수 Sum, Max, Min, Avg, COUNT를 이용해서 테이블의 집계치를 편리하게 구할 수 있음. !

• 많이 사용된다.

• GROUP BY: 각 그룹의 집계치

Having 절

• sql에서 제일 마지막 절임.
• 그룹을 선택 하는 조건이다
  • where 절은 튜플에 대한 조건임. : 튜플이 결과에 포함될 것이냐 말것이냐 조건임.
• GROUP BY에 의해서 여러 그룹들이 만들어졌을 때 , 그 그룹을 최종적으로 담을 것이냐 안담을 것이냐 하는 것.

SQL 질의에 대한 논의와 요약

File

• 하드디스크에 저장하는 단위 메모리는 주소를 통해서 접근하는 장치임. 파일은 이름을 통해서 접근하는 단위임.

• 관련정보를 이름으로 저장하는 것.

• 파일은 비휘발성의 보조 기억 장치, 하드디스크에 저장된다.

• 데이터를 저장하는 목적으로만 파일을 쓰는게 아님. 운영체제 특히 linux에서는 여러가지 장치들도 관리하기 위해서 파일이라는 이름을 사용해서 관리한다. 다양한 저장장치들 하드디스크1번, 하드디스크 2번 이 있으면, 운영체제는 그런 장치들을 서로 다른 파일로 관리하고 있음. 이런식의 파일을 device special file이라고 부름. 이거는 일반적인 file과는 다름.

• 파일에 대해서 정의되는 연산은??

  • 파일 create
  • 파일 delete
  • 파일 read, wirte
  • 파일 reposition (lseek라고도 함(엘시크)) : 파일은 여러개의 바이트로 구성되기 때문에, 어느 위치를 읽고 쓰느냐는 pointer가 있음. 한번 읽고 나면 그 다음 부분을 가리키게 됨. 쭉 읽으면 위치 pointer는 다음으로 가고, 그 위치부터 읽히게 된다. 하지만, 다른 부분부터 읽거나 쓰고 싶을 때, 이런 위치를 수정해주는 것 => reposition
  • 파일 open, close :정의로는 read,wirte 하려면 open 먼저 해야 한다라고 쓰여있음. 다 하면 close 해라. open의 역할은 그 파일을 디스크에서 메모리로 내용을 올려놓는게 아니라, 파일의 메타데이터를 메모리에 올려놓는것이다.

  File System

  • 운영체제에서 파일을 관리하는 software
  • 파일 시스템은 파일 자체의 내용도 관리하지만, 그 파일의 메타데이터도 같이 저장을 한다.
  • 파일 시스템에 파일을 저장할 때 디렉토리를 둬서, 루트 디렉토리부터 계층적으로 저장을 한다.
  • 파일 시스템은 파일을 어떻게 저장하고, 관리할지, 보호할지 담당하고 있다.
  • 디렉토리는 대부분의 file system에서 제공한다. 디렉토리도 하나의 file임. 디렉토리 파일은 그 파일의 메타데이터는 디렉토리 파일의 이름과 접근권한 등일 것이고, 디렉토리 파일의 내용은 그 디렉토리 밑에 존재하는 파일이 어떤건지, 그 파일들의 메타데이터가 된다.

Directory and Logical Disk

Directory

• 하나의 파일임.
• 파일의 내용이 '디렉토리 밑의 파일들이 어떤 파일인지의 정보'를 내용으로 한다.
• 파일의 메타데이터는 해당 디렉토리의 접근권한, 시간 등이 된다.
• 연산: 디렉토리 밑의 파일들이 어떤건지 목록을 보는 것, 그 디렉토리 밑 파일을 찾는것, 파일을 지우는 것등...

Partition

파일시스템이 하드디스크에 저장이 될텐데 우리가 이 디스크라는게 논리적인 디스크, 물리적인 디스크가 있다.

운영체제가 보는 디스크는 논리적인 디스크고, = Partition이다.

• 하드디스크를 하나사서 c드라이브, d드라이브 partition을 나누면, 그 각각이 논리적인 디스크가 됨.
• 경우에 따라서는 물리적인 디스크 여러개를 합쳐서 논리적인 디스크 하나를 구성할 수도 있음.

용도

• 파티션에 파일 시스템 설치할 수 있음.
• 논리디스크를 virtual memory swap area 용도로도 사용 가능

open()

• open 연산: 파일의 메타데이터를 메모리로 올려놓는것.

논리적인 디스크 안에 파일 시스템이 있으면,

• file metadata : 파일의 저장위치(file content가 어디 저장되어 있는지에 대한 pointer가 저장되어 있다는 뜻.), 파일의 이름, 유형, 파일 사이즈
• file content 가 저장되어 있다.

어쨌거나, 이 file을 open하게 되면 file metadata가 메모리로 올라오게 된다.

open("/a/b/c") -디렉토리를 따라가서 c라는 파일의 위치를 찾게되는 것.

• 사용자 프로그램의 시스템 콜 (시스템 콜은 read, write, open...등이 있음.)
  • 나는 a디렉토리의 b 파일을 open하겠다.

=> open 하게 되면, => 시스템콜이니까 cpu 제어권이 운영체제한테 넘어간다. => 운영체제 안에는 각 process 별로 관리하기 위한 자료구조가 있고 (PCB) => open 한 파일들이 어떤건지 관리하는 global한 table이 유지되고 있다. (Open file table)

root directory의 metadata는 미리 알려져있기 때문에 운영체제가 root directory의 metadata를 알고 있음.
=> 메모리에 먼저 올린다.
즉, root를 먼저 open 하는 것.

• metadata에는 해당 파일의 content 위치가 들어잇음.
• root directory는 그 안에 file들의 metadata를 가지고 있음.

• root 디렉토리 content에 a파일의 metadata가 존재함.

• 이 a의 metadata를 메모리에 올려놓는다.

• 위 과정을 계속 반복하다가,
• b의 metadata를 메모리에 올려놓게 된다.
• open 이라는것은 metadata를 메모리에 올려놓는 것이기 때문에 open이 끝난것.

• open이 끝나면, 시스템 콜을 한 것인데 어떤 결과값을 return 하게 된다. => 각 process마다, 그 process가 open한 파일들에 대한 metadata pointer들을 가지고 있는 일종의 배열 같은게 정의되어 있다.

지금 open한 b의 metadata 파일의 위치가 여기다. 그 위치를 가리키는 포인터가 이 배열 어딘가에 만들어지고,

그 배열이 해당 배열에서 몇번째 idx인가? => 그것이 b의 fd(file descripter)가 되어서 그 값을 사용자 process한테 return 을 한다.

• 사용자가 read 요청을 한다면 b 파일의 fd를 이용해 metadata에 접근하게 되고, metadata는 해당 content의 위치를 알게된다.

그 내용을 메모리로 읽어서 프로그램한테 전달하면된다. 이 과정에서 내용을 사용자 프로그램한테 직접 주는게 아니라 운영체제가 자신의 메모리 공간 일부에다가 먼저 읽어놓는다 그 다음에 사용자 프로그램한테 copy 해서 전달한다

만약에 이 프로그램 또는 다른 프로그램이 , 동일한 파일의 동일한 위치를 요청하면, read 시스템 콜을 하면, 디스크까지 가는게 아니라, 운영체제가 이미 읽어놓은게 있기 때문에 이걸 바로 전달할 수 있다. => buffer caching

우리가 virtual memory system의 paging 기법을 배웠었다.

• 이미 메모리에 올라와잇는 page에 대해서는 운영체제가 중간에 끼어들지 못하고 주소변환을 하드웨어가 해서 바로 접근을 했다.
• pafe fault가 나면 그제서야 운영체제가 cpu를 받아서 운영체제가 swap 영역에서 page를 읽어왔다.

그런데, file에 대한 read/wirte 시스템에서는

• 역시 운영체제가 buffer cache 라는 것을 가지고 있는데,
• 이 파일 시스템의 buffer cache는 요청한 내용이 이 buffer cache안에 있든 없든간에 운영체제한테 cpu가 넘어가게 된다.
  • 데이터를 요청했을 때 메모리가 안올라와있을 때 b의 content에서 읽어와서 메모리에 올려놨었다.
  • 나중에 이미 메모리에 올려둔 데이터를 누가 요청을 한다면 이것 역시 시스템 콜이기 때문에 cpu제어권이 운영체제한테 넘어간다.
    • 운영체제가 판단하는것. 아?이게 나한테 이미 있네? 그러면 그냥 전달 . 요청한게 없으면 디스크에서 읽어와서 buffer cache한테 올려두고, copy 해서 사용자 프로그램한테 전달한다. => 이 buffer cache라는 환경에서는 시스템 콜을 통해서 cpu가 운영체제한테 넘어오기 때문에 LRU, LFU 알고리즘을 자연스럽게 사용할 수 있다. 모든 정보를 운영체제가 알고 있기 때문이다. 전시간에 paging system에서 LRU를 못쓰고, clock 알고리즘을 썼던 것과는 대조가 된다.

커널이 유지하는 테이블들에 대해서 여러가지 이름이 주어진다. 이런 file descripter들은 프로세스마다 가지고 있다고 해서 => per-process file descriptor table

파일을 open 햇으면 프로세스마다 가지고 있는 것이 아니라, open된 파일의 목록들을 system-wide하게 한꺼번에 관리하고 있다. => system-wide open file table

이 테이블 들이, 시스템 안에 open과 관련된 테이블이 글로벌하게 하나 있는게 있고, 프로세스마다 별개로 있는 table이 있다. 지금은, 두개만 보여줬는데 구현에 따라서 이런 table이 3종류가 있을 수도 있고 그렇다 왜냐하면, 메타데이터가 디스크에 있을 때는 아래 정보만이 meta data가 되는데 이거를 메모리에 올려놓게 되면, 여기에 추가적으로 메타데이터가 필요하게 된다. 현재 이 process가 이 파일의 어느 위치를 접근하고 있다는 offset을 운영체제가 같이 가지고 있어야 한다. 근데 그거는 프로그램들 마다 별도겠죠.

• A라는 프로그램이 요 파일을 OPEN했지만 또 다른 프로그램이 이 파일을 OPEN 할수도 있다. 그러면 b라는 파일의 메타데이터는 한 copy만 올라가 있음. system-wide하게 하나만 존재하는데, offset은 서로다르다.
• a프로그램이 이 파일을 읽고 있는 위치
• b프로그램이 이 파일을 읽고 있는 위치 는 다르기 때문이다.
  => open file을 두개로 나눠서
• process와 무관하게 하나만 갖고 있는 요것과
• process가 파일을 읽고 있는 위치 offset 이거를 따로 관리하는 table을 두는 것이 일반적이다.

File Protection

파일의 접근 권한에 대해 알아보자.

메모리 접근 권한은?

• read/write만 이야기
• 파일별로 메모리를 따로 가지고 있기 때문임. (결국에는 자기 혼자밖에 못봄)

그러나, 파일은

• 여러 사용자, 여러 프로그램이 같이 사용
• 파일에 대한 접근권한은, 접근권한이 누구한테 있냐? 접근 연산 어떤 것이 가능한가?를 같이 가지고 있어야함.
• 파일 접근권한 제어방법은 3가지 정도가 있음.

Access control Matrix

• 행렬임
• 각각의 사용자가 각각의 파일에 대해서 어떤 권한이 있는지 표시
• 낭비가 심함
  • ex) user가 어떤 파일에 대해서 자기만 접근권한이 있는데, 다른 수천명의 유저가 해당 파일에 대해 접근 권한이 다 비어있을 것임. => linked list 형태로 만드는 것을 생각하게 됨. (2가지 방법) 1) Access control list: 파일을 주체로 해서 접근 권한이 있는 사용자를 linked list 형태로 묶어두는 방법. 2) Capability: 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한 표시

=> 부가적인 overhead가 크다.

Grouping

• 일반적인 운영체제에서 이 방법을 통해 파일 접근 권한 관리
• 모든 사용자에 대해서 접근 권한을 다루는 것이 아님. => 각각의 파일에 대해서 사용자 그룹을 3가지로 나눈다.
• 그 파일의 소유주에 대해서 접근권한이 read/write/execution 뭐가 있는지 표시하고, 이 사용자와 동일 그룹에 속한 사용자에 대해서 읽기/쓰기/실행권한이 있는지 없는지 표시한다. 파일 하나에 대해서 접근 권한을 나타내기 위해 총 9개의 bit만 있으면 된다.

  File System의 Mounting

  

• 하나의 물리적인 디스크를 partitioning을 통해서 여러개의 논리적인 디스크로 나눌 수가 있다.
• 각가의 논리적인 디스크에는 파일 시스템을 설치해서 사용할 수 있다.
• 루트 파일 시스템이라고 해서, 특정 os에 대해서 파일 시스템 하나가 접근이 가능한데, 만약에 다른 partition에 설치되어 있는 파일 시스템에 접근하고 싶을 때는?? => Mounting연산

Mounting

• 루트 파일 시스템의 특정 디렉토리 이름에다가 또다른 파티션에 있는 파일 시스템을 갖다가 mount를 해주면 그 mount된 디렉토리에 접근하게 되면, 또 다른 파일 시스템의 루트 디렉토리에 접근하는 꼴이 된다. => 서로 다른 파일 시스템에 서로 다른 파티션에 존재하는 파일 시스템을 접근할 수 있게 된다는 뜻.

Access Methods

파일을 접근하는 방법에 관한 것

• 순차 접근
  • 카세트 테이프 처럼 되감아야함.
• 직접 접근 (=임의 접근)
  • cd, 하드디스크 등 직접 접근 가능

HTTP의 예를 통한 응용계층 최적화 및 DNS 등 추가 응용계층 프로토콜을 배운다.

응용계층

DNS

Domain Name System

Internet 에서의 ID (기계)

IP : internet protocol

1) IPv4

• 32bit (8bit * 4)
• 10진수로 표현 (0~255 사이의 10진수) ex) 192.168.0.1
• 총 2^32개의 고유한 ip 주소 제공, 약 43억개의 주소 2) IPv6
• 128bit (16bit * 8)
• 16진수로 표현 (4비트가 필요함) ex) 2001:0db8:85a3:0000:0000:8a2e:0370:7334
• ) 2진수(0과 1의 두 가지 값을 사용하여 숫자를 표현) 표현하기 위해 1비트 필요함 4진수( 0, 1, 2, 3 네 가지 값을 사용하여 숫자를 표현) 표현하기 위해 2비트 필요함 8진수(0에서 7까지의 값을 사용하여 숫자를 표현) 표현하기 위해 3비트 필요함 16진수(0에서 9 및 A에서 F까지의 값을 사용하여 숫자를 표현) 표현하기 위해 4비트 필요함.

=> ip 주소를 암기하기 힘들어 => Domain Name을 만들자

Domain Name

• 순수하게 인간을 위한 시스템
• 응용계층 밑으로 내려가기 시작하면 의미가 사라짐.

• 운영체제는 두가지 계층으로 나뉨
  • user level
  • kernel level : 사용자가 함부로 접근할 수 없는 시스템 관련 부분이 많음 => 네트워크 응용 계층 이외의 계층들은 모두 다 kernel level에 들어가 있음.

• transport layer, network layer, data link layer, physical layer는 kernel level에 있음.
• 이 layer들은 Domain Name에 관여를 안한다.
• 다 ip로 움직인다. 왜?
• Domain Name은 사람이 보기 좋고, 기계가 보기에 안좋음.
• www.naver.com 과 formal.kau.ac.kr 을 비교해보자
  • 길이도 유동적이고 .과 같은 형식도 다름. => 동작이 오래걸림.

결론)

• domain name은 응용계층 (인터넷 5계층 기준)에서만 관여한다.
  • domain name system은 굉장히 아래쪽에서부터 다룰 것 같지만 아님.
    : 어떤 domain name이 어떤 ip를 갖게 될 것인가를 mapping 해주는 시스템 왜? 사용자가 domain name을 썼지만, 컴퓨터에게 ip로 이해시켜야함.

Domain Name System

응용계층이라고 하기엔, 좀 특별한 서비스를 갖고 있다.

1) 서비스

• Domain Name => ip주소 로 변환 하는 서비스임.
• 경우에 따라서는 Aliasing 관리 : 같은 곳에 대해서 여러개의 주소를 쓰게함.
  • 보통, 네트워크 하나당 ip 하나씩 할당 ex) 컴퓨터 유선 연결 ip 하나, 무선 연결 ip 하나 할당
• 전우주적으로 중앙관리 : 전세계적으로 일관성있고 신뢰성있게 동작하도록 중앙에서 관리한다. (어떤 사용자가 특정 도메인에 접속할 때 어느나라에서든 동일한 IP 주소로 연결된다.)
• 분산관리 : 여러 계층으로 분산된 서버들에 의해 관리된다. (아래에서 더 자세히 알아보자)

2)계층

• 최상위 계층 : Root Name Server
  • Top-Level domain name server를 관리한다.
    • Top-Level domain: ex) ".kr",".com", ".edy", ".org", ".net"
    • Top-Level domain 들 마다 domain name server가 있다.
  • Top-Level Domain server의 IP를 반환한다 (유효기간과 함께) ex) .kr로 끝나는 주소에 대해서는 어떤 ip를 반환한다. 그러니, 해당 user는 .kr로 끝나는 주소에 대해서 또 물어볼 필요 없음.
  • 유효기간동안은 동일한 top-level domain server ip 요청을 하지 않는다.

1. Recursive Domain Name Resolution

• 최근에는 지원이 안됨.
• Root Name Server가 그렇게 친절하진 않음.

2. Iterative

P2P

• 서버 없이 단말(peer)들끼리 직접 연결되어 서비스를 공유하는 시스템 (물물교환)
• 서비스 보장 X
• peer들은 ip를 바꾸며 옮겨 다닐 수 있다.

=> Hybrid System 등장

Hybrid System

• *서비스 메타정보는 서버가 관리. *
• *실질적인 서비스는 peer들끼리. *
• ex1) Skype:skype를 통해서 전화하는 것이 아니라, skype는 내가 전화를 하고 싶어하는 상대방이 어디에 위치해있는지만 알려준다. 실제 커뮤니케이션은 peer끼리 한다.
• ex2) 스타크래프트: 방을 만드는 건 서버가 해주지만, 그 방에 있는 사람들끼리 게임할 때는 peer들끼리 커뮤니케이션 한다.

Pure P2P

EX) 토렌트, 비트코인 BitTorrent: 파일을 여러 조각으로 나누어 분산하여 공유하는 파일 공유 시스템이다. 사용자는 동시에 여러 노드로부터 파일 조각을 다운로드 하고, 자신이 가진 파일 조각을 다른 사용자에게 업로드한다.

문제) 1. 신뢰성 부족 : Pure P2P 네트워크에서는 중앙 서버가 없기 때문에 각 노드의 신뢰ㅣ성을 보장하지 어렵다. 일부 노드는 고의적으로 잘못된 데이터를 제공하거나, 데이터 전송을 방해할 수 있따. 또한 노드의 가용성이 일관되지 않을 수 있으며, 특정 노드가 갑자기 ㅅ라지면 데이터 손실이나 네트워크 성능 저하가 발생할 수 있다.

• 해결: 신뢰도를 평가해서 신뢰도가 낮으면 네트워크에서 배제하거나 제한된 권한 부여한다. / 데이터를 여러 소스로부터 다운로드하고 비교해서 일치하는 데이터만을 신뢰한다. / 데이터를 암호화하고 디지털 서명을 사용해서 데이터의 무결성과 출처를 검증한다. (데이터가 전송되는 동안 변조되지 않았음을 보장.)

2. 이기적 노드 문제 : 일부 노드들은 자신의 자원을 공유하지 않고, 다른 노드의 자원만 사용하려고 한다. 이러한 이기적 행동은 네트워크 자원 균형을 깨트리고, 전체 네트워크 성능을 저하시킬 수 있다.

• 해결: 자원을 많이 공유하는 노드에게 보상을 제공하고, 자원을 거의 공유하지 않는 노드에게 패털티를 부과한다.(인센티브 구조 도입)/ 자원을 공유한 노드끼리 연결해서 이기적인 노드들이 자원을 얻기 어렵게 한다. (페어링 시스템)/ 각 노드의 자원 공유 내역을 기록하고, 평판이 낮은 노드는 자원을 얻는데 불이익을 받게 한다(노드 평판 시스템)

3. 조각들의 쏠림 현상:Pure P2P 네트워크에서 데이터 조각들이 특정 노드에 집중되어 쏠림 현상이 발생할 수 있다. 이는 네트워크의 부하를 특정노드에 집중시키고, 자원의 비효율적인 사용을 초래할 수 있다.

• 해결: 데이터 조각을 네트워크 전체에 고르게 분산시키는 알고리즘을 사요앟ㄴ다 예를 들어 분산 해시 테이블을 이용해서 조각을 특정 노드에 균등하게 분배한다.(균형 잡힌 조각 배포)/ 네트워크 상태를 모니터링하고 특정 노드에 조각이 집중될 경우, 다른 노드로 일부 조각을 재배치해서 네트워크 부하를 균등하게 분산시킨다. (동적 조각 재배치)/ 각 조각을 여러 노드에 복제해서 특정 노드에 조각이 집중되지 않도록 한다. 이로 인해 특정 노드가 사라지더라도 데이터의 가용성을 유지할 수 있다. (복제전략)

개인용 말고도, 다사용자를 위한 DBMS도 있음 => MS SQL Server

이 테이블을 만들어보자.

중첩 질의

중첩 질의: sql 안에 sql이 들어가 있는 것.

• 특히, sql의 WHERE 절 안에 완전한 SQL문이 나타나는 질의

3-Way join은 FROM절에 테이블에 3개 나오는 절임.

• WHERE 조건 3개을 만족하는 세 테이블의 튜플 들을 찾아서 SELECT 단위에 나오는 필드를 보여달라.

• PLOCATION="Stafford" : join 조건이 아니라 selection 조건임.
• 프로젝트의 관리 부서를 찾고 => 그 관리 부서의 매니저를 찾는 조건임.

SQL - 모호한 속성이름과 별명

집합으로서의 테이블

테이블을 튜플의 집합으로 간주.

Bag of tuples

중복된 튜플들.

• 튜플들의 집합이 아니라, 튜플들의 Bag이다.
• 튜플들의 멀티 Set이다.

동일한 salary 값을 하나로 표시하고, 나머지는 다 제거하기 위해서는 DISTINCT 키워드를 붙여야 한다. => Set of tuples

• DISTINCT를 사용함으로써 Set 집합이 된다.

또 다른 집합의 개념으로서 집합 연산이 가능합니다.

• SELECT 질문 두개가 UNION으로 연결됨.
• 위의 질문의 결과도 PNUMBER, 아래 질문의 결과도 PNUMBER이므로, 두개를 UNION 했을 때 의미가 있음.
• UNION 호환성 (= UNION compatibility)
• UNION(합집합), EXCEPT(차집합), INTERSECT(교집합) 연산 가능

• Union ALL 은 아까 본 multiple set 이다.

부분 문자열 비교, 산술 연산자, 정렬

• 반드시 문자열 필드에서 적용이 가능함.
• LIKE 연산자는 비슷한걸 찾는다의 의미.
• *: 0~more 0개 이상의 문자가 덧붙을 수 있다.

Date 함수를 이용한 질의

• 연도 파트만 뽑아내라.

SQL - Order By

: 질문의 결과가 어떤 튜플을 기준으로 정렬되게 해서 나오게 하고 싶을 때 사용

SQL에서 삽입, 삭제, 갱신 구문

INSERT 명령

• 필드이름이 아닌, 테이블 이름만을 명시하면 : 모든 필드의 값을 다 제공해야한다.
• 만약, 필드 이름을 주면, 해당하는 필드에 대한 값만 주면됨.

• CREATE TABLE 명령어로 DEPTS_INFO라는 테이블을 만들고,
• 그 테이블의 다른 테이블로부터 질문을 한다음에,
• 질문한 결과를 질의의 결과를, 저장한다. 여기서는 (DEPT_NAME, NO_OF_EMPS, TOTAL_SAL)
• SELECT 결과 포맷하고, INSERT할 TABLE의 포맷이 똑같아야 호환성이 있음. (DEPT_NAME, NO_OF_EMPS, TOTAL_SAL)

다른 테이블에서 데이터를 가져와서 DEPTS_INFO에 넣은 경우에

• 원본(Employee)이 바뀌면, DEPTS_INFO은 원본 데이터와 일치하지 않다.
• 원본 데이터 변경을 반영하고 싶으면, DEPTS_INFO를 view로 정의한다.

DELETE 명령

• DELETE 어떤 명령의 조건을 만족하는 레코드를 DELETE해라.
• (1)는, 한 레코드 DELETE
• 만약, 키 이외에 다른 조건을 주면 여러개의 조건을 만족하는 코드를 만족하는 레코드들이 DELETE됨.

UPDATE 명령

• WHERE : 어떤 조건을 만족하는 튜플을 찾아서
• SET: 그 튜플의 값을 바꿔라 ~

SELECT: Research 부서의 DNUMBER를 찾고,
WHERE: Research 부서의 DNUMBER에 해당하는 WHERE 조건을 만족하는 값을 찾아서 SET: Employee 월급을 올려라 ~

SQL 질의에 대한 논의와 요약