핵심 인사이트 (3줄 요약)

  1. 본질: RTO(Retransmission TimeOut)는 내가 패킷을 쏘고 나서 "도대체 상대방의 영수증(ACK)이 올 때까지 몇 초를 기다렸다가, 안 오면 포기하고 재전송을 때려야 할까?"를 라우터가 혼자 끙끙 앓으며 계산해 내는 절대적인 대기 인내심 타이머 시간이다.
  2. 제이콥슨 알고리즘 (동적 측정의 핵심): 핑(RTT)이 한국은 10ms고 미국은 200ms인데 타이머를 고정 3초로 퉁치면 비효율의 극치다. 그래서 TCP는 매번 쏠 때마다 핑 타임을 재고, 평균값(SRTT)과 들쭉날쭉한 정도(편차, RTTVAR)를 수학 공식에 넣어 "아, 이 목적지랑 통신할 땐 2.4초 정도 기다려주는 게 최적이네!"라고 매 순간 유동적으로 RTO를 갱신한다.
  3. 칸 알고리즘 (Karn's Algorithm): 재전송을 갈겼을 때 치명적인 딜레마(재전송한 놈의 영수증인지, 원래 놈의 영수증이 지각한 건지 모름)를 해결하기 위해, "재전송한 패킷으로 돌아온 영수증은 핑 타임 계산(RTO 공식)에서 무조건 빼버려라!"라고 못을 박은 천재적인 오염 방지 기술이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: TCP 송신 측이 세그먼트를 전송한 후, 수신 확인(ACK) 패킷이 도달할 때까지 기다리는 최대 허용 시간(Timeout). 이 시간이 경과하면 패킷 유실로 간주하고 재전송(Retransmission)을 수행한다.

  • 필요성: 내가 게임 아이템 구매 요청 패킷을 넥슨 서버에 쐈다. 응답이 안 온다. 0.1초 만에 "안 왔어! 재전송 쏴!" 하면 넥슨 서버는 똑같은 요청을 두 번 받아 결제가 2중으로 될 위험이 있고, 대역폭도 낭비된다. 반대로 10초나 기다리면 내 게임 화면은 10초 동안 프리징(렉) 걸린다. "기다리긴 기다려야 하는데, 너무 짧지도 않고 너무 길지도 않게, 딱 상대방과 나 사이의 도로 사정에 완벽히 들어맞는 '황금 타이머(RTO)'를 어떻게 수학적으로 구할 것인가?"

  • 💡 비유: RTO는 짜장면 배달 주문의 **"독촉 전화 대기 시간"**과 같습니다.

    • 우리 집 옆 중국집은 보통 15분이면 배달이 옵니다. 나는 주문하고 **15분+여유 시간 5분 = 20분(RTO)**을 기다리다가 안 오면 "아저씨 언제 와요!(재전송)"라고 전화를 겁니다.
    • 그런데 저 멀리 30km 밖 맛집에 배달을 시키면 1시간이 걸립니다. 여기서 내가 20분 만에 독촉 전화를 걸면 미친놈 소리를 듣습니다. 이때는 내 인내심(RTO)을 자동으로 1시간 10분으로 늘려 잡아야 합니다. 이것이 동적 RTO 계산입니다.

📢 섹션 요약 비유: RTO는 라면 물 끓이기 타이머입니다. 물의 양과 화력(네트워크 상태)이 매번 다르기 때문에, 고정된 시간 3분(고정 타이머)에 무조건 면을 넣는 바보짓을 버리고, 물이 끓는 속도를 실시간으로 눈으로 보며(RTT 측정) 면 넣는 타이밍(RTO)을 유동적으로 바꾸는 셰프의 감각입니다.

Ⅱ. RTO의 계산 마법과 칸 알고리즘 (Deep Dive)

네트워크의 지연율(RTT)은 수시로 변한다. TCP는 이를 3단계의 정밀한 수학 공식을 통해 추적한다.

1. SRTT와 RTTVAR (제이콥슨의 마법 공식)

TCP는 영수증이 올 때마다 걸린 시간(RTT)을 초시계로 잰다. 하지만 한 번 튀었다고 그 값을 맹신하면 안 된다. 과거의 기억을 부드럽게 섞어준다.

  • SRTT (평활화된 RTT): 이전 평균값 87.5% + 방금 잰 시간 12.5%. 이렇게 가중 평균을 내어 순간적으로 핑이 확 튀어도 부드러운 언덕(이동 평균)을 유지하게 한다.
  • RTTVAR (RTT 편차): 핑이 안정적인지(계속 20ms 유지), 널뛰기하는지(10ms ~ 100ms 지랄 발광) 변동성을 측정한다.
  • 최종 RTO 공식: RTO = SRTT + 4 × RTTVAR
    • 해석: "평균 시간(SRTT)만큼 기다려주되, 만약 이 동네 네트워크가 널뛰기가 심한 양아치 망(RTTVAR가 높음)이라면, 여유 시간(×4)을 엄청 넉넉하게 더 줘서 섣부른 재전송(독촉 전화)을 막아라!"

2. 칸 알고리즘 (Karn's Algorithm)의 오염 방지 룰

엄청나게 유명한 시험 단골 출제 문제다. (재전송의 딜레마).

  • 상황: 내가 1번 패킷을 쐈다. RTO(예: 3초)가 다 지났는데 답(ACK)이 안 와서, 눈물을 머금고 1번 패킷을 다시(재전송) 쐈다.
  • 사건 발생: 재전송을 갈기고 0.1초 뒤에 띠링~ 하고 1번 ACK 영수증이 도착했다!
  • 미쳐버린 딜레마: 내 PC의 뇌구조는 멘붕에 빠진다. "야, 방금 도착한 이 영수증... 아까 3.1초 전에 보냈던 원본 패킷이 지각해서 이제 온 걸까? 아니면 내가 방금 0.1초 전에 재전송한 패킷이 빛의 속도로 튕겨서 온 걸까?"
  • 만약 지각한 놈(3.1초)인데 빛의 속도(0.1초)라고 착각해서 RTO 공식에 넣어버리면? 내 PC는 "오 핑 0.1초 짱 빠르네!" 착각하고 RTO 타이머를 0.1초로 확 줄여버린다. 결국 다음 패킷부터 0.1초마다 미친 듯이 재전송 폭풍을 갈겨대어 인터넷을 망가뜨린다.
  • 칸의 해결책: "재전송한 패킷에 대해서 날아온 영수증은 출처가 불분명한 썩은 물이니까, 아예 RTO 측정 공식(타이머 갱신)에 한 방울도 섞지 마라! 무시해라!!" 이 한마디로 TCP의 계산 오염을 완벽히 차단했다.
 ┌─────────────────────────────────────────────────────────────┐
 │                칸 알고리즘(Karn's Algorithm) 딜레마 시각화        │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 내 PC ]                                       [ 목적지 ]   │
 │   1. 1번 패킷 (원본) ────────(엄청 늦게 기어감)────────▶        │
 │                                                             │
 │   2. (3초 타이머 만료!!)                                        │
 │   3. 1번 패킷 (재전송) ────────(빛의 속도로 날아감)───▶        │
 │                                                             │
 │   4. 영수증(ACK) 도착!! ◀────────────────────────       │
 │                                                             │
 │   * 내 PC의 멘붕: "저 영수증은 1번 원본이 3초 만에 만든 걸까,        │
 │                  3번 재전송이 0.1초 만에 만든 걸까? 알 수가 없다!!"  │
 │                                                             │
 │   * 칸의 철칙: "출처가 헷갈리는 영수증은 평균 핑 타임 계산에서 무조건  │
 │               제외(Ignore)시켜 계산 수질 오염을 막아라!!"          │
 └─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: RTO 계산 공식은 사장님의 **"납기일 산정법"**입니다. 직원(네트워크)의 평소 평균 작업 속도(SRTT)에다가, 이 직원이 평소에 얼마나 자주 지각하는지(RTTVAR 편차)를 곱해서 **아주 넉넉하고 합리적인 며칠짜리 데드라인(RTO)**을 세팅해, 쓸데없는 쪼쪼기(재전송)를 줄이는 고도의 인력 관리 스킬입니다.