UDP.

UDP.

#1 Summary.

같이 공부하는 사람의 입장에서 거두절미하고 무조건 알아야겠다는 것만 설명하겠다. 대부분 나보다 이미 더 많은 지식을 가지신 분이 엄청 많을 것이고 그런 분들은 참고정도만 해주셨으면 좋겠다. 관련된 많은 개념들이 있는데 다른 글에서 다루도록 하겠다. OSI 7 Layer or TCP 4 Layer는 자세하게 볼 부분들이 있으니 다른 글에서 언급하도록 하겠다. 원래는 UDP랑 TCP를 같이 설명하려고 했는데 글이 너무 길어져서 가독성이 떨어진다고 생각해서 다음 글에서 TCP에 대해 언급하겠다.

#2 UDP.

UDP(User Datagram Protocol)의 약자이고 단어 뜻대로 해석해보면 사용자 데이터그램 프로토콜(규약)이라는 뜻인데 그냥 데이터를 데이터그램 단위로 처리하는 프로토콜로 알면 될 거 같다. 트랜스포트 계층의 통신 프로토콜의 하나로써 신뢰성이 낮고 완전성을 보증하지는 않으나 가상 회선을 굳이 확립할 필요가 없고 유연하며 효율적인 응용의 데이터 전송에 사용된다. 비연결형 서비스를 지원하는 전송 계층이고 좀 더 쉽게 말해 인터넷상에서 서로 정보를 주고받을 때 정보를 보낸다는 신호 or 받는다는 신호 절차를 거치지 않는다. 즉 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜이다. 또한 보내는 쪽에서는 받는 쪽이 데이터를 받았는지 받지 않았는지 확인할 수 없고, 또 확인할 필요가 없도록 만들어진 프로토콜이다.

CF) 데이터그램(DataGram) ==> 독립적인 관계를 지니는 패킷.

CF2) 패킷(Packet) ==> 인터넷 내에서 데이터를 보내기 위한 경로 배정, 즉 라우팅을 효율적으로 하기 위해서 데이터를 여러 개의 조각(Fragment)들로 나누어 전송하는데 이 조각을 의미.

#2-1 DataGram Packet Switching.

일단 패킷과 관련된 개념들이 정말 많기에 UDP랑 연관된 데이터그램 패킷 교환만 간단하게 설명하겠다. 데이터그램이란 위에서도 언급했지만 데이터를 전송하기 전에 논리적 연결이 설정되지 않으며 패킷이 독립적으로 전송되는 것을 의미한다. 패킷을 수신한 라우터는 최적의 경로를 선택하여 패킷을 전송하는데 1개의 메시지에서 분할된 여러 패킷은 서로 다른 경로로 전송될 수 있다.(위에서 말한 비연결성) 즉 보내는 쪽에서 전송한 순서와 받는 쪽에서 도착한 순서는 100% 맞는 것이 아니라 순서가 다를 수도 있다. 좀 더 패킷 방식이라던지 관련 개념들은 다른 글에서 자세하게 설명하겠고 일단 이정도만 알면 될 거 같다.

#3 UDP's Feature.

#3-1 비연결형(포트만 확인하여 소켓을 식별하고 송수신) 서비스로 데이터그램 방식을 사용한다.

#3-2 신뢰성이 낮다.

#3-3 오류 검출.(헤더에 오류 검출 필드를 포함해서 무결성 검사, 즉 UDP 헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.)

#3-4 DNS,NFS,SNMP,RIP 등에서 주로 사용한다.

#3-5 정보를 주고 받을 때 정보를 보내거나 받는다는 신호 절차를 거치지 않는다.

#3-6 TCP보다 속도가 빠르다.

#3-7 연속성이 중요한 스트리밍 같은 서비스에 주로 사용된다.

CF)오버헤드(Overhead) ==> 프로그램의 실행에서 나타나는 현상. 즉 프로그램 실행 도중에 떨어진 위치의 코드를 실행시켜야 할 때 추가적으로 시간,메모리,자원이 사용되는 현상. 예상치 못한 자원들이 소모되는 현상.

CF2)스트리밍(Streaming) ==> 인터넷을 바탕으로 사용자들에게 각종 멀티미디어 정보를 제공하는 기술.

#4 UDP Header.

위의 그림처럼 UDP 세그먼트는 8byte 헤더와 페이로드로 구성되어 있다. 

보내는 측의 포트와 받는 측의 포도는 종단점(End Point)의 식별 용도로 쓰인다. UDP 세그먼트가 도착하게 되면 받는 측에서는 세그먼트의 페이로드 부분을 받는 측 포트와 관련있는 프로세스로 넘기게 된다. 받게 된 세그먼트로부터 포트를 가져와 세그먼트 내의 목적지 포트에 복사를 하고 자신의 포트 번호 또한 세그먼트 내에 기입함으로써 보내는 측과 받는 측의 어떤 프로세스를 받아야 하는지를 결정해준다. UDP는 흐름 제어, 오류 제어 or 손상된 세그먼트 수신에 대한 재전송을 하지 않는다. 즉 모두 사용자 프로세스의 역할이다.

#4-1 Source Port Number ==> 출발지 포트 번호를 표시한다. 서비스에 따라 포트 번호가 정해져 있는 경우도 있지만, 대부분의 경우 처음 세그먼트를 보내는 측에서 임의의 번호를 사용한다.

#4-2 Destination Port Number ==> 목적지 포트 번호를 표시한다. 서비스에 따라 포트 번호가 정해져 있다.

#4-3 Total Length(UDP Length) ==> 8 byte 헤더와 데이터를 포함한 전체 길이를 나타낸다.

#4-4 CheckSum ==> 선택사항으로 계산되지 않는다면 0이 디폴트다.

CF) 세그먼트(Segment) ==> 세그먼트는 브릿지,라우터,스위치 등에 의해 묶여져 있는 네트워크의 한 부분.

CF2) 페이로드(Payload) ==> 데이터 전송에서 실제로 전송하고자 하는데 목적인 데이터 그 자체를 말한다. 즉 데이터 전송을 위해 포함되는 부가적인 CheckSum, Header 등을 제외한 실질적인 데이터를 의미.

CF3) 종단점(End Point) ==> 사용자에 의해 발생된 메시지를 발신 또는 착신하는 신호점.

CF4) 디폴트(Default) ==> 특정 값이나 설정 값이 지정되지 않았을 때 PC는 미리 정해져 있는 값이나 설정 값을 사용하게 되는 경우.

CF5) 체크섬(CheckSum) ==> 수신자(받는 사람)가 같은 수의 비트가 도착했는지를 확인 할 수 있도록 전송 단위 내의 비트 수를 세는 것. 계산이 맞으면 오류없이 원만하게 수신된 것으로 판단.

#5 UDP Server <=> Client.

일단 UDP 자체에는 연결 자체가 없다. 그렇기에 서버 소켓과 클라이언트 소켓의 구분이 없다. 연결의 개념이 존재하지 않기에 하나의 소켓으로 2개 이상(=다중)의 영역과 데이터 주고 받기가 가능하다. 쉽게 말해 서버와 클라이언트는 1<>1,1<>N, 2<>3 같이 연결될 수 있다는 것이다.아까 위에서 잠깐 언급했던 데이터그램,즉 메시지 단위로 전송되며 크기가 초과되면 쪼개서 보낸다. 흐름 제어가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.

CF) 서버(Server) ==> 소켓을 생성하고 주소를 할당한다. 연결을 요청하고 기다리고 요청에 대한 응답을 한다.

CF2) 클라이언트(Client) ==> 소켓을 생성하고 주소를 할당하며 연결을 요청한다.

CF3) 흐름 제어(Flow Control) ==> 호스트와 호스트 간의 데이터 처리를 효율적으로 하기 위한 기법이고 End to End이라고도 한다. 보내는 측과 받는 측의 데이터 처리 속도 차이를 해결하기 위한 기법이라고 할 수 있다. 흐름 제어 방식에는 Stop and Wait, Sliding Window 방식 등이 있다.

CF4) 혼잡 제어(Congestion Control) ==> 호스트와 네트워크 상의 데이터 처리를 효율적으로 하기 위한 기법이다. 즉 보내는 측의 데이터 전달과 네트워크 처리 속도 차이를 해결하기 위한 기법이라고 할 수 있다. 혼잡 제어 방식에는 Slow Start, Fast Recovery 방식 등이 있다.

#6 Wrong Idea For UDP.

#6-1 Type Of Error.

일단 오류 형태에는 간단히 말해 분실과 순서 변경이 있다. 분실은 데이터 순서 번호 기능을 제공하지 않기에 분실 여부를 확인할 수 없다. UDP는 분실 오류 복구 기능이 없어서 상위 계층이 스스로 분실을 확인하던가 아니면 순서 번호와 비슷한 기능을 프로그램 안에 만들어야 한다. 순서 변경은 순서 번호 기능이 없기 때문에 데이터그램 도착 순서 변경 오류를 해결하려면 UDP를 사용하는 응용 프로그램 안에 데이터 순서 번호 기능이 있어야 한다.

#6-2 MisUnderStanding.

UDP는 신뢰성 없는 데이터 전송을 하니까 데이터 오류를 확인하지 않을 것이라고 생각하면 오산이다. UDP는 TCP와 같이 체크썸(CheckSum)을 이용해 데이터 오류를 확인한다. UDP는 비신뢰성이라고 했는데 이상하다라는 의문이 들 것이다. UDP에서 데이터 재전송과 데이터 순서 유지 작업을 하지 않기 때문이다. UDP는 도착한 데이터에 오류가 있다고 판단을 하면 데이터를 응용 프로그램에 전달하지 않고 지워버린다. 그래서 응용 프로그램은 데이터에 오류가 있었는데 지워졌다는 사실을 기억하지 못한다. 참고적으로 TCP는 데이터 순서 유지를 위해 각 byte마다 번호를 부여하지만 UDP는 이와 같은 기능을 제공하지 않는다.

#7 How UDP Server<=>Client Works.

#7-1 UDP Server Client Model Case 1.

클라이언트는 데이터를 받은 후 보낸 사람의 주소(IP Address, Port Number)를 확인해야 한다. recvfrom() 함수는 UDP 서버가 보낸 데이터는 물론 전혀 다른 UDP 응용 프로그램이 보낸 데이터도 수신할 수 있기 때문이다. 일단 TCP 서버와 달리 UDP서버는 멀티스레드 등의 기법을 사용하지 않고도 하나의 소켓으로 여러 개의 클라이언트 처리가 가능하다.

#7-2 UDP Server Client Model Case 2.

[출처:http://neoyeop.tistory.com/entry/UDP-Server-Client]

UDP 클라이언트를 위 그림처럼 작성할 수도 있다. UDP 소켓에 대해 Connect() 함수를 호출하면 통신할 상대의 주소 정보가 내부적으로 기억되기에 Sendto() => Recvfrom() 함수 대신 Send() => Recv() 함수를 사용해서 특정 UDP 서버와 통신할 수 있다. Sendto() 함수를 사용한 경우보다 효율적이다. 왜냐하면 Connect() 함수로 서버 주소를 한 번만 설정해두면 Send() 함수가 이 정보를 재사용하기 때문이다. 데이터를 받은 후 보낸 측의 주소(IP Address, Port Number)를 확인하지 않아도 된다. Recvfrom() 함수와 다르게 Recv() 함수는 Connect() 함수로 설정한 대상을 제외한 다른 UDP 응용 프로그램이 보낸 데이터는 받지 않기 때문이다.

#7-3 Operation Principle Sequence.

1. 서버 실행 ==> 서버는 소켓을 생성하고 클라이언트가 데이터를 보내주기를 기다린다. 이 때 서버가 사용하는 소켓은 특정 포트 번호와 결합되어 이 결합된 포트 번호로 도착한 데이터만 수신한다.

2. 임의로 첫번째 클라이언트를 A라고 하고, A는 연결 설정 없이 서버와 데이터를 바로 주고 받는다.

3. 임의로 두번째 클라이언트를 B라고 하고, B도 연결 설정 없이 서버와 데이터를 바로 주고 받는다. 여러 번 언급했지만 UDP 서버는 하나의 소켓만 사용한다.

4. UDP 클라이언트 #n처럼 한 클라이언트가 소켓을 두개이상 사용해 서버와 통신할 수 도 있다.

CF) 멀티 스레드(Multi Thread) ==> 하나의 프로그램에 동시에 여러 개의 일을 수행할 수 있도록 해주는 것이고 쓰레드(Thread)는 프로세스 내에 일을 처리하는 세부 실행 단위.

#8 Typical UDP Data Transfer Functions.

위 UDP 서버 클라이언트 모델에서 볼 수 있는 함수들은 많이 있지만 그 중 대표적으로 알아야 되는 함수들에 대해서만 설명하겠다.

#8-1 Sendto() ==> 응용 프로그램의 데이터를 운영 체제, 즉 커널 내의 보내는 버퍼에 복사함으로써 데이터를 전송한다. UDP는 Sendto() 함수를 호출할 때 소켓을 지역 IP 주소와 지역 포트 번호가 아직 결정되지 않은 상황이라면 운영 체제가 자동적으로 설정해준다. Sendto() 함수로 보낸 데이터는 독립적인 UDP 패킷으로 만들어진 다음 전송되며, 받는 쪽에서는 Recvfrom() 함수 호출 한 번으로 Sendto() 함수가 보낸 데이터를 읽을 수 있다. 그래서 뒤에서 설명하겠지만 TCP와 달리 UDP는 응용 프로그램 수준에서 메시지 경계를 구분하는 것을 할 필요가 없다.

#8-2 Recvfrom() ==> 운영 체제의 받는, 즉 수신 버퍼에 도착한 데이터를 응용 프로그램 버퍼에 복사한다. 뒤에서 설명하겠지만 TCP에서의 Recv()와 다른 점은 UDP 패킷을 한 번에 1개만 읽을 수 있다는 점이다. 다시 말해 응용 프로그램 버퍼를 크게 잡는다고해서 많은 데이터를 동시에 읽을 수는 없다.

Related Link ==> http://dungmouse.tistory.com/