Tobias Fiebig가 느린 TCP의 원인을 가상 NIC에서 찾았다

요약

RIPE 93에서 Tobias Fiebig가 설명한 느린 전송은 처음엔 접속망의 속도 제한처럼 보였다. 서버 방화벽에서 관련 ICMP를 허용해도 나아지지 않았고, 패킷 캡처와 가상 머신 비교에서 서로 다른 가상 네트워크 카드가 드러났다.
장애가 난 RTL8139의 TCP 오프로딩은 MTU 1,500바이트에 묶여 있었다. 경로 조회 결과는 1,420바이트였고, 더 구체적인 경로의 MTU를 1,320으로 고정하자 전송이 회복됐다.

분석

다운로드가 느리면 접속망 사업자가 먼저 의심받기 쉽다. 하지만 Tobias Fiebig가 RIPE 93 폐회 총회에서 보여준 패킷 기록은 가상 머신 안쪽, 오래된 네트워크 카드 에뮬레이션을 가리켰다. 네트워크가 보내는 신호와 가상 카드가 실제로 따르는 값이 달랐다.

문제는 MTU 1,500바이트보다 작은 경로를 지나는 대용량 전송에서 나타났다. 바로 옆의 다른 가상 머신에서는 같은 서비스가 작동했다. 방화벽이 “packet too big” ICMP를 막는다는 설명은 그럴듯했다. 서버 측 방화벽을 고쳐 해당 메시지를 통과시켰지만 속도는 그대로였다. 설정 하나는 바뀌었고, 원인은 남아 있었다.

Fiebig가 장애 클라이언트의 경로 정보를 살펴보자 MTU 1,420바이트가 나왔다. 호스트는 자신의 로컬 인터페이스보다 좁은 경로를 이미 알고 있었다. 그런데도 TCP 재전송이 이어졌다. 그는 더 구체적인 경로를 추가하고 MTU를 1,320바이트로 고정했다. 그제야 전송이 작동했다. 1,420은 경로 조회에서 얻은 값이고 1,320은 실제로 효과가 난 우회 설정이다.

재현용 가상 머신은 소프트웨어를 똑같이 맞추고도 실패를 재현하지 못했다. 같은 테스트 패킷을 보냈지만 문제가 없었다. Fiebig가 가상 하드웨어를 비교했을 때 차이가 보였다. 장애 게스트는 Realtek RTL8139를 에뮬레이션했고 테스트 게스트는 다른 어댑터를 사용했다. 소프트웨어만 복제한 테스트는 고장 난 조건을 놓쳤다.

조사는 QEMU의 net/hw/8139.c로 이어졌다. Fiebig는 TCP 오프로딩이 고정 MTU 1,500바이트를 사용하는 동작을 짚었다. QEMU 공식 이슈 1312도 MTU 1,500 미만 링크에서의 낮은 전송률, PMTUD 무시, 재전송, 게스트 OS MTU를 낮췄을 때의 완화를 기록한다. 발표에서 Fiebig는 관련 코드가 2006년에 시작됐다고 말하고 2016년 논의와 패치 제안을 언급했다. TCP 오프로딩을 끄는 방법도 가능했고, 그가 설명한 시스템에서는 구형 가상 카드를 VirtIO로 바꾸자 문제가 사라졌다.

Path MTU Discovery는 전송 양 끝이 경로에서 가장 좁은 링크에 맞춰 패킷 크기를 조절하도록 돕는다. RFC 1191은 IPv4 경로 MTU 발견을 설명하고 RFC 2923은 ICMP 알림이 빠지거나 잘못 처리될 때 발생하는 TCP 문제를 정리한다. 따라서 방화벽을 먼저 의심한 건 자연스러웠다. 방화벽 변경이 효과가 없었다면 다음 조사 지점은 게스트와 가상 NIC 사이였다.

실제 패킷을 수집하고, 경로가 학습한 MTU를 확인하고, 가상 NIC 모델과 오프로딩 상태를 함께 기록하는 순서가 시간을 아낀다. 공개 자료에는 장애 VM의 정확한 QEMU 버전과 오프로딩 설정이 없다. 그 두 값이 있어야 같은 조합의 확산 범위를 판단할 수 있다.