요약

  • 누적 확인(Cumulative ACK)은 견고한 경계입니다. 그 이전의 모든 바이트가 도착했다는 뜻입니다. SACK 블록은 다릅니다. 더 뒤의 범위가 지금 큐에 들어 있다고 말할 뿐이며, 수신자는 나중에 그 데이터를 버릴 수도 있습니다.
  • 이 구분 덕분에 복구 책임은 발신자에 남습니다. 발신자는 데이터를 보존하고, 부분 보고를 점수판(scoreboard)으로 합치며, 변하지 않는 혼잡 규칙 안에서 재전송을 선택합니다.
  • D-SACK은 중복 데이터를 드러내 보고서를 더 진단적으로 만들었지만, 여전히 원인을 증명하거나 대응을 규정하지 않았습니다. TCP는 수신자 측 권한 없이 공유 증거만 얻었습니다.

아직 해제될 수 없었던 바이트들

발신자가 5000부터 9000까지의 바이트를 전송했다고 가정해 봅시다. 첫 번째 세그먼트가 유실되고 이후 세그먼트들은 도착했으며, 수신자는 블록[5500,9000)을 보고합니다. 발신자는 이제 평소보다 훨씬 구체적인 소식을 받습니다. 전송 중 데이터의 상당 부분이 하나의 구멍 너머에서 기다리고 있다는 것입니다.

그러나 발신자는 그 뒤의 바이트들을 자신이 보유한 복사본에서 지우면 안 됩니다. 메모리 압박 때문에 수신자는 이전에 보고했던 데이터를 버릴 수 있습니다. 재전송 타임아웃이 보고서가 낡은 뒤에 도착할 수도 있습니다. 보통의 확인(ACK)이 어떤 범위를 넘어서야 비로소 발신자는 프로토콜의 최종 누적 확약을 받습니다.

따라서 SACK은 생산적인 모순에서 출발합니다. 보고서는 행동을 바꿀 만큼 상세하지만, 책임을 끝낼 만큼 강력하지는 않습니다.

약속을 할 수 있도록 허락된 단 하나의 필드

RFC 793은 ACKX가X미만의 모든 옥텟이 수신되었고 다음으로X가 기대된다는 뜻이라고 정의했습니다. 이 누적 경계는 순차 전달을 지탱하고, 언젠가 발신자가 버퍼에 둔 데이터를 해제하도록 합니다.

그러나 그만한 강도 때문에 이 필드는 첫 번째 구멍 너머의 섬들에 대해서는 침묵합니다. 반복되는 ACK 5000은 세그먼트 하나가 사라졌는지, 광범위한 손실인지 구분할 수 없습니다. 윈도우가 커지면서 모든 것을 다시 보내는 것은 용량을 낭비했고, 왕복마다 구멍을 하나씩 찾아내는 것은 시간을 낭비했습니다.

해법은 약속 자체를 약하게 만드는 것이 아니었습니다. 의도적으로 더 약한 힘을 지닌 두 번째 종류의 서술을 추가한 것입니다.

공표된 옵션은 아직 공통 관행이 아니었다

RFC 1072는 1988년 선택 확인 옵션을 제안했습니다. 수신자는 SYN에서 권한을 협상하고, 연결 중 비연속 데이터를 기술하게 됩니다. 이 옵션을 이해하지 못하는 피어는 누적 ACK로 계속할 수 있었습니다.

그러나 이 설계는 그 형태로 공통 인터넷 메커니즘이 되지 못했습니다.RFC 6247은 뒤에 RFC 1072를 Historic 상태로 옮겼고, 그 사이의 기록은 배포되지 않은 이유를 윈도우 스케일링을 둘러싼 불일치로 돌립니다. 공표는 제안의 성립이었지, 동시 구현이 아니었습니다.

큐보다 의도적으로 작은 보고서

RFC 2018은 1996년 이 옵션을 개정했습니다. SACK-Permitted는 SYN에만 나타납니다. 이후의 SACK 옵션은 32비트 시퀀스 경계 쌍, 즉 대기 중인 블록의 첫 바이트와 그 끝 바로 다음 바이트를 실어 나릅니다. 정상 ACK는 원래 의미를 유지합니다.

TCP는 옵션 공간을 40바이트만 제공합니다. SACK 옵션 하나는 혼자서 네 개의 블록을 실을 수 있고, 타임스탬프가 있으면 보통 세 개입니다. 따라서 수신자는 한 패킷이 기술할 수 있는 것보다 더 많은 섬을 보유할 수 있습니다. 수신자는 최신 세그먼트가 바꾼 블록을 맨 앞에 놓고, 최근 블록들을 이후의 확인에서 반복합니다. 보고서 자체도 역방향 경로에서 유실될 수 있기 때문입니다.

어떤 개별 SACK도 완전한 목록이 아닙니다. 발신자는 작고 겹치는 관찰들을 쌓아 자신만의 모델을 만듭니다.

렌게인(Reneging)은 조언과 수령의 경계를 긋습니다

RFC 2018은 SACK 정보를 자문적(advisory) 것이라고 명시합니다. 수신자는 렌게인(renege)할 수 있습니다. 즉, 이전에 보고했던 바이트를 버릴 수 있습니다. 발신자는 평상시 복구에서 SACK 표시된 범위의 재전송을 피할 수 있지만, 누적 확인이 그 범위를 덮을 때까지 원본 데이터를 보존해야 합니다.

재전송 타임아웃 이후에는 발신자가 이전의 SACK 정보가 틀렸을 가능성에 대비해야 합니다. 이 대체 경로는 부끄러운 예외가 아니라, 선택적이고 취소 가능한 증거를 안전하게 만드는 메커니즘입니다. 더 풍부한 채널이 실패할 때 기본 확약은 살아남습니다.

RFC 6675는 뒤에 보수적인 발신자 측 점수판을 규정했습니다. 보고서는 네트워크에 무엇이 남아 있는지에 대한 추정을 갱신할 뿐이며, 다음으로 어떤 세그먼트가 적격인지는 발신자가 결정합니다. 수신자는 좌표를 공급할 뿐, 복구 프로그램이 아닙니다.

중복은 스스로를 설명하지 않은 채 관찰될 수 있습니다

RFC 2883은 첫 번째 SACK 블록을 확장해 수신자가 중복 데이터를 보고할 수 있게 했습니다. D-SACK은 여러 가지 서로 다른 설명을 뒷받침할 수 있습니다. 패킷 재정렬, ACK 유실, 네트워크 복제, 혹은 너무 일찍 발화한 재전송 타이머입니다.

이 문서는 단일 대응을 의도적으로 규정하지 않습니다. 또한 수신자가 정직하게 보고한다고 반드시 신뢰할 수는 없다고 적습니다. 중복 보고는 도착 패턴에 대한 증거이지 그 원인의 증명도, 발신자 알고리즘 전체를 바꿀 권한도 아닙니다.

더 나은 증언이 더 큰 권한을 만들지는 않았습니다

선택적 증거는 혼잡 권한과도 분리된 채로 남았습니다.RFC 5681은 발신자의 혼잡 의무를 정의하고, RFC 2018은 SACK 복구가 그 의무를 보존할 것을 요구합니다. 어떤 바이트가 빠졌는지 아는 것은 허용된 윈도우를 현명하게 쓰는 데 도움을 줄 뿐, 그 윈도우를 넓히지는 않습니다.

그래서 SACK은 혼잡 붕괴 서사의 두 번째 판본이 아닙니다. 혼잡 제어는 발신자가 경로에 얼마나 넣을 수 있는지를 묻습니다. SACK은 그 예산 안에서 보존된 바이트 중 어느 것이 가장 좋은 후보인지를 묻습니다.

출처와 증거의 한계

이 RFC들은 누적 및 선택적 의미론, 옵션 한계, 렌게인, 발신자 복구, 중복 보고를 확립합니다. 그러나 전 세계 단일 배포 시점이나 모든 경로에 통하는 단일 성능 이득은 확립하지 않습니다. SACK 블록은 실패한 장비를 식별하거나, 재정렬이 아닌 손실임을 증명하거나, 수신자를 인증하거나, 영구 보관을 보증하지 않습니다.

역사적 성취는 더 좁고 더 내구적이었습니다. TCP는 수정 가능한 보고서를 상호운용 가능하게 만들면서, 최종 확약과 보존된 복사본, 그리고 행동의 결과를 발신자에게 남겨두었습니다.