[Network #2] Blocking VS non-Blocking

 

---

(1) Blocking

 

- 조건 만족이 되지 않는다면 함수는 리턴하지 않고 해당스레드는 Wait State를 만족하게 되면서, 애플리케이션은 더이상 진행되지 않는다.

 

- 예를 들어, 블로킹 소켓을 사용한 서버라고 가정하는 경우, 서버의 역할상 동시다발적으로 복수의 클라이언트가 접속하여 서비스를 이용하는데, 블록킹 소켓을 사용하면 순차적으로 클라이언트의 접속을 받아들여 작업하고 해당 작업이 완료돼야 다음 접속에 대한 작업을 할 수 있다.

 

- 이를 해결하기 위해 멀티쓰레드 방식을 이용한다. 각 클라이언트마다 각 쓰레드를 하나씩 생성하는 것이다.

 

- 하지만, 운영체제마다 스레드의 갯수가 제한되어 있으며, 제한된 스레드보다 많은 클라이언트가 접속할시 문제가 발생(가용성 부재). 또한, 스레드가 작동되기 위해서는 Context Switching이 계속 발생하게 되어 계속적으로 성능이 하락되어 나중에는 스레드의 사용 의미가 사라지게 됨.

 

(2) non-Blocking

 

- 소켓 함 호출시 조건이 만족되지 않더라도 함수가 리턴하므로 해당 쓰레드는 계속 진행이 된다.

 

- 한 개의 스레드에서 여러 클라이언트의 작업을 번갈아가면서 작업을 하기 위한 모델임(이벤트 방식과 흡사)

 

- 읽을 데이터가 있으면 읽고, 없으면 넘어가는 방식이다. (따라서 소켓에 읽을 데이터가 있는지 없는지 계속 확인해줘야 함(polling). 이는 busy-waiting을 일으켜 CPU를 많이 점유하게 되는 문제를 일으킬 수 있다.

 

- Busy Waiting은 적절히 sleep 함수를 사용하거나 Multiplexing을 이용하는 방법함으로써 해결할 수 있다.

**Multiplexing: 하나의 소켓마다 하나의 스레드를 할당하는 것이 아니라, 다수의 소켓을 하나의 스레드 내에서 동시에 확인할 수 있도록 하는 것(대표적으로 select 함수가 있음)

 

 

 

---

 

**만약에 서버가 대량의 클라이언트를 받아들이고 안정적인 서비스를 하고자 하는 경우라면?

 

- 만약 Blocking & MultiThreading 방식을 선택한다면, 스레드 갯수와 Context Switching과 관련된 단점이 있는 반면에 프로그램을 제작하기가 상대적으로 쉽다.

 

- 하지만, 대량의 클라이언트이기 때문에 가용성이나 성능 부분을 위해 non-Blocking 방식을 채택하는 것이 더 좋겠다.

 

- 물론, non-Blocking도 병목현상이 발생하는 지점에서는 스레드를 사용해줭 하는 부분이나 속도가 그다지 빠르지 않는 부분은 고려 대상이 될 수 있다.