TCP, UDP & Transport Reliability

1. Overview

TCP, UDP 및 전송 신뢰성(TCP, UDP & Transport Reliability, TUR)은 수만 킬로미터 떨어진 애플리케이션끼리 대화할 때, 중간에 편지가 분실되거나 순서가 뒤죽박죽이 되더라도 이를 완벽하게 복원해 내거나, 혹은 빠른 전송을 위해 과감히 유실을 감내하는 L4(Transport Layer)의 극단적 통신 철학을 다룹니다.

데이터 패킷이 라우터를 거칠 때 네트워크가 붐비면 라우터는 패킷을 무자비하게 버립니다(Drop). 학습자는 이런 가혹한 환경 속에서도 서로 "받았어?" "응 받았어"라며 끝까지 데이터를 물고 늘어지는 TCP의 3-Way Handshake와 혼잡 제어(Congestion Control) 물리를 훈련합니다. 반면, "못 받았으면 말고 일단 쏴!"라며 속도 하나에 올인하는 UDP의 경량성을 비교하며, 서비스 도메인(실시간 화상회의 vs 파일 전송)에 맞춰 적절한 전송 프로토콜을 선택하고 튜닝하는 아키텍트의 시야를 확보합니다.

2. Scope & Boundaries

In-Scope

• 전송 계층 비교 (Transport Paradigms): TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)의 헤더 구조 및 설계 철학 비교.
• 포트와 소켓 (Ports & Sockets): L4 포트 번호를 이용한 다중화(Multiplexing)와 역다중화(Demultiplexing) 역학.
• TCP 연결 제어 (Connection Management): 3-Way Handshake(연결 수립)와 4-Way Handshake(연결 종료), 그리고 TCP 상태 머신(State Machine, TIME_WAIT 등).
• 흐름 및 혼잡 제어 (Flow & Congestion Control): 수신자 버퍼를 배려하는 슬라이딩 윈도우(Sliding Window), 네트워크 파탄을 막는 혼잡 제어(Slow Start, AIMD, Fast Retransmit).

Out-of-Scope

• IP 주소 체계와 글로벌 라우팅: L3 계층의 BGP, OSPF를 통한 최적 경로 탐색 알고리즘 $\rightarrow$ 08-03. IP, Routing & Global 영역으로 위임.
• HTTPS와 SSL/TLS 암호화 핸드쉐이크: 전송 계층 위의 보안 프로토콜과 공개키 암호화 $\rightarrow$ 10-02. Cryptography 영역으로 위임.

Boundaries

• TUR vs. IP Routing (08-03): IP(08-03)가 '목적지 건물(호스트)까지 어떤 길로 갈 것인가'를 다룬다면, TCP/UDP(TUR)는 **'건물에 도착한 택배를 몇 호실(Port)의 어느 프로세스에게 줄 것이며, 택배가 중간에 분실되었을 때 다시 보내달라고 할 것인가 말 것인가'**를 결정하는 소프트웨어 프로세스 간의 논리적 계약입니다.

3. Counterexample

• "무조건 TCP가 좋다"는 신뢰성 맹신 (Protocol Fallacy): 실시간 FPS 게임의 총알 위치 동기화를 구현하면서, "데이터 유실은 절대 안 돼!"라며 TCP 소켓을 사용하는 행위. TCP는 패킷이 하나라도 유실되면 그 패킷이 재전송될 때까지 뒤에 도착한 멀쩡한 패킷들을 전부 버퍼에 가둬버립니다(Head-of-line Blocking). 결국 플레이어 화면은 1초간 멈췄다가 적이 순간 이동하는 치명적 렉(Lag)을 겪습니다. 실시간성이 신뢰성보다 중요한 도메인에서는, 과거 패킷이 유실되면 미련 없이 버리고 최신 패킷을 그리는 UDP를 써야 한다는 물리 법칙을 간과한 설계입니다.
• TIME_WAIT를 버그로 오해 (State Fallacy): 웹 서버를 재시작하려고 소켓을 닫았는데 TIME_WAIT 상태로 수 분간 포트가 물려있자, "이건 OS 버그다!"라며 강제 킬(Kill) 옵션을 찾아 헤매는 주니어. TIME_WAIT는 방금 끊은 연결에서 지각해서 도착한 잔여 패킷이, 다음에 우연히 같은 포트를 쓰게 된 새로운 연결의 데이터로 둔갑하는 대참사를 막기 위한 TCP의 의도된 방어 메커니즘입니다. TCP 상태 머신의 물리를 모르면 시스템의 안전장치를 버그로 착각하게 됩니다.

4. Prerequisites

• 네트워크 기초와 캡슐화 (Basic): 데이터가 L4 계층으로 올라오기 전, L3(IP)와 L2(MAC)를 어떻게 거쳐왔는지 구조를 이해해야 합니다. (08-01. NFS)
• 프로세스와 파일 입출력 (Recommended): OS가 소켓을 파일 디스크립터(FD)로 취급하고 버퍼에 데이터를 쓰는 커널 기전을 알아야 윈도우(Window) 사이즈를 조절할 수 있습니다. (03-01. OS Foundations)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 전송 계층과 포트(Port) 멀티플렉싱 (Transport Mechanics)

• Why to Learn: 1개의 랜선(IP)으로 게임도 하고 웹서핑도 하고 유튜브도 볼 수 있게 해주는, 애플리케이션 식별의 비밀을 풀기 위함입니다.
• What to Learn:
  • Concepts: L4 전송 계층의 역할, 멀티플렉싱(Multiplexing)과 역다중화(Demultiplexing), 포트(Port) 번호 공간(0~65535).
  • Skills: 잘 알려진 포트(Well-known ports), 소켓(Socket)을 구성하는 5-Tuple (Src IP, Src Port, Dst IP, Dst Port, Protocol).
  • Tools: netstat, lsof.
  • Trade-offs: OS가 가용한 포트(약 6.5만 개)를 무한정 열어주면 좋겠지만, 포트 하나당 커널 메모리를 점유하므로 포트 고갈(Port Exhaustion) 장애가 발생할 수 있는 물리적 한계.
• How to Learn:
  • 1단계: 크롬 브라우저 창을 5개 띄우고 동일한 구글(IP)에 접속했을 때, 구글 서버가 내가 띄운 5개의 창 중 어떤 창으로 HTML을 돌려보내야 할지 헷갈리지 않는 이유가 내 PC가 임의로 부여한 '출발지 포트(Ephemeral Port)' 덕분임을 도식화합니다.
  • 2단계: netstat -an 명령어를 쳐서 현재 내 컴퓨터가 어떤 포트를 열어두고(LISTEN) 있는지, 어떤 외부 IP/포트와 연결되어(ESTABLISHED) 있는지 매핑 테이블을 분석합니다.
• Implement: 특정 IP와 포트 번호를 입력받으면, 해당 포트가 열려있는지(TCP SYN을 보내 응답을 확인) 검사하는 초간단 파이썬 포트 스캐너(Port Scanner).

Recommended

Core Topic 02: TCP 연결 수립과 상태 머신 (Connection Lifecycle)

• Why to Learn: 데이터 전송 전후의 연결/해제 과정에서 발생하는 수많은 변수(좀비 연결, TIME_WAIT 고갈)를 통제하여 서버 폭발을 막기 위해서입니다.
• What to Learn:
  • Concepts: 3-Way Handshake(연결 수립), 4-Way Handshake(연결 종료), 순서 번호(Sequence Number)와 확인 응답 번호(ACK Number).
  • Skills: TCP 상태 머신(LISTEN, SYN_SENT, ESTABLISHED, FIN_WAIT, TIME_WAIT, CLOSE_WAIT).
  • Tools: Wireshark.
  • Trade-offs: "야, 끝내자" 한마디로 끊어버리면 빠르지만 마지막 데이터가 날아갈 수 있으니, 네 번에 걸쳐 서로 합의 하에 종료(4-Way)하는 신뢰의 비용.
• How to Learn:
  • 1단계: 카페에서 친구를 부를 때, "철수야 내 말 들려?(SYN)", "어 영희야 들려, 넌 내 말 들려?(SYN+ACK)", "어 들려, 이제 얘기하자(ACK)"라는 인간의 대화 방식을 TCP 3-Way Handshake로 치환해 시퀀스 다이어그램을 그립니다.
  • 2단계: 서버에서 먼저 연결을 끊었을 때(Active Close) 해당 포트가 1~2분간 TIME_WAIT 상태로 묶이는 이유를 '지연된 패킷(Delayed Packet)의 환생 방지'라는 물리적 시나리오로 증명합니다.
• Implement: Wireshark로 HTTP 접속 하나를 캡처한 뒤, 쏟아지는 수백 개의 패킷 중 첫 3개의 패킷(SYN, SYN-ACK, ACK)만 필터링하여 Sequence 번호가 어떻게 +1씩 증가하며 교환되는지 해설하는 로그 분석 리포트.

Practical

Core Topic 03: 흐름 제어와 슬라이딩 윈도우 (Flow Control)

• Why to Learn: 보내는 쪽 컴퓨터가 아무리 초고성능이어도, 받는 쪽 컴퓨터가 낡아 메모리가 부족할 때 데이터를 강제로 욱여넣어 시스템을 죽이는 짓을 막기 위함입니다.
• What to Learn:
  • Concepts: 흐름 제어(Flow Control), 수신 윈도우(Receive Window, rwnd), 버퍼(Buffer).
  • Skills: 슬라이딩 윈도우(Sliding Window) 알고리즘, 파이프라이닝(Pipelining), Zero Window 상황에서의 복구 로직.
  • Tools: TCP 덤프.
  • Trade-offs: 패킷 하나 보낼 때마다 확인 응답(ACK)을 기다리는 Stop-and-Wait의 끔찍한 비효율 vs 상대방 윈도우 크기만큼 ACK 없이 일단 와르르 쏟아붓는 Sliding Window의 속도 향상(단, 중간에 하나라도 유실되면 복구가 복잡함).
• How to Learn:
  • 1단계: 수신자가 TCP 헤더의 Window 필드에 '10,000 바이트'라고 적어 보내면, 송신자는 ACK를 받지 않더라도 딱 10,000 바이트까지만 데이터를 꽉 채워(Pipelining) 밀어 보내고 멈추는 전송 물리를 시각화합니다.
  • 2단계: 수신자의 애플리케이션이 데이터를 제때 읽어가지 않아 버퍼가 꽉 차면 Window 사이즈가 '0'으로 수렴하고, 송신자가 전송을 일시 정지(Zero Window)했다가 다시 재개하는 피드백 루프를 분석합니다.
• Implement: 윈도우 크기를 5로 설정하고 1~10번 패킷을 보내는 슬라이딩 윈도우 시뮬레이터(3번 패킷 유실 시 송신 윈도우가 어떻게 멈추고 재전송하는지 콘솔에 출력).

Advanced

Core Topic 04: 혼잡 제어와 신뢰성의 극한 (Congestion Control)

• Why to Learn: 도로(네트워크)에 차가 꽉 막혀있는데 나 먼저 가겠다고 엑셀을 밟아 교통을 완전히 마비시키는 이기심을, 프로토콜 차원에서 차단하는 이타적 알고리즘을 뜯어보기 위해서입니다.
• What to Learn:
  • Concepts: 혼잡 제어(Congestion Control), 혼잡 윈도우(Congestion Window, cwnd), 타임아웃(RTO) vs 중복 ACK.
  • Skills: Slow Start(지수적 증가), 혼잡 회피(AIMD: Additive Increase Multiplicative Decrease), 빠른 재전송(Fast Retransmit), 빠른 복구(Fast Recovery).
  • Tools: TCP BBR 알고리즘 연구.
  • Trade-offs: 윈도우를 조금씩 조심스럽게 늘리면 대역폭 낭비가 발생하지만, 무식하게 크게 보내면 라우터 큐가 꽉 차서 수만 개의 패킷이 동시다발적으로 드롭(Drop)되는 혼잡 붕괴(Congestion Collapse) 리스크.
• How to Learn:
  • 1단계: 처음에는 패킷 1개, 다음엔 2개, 4개, 8개로 지수(Exponential) 폭발을 일으키며(Slow Start) 속도를 올리다가, 임계치(ssthresh)를 넘는 순간 1개씩만 늘리며(AIMD) 조심스레 대역폭의 한계를 탐색하는 TCP의 눈치싸움을 그래프로 그립니다.
  • 2단계: 특정 패킷(예: 3번)이 유실되었을 때, 수신자가 계속 "2번까지만 받았어"라는 중복 ACK를 3번 날리면, 송신자가 타임아웃(보통 1초 이상)을 기다리지 않고 즉시 3번 패킷을 재전송하여 체감 지연 시간을 극적으로 줄이는 '빠른 재전송' 로직을 추적합니다.
• Implement: 대역폭 100Mbps, 지연 시간 50ms인 가상 네트워크 환경을 설정하고, TCP Reno(전통적 방식)와 TCP BBR(구글 최신 방식) 알고리즘이 패킷 드롭율 1% 환경에서 각각 처리량(Throughput)을 얼마나 방어해 내는지 수치화한 비교 리포트.

7. Terminology

8. References

Primary References

• [P1] CS2023 - NC/Routing and Forwarding — Routing theory.
• [P1] CS2023 - NC/Transport Layer Protocols — Transport mechanics.

Secondary References

• [Computer Networks] Andrew S. Tanenbaum — Deep academic perspective on TRP.
• [TCP/IP Illustrated, Vol 2] W. Richard Stevens — Detailed implementation.

Industry References

• [RFC 793 (TCP)] — Official protocol specification.
• [Cisco: Introduction to IP Routing] — Practical networking equipment standard.

9. Final Checklist

Primary Checklist

• TCP가 특정 패킷의 유실을 인지했을 때, 재전송을 위해 수행하는 물리적 단계(Fast Retransmit 등)를 기술할 수 있는가? (P1)
• IP 주소와 서브넷 마스크를 보고 해당 네트워크의 브로드캐스트 주소와 사용 가능한 호스트 범위를 계산 가능한가? (P1)

Secondary Checklist

• 동일한 네트워크 부하 상황에서 OSPF와 BGP가 경로를 선택하는 물리적 기준(Metric)의 본질적 차이를 식별하는가?
• TCP 타임아웃(RTO) 설정이 너무 짧거나 길 때 각각 네트워크 성능에 미치는 물리적 폐해를 인지하고 있는가?

Industry Checklist

• 실무 서비스에서 대역폭은 충분한데 파일 전송 속도가 나지 않을 때, TCP 윈도우 사이즈와 레이턴시의 관계를 통해 원인을 진단 가능한가? (SFIA)
• L3 스위치와 라우터의 물리적 성능 차이가 실제 패킷 포워딩 지연에 미치는 영향을 제안 및 분석 가능한가?