뒤돌아보기

02-1 이더넷

• 물리 계층과 데이터 링크 계층은 이더넷이라는 공통된 기술이 사용되기 때문에 서로 밀접하게 관련되어 있음

이더넷

• 유선 LAN 환경에서 가장 대중적으로 사용되는 기술로 케이블 등의 다양한 통신 매체의 규격들과 송수신되는 프레임의 형태, 프레임을 주고 받는 방법 등이 정의된 네트워크 기술

이더넷 표준

• 유선 LAN 환경에서는 대부분 물리 계층에서는 이더넷 규격 케이블을 사용하고, 데이터 링크 계층에서 주고 받는 프레임은 이더넷 프레임의 형식을 따름
• 이더넷은 국제적으로 표준화가 이루어져 IEEE 802.3이라는 이름으로 불림. 서로 다른 컴퓨터가 각기 다른 제조사의 네트워크 장비를 사용해도 이더넷 표준을 준수하면 서로 통일된 형태로 통신할 수 있음

통신 매체 표기 형태

• 이더넷 표준에 따라 통신 매체의 종류과 전송 속도가 달라질 수 있는데 속도와 특성을 한눈에 파악하기 쉽도록 아래와 같은 형태로 표기

전송 속도 BASE-추가특성

1. 전송 속도(data rate)

• 숫자만 표기되어 있으면 Mbps, 숫자 뒤에 G가 붙는 경우 Gbps 속도를 의미
  • 1000Base-T 케이블은 1000Mbps 속도를 지원하는 케이블
  • 10GBase-T 케이블은 10Gbps 속도를 지원하는 케이블

2. BASE

• 베이스 밴드(BASEband)의 약자로, 변조 타입(modulation type)을 의미
  • 변조타입 : 비트 신호로 변환된 데이터를 통신 매체로 전송하는 방법으로 대부분 디지털 신호를 송수신하는 베이브밴드 방식을 사용

3. 추가특성

• 다양한 추가적인 특성을 표현
• 10BASE-2, 10BASE-5와 같이 전송 가능한 최대 거리가 명시
• 데이터가 비트 신호로 변환되는 방식을 의미하는 물리 계층 인코딩 방식이 명시되기도 하고 (EX) 1000BASE-CX)
• 비트 신호를 옮길 수 있는 전송로 수를 의미하는 레인 수가 명시되기도 함 (ex) 100GBASE-LR4)

통신 매체 종류

• 가장 대중적인 통신 매체의 종류 예시로 추가 특성에 C, T, S, L이라는 글자가 있음
  • C: 동축 케이블
  • T: 트위스티드 페어 케이블
  • S: 단파장 광섬유 케이블
  • L: 장파장 광섬유 케이블

이더넷 프레임(Ethernet frame)

• 이더넷 네트워크에서 주고받는 프레임 형식으로 상위 계층으로부터 받아들인 정보에 헤더와 트레일러를 추가하는 캡슐화 과정을 통해 만들어짐
• 헤더는 기본적으로 프리앰블, 수신지 MAC 주소, 송신지 MAC 주소, 타입/길이로 구성되고, 페이로드는 데이터, 트레일러는 FCS로 구성

프리엠블 (preamble)

• 서두를 뜻하고, 이더넷 프레임의 시작을 알리는 8바이트(64비트) 크기의 정보임
• 첫 7바이트는 10101010 값을 가지고, 마지막 바이트는 10101011 값을 가짐. 수신지는 이 프리엠블을 통해 이더넷 프레임이 오고 있음을 알아차림

수신지 MAC 주소와 송신지 MAC 주소

• MAC 주소란 Media Access Control address로 ‘물리적 주소’라고도 불림
• 네트워크 인터페이스마다 부여되는 6바이트(48비트) 길이의 주소로 LAN 내의 수신지와 송신지를 특정할 수 있음
• 보통 NIC(Network Interface Controller)라는 장치가 네트워크 인터페이스 역할을 하는데 한 컴퓨터에 NIC가 여러개 있다면 MAC주소도 여러개 있을 수 있음
• 아래의 명령어로 컴퓨터의 MAC 주소를 직접 확인할 수 있음
  • Windows: ipconfig /all
  • 맥OS 나 리눅스 운영체제: ifconfig (결과 예시 bc:d0:74:61:fd:3c)

$ ifconfig 
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
	ether bc:d0:74:61:fd:3c
	inet6 fe80::1c94:978d:432:1cdf%en0 prefixlen 64 secured scopeid 0xf 
	inet 172.30.1.5 netmask 0xffffff00 broadcast 172.30.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active

타입/길이

• 필드에 명시된 크기가 1500(16진수 05DC) 이하인 경우 프레임의 크기(길이)를 나타냄
• 크기가 1536(16진수 0600) 이상인 경우 타입을 나타냄
• 타입이란 이더넷 프레임이 ‘어떤 정보를 캡슐화했는지’를 나타내는 정보로 이더타입(ethertype)이라고도 부름
• 대표적으로 상위 계층에서 사용된 프로토콜의 이름이 명시됨
  • 0800: IPv4
  • 86DD: IPv6
  • 0806: ARP

데이터

• 상위 계층에서 전달받거나 상위 계층으로 전달해야 할 내용으로 최대 크기는 1500 바이트
• 항상 46 바이트 이상이어야 하며 그 이하의 데이터인 경우믄 크기를 맞추기 위해 패딩(padding)이라는 정보가 내부에 채워짐. 보통 0으로 채워짐

FCS

• Frame Check Sequence로 수신한 이더넷 프레임에 오류가 있는지 체크하기 위한 필드
• 이 필드에는 CRC(Cycle Redundancy Check) 라 불리는 오류 검출용 값이 들어가는데 송신지는 프리엠블을 제외한 나머지 필드 값들을 바탕으로 CRC 값을 계산 후 FCS에 명시
• 수신지는 수신한 프레임에서 프리앰블과 FCS 필드를 제외한 나머지 필드 값을 바탕으로 CRC 값을 계산한 뒤, 이 값을 FCS와 비교하여 일치 하지 않으면 프레임을 폐기

References

• 혼자 공부하는 네트워크 Youtube 강의
• 책 "혼자 공부하는 네트워크"

pathlib 모듈은 파이썬 표준 라이브러리로, 파일 읽기/쓰기 작업이나 디렉토리에 있는 특정 유형 파일 나열, 특정 파일의 상위 디렉토리 찾기 등의 작업을 할 때 사용됨

The Problem With Representing Paths as Strings

• python 3.4 버전부터 pathlib 모듈이 등장했는데 pathlib이 존재하기 전에는 전통적으로 string을 이용하여 파일 경로를 표현했음
• 하지만 경로는 일반 문자열 이상이기 때문에 중요한 기능들이 os, glob, shutil과 같은 라이브러리를 포함한 표준 라이브러리 전체에 분산되어 있었음
• 예를 들어 아래의 코드는 txt 파일을 하위의 archive 폴더로 이동시키는 내용

import glob
import os
import shutil

for file_name in glob.glob("*.txt"):
    new_path = os.path.join("archive", file_name)
    shutil.move(file_name, new_path)

• glob, os, shutil 까지 3개의 import statement 필요
• pathlib 모듈은 여러 운영체제에서 동일한 방식으로 작동하는 Path 클래스를 제공해 위 3가지 모듈은 임포트 하는 대신 pathlib 모듈만 사용하여 동일한 작업을 수행할 수 있음

from pathlib import Path

for file_path in Path.cwd().glob("*.txt"):
    new_path = Path("archive") / file_path.name
    file_path.replace(new_path)

Path Instantiation With Python’s pathlib

• pathlib 모듈에 대해 한가지 강력한 동기는 string 대신 전용 객체로 파일 시스템을 표현하는 것
• 객체 지향 접근 방식은 기존 os.path 방식과 대조할 때, pathlib 핵심이 Path 클래스 라는 점에 주목하면 더욱 분명함

>>> from pathlib import Path
>>> Path
<class 'pathlib.Path'>

• Path 클래스로 작업하기 때문에 import pathlib; pathlib.Path 보다 from pathlib import Path로 작업하는게 더 효율적
• Path 객체를 인스턴스화 하는 방법에는 몇가지가 있지만 이 글에서는 클래스 메소드, 문자열 전달, path 컴포넌트를 조인함으로써 path 객체를 생성하는 것을 살펴봄

Using Path Methods

• Path를 import 한 후에 working directory나 home directory를 가져오기 위해 기존 메소드를 사용할 수 있음

>>> from pathlib import Path
>>> Path.cwd()
PosixPath('/Users/woo-seongchoi/Desktop/realpython')

• pathlib.Path를 인스턴스로 만들면, OS에 따라 WindowsPath나 PosixPath 객체를 얻을 수 있음
• 일반적으로 Path를 사용하면, 사용중인 플랫폼에 대한 구체적인 경로를 인스턴스화하는 동시에 코드가 플랫폼에 독립적으로 유지됨

>>> from pathlib import Path
>>> Path.home()
PosixPath('/Users/woo-seongchoi')

• Path 객체의 cwd나 home 메소드를 통해 python script의 starting point를 쉽게 얻을 수 있음

Passing in a String

• home directory나 current working directory 대신에 string을 Path 에 전달함으로써 directory나 file을 가리킬 수 있음

>>> from pathlib import Path
>>> Path("/Users/woo-seongchoi/Desktop/realpython/file.txt")
PosixPath('/Users/woo-seongchoi/Desktop/realpython/file.txt')

• Path 객체를 생성하고 string을 다루는 대신 pathlib 모듈이 제공하는 유연성을 통해 작업 가능
• POSIX는 Portable Operating System Interface 이고, path 표현 등을 포함하여 운영 체제간 호환성을 유지하기 위한 표준임

Joining Paths

• 슬래시 (’/’) 를 이용하여 경로의 일부를 연결하도록 경로를 구성할 수 있음

from pathlib import Path

for file_path in Path.cwd().glob("*.txt"):
    new_path = Path("archive") / file_path.name
    file_path.rename(new_path)

• 슬래시 연산자는 Path 객체를 포함하는 한 여러 경로 또는 경로와 문자열이 섞인 경우도 결합시킬 수 있음
• 슬래시 연산자를 사용하지 않는다면 joinpath 메소드를 사용할 수 있음

>>> from pathlib import Path
>>> Path.home().joinpath("python", "scripts", "test.py")
PosixPath('/home/woo-seongchoi/python/scripts/test.py')

References

https://realpython.com/python-pathlib/

본 글은 인프런 강의 "대세는 쿠버네티스 [초급~중급]" 를 듣고 요약 및 실습 정리한 내용입니다.

Service

• 기본적으로 자신의 cluster ip를 가짐

• Service를 Pod에 연결하면 Service IP를 통해 Pod에 접근 가능
• Pod는 재생성될 때 IP가 변경되기 때문에 신뢰성이 떨어짐

Service의 종류는 3가지가 있음

1) ClusterIP

• 외부 (External)에서 접근 불가
• Cluster 내에서 접근 가능
• Service의 9000 포트로 요청이 들어오면 Pod의 8080 포트와 연결이 됨

• 하나의 Service에 여러개의 Pod를 연결시킬 수 있고 서비스가 트래픽을 분산해서 Pod에 전달해줌
• 활용: 인가된 사용자, 내부 대쉬보드, pod의 서비스상태 디버깅

Service yaml 파일

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    app: pod
    ports:
      - port: 9000 # Service port 
      - targetPort: 8080 # Service에 연결된 Pod port
		type: ClusterIP # default로 생략가능

Pod yaml 파일

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
labels:
  app: pod
spec:
  containers:
  - name: container
    image: tmkube/app
    ports:
    - containerPort: 8080

• Service yaml파일의 targetPort와 pod yaml파일의 containerPort가 같아야 함

2) NodePort

• 서비스에 clusterIP가 할당됨
• 쿠버네티스에 할당된 모든 Node에 똑같은 Port가 할당됨
• 외부에서 어떤 노드든 간에 접속이 되면 Service에 연결이 됨
• 서비스는 자신과 연결된 Pod에 트래픽을 전달

주의할점

• pod가 있는 node만 port가 할당되는게 아니라 모든 Node에 포트가 할당됨
• 활용: 내부망 연결, 데모나 임시 연결용

apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080
    nodePort: 30000 # 30000 ~ 32767
  type: NodePort

• externalTrafficPolicy: Local을 통해 각 Node에 속한 pod로 트래픽이 분산됨

3) Load Balancer (외부 시스템 노출용)

• NodePort의 성격을 그대로 가지고 있고 추가적으로 Load Balancer가 생김 (트래픽 분산)

• Load balancer에 접근하기 위한 외부 접속 ip주소는 별도로 할당하기 위한 플러그인 설치 필요

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080
  type: LoadBalancer

이 글은 책 컴퓨터 밑바닥의 비밀 chapter 6.5의 내용을 읽고 요약한 글입니다. 

6.5 mmap: 메모리 읽기와 쓰기 방식으로 파일 처리

코드에서 메모리를 읽기 쓰는 것은 아래와 같이 배열을 정의하고 값을 할당하기만 하면 됨

int a[100];
a[10] = 2;

하지만 파일을 읽는 경우는 상대적으로 더 복잡

char buf[1024];

int fd = open("/filepath/abc.txt");
read(fd, buf, 1024);
// buf 등을 이용한 작업

• 운영체제에 파일에 접근할 수 있는 파일 서술자를 요청 후 파일의 정보를 읽을 수 있음

파일을 사용하는 것이 메모리를 사용하는 것보다 복잡한 이유

1. 디스크에서 특정 주소를 지정(addressing)하는 방법과 메모리에서 특정 주소를 지정하는 방법이 다름
2. CPU와 외부 장치 간 속도에 차이가 있음

파일에 대해 메모리처럼 직접 디스크의 파일을 읽고 쓸 수는 없을까?

6.5.1 파일과 가상 메모리

• 사용자 상태에서 메모리는 하나의 연속된 공간이고, 디스크에 저장된 파일도 하나의 연속된 공간
• 두 공간을 연관 짓는 방법은? → 가상 메모리
• 가상 메모리의 목적은 모든 프로세스가 각자 독점적으로 메모리를 소유하고 있다고 생각하게 하는 것
• 프로세스가 만나는 주소 공간은 가상이기 때문에 ‘수작을 부려’작업할 수 있는 공간이기도 함
• 파일은 개념적으로 연속된 디스크 공간에 저장되어 있다고 생각할 수 있으므로 이 공간을 프로세스 주소 공간에 직접 mapping할 수 있음
  • 길이가 200바이트인 파일을 프로세스 주소 공간에 매핑한 결과로 파일이 600~799 주소 범위에 위치하고 있다고 가정하면, 이 주소 공간에서 바이트 단위로 파일을 처리할 수 있음

6.5.2 마술사 운영 체제

• 600~799 범위의 주소 공간을 읽을 때, 대응하는 파일이 아직 메모리에 적재되지 않아 페이지 누락(page fault) 인터럽트가 발생할 수 있음
• 이후 CPU가 운영 체제의 인터럽트 처리함수를 실행하며, 실제 디스크 입출력 요청이 시작
• 파일을 메모리로 읽고 가상 메모리와 실제 메모리의 연결이 수립되면 프로그램에서 메모리를 읽고 쓰듯이 직접 디스크의 내용을 사용할 수 있음
• mmap을 사용하더라도 실제로 디스크를 읽고 써야 하기는 하지만 이 과정은 운영체제가 진행함
• 또한 가상 메모리를 경유하기 때문에 고수준 계층에 있는 사용자는 신경쓸 필요 없음

6.5.3 mmap 대 전통적인 read/write 함수

• read/write 함수 같은 입출력 함수는 저수준 계층에 시스템 호출을 사용함 → 파일을 읽고 쓸 때 데이터를 커널 상태 ↔ 사용자 상태로 복사해야 해서 큰 부담을 수반
• mmap은 디스크의 파일을 읽고 쓸 때는 시스템 호출과 데이터 복사가 주는 부담이 없음. 하지만 커널은 프로세스 주소 공간관 파일의 mapping 관계를 유지하기 위해 특정 데이터 구조를 사용해야 하며 이 역시 성능에 부담을 가져옴
• 이외에 page fault 문제가 있어 인터럽트가 발생하면 이에 상응하는 인터럽트 처리 함수가 실제로 파일을 메모리에 적재해야 함

⇒ mmap 과 read/write 함수의 성능 비교를 할 때 실제 구체적인 상황에서 각각의 방식에 대한 부담을 비교하여 선택해야 함

6.5.4 큰 파일 처리

• 큰 파일이란 물리 메모리 용량을 초과할 정도의 크기를 가진 파일을 의미
• 전통적인 read/write 함수를 사용하면 파일을 조금씩 나누어 메모리에 적재해야 하며, 파일의 일부분에 대한 처리가 끝나면 다시 다음 부분에 대한 처리를 하는 방식으로 너무 많은 메모리를 요청하면 OOM 문제가 발생할 수 있음
• mmap을 사용하면 가상 메모리의 도움하에 프로세스 주소 공간이 충분하다면 큰 파일 전체를 프로세스 주소 공간에 직접 mapping할 수 있으며 해당 파일의 크기가 실제 물리 메모리의 크기보다 크더라도 아무 문제 없음
• mmap을 호출할 때 매개변수가 MAP_SHARED 라면 사상된 영역의 변경 내용은 디스크의 파일에 직접 기록됨. 시스템은 작업중인 파일의 크기가 물리 메모리의 크기보다 큰지 전혀 관심 없음
• 매개변수가 MAP_PRIVATE 인 경우, 시스템이 실제로 메모리를 할당한다는 의미로 물리 메모리의 크기에 교환 영역(swap area)의 크기를 더한 크기가 기준이 됨

6.5.5 동적 링크 라이브러리와 공유 메모리

• 동적 링크 라이브러리의 경우 이를 차조하는 프로그램이 아무리 많더라도 실행 파일에는 라이브러리의 코드와 데이터가 포함되지 않음
• 라이브러리를 참조하는 모든 프로그램이 메모리에 적자되더라도 동일한 동적 라이브러리를 공유하므로 디스크와 메모리의 공간을 절약할 수 있음

mmap으로 해당 라이브러리를 사용하는 모든 프로세스의 주소 공간에 직접 mapping할 수 있는데 여러 프로세스는 모두 해당 라이브러리가 자신의 주소 공간에 적재되었다고 생각하지만, 실제 물리 메모리에서 이 라이브러리가 차지하는 공간은 한개 크기일 뿐임.

이 글은 책 컴퓨터 밑바닥의 비밀 chapter 6.4의 내용을 읽고 요약한 글입니다. 

6.4.1 파일 서술자

• 모든 입출력 작업은 파일 읽기와 쓰기로 구현할 수 있음

read 함수를 이용해 파일 내용을 읽을 때 아래와 같이 사용하는데 어디에서 데이터를 읽는가?

read(buffer);

• 유닉스/리눅스 세계에서 파일을 사용하려면 번호를 필요로하는데 이를 파일 서술자(file descriptor)라고 함. 즉 파일 서술자는 숫자에 불과
• 프로그래머는 파일 서술자라는 숫자를 통해 입출력을 처리할 수 있음
• 파일이 디스크에 저장되어있는지, 디스크는 어느 위치에 저장되어 있는지 등의 정보를 운영체제가 대신 처리하므로 프로세스는 이를 신경쓸 필요없음

char buffer[LEN];
int fd = open(file_name); // 파일 서술자 얻기

read(fd, buffer);

6.4.2 다중 입출력을 어떻게 효율적으로 처리하는 것일까?

• 높은 동시성이란 서버가 동시에 많은 사용자 요청을 처리할 수 있음을 의미
• 웹 서버에서 3way handshake에 성공하면 accept 함수를 호출하여 연결을 얻을 수 있고, 추가로 파일 서술자도 얻을 수 있음. 파일 서술자로 사용자와 통신을 진행

// accept 함수로 사용자의 파일 서술자 획득
int conn_fd = accept(...);

• 서버의 처리 작동 방식은 일반적으로 먼저 사용자 요청 데이터를 읽고, 이에 따라 특정한 처리를 실행

if(read(conn_fd, buff) > 0)
{
	do_something(buff);
}

• read 함수는 일반적으로 블로킹 입출력인데 높은 동시성을 위해서는 파일 서술자 수천수만 개를 처리해야 함
• 다중 스레드를 생각할 수 있지만 이 방법은 스레드 수가 너무 많아질 수 있고 스레드의 스케쥴링과 전환에 너무 많은 부담이 가해지므로 최적의 방법이 아닐 수 있음

6.4.3 상대방인 아닌 내가 전화하게 만들기

• 여러개의 파일 서술자에 대해 읽고 쓸 수 있는지 매번 체크하는 것이 아니라 관심 대상인 파일 서술자를 커널에 알려주고, 커널에 대신 감시하다가 읽고 쓸 수 있는 파일 서술자가 있을 때 알려주면 처리하겠다고 이야기 하는 것 ⇒ 입출력 다중화(input/output multiplexing) 기술

6.4.4 입출력 다중화

• 다중화(multiplexing)라는 용어는 사실 통신 분야에서 많이 사용되는데 통신 선로를 최대한 활용하기 위해 하나의 채널에서 여러 신호를 전송할 수 있어야 함 → 여러 신호를 하나로 합칠 필요가 있음. 여러 신호를 하나로 합치는 장치를 다중화기(multiplexer)라고 함
• 이 신호를 수신하는 쪽에서는 합쳐진 신호를 다시 원래의 여로 신호로 복원해야 하는데 이 장치를 역다중화기(demultiplexer)라고 함

입출력 다중화는 아래 과정을 의미

1. 파일 서술자를 획득. 서술자 종류는 상관없음
2. 특정 함수를 호출하여 커널에 다음과 같이 알림. ‘이 함수를 먼저 반환하는 대신, 이 파일 서술자를 감시하다 읽거나 쓸 수 있는 파일 서수자가 나타날 때 반환해주세요’
3. 해당 함수가 반환되면 읽고 쓸 수 있는 조건이 준비된 파일 서술자를 획득할 수 있으며 이를 통해 사응하는 처리를 할 수 있음

이 기술로 여러 입출력을 한꺼번에 처리할 수 있음. 리눅스에서는 입출력 다중화 기술을 사용하는 방법에 3가지가 있음

6.4.5 삼총사: select, poll, epoll

• 본질적으로 select, poll, epoll은 모두 동기 입출력 다중화 기술
• 이런 함수가 호출될 때 감시해야 하는 파일 서술자에서 읽기/쓰기 가능 같은 관심 대상 이벤트가 나타나지 않으면 호출된 스레드가 블로킹되어 일시 중지되고, 파일 서술자가 해당 이벤트를 생성할 때까지 함수는 반환되지 않음

select

• 감시할 수 있는 파일 서술자 묶음에 제한이 있으며 일반적으로 1024개를 넘을 수 없음
• select가 호출될 때 대응하는 프로세스 또는 스레드는 감시 대상인 파일의 대기열에 배치되므로 select 호출로 브로킹되며 일시 중지 됨
• 파일 서술자 중 하나라도 읽기 가능 또는 쓰기 가능 이벤트가 나타나면 해당 프로세스 또는 스레드가 다시 깨어남

→ 문제는 프로세스가 깨어났을 때 프로그래머는 어떤 파일 서술자가 읽고 쓸 수 있는지 알 수 없어, 준비완료 상태의 팡리 서술자를 알기 위해 처음부터 끝까지 다시 확인해야 함. 대량의 파일 서술자를 감시할 때 효율이 매우 떨어지는 근본적인 원인

poll

• select와 매우 유사하지만 최적화된 점은 감시 가능한 파일 서술자 수가 1024개 이상이라는 것
• 하지만 select와 마찬가지로 파일 서술자 수가 늘어날수록 성능이 저하되는 문제가 있음

epoll

• 커널에 필요한 데이터 구조를 생성하며 준비 완료된 파일 서술자 목록을 가짐
• 감시되고 있는 파일 서술자에서 관심 이벤트가 발생하면 해당 프로세스를 깨우면서 준비 완료된 파일 서술자가 준비 완료 목록에 추가 됨
• 프로세스와 스레드에서 모든 파일 서술자를 처음부터 끝까지 확인할 필요 없이 준비완료된 파일 서술자를 직접 획득할 수 있는데 이는 매우 효율적