IMT2000 3GPP - Trivial File Transfer Protocol

Trivial File Transfer Protocol
"TFTP"가 여기로 리디렉션된다.미국 정부 프로그램에 대해서는 테러 자금 추적 프로그램을 참조하십시오.

TFTP(Trivial File Transfer Protocol)는 클라이언트가 원격 호스트로부터 파일을 가져오거나 원격 호스트로 파일을 넣을 수 있는 간단한 잠금 단계 파일 전송 프로토콜이다.그것의 주요 용도 중 하나는 로컬 영역 네트워크에서 부팅되는 초기 단계에 있다.TFTP는 구현이 매우 간단하기 때문에 이 애플리케이션에 사용되어 왔다.

TFTP는 1981년에[1] 처음 표준화되었으며 현재 프로토콜 사양은 RFC 1350에서 확인할 수 있다.

개요

TFTP는 설계가 단순해 메모리 설치 공간이 작은 코드로 쉽게 구현할 수 있다.따라서 이 프로토콜은 고도로 재원이 공급된 컴퓨터에서 매우 낮은 공급의 싱글보드 컴퓨터(SBC)와 칩의 시스템(SoC)으로 타깃팅할 때 BOOTP, PXE, BSDP 등과 같은 네트워크 부팅 전략의 초기 단계에 대한 선택 프로토콜이다.또한 라우터, 방화벽, IP 전화 등과 같은 네트워크 어플라이언스로 펌웨어 이미지와 구성 파일을 전송하는 데도 사용된다.오늘날 TFTP는 인터넷 전송에 사실상 사용되지 않고 있다.

TFTP의 설계는 PARC 유니버설 패킷 프로토콜 세트의 일부였던 이전 프로토콜 EFTP의 영향을 받았다.TFTP는 1980년에 IEN 133에 의해 처음 정의되었다.[2]1981년 6월 TFTP 프로토콜(Revision 2)은 RFC 783으로 발행되었으며 이후 1992년 7월 RFC 1350에 의해 업데이트되었으며, 이 중 Sorcerer의 견습생 증후군을 수정하였다.1995년 3월 RFC 2347에 의해 1998년 5월 후반에 업데이트된 TFTP 옵션 확장자 RFC 1782는 TFTP의 원래 사양과 일치하는 메커니즘을 사용하여 전송 전에 파일 전송 옵션을 협상하기 위한 프레임워크를 설정하는 옵션 협상 메커니즘을 정의했다.

TFTP는 잘 알려진 포트 번호 69를 사용하여 UDP/IP 프로토콜 위에 구현된 간단한 파일 전송 프로토콜이다.TFTP는 작고 구현하기 쉽도록 설계되었으며, 따라서 보다 강력한 파일 전송 프로토콜이 제공하는 고급 기능이 대부분 부족하다.TFTP는 원격 서버로부터 또는 원격 서버로 파일을 읽고 쓰는 데만 사용한다.파일이나 디렉토리를 나열하거나 삭제하거나 이름을 바꿀 수 없으며 사용자 인증을 위한 규정이 없다.오늘날 TFTP는 일반적으로 LAN에서만 사용된다.

세부 사항

(W1) 호스트 A의 쓰기 요청
(W2) 서버 S가 요청을 승인함
(W3) 호스트 A에서 번호가 매겨진 데이터 패킷 전송
(R1) 읽을 호스트 A 요청
(R2) 서버 S가 데이터 패킷 1 전송
(R3) 호스트 A가 데이터 패킷 1을 승인함

TFTP에서 전송은 클라이언트가 서버에서 특정 파일을 읽거나 쓰도록 요청함으로써 시작된다.요청은 RFC 2347에 의해 지정된 조건에 따라 고객이 제안한 협상된 이전 매개변수 집합을 선택적으로 포함할 수 있다.서버가 요청을 승인하면 파일은 기본적으로 512바이트의 고정 길이 블록이나 RFC 2348에 의해 정의된 블록사이즈 협상 옵션에 지정된 숫자로 전송된다.일반적으로 IP 단편화를 피하기 위해 단일 IP 패킷 내에서 전송되는 전송 데이터의 각 블록은 다음 블록을 전송하기 전에 승인 패킷으로 승인되어야 한다.512바이트 이하의 데이터 패킷 또는 합의된 블록 크기 옵션의 전송 종료 신호.패킷이 네트워크에서 손실되는 경우, 의도된 수신자는 시간 초과되고 마지막 패킷(데이터 또는 승인일 수 있음)을 재전송할 수 있으므로, 손실된 패킷의 송신자가 손실된 패킷을 재전송하게 된다.잠금 단계 수신확인은 모든 이전 패킷이 올바르게 수신되었음을 보증하기 때문에 송신자는 재전송을 위해 단지 하나의 패킷만 보관해야 한다.전송에 관련된 두 장치는 모두 송신자와 수신자로 간주된다는 점에 유의하십시오.하나는 데이터를 보내고 하나는 수신확인을 받고, 다른 하나는 수신확인을 보내고 데이터를 받는다.

TFTP는 세 가지 전송 모드를 정의한다: 넷아스태시, 옥텟, 메일.

  1. NetASCII는 RFC 764에 정의된 수정된 ASCII 형식이다.0x20에서 0x7F(인쇄 가능한 문자와 공간)까지 7비트 ASCII 문자 공간의 8비트 확장성과 제어 문자의 8개로 구성된다.허용된 제어 문자에는 null(0x00), 라인 피드(LF, 0x0A), 캐리지 리턴(CR, 0x0D)이 포함된다.Netasci는 또한 전송을 위해 호스트의 라인 마커의 끝을 문자 쌍 CR LF로 변환하고, 모든 CR에 LF 또는 null을 따라야 한다고 요구한다.
  2. 옥텟은 임의의 원시 8비트 바이트의 전송을 허용하며, 수신된 파일은 전송된 것과 동일한 바이트당 바이트를 생성한다.더 정확히 말하자면, 만약 호스트가 옥텟 파일을 받았다가 반환한다면, 반환된 파일은 원본과 동일해야 한다.[3]
  3. 메일 전송 모드에서는 NetascII 전송을 사용하지만, 해당 수신자의 이메일 주소를 파일 이름으로 지정하여 파일이 이메일 수신자에게 전송된다.RFC 1350은 이 전송 방식이 쓸모없다고 선언했다.

TFTP는 UDP를 전송 프로토콜로 사용한다.전송 요청은 항상 포트 69를 대상으로 시작되지만, 데이터 전송 포트는 전송 초기화 동안 송신자와 수신자에 의해 독립적으로 선택된다.포트는 일반적으로 사용 후 삭제 포트 범위에서 네트워킹 스택의 매개 변수에 따라 무작위로 선택된다.[4]

  1. 개시 호스트 A는 RRQ(읽기 요청) 또는 WRQ(쓰기 요청) 패킷을 포트 번호 69의 호스트 S로 전송하며, 여기에는 RFC 2347의 조건에 따라 파일 이름, 전송 모드 및 선택적으로 협상된 옵션이 포함된다.
  2. S는 옵션이 사용된 경우 옵션 ACK로 응답하고 ACK(승인) 패킷은 WRQ로, DATA 패킷은 RRQ로 직접 응답한다.패킷은 임의로 할당된 사용 후 삭제 포트에서 전송되며, 향후 모든 패킷을 호스트 S로 전송해야 한다.
  3. 소스 호스트는 번호가 매겨진 DATA 패킷을 대상 호스트로 전송하며, 마지막을 제외한 모든 패킷은 전체 크기의 데이터 블록(512바이트 기본값)을 포함한다.대상 호스트는 모든 DATA 패킷에 대해 번호가 매겨진 ACK 패킷으로 응답한다.
  4. 최종 DATA 패킷은 그것이 마지막이라는 신호를 보내기 위해 전체 크기의 데이터 블록보다 적게 포함해야 한다.전송된 파일의 크기가 블록 크기의 정확한 배수인 경우 소스는 0바이트의 데이터를 포함하는 최종 DATA 패킷을 전송한다.
  5. 수신기는 각 DATA에 관련 번호 ACK로 응답한다.송신자는 다음 블록의 DATA로 블록의 첫 번째 수신 ACK에 응답한다.
  6. ACK가 결국 수신되지 않으면 재전송 타이머가 DATA 패킷을 재전송한다.

TFTP는 항상 네트워크 부팅과 연관되어 왔다.이와 관련하여 첫 번째 시도 중 하나는 TFTP 표준 RFC 906을 이용한 부트스트랩 로딩으로, 1984년에 발행된 것으로, 1981년에 발행된 리비던트 파일 전송 프로토콜 표준 RFC 783을 제정하여 부트스트랩 로딩을 위한 표준 파일 전송 프로토콜로 사용하였다.1985년에 발표된 Bootstrap Protocol 표준 RFC 951(BOOTP)이 그 직후에 발표되었는데, 디스크리스 클라이언트 머신이 자신의 IP 주소, TFTP 서버의 주소, NBP(Network Bootstrap Program)의 이름을 검색하여 TFTP를 전송, 메모리에 로드, 실행하도록 허용하였다.1997년에 발표된 DHCP(Dynamic Host Configuration Protocol) 표준 RFC 2131(Dynamic Host Configuration Protocol)의 향상된 BOOTP 기능마지막으로, 1998년 12월 PXE(Preboot Execution Environment) 버전 2.0이 출시되었고, 1999년 9월 업데이트 2.1이 파일 전송 프로토콜로 TFTP에 의존하여 공개되었다.[5]인텔은 최근 TFTP 지원을 모든 EFI/UEFI 환경으로 확장하는 새로운 UEFI 규격 내에서 PXE를 광범위하게 지원하기로 결정했다.[6][7]

원래 프로토콜은 전송 파일 크기 제한이 512바이트/블록 x 65535 블록 = 32MB이다. 1998년 TFTP Blocksize 옵션 RFC 2348에 의해 이 제한이 65535바이트/블록 x 65535 블록 = 4GB로 확장되었다.만약 정의된 blocksize는 네트워크 경로의 어느 지점에서도 최소 최대 전송 단위를 초과하는 IP패킷 크기를 생산하는 IP단편화와 재조립이 발생할 뿐 아니라 추가 더 overhead[8]라 가는 합계 이동 실패가 미니멀 리스트 IP스택 구현에 호스트 부트피 또는 PXE ROM지 않는다(또는 제시하지 못하는 제대로)를 구현입니다.p단편화 [9]및 재조립TFTP 패킷을 표준 이더넷 MTU(1500) 내에 유지해야 하는 경우 블록 크기 값은 1500에서 TFTP(4바이트), UDP(8바이트) 및 IP(20바이트)의 헤더를 뺀 값으로 계산되며 1468바이트/블록 x 65535 블록 = 92MB로 제한된다. 오늘날 대부분의 서버와 클라이언트는 블록 번호 롤오버(뒤로 가는 블록 카운터)를 지원한다.기본적으로 무제한 전송 파일 크기를 제공하는 65535 이후 0 또는 1로[10] 변경.

TFTP는 UDP를 활용하기 때문에 자체 전송 및 세션 지원을 제공해야 한다.TFTP를 통해 전송된 각 파일은 독립적인 교환을 구성한다.고전적으로, 이 전송은 잠금 단계로 수행되며, 네트워크 상에서 항상 대안적으로 한 패킷(데이터 블록 또는 '승인')만 비행한다.이러한 단일 데이터 블록 전략 때문에 TFTP는 해당 승인(창)을 기다리기 위해 전송을 일시 중지하기 전에 더 많은 양의 중단 없는 데이터 블록을 전송하는 대신, 특히 높은 지연 시간 링크에서 낮은 처리량을 제공한다.마이크로소프트는 WDS(Windows Deployment Services)의 일환으로 윈도 2008에 윈도 TFTP를 도입했는데, 2015년 1월 TFTP 윈도즈이즈 옵션 RFC 7440이 출간됐다.이는 Blocksize 옵션 RFC 2348에서[11] 종종 관찰되는 IP 조각화 부작용 없는 PXE 부팅과 같은 것에 대한 성능을 크게 향상시킨다.

보안 고려 사항

TFTP는 로그인 또는 액세스 제어 메커니즘을 포함하지 않는다.인증, 액세스 제어, 기밀성 또는 무결성 검사가 필요한 파일 전송에 TFTP를 사용할 때는 주의해야 한다.이러한 보안 서비스는 TFTP가 실행되는 계층 위 또는 아래에서 제공될 수 있다는 점에 유의하십시오.또한 TFTP 서버 프로세스에 부여된 권한에 대해서도 서버 파일 시스템의 보안을 침해하지 않도록 주의해야 한다.TFTP는 공개 읽기 액세스 권한이 있는 파일만 TFTP를 통해 사용할 수 있도록 제어장치가 설치된 경우가 많다.또한 TFTP를 통한 파일 나열, 삭제, 이름 변경 및 쓰기는 일반적으로 허용되지 않는다.고유한 프로토콜 제한이 극복할 수 없는 책임 문제를 야기할 수 있는 경우 TFTP 파일 전송은 권장되지 않는다.[12]

IETF 표준 문서

RFC 번호 제목 출판된 작가 사용되지 않는 정보 및 업데이트 정보 및 업데이트 정보
RFC 783 TFTP 프로토콜(개정 1) 1981년 6월 K. 솔린스 폐기 대상 - RFC 1350
RFC 906 TFTP를 사용한 부트스트랩 로드 1984년 6월 로스 핀레이슨 —
RFC 951 부트스트랩 프로토콜 1985년 9월 빌 크로프트 RFC 1395, 1497, 1532, 1542, 5494에 의해 업데이트됨
RFC 1350 TFTP 프로토콜(개정 2) 1992년 7월 K. 솔린스 RFC 1782, 1783, 1784, 1785, 2347, 2348, 2349에 의해 업데이트됨
RFC 1782 TFTP 옵션 확장 1995년 3월 G. 말킨 RFC 2347에 의해 폐기됨
RFC 2131 동적 호스트 구성 프로토콜 1997년 3월 R. 드롬스 RFC 3396, 4361, 5494, 6842에 의해 업데이트됨
RFC 2347 TFTP 옵션 확장 1998년 5월 G. 말킨 —
RFC 2348 TFTP 블록 크기 조정 옵션 1998년 5월 G. 말킨 —
RFC 2349 TFTP 시간 초과 간격 및 전송 크기 옵션 1998년 5월 G. 말킨 —
RFC 5505 인터넷 호스트 구성 원리 2009년 5월 아보바 —
RFC 7440 TFTP Windowsize 옵션 2015년 1월 P. 마소타 —

참고 항목

참조

  1. ^ RFC 783
  2. ^ Karen R. Sollins (1980-01-29). The TFTP Protocol. IETF. IEN 133. Retrieved 2010-05-01.
  3. ^ RFC 1350, 5페이지
  4. ^ Karen R.Sollins (July 1992). The TFTP Protocol (Revision 2). IETF. doi:10.17487/RFC1350. RFC 1350. Retrieved 2010-05-01.
  5. ^ "Preboot Execution Environment (PXE) Specification - Version 2.1" (PDF). Intel Corporation. 1999-09-20. Archived from the original (PDF) on 2013-11-02. Retrieved 2014-02-08.
  6. ^ "Unified Extensible Firmware Interface Specification" (PDF). UEFI. 2013-12-02. Retrieved 2014-04-04.
  7. ^ "UEFI PXE Boot Performance Analysis" (PDF). Intel Corporation. 2014-02-02. Archived from the original (PDF) on 2014-08-08. Retrieved 2014-04-04.
  8. ^ RFC 2348, 3페이지
  9. ^ RFC 5505, 7페이지
  10. ^ "Extending TFTP". CompuPhase. Retrieved 2018-12-12.
  11. ^ RFC 7440, 1페이지.
  12. ^ RFC 7440, 7페이지.