(1, 2, 3계층은 이전에 다뤘던 내용에 포함되어 있어 이번에는 4계층에 관해 좀 더 구체적으로 다뤄보고자 합니다.)
4계층은 Transport layer, 즉 전송층이라고 한다.
우선 전송층의 경우 논리적 연결이 종단-대-종단을 이루고 있으며 발신지 호스트의 전송층은 응용층으로부터 메시지를 받아 전송층 패킷으로 캡슐화한 후 목적지 호스트의 전송층에 논리적 연결(가상의 연결)을 통해 전송한다.
특히, 인터넷에는 여러 개의 전송층 프로토콜이 존재하며 주로 사용되는 프로토콜은 전송 제어 프로토콜(TCP, Transmission Control Protocol) 과 사용자 데이터그램 프로토콜(UDP, User Datagram Protocol)이 있다.
전송 제어 프로토콜(TCP)의 경우 데이터를 전송하기 전에 먼저 두 호스트의 전송층 사이에 논리적 연결을 설정하는 연결 지향(connection-oriented) 프로토콜이다.
이 프로토콜은 바이트들의 스트림 전송을 위해 두 TCP 사이에서 논리적인 파이프를 생성한다. TCP는 흐름 제어(Flow control, 목적지가 전송되는 데이터의 양을 감당할 수 없는 경우를 방지하기 위해 발신지 호스트의 데이터 송신율과 목적지 호스트의 데이터 수신율을 맞추는 것), 오류 제어(Error control, 오류 없이 목적지에 세그먼트들이 도달하고 훼손된 세그먼트들의 재전송을 보장하기 위해) 그리고 네트워크의 혼잡으로 인한 세그먼트들의 손실을 줄이기 위해 혼잡 제어를 제공한다.
사용자 데이터그램 프로토콜(UDP)은 처음에 논리적 연결을 설립하지 않고 사용자 데이터그램들을 전송하는 비연결형(connectionless) 프로토콜이다.
UDP에서 각 사용자 데이터그램은 이전이나 다음 데이터그램과는 관련이 없는 독립적인 하나의 개체이다(이 말인 즉슨, 비연결형임을 뜻한다.)
UDP는 흐름 제어, 오류 제어, 또는 혼잡 제어를 제공하지 않는 간단한 프로토콜이다. 이러한 단순성은 적은 양의 오버헤드를 의미하며, 패킷이 훼손되거나 손실되었을 때 짧은 메시지의 전송을 필요로 하고 TCP에 관련된 패킷들의 재전송을 감당할 수 없는 응용에 매력적이다.
그리고 새로운 프로토콜인 스트림 제어 전송 프로토콜(SCTP, Stream Control Transport Protocol)은 하루가 다르게 증가하는 멀티미디어를 위한 새로운 응용들을 위해 디자인 되었다.
자, 우선 UDP부터 좀 더 살펴보자.
사용자 데이터그램 프로토콜이라고도 불리는 UDP는 비연결이고, 신뢰성이 없는 전송 프로토콜이다. UDP는 호스트 간 통신 대신에 프로세스 간 통신을 제공하는 것을 제외하고는 IP 서비스에 어떠한 것도 추가하지 않는다.
그럼 UDP가 이렇게 기능이 없다면 왜 프로세스는 이것을 사용하려고 하는가?
UDP는 최소한의 오버헤드를 가진 매우 간단한 프로토콜이다.
만약 프로세스가 작은 메시지를 송신하기를 원하고, 신뢰성에 관하여 그다지 신경을 쓰지 않는다면 UDP를 사용할 수 있다.
UDP를 사용하여 작은 메시지를 송신하는 것은 TCP를 사용하는 것보다 송신자와 수신자 사이에 상호 작용이 훨씬 적다.
그럼, UDP에서 사용자 데이터그램은 무엇인가?
사용자 데이터그램이라고 부르는 UDP 패킷은 각각 2바이트(16비트)인 4개의 필드로 만들어진 고정된 크기의 8바이트 헤더를 가지고 있다.
그림에서 보면 알 수 있듯이 처음 두 필드는 근원지(Source)와 목적지(Destination) 포트 번호를 정의한다. 세 번째 필드는 헤더에 데이터를 더한 사용자 데이터그램의 전체 길이를 정의된다.
16비트는 전체 길이 0부터 65,536바이트를 정의할 수 있다.
(2^16 = 65,536이기 때문)
그러나 하나의 UDP 사용자 데이터그램은 65,535바이트의 총 길이를 가지는 IP 데이터그램에 저장되기 때문에 총 길이는 훨씬 작은 것을 요구한다.
그리고 마지막 필드는 선택적 검사합(Checksum)을 운반한다.
그렇다면 UDP가 제공하는 일반적인 서비스들로는 무엇이 있을까?
프로세스-대-통신
UDP는 IP 주소와 포트 번호의 결합인 소켓 주소(Socket address)를 이용하여 프로세스-대-프로세스 통신을 제공한다.
비연결 서비스
앞서 언급됐듯이 UDP는 비연결 서비스(Connectionless service)를 제공한다.
이것은 UDP에 의해 보내지는 각 사용자 데이터그램은 독립된 데이터그램이라는 것을 의미한다. 동일한 근원지 프로세스로부터 들어와서 동일한 목적지 프로그램으로 간다고 할지라도 사용자 데이터그램은 서로 관계가 없다.
사용자 데이터그램은 번호가 부여되지 않는다. 또한 TCP 경우와는 달리 연결 설정이나 연결 종료가 없다. 이것은 각 사용자 데이터그램은 서로 다른 경로로 이동할 수 있음을 의미한다.
흐름 제어 (제공하지 않음)
UDP는 매우 단순한 프로토콜이다. 흐름 제어(flow control)가 없고 따라서 윈도우 메커니즘이 없다. 수신자는 들어오는 메시지로 인하여 오버플로우가 발생할 수도 있다.
흐름 제어의 결여는 UDP를 이용하는 프로세스가 필요하다면 이러한 서비스를 스스로 제공해야만 함을 의미한다.
오류 제어 (제공하지 않음)
검사합(Checksum)을 제외하고는 UDP에는 오류 제어(error control) 메커니즘이 없다. 이것은 송신자는 메시지가 손실이 되었는지 또는 중복이 되었는지를 알 수 없음을 의미한다. 수신자가 검사합을 통하여 오류를 검출하였을 때는 사용자 데이터그램은 아무런 동작 없이 제거된다.
오류 제어의 결여는 UDP를 사용하는 프로세스가 필요하다면 이러한 서비스를 스스로 제공해야만 함을 의미한다.
검사합
UDP 검사합 계산은 의사헤더, UDP 헤더 그리고 응용층으로부터 들어오는 데이터의 세 영역이 포함된다.
의사헤더(pseudoheader)는 0으로 채워진 일부 필드들로 캡슐화되는 사용자 데이터그램에 있는 IP 패킷 헤더의 일부분이다.
검사합이 의사헤더를 포함하지 않는다면 사용자 데이터그램은 무사히 도착할 수 있다. 그러나 IP헤더가 손상된다면 잘못된 호스트로 전달될 수도 있다.
프로토콜 필드는 다른 전송층 프로토콜이 아닌 UDP에 속한다는 것을 확신시키기 위하여 덧붙여진다.
하나의 프로세스가 UDP 또는 TCP를 사용할 수 있다면 목적지 포트 번호는 동일할 수 있다는 것을 의미한다.
UDP를 위한 프로토콜 필드 값은 17이다. 이 값이 전송되는 도중에 변경된다면 수신측에서 검사합 계산이 이 값을 검출할 것이고, UDP는 그 패킷을 제거한다. 잘못된 프로토콜에는 전달되지 않는다.
UDP 패킷의 송신자는 검사합 계산을 하지 않는 것을 선택할 수 있다. 이 경우 검사합 필드는 전송되기 전에 모두 0으로 채워진다. 이런 상황에서 송신기가 검사합을 계산하기로 결정하면, 검사합이 전송되기 전에 모두 1로 변경되므로, 결과는 모두 0으로 발생한다. 다른 말로 송신기는 두 번에 걸쳐 합을 수행한다. 이것은 정상 상황에서 검사합의 값이 결코 모두 1이 되지 않으므로 혼란을 발생시키지 않는다.
이러한 UDP는 어떻게 응용할 수 있을까?
UDP의 응용
비록 UDP는 신뢰성 있는 전송층 프로토콜을 위해 이전에 언급했던 기준을 거의 하나도 만족하지 못하지만, UDP는 일부 응용을 위해 선호된다.
이유는 일부 서비스는 받아들일 수 없거나 혹은 선호되지 않는 부수적 효과를 가질 수 있기 때문이다. 때때로 응용 설계자는 최적에 맞추기 위해 타협할 필요가 있다.
예를 들면, 우리는 일상생활에서 모두 운송회사의 소화물이 1일 배송이 3일 배송보다 매우 비싸다는 것을 알고 있다.(응? 그런가?)
비록 화물 배달에서 고속과 저가가 모두 원하는 형태이기 하지만, 이들 각각은 충돌한다. 이때 최적의 선택이 필요하다.
자, 이러한 맥락(?)으로 UDP의 일부 사양과 이것의 장단점을 얘기하자면
이전에 언급했던 것처럼 UDP는 비연결 서비스(connectionless service)를 제공한다. 각 UDP 패킷이 동일한 응용 프로그램에 의해 전송되는 다른 패킷으로부터 독립적이다. 이 특징은 응용 요구조건에 따라 장점 혹은 단점으로 생각될 수 있다.
예를 들면, 이것은 클라이언트 응용이 서버로 짧은 요구를 전송하고 짧은 응답을 수신하는 경우는 장점이다.
만약 요구와 응답이 단일 사용자 데이터그램에 적합하다면, 비연결 서비스는 적합할 수 있다. 연결을 설정하거나 혹은 폐쇄하기 위한 오버헤드가 이 경우 중요할 수 있다.
연결 지향 서비스에서 위의 목적을 달성하려면, 클라이언트와 서버 사이에 최소한 9개의 패킷이 교환되어야 하는데, 비연결 서비스는 단지 2개의 패킷만 교환된다. 비연결 서비스는 적은 지연을 제공한다.
연결지향 서비스는 많은 지연을 생성한다. 만약 지연이 응용을 위한 매우 중요한 이슈라면, 비연결 서비스가 선호된다.
따라서, UDP의 일반적인 응용을 정리하자면 이와 같다.
UDP는 흐름 및 오류 제어를 하지 않는 간단한 요청-응답 통신을 요구하는 프로세스에 적당하다. 이것은 FTP와 같은 대량 데이터를 전송할 필요가 있는 프로세스를 위해서는 보통 사용되지 않는다.
UDP는 내부 흐름 및 오류 제어 기법을 가진 프로세스에 적당하다. 예를 들어 간단한 파일 전송 프로토콜(TFTP)은 흐름 및 오류 제어를 포함한다.
이것은 쉽게 UDP를 사용할 수 있다.
UDP는 멀티캐스팅을 위한 적당한 전송 프로토콜이다. 멀티캐스팅 능력은 TCP 소프트웨어가 아닌 UDP 소프트웨어 내부에 들어 있다.
UDP는 SNMP와 같은 관리 프로세스들을 위하여 사용된다.
UDP는 라우팅 정보 프로토콜(RIP)과 같은 경로 갱신 프로토콜을 위하여 사용된다.
UDP는 보통 수신 메시지의 영역 사이에 불평등한 지연을 인내할 수 없는 상호작용적 실시간 응용에 사용된다.
다음으로, 전송 제어 프로토콜(TCP, Transmission Control Protocol)이다.
전송 제어 프로토콜(TCP, Transmission Control Protocol)은 연결-지향, 신뢰성 있는 프로토콜이다. TCP는 연결지향 서비스를 제공하기 위하여 분명하게 연결 설정, 데이터 전송, 연결 해제 단계를 정의한다.
TCP는 신뢰성을 제공하기 위해 GBN과 SR 프로토콜의 결합을 사용한다.
이 목적을 달성하기 위해, TCP는 검사합(오류 검출을 위함), 분실 혹은 훼손된 패킷의 재전송, 누적 및 선택 확인응답, 그리고 타이머를 사용한다.
TCP는 프로세스-대-프로세스 통신으로 UDP처럼 포트 번호를 사용하여 프로세스 간 통신(process-to-process communication)을 제공한다.
스트림 전송 서비스(Stream Delivery Service)
UDP와 달리 TCP는 스트림 지향 프로토콜이다. UDP에서 하나의 프로세스(응용 프로그램)는 UDP에게 전달하기 위해 미리 정의된 경계를 가지는 메시지를 전송한다.
UDP는 자신의 헤더를 이 데이터에 첨가하고, 이를 IP에게 전달하여 전송하도록 한다. 프로세스로부터 오는 각 메시지는 사용자 데이터그램(user datagram)이라고 하며, 결국 하나의 IP 데이터그램이 된다. IP와 UDP는 데이터그램 사이의 어떤 관계도 알지 못한다.