mc_title2Mac Clinic Tips:
CATV/ADSL接続の問題点の解決
−IPNetTunerによるTCP/IPの最適化
How to Speed-up ADSL/CATV Connection by IPNetTuner

修正１：2001年4月23日
初稿：2001年4月17日
目次：
1..ADSLの物理的な原因
2. ソフト的な問題−TCP/IPパラメータ
3. IPnetTunerを使ったTCP/IPのチューニング
4. チューニングの実際

最近、ブロードバンド接続として、CATVやADSLが話題になっている。しかし、CATVやADSLを導入したのにスピードが出ないという問題や、フレッツADSL接続に変えたら、特定のホームページの見れなくなった、という問題も頻発している。
原因にはADSLという方式のハード的な問題と、接続方法であるTCP/IPやPPPoEの設定の問題がある。今回は、現在分かっている原因と、考えられる対応策をまとめてみた。
ソフト的な対応策として注目されているのが、シェアウェアのIPNetTunerというアプリケーションである。これはMacのTCP/IPのパラメータをチューニングするツールであるが、その使用にはかなりの専門知識を必要とする。今回、Mac ClinicではIPNetTuner日本語化キットを作成したので、その使用法の解説も合わせて説明する。
このテキストは、ADSLでの事例を中心としているが、IPNetTunerはCATVや低速のアナログモデム、ISDN接続（TA，ルーターを問わず）の速度改善にも使用することが出来、最後にそれらの例も加えたので、ユーザーは参考にして欲しい。


1.ADSLの物理的な原因

■電話局からの距離が重要
CATVの場合は関係ないが、ADSLの場合は電話局からの距離が速度に影響を与える。ASDLは通常の電話回線を用いデジタル信号を流している関係から、電話局との距離が長くなるほど減衰やノイズの影響を受けやすくなり速度は低下する。
近ければ近い程よいが、定格の最高速が保証されるのは2Km以内だと言われている。4Km程度でも接続できている例もあるようだが、速度は400Kbps程度で我慢せざるを得ない（それでもISDNよりは十分に速いが）。

これが大都市以外の地方ではADSLがなかなか整備されない一つの要因となっている。セルラー式の携帯電話と同じ（これも数百メートルごとに中継基地が必要）で、ADSLは人口密度の高い地域でなければ整備できない構造になっている。

■電話線の品質の問題
先にも述べたように、ADSLはノイズの影響を受けやすい。ノイズを受けると当然、正しいデータが送られなくなる。TCP/IPでは送信側と受信側で正しくデータが送られているかのチェックを行い、エラーのデータやデータが損失されると、それが送信側に通知され再度同じデータが送られてくる。ノイズが多い回線では、このデータの再送の頻度が増え、実際のデータの転送速度は遅くなる。

ノイズには二つの種類があり、一つは電源ノイズだ。ADSLモデムは電源ノイズの影響を受けやすく、これが速度を低下させることがある。ADSLモデムにはそのためにアース端子が備えられており、できる限りこれを接地することが好ましい。アース端子はエアコン、洗濯機、電子レンジ用のコンセントについていることが多い。アースの接続で1Mbpsから1.1Mbpsへ約100Kbpsほど高速化したという報告がある。

電源ノイズをカットするオーディオ機器用のノイズフィルタを用いるのも良いかもしれない。

2番目のノイズの原因は、戸外の電話線の問題だ。
電話局から家庭まではアナログ電話、ISDN、ADSLのどれも同じ電話線を使用している。NTTの電話局の中でそれぞれ異なる交換機に接続しなおしている。電柱の上を走っている集合ケーブル（カッドという）は複数の家用の電話線が束になって入っている。アナログ電話とISDN、アナログ電話とADSLの組み合わせの場合はお互いにノイズの影響を受けないが、ISDNとADSLの電話線が隣り合わせにあるとノイズの影響を受けると言われている。

NTTの説明によると、基本的には同一集合ケーブルにADSLとISDNを混在させることはなく、分離するように配線しているようだが、最近はやりのインターネットマンションのようにすべてISDNになっている場合はこれが出来ないことがあるらしい。ただ一般には、集合ケーブルにはかなりの回線の余裕が持たせてあるので、回線を交換してもらえばよい。

こうした回線調整は東京めたりっく通信などでは無料で行ってくれるそうだが、フレッツ・ADSLの場合は有料になるという。いずれにしても、極端に速度がでない場合や、ADSL開設当初は速度がでていたのに急にでなくなったというような場合は、通信業者に相談してみるとよい。


2. ソフト的な問題−TCP/IPパラメータ

■TCP/IPの仕組み(1)　パケットサイズ(MTU)
TCP/IPによる通信では一つのデータは、パケット（またはデータグラム）と呼ばれる特定の長さのデータ単位に分割され転送される。それぞれのパケットは独立して最短のルートを探して送り先に届けられるが、それを正しく行うために荷札のような情報（ヘッダやフッタと呼ぶ）がそれぞれにパケットに付加される。そのためネットワーク上を流れるデータの総量は実際のデータ量よりも大きくなる。特にフレッツADSLで使われているPPPoE（PPP over Ethernet）では、プロバイダのゲートウェイとルータとの間をトネリングさせてPPPで接続する方式のため、さらに多くのヘッダが付加される。 つまり、パケット数が増えるほど、実際のデータ以外の情報が増えることを意味している。

TCP/IPではデータの分割数を決めるのではなく、パケットのサイズを規定する。これは、宅急便でリンゴのようなものを送るとき、あらかじめ箱のサイズが決められているようなものだ。
パケットのサイズはTCP/IPでは「最大転送単位」（MTU＝Max Transfer Unit）として、ダイヤルアップ先ごと、ネットワークボードごとに設定することが可能となっている。

同じデータを伝送するなら、パケット数はなるべく少ない方がいいわけで、MTUをできる限り大きくするのが良いように見えるが、むやみやたらと増やすべきではない。MTUが大きすぎると、細かなデータを多数やりとりするようなとき（小さな画像をたくさん使っているホームページなど）に効率が悪くなる。最後のパケットに発生する余分なデータ領域が増えてしまう。また、経路中のネットワークに設定されているMTUよりも大きなパケットを送ると、途中でデータが分割されてしまうこともある。

■特定のホームページが見れない！ｰMTUの謎

MacでもWindowsでもTCP/IPのMTUのデフォールト値は1500になっている。
これはEthernetのMTU値が1500であるためだ。
CATVモデムやADSLモデムの場合は、より大サイズのMTUにも対応しているのだが、Ethernet環境で使うことを考えると、1500以上にすることは意味がない。
従って、CATVモデムやADSLモデムはデフォールトの1500で使用するのが基本だが、ウェッブサーバーによってはこれよりも低いMTU値で設定されているものがある。
非常に人気のあるサーバーの場合は、トラフィックが多く、サーバーの負荷が大きい。そのため、各サーバー管理者は最適のパラメータを探し設定している。MTUは時として小さく設定される。
クライアント側が設定しているMTU値よりも、サーバーのMTU値の方が小さい場合、パケットは断片化（フラグメント）されてしまう。断片化されたパケットが送信先にきちんと送り届けられれば再び結合され、データは届いたことになるが、ほとんどの場合は、行き先不明になりデータは未達になる。このため、特定のホームページをダウンロードできない（つまり見れない）という症状が発生する。テキストだけで構成されている、または画像ファイルが非常に小さい（Mac Clinicのようなページ）はよいが、大きな画像やストリーミングファイルを付けたものはその対象となりやすい。

これは引っ越しをするときのトラックのサイズを考えるとわかりやすい。
現在の家も引っ越し先の家も前の道路は6m幅があるため、6トントラックでも大丈夫と判断した。しかし、引っ越しの日、途中の経路で工事があり、狭い道を迂回しなければならなくなった。その道は狭いため、6トントラックは通れず、仕方なく、2トントラックを数台呼んで、荷物を載せ変えて運ぶしか手が無かった。しかしその中の一台がどこかに行ってしまった。始めから2トントラックを手配していれば問題はなかったのだが。ここでは、トラックのサイズがMTUサイズに当たる。

ホームページ以外でも、大きなサイズの添付書類を付けた電子メールの場合は、やはり断片化が起き、不達という症状が起きる。これもメールサーバーのMTU値が1500より小さいことが原因だ。
サーバー以外に、インターネットでは多数のルーターを経由してパケットが送られる。それぞれのルーターも個別のMTU値を設定していることがあり、それがボトルネックとなることがある。

よく見るホームページが見れないという症状が生じたときは、クライアント（Mac）側のMTU値を変更してみるのがよい。

■TCP/IPの仕組み(2)　ウィンドウサイズ
もうひとつ、TCP/IPで通信を行う場合、速度に対し大きな影響を与えているのがウィンドウサイズである。ここでいうウィンドウとは、Macのファインダで現れるウィンドウのことではない。通信を行う場合、送信側と受信側の「窓口」の意味でのウィンドウの大きさだ。物流で言えば納品書、事務所で言えば受付のようなものだ。このサイズが小さいと、せっかく、データが届いても受付ができなくなってしまう。受付が出来ない場合は、受付が出来ないという応答メッセージが送信側に送られ、送信側は再度同じパケットを送信する。これを再送信パケットという。

当然のことながら、再送信パケットが多くなれば、実際の転送速度は遅くなる。特にインターネットのように、応答するにも時間がかかる（遅延時間という）場合はなおさらだ。
従って、ダウンロード速度を高速化したい場合は、この受信側の窓口の大きさを大きくするのが効果がある。

受信側の窓口の大きさは「受信ウィンドウサイズ」または「RWin」（ReceiveWindow Size）と呼ばれる。このサイズは具体的には、相手先への応答なしに、無条件にデータを受け取ることができるバッファの量を表している。送信側は、送信先のRWinがいっぱいになるまでは、受信側の応答を待たずに一気に送信できる。

このサイズはダウンロード先のPC毎に決めることが出来る。
このサイズもMTUと同じように大きくすればいいというものではなく、大きすぎれば今度はPCのCPUへの負担が大きくなる。やはり最適のサイズというのがあるのだ。

一般には、RWINの最適値は（MTU-40）の10倍以上がよいとされており、12〜24倍をためしてみるとよい。
NTT東日本が公開している技術資料によると、フレッツ・ADSLではMTUを1454、RWinを16384に設定すると良いと記している。



3. IPnetTunerを使ったTCP/IPのチューニング

■なぜチューニングが必要か
Macは漢字トーク7.5.3以降、OpenTransportと呼ばれるシステムがネットワークの総合制御を行っている。インターネットの接続プロトコルであるTCP/IPもこの管理下にある。OpenTransportは低速のアナログモデム、低速のLocalTalkから、100Mbpsのイーサネットまでもカバーする優れた仕組みを持っているが、一方でそれがために、ここのネットワークには最適化されていない欠点がある。特に最近のようにブロードバンド接続が普及してくると、TCP/IPの設定が不十分になってきている。

しかし、MacOSにはTCP/IPの内部構成（設定とよんでもよいが一般にはConfiguration＝構成という言葉を使う）をユーザーが変更できる仕組みが無いので、サードパーティ製のソフトを使わざるを得ない。

シェアウェアのIPNetTunerはそれが行える多分唯一のソフトだろう。
これを使うと、ウィンドウサイズ（RWin）、タイムアウト間隔、最大セグメントサイズ（MSS)、最大転送ユニット(MTU)といった、30以上のTCP/IPのパラメータを調整することが可能になる。


■IPNetTunerの基本的な使い方
IPNetTunerでは30以上のTCP/IPパラメータを調整可能だが、TCP/IPに関する専門知識が無いかぎり、その全ての調整を行うのは非常に難しい。
設定を行うには、まず、自分の通信環境がどういう状態なのかを知る必要があるが、IPNetTunerの姉妹ソフトであるｲPMonitorを使うのがよい。さまざまなモニタリングの機能があり、見ているだけでも面白い。これは「モニタ」画面でライブで送受信の速度を表示している例だ。



前章で述べたように、ADSLやCATV接続で調整が必要なのは、一般にはMTUとRWinであり、まずはここだけを調整してみればよいだろう。

IPNetTunerは各自の設定を「設定ファイル」として保存することができる。このファイルをデスクトップに置いておき、ダブルクリックするとIPNetTunerが起動しTCP/IPの構成が修正される。IPNetTunerは自動的に終了するが、この構成はMacを再起動するまで保持される。
毎回設定ファイルをダブルクリックするのが面倒ならば、このファイルをシステムフォルダ内の「起動フォルダ」に入れておけばよい。

また、設定ファイルは配付することもできる。IPNetTunerのアプリケーションフォルダには4つのサンプルファイルが入っている。これを使いさらに調整することも出来る。まだあまり一般的には行われていないが、ネットで各自の設定を配付しても良いだろう。

IPNetTunerの設定は一時的にTCP/IPの構成を変えるもので、TCP/IPそのものを書き換えるわけではないので、もし通信環境が改善されなければ、IPNetTunerの設定を初期値（デフォルト）に戻すか、単にMacを再起動すればよい。何回でも自分で実験をして最適の構成を見つけて欲しい。


4.チューニングの実際

例１：フレッツADSLでホームページが見れなくなった場合の対応

最適のMTU値を探す方法
ADSLに変えたら、「http://www.abc.com」のホームページが見れなくなった仮定しよう。
まずは、TCP/IPのモニタリングツールを使って状況を把握するのがよい。
いくつかのツールがあり、Mac ClinicではIPNetMonitorとWhat Routeの日本語化キットを提供しているが、ここではIPNetMonitorを使う。

IPNetMonitorを起動し、「ルートを追跡」(traceroute)画面を選択する。
検索先の名称欄に「www.abc.com」とサーバー名を入力する。IPアドレスが分かっている場合は、それでもよい。「追跡」ボタンを押すと、「www.abc.com」サーバーまでに経由している全てのルータが表示される。
これらのルーターの中に問題がある可能性もあるが、ほとんどの場合は、WWWサーバー（ウェッブサーバー）に原因があるので、今回の観察は観察にとどめておく。

次に、同じIPNetMonitorの「Ping」画面を選択する。
Ping（ピング）というのは、ピンポン(PingPong）のピンで、相手のサーバーに小さなパケット（データの塊）を送り、送り返されるまでの時間（ラウンドトリップ時間）を測定する手法である。
Ping画面の下でパラメータを入力できる。
制限＝Pingの回数（初期値は10回、このままでよい）
遅延＝次のPingを送るまでの間隔（初期値は1秒、これもこのままでよい）
サイズ＝1回のPingで送るセグメントのサイズ。これが今回測定したいMTUを決定する。
まずは、名称欄に「www.abc.com」とサーバー名を入力する。IPアドレスが分かっている場合は、それでもよい。
そして「検証」ボタンを押す。すると、Pingが10回行われる。
今回は、往復時間の値はあまり意味を持たない。損失無く受信が出来ていればそのセグメントサイズはOKだということだ。

サイズに1500を入れてピングを実行する。
次のダイアログのように、受信欄に×が付き、受信数はゼロ、損失は100%と表示される。
これは、相手サーバーのMTU値が1500よりも小さいため、先にも述べたように断片化（フラグメント）が発生し、ピンされたセグメントが受信できないということを表している。



フレッツADSLの場合、MTUの最適値は1454とされており、NTTから渡されるPPPoE接続ツールでも自動的にMTU＝1454に設定される。東京めたりっくやイーアクセスの場合は、PPPoE接続ツールがそうなっておらず、まずは初期値の1500から始めることになる。
NTTによると，1454というMTU値はどんな経路でパケットが流れても，絶対にフラグメント（パケットが分割されること）しない最大サイズということである。
1500なり1454でスタートして、見えないホームページなどがあれば、IPNetTunerの「ip_interface_MTU」で１つづつ減らして最適値を探すとよい。
サイズをにいろいろな数字を入れて、ピングを繰り返す。
断片化が起きない、損失ゼロのもので最大のサイズが最適のMTU値になる。

最適のMTU値が決まったら、IPNetTunerの「tcp_interface_MTU」画面で、値を入力し、「実行」する。その設定ファイルを保存して次回から使用すればよい。




今までの設定ファイルをテキストエディタで開いて、MTUの数値を変えて保存してもよい。


例2：CATV/ADSLモデムで速度が出ない場合の対応
CATVモデムやADSLモデムは上り下りの速度が異なる非対称通信方式をとっている。しかし、OpenTransportの初期設定はこの方式には最適化されていない。特に、初期設定の「TCP受信ウィンドウサイズ」が非常に小さいため、ウィンドウがすぐに満タンになり、データは待機状態になる。

受信ウィンドウサイズ(RWnd)を調整するには、IPNetTunerの「tcp_rwin_mss_multiplier」を設定する。一見このサイズはできる限り大きくすればいいようにみえるが、かえって潜伏期間が長くなったり不要にメモリを消費することになるので、最適な大きさを見つける必要がある。




RWnd初期値設定(画面設定はゼロを入力）は約16KB（MSS1460バイト*x12)になっている。（*MSS=MTUー40）
PNetTunerのマニュアルには「CATVモデムや/ADSLモデムの場合は、36KBから初めて少しづつ増やしていくのがよい。」と書いてあり、この場合は「tcp_rwin_mss_multiplier」値は24となる。次の読者の例にもあるように、大きな数値が効果がある場合と、初期設定以下（1〜11では初期設定より小さくなる）の方が速度が改善されたと言う報告もあるので、とにかくいろいろ試行錯誤するのがよいようだ。

●読者の改善例1
PowerMac G3 DT233( OS8.6 )を使用中。先日、フレッツADSLに加入しましたが、FTPソフトで高い通信速度を出すとフリーズ、あるいは、エラー12、システムトラップなどが出て困っておりました。
このテキストの解説に従い、受信ウィンドウサイズ(RWnd)を36ぐらいにして試してみたところ、フリーズ＆エラー12は、まるで嘘のようになくなり、今はインターネット常時接続を楽しんで おります。プロバイダや、LANカードに問題があると思っていましたが、TCP/IPの問題だったんですね。
（2001.4.21　Zeroさん）

●読者の改善例2
iMac/233(Rev.A)(メモリ96M)を使用。大阪在住で、NTT西日本のフレッツADSLサービスを選択。プロバイダは「ぷらら」です。
接続速度は、時刻やサイトによってばらつきがあり、最高で1MB、最低で450Kbps、平均して500〜800Kbps位でした。こんなものかと思いましたが、IPNetTunerで改善が出来るものかと思い、試してみました。
フレッツ接続ツールを起動した状態で、IPNetTunerを起動し、「ip_interface_MTU」 を見ると、設定値は1447になっていました。Mac用のフレッツADSL接続ツールの初期設定値は1447のようです。これを1454に変更しても顕著な変化が確認できないので、これはこのままで使用しています。
次に、「tcp_rwin_mss_multiplier」を9に変更した時に、明らかな速度の向上が認められました。8でもよく似た結果ですが、9の方が少しいいようですので、9に設定しました。
新しい設定を行ってからは、900bpsより落ち込む事はほとんどなく、安定して900Kbpsk〜1Mbps強が出るようになりました。IPNetTunerさまさまです。
速度計測のために、" http://member.nifty.ne.jp/oso/speedtest/ "を使用しました。
（2001.4.23　Y.K.＠大阪）


例3：低速モデム/ISDNでのFTP速度の改善
28.8Kbpsのモデムを経由してFTPアップロード速度が実際どうなっているかを見てみよう。まず、IPNetMonitorを起動し、「TCP情報」画面を開く。（表示は全て日本語化キットによる日本語版を使用している）
「開始」ボタンを押すと、データがどう送られてきているかをライブで見ることが出来る。


グラフの水平方向は時間を現し、大きな一目盛りが10秒に当たる。縦方向はデータの転送速度を表す。グラフの棒のうち、赤い棒は受信されたデータの量、オレンジの棒は再送信されたデータ量を表示している。
左側には、送信、再送信データの数と、受信データの数ならびにその平均速度、損失データの数などが表示される。再送信データとは、受信ウィンドウサイズが小さいなどの理由で再度送られたデータである。損失とはどこか経路の中で消滅してしまったデータで、これも再送信される。重複データは、例えば、受け取り確認に非常に時間がかかった場合、送信側は届かなかったものと判断し（この判断までの時間をタイムアウト間隔という）再送信する、実際には届いていたのだから重複項目になる。
これらのことがこの画面に表示される。

今回の状況を観察すると、オレンジのグラフや統計値から、再送信データが非常に多いことが分かる。結果として、全体の速度が遅くなっている。

再送信データが多い原因としては、低速モデムの場合は、再送信のタイムアウト間隔が非常に短いためであることが多い。ADSLのような高速通信の場合は、さらに受信ウィンドウサイズ（RWin)が原因となっている可能性がある。
この場合は、低速モデムであるので、再送信のタイムアウト間隔を増加してみよう。ここでは、IPNetMonitor設定ファイルである「OTTCPSlowLinkTuneup」（IPNetMonitorフォルダ内にある）を使ってみた。
「OTTCPSlowLinkTuneup」をオプションを押しながらダブルクリックし、IPNetTunerを起動する。（表示は全て日本語化キットによる日本語版を使用している）



プルダウンメニューのうち、「tcp_rexmt_interval_min」を開くと、設定値が初期値の200から1500に変わっているのがわかる。
再度、同じ状態をIPNetMonitorのTCP情報ウィンドウで見てみよう。



オレンジのバーが全く無くなり、統計欄の再送信データも0%となっていることが分かる。
TCP再送信タイムアウト間隔の増加が有効であったことになる。

例4：アナログモデムでファイルのダウンロードとブラウジングを同時におこなう
ホームページからファイルをダウンロードしている間、他のホームページを閲覧するということは一般的だろう。しかし、FTPダウンロードで回線が占有され、閲覧の方が無反応になることがある。
これが現実にはどういう現象なのかをIPNetMonitorの「接続リストウィンドウ」の最大セグメントサイズ（MSS)と受信ウィンドウサイズ(RWnd*1)を見てみよう。

*1　TCP/IPのパラメータではrwinが正しいが、IPNetTunerではRWndと表示される。




28.8Kbpsモデムでは、既に圧縮されたファイルは3Kbpsが持続されるダウンロード速度になる。17520の受信ウィンドウサイズで受信した場合、17Ｋ÷3＝6で、6秒分のデータしか受け付けられないことになる。つまり、FTPデータのダウンロードが優先されると、6秒間はホームページのダウンロードが出来なくなり、ホームページの表示に中断が生じる。
IPNetTunerを使うと、ブラウザーの反応を向上させながら、同時にFTPダウンロードの速度も速めることが出来る。
以下の表は、IPNetTunerを使って、「tcp_mass_max」と「tcp_rwin_mss_multiplier」の設定を変化させた場合の効果だ。


最大セグメントサイズ(MSS)ﾊﾞｲﾄMSS倍数受信ウィンドウ(RWnd)ﾊﾞｲﾄダウンロードB/W KBPING時間 秒飛行中FTPデータ量　秒相当
1,4601217,5201.84.49.5
1,460913,1402.74.04.8
1,46068,7602.82.63.0
1,46034,3802.71.11.6
53684,2882.71.21.6
268164,2882.71.41.6
53663,2612.71.01.6
1,46022,9202.70.71.1
53642,1442.70.50.8
26882,1442.60.70.8
1,46011,4602.10.30.7
53621,0722.40.30.4
26841,0722.50.30.4
53615361.30.20.4
26825361.40.20.4
26812680.90.20.3


第一行目はOpenTransportの初期設定で、パケットサイズ、ウィンドウサイズとも大きい。モデム接続の場合は、バンド幅（帯域）、相互反応とも弱くなる。

イーサネット接続では大きなパケットサイズや大金あウィンドウサイズは恩恵があるが、低速のモデムでは小さな設定の方がよい。例えば、31Kモデムの場合では、500バイトのパケットサイズでも0.15秒かかることになる。

目的のサイトに対して潜伏データを十分なデータでカバーさせるには、受信ウィンドウサイズを大きくすることが必要である。低速のモデムでは1秒分のデータで十分だということだ。これにより、ダウンロードの速度と相互反応の最適の組み合わせが出来る。

OpenTransportの初期設定を使いナローバンドでFTPダウンロードを行う場合は、重複項目が多くなる傾向がある。これは、受信ウィンドウまでに届く時間が遅いため、送信側は受信確認がタイムアウトになり、不達と判断して再送信するためである。

従って、低速モデムでFTPとホームページ閲覧の同時進行の速度を改善するには、以下のような設定がよい。

#auto
tcp_mss_max=536
tcp_rwin_mss_multiplier=6
tcp_rexmit_interval_initial=3000
tcp_rexmit_interval_min=3000
tcp_conn_grace_period=3000
#end



参考資料：
IPNetTuner Documentation and Examples, Sustainable Softworks, 2001
わが家のブロードバンド化計画、ZDNetニュース　2001.3.16 & 3.23
フレッツ・ADSL導入記
ぷらら・フレッツＡＤＳＬサービス掲示板他


(C)2001　ハリー小野（Harry Ono）
無断転載、リンク等を禁止します<