소켓에서 발생하는 이벤트 - 발생 감지의 기준 level trigger와 egde trigger(1/2)

TCP로 연결된 두 지점은 소켓을 통하여 데이터를 전송하고 수신합니다. 소켓의 내부를 조금 더 들여다보면 데이터 전송을 위한 임시 공간이 존재하는데, Read Buffer, Write Buffer 입니다.


(1) Read Buffer: 원격으로부터 전송받은 데이터를 임시로 저장하는 공간입니다. 데이터를 수신하게 되면 임시로 이 공간에 저장합니다. 이 공간은 커널영역의 메모리입니다. 어플리케이션에서 소켓으로부터 읽기를 시도하면 이 버퍼로부터 데이터를 가져오는 동작을 수행합니다. (즉, 커널영역의 메모리 공간에서 유저모드의 메모리 공간으로 복사가 발생함)

(2) Write Buffer: 원격으로 데이터를 전송하기 전에 임시로 이 버퍼에 저장합니다. (이 공간도 커널영역의 메모리 입니다.) 어플리케이션에서 데이터 전송(send)를 수행하면 실제로는 이 버퍼에 데이터 쓰기 작업을 진행합니다. 네트워크 스택은 이 버퍼의 데이터를 전송함으로써 실제로 데이터 전달이 수행되는 것입니다.

소켓에서 발생하는 이벤트를 정의하는 것은 이 두 버퍼의 상태 변화를 의미하는 것입니다. 예를 들어, 어플리케이션에서 데이터를 수신(Read) 동작을 수행하기 위해서는 Read Buffer에 수신된 데이터가 존재한다는 것을 의미합니다. 어플리케이션에서 데이터의 전송(send)이 가능하다는 것은 Write Buffer에 여유공간이 있어서 데이터 쓰기 작업이 가능하다는 것을 의미합니다.

즉, 읽기 가능(Readable) 한가 또는 쓰기 가능(Writable)한가를 판단하는데 있어서 무엇을 기준으로 판단할 것인지 정하는 것인데, 단순히 버퍼의 데이터의 존재 유무가 판단 기준뿐만 아니라, 버퍼 공간의 변경 시점도 연관이 있습니다. 이 두가지지 기준이 level trigger, egde trigger 입니다.

두 트리커의 차이점은 소켓버퍼에 데이터가 있는 경우에 그것을 소켓 이벤트로 간주하는 기준입니다. 참고로 이벤트 감지에 사용되는 구현이 각 OS에 있습니다.

MS 윈도우: IOCP 
리눅스: epoll(구 버전 select, poll)
BSD Unix(FreeBSD): kqueue


레벨트리거(Level Trigger): 소켓버퍼에 데이터가 들어있으면 이벤트가 발생하는 트리거입니다. 즉, 소켓에서 read 할 수 있는 데이터가 1바이트 이상 있을때 이벤트가 발생했다고 리턴해줍니다. 여기서 1바이트라고 했지만 그 기준을 소켓옵션설정을 통해 조정할 수 있습니다. 이것을 조정하면 10바이트 이상일 경우에만 이벤트가 발생하는 것으로 기준을 설정할 수도 있습니다. (select(), poll() 등이 레벨트리거에 속함)

에지트리거(Edge Trigger): 소켓버퍼의 데이터가 들어오는 시점 자체가 트리거의 기준입니다. 소켓버퍼가 비어 있다가 상대방이 전송한 데이터가 수신 버퍼에 들어오면(또는 비어있지 않더라도 추가로 수신하면) 이때 이벤트가 발생한 것으로 트리거 됩니다. 소켓에서 수신한 데이터를 어플리케이션에서 read 했는지 여부는 무관합니다. 즉, 에지트리거에서 이벤트가 발생했고(데이터가 들어왔고), 어플리케인션에서 read 하지 않더라도 그 이후에 다른 데이터가 추가로 들어오면 에지트리거는 다시 이벤트가 발생했다고 리턴합니다. (epoll(), kqueue() 등이 에지트리거에 속함. 이것들은 설정에 따라 레벨트리거로도 사용할 수 있음.)

일반적으로.... 에지트리거가 대량의 접속시에 더 나은 응답속도((이벤트 트리거 감지가 빠름)를 제공합니다. 다만, 에지의 관리의 어려움으로 인해 레벨 트리거가 더 많이 사용되는 것 같습니다. 성능이 우수하다고 알려진 Redis도 레벨트리거를 사용하고, 레벨트리거를 사용함에도 불구하고 대부분의 요건에 만족할 만한 성능을 보여준다고 봐도 되겠네요.

Redis가 실제로 Level 트리거를 사용하는 것을 보여주는 실제 소스코드를 가져왔습니다.

epoll의 기본 트리거는 level 트리거이고, 아래 소스에서 50, 51 라인은 epoll_event ee 구조체의 events 필드에 EPOLLIN 또는 EPOLLOUT 만 지정되고, EPOLLET (Edge Triggered를 의미하는 플래그)가 사용되지 않고 있습니다.






이해를 돕기 위해서 그림하나 추가합니다. 아래 그림은 소켓 버퍼의 상태와 edge와 level를 표현합니다.





에지트리거를 다룰 때 주의점:
에지트리거를 통해 이벤트 받았고 read 작업을 해야하는데, 이 시점에 read 할 수 있는 모든 데이터를 read 해야합니다(즉, Read Buffer의 데이터를 모두 가져와야함). 왜냐하면, 에지트리거는 데이터 유입에 대한 이벤트이므로 추가로 데이터 유입이 없으면 이벤트가 오지 않으므로 이번 이벤트를 통해 read를 할 때 다음에 다시 이벤트가 온다는 보장이 없으므로 이 시점에 읽을 수 있는 모든 데이터를 read 해야만 정상적인 처리가 됩니다. 어플리케이션의 read 버퍼가 작아서 꽉찬 상태로 리턴되면 이것을 다른 버퍼에 저장해 두고, 나머지를 다시 소켓으로부터 read 해야한다. 더 읽을 것이 없을때까지 계속 read 해야 한다. 이번에 read를 모두 하지 않으면 영원히 다시 read할 이벤트가 오지 않을 수 있기 때문입니다. 이런 요소가 어플리케이션에서의 구현을 복잡하게 만드는 요소입니다.

참고문헌: Unix Network Programming (written by Stevens)

이 블로그의 인기 게시물

런드리고 4년의 회고

기억이 흐릿해지기   전에   런드리고(의식주컴퍼니)에서 있었던 4년의 회고를 적고자 합니다. 저에게 런드리고는 처음으로 스타트업이라는 곳을 경험하게 해준 곳이고 4년   동안   정말 훌륭한 동료들과 즐겁고 열정적으로 근무한 회사입니다. 저와 함께한 회사의 모든 동료들에게 감사함을 전합니다. 1. 채용 회사에 조인할 당시에 개발자 수는 한자리 숫자였어요. 앱 개발자, FE 개발자, BE 개발자 분포로 기술 스택은 Android Kotlin, iOS Swift, Frontend PHP, Backend Java-Spring, & Golang. 그리고, Kafka, Redis. 스타트업에서 좋은 개발자 채용은 어렵습니다. 이유도 명확합니다. 채용을 열어도 회사가 외부에 알려지지 않아 지원자가 많지 않고, 지원자의 역량(물론, 이력 내용으로만 판단)도 회사의 인지도와 비례하였습니다. 초기 스타트업이 채용에서 많이 사용하는 방식으로 지인 찬스가 있습니다. 물론, 이 방식에 대해서 장단점을 논하는 글을 본 적이 있지만, 지인 찬스 채용의 단점은 극복해야 할 문제이지 이 문제 때문에 사용하지 못할 이유는 없습니다. 저는 이 방식으로 채용했습니다. 운이 좋았습니다. 제가 과거에 같이 근무했던 훌륭한 시니어 개발자분들이 여러 명 조인해주셨어요. 스타트업으로 이직을 결정하는 여러 요소가 있는데, 그중에 하나가 회사가 어떤 사업을 하고 있느냐일 것입니다. 런드리고는 세탁 사업을 하고 있고, 세탁의 수요는 지속적입니다. 이 의미는 세탁 사업을 하는 회사의 전망은 밝을 것이라는 기대입니다. 이런 기대를 기반으로, 세탁은 어떤 문제를 해결해야 하는지, 개발을 통해서 해결할 수 있는지을 도전할 수 있다면 이는 개발자가 그 회사에 조인하게 만드는 중요한 요소입니다. 이제 중요한 요소 하나는 충족되었다고 보겠습니다. 다음은 어떤 사람들과 어떻게 일하느냐가 중요한 요소인데, 이것은 일종의 평판 조회와 유사한 것이고, 과거에 직접적인 동료였으니 이는 ...
Read more »

소켓에서 발생하는 이벤트 - 소켓에서 읽기와 쓰기(2/2)

  소켓으로부터 데이터의 읽기, 쓰기 작업은 데이터를 수신, 송신하는 동작입니다. 소켓의 특성에 따라 두 가지로 나눌 수 있는데, Blocking socket과 Non-Blocking socket 입니다. 어쩌면 Non-Blocking 소켓을 처음듣는 분이 계실지도 모르겠네요. 소켓 프로그래밍을 다룬다고 하면 Blocking 소켓을 의미하는 경우가 많습니다. 이제 두 가지 소켓 종류에 따라 읽기, 쓰기 작업의 구현이 어떻게 달라져야하는지 알아보겠습니다. Blocking 소켓 소켓에서 처리되기를 원하는 작업이 완료된 이후 함수가 반환되어 다음 작업이 수행됩니다. 예를 들어, 쓰기(send) 작업의 경우에 내가 전송하려는 데이터가 모두 전송되면 send() 함수가 리턴됩니다. Non-Blocking 소켓 소켓에서 현재 처리될 수 없는 작업이면 기다리지 않고 즉시 반환됩니다. 반환값에 따라 적절한 처리가 필요합니다. 읽기, 쓰기 함수의 동작을 구체적으로 알아보고 구현상 주의해야할 점에 대해서 적어보겠습니다. 1. 읽기작업(recv 함수) 수신 구현을 알아보기 전에 먼저 수신 버퍼의 존재를 이해 해야합니다. 앞의 블로그( 링크 )에서 설명한 Receive Buffer에 대한 설명을 가져왔습니다. ==== Receive Buffer: 원격으로부터 전송받은 데이터를 임시로 저장하는 공간입니다. 데이터를 수신하게 되면 임시로 이 공간에 저장합니다. 이 공간은 커널영역의 메모리입니다. 어플리케이션에서 소켓으로부터 읽기를 시도하면 이 버퍼로부터 데이터를 가져오는 동작을 수행합니다. (즉, 커널영역의 메모리 공간에서 유저모드의 메모리 공간으로 복사가 발생함) ==== Blocking Socket를 다룰 때,  recv() 함수의 동작은 아래와 같습니다. recv() 함수를 호출하는 시점에, (1)  Receive Buffer 에 수신된 데이터가 이미 있다면, 그 데이터를 가져온 후에 반환. (2)  Receive Buffer 가 비어있고 연결이...
Read more »