File descriptor

파일 디스크립터를 학습하기 앞서, 과정의 이해를 돕는 네 가지 핵심 용어를 간단하게 정의하겠습니다.

파일 디스크립터 (File Descriptor, FD):

• OS 커널이 관리하는 열린 파일이나 소켓 같은 자원(resource)에 부여하는 0 이상의 정수 값입니다.

  • 커널이 열려 있는 파일이나 소켓 같은 자원을 식별하기 위해 부여하는 0 이상의 정수.

• 복잡한 커널 내부의 자원을 '대기 번호표'처럼 단순한 숫자로 추상화하여, 애플리케이션이 쉽게 자원을 제어할 수 있게 해주는 핸들(handle)입니다.

• 즉, 프로세스 관점에서는 특정 자원을 가리키는 참조 값입니다.

소켓 (Socket):

• 네트워크 통신의 창구로, 네트워크 통신을 위한 엔드포인트(endpoint). 커널 레벨에서 관리되는 통신 관련 데이터 구조체입니다.

• IP 주소와 포트 번호로 식별되는 통신의 종착점(Endpoint)으로, 프로세스는 이 소켓을 통해 네트워크로 데이터를 보내거나 받을 수 있습니다.

시스템 콜 (System Call):

• 사용자 영역(User-space)에서 실행되는 애플리케이션이 커널 영역(Kernel-space)의 기능을 사용하기 위해 호출하는 공식적인 인터페이스입니다.

• socket(), bind(), accept() 와 같은 함수들이 대표적인 시스템 콜입니다.

I/O 멀티플렉싱 (I/O Multiplexing):

• 단일 프로세스/스레드에서 여러 개의 I/O 작업을 동시에 처리하는 기술입니다.

• select, poll, epoll(Linux), kqueue(BSD) 등이 대표적입니다.

파일 디스크립터는 어떻게 생성되는가?

새로운 파일 디스크립터가 생성되는 과정은 애플리케이션의 요청과 커널의 내부 작업이 맞물려 진행됩니다.

1단계: 리스닝 소켓 준비

애플리케이션 서버는 클라이언트의 연결을 받기 위해서 다음과 같은 시스템 콜을 순서대로 호출합니다.

1. socket(): 커널에 소켓 생성을 요청합니다.

   • 커널은 내부에 소켓 구조체를 만들고, 이를 가리키는 첫 번째 파일 디스크립터를 애플리케이션에 반환합니다. (e.g., fd = 3)

   • 즉, 커널은 요청을 수락하고 소켓을 생성한 뒤, 해당 소켓을 가리키는 파일 디스크립터를 반환합니다.

2. bind(): 생성된 소켓에 특정 IP 주소와 PORT 번호를 바인딩합니다.

   • 이 소켓은 ‘192.168.1.10:8080’ 주소에서만 사용할 겁니다.’ 라고 소켓에 특정 주소와 포트를 바인딩합니다.

3. listen(): 소켓을 리스닝 상태로 전환합니다.

   • 이 함수 호출을 통해 커널은 이 소켓을 통해 들어오는 연결 요청을 받아들일 준비를 합니다.

이때 생성된 fd = 3은 리스닝 소켓(Listening Socket)의 파일 디스크립터(FD)입니다.

이 FD의 역할은 오직 연결 요청을 받는 것이지, 실제 데이터를 주고받는 용도가 아니라는 점입니다.

• ⭐️ 실제 데이터 통신에 직접 사용되지 않습니다.

2단계: 연결 수립 (TCP Handshake) - 커널의 역할

클라이언트가 서버의 IP와 포트로 연결 요청(SYN 패킷)을 보내면, 이때부터는 커널이 네트워크 연결 수립의 전 과정을 전담합니다.

• 커널은 SYN 패킷을 수신하고 SYN-ACK로 응답하며, 클라이언트의 마지막 ACK를 받아 TCP 3-Way Handshake를 완료합니다.

• 이 과정 동안 listen()을 호출한 서버 애플리케이션은 아무런 알림도 받지 않습니다. 커널이 모든 과정을 독립적으로 처리하여 연결을 완전히 수립합니다.

  • 연결에 성공하면 커널은 연결 정보를 리스닝 소켓에 할당된 completed connection queue에 추가합니다.

3단계: 새 파일 디스크립터의 생성 (accept)

애플리케이션 서버는 보통 accept() 시스템 콜을 호출하여 블로킹(blocking) 상태로 대기합니다.

• 애플리케이션 서버는 accept를 호출 후에 잠들고, 커널에게 연결 완료 큐에 새로운 연결이 들어오면 ‘알려줘’라고 요청합니다.

• 즉, accept는 커널이 서버 애플리케이션에게 ‘새 연결 도착’을 알려주는 신호라 볼 수 있습니다.

커널이 큐에 새로운 연결이 있음을 확인하면, accept() 호출에 응답하기 위해 다음 작업을 수행합니다.

1. 큐에서 가장 먼저 대기하던 연결 정보를 꺼냅니다.

2. 연결 정보를 가지고 connection을 위한 새로운 통신용 소켓(connected socekt) 구조체를 커널 메모리에 생성합니다.

3. 생성한 새로운 소켓을 가리키는 파일 디스크립터를 할당(생성)합니다.

   • 프로세스의 파일 디스크립터 테이블에서 비어있는 가장 작은 번호를 할당합니다.

4. 이 새로운 파일 디스크립터 번호를 애플리케이션에게 반환합니다.

위와 같이 데이터 통신에 사용될 FD는 애플리케이션이 직접 만드는 것이 아니라, 연결 요청을 받은 커널이 만들어서 accept()의 반환값으로 애플리케이션에 건네주는 것입니다.

• 서버는 fd=3(리스닝 소켓)으로는 계속 새로운 클라이언트를 수립하고, fd=4(연결 소켓)으로는 연결된 클라이언트와 데이터를 주고받습니다.

효율적으로 FD 관리하기

수많은 클라이언트 요청이 들어오면 이에 대응한 파일 디스크립터가 생성됩니다. 서버는 어떤 클라이언트가 데이터를 보냈는지 알기 위해서는 FD들을 계속 확인해야 하고 모든 FD들을 순회하면서 ‘데이터 왔니?’라고 묻는 것은 매우 비효율적일 것입니다.

이때 I/O 멀티플렉싱 기술인 epoll이 사용됩니다.

1단계: epoll_create()

• 애플리케이션(서버 프로세스)이 시스템 콜을 호출하여 커널에 epoll 인스턴스를 만들어 달라고 요청합니다.

• 이 epoll 인스턴스는 감시할 FD 목록을 담는 공간입니다.

2단계: epoll_ctl()

• 애플리케이션이 accpet()로 받은 FD를 epoll 인스턴스에 등록하기 위해 시스템 콜을 호출합니다.

• 즉, ‘이 FD에서 읽을 데이터가 생기면 알려줘’라고 커널에 요청하는 것입니다.

3단계: epoll_wait()

• 역시 애플리케이션이 시스템 콜을 호출합니다.

• 애플리케이션은 ‘이벤트가 발생할 때까지 대기하겠습니다.’라고 커널에 알리고 블로킹 상태에 들어갑니다.

• 커널은 이벤트가 발생하는 경우 애플리케이션을 깨워 FD 정보를 반환해주고, 애플리케이션은 이를 처리합니다.

이렇게 서버는 수만 개의 FD를 직접 관리할 필요 없이 특정 FD로 데이터가 수신되면 커널이 이를 감지하고, epoll_wait()에서 대기 중인 애플리케이션을 깨워 이벤트가 발생한 FD 목록만을 정확히 알려줍니다.

애플리케이션은 그 FD들에 대해서만 I/O 작업을 처리하면 되므로, CPU 낭비 없이 효율적으로 여러 연결을 처리할 수 있습니다.

정리

파일 디스크립터의 생성 과정을 보면, 역할이 매우 명확하게 분리되어 있음을 알 수 있었습니다.

• 연결을 받는 책임 (리스닝 소켓): 오직 새로운 연결을 수락하는 데만 집중합니다.

• 데이터를 통신할 책임 (연결 소켓): 각 클라이언트와의 실제 통신을 전담합니다.

• 연결을 중재하고 자원을 할당할 책임 (커널): 네트워크 handshake를 처리하고, 요청에 따라 파일 디스크립터를 생성하여 애플리케이션에 전달합니다.

FD의 생성 및 관리 과정을 요약하면 다음과 같습니다.

1. 준비: 서버 애플리케이션은 리스닝 소켓을 미리 준비합니다.

2. 연결: 연결 요청과 수립(Handshake)는 커널이 전담하여 처리합니다.

3. 생성: 연결이 완료되면, 애플리케이션의 accpet() 호출에 대한 응답으로 커널이 새로운 통신용 FD를 생성하여 반환합니다.

4. 관리: 생성된 FD를 어떻게 관리할지는 서버의 아키텍처에 따라 달라집니다. 고성능 서버의 경우, FD를 epoll과 같은 I/O 멀티플렉싱 도구에 등록하여 최소한의 자원으로 여러 연결을 효율적으로 처리하는 방식을 선택합니다.