요약

  • RFC 3465는 적정 바이트 계산(Appropriate Byte Counting)을 제안했습니다. TCP의 혼잡 윈도우를 ACK 메시지 수가 아니라 새로 확인된 바이트 수에 따라 키움으로써, 지연 ACK나 ACK 분할이 크레딧을 임의로 바꾸지 못하게 한 것입니다.
  • 바이트 근거에도 여전히 한도가 필요했습니다. 슬로우 스타트에서는 각 ACK의 증가분이L로 제한되었고,L은 발신자 최대 세그먼트 크기(SMSS)의 2배를 넘을 수 없으며, 재전송 타임아웃 후에는 1배로 내려야 했습니다. 재전송 타임아웃 이후 누적 ACK는 최신 경로 용량이 아니라 오래된 데이터를 함께 가리킬 수 있기 때문입니다.

ACK 메시지는 진행 단위가 아니었다

기존의 혼잡 윈도우 성장은 접근하기 쉬운 대리 지표에 의존했습니다. 슬로우 스타트에서는 도착하는 ACK마다 고정된 증가분을 더할 수 있었고, 혼잡 회피에서는 구현체들이 왕복당 한 세그먼트의 성장을 흉내 내기 위해 ACK마다 일부분을 더하는 방식을 흔히 사용했습니다. 수신자가 세그먼트마다 확인을 보내고 ACK가 유실되지 않는다면 이 대리 지표는 깔끔하게 작동했습니다. 그러나 ACK 메시지 수를 바꾸면 동일한 바이트 진행이 서로 다른 발신자 반응을 낳았습니다.

2003년 2월에 Experimental로 발표된RFC 3465는 이 대리 지표를 누적 확인이 실제로 커버하는 바이트로 대체했습니다.일반 텍스트,RFC Editor 기록,Datatracker 항목,문서 이력,참고 문헌,이후 인용,정오표 검색이 공개 기록을 묶고 있습니다. 이 문서는RFC 2581의 윈도우 성장 로직을 수정했으며, RFC 2581의 표준 트랙 후속 문서는RFC 5681입니다.

지연 확인은 이 불일치의 한쪽 면을 드러냈습니다.RFC 1122가 규정한 수신자 동작은 대략 두 번째마다 꽉 찬 세그먼트를 확인할 수 있었습니다. ACK 수를 세는 발신자는 성장 기회가 절반으로 줄어 보고, 의도된 속도의 절반 정도로만 윈도우를 열 수 있었습니다. ACK 하나가 유실되면 나중에 도착한 누적 ACK가 같은 바이트가 도달했음을 증명하더라도 또 하나의 기회가 사라졌습니다.

반대 방향의 조작은 ACK 분할이었습니다. 수신자는 들어온 세그먼트 하나를 작은 단위로 나눠 여러 개의 ACK로 확인할 수 있었습니다. 모든 메시지가 고정된 혼잡 윈도우 증가분을 얻는다면, 전달된 데이터 한 세그먼트가 여러 단위의 전송 크레딧을 만들어낼 수 있었습니다. RFC 3465는 그 수신자 동작을, 같은 유한한 총량의 새 바이트 근거만 담은 반복 메시지로 명확하게 보이게 만들었습니다.

발신자는 바이트 장부를 유지했다

혼잡 회피에서 적정 바이트 계산은 TCP 제어 블록에bytes_acked를 유지했습니다. 각 ACK는 이전에 확인되지 않은 바이트 중 실제로 커버하는 부분만 더했습니다. 누적치가 현재cwnd에 도달하면 발신자는 그 윈도우 크기를 빼고cwnd를 발신자 최대 세그먼트 크기(SMSS) 하나만큼 늘렸습니다. 이렇게 하면 왕복당 대략 한 세그먼트라는 목표를 유지하면서, 진행이 많은 ACK로 오든 적은 ACK로 오든 결과가 달라지지 않았습니다.

슬로우 스타트에는 다른 규칙이 필요했습니다. 발신자는 도착한 ACK의 새로 확인된 바이트만큼cwnd를 늘릴 수 있되,L이라 불리는 한도를 넘을 수 없었습니다.L=1*SMSS에서는 이전 규칙보다 더 공격적이지 않았고, RFC 3465는 TCP 스택을 위해 이 보수적 형태의 ABC를 권장했습니다.L=2*SMSS는 두 세그먼트마다 하나의 ACK를 상쇄할 수 있기 때문에 실험으로 허용되었지만, 2 SMSS를 초과하는 값은 금지되었습니다.

이 상한은 공정성 이상을 보호했습니다. 매우 큰 누적 또는 스트레치 ACK가 그대로 선속 버스트를 풀어놓을 수 있었습니다. 2 SMSS에서조차 ABC는 ACK 하나 뒤의 미세 버스트를 키우고 슬로우 스타트를 왕복당 거의 두 배씩 확장되도록 만들 수 있었습니다. RFC는 제한된 시뮬레이션에서 다소 높은 손실을 보고하면서, 보편적 안전성이나 배포를 주장하는 대신 추가 실험을 권했습니다. 또한RFC 2018의 선택적 확인과 함께 이 동작을 쓰도록 권장했습니다.RFC 2861은 응용이 데이터를 보내지 않는 기간에 미사용 혼잡 윈도우 크레딧이 쌓이는 관련 문제를 다루었습니다.

누적 ACK는 오래된 이력을 담을 수 있었다

가장 날카로운 경계는 재전송 타임아웃 뒤에 나타났습니다. 초기 세그먼트 하나가 유실되었지만 이후 세그먼트들은 수신자에 도달했다고 가정해 봅시다. 타이머가 만료되면 발신자는 빠진 세그먼트를 재전송합니다. 다음 누적 ACK는 그 재전송과, 최신 왕복 이전에 이미 도달했던 데이터를 갑자기 함께 커버할 수 있습니다. 이 바이트들은 발신자에게는 새로 확인된 것이지만, 전부가 동등한 데이터가 방금 네트워크를 떠났다는 증명은 아니었습니다.

따라서 RFC 3465는 RTO 이후 슬로우 스타트 회복에서L=1*SMSS를 요구했습니다. 당시RFC 2988이 규정하던 타이머 규칙, 이후RFC 6298로 대체된 규칙이 주변의 회복 맥락을 제공했습니다. 구분은 미묘합니다. 누적 확인 상태는 유효한 프로토콜 근거지만, 그 시간적 의미가 현재 용량 탐색보다 넓을 수 있습니다.

다른 TCP 메커니즘들은 서로 다른 권한을 가졌습니다.RFC 3042는 제한된 조건 하에서 세 번째 중복 ACK 이전에 새 데이터를 보내는 Limited Transmit을 허용했지만, ABC의 윈도우 장부를 정의하지는 않았습니다.RFC 3449는 비대칭 경로, ACK 필터링과 재구성을 분석했지만, 발신자 크레딧을 메시지 수에서 바이트 수로 옮기지는 않았습니다.RFC 2525의 구현 목록은 정확한 발신자·수신자 동작이 왜 중요했는지를 보여주는 배경이지, ABC 배포의 증명이 아닙니다.

Lu Heng의 이후현실 층위 논의는 네 가지 영수증을 구분하는 데 도움이 됩니다. 관찰된 ACK 메시지, 누적으로 새로 확인된 바이트, 알고리즘이 인정한 크레딧, 실제 경로로 보내진 데이터입니다. 그의실행 코드 우선주장은 주목을 누적기, 상한, 회복 상태와 방출된 버스트로 돌립니다. 이들은 RFC 저자의 사적 의도에 대한 주장이 아니라 이후의 편집적 렌즈입니다.

RFC 3465는 확인된 모든 바이트가 새 용량이라고 선언하지 않았습니다. 회계를 조작하기 어렵게 만들고, 그 회계가 승인할 수 있는 범위를 유한하게 묶었습니다. 영수증의 수는 바뀔 수 있었습니다. 그 밑에 깔린 진행은 같아야 했습니다.

출처