idea·blog

04 · 사라진 데이터 다시 보내기

받았다는 답이 없으면 다시 보냅니다.

택배 수령 확인이 오지 않으면 같은 상자를 다시 보내는 것과 비슷합니다. 데이터나 답장이 사라졌을 때 복구되는 흐름만 따라가 보세요.

이것만 기억하세요받았다는 답이 없으면
다시 보낸다

아래 파란 버튼만 누르세요

사라진 뒤 다시 도착하는 5장면

시나리오
  1. 1조각 보내기
  2. 2조각 유실
  3. 3답 없음
  4. 4다시 보내기
  5. 5복구 완료
준비
‘조각이 사라질 때’ 실험을 시작할 준비가 됐어요

아래 ‘실험 시작’을 누르면 지금 무슨 일이 생겼는지 한 장면씩 보여드려요.

대기 중
내 컴퓨터192.168.0.10
조각 1대기조각 2대기
타이머 꺼짐
Redis 서버192.168.0.20 : 6379
?아직?아직
번호로 중복을 걸러요
시나리오: 조각이 사라질 때보내기 시작을 누르면 데이터 두 조각이 어떤 일을 겪는지 한 단계씩 보여드려요. 시나리오를 바꿔가며 비교해 보세요.

약속 세 가지만

패킷이 사라져도 데이터가 완성되는 이유

01받은 범위를 알려줘요.

서버는 “여기까지 받았다”고 ACK으로 알려줘요. 실제 TCP에서는 여러 바이트를 한 번의 누적 ACK으로 확인할 수도 있어요.

02답이 없으면 다시 보내요.

보낸 쪽은 아직 확인되지 않은 데이터를 위해 타이머를 관리해요. 시간이 지나면 가장 앞의 미확인 조각부터 다시 보내요.

03번호로 중복을 빼요.

답장이 사라져서 같은 조각이 두 번 도착해도, 받는 쪽은 번호를 보고 이미 받은 범위를 알아봐요. 같은 바이트를 받은 데이터에 두 번 넣지 않아요.

보내고 타이머 켜기ACK 기다리기안 오면 재전송빠짐없이 완성
규격 기반 시뮬레이션입니다.

이 페이지는 실제 패킷 캡처가 아니라 TCP의 확인 응답과 재전송 원리를 따라 만든 교육용 시뮬레이션입니다. 이해를 돕기 위해 조각 번호(1, 2)를 썼지만 실제 TCP는 바이트 단위의 누적 ACK을 쓰며 ACK을 잠시 늦춰 보낼 수도 있습니다. RTO는 왕복 시간을 바탕으로 계산하고, 만료되면 가장 오래 확인되지 않은 세그먼트를 재전송합니다. 빠른 재전송, 선택적 확인(SACK), 혼잡 제어는 다루지 않습니다.

참고: RFC 9293 (TCP) · RFC 6298 (Retransmission Timer)

실험을 마쳤다면