손실 추정·탐색·타임아웃은 같은 사건이 아닙니다
RACK은 ACK로 확인된 전달과 시간 정보를 사용해 손실을 추정합니다. 뒤따르는 패킷의 ACK가 없는 tail loss에는 TLP가 추가 전달·피드백을 유도합니다. 현재 Linux 문서의 tcp_recovery 설명은 RACK을 지원하는 손실 탐지 방식으로 적고 있으며, duplicate-ACK 휴리스틱을 끄는 선택 비트도 구분합니다. 둘을 서로 무관한 두 엔진이 항상 병렬로 실행되는 것으로 그리지 않습니다.
Linux 네트워크 설정: tcp_recovery와 early retransmit
RACK: 확인된 전달과 시간으로 손실을 추정
TLP: 마지막 구간의 피드백 부족에 probe
RTO: 재전송 타이머 만료와 backoff
RFC 8985의 RACK-TLP 알고리즘에서 TLP는 RACK과 함께 쓰입니다. 이 그림은 서로 다른 판단을 나눈 것이며 세 타이머를 동시에 동작시키라는 뜻이 아닙니다.
RTO 숫자와 실제 로그 간격은 다릅니다
RFC 6298은 RTT 추정과 변동으로 RTO를 계산하고, 재전송 타이머가 만료되면 backoff하도록 정의합니다. RTT 측정 전의 초기값, 구현의 최소·최대값, 이미 적용된 backoff를 같은 숫자로 합치지 않습니다. 혼잡 윈도우가 모든 복구에서 반드시 반으로 줄어든다는 설명도 피합니다.
저장된 26쪽 실험 자료는 Linux 4.10·HZ=250의 작성자 로그입니다. 51 jiffies는 204 ms이지만, 표시된 arm 시각 7901.132022와 첫 retransmit entry 7901.561629의 차이는 429.607 ms입니다. 이 불일치를 숨기거나 204 ms를 실제 관측 간격이라고 쓰면 안 됩니다.
서로 다른 로그 지점·타이머 갱신·스케줄링을 추가 추적해야 원인을 판단할 수 있습니다. 로그 사이의 공백만으로 그 시간에 CPU가 무엇을 했는지 증명되지는 않습니다. 이 계산은 원본 로그의 재해석이지 여기서 다시 실행한 실험이 아닙니다.
재전송 조건과 연결 포기 조건을 나눕니다
tcp_retries1은 네트워크 계층에 문제를 의심하게 하는 기준이고 tcp_retries2는 연결 포기 판단의 시간 예산과 관련합니다. 단순한 패킷 재전송 횟수만 세는 설정으로 읽지 않습니다. 문서의 기본값 계산 예시도 모든 연결에서 같은 초에 종료된다는 보장은 아닙니다.
Linux 문서: tcp_retries1·tcp_retries2
TCP_USER_TIMEOUT은 동기화된 연결 상태에서 미확인 송신 데이터나 zero window 때문에 보내지 못한 데이터가 허용 시간보다 오래 남는 경우를 다룹니다. 재전송 자체의 시각을 지정하거나 상대 앱의 처리 완료를 기다리는 API가 아닙니다.
실험 코드는 그대로 운영 환경에 옮기지 않습니다
원본의 256바이트 버퍼는 최대 256바이트를 받은 뒤 문자열 종료 바이트를 붙일 수 있어 경계를 넘습니다. 수신 길이와 남은 공간을 검증해야 합니다. 한 번의 send가 모든 데이터를 받았는지도 따로 처리해야 합니다.
ACK 비트를 고르는 필터는 payload가 없는 ACK만 고른다는 뜻이 아닙니다. 사용자 스레드를 재워도 커널의 ACK 처리가 자동으로 멈추지는 않습니다. 기존 방화벽 전체를 비운 뒤 테스트 규칙 하나를 지우는 것은 원상복구가 아닙니다.
이 검토에서는 방화벽·sysctl을 바꾸거나 패킷 손실을 주입하지 않았습니다. 원본의 실제 로그 범위와 별도로 제안된 반대 방향 실험을 구분하고, 현재 환경에서 재현한 것으로 기록하지 않습니다.
send 성공·TCP ACK·업무 완료를 따로 기록합니다
send()의 양수 반환은 로컬 송신 경로가 받아들인 바이트 수입니다. TCP ACK는 상대 TCP 계층의 수신 진척을 뜻하지만 상대 앱의 파싱·저장·업무 완료를 보장하지 않습니다. 업무 재시도에는 애플리케이션 응답과 요청 식별자·멱등성 규칙이 필요합니다.