데이터 전송의 기본 원리

네트워크가 무엇이고 인터넷이 어떤 구조인지 이해했다면, 이제 그 안에서 데이터가 실제로 어떻게 전달되는지를 들여다볼 차례입니다.

인터넷이 느리다라는 말을 할 때, 정확히 무엇이 느린 것인지 자신 있게 대답할 수 있는 사람은 많지 않습니다. 이 절에서 다루는 교환 방식과 성능 지표를 이해하면, 그 질문에 답할 수 있게 됩니다.

회선 교환 vs 패킷 교환

데이터를 목적지까지 전달하는 방식은 크게 두 가지입니다.

회선 교환(Circuit Switching)은 통신을 시작하기 전에 송신자와 수신자 사이에 전용 경로(회선)를 미리 설정하는 방식입니다.

회선 교환: 전용 경로 독점
[A] ════════════════════════> [B]   (통화 중 — 회선 점유)
     다른 이용자 사용 불가

과거의 전화 통화를 떠올리면 됩니다. 전화를 걸면 두 사람 사이에 전용 회선이 할당되고, 통화가 끝날 때까지 이 회선은 다른 사용자가 사용할 수 없습니다. 대역폭이 안정적으로 보장되지만, 대화가 잠시 멈추는 순간에도 회선을 계속 점유하기 때문에 자원 낭비가 심합니다.

패킷 교환(Packet Switching)은 데이터를 패킷(Packet)이라는 작은 단위로 나누어 독립적으로 전송하는 방식입니다.

각 패킷은 목적지 주소 같은 전달 정보를 가지고 있으며, 라우터는 패킷마다 다음 홉을 결정합니다. 같은 흐름의 패킷이 항상 다른 경로를 타는 것은 아니지만, 라우팅 변화나 부하 분산 환경에서는 서로 다른 경로로 갈 수도 있습니다. 수신 측 또는 전송 계층은 필요한 경우 순서를 맞추고 손실을 복구합니다.

비교	회선 교환	패킷 교환
연결 방식	통신 전 경로와 자원 예약	패킷 단위 전달, 라우터가 다음 홉 결정
전용 경로	있음 (독점 또는 예약)	없음 (통계적 공유)
자원 효율	유휴 시간에도 예약 자원 점유	실제 트래픽이 있을 때 링크 자원 사용
지연	예약 후에는 비교적 일정	혼잡, 큐잉, 라우팅 상태에 따라 가변
확장성	연결 수와 예약 자원에 제한	많은 흐름이 같은 인프라를 공유하기 쉬움
장애 내성	예약 경로 장애 시 재설정 필요	라우팅이 수렴하면 우회 가능
적합한 용도	전통적 전화망, 전용 회선 서비스	인터넷, 데이터 중심 네트워크

오늘날의 인터넷은 기본적으로 패킷 교환 방식을 기반으로 동작합니다. 다만 MPLS, 전용 회선, 가상 회선처럼 운영자가 특정 경로나 품질을 관리하는 기술도 함께 쓰일 수 있습니다.

패킷의 구조

대부분의 네트워크 전송 단위는 크게 헤더(Header)와 페이로드(Payload)로 이해할 수 있습니다. 데이터 링크 계층 프레임처럼 끝에 FCS 같은 트레일러(Trailer)가 붙는 경우도 있습니다.

헤더는 전달과 처리를 위한 메타데이터를 담고 있습니다. 계층에 따라 출발지/목적지 주소, 포트 번호, 프로토콜 번호, TTL/Hop Limit, 순서 번호 같은 정보가 들어갑니다. 택배 상자에 붙이는 송장이라고 생각하면 직관적입니다.

페이로드는 실제로 전달하려는 데이터, 즉 "상자 안의 물건"입니다.

네트워크의 각 계층은 패킷에 자신만의 헤더를 추가합니다. 이 과정을 캡슐화(Encapsulation)라고 합니다.

수신 측에서는 역순으로 각 계층의 헤더를 벗겨내며(역캡슐화), 최종적으로 애플리케이션 데이터를 얻습니다.

MTU와 단편화

MTU(Maximum Transmission Unit)는 특정 링크에서 한 번에 실을 수 있는 최대 L3 패킷 크기입니다. 일반 이더넷의 MTU는 보통 1500바이트이지만, PPPoE, VPN, 터널링, 점보 프레임 환경에서는 달라질 수 있습니다.

mtu_check.py

ETHERNET_MTU = 1500
IP_HEADER = 20
TCP_HEADER = 20
MSS = ETHERNET_MTU - IP_HEADER - TCP_HEADER  # Maximum Segment Size

print(f"MTU: {ETHERNET_MTU} bytes")
print(f"IP 헤더: {IP_HEADER} bytes")
print(f"TCP 헤더: {TCP_HEADER} bytes")
print(f"MSS (실제 데이터): {MSS} bytes")

# 10KB 파일 전송 시 필요한 세그먼트 수
file_size = 10 * 1024
segments = -(-file_size // MSS)  # 올림 나눗셈
print(f"\n10KB 전송 → {segments}개 세그먼트 필요")

전송하려는 IP 패킷이 경로의 MTU를 초과하면 단편화(Fragmentation) 문제가 생깁니다. IPv4에서는 DF 비트가 꺼져 있으면 라우터가 단편화할 수 있지만, DF가 켜져 있으면 ICMP 오류로 송신자에게 더 작은 크기를 요구합니다. IPv6에서는 중간 라우터가 단편화하지 않고, 송신자가 Fragment 헤더를 사용해야 합니다.

단편화는 오버헤드와 손실 영향을 키우므로, 현대 네트워크에서는 Path MTU Discovery 또는 Packetization Layer PMTUD로 경로상 최소 MTU를 파악하고 전송 크기를 조절하는 방식이 중요합니다.

지연, 대역폭, 처리량

네트워크 성능을 논할 때 반드시 구분해야 하는 세 가지 핵심 지표입니다.

지연 (Latency)

지연(Latency)은 데이터가 출발지에서 목적지까지 도달하는 데 걸리는 시간입니다.

지연 유형	원인	특징	줄이는 방법
전파 지연	물리적 거리, 매체 속도	거리의 영향을 크게 받음	서버를 가까이 배치, CDN 활용
전송 지연	패킷 크기 / 링크 속도	큰 패킷과 낮은 링크 속도에서 증가	대역폭 확장, 압축, 전송량 축소
처리 지연	장비의 헤더 검사와 처리	장비 성능과 기능에 따라 달라짐	고성능 장비, 불필요한 처리 감소
큐잉 지연	버퍼 대기, 트래픽 집중	혼잡할수록 급격히 증가	혼잡 제어, QoS, 트래픽 분산

latency_measurement.sh

# RTT(Round-Trip Time) 측정
ping -c 10 google.com
# 결과: min/avg/max/mdev = 3.2/4.1/5.8/0.7 ms

# 경로별 지연 측정
traceroute -n google.com
# 각 홉(라우터)에서의 RTT를 확인

# HTTP 요청의 각 단계별 시간 측정
curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

대역폭과 처리량

대역폭(Bandwidth)은 단위 시간당 전송할 수 있는 최대 데이터량입니다. 도로에 비유하면 차선 수에 해당합니다.

처리량(Throughput)은 실제로 전송된 데이터량입니다. 혼잡, 패킷 손실, 프로토콜 오버헤드, 수신/송신 장비 성능 때문에 처리량은 보통 명목 대역폭보다 낮습니다.

bandwidth_vs_throughput.py

def calculate_throughput(bandwidth_mbps, packet_loss_pct, overhead_pct):
    """실제 처리량 추정"""
    effective = bandwidth_mbps * (1 - packet_loss_pct / 100)
    effective *= (1 - overhead_pct / 100)
    return effective

# 1Gbps 회선, 패킷 손실 0.1%, 프로토콜 오버헤드 5%
throughput = calculate_throughput(1000, 0.1, 5)
print(f"대역폭: 1000 Mbps")
print(f"실제 처리량: {throughput:.1f} Mbps")

# 대용량 파일 전송 시간 추정
file_size_gb = 10
transfer_time = (file_size_gb * 8 * 1024) / throughput
print(f"\n10GB 파일 전송: {transfer_time:.0f}초 ({transfer_time/60:.1f}분)")

핵심 비유: 대역폭은 파이프의 굵기, 지연은 파이프의 길이, 처리량은 실제로 흐르는 물의 양입니다.

병목과 혼잡의 차이

네트워크가 느리다라는 증상은 같지만, 원인은 크게 두 가지로 나뉩니다.

병목(Bottleneck)은 경로 중 가장 좁은(대역폭이 낮은) 구간이 전체 성능을 제한하는 현상입니다.

서버 ──1Gbps──→ 라우터 ──1Gbps──→ ISP ──100Mbps──→ 사용자
                                           ↑
                                      병목 지점!
                                  처리량 상한 = 100Mbps

혼잡(Congestion)은 특정 지점에 트래픽이 한꺼번에 몰려 큐잉 지연이 급증하고, 심하면 패킷 손실이 발생하는 현상입니다.

라우터의 버퍼가 가득 차면 새로 도착하는 패킷을 버리거나, ECN처럼 혼잡 신호를 표시할 수 있습니다. 송신 측이 손실을 감지하고 재전송을 늘리는데 전송량을 줄이지 않으면, 재전송 트래픽이 다시 혼잡을 키워 혼잡 붕괴(Congestion Collapse)로 이어질 수 있습니다. 그래서 TCP 혼잡 제어는 손실이나 ECN 신호를 기반으로 송신량을 조절합니다.

구분	병목	혼잡
원인	경로 중 상대적으로 낮은 용량 구간	순간 트래픽 집중과 버퍼 대기
특성	구조적으로 오래 지속될 수 있음	시간대와 부하에 따라 변동
증상	처리량 상한 제한	지연 급증, 지터 증가, 패킷 손실
해결	회선 증설, CDN, 캐시, 경로 개선	혼잡 제어, QoS, 로드 밸런싱, AQM

bottleneck_check.sh

# 경로상 병목 확인
mtr -rw -c 20 example.com
# 각 홉의 패킷 손실률과 지연을 확인

# 대역폭 측정 (서버 필요)
iperf3 -c server.example.com -t 30
# → 실제 achievable throughput 측정

이어지는 장에서는 이처럼 복잡한 네트워크의 동작을 체계적으로 이해하기 위해, 통신을 계층별로 분리하는 모델을 살펴보겠습니다.