IP & TCP Core Dynamics

1. Overview

IP와 TCP 핵심 역학(IP & TCP Core Dynamics)은 인터넷의 두 기둥인 IP(배달부)와 TCP(품질보증팀)가 결합하여, 거칠고 파괴적인 네트워크 환경에서 어떻게든 데이터를 목적지까지 완벽하게 밀어 넣는 인터넷의 뼈대를 해부합니다.

학습자는 단순히 주소를 찾아가는 **IP(Internet Protocol)**의 베스트 에포트(Best-effort) 원칙이 갖는 '무책임함'을 뜯어봅니다. 나아가 이 무책임함을 수습하기 위해 패킷에 번호표(Sequence Number)를 붙이고 확인증(ACK)을 강요하는 **TCP(Transmission Control Protocol)**의 집요한 추적 시스템을 장악합니다. 마지막으로, 보내는 쪽(송신자)이 너무 빨리 데이터를 쏟아부어 받는 쪽(수신자)의 버퍼가 터지는 것을 막기 위해, 수신자가 허락한 양만큼만 데이터를 쏘는 **흐름 제어(Flow Control, Sliding Window)**의 우아한 속도 조절 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• IP Protocol Core: 비연결성(Connectionless), Best-effort Delivery, IP Fragmentation(단편화).
• TCP Protocol Core: 연결 지향성, 순서 보장(Sequence Number), 패킷 재전송(Retransmission).
• Flow Control (흐름 제어): Sliding Window 알고리즘, Receiver Window (rwnd).
• TCP Header Analysis: SYN, ACK, PSH, FIN 플래그와 윈도우 사이즈 필드.

Out-of-Scope

• 네트워크 혼잡 제어(Congestion Control): 네트워크 전체가 막힐 때 늦추는 알고리즘(Slow Start 등) → 08-02-02 Congestion Control 영역으로 분리.
• TCP 3-Way/4-Way Handshake 상세: 연결 생성 및 종료 과정 → 08-01-03 Transport Layer 영역에서 이미 다룸.

Boundaries

• Flow Control (수신자 보호) vs Congestion Control (네트워크 보호): 이 두 가지를 헷갈리면 TCP를 절반만 아는 것입니다. '흐름 제어'는 받는 사람(수신자)의 메모리 버퍼가 꽉 찰까 봐 늦춰주는 1:1 배려입니다. 반면 '혼잡 제어'는 중간에 있는 통신사 라우터(네트워크)가 터질까 봐 눈치를 보며 속도를 늦추는 공공도덕입니다. 본 문서에서는 수신자를 보호하는 '흐름 제어(Sliding Window)'에만 집중하여 경계를 긋습니다.

3. Counterexample

• IP를 맹신하는 설계 (The UDP Trap): "내부망(LAN)은 빠르고 안전하니까 UDP로 파일 전송을 짜자!"라고 개발했습니다. 테스트 환경에서는 잘 되지만, 프로덕션 트래픽이 몰려 스위치 버퍼가 가득 차자 IP 계층에서 패킷 드롭(Drop)이 발생합니다. IP는 패킷이 없어졌다는 사실조차 알려주지 않는(Best-effort) 무책임한 프로토콜인데, 이를 보완할 재전송(Retransmission) 로직을 짜넣지 않아 파일이 깨지는 참사입니다.
• Sliding Window 붕괴 (Stop-and-Wait): TCP를 모사한 커스텀 프로토콜을 만들면서, "패킷 1개 보내고 → ACK 기다리고 → 패킷 1개 보내고 → ACK 기다리는(Stop-and-Wait)" 방식을 썼습니다. 한국에서 미국으로 통신(RTT 200ms)할 때, 대역폭이 1Gbps라도 초당 5개의 패킷밖에 못 보내는 절망적인 속도가 나옵니다. 수신자가 허락한 윈도우 크기(예: 패킷 100개)만큼은 ACK를 기다리지 않고 한 번에 쏟아부어야(Sliding Window) 파이프라인 효율이 극대화된다는 물리학을 무시한 설계입니다.

4. Prerequisites

• L3/L4 기본 개념 (Basic): IP 헤더와 TCP 포트, 3-Way Handshake. (08-01 OSI Stack)
• 메모리 버퍼 기초 (Basic): 큐(Queue) 자료구조의 원리. (04-01 Data Structures)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 무책임한 배달부, IP (The Unreliable IP)

• Why to Learn: 인터넷의 하부 구조인 IP 프로토콜이 태생적으로 '신뢰성을 보장하지 않음'을 명확히 인지해야, 왜 TCP 같은 복잡한 상위 프로토콜이 덧붙여져야만 했는지 아키텍처적 당위성을 깨닫기 위함입니다.
• What to Learn:
  • Concepts: Best-effort Delivery, Connectionless (비연결성), Unreliable (비신뢰성), Out-of-Order (순서 뒤바뀜), IP Fragmentation (단편화).
  • Skills: 패킷이 중간 라우터 버퍼 초과로 버려지거나(Drop), 다른 경로를 타서 늦게 도착하는(Out-of-Order) 물리적 현상 이해.
• How to Learn:
  • 1단계: 비연결성(Connectionless)의 한계: IP는 전화통화가 아니라 '엽서'입니다. 엽서 3장을 차례대로 우체통에 넣었지만, 우체국(라우터) 사정에 따라 3번 엽서가 1번 엽서보다 먼저 도착할 수도 있고, 2번 엽서는 배달부가 잃어버릴 수도 있습니다.
  • 2단계: 베스트 에포트(Best-effort): 라우터는 패킷을 목적지로 보내기 위해 '최선'을 다할 뿐, 실패했다고 발송자에게 알려줄 의무가 전혀 없는 쿨한(무책임한) IP의 뼈대를 해부합니다.
• Implement: IP 라우터 Drop 시뮬레이터. Router_Queue_Size = 2. 송신자가 1초에 패킷 5개를 [1, 2, 3, 4, 5] 쏨. 라우터 큐가 2개 꽉 차면 3, 4, 5번 패킷은 가차 없이 버려버림(Drop). 수신자는 [1, 2]만 받고 송신자는 아무것도 모른 채로 종료되는 통신 단절(Unreliable) 데모.

Recommended

Core Topic 02: 집요한 조립공, 순서 번호와 확인증 (TCP Seq & ACK)

• Why to Learn: IP가 잃어버린 패킷을 귀신같이 찾아내 다시 보내고, 뒤죽박죽된 순서를 완벽한 파일로 조립해 내는 TCP의 핵심 무결성(Integrity) 보장 원리를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Sequence Number (Seq, 순서 번호), Acknowledgment Number (ACK, 확인 응답 번호), Retransmission (재전송), Timeout (타임아웃).
  • Skills: Wireshark 패킷 캡처에서 Seq와 ACK 번호가 교차하며 티키타카(Ping-Pong)하는 바이트 추적 흐름 읽어내기.
• How to Learn:
  • 1단계: 순서 번호(Seq): 엽서(패킷)마다 일련번호를 적습니다. "나 지금 100번째 바이트부터 200번째 바이트(Seq 100) 보낸다." 패킷이 순서가 뒤집혀서 와도 수신자 OS는 이 번호를 보고 메모리(버퍼)에서 완벽히 순서대로 재조립합니다.
  • 2단계: 확인증(ACK)과 타임아웃: 수신자가 패킷을 받으면 "잘 받았어. 다음엔 201번째 바이트 줘(ACK 201)"라고 확인증을 보냅니다. 송신자가 패킷을 보냈는데 1초(Timeout)가 지나도 ACK가 안 오면 "아, 중간에 잃어버렸구나" 확신하고 패킷을 재전송(Retransmission)하는 끈질긴 추적 시스템을 뜯어봅니다.
• Implement: TCP 재전송 및 재조립 스크립트. Send([1, 2, 3]). 네트워크가 2를 드롭. Receiver가 1 수신 후 ACK 2 쏨. 3 수신 후 버퍼에 임시 저장(Out-of-order)하고 여전히 ACK 2 쏨. Sender가 타임아웃 됨. 2 재전송. Receiver가 2를 받아 버퍼의 3과 결합 후 한 방에 ACK 4를 쏘아 올리는 무결성 복구 렌더링.

Practical

Core Topic 03: 배려의 밸브 조절, 슬라이딩 윈도우 (Flow Control)

• Why to Learn: 보내는 쪽 컴퓨터가 i7 최고급이고 받는 쪽이 펜티엄이라 버퍼 처리가 늦을 때, 수신자 서버가 터지지 않게 송신자가 템포를 조절해 주는 흐름 제어 매커니즘을 쥐기 위함입니다.
• What to Learn:
  • Concepts: Flow Control (흐름 제어), Sliding Window (슬라이딩 윈도우), Receiver Window (rwnd - 수신 윈도우), Zero Window.
  • Skills: ACK 패킷에 담겨오는 Window Size 값을 뜯어보고, 송신 측이 파이프라인에 한 번에 밀어 넣는 데이터양 조절하기.
• How to Learn:
  • 1단계: 수신 버퍼의 한계: 수신 측 OS는 데이터를 받으면 메모리(버퍼)에 쌓아두고 앱(어플리케이션)이 가져가길 기다립니다. 앱이 바빠서 안 가져가면 버퍼가 꽉 찹니다. 이때 송신 측이 데이터를 더 보내면 다 버려집니다(버퍼 오버플로우).
  • 2단계: 슬라이딩 윈도우: 수신 측이 ACK를 보낼 때 "내 버퍼 지금 500바이트 남았어(Window=500)"라고 귀띔해 줍니다. 송신 측은 ACK를 아직 못 받았더라도 이 500바이트 한도 내에서는 연속으로(파이프라이닝) 데이터를 밀어 넣습니다. 수신 버퍼가 0이 되면 Zero Window를 띄워 송신을 완벽히 멈춰 세우는 밸브 조절을 해부합니다.
• Implement: 슬라이딩 윈도우 로직 모사 (파이썬). Receiver_Buffer_Max = 5. Receiver_App_Read_Speed = 1초에 1개. Sender_Speed = 1초에 3개. Sender가 패킷을 쏠 때마다 Window Size가 줄어듦. 2초 만에 Window=0이 되어 Sender가 블로킹 대기 상태(Zero Window)에 진입. Receiver App이 데이터를 읽어내어 Window Size가 복구되면 Sender가 다시 송신을 시작하는 밸브 렌더링.

Advanced

Core Topic 04: 기가비트 시대의 창문 확장 (Window Scaling & Performance)

• Why to Learn: 1Gbps 초고속 랜선을 깔았는데도 해외망(RTT 200ms)만 타면 파일 다운로드가 느려지는 현상의 원인(BDP 한계)을 파악하고 창문 크기를 찢어발기기 위함입니다.
• What to Learn:
  • Concepts: BDP (Bandwidth-Delay Product), TCP Window Scaling Option, Long Fat Network (LFN).
  • Skills: 대역폭(Bandwidth)과 지연 시간(Delay)을 곱하여, 현재 회선을 100% 꽉 채워 쓰기 위해 필요한 '최소 윈도우 사이즈' 계산.
• How to Learn:
  • 1단계: 회선은 넓은데, 창문이 작다: TCP 헤더의 Window Size 필드는 원래 16비트($64KB$)밖에 안 됩니다. 미국까지 왕복(RTT) 200ms가 걸리는데, 한 번에 $64KB$ 밖에 못 보내고 ACK를 기다려야 한다면, 1Gbps 선로가 텅텅 빈 채로 속도가 2Mbps밖에 안 나오는 바보 같은 상황(BDP의 저주)을 해부합니다.
  • 2단계: Window Scaling (창문 찢기): 이 낡은 규격을 부수기 위해 TCP 3-Way Handshake 때 Window Scale Option을 교환합니다. "내가 보내는 Window 숫자에 $2^8(256)$ 을 곱해서 해석해라." 이를 통해 윈도우 크기를 $64KB$ 에서 최대 $1GB$ 까지 기하급수적으로 찢어 늘려, 200ms 동안 기다리는 텅 빈 파이프라인을 꽉꽉 채워 쏘는 모던 TCP의 튜닝을 뜯어봅니다.
• Implement: BDP(대역폭-지연 곱)에 따른 전송량 계산기. 대역폭 1Gbps, RTT 200ms 입력. 물리적으로 선로에 띄워둘 수 있는 데이터양(BDP)은 $1Gbps \times 0.2s = 25MB$ 임. 기존 $64KB$ 윈도우로는 회선 능력의 $0.2\%$ 밖에 못 씀을 수학적으로 증명하고, Window Scaling Option이 적용되었을 때 대역폭을 $100\%$ 활용하는 수치(Throughput) 비교 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Transport Layer Protocols (TCP Reliability)
• [P5] SFIA - Network Design (NTDS) - Protocol Analysis and Flow Control

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - Principles of Reliable Data Transfer
• [TCP/IP Illustrated, Volume 1] Kevin R. Fall - TCP Connection Management and Data Flow

Industry

• [IETF RFC 793] - Transmission Control Protocol (Sliding Window Mechanics)
• [IETF RFC 7323] - TCP Extensions for High Performance (Window Scaling)

9. Final Checklist

Primary

• IP 계층이 보장하지 않는 데이터 유실(Drop) 현상을 해결하기 위해, TCP가 순서 번호(Sequence Number)와 확인 응답(ACK), 그리고 타임아웃(Timeout)을 통해 재전송을 트리거하는 메커니즘을 설명할 수 있는가?
• 수신자(Receiver) 서버의 처리 속도보다 송신자(Sender)가 데이터를 붓는 속도가 빠를 때, 수신 버퍼 오버플로우를 막기 위한 TCP의 흐름 제어(Flow Control) 철학을 증명할 수 있는가?

Secondary

• 패킷을 1개 보내고 ACK를 기다리는 Stop-and-Wait 방식의 극악의 비효율성을 지적하고, 슬라이딩 윈도우(Sliding Window)가 ACK 없이 여러 패킷을 동시에 파이프라이닝(Pipelining)하는 효율성을 해부할 수 있는가?
• 수신자의 버퍼가 가득 차서 Window Size를 0으로 통보했을 때(Zero Window), 송신자가 전송을 멈추고 지속적으로 Window Probe 패킷을 보내어 창문이 열렸는지 확인하는 블로킹 해제 과정을 논증할 수 있는가?

Industry

• 대역폭(Bandwidth)은 크지만 지연 시간(RTT)이 긴 해외망(LFN) 환경에서, BDP(대역폭-지연 곱)의 물리학을 바탕으로 기본 16비트 Window Size($64KB$)가 갖는 병목 한계를 식별할 수 있는가?
• 위와 같은 네트워크 병목을 해소하기 위해, TCP 3-Way Handshake 과정에서 교환되는 Window Scale Option을 통해 창문 크기를 기가비트 수준으로 확장하는 고성능 튜닝 기법을 평가할 수 있는가?