요약

  • TCP의 누적 확인 번호는 연속된 데이터의 끝에서 멈춘다. SACK은 그 앞에 빈틈이 있어도 뒤쪽에 도착한 바이트 구간을 수신자가 따로 알릴 수 있게 했다.
  • RFC 2018은 수신자가 SACK으로 알린 데이터를 나중에 버리는 것을 허용했다. 송신자는 누적 확인이 닿을 때까지 자기 사본을 지켜야 했다.

서류의 첫째, 둘째, 넷째 쪽이 도착했다. 접수 도장은 둘째 쪽까지만 찍힌다. 셋째 쪽이 빠졌기 때문이다. 직원은 넷째 쪽이 책상 위에 있다고 여백에 적는다. 책상이 차면 그 종이를 치울 수도 있다. TCP의 선택 확인은 이 도장과 연필 메모의 차이를 통신 규칙으로 만들었다.

1988년 RFC 1072는 대역폭과 지연이 모두 큰 경로에서 누적 확인만 사용하는 불편을 설명했다. 한 세그먼트가 사라지면 확인 번호가 멈춘다. 그 뒤의 세그먼트가 이미 도착해도 송신자는 그 숫자만으로 알 수 없다. 다음 왕복을 기다리면 복구가 늦어지고, 무작정 다시 보내면 이미 가진 데이터까지 옮긴다. 선택 보고는 빈칸 뒤에 있는 조각을 드러내기 위한 제안이었다. 당시 문서는 실험적 제안이었고, 나중의 SACK 형식 자체는 아니었다.

1996년 10월의 RFC 2018은 SACK을 TCP 옵션으로 정했다. 상대가 연결 시작 SYN에서 SACK-Permitted를 알린 뒤에만 수신자가 SACK 옵션을 보낼 수 있었다. 평소의 확인 번호는 TCP 헤더에 남아 끊기지 않고 도착한 앞부분을 가리켰다. 별도의 SACK 블록은 그 뒤에 받은 바이트 구간의 시작과 끝을 담았다. 공식 접수 범위와 책상 위 낱장의 목록이 한 답장에 실렸다.

목록을 적을 공간은 넉넉하지 않았다. TCP 옵션에는 떨어져 있는 모든 구간을 언제나 담을 수 없다. RFC 2018은 ACK를 일으킨 새 세그먼트가 들어 있는 블록을 보통 첫 칸에 넣도록 했다. 다만 그 세그먼트가 누적 번호를 전진시켰다면 예외다. 남은 공간에는 다른 구간을 채우고 최근 블록을 다시 적는 것도 권했다. 앞선 ACK가 사라져도 뒤의 반복 보고가 단서를 전할 수 있다. 송신자가 보는 수신 버퍼 지도는 유용하지만 완전한 장부는 아니다.

8절에는 책상을 비우는 규칙이 있다. 수신자는 메모리 압박 등으로 순서가 어긋나게 도착한 데이터를 버릴 수 있으며, 이전에 SACK으로 알린 데이터도 포함된다. 이를 reneging이라고 부른다. 다음 SACK에서는 버린 옛 구간을 여전히 가지고 있는 것처럼 다시 적어서는 안 된다. 첫 블록의 특별 규칙은 방금 도착한 세그먼트를 곧 버리려 해도 그 도착 사실을 보여 준다. 보고는 그 순간의 수신과 대기열 상태를 기록한다. 보관 기간까지 보증하지 않는다.

따라서 송신자에게는 단호한 규칙이 붙었다. 누적 확인 번호가 덮기 전에는 바이트를 삭제하지 말 것. SACK을 이용해 어느 빈틈을 먼저 메울지 고르고, 상대가 갖고 있어 보이는 부분은 당장 다시 보내지 않아도 된다. 그러나 재전송할 수 있는 원본은 남겨 둔다. 상대가 대기열을 정리했다면 그 사본으로 흐름을 다시 이어야 한다.

2000년 7월 RFC 2883은 같은 옵션을 중복 데이터 보고에도 썼다. D-SACK이 그것이다. 누적 확인 번호의 뜻이나 ACK를 보내는 시점은 그대로였다. 중복 도착이 ACK 한 장에만 나타날 수 있고, 그 ACK가 사라지면 소식도 사라진다. 자세한 접수 메모조차 배달을 필요로 했다.

SACK 덕분에 송신자는 끊긴 흐름을 덜 막연하게 복구했다. 동시에 프로토콜은 소박한 기록 관리 원칙을 지켰다. 연필 메모를 보고 다음 배송을 정하되, 원본을 파기하는 일은 누적 접수 도장이 따라온 뒤에 한다.