訳: 岡橋 一輝 最終更新日: 1999/7/4 --- Network Working Group G. Malkin Request for Commments: 2348 Bay Networks Updates: 1350 A. Harkin Obsoletes: 1783 Hewlett Packard Co. Category: Standards Track May 1998 TFTP Blocksize Option TFTP ブロックサイズオプション 本書の位置付け（Status of this Memo） 本書は Internet Community のために標準化過程プロトコルについて記して おり、改善に向けての議論や提案を求めるものである。このプロトコルの標準 化の現状については Internet Official Protocol Standards（STD1）の最新 版を参照されたい。本書の配布は無制限に行ってよい。 著作権（Copyright Notice） Copyright (C) The Internet Society (1998). All Rights Reserved. 概要（Abstract） 簡易ファイル転送プロトコルは、クライアントから遠隔ホストのファイルを 読み書き可能にする、簡潔かつ安全だが融通の利かないファイル転送機構であ る。主な利用法の一つには、記憶装置を持たない LAN 上のホストを起動させ るというのがある。TFTP は実装が非常に容易であり、容量が小さい ROM に直 接焼き付けるのも可能なため、よく利用される。しかし、ブロックの大きさが 512octet の固定長だと、MTU（最大転送単位）が 1500octet 以上ある LAN 上 ではとても効率的とは言えない。 本書では、クライアント・サーバ間の折衝によってブロックの大きさをネッ トワーク媒体に最適化する方法を述べる。TFTP オプションの拡張機構につい ては [RFC2347] を参照せよ。 ブロックサイズオプション仕様（Blocksize Option Specification） TFTP の読み出し、書き込み要求パケットを以下の様に修正し、ブロックサ イズオプションを指定できるようにする。Opcode 以外のフィールドは 0x00 で終端することに注意せよ。 +--------+--------+---+------+---+---------+---+---------+---+ | Opcode |Filename| 0 | Mode | 0 | blksize | 0 | #octets | 0 | +--------+--------+---+------+---+---------+---+---------+---+ Opcode [RFC1350] の定義通り、読み出し要求の場合は 1、書き込み要求の場合 は 2 を入れる。 Filename [RFC1350] の定義通り操作対象のファイル名を入れる。 Mode [RFC1350] の定義通りファイル転送モードを入れる。netascii、octet mail のうちいずれかの文字列。 blksize ブロックサイズオプションを表す blksize という文字列を入れる。大 文字と小文字は区別しない。 #octets 希望するブロックの octet 数を ASCII 文字列で入れる。正当な値の範 囲は 8octet 以上、65464octet 以下である。この値はデータ部分の octet 数を指定しているのであって、TFTP ヘッダの 4octet は含まな い。 例を挙げよう: +-------+--------+---+-------+---+---------+---+--------+---+ | 1 | foobar | 0 | octet | 0 | blksize | 0 | 1428 | 0 | +-------+--------+---+-------+---+---------+---+--------+---+ これは foobar というファイルの読み出し要求である。転送モードをバイナ リ、ブロックの大きさを 1428octet にするよう要求している。（1428octet というのは、TFTP、UDP、IP の各ヘッダを付け加えても Ethernet の MTU に 収まる程度のデータ長である） オプションを許可する場合、サーバはクライアントに OACK を送信する。 OACK で応答するブロックサイズは、クライアントの指定値と等しい、もしく は小さい値でなければならない。OACK を受け取ったクライアントは、そこに 格納された値を承諾するか、もしくは ERROR パケット（Error Code 8）を返 送して転送を終了しなければならない。 最終 DATA パケットを識別する手段については、RFC1350[1]から特に変更し ない。折衝で決定したブロックサイズより小さいデータ長のパケットが到着す れば、それが転送終了の合図である。ブロックサイズが全転送量より大きい場 合、先頭のパケットがそのまま最終パケットになる。全転送量がブロックサイ ズの整数倍になる場合、Data フィールドを含まない余分な DATA パケットが 転送終了を知らせる。 実証実験（Proof of Concept） 試作段階の実装で様々なブロックサイズによる性能実験を行った。実験には 軽負荷の Ethernet に接続した HP-UX 9000 を利用し、2.25MB のファイルを octet モードで転送した。ルータを経由する場合（g）と経由しない場合（n） について、各々五回の平均転送時間を測った。結果は以下の通り: | 37 + g | 35 + | 33 + | 31 + | 29 + | 27 + | g blocksize n-time g-time 25 + --------- ------ ------ s | n 512 23.85 37.05 e 23 + g 1024 16.15 25.65 c | 1428 13.70 23.10 o 21 + 2048 10.90 16.90 n | 4096 6.85 9.65 d 19 + 8192 4.90 6.15 s | 17 + g | n 15 + | n 13 + | 11 + n | g 9 + | 7 + n | g 5 + n " 0 +------+------+--+---+------+------+--- 512 1K | 2K 4K 8K 1428 blocksize (octets) ルータを経由しない場合の転送時間について、512octet 標準とそれ以外を 比較してみよう: 1024 2x -32% 1428 2.8x -42% 2048 4x -54% 4096 8x -71% 8192 16x -80% 当初の期待通りブロックサイズの増加に伴って転送時間が減少した。これは 行き来するパケットの総数が減ったためである。たとえば、ブロックサイズを 512octet から二倍にすれば、データパケットだけでなく確認応答の回数も半 減して応答に対する待ち時間が節約できる。更に、余分なフレーミングを減ら してオーバヘッドを回避するという副次効果もある。 もちろん、ブロックサイズが MTU を上回れば、IP による断片化と再構成に よりオーバヘッドを招くことになる。この影響は経由ルータ数が増加するほど 顕著なものになるだろう。 セキュリティに関する考察（Security Considerations） TFTP 自体には何のセキュリティ機構も存在しない。この事実に起因してか TFTP はファイルのリネームや削除、それに上書きといった悪用され得る機能 を具えていない。今回の拡張によって TFTP のセキュリティが強化されるわけ ではないが、逆に危険が増加することもない。 参照資料（References） [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, October 1992. [RFC2347] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347, May 1998. 著者の連絡先（Authors' Addresses） Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 10821 Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com Art Harkin Networked Computing Division Hewlett-Packard Company 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com 著作権（Full Copyright Statement） Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.