Transport Layer
트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 애플리케이션 프로세스간의 논리적 통신(logical communication)을 제공합니다. 논리적 통신은 애플리케이션 관점에서 보면 프로세스들이 동작하는 호스트들이 직접 연결된 것처럼 보인다는 것을 의미합니다. 또한 트랜스포트 계층은 프로토콜은 네트워크 라우터가 아닌 종단 시스템에서 구현됩니다. 트랜스포트 계층 세그먼트라고 알려진 트랜스포트 계층 패킷으로 변환되어 네트워크 계층 패킷(데이터그램) 안에 캡슐화되어 목적지로 전달됩니다.(라우터는 데이터그램 안에 캡슐화된 트랜스포트 계층 세그먼트의 필드를 검사하지 않습니다.)
이 후 수신 애플리케이션의 트랜스포트 계층에서 세그먼트 내부의 데이터를 이용할 수 있도록 수신된 세그먼트를 역캡슐화합니다.
다중화(Multiplexing)와 역다중화(Demultiplexing)
목적지 호스트에서의 트랜스포트 계층은 바로 아래의 네트워크 계층으로부터 세그먼트를 수신하고 호스트에서 동작하는 해당 애플리케이션 프로세스에게 이 세그먼트의 데이터를 전달하는 의무를 가집니다. 네트워크 애플리케이션의 한 부분으로서 프로세스는 소켓(socket)을 가지고 있는데 이 소켓은 네트워크에서 프로세스로 데이터를 전달하고 프로세스로부터 네트워크로 데이터를 전달하는 출입구 역활을 합니다. 트랜스포트 계층은 실제로 데이터를 직접 프로세스로 전달하지 않는 대신 중간 매개자인 소켓에 전달합니다. 각각의 소켓은 하나의 유일한 식별자의 포맷을 통해 소켓이 UDP 소켓인지 TCP 소켓인지에 따라 달라집니다.
수신 측의 트랜스포트 계층은 수신 소켓을 식별하기 위해 필드들을 검사하고 트랜스포트 계층 세그먼트의 데이터를 올바른 소켓으로 전달하는데 이런 작업을 역다중화라고 합니다. 반대로 출발지 호스트에서 소켓으로부터 데이터를 모으고 이에 대한 세그먼트를 생성하기 위해 각 데이터에 헤더 정보로 캡슐화하고 그 세그먼트들을 네트워크 계층으로 전달하는 작업을 다중화라고 합니다.
정리하자면 트랜스포트 계층 다중화에는 다음 두 가지 요구 사항이 있습니다.
- 소켓은 유일한 식별자를 갖습니다.
- 각 세그먼트는 세그먼트가 전달될 적절한 소켓을 가리키는 특별한 필드를 갖습니다.
이 특별한 필드라는 것은 출발지 포트 번호 필드(source port number field)와 목적지 포트 번호 필드(destination port number field)입니다.
각각의 포트 번호는 0~65,535 까지의 16비트 정수입니다. 그중에서 0~1023까지의 포트 번호를 잘 알려진 포트 번호(well-known port number)라고 하여 사용을 엄격하게 제한하고 있습니다. HTTP(80번), FTP(21번)처럼 잘 알려진 애플리케이션 프로토콜에서 사용되도록 예약 되어 있습니다.
비연결형 트랜스포트: UDP
UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작합니다. UDP는 다중화/역다중화 기능과 간단한 오류 검사 기능을 제외하면 IP에 아무 것도 추가하지 않습니다. 사실상 UDP로 통신한다는 것은 애플리케이션은 거의 IP와 직접 통신하는 셈입니다. UDP는 세그먼트를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 개체들 사이에 핸드셰이크를 사용하지 않기 때문에 UDP를 비연결형이라고 합니다.
다음은 UDP가 비연결형 트랜스포트로서 가지는 장점입니다.
- 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어:
- UDP: 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 UDP는 데이터를 UDP 세그먼트로 만들고 그 세그먼트를 즉시 네트워크 계층으로 전달합니다.
- TCP: 혼잡 제어 메커니즘을 통해 목적지/출발지 호스트들 사이에서 하나 이상의 링크가 과도하게 혼잡해지면 트랜스포트 계층 TCP 송신자를 제한합니다. 또한 데이터의 전달이 얼마나 오래 걸리는지에 관계 없이 목적지가 세그먼트의 수신 여부를 확은응답할 때까지 데이터 세그먼트 재전송을 계속합니다.
- 연결 설정이 없음: TCP는 세 방향 핸드셰이크(three-way handshake)를 사용하는 반면에 UDP는 공식적인 사전준비 없이 전송합니다. 그러므로 UDP는 연결을 설정하기위한 어떤 지연도 없습니다. 또한 HTTP 3.0 버전은 그간 사용하던 TCP 통신을 버리고 UDP를 채택했습니다. 정확히는 UDP를 기반으로 동작하는 QUIC(Quick UDP Internet Connection) 프로토콜을 채택했습니다.
- 연결 상태가 없음: TCP는 종단 시스템에서 수신 버퍼와 송신 버퍼, 혼잡 제어 파라미터, 순서 번호와 확인응답 번호를 파라미터로 포함하여 연결 상태를 유지합니다. UDP는 연결 상태를 유지하지 않으며 이 파라미터 중 어떤 것도 기록하지 않습니다. 이러한 이유로 일반적으로 특정 애플리케이션 적용 서버는 애플리케이션 프로그램이 TCP보다 UDP에서 동작할 때 일반적으로 좀 더 많은 액티브 클라이언트를 수용할 수 있습니다.
- 작은 패킷 헤더 오버헤드: TCP는 세그먼트마다 20 바이트의 헤더 오버헤드를 갖지만, UDP는 단지 8 바이트의 오버헤드를 갖습니다.
비록 오늘날 멀티미디어 애플리케이션을 UDP 위에서 동작시키는 방법이 일반적으로 사용되지만 아직 논의의 여지가 있습니다. 네트워크가 꼭 필요한 작업을 할 수 없게 되는 폭주 상태에서 빠지는 것을 막기 위해 혼잡 제어는 반드시 필요합니다. 그렇기 때문에 UDP의 혼잡 제어 결여는 UDP 송신자와 수신자 간의 높은 손실률을 초래할 수 도 있고 TCP 세션의 혼잡이 발생할 수 이씅며 이는 잠재적으로 심각한 문제점입니다. 이에 대한 대안으로 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공한다면 UDP를 사용할 때도 신뢰적인 데이터 전송이 가능합니다. 즉 애플리케이션 프로세스들은 TCP의 혼잡 제어 메커니즘에 의해 전송률 억제를 강요당하지 않고도 신뢰적으로 통신할 수 있습니다.
UDP 세그먼트 구조
UDP 세그먼트 구조는 RFC 768에 위와 같으 정의되어 있습니다. 애플리케이션 데이터는 UDP 데이터그램의 데이터 필드에 위치합니다. UDP 헤더는 2 바이트씩 구성된 단 3개의 필드만을 갖습니다. 포트 번호는 목적지 호스트가 목적지 종단 시스템에서 동작하는(역다중화 기능을 수행하는) 정확한 프로세스에게 애플리케이션 데이터를 넘기게 해줍니다. 체크섬(checksum)은 세그먼트에 오류가 발생했는지를 검사히기 위해 수신 호스트가 사용합니다.(체크섬은 UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산합니다.) 길이 필드는 헤더를 포함하는 UDP 세그먼트의 길이(바이트 단위)를 나타냅니다.
UDP 체크섬
UDP 체크섬은 출발지로부터 목적지로 이동했을 때 UDP 세그먼트안의 비트에 대한 변경사항이 있는지 검사하는 필드입니다. 송신자 측에서 UDP는 세그먼트 안에 있는 모든 16 비트 워드의 합산에 대해 다시 1의 보수를 수행하며 합산 과정에서 발생하는 오버플로는 윤회식 자리올림(wrap around)을 합니다. 이 결괏값이 UDP 세그먼트의 체크섬 필드에 삽입됩니다.
많은 링크 계층 프로토콜이 오류 검사를 제공하는데도 불구하고 UDP가 체크섬을 제공하는 이유는 출발지와 목적지 사이의 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문입니다. 즉 링크 중에서 하나가 오류 검사를 제공하지 않는 프로토콜을 사용할 수 도 있습니다. 주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지도 않고 종단 간의 데이터 전송 서비스가 오류 검사를 제공해야 한다면 UDP는 종단 기반으로 트랜스포트 계층에서 오류 검사를 제공해야하는 것입니다. 이는 종단과 종단의 원칙(end-end principle)의 한 예입니다.
해당 글은 컴퓨터 네트워킹 하향식 접근(James F. Kurose, Keith W. Ross)을 읽고 공부한 내용을 정리한 글입니다.
오탈자 및 오류 내용을 댓글 또는 메일로 알려주시면, 검토 후 조치하겠습니다.