한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › TCP 재전송의 근본 원인

경로 변경·ECMP 불량 경로 Route change / bad ECMP member

원인 ID rt-path · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

그림과 실험이 있는 원본 카드로 열기 →

인터넷 경로가 바뀌는 몇 초 동안, 또는 여러 ECMP 경로 중 불량인 경로에 배정된 연결에서 패킷이 사라집니다.

왜 BGP 경로 재계산, 또는 여러 경로(ECMP·LAG) 중 한 경로의 장비·회선 불량 → 그러면 경로 전환 중 일시 손실, 또는 그 경로를 타는 연결만 꾸준한 손실 → 화면에서는 갑자기 몇 초 멈춘 뒤 몰아치기, 또는 “재접속하면 나아짐”(다른 경로로 배정)

증상
멈춤, 몰아치기, 순간이동
요인
손실
누가 겪나
특정 지역·통신사
언제
가끔 무작위로
담당
주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일
연결별 재전송 통계(TCP_INFO)를 남겨 겪는 사람의 IP·포트와 시각을 뽑을 수 있게 하기, 몇 초 멈춘 연결을 바로 끊지 않기.
인프라팀 할 일
지역·통신사별 재전송률 모니터링, 재접속으로 경로가 바뀌는지 확인, 여러 통신사 회선 확보, 우리 장비의 ECMP·LAG 경로 중 불량 링크 점검, 경로 측정도 게임과 같은 TCP 포트로(mtr --tcp --port. 경로는 주소·포트로 정해지므로 보통 핑은 다른 경로로 가서 멀쩡하게 나오기도 함).
외부 할 일
통신사에 같은 TCP 포트로 잰 경로 측정 결과와 재접속 전후 비교를 붙여 불량 경로 보고.
그래프에서는
어느 순간부터 계단처럼 올라감 · RTT(핑), 지역·통신사별 재전송률
확인할 곳
bcc tcpretrans -c로 재전송을 연결별로 모아 겪는 유저의 주소·포트를 뽑고, 서버에서 유저 쪽으로, 유저 쪽에서 서버로 게임과 같은 TCP 포트로 mtr(mtr -T -P PORT)을 떠서 비교함. 재접속 전후 결과도 비교함
이러면 맞음
어느 시각을 기점으로 한 지역·통신사의 RTT가 계단처럼 바뀌며 몇 초 손실이 몰리거나, 같은 통신사 안에서도 일부 연결(주소·포트 조합)만 꾸준히 재전송하고 재접속하면 나아짐. 일반 ping은 멀쩡한데 TCP mtr에서만 손실이 보이기도 함
이러면 아님
그 통신사의 모든 연결이 저녁 피크에 함께 나빠지면 “병목 대기열 넘침”. 한 유저만 나쁘고 공유기까지 가는 ping부터 손실이면 “무선 구간 손실”
확인 수단
인프라 도구로 확인(게임 코드 불필요)
실제 사례
Cloudflare 2020: Cloudflare 백본 설정 오류로 일부 도시의 트래픽 손실

출처

  1. RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
    다중 경로에서는 ping·traceroute 같은 진단 도구의 결과를 믿기 어렵고, 흐름을 해시해 경로를 고정하는 방식을 설명
  2. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
    ECMP는 흐름을 구분하는 헤더 필드의 해시로 다음 경로를 고름(같은 흐름은 같은 경로)
  3. tcp(7) — Linux manual page Linux man-pages
    TCP_INFO: 소켓별 상태(struct tcp_info) 조회
  4. mtr(8) manual page source mtr
    -T(--tcp)는 ICMP 대신 TCP SYN으로, -P(--port)는 대상 포트 지정
  5. Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
    재전송마다 상대 주소·포트를 한 줄씩 보여 주고 -c는 흐름별 재전송 수를 집계

함께 보면 좋은 원인

같은 층: TCP 재전송의 근본 원인

같은 증상(멈춤)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기