// 제 목: 다중연결(multiple sockets) 서버의 구현방법 종류
// 작성자: 김영대( http://www.howto.pe.kr )
1) fork
.다중연결 네트워크 프로그래밍을 위한 것보다는 일반적인 시스템 프로그램에 사용되는 기법으로,
네트워크 프로그래밍에 확대시켜서 사용한것이다.
.하나의 클라이언트를 처리하다가 문제가 생겨도 해당 프로세스에게만 영향을 끼치므로 전체 서비스에
지장이 생길 염려가 줄고, 프로그래밍 역시 select, poll, thread 를 사용하는것에 비해서 간단하며
디버깅이 용이하다라는 장점이 있다.
.단점은 자식프로세스를 생성하는데 많은 시간과 자원이 소모되며(응답속도 저하), 어느정도 이상의
자식 프로세스를 생성시켰을 때 Unix 버전에 따라 다르지만 생성되는 프로세스의 수에 제한이 있다.
특히 httpd 와 같이 세션이 짧은(몇초이내) 경우는 문제 없지만 세션이 길다면 생성되는 프로세스의
수에 많은 제한이 있을것이다. 그리고 생성된 프로세스간의 내부 통신을 위해 IPC 사용이 불가피하여
IPC 로 인한 프로그램의 복잡도와 시스템콜 사용의 부하를 감당해야 한다.
2) select()
.fork 와 같이 자식프로세스를 생성하는 방법이 아닌 한 프로세스내에서 전부 처리되므로 프로세스
생성시 발생하는 부하를 줄일 수 있으며 IPC 를 사용할 필요가 없다.
.단점은 많은 socket connection 을 한 프로세스가 처리해야 하므로 하나의 request 처리동안 다를
request 들은 전부 대기해야 한다. 그러므로 request에 대한 처리가 빠른경우(예를들어 채팅)만
사용해야 한다. 무엇보다 가장 큰 단점은 select 는 기본적으로 FD_SET 의 각 비트를 체크하여
socket 에 이벤트가 발생했는지 검사하는데 이것의 길이가 1024 인것이 문제이다. 즉 하나의 FD_SET
은 1024 개수의 socket 만 처리할 수 있으므로 그 이상인 경우는 FD_SETSIZE 를 수정하여 갯수를
늘릴 수 는 있지만 FD_SETSIZE 는 표준 라이브러리를 수정하는 결과이므로 바람직하지 않다.
그러므로 1024 개수 이상인 경우라면 FD_SET 을 여러 개 사용하여 처리한다.
3) poll()
.select 와 비슷하다. 다른점이라면 select의 FD_SET의 1024 제한이 없으며 select 에서는 3가지
event를 검사하지만 poll 은 6가지의 event 를 검사할 수 있다. 단점은 socket 개수만큼 poll
구조체를 만들어야 하므로 메모리 낭비가 select() 에 비해 심하다. 성능은 select() 보다는 좋다
4) thread
. PTHREAD_SCOPE_PROCESS 와 PTHREAD_SCOPE_SYSTEM 의 사용에 따라 장단점이 많이 다르지만
많은 자원을 공유하여 IPC를 사용하지 않는 장점이 있다. 하나의 쓰레드가 잘못 동작하여 죽는경우
프로세스내의 모든 쓰레드가 영향을 받는다.
5) 비동기I/O 시그널(SIGIO)
. socket 에 비동기 I/O신호가 있을때 커널로부터 SIGIO 시그널을 받을 수 있도록 하는 방법이다.
signal(SIGIO, 시그널처리함수); 로 시그널처리함수를 지정한 후 fcntl(소켓, F_SETFL, O_SYNC); 로
소켓을 지정한다. 이것은 커널로부터 직접 시그널을 받으므로 이에 대한 반응을 빨리 할 수 있지만
여러 개의 socket에 대해 동시에 사용된다면 시그널(SIGIO) 발생후 시그널 처리함수가 호출될 때
어떤 소켓에서 발생했는지 알 수 없다는 단점이 있다. 이에 최근에는 시그널에 fd(file descriptor)를
실을 수 있는 Posix Real-Time 시그널이 연구되고 있다.
6) preforking
. 특별한 API 함수가 있는 것은 아니고 socket()->bind()->listen()->fork()->accept() 순서로 진행되어
동일한 IP/Port 로 fork() 한 여러 프로세스가 나누어(round robin) accept() 하는 방식이다
Apache 가 대표적인 구현사례로 성능면에서 월등하다. 하지만 BSD 계열들은 TCP/IP 커널에서
직접 round robin 으로 accept() 를 처리해 주지만 일반적인 UNIX 들은 lock(file lock, system wide
mutex lock) 을 사용하여 구현된다.
7) /dev/poll (Solaris 표준, Linux 는 patch 필요)
.Linux/Solaris 의 경우는 지원되나 다른 UNIX 들은 지원 불분명
8) Posix Real-Time Signal
.현재 연구 진행되는 기술
9) kqueue (FreeBSD 표준)
.FreeBSD 에만 구현되어 있으며 성능면에서 가장 월등하다
* 성능비교
On a 167MHz sun4u Sparc Ultra-1 running SunOS 5.7 (Solaris 7) Generic_106541-11:
pipes 100 1000 10000
select 151 - -
poll 470 676 3742
/dev/poll 61 70 92
On a 4X400Mhz Enterprise 450 running Solaris 8 (results contributed by Doug Lea):
pipes 100 1000 10000
select 60 - -
poll 273 388 1559
/dev/poll 27 28 34
On an idle 650 MHz dual Pentium III running Red Hat Linux 6.2 with kernel 2.2.14smp plus the /dev/poll patch plus Dave Miller's patch to speed up close():
pipes 100 1000 10000
select 28 - -
poll 23 890 11333
/dev/poll 19 146 4264
On a single processor 600Mhz Pentium-III with 512MB of memory, running FreeBSD 4.x-STABLE (results contributed by Jonathan Lemon):
pipes 100 1000 10000 30000
select 54 - - -
poll 50 552 11559 35178
kqueue 8 8 8 8
|
|
