요약

  • RFC 2348의 프로토타입은 중간 게이트웨이 없이 블록 크기가 512옥텟에서 8,192옥텟으로 커졌을 때 2.25MB TFTP 전송 시간을 23.85초에서 4.90초로 단축했습니다.
  • 더 큰 블록은 기존 페이로드 크기의 16배였습니다. 그러나 측정된 소요 시간은 약 80% 감소했을 뿐, 16배가 아니었습니다. RFC 자체가 경로 MTU를 초과하는 블록은 단편화와 재조립 비용을 추가한다고 경고합니다.

기존 TFTP의 대가는 단순함이었습니다. 작은 기계가 파일을 요청하고, 데이터 블록 하나를 받고, 이를 확인하고 다음 블록을 기다릴 수 있었습니다. 프로토콜의 익숙한 512옥텟 블록은 각 교환을 절제된 수준으로 유지했으며, 부팅 코드가 제한된 ROM에 담긴 디스크리스 시스템에 적합했습니다. 그러나 정지-대기 방식은 모든 확인 응답을 하나의 멈춤으로 만들었습니다. 더 큰 프레임 예산을 가진 로컬 네트워크에서는 그 리듬의 상당 부분이 헤더 전송과 대기에 소모되고 파일 데이터 전달에는 쓰이지 않았습니다.

1998년 5월,RFC 2348은 좁은 범위의 변경을 제안했습니다. 클라이언트가 다른blksize를 요청할 수 있도록 한 것입니다. 협상 기계 장치는RFC 2347에서 왔으며, 이는 읽기 또는 쓰기 요청에 옵션을 덧붙이고 옵션 확인(OACK)으로 응답하는 방식이었습니다. 서버는 클라이언트가 요청한 값보다 크지 않은 값을 수용할 수 있었고, 클라이언트가 요청하지 않은 옵션을 임의로 만들 수는 없었습니다. 클라이언트는 이후 확인된 값을 사용하거나 전송을 종료해야 했습니다. 구형 서버가 옵션을 무시하면 교환은 일반 TFTP 동작으로 계속될 수 있었습니다. 이는 기준선을 몰래 재작성한 것이 아니라 확장이었습니다.

제안된 범위는 넓었습니다. TFTP의 4옥텟 헤더를 제외하고 블록당 8~65,464 데이터 옥텟이었습니다. RFC 2348은 TFTP, UDP, IP 헤더를 계산에 반영한 후 1,428옥텟을 이더넷 MTU 예시로 제시했습니다. 이 숫자는 작업 예시였지 보편적인 설정이 아니었습니다. 옵션 값은 두 TFTP 엔드포인트가 합의한 전송 크기에 대한 답이었으며, 경로상의 모든 링크와 터널이 결과 IP 패킷을 단편화 없이 운반할 수 있다는 증명이 아니었습니다.

이 문서는 모든 네트워크에 대한 주장 대신 자체 실험을 포함했습니다. HP-UX 9000 시스템 두 대가 여유로운 이더넷 위에서 2.25MB 파일을 옥텟 모드로 전송했습니다. 저자들은 중간 게이트웨이가 있는 경우와 없는 경우로 나누어 다섯 번 실행의 평균을 냈습니다. 블록당 512옥텟일 때 보고된 시간은 게이트웨이 없는 경로에서 23.85초, 게이트웨이가 하나 있는 경로에서 37.05초였습니다. 8,192옥텟일 때는 각각 4.90초와 6.15초였습니다. 소요 시간 비율은 약 4.87배와 6.02배로 계산되며, 감소율은 약 79.5%와 83.4%입니다.

그렇다면 RFC의 "16배" 비교는 무엇을 의미할까요? 페이로드 블록이 16배 커진 것입니다. 8,192를 512로 나눈 값입니다. 관측된 전송이 16배 빨라진 것은 아닙니다. 같은 비교는 다섯 번 실행 평균과 일치하는 약 80%의 시간 감소를 보고합니다. 이 구분은 블록 크기 비율, 패킷 수 감소, 실측 속도 향상이 서로 다른 양이기 때문에 중요합니다. 그래도 개선은 인상적이었습니다. 더 큰 블록은 데이터 패킷 수, 확인 응답 수, 대기 횟수를 줄였고, 패킷당 프레이밍과 처리 오버헤드도 줄였습니다.

한계는 결과 바로 옆에 적혀 있었습니다. 블록이 경로 MTU를 초과하면 IP 단편화와 재조립이 오버헤드를 추가하기 시작하며, RFC는 게이트웨이가 늘어날수록 이 페널티가 더 두드러질 것으로 예상했습니다. 테스트 이더넷에서 효율적인 블록이 더 작은 링크, 캡슐화 또는 터널 이후에는 부적합할 수 있습니다. 이 실험은 다양한 인터넷 경로를 테스트하지 않았고, 분산을 정량화하지 않았으며, 일반적으로 최적인 블록 크기를 특정하지도 않았습니다. 이 문서는 메커니즘을 확립하고 범위가 제한된 프로토타입 결과를 보고했을 뿐, 배포 실태 조사는 아니었습니다.

이후 작업은 또 다른 조정 축을 드러냈습니다.RFC 7440은 TFTPwindowsize를 정의하여 확인 응답을 기다리기 전에 여러 연속 블록을 보낼 수 있게 합니다. 윈도우 깊이와 블록 크기는 모두 정지-대기 비용을 바꿀 수 있지만 같은 다이얼이 아닙니다. 그리고 이후RFC 8900은 운영 네트워크에서 IP 단편화가 왜 취약한지를 다루는데, 이후의 지침을 1998년 프로토타입이 실패했다는 증거로 소급 적용해서는 안 됩니다. 원래의 경고만으로 충분합니다. 협상된 페이로드는 경로 전체에 대한 증명이 아니라는 것입니다.

따라서 RFC 2348의 유용한 역사적 교훈은 "크면 빠르다"보다 더 절제되어 있습니다. 이 문서는 작은 프로토콜이 왜 더 큰 단위를 협상할 수 있는지를 정확히 보여주고, 명시된 조건에서 상당한 감소를 입증하며, 그 거래를 뒤집을 수 있는 네트워크 경계를 명명했습니다. 결과는 마법의 숫자가 아니었습니다. 전송이 실제로 사용하는 경로를 측정하라는 초대였습니다.

출처는 원래의TFTP 사양, RFC 1350,RFC 2347의 협상 규칙, 동시대의 타임아웃 및 전송 크기 옵션을 담은RFC 2349, 그리고 이후의 TFTP 윈도우 및 단편화 문서인RFC 7440과RFC 8900입니다.