반응형

개요

 소켓 서버를 만드는데 대표적인 방식들이 있다. 그것은 Window IOCP와 Linue epoll이다 두개의 개념을 알아보고, 각 특징을 알아보자.

 윈도우에서 제공하는 비동기 I/O 방법 중에 가장 뛰어난 방법인 I/O completion port (IOCP)가 있다.

 리눅스에서 제공하는 select보다 좋은 interrupt 방식인 epoll 방식이 있습니다.

 

Window IOCP

 다중 클라이언트 요청을 처리하기 위해서는, 시리얼 모델 보다는, 컨커런트 모델을 채택해서 앱을 구현했었다. 하지만, 컨커런트 모델을 사용하면서, 생각보다 성능이 잘 나오지 않았는 데, 그 이유는 동시에 많은 수의 요청이 들어올 경우에 동시에 많은 스레드를 생성되어서, 스레드들 간의 context switch 때문에 CPU시간이 낭비되기 때문입니다.

 이런점을 개선하기 위해, IOCP가 탄생하였습니다.

 

 시리얼 모델이란?  하나의 시레드로 사용자의 요청을 대기 및 수행 처리 (동시 사용자 요청이 들어오면, 다른 하나의 대기가 발생)

 컨커런트 모델이란?  요청이 들어올 때마다, 새로운 스레드를 생성해서 요청을 처리, 요청 작업이 완료되면, 새로 생성된 스레드 종료.

 

 먼저, IOCP는 IOCP 객체에 의해 관리됩니다. 또한, 이 객체는 커널 안에서 관리됩니다. (IOCP는 똑똑하게 관리되고 동작됩니다)

 그리고 IOCP는 멀티스레드 환경에서 동작합니다. 방식은, 콜백함수들을 멀티스레드에서 동시에 동작해서, 성능을 높입니다. (이것이 IOCP의 성능의 비결)

 

- 게임서버가 소켓이 수백개, 수천개를 동시에 처리하는데, IOCP 객체는 1개만 필요합니다. 그 이유는, IOCP 객체는 여러 소켓을 관리하는 자료구조, 컨테이너인 DEVICE LIST를 사용하기 때문입니다. 해당 소켓을 IOCP에 등록하고, 그렇게되면, DEVICE LIST에 등록이 됩니다. (우리는 이 DEVICE LIST에 등록된 소켓을 볼수도 건드릴 수도 없다.)

 (디바이스를 등록하는 방식)

 

- 스레드 풀을 통해 재사용할 수 있습니다. 즉, 스레드를 만들었다 지웠다 할필요가 없습니다.

 

 큐를 이용. SEND RECV하면 큐에 쌓이고, send 했을 떄, 네트워크 카드로 데이터가 전송됐다면 완료되는 겁니다. recv 기다렸

Linux epoll

select와 poll의 한계

- select를 사용하면 모든 OS에 범용적으로 사용할 수 있지만, 매번 fs set을 복사해줘야함 (read, write, error 최대 3개나)

OS 튜닝을 하지 않는 이상, 1024개 한계도 있고, 가장 비효율적인, max size만큼 반복해야 하는 문제가 있따.

 

- linux나 IBM AIX라면 poll 사용을 고려할 수도 있다, poll은 select의 단점인 복사와 한개치가 정해지지도 않았다.

다만, select의 bit array loop의 단점이 poll fd array loop로 변경되었을 뿐, 개선은 되지 않았다.

 

epoll의 등장

linux kernel 2.5.44에 처음 소개된, event 기반 multiplexing 함수인 epoll이 등장하게 됨.

말 그대로 select나 polling 방식이 아닌, interrupt (또는 evnet-driven) 방식이기 때문에, 이벤트 감지에 O(1) 성능을 보여준다.

 

window iocp와의 비교

http://www.slideshare.net/sm9kr/iocp-vs-epoll-perfor?qid=3c154372-42f3-4505-aa95-2cb21ab78984&v=qf1&b=&from_search=2

 

Windows IOCP vs Linux EPOLL Performance Comparison

Updated 20130618: Receive Side Scaling test I/O event notification model performance test Windows IOCP and Linux EPOLL

www.slideshare.net

 

 결론은, 근소하게 IOCP가 빠르고, CPU 점유율을 덜 먹으며, muti-core에서 분산처리가 잘된다.

 하지만, 글들과 짧은 경험을 조합했을 때, 여러가지 측면을 고려해서, 서버 방식을 정의해야한다.

 

 종종 window iocp와 비교를 많이한다. 한국에서, IOCP를 많이 쓰는 이유는, 인력 공급이 얼마나 수월하냐에서 발생했다. unix나 linux를 다루거나 공부하는 사람이 적어서 그렇다고 생각한다, (출처 4)에 따르면). 이런 상황에서, windows 개발자를 구하는게 훨씬 쉬울 것이다. 따라서, 이를 통해 익숙해진 client개발자를 server 개발자로 전향하기도 훨씬 쉬운 이유도 있다.

 

 

참고자료/출처

1)

https://popcorntree.tistory.com/80

 

2) [Window c++] I/O completion port (IOCP)

https://jungwoong.tistory.com/43

 

2)

https://1d1cblog.tistory.com/370

 

3) Practical difference between epoll and Windows IO Completion Ports (IOCP)

https://www.ulduzsoft.com/2014/01/practical-difference-between-epoll-and-windows-io-completion-ports-iocp/

 

4) epoll vs iocp

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=cestlavie_01&logNo=220892515318 

반응형