TCP는 Sequence Number와 ACK를 이용해 데이터가 정상적으로 도착했는지 확인합니다.
송신자는 아직 확인되지 않은 데이터를 관리하고, 재전송 타이머가 만료되면 확인되지 않은 가장 앞선 데이터를 재전송합니다. 또한 전통적인 Fast Retransmit에서는 송신자가 같은 ACK 번호의 중복 ACK를 3개 받으면, 수신자가 기다리는 데이터가 유실되었을 가능성이 높다고 판단해 타임아웃 전에 재전송합니다. ACK 자체를 다시 요청하는 동작은 아닙니다. RFC 6298, RFC 5681
타임아웃의 기준은 어떻게 잡는게 좋을까요?
RTO는 RTT를 기반으로 동적으로 계산하며, RTT의 평균과 변동성을 고려합니다. 또한 재전송이 반복되면 Exponential Backoff를 통해 RTO를 증가시켜 네트워크 혼잡을 악화시키지 않도록 합니다.
왜 Duplicate ACK를 3번 받으면 재전송하나요?
3이라는 숫자가 수학적으로 유실을 확정하는 값은 아니고, 불필요한 재전송과 빠른 유실 복구 사이의 경험적인 절충값이라고 생각합니다.
중복 ACK는 어떤 상황에서 만들어지나요?
예를 들어 수신자가 다음 바이트 1000을 기다리는데 그 뒤의 데이터가 먼저 도착하면, 여전히 1000부터 필요하다는 ACK를 보낼 수 있습니다. 뒤쪽 데이터가 계속 도착해도 빈 구간이 채워지지 않으면 같은 ACK 번호가 반복됩니다. 패킷 순서가 바뀐 경우에도 나타날 수 있으므로 중복 ACK 하나만으로 유실을 확정하지 않습니다.
Sequence Number와 ACK Number는 어떤 관계인가요?
Sequence Number는 데이터가 바이트 스트림의 어디에 해당하는지 표시하는 숫자이고, ACK Number는 그 ACK를 보내는 호스트가 상대에게서 다음에 받기를 기대하는 바이트의 번호입니다. 기본 ACK는 그 앞까지 연속해서 받았음을 뜻하는 누적 확인입니다.
데이터는 도착했는데 ACK만 유실되면 어떻게 되나요?
뒤에 도착한 누적 ACK가 앞선 데이터까지 확인해주면 재전송이 필요 없을 수 있습니다. 확인이 오지 않아 타임아웃으로 재전송하더라도 수신 TCP는 시퀀스 번호로 중복 데이터를 구분합니다. 하지만 새 연결에서 같은 HTTP 요청을 다시 보내는 것은 별도의 업무 중복 문제가 됩니다.
누적 ACK만으로는 뒤쪽에서 받은 데이터를 알 수 없는데, 이를 보완할 방법이 있나요?
SACK(Selective Acknowledgment)을 사용할 수 있습니다. 수신자가 누적 ACK 이후에 이미 받은 데이터 구간을 추가로 알려주어 송신자가 빠진 구간을 더 효율적으로 재전송하도록 돕습니다. 누적 ACK를 없애는 것이 아니라 보완하는 옵션입니다. RFC 2018