TCP와 UDP

1. 전송 계층 프로토콜의 이해

네트워크 통신에서 데이터는 여러 계층을 거쳐 전송됩니다. 이 중 전송 계층(Transport Layer)은 애플리케이션 간의 종단 간(end-to-end) 통신을 담당하며, 데이터의 신뢰성, 흐름 제어, 혼잡 제어 등을 관리합니다. 전송 계층의 대표적인 프로토콜로는 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)가 있습니다. 이 두 프로토콜은 각각 다른 특성과 목적을 가지고 설계되었으며, 애플리케이션의 요구사항에 따라 적절히 선택되어 사용됩니다.

2. TCP (Transmission Control Protocol)

TCP는 연결 지향적(Connection-Oriented)이며 신뢰성 있는(Reliable) 데이터 전송을 제공하는 프로토콜입니다. 데이터를 정확하고 순서대로 전달하는 것을 목표로 하며, 이를 위해 다양한 메커니즘을 사용합니다.

2.1. 이론적 배경 및 주요 특징

• 연결 지향성 (Connection-Oriented): 데이터 전송에 앞서 송신자와 수신자 간에 논리적인 연결을 설정합니다. 이 연결은 '3-Way Handshake' 과정을 통해 이루어지며, 데이터 전송 후에는 '4-Way Handshake'를 통해 연결을 해제합니다.
• 신뢰성 (Reliability): 데이터 손실, 중복, 순서 바뀜 없이 정확하게 전달되도록 보장합니다. 이를 위해 다음과 같은 메커니즘을 사용합니다.
  • 순서 번호 (Sequence Number): 각 TCP 세그먼트에 순서 번호를 부여하여 수신자가 데이터를 올바른 순서로 재조립할 수 있도록 합니다.
  • 확인 응답 (Acknowledgement Number): 수신자는 데이터를 성공적으로 수신했음을 송신자에게 알리는 확인 응답(ACK)을 보냅니다.
  • 재전송 (Retransmission): 송신자는 일정 시간 내에 확인 응답을 받지 못하거나, 중복된 확인 응답을 받으면 해당 데이터를 재전송합니다.
  • 체크섬 (Checksum): 데이터 손상 여부를 확인하기 위해 체크섬을 계산하고 검증합니다.
• 흐름 제어 (Flow Control): 송신자가 수신자의 처리 속도보다 빠르게 데이터를 보내는 것을 방지하여 수신 버퍼 오버플로우를 막습니다. '슬라이딩 윈도우(Sliding Window)' 메커니즘을 사용하여 수신자가 처리할 수 있는 데이터 양을 조절합니다.
• 혼잡 제어 (Congestion Control): 네트워크의 혼잡으로 인해 데이터 손실이 발생할 경우, 송신 속도를 줄여 네트워크 혼잡을 완화합니다. '느린 시작(Slow Start)', '혼잡 회피(Congestion Avoidance)', '빠른 재전송(Fast Retransmit)', '빠른 회복(Fast Recovery)' 등의 알고리즘을 사용합니다.
• 전이중 통신 (Full-Duplex): 송신자와 수신자가 동시에 데이터를 주고받을 수 있습니다.
• 바이트 스트림 서비스 (Byte Stream Service): 애플리케이션에게 바이트 스트림 형태로 데이터를 제공하며, 세그먼트 경계에 대한 개념은 애플리케이션에 노출되지 않습니다.

2.2. 내부 구조 및 구현 방식

2.2.1. TCP 헤더 (TCP Header)

TCP 세그먼트는 TCP 헤더와 데이터 부분으로 구성됩니다. TCP 헤더는 최소 20바이트이며, 옵션 필드에 따라 최대 60바이트까지 확장될 수 있습니다.

• Source Port (16 bits): 송신 측 애플리케이션의 포트 번호.
• Destination Port (16 bits): 수신 측 애플리케이션의 포트 번호.
• Sequence Number (32 bits): 현재 세그먼트의 첫 번째 데이터 바이트의 순서 번호.
• Acknowledgement Number (32 bits): 다음에 수신하기를 기대하는 데이터 바이트의 순서 번호 (ACK 플래그가 1일 때 유효).
• Data Offset (4 bits): TCP 헤더의 길이를 32비트 워드 단위로 나타냅니다. (옵션 필드의 존재 여부에 따라 가변적)
• Reserved (6 bits): 미래 사용을 위해 예약된 필드 (항상 0).
• Flags (6 bits):
  • URG (Urgent Pointer): 긴급 데이터가 있음을 나타냅니다.
  • ACK (Acknowledgement): 확인 응답 번호 필드가 유효함을 나타냅니다.
  • PSH (Push): 수신 애플리케이션에게 버퍼링된 데이터를 즉시 전달하도록 요청합니다.
  • RST (Reset): 연결을 강제로 종료하거나 비정상적인 연결을 재설정합니다.
  • SYN (Synchronize): 연결 설정 요청 시 사용됩니다.
  • FIN (Finish): 연결 종료 요청 시 사용됩니다.
• Window Size (16 bits): 수신자가 현재 수신할 수 있는 버퍼 공간의 크기 (바이트 단위). 흐름 제어에 사용됩니다.
• Checksum (16 bits): 헤더와 데이터의 오류 검출을 위한 체크섬.
• Urgent Pointer (16 bits): URG 플래그가 설정되었을 때, 긴급 데이터의 마지막 바이트까지의 오프셋을 나타냅니다.
• Options (가변): MSS(Maximum Segment Size), Window Scale, Selective ACK(SACK) 등 다양한 옵션이 포함될 수 있습니다.

2.2.2. 연결 설정 및 해제

• 3-Way Handshake (연결 설정):
  1. SYN (Synchronize): 클라이언트가 서버에게 연결 요청 (SYN 플래그 1, 초기 순서 번호 X).
  2. SYN-ACK (Synchronize-Acknowledgement): 서버가 클라이언트의 요청 수락 및 자신의 연결 요청 (SYN 플래그 1, ACK 플래그 1, 순서 번호 Y, 확인 응답 번호 X+1).
  3. ACK (Acknowledgement): 클라이언트가 서버의 요청 수락 (ACK 플래그 1, 확인 응답 번호 Y+1).
• 4-Way Handshake (연결 해제):
  1. FIN (Finish): 한쪽 호스트(예: 클라이언트)가 연결 종료 요청 (FIN 플래그 1, 순서 번호 U).
  2. ACK (Acknowledgement): 다른 호스트(예: 서버)가 종료 요청 수락 (ACK 플래그 1, 확인 응답 번호 U+1).
  3. FIN (Finish): 서버도 데이터 전송을 마치고 연결 종료 요청 (FIN 플래그 1, 순서 번호 V).
  4. ACK (Acknowledgement): 클라이언트가 서버의 종료 요청 수락 (ACK 플래그 1, 확인 응답 번호 V+1). 클라이언트는 TIME_WAIT 상태로 전환되어 일정 시간(보통 2MSL, Maximum Segment Lifetime) 동안 기다린 후 연결을 완전히 닫습니다. 이는 지연된 세그먼트가 도착하는 것을 방지하고, 서버가 마지막 ACK를 받지 못했을 경우 재전송할 수 있도록 시간을 줍니다.

2.2.3. 흐름 제어 (Flow Control) - 슬라이딩 윈도우

수신자가 처리할 수 있는 데이터 양을 송신자에게 알려주어 송신 속도를 조절합니다. TCP 헤더의 'Window Size' 필드를 통해 수신 버퍼의 남은 공간을 송신자에게 알립니다. 송신자는 이 윈도우 크기 내에서만 데이터를 전송할 수 있습니다.

2.2.4. 혼잡 제어 (Congestion Control)

네트워크 혼잡으로 인한 성능 저하를 방지하기 위한 메커니즘입니다.

• 혼잡 윈도우 (Congestion Window, cwnd): 송신자가 한 번에 보낼 수 있는 데이터 양을 제한하는 윈도우.
• 느린 시작 (Slow Start): 연결 초기에는 cwnd를 작게 시작하여 지수적으로 증가시킵니다.
• 혼잡 회피 (Congestion Avoidance): cwnd가 임계값(ssthresh)에 도달하면 cwnd를 선형적으로 증가시킵니다.
• 빠른 재전송 (Fast Retransmit): 3개의 중복 ACK를 받으면 타임아웃을 기다리지 않고 손실된 세그먼트를 즉시 재전송합니다.
• 빠른 회복 (Fast Recovery): 빠른 재전송 후 cwnd를 절반으로 줄이고 선형적으로 증가시킵니다.

2.3. 계층 구조에서의 동작 (사용자 영역부터)

1. 애플리케이션 계층 (User Space):
   • 웹 브라우저, 이메일 클라이언트, 파일 전송 프로그램 등 애플리케이션은 socket() API를 사용하여 소켓을 생성합니다.
   • bind()를 통해 로컬 주소와 포트를 할당하고, 서버의 경우 listen()으로 연결 요청을 대기합니다.
   • 클라이언트는 connect()를 통해 서버에 연결을 요청하고, 서버는 accept()로 연결을 수락합니다.
   • send() 또는 write()를 통해 데이터를 전송하고, recv() 또는 read()를 통해 데이터를 수신합니다.
   • close()를 통해 연결을 종료합니다.
2. 전송 계층 (OS Kernel - TCP/IP Stack):
   • 애플리케이션이 send()를 호출하면, OS 커널의 TCP 스택은 애플리케이션 데이터를 세그먼트(Segment)로 분할합니다.
   • 각 세그먼트에 순서 번호, 확인 응답 번호, 윈도우 크기, 플래그 등 TCP 헤더 정보를 추가합니다.
   • 체크섬을 계산하여 헤더에 포함합니다.
   • 흐름 제어 및 혼잡 제어 알고리즘에 따라 전송할 세그먼트의 양과 속도를 결정합니다.
   • 세그먼트를 IP 계층으로 전달합니다.
   • 수신 시, IP 계층으로부터 받은 세그먼트의 체크섬을 검증하고, 순서 번호를 확인하여 올바른 순서로 재조립합니다.
   • 확인 응답(ACK)을 생성하여 송신자에게 보냅니다.
   • 재전송 타이머를 관리하고, 손실된 세그먼트가 감지되면 재전송을 요청합니다.
   • 재조립된 데이터를 애플리케이션 버퍼에 저장하고, 애플리케이션이 recv()를 호출하면 데이터를 전달합니다.
3. 네트워크 계층 (OS Kernel - TCP/IP Stack):
   • TCP 세그먼트를 IP 패킷(Packet)으로 캡슐화합니다.
   • IP 헤더(Source IP, Destination IP 등)를 추가합니다.
   • 라우팅 테이블을 참조하여 다음 홉(Next Hop)으로 패킷을 전달할 경로를 결정합니다.
   • 데이터 링크 계층으로 패킷을 전달합니다.
4. 데이터 링크 계층 (OS Kernel & NIC Driver):
   • IP 패킷을 프레임(Frame)으로 캡슐화합니다.
   • MAC 헤더(Source MAC, Destination MAC 등)를 추가합니다.
   • 이더넷(Ethernet)과 같은 물리적 매체에 적합한 형태로 데이터를 변환합니다.
   • 물리 계층으로 프레임을 전달합니다.
5. 물리 계층 (NIC Hardware):
   • 프레임을 전기 신호, 광 신호 등으로 변환하여 물리적 매체(케이블, 무선 등)를 통해 전송합니다.

3. UDP (User Datagram Protocol)

UDP는 비연결성(Connectionless)이며 신뢰성을 보장하지 않는(Unreliable) 데이터 전송 프로토콜입니다. 최소한의 오버헤드로 빠른 데이터 전송을 목표로 합니다.

3.1. 이론적 배경 및 주요 특징

• 비연결성 (Connectionless): 데이터 전송에 앞서 연결을 설정하거나 해제하는 과정이 없습니다. 각 데이터그램(Datagram)은 독립적으로 처리됩니다.
• 신뢰성 없음 (Unreliability): 데이터 손실, 중복, 순서 바뀜에 대한 보장을 하지 않습니다. 송신자는 데이터가 수신자에게 성공적으로 전달되었는지 확인하지 않으며, 재전송 메커니즘도 없습니다.
• 흐름 제어 없음 (No Flow Control): 수신자의 버퍼 상태를 고려하지 않고 데이터를 계속 전송합니다.
• 혼잡 제어 없음 (No Congestion Control): 네트워크 혼잡 상황에서도 송신 속도를 조절하지 않습니다.
• 최소한의 오버헤드 (Minimal Overhead): TCP에 비해 헤더가 매우 작고, 연결 설정/해제, 확인 응답, 재전송 등의 복잡한 메커니즘이 없으므로 오버헤드가 적습니다.
• 빠른 전송 (Fast Transmission): 오버헤드가 적고 제어 메커니즘이 없기 때문에 데이터 전송 속도가 빠릅니다.
• 데이터그램 서비스 (Datagram Service): 애플리케이션이 보낸 데이터그램의 경계를 유지합니다. 즉, 한 번에 보낸 데이터는 한 번에 수신됩니다.

3.2. 내부 구조 및 구현 방식

3.2.1. UDP 헤더 (UDP Header)

UDP 데이터그램은 UDP 헤더와 데이터 부분으로 구성됩니다. UDP 헤더는 고정된 8바이트입니다.

• Source Port (16 bits): 송신 측 애플리케이션의 포트 번호 (선택 사항, 0일 수 있음).
• Destination Port (16 bits): 수신 측 애플리케이션의 포트 번호.
• Length (16 bits): UDP 헤더와 데이터의 총 길이 (바이트 단위).
• Checksum (16 bits): 헤더와 데이터의 오류 검출을 위한 체크섬 (선택 사항, 0일 수 있음).

3.2.2. 연결 설정 및 해제 없음

UDP는 연결 설정 및 해제 과정이 없으므로, 3-Way Handshake나 4-Way Handshake와 같은 절차가 존재하지 않습니다. 데이터를 보내고 싶을 때 언제든지 보낼 수 있습니다.

3.3. 계층 구조에서의 동작 (사용자 영역부터)

1. 애플리케이션 계층 (User Space):
   • DNS 클라이언트, VoIP 애플리케이션, 온라인 게임 등 애플리케이션은 socket() API를 사용하여 소켓을 생성합니다.
   • bind()를 통해 로컬 주소와 포트를 할당합니다.
   • sendto()를 통해 목적지 주소와 포트를 지정하여 데이터를 전송합니다.
   • recvfrom()을 통해 데이터를 수신합니다.
   • close()를 통해 소켓을 닫습니다.
2. 전송 계층 (OS Kernel - TCP/IP Stack):
   • 애플리케이션이 sendto()를 호출하면, OS 커널의 UDP 스택은 애플리케이션 데이터를 데이터그램(Datagram)으로 캡슐화합니다.
   • UDP 헤더(Source Port, Destination Port, Length)를 추가합니다.
   • 체크섬을 계산하여 헤더에 포함할 수 있습니다 (선택 사항).
   • 데이터그램을 IP 계층으로 전달합니다.
   • 수신 시, IP 계층으로부터 받은 데이터그램의 체크섬을 검증합니다 (체크섬이 0이 아니면).
   • 데이터그램을 애플리케이션 버퍼에 저장하고, 애플리케이션이 recvfrom()을 호출하면 데이터를 전달합니다. 순서가 바뀌거나 손실된 데이터그램에 대한 처리는 하지 않습니다.
3. 네트워크 계층 (OS Kernel - TCP/IP Stack):
   • UDP 데이터그램을 IP 패킷(Packet)으로 캡슐화합니다.
   • IP 헤더(Source IP, Destination IP 등)를 추가합니다.
   • 라우팅 테이블을 참조하여 다음 홉(Next Hop)으로 패킷을 전달할 경로를 결정합니다.
   • 데이터 링크 계층으로 패킷을 전달합니다.
4. 데이터 링크 계층 (OS Kernel & NIC Driver):
   • IP 패킷을 프레임(Frame)으로 캡슐화합니다.
   • MAC 헤더(Source MAC, Destination MAC 등)를 추가합니다.
   • 이더넷(Ethernet)과 같은 물리적 매체에 적합한 형태로 데이터를 변환합니다.
   • 물리 계층으로 프레임을 전달합니다.
5. 물리 계층 (NIC Hardware):
   • 프레임을 전기 신호, 광 신호 등으로 변환하여 물리적 매체(케이블, 무선 등)를 통해 전송합니다.

4. TCP와 UDP 비교

특징	TCP (Transmission Control Protocol)	UDP (User Datagram Protocol)
연결 방식	연결 지향 (Connection-Oriented)	비연결 (Connectionless)
신뢰성	높음 (데이터 손실, 중복, 순서 바뀜 없음 보장)	낮음 (신뢰성 보장 안 함)
데이터 순서	순서 보장	순서 보장 안 함
흐름 제어	있음 (수신자 버퍼 오버플로우 방지)	없음
혼잡 제어	있음 (네트워크 혼잡 시 송신 속도 조절)	없음
오버헤드	높음 (연결 설정/해제, 헤더 크기, 제어 메커니즘)	낮음 (최소한의 헤더, 제어 메커니즘 없음)
속도	느림 (신뢰성 및 제어 메커니즘으로 인한 지연)	빠름 (오버헤드 및 제어 메커니즘 없음)
데이터 단위	세그먼트 (Segment), 바이트 스트림	데이터그램 (Datagram)
사용 사례	웹 브라우징 (HTTP/HTTPS), 이메일 (SMTP, POP3, IMAP), 파일 전송 (FTP), SSH, 데이터베이스 연결	DNS, DHCP, VoIP, 온라인 게임, 실시간 스트리밍, SNMP, NTP
애플리케이션	신뢰성이 중요한 애플리케이션	속도와 효율성이 중요한 애플리케이션

4.1. 장단점 및 강점

TCP의 장점

• 신뢰성: 데이터가 손실되거나 손상되지 않고, 올바른 순서로 전달됨을 보장합니다.
• 흐름 제어: 수신자의 처리 능력을 고려하여 데이터 전송 속도를 조절하므로, 수신 버퍼 오버플로우를 방지합니다.
• 혼잡 제어: 네트워크 혼잡을 감지하고 송신 속도를 조절하여 네트워크 전체의 안정성을 유지합니다.
• 오류 제어: 손상되거나 손실된 데이터를 감지하고 재전송하여 데이터 무결성을 보장합니다.

TCP의 단점

• 높은 오버헤드: 연결 설정/해제, 헤더 정보, 다양한 제어 메커니즘으로 인해 UDP보다 많은 자원과 시간을 소모합니다.
• 느린 속도: 신뢰성 보장을 위한 재전송, 흐름/혼잡 제어 등으로 인해 실시간성이 중요한 애플리케이션에는 적합하지 않을 수 있습니다.
• 지연 (Latency): 재전송 메커니즘으로 인해 지연이 발생할 수 있습니다.

UDP의 장점

• 낮은 오버헤드: 헤더가 작고 제어 메커니즘이 없어 매우 효율적입니다.
• 빠른 속도: 연결 설정/해제 과정이 없고 재전송 등의 지연이 없어 데이터 전송 속도가 빠릅니다.
• 실시간성: 지연에 민감한 실시간 애플리케이션(예: 음성/영상 스트리밍, 온라인 게임)에 적합합니다.
• 멀티캐스트/브로드캐스트 지원: 여러 수신자에게 동시에 데이터를 보낼 수 있습니다.

UDP의 단점

• 신뢰성 없음: 데이터 손실, 중복, 순서 바뀜이 발생할 수 있으며, 이에 대한 처리는 애플리케이션 계층에서 직접 구현해야 합니다.
• 흐름/혼잡 제어 없음: 수신자의 버퍼 오버플로우나 네트워크 혼잡을 유발할 수 있습니다.
• 오류 제어 없음: 데이터 손상 시 재전송을 요청하지 않습니다.

4.2. 언제 어디에 사용하는 것이 좋은가?

• TCP 사용 사례:
  • 웹 브라우징 (HTTP/HTTPS): 웹 페이지의 모든 콘텐츠(텍스트, 이미지, 스크립트)가 정확하게 전달되어야 하므로 신뢰성이 필수적입니다.
  • 이메일 (SMTP, POP3, IMAP): 이메일 내용이 손실되거나 변경되면 안 되므로 신뢰성이 중요합니다.
  • 파일 전송 (FTP): 파일의 모든 바이트가 정확하게 전송되어야 하므로 신뢰성이 가장 중요합니다.
  • 보안 셸 (SSH): 원격 접속 시 명령어가 정확하게 전달되어야 합니다.
  • 데이터베이스 연결: 데이터의 무결성이 최우선이므로 신뢰성 있는 연결이 필요합니다.
  • 채팅 애플리케이션: 메시지가 순서대로 정확하게 전달되어야 합니다.
• UDP 사용 사례:
  • DNS (Domain Name System): 도메인 이름-IP 주소 변환 요청은 작고 빠르게 처리되어야 하며, 손실되더라도 재요청하면 되므로 UDP가 효율적입니다.
  • DHCP (Dynamic Host Configuration Protocol): IP 주소 할당 요청은 브로드캐스트로 이루어지며, 빠른 응답이 중요합니다.
  • VoIP (Voice over IP): 음성 데이터는 약간의 손실이 발생하더라도 전체 통화 품질에 큰 영향을 주지 않으며, 실시간성이 훨씬 중요하므로 UDP가 선호됩니다.
  • 온라인 게임: 플레이어의 움직임이나 상태 업데이트는 실시간으로 빠르게 전달되어야 하며, 약간의 데이터 손실은 게임 플레이에 큰 지장을 주지 않습니다. (물론 중요한 데이터는 애플리케이션 계층에서 신뢰성을 보장하기도 합니다.)
  • 실시간 스트리밍 (영상/음악): 연속적인 데이터 흐름에서 약간의 손실은 허용되지만, 지연은 치명적이므로 UDP가 사용됩니다.
  • SNMP (Simple Network Management Protocol): 네트워크 장비의 상태를 모니터링하는 데 사용되며, 빠르고 간단한 질의/응답에 적합합니다.
  • NTP (Network Time Protocol): 시간 동기화에 사용되며, 정확성보다는 빠른 응답이 중요합니다.

5. 공식 문서 및 참조

• TCP: RFC 793 (Transmission Control Protocol)
• UDP: RFC 768 (User Datagram Protocol)

6. 요약

TCP와 UDP는 전송 계층에서 애플리케이션 간의 통신을 담당하는 두 가지 핵심 프로토콜입니다. TCP는 '연결 지향적'이며 '신뢰성'을 최우선으로 합니다. 데이터를 보내기 전에 3-Way Handshake로 연결을 설정하고, 순서 번호, 확인 응답, 재전송, 흐름 제어, 혼잡 제어 같은 복잡한 메커니즘을 통해 데이터가 손실 없이 정확하고 순서대로 전달되도록 보장합니다. 이 때문에 웹 브라우징, 파일 전송, 이메일처럼 데이터의 정확성이 중요한 서비스에 주로 사용됩니다.

반면에 UDP는 '비연결성'이며 '신뢰성'을 보장하지 않습니다. 연결 설정 과정 없이 데이터를 즉시 전송하며, 흐름 제어나 혼잡 제어 같은 복잡한 기능이 없어 오버헤드가 매우 적고 빠릅니다. 데이터 손실이나 순서 바뀜이 발생할 수 있지만, 지연에 민감한 실시간 애플리케이션, 예를 들어 온라인 게임, 음성/영상 스트리밍, DNS 질의 등에 적합합니다.

결론적으로, 데이터의 '정확성'이 중요하다면 TCP를, '속도'와 '실시간성'이 중요하다면 UDP를 선택하는 것이 일반적입니다. 각 프로토콜은 고유한 장단점을 가지고 있으므로, 애플리케이션의 요구사항에 맞춰 적절히 활용해야 합니다.