Transport Layer Mechanisms

1. Overview

전송 계층 메커니즘(Transport Layer Mechanisms)은 패킷이 인터넷 험지를 뒹굴다 순서가 뒤섞이고 소실되는 IP(네트워크 계층)의 무책임한 배달 방식을 참지 못하고, "어떤 일이 있어도 100% 완전한 상태로 조립해 주겠다"고 선언하는 **L4(전송 계층)**의 신뢰성 보장 물리학을 해부합니다.

학습자는 단순히 목적지 기기(IP)에 도달하는 것을 넘어, 기기 안에서 돌아가는 수많은 프로그램 중 도대체 어떤 프로세스가 이 패킷의 주인인지를 구별해 내는 **포트(Port)**의 다중화(Multiplexing) 마법을 뜯어봅니다. 나아가 무책임하지만 미친 듯이 빠른 UDP와, 느리지만 완벽하게 순서를 맞추고 분실물을 재요청하는 TCP의 근본적인 철학 차이를 장악합니다. 마지막으로, TCP가 어떻게 서로 인사(3-way Handshake)를 나누고 이별(4-way Teardown)을 준비하는지, 연결 지향형(Connection-oriented) 프로토콜의 신뢰성 제어 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Transport Layer (L4): IP 통신(Host-to-Host)의 한계를 넘어선 Process-to-Process 통신.
• Port Numbers: Well-known 포트, 다중화(Multiplexing)와 역다중화(Demultiplexing).
• TCP vs UDP Core: 연결 지향(TCP)과 비연결형(UDP)의 근본적 트레이드오프.
• TCP State Machine: 3-Way Handshake(연결 수립)와 4-Way Handshake(연결 종료).

Out-of-Scope

• TCP 혼잡 제어(Congestion Control)와 윈도우 사이즈 딥 다이브: 슬라이딩 윈도우, Slow Start 알고리즘 $\rightarrow$ 08-02-02 Congestion Control 영역으로 위임.
• UDP 기반 실시간 프로토콜(WebRTC): 미디어 스트리밍 통신 $\rightarrow$ 08-02-04 UDP & Real-time 영역.

Boundaries

• L3 (IP) vs L4 (Port): L3의 IP 주소는 패킷을 '정확한 건물(Host)'까지 데려다주는 역할만 합니다. 하지만 건물 안에는 카카오톡, 웹 브라우저, 게임 등 수백 명의 입주자(Process)가 살고 있습니다. L4의 포트 번호는 이 수백 명 중 '정확한 호수(Process)'를 찾아 문을 두드리는 역할을 합니다. IP 주소만으로는 절대로 2개 이상의 네트워크 프로그램을 동시에 띄울 수 없음을 명확히 경계 짓습니다.

3. Counterexample

• 포트(Port) 충돌의 바보짓: 개발자가 스프링 부트 서버를 띄워놓고 까먹은 상태에서, 똑같은 프로젝트를 하나 더 띄우려다 Web server failed to start. Port 8080 was already in use. 에러를 맞고 당황합니다. "IP는 내 컴퓨터 하나인데 왜 서버 2개가 동시에 안 뜨지?" 포트 번호(L4)는 운영체제가 네트워크 트래픽을 정확한 프로세스로 꽂아주기 위한 유일한 소켓 식별자이며, 하나의 포트 번호는 하나의 프로세스만 독점할 수 있다는 다중화(Multiplexing)의 기본을 망각한 것입니다.
• UDP로 파일 전송하기: 1GB짜리 압축 파일을 전송하는 프로그램을 짰습니다. 속도를 높이겠다고 아무 고민 없이 UDP를 썼습니다. 수신 측에서 압축을 풀려니 "파일이 손상되었습니다"라는 에러가 납니다. 인터넷 망(L3)은 언제든 패킷을 버리거나(Drop) 순서를 뒤섞을 수 있는데, 이를 번호표(Sequence Number)로 조립하고 유실 시 재요청(Retransmission)하는 TCP의 신뢰성 뇌를 빼버리고 무작정 빠르기만 한 UDP를 쓴 극악의 설계 미스입니다.

4. Prerequisites

• 네트워크 계층 (Basic): IP 헤더의 한계와 베스트 에포트(Best-effort) 전달. (08-01-02 Network Layer)
• 프로세스와 스레드 (Basic): OS 레벨의 프로세스 식별. (03-01 OS Core)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 건물과 호수, 포트와 다중화 (Port & Multiplexing)

• Why to Learn: IP 주소(건물)만으로는 절대 컴퓨터 내부의 수많은 프로그램(호수)을 구별할 수 없음을 깨닫고, Socket 프로그래밍의 핵심 식별자를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Process-to-Process Communication, Multiplexing(다중화), Demultiplexing(역다중화), Port Number (16-bit).
  • Skills: Well-known Ports (80, 443, 22, 3306 등) 식별 및 netstat을 이용한 내 컴퓨터의 포트 점유 상태 확인.
• How to Learn:
  • 1단계: IP의 한계: 구글 서버(142.250.X.X)에 패킷이 도착했습니다. 그런데 이 서버 안에는 웹 서버(Nginx)도 돌고, SSH 데몬도 돌고, DB도 돌고 있습니다. IP 주소만 적힌 패킷은 누구한테 가야 할지 몰라 방황합니다.
  • 2단계: 포트(Port)의 이정표: 패킷의 L4 헤더에 목적지 포트: 80이라고 적혀 있습니다. 운영체제(OS)는 이를 보고 "아, 80번 포트를 물고 있는 Nginx 프로세스한테 던져줘야겠군" 하고 역다중화(Demultiplexing)를 해줍니다. 반대로 내 PC의 여러 프로그램이 데이터를 내보낼 때는 OS가 각자 임시 포트(49152~)를 달아서 하나로 합쳐서(Multiplexing) 랜선으로 쏘는 역학을 뜯어봅니다.
• Implement: 로컬 포트 바인딩 및 충돌 렌더링. 파이썬 socket 라이브러리로 8080 포트를 점유하는 에코 서버 스레드 A를 실행. 동일한 8080 포트를 점유하려는 스레드 B를 띄웠을 때 Address already in use OS 에러가 발생하는 다중화 제약 조건 데모.

Recommended

Core Topic 02: 집요함과 무책임함 (TCP vs UDP Philosophy)

• Why to Learn: 모든 통신에 무조건 TCP를 쓰는 무식함을 버리고, 데이터의 '무결성'이 중요한지 '실시간성'이 중요한지에 따라 L4 프로토콜을 선택하는 설계자의 감각을 쥐기 위함입니다.
• What to Learn:
  • Concepts: Connection-oriented (연결 지향형), Connectionless (비연결형), Reliability (신뢰성), Ordering (순서 보장), Overhead.
  • Skills: 파일 전송(HTTP/FTP)에는 TCP를, 실시간 스트리밍(VoIP/FPS 게임)에는 UDP를 선택해야 하는 비즈니스 트레이드오프 분석.
• How to Learn:
  • 1단계: TCP (완벽주의자): 1GB짜리 게임 클라이언트를 다운받습니다. 중간에 10MB짜리 패킷 하나가 유실되었습니다. TCP는 이를 귀신같이 알아채고 재요청(Retransmission)하며, 1번 패킷보다 2번 패킷이 먼저 도착하면 메모리 버퍼에 쥐고 있다가 순서를 1, 2번으로 완벽히 재조립해서 앱에 넘깁니다. 느리지만 완벽합니다.
  • 2단계: UDP (무책임한 속도광): 실시간 줌(Zoom) 화상 회의를 합니다. 영상 프레임 1개가 유실되었습니다. 이걸 TCP처럼 "잠깐만요! 저 프레임 1개 못 받았어요 재전송 좀!" 하고 1초를 멈추면 대화가 끊겨 유저가 분노합니다. 차라리 깍두기가 살짝 끼더라도 그냥 버리고 다음 프레임을 빠르게 받는(No Retransmission) UDP의 실시간성을 해부합니다.
• Implement: TCP vs UDP 시뮬레이터 로직. 패킷 1, 2, 3 발사. 망에서 2번 패킷 드롭(Drop) 발생.
  • UDP 로직: 앱에 [1, 3] 전달 끝.
  • TCP 로직: 앱에 [1] 전달 후 3은 버퍼에 저장 $\rightarrow$ 수신 측이 "2번 안 옴" ACK 쏨 $\rightarrow$ 송신 측이 2 재전송 $\rightarrow$ 수신 측이 2 수신 후 버퍼의 3과 합쳐 [2, 3] 앱에 전달. 이 극명한 철학 차이 콘솔 렌더링.

Practical

Core Topic 03: 신뢰의 시작, 3-Way Handshake (TCP Connection)

• Why to Learn: TCP가 '연결 지향(Connection-oriented)'이라는 말의 실체를 뜯어보고, 서버가 무리하게 많은 연결을 받다가 터지는 SYN Flooding 공격을 방어하기 위함입니다.
• What to Learn:
  • Concepts: TCP Header (SYN, ACK 플래그), Sequence Number (순서 번호), 3-Way Handshake, Connection Establishment, SYN Flooding.
  • Skills: Wireshark를 이용해 브라우저가 웹 서버와 맺는 3번의 인사(SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK) 패킷 캡처 및 분석.
• How to Learn:
  • 1단계: 인사 없이 본론 꺼내기 (UDP): 상대방이 죽어있든 말든, 버퍼가 터지든 말든 무작정 데이터를 던집니다.
  • 2단계: 3-Way Handshake (TCP):
    1. 클라이언트: "안녕? 내 데이터 시작 번호는 100번이야." (SYN)
    2. 서버: "어 안녕, 100번 받았고 다음엔 101번 줘(ACK 101). 그리고 내 데이터 시작 번호는 500번이야." (SYN+ACK)
    3. 클라이언트: "오케이, 500번 받았어 다음엔 501번 줘(ACK 501)." (ACK) 이 세 번의 인사가 끝나야 비로소 양쪽 OS 커널에 소켓(Socket) 메모리가 할당되고 연결이 맺어지는 동기화 과정을 해부합니다.
• Implement: 3-Way Handshake 상태 머신 파이썬 모사. Client 상태(CLOSED->SYN_SENT->ESTABLISHED), Server 상태(LISTEN->SYN_RCVD->ESTABLISHED). 세 번의 메시지 교환(SYN, SYN+ACK, ACK)에 따라 양쪽의 상태 값이 변하고, 최종적으로 양쪽 변수가 ESTABLISHED가 되어야만 데이터 전송 함수가 열리는(Lock 해제) 로직 렌더링.

Advanced

Core Topic 04: 안전한 이별, 4-Way Teardown (TCP Disconnection)

• Why to Learn: "다 썼으면 그냥 선 뽑으면 되지"라는 안일한 생각으로 좀비 커넥션(TIME_WAIT)을 방치하다가, 서버의 포트가 고갈되어 터지는 네트워크 마비를 피하기 위함입니다.
• What to Learn:
  • Concepts: FIN, ACK, 4-Way Handshake, Half-close (반만 닫기), TIME_WAIT State, Port Exhaustion (포트 고갈).
  • Skills: 4-Way 종료 과정 중 발생하는 TIME_WAIT 상태의 필요성 이해 및 트래픽 폭주 시 포트 고갈(Port Exhaustion) 모니터링.
• How to Learn:
  • 1단계: 일방적인 이별통보의 위험성: 서버가 "나 다 보냈어, 끊을게" 하고 소켓을 쾅 닫아버립니다. 클라이언트는 아직 서버로 보낼 데이터(마지막 인사)가 남아있었는데, 서버가 죽어버려 에러가 발생합니다.
  • 2단계: 4-Way Teardown (우아한 종료):
    1. A: "나 보낼 거 다 보냈어. 끊을게." (FIN)
    2. B: "알았어, 잠시만. (내 앱이 아직 처리 중이야)" (ACK)
    3. B: "(처리가 끝나고) 나도 다 끝났어. 이제 진짜 끊자." (FIN)
    4. A: "고생했어, 잘 가." (ACK) 이 완벽한 4번의 티키타카를 해부합니다. 특히 마지막 ACK를 보낸 A는 B가 못 들었을까 봐 잠시 소켓을 열어두고 기다리는(TIME_WAIT) 배려와 그로 인한 서버 리소스 낭비의 딜레마를 뜯어봅니다.
• Implement: 포트 고갈(Port Exhaustion) 시뮬레이션. Client가 Server로 1초에 1,000개의 커넥션을 맺고 즉시 끊음(4-way). OS 규칙에 따라 끊어진 소켓은 60초간 TIME_WAIT 상태로 포트를 점유함. 60초가 되기 전에 65,535개의 가용 포트를 모두 소진하여 새로운 연결이 거부되는 [ERROR] Cannot assign requested address 현상 콘솔 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Transport Layer Protocols
• [P5] SFIA - Network Design (NTDS) - Transport Protocols (TCP/UDP)

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - The Transport Layer (TCP and UDP)
• [TCP/IP Illustrated, Volume 1] Kevin R. Fall - The Transmission Control Protocol

Industry

• [Cloudflare Learning Center] - What is a TCP 3-way handshake?
• [IETF RFC 793] - Transmission Control Protocol (TCP) Specification

9. Final Checklist

Primary

• IP 주소(L3)만으로는 컴퓨터 안에서 동시에 실행되는 웹 브라우저와 게임 클라이언트를 구별할 수 없음을 지적하고, 포트(Port) 번호를 통한 다중화(Multiplexing)와 역다중화 원리를 설명할 수 있는가?
• 데이터가 중간 라우터에서 순서가 뒤섞이거나 유실(Drop)되었을 때, 이를 무시하고 다음 프레임을 빨리 넘기는 UDP와, 순서 번호(Seq)를 확인해 재요청(Retransmission)하여 완벽히 조립하는 TCP의 철학 차이를 증명할 수 있는가?

Secondary

• TCP가 신뢰성 있는 통신을 시작하기 전, 양쪽 OS 커널이 소켓 버퍼를 초기화하고 초기 순서 번호(ISN)를 교환하는 3-Way Handshake(SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK)의 3단계를 해부할 수 있는가?
• 악의적인 해커가 가짜 IP로 SYN 패킷만 미친 듯이 보내고 마지막 ACK를 응답하지 않아, 서버의 연결 대기 큐(Backlog Queue)를 가득 채워 마비시키는 SYN Flooding 공격의 원리를 논증할 수 있는가?

Industry

• TCP 4-Way Teardown 과정에서 발생하는 TIME_WAIT 상태의 네트워크 공학적 필요성을 이해하고, 초당 1,000건의 연결이 맺어지고 끊어지는 대용량 서버에서 발생할 수 있는 포트 고갈(Port Exhaustion) 리스크를 평가할 수 있는가?
• 단 하나의 큰 파일을 다운로드하는 경우(TCP 적합)와, 초당 60프레임이 실시간으로 쏟아지는 FPS 게임의 좌표 데이터 동기화(UDP 적합) 사이의 아키텍처적 트레이드오프(Overhead vs Reliability)를 설계에 반영할 수 있는가?