[Computer network] Chapter 5 - Transport Layer : (TCP/UDP)

1. Transport Layer

Transport Layer는 Network Layer와 Application Layer 사이에 위치하여 프로세스 간 통신을 위해 매우 중요한 역할을 담당하고 있다. 이번 챕터에서 이에 대해 자세히 알아보도록 하자.

• Logical Connection at the Transport Layer : Transport Layer는 출발지와 목적지의 두 호스트가 직접 연결(논리적 연결)되도록 하는 기능을 제공한다. 이는 프로세스 간 통신이라고도 부른다.

  • 전송 계층은 네트워크 계층에서 서비스를 수신하고, 응용 계층에 서비스를 제공한다.

  • 출발지 호스트와 목적지 호스트의 프로세스 간 통신을 제공하여, 논리적 연결을 형성한다.

  • 데이터 신뢰성을 위한 여러 프로토콜(대표적으로 TCP)을 사용한다.

  • 오류 제어 / 흐름 제어 등의 기능이 전송 계층에서 구현된다.

• Network Layer vs Transport Layer

  • Network Layer : 네트워크를 통해 데이터(패킷)이 전달되도록 지원한다.

    • 라우터는 네트워크 계층까지만 구현되어 있다.

    • Internet Protocol(IP)를 사용하는 계층이다.

  • Transport Layer : 두 호스트의 프로세스 간 연결을 지원한다.

    • 라우터는 전송 계층을 포함하지 않는다.

    • TCP/UDP를 사용하는 계층이다.

• Port Number : 데이터가 올바른 프로세스에 도달하기 위해 포트 번호가 사용된다. OS에서 프로세스 관리를 위해 pid를 사용하듯이, 네트워크에서 프로세스 관리를 위해 포트 번호를 사용한다.

  • IP 주소는 데이터가 전달 될 특정 호스트를 지정한다면, 포트 번호는 호스트 내에서 데이터가 전달 될 특정 프로세스를 지정한다.

    • IP와 Port Number 두 요소 모두 올바른 데이터 전달을 위해 필수적이다.

    • Socket Address = IP Address + Port Number

  • 호스트의 네트워크 계층에 도달한 데이터 패킷은 역캡슐화 과정에서 IP 주소가 제거되며 전송 계층으로 전달된다.

  • 전송 계층은 Port Number를 확인하고, 적절한 프로세스로 데이터를 전달한다.

  • 잘 알려진(자주 사용되는) Port Number들

1-1. Pushing and Pulling

• Pushing and Pulling

  • Pushing : 소비자의 상태를 고려하지 않고 데이터를 전달하는 방식이다.

    • 소비자가 데이터를 받을 수 있는 상태인지 여부를 고려하지 않고 데이터를 전송하므로 데이터 손실 가능성이 존재한다.

    • 소비자가 생산자에게 흐름 제어 메시지를 보내 데이터 전송 속도(량)를 조절한다.

    • 흐름 제어 메커니즘이 반드시 필요하지만 링크 활용률이 높다.

  • Pulling : 소비자의 상태를 고려하여 데이터를 전달하는 방식이다.

    • 소비자가 데이터를 받을 수 있는 상태인 경우에만 생산자에게 데이터를 요청한다.

    • 생산자는 데이터 전송을 요청을 받아야만 데이터를 전송한다.

    • 흐름 제어 메커니즘은 필요없지만, 링크 활용률이 떨어진다.

• Flow Control and Error Control : 전송 계층에는 흐름 제어와 오류 제어를 위한 메커니즘이 존재한다.

  • 흐름 제어 : 수신측이 처리 가능한 수준으로 송신측과 수신측 사이의 데이터 전송 속도를 조절하는 메커니즘이다.

  • 오류 제어 : 데이터 전송 중 발생할 수 있는 오류를 감지하고 이를 수정하는 메커니즘이다.

2. Transport Layer protocols

전송 계층 프로토콜은 두 가지 유형의 서비스(연결 지향 서비스, 연결 없는 서비스)를 제공한다. TCP는 대표적인 연결 지향 프로토콜이며, UDP는 대표적인 비연결 지향 프로토콜이다.

• TCP/UDP : 전송 계층에 위치한 프로토콜이다. TCP는 연결 지향, UDP는 비연결 지향 프로토콜이다.

• Connetionless Service (비연결 지향 서비스) : 송신측과 수신측 사이에 별도의 연결 과정 없이 데이터를 전송할 수 있다.

  • 각 패킷은 독립적으로 전송되므로, 패킷은 서로 다른 경로를 통해 이동할 수도 있다.

    • Jitter가 발생 가능하다. 따라서 송신측의 패킷 전송 순서와 수신측의 패킷 수신 순서가 다를 수 있다.

  • 오류 감지/수정 메커니즘이 없다.

  화상 채팅과 같이 패킷 도착 순서가 중요하지 않지만 실시간 통신이 중요한 환경에 적합하다.

• Connection Oriented Service (연결 지향 서비스) : 데이터 전송 전에 송신측과 수신측 사이의 논리적 연결을 설정하고, 데이터 전송이 완료되면 연결을 해제하는 전송 방식이다.

  • 각 패킷은 독립적으로 전송되지만, 도착한 패킷의 순서가 바뀌더라도 이를 처리하기 위한 메커니즘이 포함되어 있다.

    • 데이터 전송의 신뢰성을 보장하는 메커니즘이 존재한다.

    • 데이터의 무결성을 보장하는 메커니즘(오류 감지/수정)이 존재한다.

  파일 전송과 같이 데이터의 무결성이 중요한 환경에 적합하다.

2-1. Simple Protocol

• Simple Protocol : 패킷 전송 과정에서 오류가 발생하지 않고, 송신측의 패킷 전송 속도와 수신측의 패킷 처리 속도가 균형을 이룬 이상적인 환경을 전제로 한 프로토콜이다.

  • 완벽히 이상적인 환경이므로, 흐름 제어나 오류 제어 기능이 필요없다.

  • 매우 단순하지만, 현실적으로 실현 불가능한 프로토콜이다.

2-2. Stop and Wait Protocol

• Stop and Wait Protocol : 송신자는 패킷을 전송하고, 수신자로부터 확인 응답(Acknowledgment, ACK)을 받을 때까지 대기하는 방식으로 데이터 전송이 이루어진다.

  • 오류 감지 메커니즘이 포함(체크섬)되어 있다.

  • 패킷이 전송 과정에서 손실된다면 Deadlock이 발생할 수 있다.

    • 이를 방지하기 위해 Timer를 세팅한다.

    • 타임 아웃이 발생할 경우 오류가 발생했다고 판단하고 마지막으로 보낸 패킷을 재전송한다.

    Timer는 적당한 값으로 설정해야 하지만, 패킷 전송 및 수신에 걸리는 시간은 고정적이지 않기에(특히 Queueing Delay) 쉽지 않은 문제이다.

• Flow Diagram

  • 송신측 : 한번에 하나의 패킷을 전송하고, 수신측이 해당 패킷을 제대로 수신하였다는 응답 메시지(ACK)를 보낼 때까지 대기한다.

  • 수신측 : 패킷을 받은 뒤 오류 검출 과정을 거치며, 정상적으로 패킷을 받았다면 송신측에 ACK 메시지를 보낸다.

  • 타임아웃이 발생할 경우, 오류가 발생했다고 간주하며 마지막으로 보낸 패킷을 재전송한다.

데이터 전송 무결성을 보장하지만, 일방 통신 방식이기 때문에 링크 활용률이 매우 떨어진다.

2-3. Go Back N Protocol

• Go Back N Protocol (GBN) : Stop and Wait에 Sliding Window를 추가한 방식이다. 수신측의 ACK 응답을 기다리는 동안에도 패킷을 전송할 수 있으며, ACK를 수신한 패킷과 수신하지 못한 패킷을 구분하는 메커니즘이 포함되어 있다.

  • Sliding Window : 송신측이 정해진 윈도우 크기 $n$만큼의 패킷을 ACK 수신 여부와 관계 없이 전송하도록 지원한다.

    • ACK를 수신하지 못한 패킷과 ACK를 수신한 패킷을 구분하며, ACK를 수신한 패킷은 재전송하지 않는다.

    • 모든 패킷이 ACK를 수신하지 못한 경우, 타임아웃이 발생할 때 해당 패킷들을 전부 재전송한다.

• Flow Diagram

  • 송신측 : ACK 메시지 수신 여부와 관계 없이 전송이 준비된 패킷을 정해진 Window 크기만큼 보낸다.

    • ACK 메시지가 도착한다면, 해당 번호에 해당하는 패킷이 Base 패킷이 되며, 보낼수 있는 패킷의 개수가 증가한다.

  • 수신측 : 패킷 수신 후, 순서가 맞는 패킷에 대해서만 ACK 응답을 보낸다.

    • ACK 메시지에는 다음에 받아야 할 패킷 번호가 포함되어 있다.

연속적으로 패킷을 전송한 뒤, 손실된 패킷부터 전부 재전송하는 방식이므로 재전송에 필요한 오버헤드가 크지만 Stop and Wait에 비해 링크 활용률이 높다.

2-4. Selective Repeat Protocol

• Selective Repeat Protocol (SR) : GBN은 패킷 손실이 자주 발생하는 환경에서 재전송 오버헤드가 크다. 이러한 한계를 해결하기 위해, SR 프로토콜은 오류가 발생한 패킷만을 재전송하도록 설계되었다.

  • 송신측은 Send Window, 수신측은 Receive Window가 존재한다.

    • 두 윈도우의 크기는 동일하다.

    • 수신측은 순서가 맞지 않는 패킷도 전부 버퍼에 저장한다.

  • 송신측은 어떤 패킷에 오류가 발생했는지 정확히 파악할 수 있으므로, 해당 패킷만 재전송하면 된다.

• Flow Diagram

  • 송신측

    • 패킷을 전송하고, 수신측으로부터 ACK를 받으면 해당 패킷을 윈도우에서 제거한다.

    • 타임 아웃이 발생하면, 오류가 발생한 패킷만 재전송한다.

  • 수신측

    • 순서에 맞게 수신한 패킷은 어플리케이션으로 전송한다.

    • 순서에 맞지 않게 받은 패킷은 전부 버퍼에 저장한다.

    • 수신한 패킷에 대한 ACK 메시지를 송신측으로 전송한다.

    • 송신측은 오류가 발생한 패킷을 정확히 파악할 수 있으므로, 해당 패킷만 재전송한다.

버퍼를 활용해 오류가 발생한 패킷에 대한 정보를 송신측에 전달할 수 있으므로, 재전송에 따른 오버헤드를 줄일 수 있고 링크 활용률이 좋지만, 버퍼 관리를 위한 오버헤드가 발생한다.

2-5. Bidirectional Protocol

• Bidirectional Protocol : 위에서 소개한 네 가지 프로토콜은 모두 단방향 통신 방식이지만, 일반적으로 통신은 양방향이다. 따라서, 이번에는 양방향 통신 프로토콜에 대해 알아보도록 하자.

  • Piggybacking : 양방향 통신을 지원하기 위해, 데이터와 ACK 메시지를 한 패킷에 결합하여 전송하는 기법이다.

    • 데이터 패킷과 ACK 패킷을 결합하여, 데이터 전송과 ACK 메시지 전송을 동시에 처리한다.

    • 클라이언트는 데이터 번호와 서버로부터 받은 마지막 ACK의 번호를 결합한 패킷을 전송한다.

    • 서버또한 데이터 번호와 클라이언트로부터 받은 마지막 ACK의 번호를 결합한 패킷을 전송한다.

양방향 통신 방식이므로 단방향 통신 방식에 비해 링크 효율성이 높다.

3. User Datagram Protocol (UDP)

• User Datagram Protocol : UDP는 비연결형 프로토콜로 신뢰성 있는 데이터 전송을 보장하지 않지만, 매우 단순한 구조를 갖기 때문에 오버헤드가 적다. 따라서 주로 실시간 전송이 필요한 애플리케이션 환경에서 사용된다.

  • Connectionless (비연결 지향) : 데이터 전송 과정에서 별도의 연결 설정이 없다.

  • Unreliable (신뢰성 미보장) : 패킷 손실, 순서 변경 등을 감지하거나 수정하는 메커니즘이 없으므로, 데이터 전송의 신뢰성을 보장하지 않는다.

  • Minimized Overhead : 단순한 구조이므로, 데이터 전송 과정의 오버헤드가 매우 적다.

• User Datagram (UDP Packet) : UDP 패킷은 다음과 같은 구조를 가지며, IP 패킷에 포함되어 전송된다.

  • Header : 8바이트로 크기가 고정됨

    • 2바이트로 크기가 고정된 4개의 필드로 구성

  • Data : $(8 \sim 65,535)bytes$ 크기의 데이터를 담고있는 필드이다.

• 예제 : 16진수로 표현된 UDP Header 해석

  • What is the source port Number?

    • 출발지 포트 번호는 첫 번째 4개의 16진수 숫자(2바이트)

    • 따라서 $CB84_{16}$

  • What is the destination port Number?

    • 목적지 포트 번호는 출발지 포트 번호의 다음 2바이트

    • 따라서 $000D_{16}$

  • What is the total length of the user datagram?

    • total length는 목적지 포트 번호 다음 2바이트

    • 따라서 $001C_{16}$

  • What is the length of the data?

    • Data length = total length - 8(header length)

    • 따라서 $001C_{16} - 0008_{16} = 0014_{16}$

  • Is the packet directed from a client to a server or vice versa?

    • 질문의 요지는, 위 패킷이 Client to server인지, Server to client인지를 묻는 것이다.

    • 목적지 포트 번호 13은 Daytime 서비스에 해당되는데, 이는 주로 서버에서 사용된다.

    • 따라서 Client to server UDP Packet이라고 유추할 수 있다.

  • What is the client process?

    • Daytime service

• UDP Checksum : UDP에서는 IP Header와 UDP Header의 정보들을 합쳐 IPv4 PseudoHeader(IPv4 가상 헤더)를 만든 뒤 체크섬 계산을 진행한다.

  • IPv4 헤더의 체크섬 계산 방식과 동일하다.

    • 가상 헤더의 필드를 16비트 단위로 모두 더하여 합계를 구한다.

    • 발생한 carry bit은 가장 오른쪽 4비트에 더해준다.

    • 최종 결과에 1의 보수를 취해준다.

  • 가상 헤더는 실제로 전송되는 헤더는 아니며, 체크섬 계산에만 사용된다.

• UDP with Application : TCP는 오버헤드가 매우 큰 프로토콜이다. 따라서 주어진 환경에 따라 TCP/UDP 중 선택하여 프로토콜을 적용하는 것이 중요하다. 아래 사례들을 살펴보자.

  • DNS : DNS는 한 방향으로 하나의 메시지를 전송하고, 반대 방향에서 응답을 받는 단순한 통신 과정을 거치며, 특정 요청에 대한 응답이 중요하기 때문에 메시지의 순서가 중요하지 않다. 따라서 오버헤드가 적고 속도가 빠른 UDP를 사용하는 것이 적합하다.

  • SMTP : SMTP는 주로 전자메일에 사용되는 서비스인데, 이런 환경의 경우 User가 메일에 Text 외에도 여러가지 데이터(이미지, 오디오, 비디오...)를 포함할 수도 있다. 만약 UDP 방식을 사용한다면, 메일이 여러 패킷으로 나누어져 전송될 것이다. 이중 일부 패킷의 순서가 바뀐다거나, 손실될 경우 해당 파일은 심각하게 손상될 가능성이 높다. 따라서 TCP 방식을 사용하는 것이 적합하다.

  • File download : 인터넷에서 어떤 파일을 다운로드 받을 때 UDP 방식을 사용한다고 생각해보자. 데이터는 여러 패킷으로 나누어져 서버에서 전송될 것이고, 클라이언트가 수신하는 과정에서 일부 패킷이 손실되거나 순서가 변경될 경우 이 파일은 심각하게 손상될 가능성이 높다. 따라서 TCP 방식을 사용하는 것이 적합하다.

  • Skype : Skype와 같은 실시간 대화형 어플리케이션은 어떨까? 오디오, 비디오와 같은 데이터가 패킷으로 나누어져 순차적으로 전송될 것이다. 만약 패킷이 손실되거나 순서가 바뀌는 등의 문제가 발생하였을 때, 이를 재전송한다면 오히려 어플리케이션 실행 흐름이 방해받을 것이다. 이러한 실시간 통신이 중요한 어플리케이션의 경우, 오버헤드가 적은 UDP를 사용하는 것이 적절하다.

4. Question

• What is the basic operation of transport layer?

  • Answer : Flow control, Error Control

• What is difference between UDP and TCP?

  • Answer

    • UDP는 비연결 지향 프로토콜이며, 데이터 전송 무결성을 보장하지 못하지만 구조가 단순하고 전송 속도가 빠르기 때문에 실시간 데이터 전송이 필요한 어플리케이션 환경(예를 들면, 화상 채팅)에서 적합하다.

    • TCP는 연결 지향 프로토콜이며, 데이터 전송 무결성을 보장하지만 UDP에 비해 구조가 복잡하고 데이터 처리에 들어가는 오버헤드가 크다. 따라서 데이터 손상이 발생하면 심각한 문제가 되는 환경(예를 들면, 파일 다운로드)에서 적합하다.

• Which one is better, UDP and TCP?

  • Answer : 두 프로토콜의 장단점을 고려하여 어플리케이션의 특성과 작동 환경에 맞게 선택하는 것이 중요하다.