동시 접속 처리는 연결당 실행 단위를 어떻게 둘지의 선택이다
`accept()`는 연결을 하나씩 꺼내지만, 그 뒤 처리 모델은 여러 가지입니다. 핵심 비교축은 격리, 메모리 비용, 컨텍스트 스위칭, 공유 자원 관리입니다.
fork
연결마다 프로세스
격리는 좋지만 생성 비용과 메모리 사용량이 큽니다.
thread
연결마다 스레드
프로세스보다 가볍지만 락과 공유 상태 관리가 필요합니다.
pool
고정 작업자에게 배분
생성 비용은 줄지만 큐 대기와 작업자 포화가 생깁니다.
event loop
준비된 소켓만 처리
많은 연결을 적은 실행 단위로 다루지만 논블로킹 설계가 필요합니다.
모델
강점
부담
적합한 상황
fork
장애 격리, 구현 단순
메모리와 프로세스 생성 비용
낮은 동시성, 강한 격리
thread
코드 흐름이 직관적
락, race, 컨텍스트 스위칭
중간 규모 블로킹 I/O
pool
자원 상한을 관리하기 쉬움
큐 지연, 긴 작업의 점유
요청 시간이 예측 가능한 서버
epoll
많은 idle 연결에 강함
상태 머신과 논블로킹 코드
채팅, 프록시, 실시간 연결
CPU 작업 연산이 길면 I/O 모델만으로 해결되지 않는다 별도 worker pool이나 큐로 무거운 작업을 분리합니다.
공유 상태 스레드는 공유가 쉬운 만큼 동기화가 필요하다 클라이언트 목록, 통계, 캐시 접근은 락 범위를 짧게 둡니다.
idle 연결 대기 시간이 길수록 event loop가 유리하다 대부분 기다리는 연결은 스레드를 하나씩 붙이는 방식이 비싸집니다.