TCP UDP의 선택

 

네트워크 서버는 서비스를 제공하는 서버라는 특성 때문에 시작된 후에는 종료하지 않고

서비스를 요청하는 클라이언트에게 서비스를 제공합니다.

서버 프로그램의 이런 특성은 반복문을 통해서 구현되는데, 이런 특징은 TCP 기반의 서버

이든 UDP 기반의 서버이든 네트워크 서버라면 공통적으로 가지는 특징입니다.

 

TCP 서버와 UDP 서버가 가질 수 있는 중요한 차이중 하나는 TCP 서버는 거의 예외없이

Concurrent 서버이고, UDP 서버는 Iterative 서버일 때가 많습니다.

일반적으로 TCP 서버의 경우 동시에 여러 클라이언트를 서비스 하는 경우가 대부분이고,

클라이언트에게 제공하는 서비스의 시간도 상당히 깁니다. 대표적인 TCP 클라이언트인

telnet 이나 ftp등의 프로그램을 생각해보면 알 수 있습니다.

이를 구현하기 위해서 TCP 서버는 클라이언트의 요청이 있을 때 마다 별도의 Thread

Runnable 서비스 객체를 대응시켜 별도의 Thread로 하여금 클라이언트를 일대일로

서비스하게 합니다. 이런 모양이 가장 일반적인 TCP 기반 네트워크 서버의 구조입니다.

 

반면 UDP 기반의 서버는 Concurrent 서버 모델로 구성하지 않아도 됩니다.

클라이언트의 요청에 따라 별도의 Thread Runnable 서비스 객체를 만드는 행동을 하지

않아도 별 무리가 없다는 뜻입니다.

물론 TCP 서버처럼 클라인언트 요청이 있을 때 마다 별도의 Thread Runnable 서비스

객체를 만들어도 무방합니다. 다만 UDP 서버의 경우는 클라이언트 요청마다 별도의

Thread Runnable 서비스 객체를 만들어 대응하지 않아도 클라이언트의 서비스 요청을

처리하는데 무난한 경우가 많습니다.

이것은 UDP기반의 네트워크 프로그램들의 특성 때문입니다.

 

UDP 기반의 네트워크 프로그램의 특성은 아주 짧은 메시지를 읽고, 거기에 적절한 메시지

를 돌려주는 서비스가 대부분인데, 아주 짧은 시간에 서비스가 끝납니다.

대부분의 클라이언트가 오랫동안 서버와 연결되어 읽고,쓰는 TCP 기반의 서비스와는

차별됩니다. 이런 이유로 UDP 기반의 네트워크 서버는 Concurrent 서버로 구성하지 않고,

Iterative 서버로 구성해도 별 무리가 없을 때가 많습니다. 클라이언트 입장에서는

곧 자기 차례가 돌아와서 서비스를 받을 수 있기 때문입니다.

 

UDP 기반의 네트워크 프로그램의 대표적인 예는 DNS서버와 DNS 클라이언트입니다.

여러분이 웹브라우저에 DNS이름을 입력하면 우선 DNS이름에 대한 IP 주소를 찾습니다.

이런 행동을 하는 프로그램이 DNS 클라이언트이고, 이름은 Resolver라고 합니다.

Resolver DNS 서버에게 짧은 메시지(DNS Query)를 보내면 DNS 서버로부터 짧은 답변

메시지(DNS Response)가 옵니다.  그걸로 서비스 끝입니다.

UDP는 서비스 기간이 상당히 짧고, 가벼우며, 한번 요청 그리고 한번의 응답으로 끝나는

형태의 서비스에 적절합니다.

Concurrent 형태의 서버로 UDP 네트워크를 서버를 구성해도 좋지만, 클라이언트가

서비스를 받고 곧 사라지고, 다음 클라이언트가 서비스를 받을 수 있다면, 굳이 Concurrent

서버로 구성하지 않고, IterativeServer고 구성해도 무방합니다.

 

반면에 TCP기반의 대표적인 네트워크 프로그램인 telnet,ftp,mail등은 상당한 시간동안

지속적으로 클라이언트에게 서비스합니다. 이런 서비스를 제공하는 서버가 클라이언트의

요청마다 별도의 Thread Runnable 서비스 객체를 제공하지 않고 IterativeServer

구성돼 서비스를 한다고 생각해볼까요?

오전 일찍 ftp 서비스를 받고 있는 친구가 오후 늦게까지 동영상을 다운받고 있다면

그 사이에는 다른 ftp 클라이언트는 서버로부터 절대 ftp 서비스를 받을 수 없을 것입니다.

왜냐하면 서비스 Thread가 하나 뿐이기 때문이지요.

현재 서비스가 끝나야 다음 서비스를 해줄 수 있는 것이니까요.

 

네트워크 프로그램의 기본은 네트워크를 통한 읽고,쓰기입니다.

이런 관점에서 볼 때 TCP기반 프로그램이든 UDP기반 프로그램이든 네트워크를 통해 읽고,

쓰기를 한다는 관점에서는 동일하기 때문에 TCP 기반 프로그램으로 할 수 있는 모든 것을

UDP기반 프로그램으로 할 수 있습니다. 마찬가지로 UDP기반 프로그램으로 할 수 있는

모든 것을 TCP기반 프로그램으로 할 수 있습니다.

하지만 네트워크 프로그램이 크게 TCP기반 프로그램 , UDP기반 프로그램으로 나눠지는

가장 큰 이유는 TCP가 제공하는 서비스는 UDP가 제공하는 서비스 보다 질적으로 우월한

대신, UDP TCP 보다 매우 저렴하기 때문입니다.

 

네트워크 서버가 제공하는 서비스의 형태에 따라 TCP가 제공하는 수준의 서비스가 필요한

지를 판단해서 TCP가 제공하는 서비스가 꼭 필요하다면 TCP 기반 프로그램을 하고

그렇지 않으면 UDP 기반의 프로그램을 하는 것이 옳을 것입니다.

만약 TCP 기반으로 되어 있는 프로그램을 기어이 UDP 기반으로 다시 만든다고 한다면

TCP가 제공하는 서비스를 UDP는 제공하지 않으므로 프로그램을 만드는 개발자가 TCP

제공하는 수준의 서비스를 스스로 구현해 주어야 합니다.

, 네트워크를 통해서 읽고,쓰기를 할 때 데이타그램을 잃어 버릴수 있다는 생각,

읽고,쓸때 데이터그램의 순서가 뒤죽박죽일 수 있다는 생각등을 모두 반영해서 프로그램을

해야하기 때문에 엄청 힘들게 구현될 수 밖에 없습니다.

그리고 결국 그렇게 프로그램에 반영된 내용은 TCP가 제공하는 서비스를 프로그램 개발자

가 구현한 것과 별반 다르지 않을 것입니다.

다시 말하면 TCP가 제공하는 서비스를 사용하지 않고, 프로그램 개발자가 쓸데없이 TCP

제공하는 스스로 만들어 쓰는 겁니다. 시간이 아주 많거나 용쓰는 사람일 것입니다.

 

UDP기반의 프로그램을 TCP기반으로 만들게 되면 같은 기능을 구현하고 같은 서비스를

제공하는데 훨씬 비싼 값을 주고 하는 셈이 됩니다.

TCP를 사용하는 자원은 UDP를 사용하는 자원보다 훨씬 더 크고,비쌉니다.

왜냐하면 TCP 프로그램은 데이터를 한 비트라도 보내기 위해서는 TCP 연결을 한후에

한 비트라도 보낼수 있기 때문입니다. 더구나 언젠가는 TCP 연결을 해제해야 합니다.

이 연결을 해제하는 것도 부담입니다.

 

UDP 프로그램에서는 네트워크 연결이라는 개념이 없이 그냥 네트워크로 한 비트를

보내면 됩니다. TCP와 같은 오버헤드가 없으므로 UDP TCP보다 훨씬 빠르고 가볍습니다.

짧은 메시지를 주고 받는 프로그램이라면 특성상으로 살펴 볼 때 TCP기반의 프로그램보다

UDP기반 프로그램이 보다 효율적입니다.

 

이와 같이 TCP UDP는 각각의 장단점이 있어 TCP 프로그램과 UDP 프로그램은

네트워크 프로그램을 양분하고 있습니다.

네트워크를 통해서 읽고,쓰기를 할 때 TCP 혹은 UDP를 사용할 것이지는 제공하는 서비스

의 특성을 고려해서 선택하는 것이 옳습니다.

Posted by
,