요약

  • TFTP는 초기 RRQ 또는 WRQ를 69번 포트로 보낸 뒤, 수락된 전송의 UDP 포트로는 클라이언트가 선택한 전송 식별자와 서버가 선택한 전송 식별자를 사용했습니다.
  • 이 튜플은 의도적으로 좁았습니다. 잘못된 소스 TID는 유효한 전송을 끝내지 않고 오류 5를 만들었으며, 이후의 수정 사항과 옵션들은 재전송과 처리량을 바꿨지만 TID를 인증으로 바꾸지는 않았습니다.

69번 포트는 초인종이었다

TFTP는 작은 구현을 위해 설계되었습니다. RFC 783은 디렉터리 목록, 사용자 인증, FTP의 제어 어휘 없이 파일을 읽거나 쓸 수 있는 프로토콜을 기술했습니다. 이 절약은 소프트웨어를 담을 공간이 거의 없는 환경에서 특히 유용했습니다. 로컬 네트워크에서 첫 파일을 얻으려는 기기는 범용 원격 파일 세션을 필요로 하지 않았습니다.

최소성이 상태를 제거한 것은 아닙니다. 상태가 어디에 존재하는지를 바꾼 것입니다.

읽기의 경우 클라이언트는 자신의 로컬 전송 식별자, 즉 TID를 선택하고 서버의 알려진 TID인 69번 포트로 RRQ를 보냅니다. 쓰기도 같은 방식으로 WRQ를 보냅니다. 긍정적인 응답은 일반적으로 69번에서 계속되지 않습니다. 서버는 자신의 TID를 선택하고 이를 DATA 블록 1 또는 ACK 블록 0의 소스로 사용합니다. 그 이후에는 모든 데이터그램이 클라이언트 TID와 서버 TID를 목적지 및 소스 포트로 담습니다.

따라서 웰노운 포트는 새 요청을 들을 수 있는 위치를 식별할 뿐입니다. 수락된 모든 전송의 엔드포인트를 식별하는 것은 아닙니다. 이 구분 덕분에 하나의 리스너가 여러 독립적인 교환을 시작하면서도 DATA와 ACK 패킷을 혼동하지 않을 수 있습니다. 동시에 소스가 69번인 패킷만 허용하는 방화벽 규칙은 요청은 받아들이고 회신은 끊어버릴 수 있음을 의미합니다.

첫 응답이 로컬 권위를 고정했다

RFC 1350은 각 측이 자신의 TID를 선택하도록 요구하여 곧바로 재사용이 일어날 가능성을 낮춥니다. 첫 긍정 응답이 도착하면 그 두 값은 해당 전송에 대해 고정됩니다. 이후의 패킷은 기대된 소스 TID에서 와야 합니다.

이것은 사람, 기기, 파일의 신원에 대한 주장이 아닙니다. TID는 수명이 짧은 전송 계층 이름입니다. 이 블록이 어느 데이터그램 대화에 속하는지를 말할 뿐이며, 서버가 권한을 부여받았는지, 파일이 진짜인지, 소스 주소가 위조될 수 없는지를 증명하지 않습니다.

그 좁은 범위 안에서조라 이 검사는 중요합니다. 초기 RRQ가 네트워크에서 중복되었다고 가정해 봅시다. 서버는 두 사본을 두 개의 요청으로 취급하고 서로 다른 두 TID로 응답할 수 있습니다. 클라이언트는 첫 긍정 응답을 수락합니다. 다른 응답이 도착하면 클라이언트는 두 대화를 합치지 않고 이미 진행 중인 전송을 희생하지도 않습니다. 그 패킷을 폐기하고, 그 소스로 오류 5, 즉 알 수 없는 전송 ID(Unknown transfer ID)를 보낸 뒤, 수락된 전송을 계속합니다.

RFC 1350은 잘못된 소스 포트를 연결을 종료하지 않는 예외적인 오류로 부릅니다. 대부분의 다른 오류는 교환을 끝내며 예의상만 보내집니다. ERROR 패킷은 확인되지도 재전송되지도 않습니다. 잘못된 TID 규칙이 다른 이유는 그 오류가 유효한 전송이 아니라 낯선 대화에 속하기 때문입니다.

하나의 블록이 전체 전진 경계를 담당했다

원래의 전송 리듬은 stop-and-wait였습니다. DATA 블록은 1부터 시작했습니다. 송신자는 한 블록을 전송하고 그 블록을 보존한 채 대응하는 ACK를 기다린 뒤에야 전진했습니다. 512옥텟보다 짧은 블록은 끝을 표시했으며, 파일 길이가 정확히 배수라면 길이 0인 블록이 종단 신호를 제공했습니다.

이 한 블록짜리 전진 경계가 흐름 제어를 제공하고 TFTP 내부의 재정렬을 피했습니다. 수신자는 작은 카운터만으로 다음 블록과 중복을 구분할 수 있었습니다. 송신자는 현재 블록만 보존하면 되었습니다. 마지막 수신자는 마지막 ACK 후 잠시 기다리는 것이 권장되었는데, 그 ACK가 유실되고 마지막 DATA가 다시 나타나더라도 다시 확인 응답할 수 있도록 하기 위함이었습니다.

이 절약에는 성능 대가가 있었습니다. 한 번에 한 블록만 전송 중일 수 있었습니다. 더 중요하게는, 초기 문구가 어느 쪽이든 오래된 중복에 대해 자신의 현재 데이터그램을 재전송하는 것을 허용했습니다. 잘못된 타이밍에서 그 규칙은 스스로 트래픽을 만들어냈습니다.

견습 마법사가 모든 응답을 복제했다

RFC 1123은 이 실패에 기억에 남는 이름을 붙였습니다. 바로 견습 마법사 증후군(Sorcerer's Apprentice Syndrome)입니다. 데이터그램이 지연됩니다. 한 엔드포인트가 타임아웃되어 재전송합니다. 지연된 사본이 나중에 도착하면서 또 다른 응답을 유발합니다. 각 중복 응답이 자기 자신의 중복을 만들어낸다면, 이후의 모든 DATA와 ACK는 두 번씩 이동할 수 있습니다.

바이트가 손상되지 않았더라도 프로토콜은 운영적으로 실패할 수 있습니다. 추가 패킷들은 지연을 야기한 혼잡을 악화시키고, 더 많은 타임아웃을 만들며, 전송이 끝나는 것을 막을 수 있습니다. 진행을 증명하는 메커니즘이 스스로 부하를 만드는 한, 올바른 바이트만으로는 충분하지 않습니다.

필요한 수리는 비대칭적이었습니다. DATA 발신자는 중복 ACK를 받았다는 이유만으로 현재 DATA를 다시 보내서는 안 됩니다. 재전송은 모든 낡은 신호가 아니라 관련 타임아웃 또는 상태 전이에 의해서만 승인됩니다. RFC 1350이 수정된 동작으로 RFC 783을 대체했습니다.

이 수정은 블록 번호가 실제로 무엇을 했는지 드러냅니다. 그것은 청크 옆에 인쇄된 단순 카운터가 아니었습니다. 블록 번호는 기대된 TID들과 로컬 타이머와 함께, 데이터그램이 교환을 전진시키는지, 이미 확인된 상태를 반복하는지, 다른 전송에 속하는지, 복구를 정당화하는지를 결정했습니다.

확장은 용량을 협상했지 신원은 아니었다

512옥텟 lockstep은 작은 코드에는 매력적이었지만 더 많은 것을 담을 수 있는 경로에는 좋지 않았습니다. RFC 2347은 RRQ와 WRQ에 옵션 협상을 추가했습니다. 요청할 수 있는 것은 클라이언트뿐이었습니다. 서버는 요청된 옵션을 OACK에서 확인 응답하거나, 지원하지 않는 옵션은 생략하거나, 해당 옵션의 규칙에 따라 잘못된 값을 거절할 수 있었습니다. 요청되지 않은 옵션을 전송에 몰래 넣을 수는 없었습니다.

읽기의 경우 DATA가 시작되기 전에 ACK 블록 0이 OACK를 수락합니다. 쓰기의 경우 DATA 블록 1이 이를 수락합니다. 확인 응답되지 않은 옵션은 처음부터 제안되지 않은 것처럼 무시됩니다. 따라서 응답은 클라이언트의 희망과 양쪽 엔드포인트가 실제로 사용하기로 합의한 매개변수를 분리합니다.

RFC 2348은 다른 블록 크기를 허용했습니다. RFC 2349는 타임아웃 구간과 전송 크기를 협상하거나 공개할 수 있게 했습니다. RFC 7440은 나중에 그 창의 마지막 블록에 대한 확인 응답 전에 연속 블록 창을 허용했습니다. 창 크기 1은 기존의 stop-and-wait 형태를 유지했고, 더 큰 창은 더 많은 미확정 상태를 더 높은 처리량으로 교환했습니다.

그 어떤 변화도 전송을 69번 포트로 되돌리지 않았습니다. 그 어떤 것도 파일에 대한 접근 권한을 부여하거나 엔드포인트를 인증하지 않았습니다. 이들은 두 TID 간의 대화와 그 매개변수에 대한 명시적 합의를 보존하면서 확인 응답 사이에서 허용되는 작업량을 넓혔습니다.

작은 프로토콜은 큰 책임을 바깥에 남겨두었다

TFTP의 경계는 정직했지만 좁았습니다. 이 프로토콜은 패킷이 이 전송에 대해 수락된 TID에서 왔다는 것, 블록이 새것인지 반복인지, 옵션이 확인 응답되었는지, 종단 짧은 블록이 도착했는지를 말할 수 있었습니다. 그러나 요청된 경로가 안전한지, 쓰기가 허용되어야 하는지, 부팅 이미지가 서명되었는지, 네트워크 기기가 자신이 내려받은 것을 신뢰해야 하는지는 말할 수 없었습니다.

그 결정들은 주변 시스템에 속합니다. 접근 가능한 주소 범위, 파일 루트 제한, 읽기·쓰기 정책, 아티팩트 출처, 방화벽 또는 NAT 상태, 그리고 초기 요청을 동적 튜플과 연결하는 로그 등이 그것입니다. TID 선택을 인증으로 다루는 것은 교환에서 가장 작은 이름에게 가장 큰 주장을 짊어지게 하는 일입니다.

따라서 TFTP의 역사는 낡고 단순한 전송 도구의 이야기가 아닙니다. 웰노운 포트는 결과 대화를 소유하지 않고 발견을 승인할 수 있고, 하나의 오류가 양쪽을 모두 종료하기보다는 하나의 교환을 다른 교환으로부터 보호해야 할 수 있으며, 성능 확장은 합의와 신원의 경계가 그 확장을 살아남을 때만 안전하다는 점을 보여주는 간결한 사례입니다.

출처와 한계

원래 설계는RFC 783에, 호스트 요구사항과 중복 수정은RFC 1123에, 개정된 기본 프로토콜은RFC 1350에 문서화되어 있습니다. 이후의 협상은RFC 2347,RFC 2348,RFC 2349및RFC 7440에서 정의됩니다.IANA 서비스 레지스트리가 69번 포트를 기록합니다. 이 출처들은 2026년 배포 현황을 측정하지 않으며, TID를 신원·권한·기밀성 또는 파일 무결성의 증명으로 만들지 않습니다.