Trivial File Transfer Protocol
詳細

TFTPでは、転送はクライアントがサーバ上の特定のファイルを読み書きする要求を発行することによって開始される。要求には、 RFC 2347 で指定された条件の下で、転送パラメータをオプションで含むことができる。サーバが要求を承認すると、クライアントはファイルを送信する。ファイルは、デフォルトで512バイトの固定長ブロック、または RFC 2348 で定義されているblocksize negotiatedオプションで指定されたバイト数で送信される。IPフラグメンテーションを回避するために、通常、単一のIPパケット内で搬送される転送データの各ブロックは、次のブロックが送信される前に確認パケットによって確認応答されなければならない。512バイト（またはオプションで指定されたブロックサイズ）未満のデータパケットを送信することにより、転送の終了を知らせる。パケットがネットワーク内で紛失した場合には、再送処理が行われる。送信側でデータ転送後に確認パケットの受信がタイムアウトした場合、直前のデータブロックを再送する。受信側で確認パケット送信後に次のデータブロックの受信がタイムアウトした場合、直前の確認応答を再送する。このようなロックステップ（英語版）の確認応答によって、それまでに送信した全てのパケットが正しく受信されたことが保証される。送信側は再送信用に1つのパケットのみを保持する必要がある。TFTPにおいては、転送に関与する両方のデバイスが、送信者・受信者のどちらの立場にもなる。一方はデータを送信して確認応答を受信し、もう一方は確認応答を送信してデータを受信する。
TFTPでは、netascii、octet、mailの3つの転送モードを定義する。
netascii転送モードは、 RFC 764 で定義されているASCIIの修正形式である。これは、0x20から0x7Fまでの7ビットASCII文字空間の8ビット拡張（印刷可能文字とスペース）および8つの制御文字で構成されている。許容される制御文字には、ヌル（0x00）、改行（LF、0x0A）、キャリッジリターン（CR、0x0D）がある。netasciiでは、ホスト上の行末マーカーを転送のために"CR LF"に変換し、すべてのCRの後にLFまたはヌルを付ける必要がある。
octet転送モードは、任意の生の8ビットバイトの転送を可能にし、受信ファイルは結果として送信されたものとバイト対バイトで同じになる。より正確には、ホストがオクテットファイルを受信してそれを返した場合、返されたファイルは元のファイルと同一でなければならない。
mail転送モードはnetascii転送を使用するが、ファイル名として受信者のEメールアドレスを指定することで、ファイルはEメール受信者に送信される。 RFC 1350 では、この転送モードは廃止したと宣言された。
TFTPはトランスポート層プロトコルとしてUDPを使用する。転送要求は常にポート69を対象として開始されるが、データ転送に使用するポートは、転送の初期化中に送信側と受信側によって個別に選択される。ポート番号は、ネットワーキングスタックのパラメータに従って、通常はエフェメラルポートの範囲からランダムに選択される。
開始ホストAは、ポート番号69でホスト名SにRRQ（読み取り要求）またはWRQ（書き込み要求）パケットを送信する。このパケットには、ファイル名、転送モードのほか、オプションで RFC 2347 の規定に基づく任意のネゴシエーションオプションが含まれる。
Sは、オプションが使用された場合にはオプションACK、WRQに対してはACK（確認応答）パケットを送信し、RRQに対しては直接データパケットを送信することで応答する。パケットはランダムに割り当てられたエフェメラルポートから送信され、これ以降のホストSへのパケットは全てこのポートに転送される。
送信元ホストは、番号付きのデータパケットを送信先ホストに送信する。最後のパケット以外には、フルサイズのデータブロック（デフォルトでは512バイト）が含まれている。宛先ホストは、すべてのデータパケットに対して番号付きのACKパケットで応答する。
最後のデータパケットは、フルサイズ未満のデータブロックでなければならない。これによって、それが最後のデータパケットであることを相手に知らせる。転送されたファイルのサイズがブロックサイズの正確な倍数である場合は、送信元は最後に0バイトのデータを含むデータパケットを送信する。
受信側は、対応するデータパケットと同じ番号をつけたACKパケットを送信することで、データパケットに対し確認応答する。送信側は、受信したACKパケットに対し、次のデータパケットを送信することで確認応答する。
ACKパケットが受信されず、再送信タイマーがタイムアウトした場合、データパケットを再送信する。
TFTPは常にネットワーク起動に関連付けられている。1984年に公開されたTFTP標準を使用したブートストラップロード RFC 906 では、1981年に公開されたTrivial File Transfer Protocol標準 RFC 783をブートストラップロードの標準ファイル転送プロトコルとして使用することを定めている。1985年に公開されたBootstrap Protocol(BOOTP)標準 RFC 951により、ディスクレスクライアントマシンが自身のIPアドレス、TFTPサーバのアドレス、ネットワークブートストラッププログラム(NBP)の名前をTFTP転送し、メモリにロードして実行することができるようになった。1997年に発行されたDynamic Host Configuration Protocol(DHCP)標準 RFC 2131では、BOOTP機能を改善した。最後に、Preboot Execution Environment(PXE)バージョン2.0が1998年12月にリリースされ、ファイル転送プロトコルとしてTFTPを利用するアップデート2.1が1999年9月に公表された。インテルは最近、新しいUEFIの仕様内でPXEを広くサポートすることを決定した。これは、TFTPへの対応を全てのEFI/UEFI環境に拡張するものである。
元のプロトコルでは、転送ファイルサイズの上限は512バイト/ブロック×65535ブロック = 32 MBである。1998年には、TFTP Blocksize Option RFC 2348 によってこの制限は65535バイト/ブロック×65535ブロック = 4.294 GBに拡張された。定義されたブロックサイズがネットワークパスにおける最小のMTUを超えるIPパケットサイズを生成する場合、IPの断片化と再構成が発生し、オーバーヘッドが増えるだけでなく、ホストのBOOTPに最小のIPスタックが実装されたかPXE ROMがIPの断片化と再構成を実装していないときに転送が失敗する。
TFTPパケットを標準のイーサネットMTU（1500）以内に保持する必要がある場合、ブロック値は1500からTFTPのヘッダ（4バイト）、UDPヘッダ（8バイト）、IPヘッダ（20バイト）を引いて1468バイト/ブロックと計算され、制限は1468バイト/ブロック×65535ブロック = 92 MBとなる。今日、ほとんどのサーバとクライアントはブロック番号のロールオーバー（65535の後にブロックカウンタが0または1に戻る）に対応しており、これにより、本質的に無制限の転送ファイルサイズを与えることができる。
TFTPはUDPを利用するため、独自のトランスポート層およびセッション層のサポートを提供する必要がある。TFTPを介して転送された各ファイルは、独立した交換を構成する。古典的には、この転送はロックステップで実行され、1つのパケット （データブロックまたは確認応答）だけがネットワーク上を随時送信される。大量のデータブロックを送信してから転送を一時停止して確認応答を待つ（ウィンドウイング）のではなく、単一のデータブロック戦略を取ることにより、TFTPではスループットが低くレイテンシが大きくなる。Microsoftは、Windows 2008にWindows展開サービス(WDS)の一部としてウィンドウ化TFTPを導入し、2015年1月にTFTP Windowsize Option RFC 7440 が公開された。これにより、Blocksize Option RFC 2348 で時々見られるIPフラグメンテーションの副作用なしに、PXEブートなどをする際のパフォーマンスをかなり改善する。