작은 요청은 되는데 큰 응답만 멈추는 이유는 뭘까요?¶

연결이 됐고 작은 요청도 성공하면 길은 멀쩡한 것 같죠? 사실은 큰 패킷만 조용히 사라지는 길일 수 있어요.

MTU, Fragmentation, 그리고 Path MTU에서는 길마다 한 번에 통과시킬 수 있는 패킷 크기가 다르고, 너무 큰 패킷을 줄이라는 ICMP 힌트가 사라지면 MTU black hole이 생길 수 있다는 큰 그림을 봤어요.

그리고 ICMP와 ICMPv6 Type에서는 IPv4의 Type 3, Code 4와 IPv6의 Packet Too Big이 경로 MTU를 알려주는 중요한 메시지라는 것도 봤죠.

이번에는 그 장면을 실제 장애처럼 읽어볼게요.

• DNS 조회는 성공해요.
• TCP 3-way handshake도 끝나요.
• 짧은 API 응답이나 작은 파일은 잘 받아요.
• 그런데 로그인 뒤 큰 페이지, 파일 다운로드, 인증서가 긴 HTTPS 응답처럼 데이터가 커지는 순간 멈춰요.
• 서버는 같은 TCP 구간을 여러 번 재전송해요.
• 필요한 ICMP 메시지는 발신자에게 돌아오지 않아요.
• 결국 브라우저는 오래 기다리다가 timeout으로 끝나요.

이 증상은 서버가 느리거나 방화벽이 연결을 막은 것처럼 보이기 쉬워요. 하지만 연결 자체는 이미 열렸어요.

"작은 패킷이 지나갔다는 사실이, 큰 패킷도 지나간다는 뜻일까요?"

먼저 장애 장면을 한 줄로 줄여볼게요¶

서버 쪽 인터페이스 MTU는 1500이고, 경로 중간에 VPN 터널이 하나 있다고 해볼게요. 터널 헤더가 바깥에 더 붙으면서 실제로 안쪽 IP 패킷이 안전하게 지나갈 수 있는 크기는 1400이 됐어요.

서버는 자기 첫 링크만 보고 1500바이트 패킷을 보낼 수 있다고 생각해요. 하지만 경로 중간에서는 그 크기를 그대로 통과시킬 수 없어요.

정상이라면 중간 장비가 "이 길에서는 더 작게 보내세요"라는 ICMP 메시지를 돌려줘야 해요. 발신자는 그 값을 보고 패킷 크기를 줄이고 다시 보내고요.

문제는 그 안내문이 돌아오지 않을 때예요.

sequenceDiagram
    participant C as 클라이언트
    participant T as 좁은 터널 구간
    participant S as 서버

    C->>S: TCP SYN
    S-->>C: SYN-ACK
    C->>S: ACK
    C->>S: 작은 HTTP 요청
    S-->>C: 작은 응답 헤더
    S->>T: 큰 TCP 데이터<br/>경로 MTU보다 큼
    T--xC: 패킷 폐기
    T-->>S: ICMP Too Big 필요
    Note over T,S: ICMP가 필터링되거나 전달되지 않음
    S->>T: 같은 TCP 구간 재전송
    T--xC: 다시 폐기
    S->>T: 같은 구간 반복 재전송
    T--xC: 다시 폐기
    Note over C,S: 연결은 열렸지만 데이터가 앞으로 가지 않음

이 그림에서 TCP handshake가 성공한 이유는 handshake 패킷이 작기 때문이에요. 짧은 요청과 응답 헤더도 좁은 길을 통과할 수 있어요. 문제는 서버가 경로 MTU보다 큰 첫 데이터 패킷을 보내는 순간부터 시작돼요.

기본 감각을 실제 장애 신호로 바꿔봐요¶

기본편에서 본 길과 짐의 비유를 실제 용어로 옮기면 이렇게 돼요.

여기서 black hole은 모든 패킷을 삼키는 장비 이름이 아니에요. 특정 크기보다 큰 패킷은 사라지는데, 왜 사라졌는지 알려주는 피드백도 돌아오지 않는 상태를 설명하는 표현이에요.

먼저 읽을 신호 일곱 가지¶

MTU black hole은 "접속 불가"보다 일부만 되는 장애로 나타나는 경우가 많아요. 그래서 성공한 신호와 실패한 신호를 같이 모아야 해요.

flowchart TD
    A[요청이 중간에서 멈춤] --> B{TCP handshake는 끝났나요?}
    B -->|아니오| C[라우팅, 방화벽, SYN 경로부터 확인]
    B -->|예| D{작은 데이터는 지나가나요?}
    D -->|아니오| E[TLS, 정책, 서버 처리, 일반 손실도 확인]
    D -->|예| F{큰 구간만 같은 sequence로 재전송되나요?}
    F -->|아니오| G[앱 지연, 혼잡, 수신 윈도우 등 확인]
    F -->|예| H{ICMP Too Big 피드백이 발신자에 도착하나요?}
    H -->|예| I[발신자의 PMTU 반영과 재패킷화 확인]
    H -->|아니오| J[MTU black hole 경로 조사]

이 흐름은 MTU 문제를 한 번에 확정하는 공식이 아니에요. 다만 연결이 열렸는지, 크기에 따라 결과가 갈리는지, 같은 큰 구간이 반복되는지, ICMP 피드백이 있는지를 차례로 보면 다른 장애와 훨씬 빨리 갈라낼 수 있어요.

캡처에서는 "같은 큰 구간"이 반복되는지 봐요¶

아래는 읽기 연습을 위한 축약 예시예요. 실제 tcpdump 출력은 TCP 옵션, checksum offload, 상대 sequence 표시 방식에 따라 다르게 보일 수 있어요.

10:20:00.100 C > S  Flags [S],  seq 1000, length 0
10:20:00.110 S > C  Flags [S.], seq 5000, ack 1001, length 0
10:20:00.120 C > S  Flags [.],  ack 5001, length 0

10:20:00.130 C > S  Flags [P.], seq 1001:1211, ack 5001, length 210
10:20:00.140 S > C  Flags [.],  ack 1211, length 0

10:20:00.150 S > C  Flags [P.], seq 5001:6449, ack 1211, length 1448
10:20:01.160 S > C  Flags [P.], seq 5001:6449, ack 1211, length 1448
10:20:03.180 S > C  Flags [P.], seq 5001:6449, ack 1211, length 1448
10:20:07.220 S > C  Flags [P.], seq 5001:6449, ack 1211, length 1448

앞부분에서는 handshake와 210바이트 요청이 성공했어요. 그다음 서버가 보낸 seq 5001:6449 구간은 같은 범위로 반복돼요.

이때 중요한 건 단순히 retransmission이 있다가 아니에요.

TCP 재전송만으로 MTU 문제를 확정할 수는 없어요. 혼잡, 무선 손실, 방화벽 정책, 수신자 장애도 재전송을 만들 수 있거든요.

MTU 쪽으로 무게가 실리는 건 작은 패킷은 안정적으로 성공하는데 일정 크기 이상의 패킷만 같은 지점에서 반복 실패하는 패턴이에요.

ICMP는 어느 캡처 위치에서 사라졌는지 나눠봐요¶

발신자 서버에서 ICMP가 안 보인다고 해서, 중간 라우터가 아예 만들지 않았다고 바로 결론 내리면 안 돼요.

flowchart LR
    S[서버<br/><small>큰 패킷 발신</small>] --> F1[서버 앞 방화벽]
    F1 --> T[터널 / 좁은 경로]
    T --> F2[상대편 방화벽]
    F2 --> C[클라이언트]

    T -. ICMP Too Big .-> F1
    F1 -. 필터링될 수 있음 .-> S

ICMP 피드백은 여러 이유로 사라질 수 있어요.

• 중간 라우터가 필요한 ICMP를 만들지 않아요.
• 방화벽이 모든 ICMP 차단 정책으로 함께 버려요.
• 터널 장비가 바깥 패킷의 오류를 안쪽 발신자에게 제대로 전달하지 못해요.
• NAT가 ICMP 안에 인용된 원래 패킷 정보를 올바르게 변환하지 못해요.
• 비대칭 경로 때문에 ICMP의 돌아오는 길이 달라져요.
• 장비의 ICMP rate limit 때문에 일부 메시지만 보여요.

그래서 가능하다면 한 지점의 캡처로 끝내지 말고, 큰 패킷이 사라지기 전과 후, ICMP가 생성되는 쪽과 발신자 쪽을 나눠서 봐야 해요.

왜 ping은 되는데 웹은 멈출까요?¶

기본 ping은 보통 작은 payload를 사용해요. 그래서 경로 MTU가 1400이어도 작은 Echo Request와 Echo Reply는 문제없이 지나갈 수 있어요.

작은 ping
  IP packet 84 bytes
  -> 좁은 경로 통과

큰 TCP data
  IP packet 1500 bytes
  -> 좁은 경로에서 폐기
  -> ICMP 피드백도 사라짐

이 때문에 아래 결과가 동시에 나올 수 있어요.

즉 ping 성공은 모든 크기의 패킷이 안전하게 지나간다는 증명이 아니에요. 게다가 어떤 네트워크는 Echo 메시지는 막고 TCP는 허용하기도 하니, 반대 방향으로도 단정하면 안 되고요.

크기를 바꿔가며 경계를 찾을 수 있어요¶

Linux의 ping 구현에서는 IPv4 패킷을 조각내지 않도록 요청하고 payload 크기를 바꿔볼 수 있어요.

ping -4 -M do -s 1472 203.0.113.20
ping -4 -M do -s 1372 203.0.113.20

일반적인 IPv4 헤더 20바이트와 ICMP 헤더 8바이트를 가정하면:

큰 값은 실패하고 작은 값은 성공한다면 크기 경계를 의심할 근거가 생겨요. 하지만 이 테스트에도 한계가 있어요.

• ping 옵션은 운영체제마다 달라요.
• ICMP Echo와 실제 TCP/UDP 트래픽의 경로·정책이 다를 수 있어요.
• 로드 밸런싱 때문에 패킷 크기나 5-tuple에 따라 다른 경로를 탈 수도 있어요.
• IPv4 옵션이나 터널 헤더가 있으면 단순히 28바이트만 더하는 계산이 달라져요.
• 성공과 실패가 갈리는 값이 보여도 어느 장비가 좁은지는 별도 캡처가 필요해요.

Linux에서는 tracepath가 경로 MTU 변화를 찾는 데 도움을 줄 때도 있어요.

tracepath 203.0.113.20
tracepath -6 2001:db8::20

다만 중간 장비가 응답하지 않거나 경로가 비대칭이면 결과가 완전하지 않을 수 있어요. 도구 하나의 숫자보다 실제 애플리케이션 재현, 양쪽 캡처, 인터페이스·터널 MTU 설정을 함께 보는 편이 안전해요.

업로드는 되고 다운로드만 멈출 수도 있어요¶

인터넷 경로는 양방향이 완전히 같은 길이라고 보장되지 않아요. 그래서 MTU black hole도 한 방향에서만 드러날 수 있어요.

예를 들어 클라이언트가 보내는 요청은 작아서 서버까지 도착해요. 서버가 보내는 응답은 커서 반대 방향의 좁은 터널에서 막힐 수 있어요.

반대로 큰 파일 업로드만 실패하고 작은 다운로드는 잘될 수도 있고요.

그래서 장애를 기록할 때는 "통신이 안 된다"보다 이렇게 적는 편이 좋아요.

"클라이언트에서 서버로 보내는 300바이트 요청은 도착하지만, 서버에서 클라이언트로 보내는 첫 1448바이트 TCP payload부터 ACK가 진행하지 않아요."

이렇게 방향과 크기를 적으면 조사 범위가 훨씬 작아져요.

MSS가 맞아도 MTU 문제가 생길 수 있을까요?¶

TCP handshake에서는 양쪽이 한 TCP 세그먼트에 어느 정도 payload까지 받을 수 있는지 MSS 옵션으로 알려줄 수 있어요.

Ethernet MTU 1500을 기준으로 IPv4 TCP 옵션이 없는 단순 계산을 하면 흔히 이런 숫자를 떠올려요.

1500 - IPv4 header 20 - TCP header 20 = MSS 1460

그런데 경로 중간에 터널이 생겨 실제 PMTU가 1400이라면, 1460바이트 TCP payload는 너무 클 수 있어요.

방화벽이나 터널 장비가 TCP SYN의 MSS 값을 경로에 맞게 낮추는 MSS clamping을 쓰기도 해요. 이 방식은 TCP 트래픽에서 큰 세그먼트가 만들어지는 일을 줄일 수 있어요.

하지만 MSS clamping을 모든 문제의 정답으로 보면 안 돼요.

• UDP에는 TCP MSS가 없어요.
• IPv6와 다른 전송 프로토콜도 별도로 봐야 해요.
• 경로가 바뀌면 고정값이 다시 틀릴 수 있어요.
• 너무 낮게 잡으면 불필요하게 작은 패킷을 많이 보낼 수 있어요.
• ICMP 전달이나 터널 MTU 설정이 잘못된 근본 원인은 남을 수 있어요.

MSS clamping은 필요한 경계에서 쓸 수 있는 운영 도구지만, 먼저 어느 캡슐화가 몇 바이트를 더하고 실제 경로 MTU가 얼마인지를 확인해야 해요.

잘못 읽기 쉬운 함정 여섯 가지¶

또 하나 자주 생기는 오해는 "큰 응답이면 애플리케이션이 늦게 만들었겠지"예요. 서버 로그에서는 응답 생성이 이미 끝났는데 클라이언트가 받지 못할 수도 있어요.

이때는 앱 처리 시간만 보지 말고:

• 서버가 응답을 언제 쓰기 시작했는지
• 커널이 같은 TCP 구간을 재전송하는지
• 클라이언트 ACK가 어디서 멈췄는지
• 앞단 프록시가 client write timeout으로 끝냈는지

를 같은 시간축에 놓아야 해요.

실제 대응은 이 순서로 잡아요¶

flowchart TD
    A[작은 통신 성공<br/>큰 전송 정지] --> B[방향과 실패 크기 기록]
    B --> C[양쪽 TCP 캡처로<br/>sequence와 ACK 진행 확인]
    C --> D[경로의 인터페이스·터널·VPN MTU 확인]
    D --> E[IPv4 Fragmentation Needed<br/>IPv6 Packet Too Big 전달 확인]
    E --> F{필요한 ICMP가 사라지나요?}
    F -->|예| G[방화벽·NAT·터널의 ICMP 처리 수정]
    F -->|아니오| H[발신자의 PMTU 반영과 재패킷화 확인]
    G --> I[필요하면 경계 MTU / MSS 조정]
    H --> I
    I --> J[작은 요청과 큰 전송을 다시 검증]

1. 증상을 방향과 크기로 다시 적어요¶

먼저 아래를 기록해요.

• 어느 출발지와 목적지 사이인지
• IPv4인지 IPv6인지
• 업로드와 다운로드 중 어느 방향인지
• 어느 정도 크기부터 실패하는지
• VPN, 터널, 특정 지점, 특정 ISP에서만 생기는지

2. 양쪽 캡처를 같은 시각으로 맞춰요¶

발신자에서는 큰 패킷이 나가는데 수신자에는 안 보이는지 확인해요. 수신자까지 도착했는데 ACK만 돌아오지 않는다면 반대 방향도 따로 봐야 하고요.

tcpdump -ni any 'host 203.0.113.20 or icmp or icmp6'

운영 캡처에서는 대상 IP, 포트, 시간 범위를 더 좁혀야 해요. TLS 트래픽이어도 TCP sequence, ACK, 길이, 재전송, ICMP 신호는 볼 수 있어요.

3. 터널 오버헤드까지 계산해요¶

VPN, GRE, VXLAN, IPsec 같은 캡슐화는 원래 패킷 바깥에 헤더를 더 붙여요. 겉 링크 MTU가 그대로여도 안쪽 패킷이 쓸 수 있는 크기는 줄어들 수 있어요.

제품과 모드마다 오버헤드가 다르니 숫자를 외워서 적용하지 말고, 실제 캡슐화와 설정을 확인해야 해요.

4. 필요한 ICMP가 끝까지 돌아오는지 확인해요¶

IPv4 PMTUD에서는 Fragmentation Needed 메시지가, IPv6에서는 Packet Too Big 메시지가 발신자에게 도달해야 패킷 크기를 줄일 수 있어요.

모든 ICMP 차단처럼 넓은 정책이 있다면 필요한 메시지까지 막고 있지 않은지 확인해요. 터널과 NAT가 ICMP 안의 인용 패킷을 원래 흐름과 연결할 수 있게 처리하는지도 중요하고요.

5. 우회책과 근본 수정을 나눠요¶

상황에 따라 다음 조치가 필요할 수 있어요.

가장 좋은 결과는 경로가 실제 크기를 정확히 알리고, 발신자가 그 값에 맞춰 다시 패킷화하는 것이에요. 단순히 모든 호스트 MTU를 작은 값으로 내리면 장애는 가려질 수 있지만, 왜 특정 경로에서만 문제가 생겼는지는 남아요.

수정 뒤에는 작은 성공 말고 큰 전송까지 확인해요¶

정책이나 MTU를 고친 뒤 ping 한 번만 성공했다고 종료하면 안 돼요. 원래 실패했던 큰 요청이나 다운로드를 같은 조건으로 다시 통과시켜야 해요.

MTU 문제는 경로별로 달라질 수 있어요. 한 클라이언트에서 성공했다고 모든 사용자의 경로가 고쳐졌다고 단정하지 말고, 실제 영향 구간을 나눠서 다시 확인해야 해요.

더 깊이 보고 싶다면¶

• RFC 1191: Path MTU Discovery — IPv4에서 DF와 ICMP Fragmentation Needed를 이용해 PMTU를 찾는 기본 흐름을 설명해요.
• RFC 8201: Path MTU Discovery for IP version 6 — IPv6의 Packet Too Big 처리와 PMTU 갱신 규칙을 설명해요.
• RFC 2923: TCP Problems with Path MTU Discovery — 작은 통신은 되지만 큰 전송이 멈추는 오래된 black hole 증상과 탐지 문제를 정리해요.
• RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports — ICMP에만 의존하지 않고 packetization layer에서 probe로 경로 크기를 탐색하는 접근을 설명해요.

자, 정리해볼까요?¶

연결이 열렸다는 사실은 출발선이 통과됐다는 뜻일 뿐이에요. 데이터가 커진 뒤에도 같은 길을 끝까지 지나가는지는 패킷 크기와 피드백을 따로 봐야 해요.

이어서 보면 좋은 글¶

• MTU와 단편화의 큰 그림부터 다시 보고 싶다면 — MTU, Fragmentation, 그리고 Path MTU
• 캡처에서 Fragmentation Needed와 Packet Too Big 번호를 읽고 싶다면 — ICMP와 ICMPv6 Type은 어떻게 읽어야 할까요?
• 같은 sequence 구간이 왜 반복되는지 TCP 관점으로 보고 싶다면 — TCP 재전송과 신뢰성
• 긴 캡처 한 줄을 읽는 순서가 아직 낯설다면 — tcpdump 한 줄은 어떻게 읽어야 할까요?